draft-ietf-ngtrans-isatap-05.txt   draft-ietf-ngtrans-isatap-06.txt 
NGTRANS Working Group F. Templin NGTRANS Working Group F. Templin
INTERNET-DRAFT Nokia INTERNET-DRAFT Nokia
T. Gleeson T. Gleeson
Cisco Systems K.K. Cisco Systems K.K.
M. Talwar M. Talwar
D. Thaler D. Thaler
Microsoft Corporation Microsoft Corporation
Expires 18 April 2003 18 October 2002 Expires 31 April 2003 31 October 2002
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
draft-ietf-ngtrans-isatap-05.txt draft-ietf-ngtrans-isatap-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts. may also distribute working documents as Internet- Drafts.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
over ISATAP links (i.e., automatic IPv6-in-IPv4 tunneling), including over ISATAP links (i.e., automatic IPv6-in-IPv4 tunneling), including
a new EUI-64 [EUI64] based interface identifier [ADDR][AGGR] format a new EUI-64 [EUI64] based interface identifier [ADDR][AGGR] format
that embeds an IPv4 address. This format supports configuration of that embeds an IPv4 address. This format supports configuration of
global, site-local and link-local addresses as specified in [AUTO] as global, site-local and link-local addresses as specified in [AUTO] as
well as simple link-layer address mapping. Simple validity checks for well as simple link-layer address mapping. Simple validity checks for
received packets are given. Also specified in this document is the received packets are given. Also specified in this document is the
operation of IPv6 Neighbor Discovery for ISATAP, as permitted for operation of IPv6 Neighbor Discovery for ISATAP, as permitted for
NBMA links by [DISC]. The document finally presents deployment and NBMA links by [DISC]. The document finally presents deployment and
security considerations for ISATAP. security considerations for ISATAP.
********************************************************************
PLEASE NOTE:
The current version of this specification embodies several opera-
tional issues for anticipated deployment scenarios. These issues are
clearly delineated in "starred" blocks such as this in the current
document for now. They will be resolved in a new version of the spec-
ification to be released in the near future.
********************************************************************
2. Applicability Statement 2. Applicability Statement
ISATAP provides the following features: ISATAP provides the following features:
- treats site's IPv4 infrastructure as an NBMA link layer using - treats site's IPv4 infrastructure as an NBMA link layer using
automatic IPv6-in-IPv4 tunneling (i.e., no configured tunnel state) automatic IPv6-in-IPv4 tunneling (i.e., no configured tunnel state)
- enables incremental deployment of IPv6 hosts within IPv4 sites with - enables incremental deployment of IPv6 hosts within IPv4 sites with
no aggregation scaling issues at border gateways no aggregation scaling issues at border gateways
skipping to change at page 4, line 12 skipping to change at page 3, line 46
an IPv6 node that has an ISATAP interface over which it forwards an IPv6 node that has an ISATAP interface over which it forwards
packets not explicitly addressed to itself. packets not explicitly addressed to itself.
ISATAP host: ISATAP host:
any node that has an ISATAP interface and is not an ISATAP router. any node that has an ISATAP interface and is not an ISATAP router.
4. Transmission of IPv6 Packets on ISATAP Links 4. Transmission of IPv6 Packets on ISATAP Links
ISATAP links transmit IPv6 packets via automatic tunneling using the ISATAP links transmit IPv6 packets via automatic tunneling using the
site's IPv4 infrastructure as an NBMA link layer. Automatic tunneling site's IPv4 infrastructure as an NBMA link layer. Automatic tunneling
for ISATAP uses the same mechanisms specified in [MECH,3.1-3.6], for ISATAP uses the same encapsulation, hop limit, IPv4 header con-
i.e., IPv6 packets are automatically encapsulated in IPv4 using 'ip- struction, and decapsualtion specifications in [MECH, 3], i.e., IPv6
protocol-41' as the payload type number. packets are automatically encapsulated in IPv4 using 'ip-protocol-41'
as the payload type number. The specifications in [MECH, 3.2, 3.4] do
******************************************************************** not apply for ISATAP; instead:
Operational Issue #1:
The [MECH] document referenced above is currently undergoing a (bis) - The default link MTU SHOULD be set to the minimum IPv6 MTU of
revision that will likely require future changes to the above text. 1280 bytes [IPV6], unless specific configuration information
is available. The Don't Fragment bit SHOULD NOT be set in the
encapsulating IPv4 header.
******************************************************************** - IPv4 ICMP errors and ARP failures may be processed as
link error notifications, as allowed by [DISC]
Specific considerations for ISATAP links are given below: Specific considerations for ISATAP links are given below:
4.1. ISATAP Interface Identifier Construction 4.1. ISATAP Interface Identifier Construction
IPv6 unicast addresses [ADDR][AGGR] include a 64-bit interface iden- IPv6 unicast addresses [ADDR][AGGR] include a 64-bit interface iden-
tifier field in "modified EUI-64 format", based on the IEEE EUI-64 tifier field in "modified EUI-64 format", based on the IEEE EUI-64
[EUI64] specification. (Modified EUI-64 format inverts the sense of [EUI64] specification. (Modified EUI-64 format inverts the sense of
the 'u/l' bit from its specification in [EUI64], i.e., 'u/l' = 0 the 'u/l' bit from its specification in [EUI64], i.e., 'u/l' = 0
indicates local-use.) ISATAP interface identifiers are constructed by indicates local-use.) ISATAP interface identifiers are constructed by
prepending the 32-bit string '00-00-5E-FE' with an IPv4 address (see prepending the 32-bit string '00-00-5E-FE' with an IPv4 address (see
the following section for examples). Appendix B includes text the following section for examples). Appendix B includes text
explaining the historical basis for this construction rule. explaining the rationale for this construction rule.
********************************************************************
Operational Issue #2:
The above construction rule unnecessarily wastes bits in the inter-
face identifier that may be useful for other purposes.
********************************************************************
4.2. Stateless Autoconfiguration and Link-Local Addresses 4.2. Stateless Autoconfiguration and Link-Local Addresses
ISATAP addresses are unicast addresses [ADDR,2.5] that use ISATAP ISATAP addresses are unicast addresses [ADDR,2.5] that use ISATAP
format interface identifiers as follows: format interface identifiers as follows:
| 64 bits | 32 bits | 32 bits | | 64 bits | 32 bits | 32 bits |
+------------------------------+---------------+----------------+ +------------------------------+---------------+----------------+
| link-local, site-local or | 0000:5EFE | IPv4 Address | | link-local, site-local or | 0000:5EFE | IPv4 Address |
| global unicast prefix | | of ISATAP link | | global unicast prefix | | of ISATAP link |
skipping to change at page 6, line 20 skipping to change at page 5, line 41
3 (Address Unreachable) [ICMPv6] MUST be returned. No other sending 3 (Address Unreachable) [ICMPv6] MUST be returned. No other sending
rules are necessary. rules are necessary.
The procedure for mapping unicast addresses into link-layer addresses The procedure for mapping unicast addresses into link-layer addresses
is to simply treat the last four octets of the ISATAP address as an is to simply treat the last four octets of the ISATAP address as an
IPv4 address (in network byte order). No multicast address mappings IPv4 address (in network byte order). No multicast address mappings
are specified. are specified.
4.5. Validity Checks for Received Packets 4.5. Validity Checks for Received Packets
ISATAP interfaces MUST silently discard any received packets that do Packets received on ISATAP interfaces MUST satisfy at least one
not satisfy at least one of the following validity checks: (i.e., one or both) of the following validity checks:
- the network-layer (IPv6) source address has a prefix configured on - the network-layer (IPv6) source address has a prefix configured on
the ISATAP interface and an ISATAP-format interface identifier that the ISATAP interface and an ISATAP-format interface identifier that
embeds the link-layer (IPv4) source address, i.e., source is on-link embeds the link-layer (IPv4) source address, i.e., source is on-link
- the link-layer (IPv4) source address is in the Potential Routers List - the link-layer (IPv4) source address is an "active" member of
(see section 5.2), i.e., previous hop is an on-link ISATAP router the Potential Routers List (see section 5.2), i.e., previous
hop is an on-link ISATAP router actively being used by the node
********************************************************************
Operational Issue #3:
The Potential Routers List gives no router reachabilty information.
The second validity check above can lead to packets being accepted
from nodes claiming to be routers, but for which the accepting node
has no affiliation.
******************************************************************** Packets that do not satisfy at least one of the above checks are
silently discarded.
5. Neighbor Discovery for ISATAP Links 5. Neighbor Discovery for ISATAP Links
Section 3.2 of [DISC] ("Supported Link Types") provides the following Section 3.2 of [DISC] ("Supported Link Types") provides the following
guidelines for non-broadcast multiple access (NBMA) link support: guidelines for non-broadcast multiple access (NBMA) link support:
"Redirect, Neighbor Unreachability Detection and next-hop determi- "Redirect, Neighbor Unreachability Detection and next-hop determi-
nation should be implemented as described in this document. Address nation should be implemented as described in this document. Address
resolution and the mechanism for delivering Router Solicitations resolution and the mechanism for delivering Router Solicitations
and Advertisements on NBMA links is not specified in this docu- and Advertisements on NBMA links is not specified in this docu-
skipping to change at page 7, line 16 skipping to change at page 6, line 39
Address resolution and the mechanisms for delivering Router Solicita- Address resolution and the mechanisms for delivering Router Solicita-
tions and Advertisements for ISATAP links are not specified by tions and Advertisements for ISATAP links are not specified by
[DISC]; instead, they are specified in this document. (Note that [DISC]; instead, they are specified in this document. (Note that
these mechanisms MAY potentially apply to other types of NBMA links these mechanisms MAY potentially apply to other types of NBMA links
in the future.) in the future.)
5.1. Address Resolution 5.1. Address Resolution
Protocol addresses (IPv6) in ISATAP are resolved to link-layer Protocol addresses (IPv6) in ISATAP are resolved to link-layer
addresses (IPv4) by a static computation, i.e., the last four octets addresses (IPv4) by a static computation, i.e., the last four octets
are treated as an IPv4 address. Thus the functions and conceptual are treated as an IPv4 address.
data structures used by [DISC] for the purpose of address resolution
are not required. The conceptual "neighbor cache" described in [DISC]
is still needed for other functions, such as neighbor unreachability
detection, but it is not used for address resolution.
********************************************************************
Operational Issue #4.1:
The static computation used for address resolution on ISATAP links
does not trigger neighbor reachability detection as specified in
[DISC, 7.3.3], leading to possible black holes.
******************************************************************** ISATAP nodes SHOULD perform Neighbor Unreachability Detection (NUD)
as specified in [DISC, 7.3], and MUST send solicited neighbor adver-
tisements as specified in [DISC, 7.2.4].
The link-layer address option used in [DISC] is not needed. Link- The link-layer address option used in [DISC] is not needed. Link-
layer address options SHOULD NOT be sent in any Neighbor Discovery layer address options SHOULD NOT be sent in any Neighbor Discovery
packets, and MUST be silently ignored in any received Neighbor Dis- packets, and MUST be silently ignored in any received Neighbor Dis-
covery packets. covery packets.
5.2. Router and Prefix Discovery 5.2. Router and Prefix Discovery
Since the site's IPv4 infrastructure is treated as an NBMA link Since the site's IPv4 infrastructure is treated as an NBMA link
layer, unsolicited Router Advertisements do not provide sufficient layer, unsolicited Router Advertisements do not provide sufficient
skipping to change at page 8, line 39 skipping to change at page 8, line 4
to be used within a site for this purpose, but administrators to be used within a site for this purpose, but administrators
are encouraged to use the "isatap.domainname" convention are encouraged to use the "isatap.domainname" convention
(e.g., isatap.example.com), as specified in [RFC2219]. Nodes (e.g., isatap.example.com), as specified in [RFC2219]. Nodes
can construct this domain name by prepending the label "isatap" can construct this domain name by prepending the label "isatap"
to their parent domain name, which is established by other to their parent domain name, which is established by other
means. Nodes then query this domain name for address records means. Nodes then query this domain name for address records
(e.g., DNS 'A' resource records), and initialize the PRL with (e.g., DNS 'A' resource records), and initialize the PRL with
the IPv4 addresses in the replies. the IPv4 addresses in the replies.
3. After initialization, nodes periodically repeat the above 3. After initialization, nodes periodically repeat the above
procedure every ResolveInterval seconds to update the PRL with procedure ResolveInterval to update the PRL with any IPv4
any IPv4 addresses added/deleted since the previous iteration. addresses added/deleted since the previous iteration. When
When DNS is used, nodes MUST follow the procedures in [RFC1035] DNS is used, nodes MUST follow the procedures in [RFC1035]
regarding cache invalidation when the DNS time-to-live expires. regarding cache invalidation when the DNS time-to-live expires.
5.2.2. Validation of Router Advertisement Messages 5.2.2. Validation of Router Advertisement Messages
A node MUST silently discard any received Router Advertisement mes- A node MUST silently discard any received Router Advertisement mes-
sages that do not satisfy the validity checks in [DISC,6.1.2] as well sages that do not satisfy the validity checks in [DISC,6.1.2] as well
as the following additional validity check for ISATAP: as the following additional validity check for ISATAP:
- the network-layer (IPv6) source address is derived from - the network-layer (IPv6) source address is derived from
an IPv4 address in the PRL an IPv4 address in the PRL
skipping to change at page 9, line 25 skipping to change at page 8, line 38
tisement to the address of the node which sent the Router Solicita- tisement to the address of the node which sent the Router Solicita-
tion. The source address of the Router Advertisement is a link-local tion. The source address of the Router Advertisement is a link-local
unicast address associated with the interface. This MAY be the same unicast address associated with the interface. This MAY be the same
as the destination address of the Router Solicitation. ISATAP routers as the destination address of the Router Solicitation. ISATAP routers
MAY engage in the polling process described under Host Specification MAY engage in the polling process described under Host Specification
below (e.g. if Router Advertisement consistency verification below (e.g. if Router Advertisement consistency verification
[DISC,6.2.7] is desired), but this is not required. [DISC,6.2.7] is desired), but this is not required.
5.2.4. Host Specification 5.2.4. Host Specification
Hosts periodically poll each entry in the PRL ("PRL(i)") by sending Hosts periodically poll one or more entries in the PRL ("PRL(i)") by
unicast Router Solicitation messages using the IPv4 address sending unicast Router Solicitation messages using the IPv4 address
("V4ADDR_PRL(i)") and associated timer in the entry. Hosts add the ("V4ADDR_PRL(i)") and associated timer in the entry. Hosts add the
following variable to support the polling process: following variable to support the polling process:
MinRouterSolicitInterval MinRouterSolicitInterval
Minimum time between sending Router Solicitations Minimum time between sending Router Solicitations
to any router. Default and suggested minimum: 15min to any router. Default and suggested minimum: 15min
When PRL(i) is first added to the list, the host sets its associated When a PRL(i) is selected for polling, the host sets its associated
timer to MinRouterSolicitInterval. timer to MinRouterSolicitInterval and initiates polling following a
short delay as for initial solicitations [ND,6.3.7]), and when the
Entries are polled when they are created (following a short delay as associated timer expires.
for initial solicitations [ND,6.3.7]), and when the associated timer
expires.
Polling consists of sending Router Solicitations to the ISATAP link- Polling consists of sending Router Solicitations to the ISATAP link-
local address constructed from the entry's IPv4 address, i.e., they local address constructed from the entry's IPv4 address, i.e., they
are sent to 'FE80::0:5EFE:V4ADDR_PRL(i)' instead of 'All-Routers mul- are sent to 'FE80::0:5EFE:V4ADDR_PRL(i)' instead of 'All-Routers mul-
ticast'. They are otherwise sent in the same manner described in ticast'. They are otherwise sent in the same manner described in
[DISC,6.3.7]. [DISC,6.3.7].
When the host receives a valid Router Advertisement (i.e., one that When the host receives a valid Router Advertisement (i.e., one that
satisfies the validity checks in sections 4.5 and 5.2.2) it processes satisfies the validity checks in sections 4.5 and 5.2.2) it is pro-
them in the same manner described in [DISC,6.3.4]. The host addition- cesses in the same manner described in [DISC,6.3.4]. The host addi-
ally resets the timer associated with the PRL entry that matches the tionally resets the timer associated with the V4ADDR_PRL(i) embedded
network-layer source address in the Router Advertisement. The timer in the network-layer source address in the Router Advertisement. The
is reset to either 0.5 * (the minimum value in the router lifetime or timer is reset to either 0.5 * (the minimum value in the router life-
valid lifetime of any on-link prefixes advertised) or MinRouterSolic- time or valid lifetime of any on-link prefixes advertised) or Min-
itInterval; whichever is longer. RouterSolicitInterval; whichever is longer.
********************************************************************
Operational Issue #4.2:
The Router and Host specifications above effectively treat the IPv4
path as a single IPv6 hop. The host caches link state information for
the hop, but the link is unidirectional (from the host to the router)
and subject to change due to network topology fluctuations. The
router caches no information, thus has no level of assurance that the
host will receive critical ICMPv6 messages, e.g., ICMPv6 Packet Too
Big.
********************************************************************
********************************************************************
Operational Issue #5:
Solutions to 4.1 and 4.2 above may impart control message overhead
explosion if hosts are to poll all routers in the PRL as currently
suggested above.
********************************************************************
6. ISATAP Deployment Considerations 6. ISATAP Deployment Considerations
6.1. Host And Router Deployment Considerations 6.1. Host And Router Deployment Considerations
For hosts, if an underlying link supports both IPv4 (over which ISA- For hosts, if an underlying link supports both IPv4 (over which ISA-
TAP is implemented) and also supports IPv6 natively, then ISATAP MAY TAP is implemented) and also supports IPv6 natively, then ISATAP MAY
be enabled if the native IPv6 layer does not receive Router Adver- be enabled if the native IPv6 layer does not receive Router Adver-
tisements (i.e., does not have connection with an IPv6 router). After tisements (i.e., does not have connection with an IPv6 router). After
a non-link-local address has been configured and a default router a non-link-local address has been configured and a default router
acquired on the native link, the host SHOULD discontinue the 'Router acquired on the native link, the host SHOULD discontinue the 'Router
Polling Process' process specified in section 5.2.4 and allow exist- Polling Process' process specified in section 5.2.4 and allow exist-
ing ISATAP address configurations to expire as specified in ing ISATAP address configurations to expire as specified in
[DISC,5.3][AUTO,5.5.4]. In this way, ISATAP use will gradually dimin- [DISC,5.3][AUTO,5.5.4]. Any ISATAP addresses added to the DNS for
ish as IPv6 routers are widely deployed throughout the site. this host should also be removed. In this way, ISATAP use will gradu-
ally diminish as IPv6 routers are widely deployed throughout the
site.
Routers MAY configure a native link to simultaneously support both Routers MAY configure an interface to simultaneously support both
native IPv6, and also ISATAP (over IPv4). Routing will operate as native IPv6, and also ISATAP (over IPv4). Routing will operate as
usual between these two domains. Note that the prefixes used on the usual between these two domains. Note that the prefixes used on the
ISATAP and native IPv6 interfaces will be distinct. The IPv4 ISATAP and native IPv6 interfaces will be distinct. The IPv4
address(es) configured on a router's ISATAP interface(s) SHOULD be address(es) configured on a router's ISATAP interface(s) SHOULD be
added (either automatically or manually) to the site's address added (either automatically or manually) to the site's address
records for ISATAP router interfaces (see section 5.2.1). records for ISATAP router interfaces (see section 5.2.1).
6.2. Site Administration Considerations 6.2. Site Administration Considerations
The following considerations are noted for sites that deploy ISATAP: The following considerations are noted for sites that deploy ISATAP:
skipping to change at page 11, line 37 skipping to change at page 10, line 32
Router List and 'N' is the total number of nodes on the ISATAP link. Router List and 'N' is the total number of nodes on the ISATAP link.
The MinRouterSolicitInterval ([5.2.4]) bounds control traffic for The MinRouterSolicitInterval ([5.2.4]) bounds control traffic for
large numbers of nodes even in worst-case scenarios. large numbers of nodes even in worst-case scenarios.
- ISATAP nodes periodically refresh the entries on the PRL, typically - ISATAP nodes periodically refresh the entries on the PRL, typically
by polling the DNS. Responsible site administration can reduce the by polling the DNS. Responsible site administration can reduce the
control traffic. At a minimum, administrators SHOULD ensure that control traffic. At a minimum, administrators SHOULD ensure that
the site's address records for ISATAP router interfaces (see the site's address records for ISATAP router interfaces (see
section 5.2.1) are well maintained. section 5.2.1) are well maintained.
********************************************************************
Operational Issue #6:
Sites may enable Network Address Translators (NATs) internally, but
most NATs work only for UDP/IPv4 and TCP/IPv4 packets. ISATAP uses
IPv6/IPv4 encapsulation, and may encounter operational problems in
sites that deploy NATs internally.
********************************************************************
7. IANA considerations 7. IANA considerations
Appendix B gives historical considerations for managing the IEEE OUI Appendix B offers one possible specification for managing the IEEE
assigned to IANA for EUI-64 interface identifier construction. These OUI assigned to IANA for EUI-64 interface identifier construction.
considerations are noted and made freely available to IANA for any This specification is made freely available to IANA for any purpose
purpose they may find useful. they may find useful.
8. Security considerations 8. Security considerations
Site administrators are advised that, in addition to possible attacks Site administrators are advised that, in addition to possible attacks
against IPv6, security attacks against IPv4 MUST also be considered. against IPv6, security attacks against IPv4 MUST also be considered.
Many security considerations in [6OVER4,9] apply also to ISATAP. Many security considerations in [6OVER4,9] apply also to ISATAP.
Responsible IPv4 site security management is strongly encouraged. In Responsible IPv4 site security management is strongly encouraged. In
particular, border gateways SHOULD implement filtering to detect particular, border gateways SHOULD implement filtering to detect
spoofed IPv4 source addresses at a minimum; ip-protocol-41 filtering spoofed IPv4 source addresses at a minimum; ip-protocol-41 filtering
skipping to change at page 12, line 42 skipping to change at page 11, line 22
[DISC,6.1.2] implies that nodes trust Router Advertisements they [DISC,6.1.2] implies that nodes trust Router Advertisements they
receive from on-link routers, as indicated by a value of 255 in the receive from on-link routers, as indicated by a value of 255 in the
IPv6 'hop-limit' field. Since this field is not decremented when ip- IPv6 'hop-limit' field. Since this field is not decremented when ip-
protocol-41 packets traverse multiple IPv4 hops [MECH,3.3], ISATAP protocol-41 packets traverse multiple IPv4 hops [MECH,3.3], ISATAP
links require a different trust model. In particular, ONLY those links require a different trust model. In particular, ONLY those
Router Advertisements received from a member of the Potential Routers Router Advertisements received from a member of the Potential Routers
List are trusted; all others are silently discarded (see section List are trusted; all others are silently discarded (see section
5.2.2). This trust model is predicated on IPv4 source address filter- 5.2.2). This trust model is predicated on IPv4 source address filter-
ing, as described above. ing, as described above.
********************************************************************
Operational Issue #7:
The above trust basis specification incurs the same issue identified
in "Operational Issue #3.
********************************************************************
The ISATAP address format does not support privacy extensions for The ISATAP address format does not support privacy extensions for
stateless address autoconfiguration [PRIVACY]. However, since the stateless address autoconfiguration [PRIVACY]. However, since the
ISATAP interface identifier is derived from the node's IPv4 address, ISATAP interface identifier is derived from the node's IPv4 address,
ISATAP addresses do not have the same level of privacy concerns as ISATAP addresses do not have the same level of privacy concerns as
IPv6 addresses that use an interface identifier derived from the MAC IPv6 addresses that use an interface identifier derived from the MAC
address. address.
Acknowledgements Acknowledgements
Some of the ideas presented in this draft were derived from work at Some of the ideas presented in this draft were derived from work at
skipping to change at page 15, line 47 skipping to change at page 14, line 18
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 703 8835 Phone: +1 425 703 8835
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
APPENDIX A: Major Changes APPENDIX A: Major Changes
changes from version 05 to version 06:
- Addressed operational issues identified in 05 based on
discussion between co-authors
- Clarified ambiguous text per comments from Hannu Flinck;
Jason Goldschmidt
changes from version 04 to version 05: changes from version 04 to version 05:
- Moved historical text in section 4.1 to Appendix B in - Moved historical text in section 4.1 to Appendix B in
response to comments from Pekka Savola response to comments from Pekka Savola
- Identified operational issues for anticipated deployment - Identified operational issues for anticipated deployment
scenarios scenarios
- Included SRI IPR statement and contact information - Included SRI IPR statement and contact information
skipping to change at page 17, line 4 skipping to change at page 15, line 30
interface is assigned a /64 prefix that is distinct from the interface is assigned a /64 prefix that is distinct from the
prefixes assigned to any other interfaces attached to the prefixes assigned to any other interfaces attached to the
node - be they physical or logical interfaces. This approach node - be they physical or logical interfaces. This approach
eliminates ISATAP-specific sending rules presented in earlier eliminates ISATAP-specific sending rules presented in earlier
draft versions. draft versions.
- Changed sense of 'u/l' bit in the ISATAP address interface - Changed sense of 'u/l' bit in the ISATAP address interface
identifier to indicate "local scope", since ISATAP interface identifier to indicate "local scope", since ISATAP interface
identifiers are unique only within the scope of the ISATAP identifiers are unique only within the scope of the ISATAP
prefix. (See section 4.) prefix. (See section 4.)
changes from personal draft to version 00: changes from personal draft to version 00:
- Title change to provide higher-level description of field of - Title change to provide higher-level description of field of
use addressed by this draft. Removed other extraneous text. use addressed by this draft. Removed other extraneous text.
- Major new section on automatic discovery of off-link IPv6 routers - Major new section on automatic discovery of off-link IPv6 routers
when IPv6-IPv4 compatibility addresses are used. when IPv6-IPv4 compatibility addresses are used.
APPENDIX B: Historical Interface Identifier Construction Rules APPENDIX B: Rationale for Interface Identifier Construction Rules
ISATAP specifies an [EUI64]-format address construction for the Orga- ISATAP specifies an [EUI64]-format address construction for the Orga-
nizationally-Unique Identifier (OUI) owned by the Internet Assigned nizationally-Unique Identifier (OUI) owned by the Internet Assigned
Numbers Authority [IANA]. This format (given below) is used to con- Numbers Authority [IANA]. This format (given below) is used to con-
struct both native [EUI64] addresses for general use and modified struct both native [EUI64] addresses for general use and modified
EUI-64 format interface identifiers for use in IPv6 unicast EUI-64 format interface identifiers for use in IPv6 unicast
addresses: addresses:
|0 2|2 3|3 3|4 6| |0 2|2 3|3 3|4 6|
|0 3|4 1|2 9|0 3| |0 3|4 1|2 9|0 3|
skipping to change at page 18, line 20 skipping to change at page 16, line 52
'01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03'). '01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03').
But, the specification also provides a special TYPE (0xFE) to indi- But, the specification also provides a special TYPE (0xFE) to indi-
cate an IPv4 address is embedded. Thus, when the first four octets of cate an IPv4 address is embedded. Thus, when the first four octets of
a [ADDR]-compatible IPv6 interface identifier are: '00-00-5E-FE' a [ADDR]-compatible IPv6 interface identifier are: '00-00-5E-FE'
(note: the 'u/l' bit MUST be 0) the interface identifier is said to (note: the 'u/l' bit MUST be 0) the interface identifier is said to
be in "ISATAP format" and the next four octets embed an IPv4 address be in "ISATAP format" and the next four octets embed an IPv4 address
encoded in network byte order. encoded in network byte order.
INTELLECTUAL PROPERTY INTELLECTUAL PROPERTY
SRI International has sent the following message to the IETF Execu- SRI International has notified the IETF of IPR considerations for
tive Director (Steve Coya) regarding intellectual property rights. some aspects of this specification. For more information consult the
(An auto-reply from Steve Coya's mailer also appears below.) Please online list of claimed rights.
direct all inquiries regarding intellectual property rights pertain-
ing to this document to the contact given in the message below:
Date: Tue, 15 Oct 2002 15:37:47 -0700
To: scoya@ietf.org
From: Peter Marcotullio <jpm@erg.sri.com>
Subject: Revised IPR statement
Dear Mr. Coya,
Please replace SRI's previous IPR statement for the ISATAP Draft "ISI
patent statement pertaining to draft-ietf-ngtrans-isatap" (by the way the
previous statement was mislabeled as "ISI" when it should have been "SRI
International") with the following:
SRI International Patent statement pertaining to draft-ietf-ngtrans-isatap
Statement for 'draft-ietf-ngtrans-isatap-04.txt':
*****************************************************
Patent Rights Statement. SRI International has filed one or more patent
applications pertaining to aspects of this submission. SRI grants
royalty-free permission under such applications and resulting patents for
both commercial and non-commercial uses, for development of and compliance
with IETF standardization purposes. Any aspects or variants of SRI's
submission or intellectual property that are not included in IETF
standards and/or are not necessary for compliance with IETF standards may
require an additional license from SRI under terms to be negotiated by the
parties.
Please feel free to contact me if you have any questions or comments.
Thanks,
Peter Marcotullio
Please note that this revised IPR statement expands the rights that SRI is
granting to the IETF community.
------------------------------------------------------------------------------
Peter Marcotullio
Director, Business Development
Information, Telecommunications and Automation Division
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
+1 650.859.5457
+1 650.859.4812 fax
peter.marcotullio@sri.com
www.sri.com
Date: Tue, 15 Oct 2002 18:35:46 -0400 (EDT)
From: Steve Coya <scoya@ietf.org>
Subject: Gone again
X-Spam-Status: No, score=0.7 threshold=6.0
X-Spam-Level: x
Hi, this is Steve Coya's mail account.
Steve is out of the office and will not return until Tuesday,
October 22. He will NOT be able to respond to email during that
period.
I will make Steve read your message regarding "Revised IPR statement" when he
returns (though replies may take longer - sigh).
Thanks for your patience and understanding.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/