idnits 2.17.1 draft-ietf-ngtrans-isatap-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 28 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '...Pv4 (for ISATAP), and MAY also support...' RFC 2119 keyword, line 119: '...signed to the ISATAP link and MUST NOT...' RFC 2119 keyword, line 143: '...default link MTU SHOULD be set to the ...' RFC 2119 keyword, line 145: '...n't Fragment bit SHOULD NOT be set in ...' RFC 2119 keyword, line 195: '... the ISATAP link MAY be configured ove...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (31 October 2002) is 7846 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6' is mentioned on line 99, but not defined -- Looks like a reference, but probably isn't: '3' on line 138 -- Looks like a reference, but probably isn't: '9' on line 445 == Unused Reference: 'IPV4' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'SIP' is defined on line 549, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'ADDR') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2462 (ref. 'AUTO') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. 'DISC') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2893 (ref. 'MECH') (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 1631 (ref. 'NAT') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NGTRANS Working Group F. Templin 3 INTERNET-DRAFT Nokia 4 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 10 Expires 31 April 2003 31 October 2002 12 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 14 draft-ietf-ngtrans-isatap-06.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet- Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies the Intra-Site Automatic Tunnel Addressing 39 Protocol (ISATAP) that connects IPv6 hosts and routers (nodes) within 40 IPv4 sites. ISATAP is a transition mechanism that enables incremental 41 deployment of IPv6 by treating the site's IPv4 infrastructure as a 42 Non-Broadcast Multiple Access (NBMA) link layer for IPv6. ISATAP 43 mechanisms use an IPv6 interface identifier format that embeds an 44 IPv4 address - this enables automatic IPv6-in-IPv4 tunneling within a 45 site, whether the site uses globally assigned or private IPv4 46 addresses. The new interface identifier format can be used with both 47 local and global unicast IPv6 prefixes - this enables IPv6 routing 48 both locally and globally. ISATAP mechanisms introduce no impact on 49 routing table size and require no special IPv4 services (e.g., IPv4 50 multicast). 52 1. Introduction 54 This document presents a simple approach that enables incremental 55 deployment of IPv6 within IPv4-based sites in a manner that is com- 56 patible with inter-domain transition mechanisms, e.g., [6TO4]. We 57 refer to this approach as the Intra-Site Automatic Tunnel Addressing 58 Protocol, or ISATAP (pronounced: "ice-a-tap"). ISATAP allows dual- 59 stack nodes that do not share a common link with an IPv6 router to 60 automatically tunnel packets to the IPv6 next-hop address through 61 IPv4, i.e., the site's IPv4 infrastructure is treated as an NBMA link 62 layer. 64 This document specifies details for the transmission of IPv6 packets 65 over ISATAP links (i.e., automatic IPv6-in-IPv4 tunneling), including 66 a new EUI-64 [EUI64] based interface identifier [ADDR][AGGR] format 67 that embeds an IPv4 address. This format supports configuration of 68 global, site-local and link-local addresses as specified in [AUTO] as 69 well as simple link-layer address mapping. Simple validity checks for 70 received packets are given. Also specified in this document is the 71 operation of IPv6 Neighbor Discovery for ISATAP, as permitted for 72 NBMA links by [DISC]. The document finally presents deployment and 73 security considerations for ISATAP. 75 2. Applicability Statement 77 ISATAP provides the following features: 79 - treats site's IPv4 infrastructure as an NBMA link layer using 80 automatic IPv6-in-IPv4 tunneling (i.e., no configured tunnel state) 82 - enables incremental deployment of IPv6 hosts within IPv4 sites with 83 no aggregation scaling issues at border gateways 85 - requires no special IPv4 services within the site (e.g., multicast) 87 - supports both stateless address autoconfiguration and manual 88 configuration 90 - supports networks that use non-globally unique IPv4 addresses (e.g., 91 when private address allocations [PRIVATE] are used), but does not 92 allow the virtual ISATAP link to span a Network Address 93 Translator [NAT] 95 - compatible with other NGTRANS mechanisms (e.g., [6TO4]) 97 3. Terminology 99 The terminology of [IPv6] applies to this document. The following 100 additional terms are defined: 102 link: 103 same definition as [AUTO][DISC]. 105 underlying link: 106 a link layer that supports IPv4 (for ISATAP), and MAY also support 107 IPv6 natively. 109 ISATAP link: 110 one or more underlying links used for IPv4 tunneling. The IPv4 111 network layer addresses of the underlying links are used as 112 link-layer addresses on the ISATAP link. 114 ISATAP interface: 115 a node's attachment to an ISATAP link. 117 ISATAP prefix: 118 a prefix used to configure an address on the ISATAP interface. This 119 prefix is administratively assigned to the ISATAP link and MUST NOT 120 be duplicated on native IPv6 links. 122 ISATAP address: 123 an IPv6 address with an ISATAP prefix and an ISATAP format interface 124 identifier constructed as specified in section 4. 126 ISATAP router: 127 an IPv6 node that has an ISATAP interface over which it forwards 128 packets not explicitly addressed to itself. 130 ISATAP host: 131 any node that has an ISATAP interface and is not an ISATAP router. 133 4. Transmission of IPv6 Packets on ISATAP Links 135 ISATAP links transmit IPv6 packets via automatic tunneling using the 136 site's IPv4 infrastructure as an NBMA link layer. Automatic tunneling 137 for ISATAP uses the same encapsulation, hop limit, IPv4 header con- 138 struction, and decapsualtion specifications in [MECH, 3], i.e., IPv6 139 packets are automatically encapsulated in IPv4 using 'ip-protocol-41' 140 as the payload type number. The specifications in [MECH, 3.2, 3.4] do 141 not apply for ISATAP; instead: 143 - The default link MTU SHOULD be set to the minimum IPv6 MTU of 144 1280 bytes [IPV6], unless specific configuration information 145 is available. The Don't Fragment bit SHOULD NOT be set in the 146 encapsulating IPv4 header. 148 - IPv4 ICMP errors and ARP failures may be processed as 149 link error notifications, as allowed by [DISC] 151 Specific considerations for ISATAP links are given below: 153 4.1. ISATAP Interface Identifier Construction 155 IPv6 unicast addresses [ADDR][AGGR] include a 64-bit interface iden- 156 tifier field in "modified EUI-64 format", based on the IEEE EUI-64 157 [EUI64] specification. (Modified EUI-64 format inverts the sense of 158 the 'u/l' bit from its specification in [EUI64], i.e., 'u/l' = 0 159 indicates local-use.) ISATAP interface identifiers are constructed by 160 prepending the 32-bit string '00-00-5E-FE' with an IPv4 address (see 161 the following section for examples). Appendix B includes text 162 explaining the rationale for this construction rule. 164 4.2. Stateless Autoconfiguration and Link-Local Addresses 166 ISATAP addresses are unicast addresses [ADDR,2.5] that use ISATAP 167 format interface identifiers as follows: 169 | 64 bits | 32 bits | 32 bits | 170 +------------------------------+---------------+----------------+ 171 | link-local, site-local or | 0000:5EFE | IPv4 Address | 172 | global unicast prefix | | of ISATAP link | 173 +------------------------------+---------------+----------------+ 175 Link-local, site-local, and global ISATAP addresses can be created 176 exactly as specified in [ADDR], (e.g., by auto-configuration [AUTO] 177 or manual configuration). For example, the IPv6 address: 179 3FFE:1A05:510:1111:0:5EFE:8CAD:8108 181 has a prefix of '3FFE:1A05:510:1111::/64' and an ISATAP format inter- 182 face identifier with embedded IPv4 address: '140.173.129.8'. The 183 address is alternately written as: 185 3FFE:1A05:510:1111:0:5EFE:140.173.129.8 187 The link-local and site-local variants (respectively) are: 189 FE80::0:5EFE:140.173.129.8 190 FEC0::1111:0:5EFE:140.173.129.8 192 4.3. ISATAP Link/Interface Configuration 194 A node configures an ISATAP link over one or more underlying IPv4 195 links, i.e., the ISATAP link MAY be configured over one or more link- 196 layer (IPv4) addresses. Each link-layer address 'V4ADDR_LINK' is used 197 to configure a link-local address 'FE80::0:5EFE:V4ADDR_LINK' on an 198 ISATAP interface. ISATAP interfaces MAY be assigned one per link- 199 layer address, or as a single interface for multiple link-layer 200 addresses. 202 In the former case, the address of each ISATAP interface SHOULD be 203 added to the Potential Routers List (see section 5.2.1). In the lat- 204 ter case, the interface will accept ISATAP packets addressed to any 205 of the IPv4 link-layer addresses, but will choose one as its primary 206 address, used for sourcing packets. Only this address need be repre- 207 sented in the Potential Routers List. 209 4.4. Sending Rules and Address Mapping 211 The IPv6 next-hop address for packets sent on an ISATAP link MUST be 212 an ISATAP address. Packets that do not satisfy this constraint MUST 213 be discarded and an ICMP destination unreachable indication with code 214 3 (Address Unreachable) [ICMPv6] MUST be returned. No other sending 215 rules are necessary. 217 The procedure for mapping unicast addresses into link-layer addresses 218 is to simply treat the last four octets of the ISATAP address as an 219 IPv4 address (in network byte order). No multicast address mappings 220 are specified. 222 4.5. Validity Checks for Received Packets 224 Packets received on ISATAP interfaces MUST satisfy at least one 225 (i.e., one or both) of the following validity checks: 227 - the network-layer (IPv6) source address has a prefix configured on 228 the ISATAP interface and an ISATAP-format interface identifier that 229 embeds the link-layer (IPv4) source address, i.e., source is on-link 231 - the link-layer (IPv4) source address is an "active" member of 232 the Potential Routers List (see section 5.2), i.e., previous 233 hop is an on-link ISATAP router actively being used by the node 235 Packets that do not satisfy at least one of the above checks are 236 silently discarded. 238 5. Neighbor Discovery for ISATAP Links 240 Section 3.2 of [DISC] ("Supported Link Types") provides the following 241 guidelines for non-broadcast multiple access (NBMA) link support: 243 "Redirect, Neighbor Unreachability Detection and next-hop determi- 244 nation should be implemented as described in this document. Address 245 resolution and the mechanism for delivering Router Solicitations 246 and Advertisements on NBMA links is not specified in this docu- 247 ment." 249 ISATAP links SHOULD implement Redirect, Neighbor Unreachability 250 Detection, and next-hop determination exactly as specified in [DISC]. 251 Address resolution and the mechanisms for delivering Router Solicita- 252 tions and Advertisements for ISATAP links are not specified by 253 [DISC]; instead, they are specified in this document. (Note that 254 these mechanisms MAY potentially apply to other types of NBMA links 255 in the future.) 257 5.1. Address Resolution 259 Protocol addresses (IPv6) in ISATAP are resolved to link-layer 260 addresses (IPv4) by a static computation, i.e., the last four octets 261 are treated as an IPv4 address. 263 ISATAP nodes SHOULD perform Neighbor Unreachability Detection (NUD) 264 as specified in [DISC, 7.3], and MUST send solicited neighbor adver- 265 tisements as specified in [DISC, 7.2.4]. 267 The link-layer address option used in [DISC] is not needed. Link- 268 layer address options SHOULD NOT be sent in any Neighbor Discovery 269 packets, and MUST be silently ignored in any received Neighbor Dis- 270 covery packets. 272 5.2. Router and Prefix Discovery 274 Since the site's IPv4 infrastructure is treated as an NBMA link 275 layer, unsolicited Router Advertisements do not provide sufficient 276 means for router discovery on ISATAP links. Thus, alternate mecha- 277 nisms are required and specified below: 279 5.2.1. Conceptual Data Structures 281 ISATAP nodes use the conceptual data structures Prefix List and 282 Default Router List exactly as specified in [DISC,5.1]. ISATAP links 283 add a new conceptual data structure "Potential Router List" and the 284 following new configuration variable: 286 ResolveInterval Time between name service resolutions. 287 Default and suggested minimum: 1hr 289 A Potential Router List (PRL) is associated with every ISATAP link. 290 The PRL provides context for router discovery and a trust basis for 291 router validation (see security considerations). Each entry in the 292 PRL has an IPv4 address and an associated timer used for polling. The 293 IPv4 address represents a router's ISATAP interface (likely to be an 294 "advertising interface"), and is used to construct the ISATAP link- 295 local address for that interface. 297 When a node enables an ISATAP link, it initializes the Potential 298 Router List (PRL) for that link. Unless other information is avail- 299 able (e.g., manual address configuration, a vendor-specific DHCP 300 option, etc.) the following method (similar to the [SIP, 1.4.2] pro- 301 cedure) SHOULD be used: 303 1. The site administrator maintains address records for ISATAP 304 router interfaces, and makes these available in the site's 305 name service. Nodes attempt to find one or more addresses 306 for the PRL by querying the name service. 308 2. There are no mandatory rules on the selection of domain name 309 to be used within a site for this purpose, but administrators 310 are encouraged to use the "isatap.domainname" convention 311 (e.g., isatap.example.com), as specified in [RFC2219]. Nodes 312 can construct this domain name by prepending the label "isatap" 313 to their parent domain name, which is established by other 314 means. Nodes then query this domain name for address records 315 (e.g., DNS 'A' resource records), and initialize the PRL with 316 the IPv4 addresses in the replies. 318 3. After initialization, nodes periodically repeat the above 319 procedure ResolveInterval to update the PRL with any IPv4 320 addresses added/deleted since the previous iteration. When 321 DNS is used, nodes MUST follow the procedures in [RFC1035] 322 regarding cache invalidation when the DNS time-to-live expires. 324 5.2.2. Validation of Router Advertisement Messages 326 A node MUST silently discard any received Router Advertisement mes- 327 sages that do not satisfy the validity checks in [DISC,6.1.2] as well 328 as the following additional validity check for ISATAP: 330 - the network-layer (IPv6) source address is derived from 331 an IPv4 address in the PRL 333 5.2.3. Router Specification 335 Advertising ISATAP interfaces of routers behave the same as advertis- 336 ing interfaces described in [DISC,6.2]. However, periodic unsolicited 337 multicast Router Advertisements are not required, thus the "interval 338 timer" associated with advertising interfaces is not used for that 339 purpose. 341 When an ISATAP router receives a valid Router Solicitation on an 342 advertising ISATAP interface, it replies with a unicast Router Adver- 343 tisement to the address of the node which sent the Router Solicita- 344 tion. The source address of the Router Advertisement is a link-local 345 unicast address associated with the interface. This MAY be the same 346 as the destination address of the Router Solicitation. ISATAP routers 347 MAY engage in the polling process described under Host Specification 348 below (e.g. if Router Advertisement consistency verification 349 [DISC,6.2.7] is desired), but this is not required. 351 5.2.4. Host Specification 353 Hosts periodically poll one or more entries in the PRL ("PRL(i)") by 354 sending unicast Router Solicitation messages using the IPv4 address 355 ("V4ADDR_PRL(i)") and associated timer in the entry. Hosts add the 356 following variable to support the polling process: 358 MinRouterSolicitInterval 359 Minimum time between sending Router Solicitations 360 to any router. Default and suggested minimum: 15min 362 When a PRL(i) is selected for polling, the host sets its associated 363 timer to MinRouterSolicitInterval and initiates polling following a 364 short delay as for initial solicitations [ND,6.3.7]), and when the 365 associated timer expires. 367 Polling consists of sending Router Solicitations to the ISATAP link- 368 local address constructed from the entry's IPv4 address, i.e., they 369 are sent to 'FE80::0:5EFE:V4ADDR_PRL(i)' instead of 'All-Routers mul- 370 ticast'. They are otherwise sent in the same manner described in 371 [DISC,6.3.7]. 373 When the host receives a valid Router Advertisement (i.e., one that 374 satisfies the validity checks in sections 4.5 and 5.2.2) it is pro- 375 cesses in the same manner described in [DISC,6.3.4]. The host addi- 376 tionally resets the timer associated with the V4ADDR_PRL(i) embedded 377 in the network-layer source address in the Router Advertisement. The 378 timer is reset to either 0.5 * (the minimum value in the router life- 379 time or valid lifetime of any on-link prefixes advertised) or Min- 380 RouterSolicitInterval; whichever is longer. 382 6. ISATAP Deployment Considerations 384 6.1. Host And Router Deployment Considerations 386 For hosts, if an underlying link supports both IPv4 (over which ISA- 387 TAP is implemented) and also supports IPv6 natively, then ISATAP MAY 388 be enabled if the native IPv6 layer does not receive Router Adver- 389 tisements (i.e., does not have connection with an IPv6 router). After 390 a non-link-local address has been configured and a default router 391 acquired on the native link, the host SHOULD discontinue the 'Router 392 Polling Process' process specified in section 5.2.4 and allow exist- 393 ing ISATAP address configurations to expire as specified in 394 [DISC,5.3][AUTO,5.5.4]. Any ISATAP addresses added to the DNS for 395 this host should also be removed. In this way, ISATAP use will gradu- 396 ally diminish as IPv6 routers are widely deployed throughout the 397 site. 399 Routers MAY configure an interface to simultaneously support both 400 native IPv6, and also ISATAP (over IPv4). Routing will operate as 401 usual between these two domains. Note that the prefixes used on the 402 ISATAP and native IPv6 interfaces will be distinct. The IPv4 403 address(es) configured on a router's ISATAP interface(s) SHOULD be 404 added (either automatically or manually) to the site's address 405 records for ISATAP router interfaces (see section 5.2.1). 407 6.2. Site Administration Considerations 409 The following considerations are noted for sites that deploy ISATAP: 411 - ISATAP links are administratively defined by a set of router 412 interfaces, and set of nodes which have those interface addresses 413 in their potential router lists. Thus, ISATAP links are defined by 414 administrative (not physical) boundaries. 416 - ISATAP hosts and routers can be deployed in an ad-hoc and independent 417 fashion. In particular, ISATAP hosts can be deployed with little/no 418 advanced knowledge of existing ISATAP routers, and ISATAP routers 419 can deployed with no reconfiguration requirements for hosts. 421 - ISATAP nodes periodically send Router Solicitations to all entries 422 in the Potential Router List. Worst-case control traffic is on the 423 order of (M x N), where 'M' is the number of routers in the Potential 424 Router List and 'N' is the total number of nodes on the ISATAP link. 425 The MinRouterSolicitInterval ([5.2.4]) bounds control traffic for 426 large numbers of nodes even in worst-case scenarios. 428 - ISATAP nodes periodically refresh the entries on the PRL, typically 429 by polling the DNS. Responsible site administration can reduce the 430 control traffic. At a minimum, administrators SHOULD ensure that 431 the site's address records for ISATAP router interfaces (see 432 section 5.2.1) are well maintained. 434 7. IANA considerations 436 Appendix B offers one possible specification for managing the IEEE 437 OUI assigned to IANA for EUI-64 interface identifier construction. 438 This specification is made freely available to IANA for any purpose 439 they may find useful. 441 8. Security considerations 443 Site administrators are advised that, in addition to possible attacks 444 against IPv6, security attacks against IPv4 MUST also be considered. 445 Many security considerations in [6OVER4,9] apply also to ISATAP. 447 Responsible IPv4 site security management is strongly encouraged. In 448 particular, border gateways SHOULD implement filtering to detect 449 spoofed IPv4 source addresses at a minimum; ip-protocol-41 filtering 450 SHOULD also be implemented. 452 If IPv4 source address filtering is not correctly implemented, the 453 validity checks in section 4.7 will not be effective in preventing 454 IPv6 source address spoofing. 456 If filtering for ip-protocol-41 is not correctly implemented, IPv6 457 source address spoofing is clearly possible, but this can be elimi- 458 nated if both IPv4 source address filtering, and the validity checks 459 in section 4.7 are implemented. 461 [DISC,6.1.2] implies that nodes trust Router Advertisements they 462 receive from on-link routers, as indicated by a value of 255 in the 463 IPv6 'hop-limit' field. Since this field is not decremented when ip- 464 protocol-41 packets traverse multiple IPv4 hops [MECH,3.3], ISATAP 465 links require a different trust model. In particular, ONLY those 466 Router Advertisements received from a member of the Potential Routers 467 List are trusted; all others are silently discarded (see section 468 5.2.2). This trust model is predicated on IPv4 source address filter- 469 ing, as described above. 471 The ISATAP address format does not support privacy extensions for 472 stateless address autoconfiguration [PRIVACY]. However, since the 473 ISATAP interface identifier is derived from the node's IPv4 address, 474 ISATAP addresses do not have the same level of privacy concerns as 475 IPv6 addresses that use an interface identifier derived from the MAC 476 address. 478 Acknowledgements 480 Some of the ideas presented in this draft were derived from work at 481 SRI with internal funds and contractual support. Government sponsors 482 who supported the work include Monica Farah-Stapleton and Russell 483 Langan from U.S. Army CECOM ASEO, and Dr. Allen Moshfegh from U.S. 484 Office of Naval Research. Within SRI, Dr. Mike Frankel, J. Peter Mar- 485 cotullio, Lou Rodriguez, and Dr. Ambatipudi Sastry supported the work 486 and helped foster early interest. 488 The following peer reviewers are acknowledged for taking the time to 489 review a pre-release of this document and provide input: Jim Bound, 490 Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, Ole 491 Troan, Vlad Yasevich. 493 The authors acknowledge members of the NGTRANS community who have 494 made significant contributions to this effort, including Rich Draves, 495 Alain Durand, Nathan Lutchansky, Art Shelest, Margaret Wasserman, and 496 Brian Zill. 498 The authors wish to acknowledge the work of Quang Nguyen [VET] under 499 the guidance of Dr. Lixia Zhang that proposed very similar ideas to 500 those that appear in this document. This work was first brought to 501 the authors' attention on September 20, 2002. 503 Finally, the authors recognize that ideas similar to those in this 504 document may have already been presented by others and wish to 505 acknowledge any other such contributions. 507 Normative References 509 [ADDR] Hinden, R., and S. Deering, "IP Version 6 Addressing 510 Architecture", RFC 2373, July 1998. (Pending approval 511 of "addr-arch-v3"). 513 [AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6 514 Aggregatable Global Unicast Address Format", 515 RFC 2374, July 1998. 517 [AUTO] Thomson, S., and T. Narten, "IPv6 Stateless Address 518 Autoconfiguration", RFC 2462, December 1998. 520 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 521 Discovery for IP Version 6 (IPv6)", RFC 2461, 522 December 1998. 524 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 525 Registration Authority", 526 http://standards.ieee.org/regauth/oui/tutori- 527 als/EUI64.html, 528 March 1997. 530 [ICMPv6] Conta, A. and S. Deering, "Internet Control Message 531 Protocol (ICMPv6) for the Internet Protocol Version 6 532 (IPv6) Specification", RFC 2463, December 1998. 534 [IPV4] Postel, J., "Internet Protocol", RFC 791. 536 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 537 (IPv6) Specification", RFC 2460. 539 [MECH] Gilligan, R., and E. Nordmark, "Transition Mechanisms for 540 IPv6 Hosts and Routers", RFC 2893, August 2000. 542 [NAT] Egevang, K., and P. Francis, "The IP Network Address 543 Translator (NAT)", RFC 1631, May 1994. 545 [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 546 and E. Lear, "Address Allocation for Private Internets", 547 RFC 1918, February 1996. 549 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and 550 J. Rosenberg, "SIP: Session Initiation Protocol", 551 RFC 2543, March 1999. 553 Informative References 555 [6OVER4] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 556 Domains without Explicit Tunnels", RFC 2529. 558 [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains 559 via IPv4 Clouds", RFC 3056, February 2001. 561 [IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 562 USC/Information Sciences Institute, October 1994. 564 [PRIVACY] Narten, T., R. Draves, "Privacy Extensions for Stateless 565 Address Autoconfiguration in IPv6", RFC 3041, 566 January 2001. 568 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 569 Specification", RFC 1035, November 1987. 571 [RFC2219] Hamilton, M., and R. Wright, "Use of DNS Aliases for 572 Network Services", RFC 2219 (BCP), October 1997. 574 [VET] Nguyen, Quang, "Virtual Ethernet: A New Approach to 575 IPv6 Transition", http://irl.cs.ucla.edu/vet/report.ps, 576 MS Project Report, Spring 1998. 578 Authors Addresses 580 Fred L. Templin 581 Nokia 582 313 Fairchild Drive 583 Mountain View, CA, USA 584 Phone: (650)-625-2331 585 Email: ftemplin@iprg.nokia.com 587 Tim Gleeson 588 Cisco Systems K.K. 589 Shinjuku Mitsu Building 590 2-1-1 Nishishinjuku, Shinjuku-ku 591 Tokyo 163-0409, JAPAN 592 email: tgleeson@cisco.com 594 Mohit Talwar 595 Microsoft Corporation 596 One Microsoft Way 597 Redmond, WA 98052-6399 598 Phone: +1 425 705 3131 599 EMail: mohitt@microsoft.com 601 Dave Thaler 602 Microsoft Corporation 603 One Microsoft Way 604 Redmond, WA 98052-6399 605 Phone: +1 425 703 8835 606 EMail: dthaler@microsoft.com 608 APPENDIX A: Major Changes 610 changes from version 05 to version 06: 612 - Addressed operational issues identified in 05 based on 613 discussion between co-authors 615 - Clarified ambiguous text per comments from Hannu Flinck; 616 Jason Goldschmidt 618 changes from version 04 to version 05: 620 - Moved historical text in section 4.1 to Appendix B in 621 response to comments from Pekka Savola 623 - Identified operational issues for anticipated deployment 624 scenarios 626 - Included SRI IPR statement and contact information 628 - Included reference to Quang Nguyen work 630 changes from version 03 to version 04: 632 - Re-wrote section on Potential Router List initialization to 633 reference existing precedence in other documents 635 - several minor wording changes based on feedback from the 636 community 638 changes from version 02 to version 03: 640 - Added contributing co-authors 642 - RSs are now sent to unicast addresses rather than all-routers-multicast 643 - Brought draft into better alignment with other IPv6 644 standards-track documents 646 - Added applicability statement 648 changes from version 01 to version 02: 650 - Cleaned up text and tightened up terminology. Changed "IPv6 destination 651 address" to "IPv6 next-hop address" under "sending rules". Changed 652 definition of ISATAP prefix to include link and site-local. Changed 653 language in sections 4 and 5 655 changes from version 00 to version 01: 657 - Revised draft to require different /64 prefixes for ISATAP 658 addresses and native IPv6 addresses. Thus, a node's ISATAP 659 interface is assigned a /64 prefix that is distinct from the 660 prefixes assigned to any other interfaces attached to the 661 node - be they physical or logical interfaces. This approach 662 eliminates ISATAP-specific sending rules presented in earlier 663 draft versions. 665 - Changed sense of 'u/l' bit in the ISATAP address interface 666 identifier to indicate "local scope", since ISATAP interface 667 identifiers are unique only within the scope of the ISATAP 668 prefix. (See section 4.) 670 changes from personal draft to version 00: 672 - Title change to provide higher-level description of field of 673 use addressed by this draft. Removed other extraneous text. 675 - Major new section on automatic discovery of off-link IPv6 routers 676 when IPv6-IPv4 compatibility addresses are used. 678 APPENDIX B: Rationale for Interface Identifier Construction Rules 680 ISATAP specifies an [EUI64]-format address construction for the Orga- 681 nizationally-Unique Identifier (OUI) owned by the Internet Assigned 682 Numbers Authority [IANA]. This format (given below) is used to con- 683 struct both native [EUI64] addresses for general use and modified 684 EUI-64 format interface identifiers for use in IPv6 unicast 685 addresses: 687 |0 2|2 3|3 3|4 6| 688 |0 3|4 1|2 9|0 3| 689 +------------------------+--------+--------+------------------------+ 690 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 691 +------------------------+--------+--------+------------------------+ 693 Where the fields are: 695 OUI IANA's OUI: 00-00-5E with 'u' and 'g' bits (3 octets) 697 TYPE Type field; specifies interpretation of (TSE, TSD) (1 octet) 699 TSE Type-Specific Extension (1 octet) 701 TSD Type-Specific Data (3 octets) 703 And the following interpretations are specified based on TYPE: 705 TYPE (TSE, TSD) Interpretation 706 ---- ------------------------- 707 0x00-0xFD RESERVED for future IANA use 708 0xFE (TSE, TSD) together contain an embedded IPv4 address 709 0xFF TSD is interpreted based on TSE as follows: 711 TSE TSD Interpretation 712 --- ------------------ 713 0x00-0xFD RESERVED for future IANA use 714 0xFE TSD contains 24-bit EUI-48 intf id 715 0xFF RESERVED by IEEE/RAC 717 Thus, if TYPE=0xFE, TSE is an extension of TSD. If TYPE=0xFF, TSE is 718 an extension of TYPE. Other values for TYPE (hence, other interpreta- 719 tions of TSE, TSD) are reserved for future IANA use. 721 The above specification is compatible with all aspects of [EUI64], 722 including support for encapsulating legacy EUI-48 interface identi- 723 fiers (e.g., an IANA EUI-48 format multicast address such as: 724 '01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03'). 725 But, the specification also provides a special TYPE (0xFE) to indi- 726 cate an IPv4 address is embedded. Thus, when the first four octets of 727 a [ADDR]-compatible IPv6 interface identifier are: '00-00-5E-FE' 728 (note: the 'u/l' bit MUST be 0) the interface identifier is said to 729 be in "ISATAP format" and the next four octets embed an IPv4 address 730 encoded in network byte order. 732 INTELLECTUAL PROPERTY 734 SRI International has notified the IETF of IPR considerations for 735 some aspects of this specification. For more information consult the 736 online list of claimed rights.