idnits 2.17.1 draft-ietf-ngtrans-isatap-16.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 15, 2003) is 7496 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) == Unused Reference: 'RFC2827' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 616, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-addr-arch-v4-00 -- Possible downref: Normative reference to a draft: ref. 'ICMPV6' == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-00 -- Possible downref: Normative reference to a draft: ref. 'MIB' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft Nokia 4 Expires: April 14, 2004 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 October 15, 2003 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-16.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 14, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document specifies an Intra-Site Automatic Tunnel Addressing 43 Protocol (ISATAP) that connects IPv6 hosts and routers within IPv4 44 sites. ISATAP treats the site's IPv4 unicast infrastructure as a 45 Non-Broadcast, Multiple Access (NBMA) link layer for IPv6 with no 46 requirement for IPv4 multicast. ISATAP enables automatic IPv6-in-IPv4 47 tunneling whether globally assigned or private IPv4 addresses are 48 used. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Basic IPv6 Operation . . . . . . . . . . . . . . . . . . . . . 4 56 5. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 6 57 6. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 8 58 7. Address Autoconfiguration . . . . . . . . . . . . . . . . . . 12 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 60 9. Security considerations . . . . . . . . . . . . . . . . . . . 12 61 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 62 Normative References . . . . . . . . . . . . . . . . . . . . . 13 63 Informative References . . . . . . . . . . . . . . . . . . . . 14 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 65 A. Major Changes . . . . . . . . . . . . . . . . . . . . . . . . 15 66 B. Interface Identifier Construction . . . . . . . . . . . . . . 16 67 Intellectual Property and Copyright Statements . . . . . . . . 18 69 1. Introduction 71 This document specifies a simple mechanism called the Intra-Site 72 Automatic Tunnel Addressing Protocol (ISATAP) that enables 73 incremental deployment of IPv6 [RFC2460] within IPv4 [RFC0791] sites. 74 ISATAP allows dual-stack nodes that do not share a link with an IPv6 75 router to automatically tunnel packets to the IPv6 next-hop address 76 through IPv4, i.e., the site's IPv4 infrastructure is treated as a 77 link layer for IPv6. 79 The main objectives of this document are to: 1) specify operational 80 details for automatic tunneling of IPv6 over IPv4 using ISATAP, 2) 81 specify the format of IPv6 interface identifiers using an embedded 82 IPv4 address, 3) specify the operation of Neighbor Discovery and 83 Address Autoconfiguration, and 4) discuss security considerations. 85 The specification in this document is very similar to [RFC2529], with 86 the primary distinction that ISATAP does not require IPv4 multicast 87 support within the site. 89 2. Requirements 91 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 92 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 93 document, are to be interpreted as described in [RFC2119]. 95 This document also makes use of internal conceptual variables to 96 describe protocol behavior and external variables that an 97 implementation must allow system administrators to change. The 98 specific variable names, how their values change, and how their 99 settings influence protocol behavior are provided to demonstrate 100 protocol behavior. An implementation is not required to have them in 101 the exact form described here, so long as its external behavior is 102 consistent with that described in this document. 104 3. Terminology 106 The terminology of [RFC2460][RFC2461][RFC2462] applies to this 107 document. The following additional terms are defined: 109 site: 110 same as defined in [RFC3582], which is intended to be equivalent 111 to "enterprise" as defined in [RFC1918]. 113 ISATAP interface: 114 an interface used for automatic IPv6-in-IPv4 tunneling and 115 configured over one or more IPv4 addresses assigned to one or more 116 of the node's IPv4 interfaces that belong to the same site. 118 advertising ISATAP interface: 119 same meaning as advertising interface in ([RFC2461], section 120 6.2.2). 122 ISATAP address: 123 an address with an on-link prefix assigned on an ISATAP interface 124 and with an interface identifier constructed as specified in 125 Section 4.1. 127 4. Basic IPv6 Operation 129 ISATAP interfaces automatically tunnel IPv6 packets in IPv4 using the 130 site's IPv4 infrastructure as a link layer, i.e., IPv6 treats the 131 site's IPv4 infrastructure as a Non-Broadcast, Multiple Access (NBMA) 132 link layer with properties similar to [RFC2491]. The following 133 sections specify details for basic IPv6 operation on ISATAP 134 interfaces: 136 4.1 Interface Identifiers and Unicast Addresses 138 Interface identifiers for ISATAP are constructed in Modified EUI-64 139 format as specified in ([ADDR-ARCH], section 2.5.1). They are formed 140 by appending a 32-bit IPv4 address to the 32-bit leading token 141 '0000:5EFE', then setting the universal/local ("u") bit as follows: 143 When the IPv4 address is globally unique (i.e., provider-assigned), 144 the "u" bit is set to 1 and the leading token becomes '0200:5EFE'. 145 When the IPv4 address is from a private allocation [RFC1918], the "u" 146 bit is set to 0 and the leading token remains as '0000:5EFE'. 148 Global and link-local IPv6 unicast addresses ([ADDR-ARCH], sections 149 2.5.4, 2.5.6) for ISATAP are constructed as follows: 151 | 64 bits | 32 bits | 32 bits | 152 +------------------------------+---------------+----------------+ 153 | global/link-local prefix | 000[0/2]:5EFE | IPv4 Address | 154 +------------------------------+---------------+----------------+ 156 (Appendix B provides additional non-normative details.) 158 4.2 ISATAP Interface Management 160 The IP Tunnel MIB [MIB] is used, with the following additions for 161 ISATAP interfaces: 163 o For each IPv4 address an ISATAP interface is configured over, a 164 tuple consisting of the IPv4 address and ifIndex for the 165 corresponding IPv4 interface ([RFC2863], section 3.1.5) is added 166 to ifRcvAddressTable ([MIB], section 3.1.2). 168 o tunnelIfRemoteInetAddress in the tunnelIfEntry object ([MIB], 169 section 4) is set to 0.0.0.0 for ISATAP interfaces. 171 When an IPv4 address over which an ISATAP interface is configured is 172 removed from its IPv4 interface, the corresponding (IPv4 addres, 173 ifIndex)-tuple MUST be removed from the ISATAP interface 174 ifRcvAddressTable. If the IPv4 address is also used as 175 tunnelIfLocalInetAddress ([MIB], section 5) in the ISATAP interface 176 tunnelIfEntry, the interface MUST either set tunnelIfLocalInetAddress 177 to a different IPv4 address or be disabled. 179 When a new IPv4 address is added to an IPv4 interface an ISATAP 180 interface is configured over, a new (IPv4 address, ifIndex)-tuple MAY 181 be added to ifRcvAddressTable and tunnelIfLocalInetAddress MAY be set 182 to the new address. 184 4.3 Multicast and Anycast 186 ISATAP interfaces recognize an IPv6 node's required addresses 187 ([ADDR-ARCH], section 2.8). The following multicast mappings are 188 defined for packets sent on ISATAP interfaces: 190 o When the IPv6 destination address is the 'All-Routers' 191 ([ADDR-ARCH], section 2.7.1) or 192 'All_DHCP_Relay_Agents_and_Servers' ([RFC3315], section 1.2) 193 multicast address, it is mapped to V4ADDR(i) for one or more 194 PRL(i)'s (see: Section 6.1). The manner of selecting PRL(i)'s is 195 up to the implementation. 197 Other multicast mappings, and mechanisms for general-purpose 198 multicast/anycast emulation on ISATAP interfaces are beyond the scope 199 of this document. 201 4.4 Source/Target Link Layer Address Options 203 Source/Target Link Layer Address Options ([RFC2461], section 4.6.1) 204 for ISATAP have the following format: 206 +-------+-------+-------+-------+-------+-------+-------+--------+ 207 | Type |Length | 0 | 0 | IPv4 Address | 208 +-------+-------+-------+-------+-------+-------+-------+--------+ 210 Type: 211 1 for Source Link-layer address. 212 2 for Target Link-layer address. 214 Length: 215 1 (in units of 8 octets). 217 IPv4 Address: 218 The 32 bit IPv4 address, in network byte order. 220 5. Automatic Tunneling 222 ISATAP interfaces use the basic transition mechanisms specified in 223 [MECH] with the following exceptions: 225 5.1 Tunnel MTU and Fragmentation 227 The specification in ([MECH], section 3.2) is not used; the 228 specification in this section is used instead. 230 The minimum MTU for IPv6 interfaces is 1280 bytes ([RFC2460], Section 231 5), but the following operational considerations are noted: 233 o Nearly all IPv4 nodes connect to physical links with MTUs of 1500 234 bytes or larger (e.g., Ethernet) 236 o Sub-IPv4 layer encapsulations (e.g., VPN) may occur on some paths 238 o Commonly-deployed VPN interfaces use an MTU of 1400 bytes 240 To maximize efficiency and minimize IPv4 fragmentation for the 241 predominant deployment case, LinkMTU for ISATAP interfaces SHOULD be 242 set to no more than 1380 bytes (1400 minus 20 bytes for IPv4 243 encapsulation). 245 LinkMTU MAY be set to larger values when a dynamic link layer (IPv4) 246 MTU discovery mechanism is used, or when a static MTU assignment is 247 used and the anticipated/measured level of fragmentation in the 248 site's IPv4 network is deemed acceptable. 250 When a dynamic link layer MTU discovery mechanism is not used, the 251 Don't Fragment (DF) bit MUST NOT be set in the encapsulating IPv4 252 header of packets sent on the ISATAP interface. In this case, black 253 holes may in rare instances occur along some paths even when the 254 tunnel interface uses the IPv6 minimum MTU of 1280 bytes. (This 255 concern is not specific to ISATAP interfaces, but applies to all 256 tunnels for which nested levels of sub link-layer encapsulation may 257 occur.) 259 5.2 Handling IPv4 ICMP Errors 261 ARP failures and persistent ICMPv4 errors SHOULD be processed as 262 link-specific information indicating that a path to a neighbor has 263 failed ([RFC2461], section 7.3.3). 265 5.3 Link-Local Addresses 267 The specification in ([MECH], section 3.7) is not used; the 268 specification in Section 4.1 of this document is used instead. 270 5.4 Neighbor Discovery over Tunnels 272 The specification in ([MECH], section 3.8) is not used; the 273 specifications in Section 6 and Section 7 of this document are used 274 instead. 276 5.5 Decapsulation/Filtering 278 The specifications in ([MECH], sections 3.6, 3.9 and 4.1) are used. 280 In addition, the decapsulator MUST determine the correct tunnel 281 interface to receive each IPv4 protocol-41 packet via a table lookup 282 for the tuple consisting of the packet's IPv4 source and destination 283 address, and ifIndex for the receiving IPv4 interface. (Note that 284 ISATAP interfaces match all IPv4 source addresses by default; if a 285 tunnel interface with a more-specific match on the IPv4 source 286 address exists, it is selected to receive the packet as for 287 longest-prefix-match.) Packets for which the correct tunnel interface 288 cannot be determined are discarded; in this case, the decapsulator 289 MAY also send an ICMPv4 Destination Unreachable message with code 3 290 (Port Unreachable) ([RFC1122], section 3.2.2.1) to the IPv4 source 291 address in the packet's outer header. 293 After determining the correct tunnel interface, the decapsulator MUST 294 also verify that the packet's link-layer (IPv4) source address is 295 correct for the network-layer (IPv6) source address. For ISATAP 296 interfaces, the packet's link-layer source address is correct if one 297 (or more) of the following are true: 299 o the network-layer source address is an ISATAP address that embeds 300 the link-layer source address in its interface identifier. 302 o the network-layer source address is an IPv6 neighbor within the 303 same site as the receiving ISATAP interface, and the link-layer 304 source address matches the link layer address in the neighbor 305 cache. 307 o the link-layer source address is a member of the Potential Router 308 List for the site (see: Section 6.1). 310 Packets for which the link-layer source address is incorrect are 311 discarded, and an ICMPv6 Destination Unreachable message ([ICMPV6], 312 section 3.1) SHOULD be sent to the IPv6 source in the inner header of 313 the encapsulated packet (subject to rate limiting as in [ICMPV6], 314 section 2.4, paragraph f). 316 6. Neighbor Discovery 318 ISATAP interfaces use the neighbor discovery mechanisms specified in 319 [RFC2461] with the following exceptions: 321 6.1 Conceptual Model Of A Host 323 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 324 ISATAP interfaces add: 326 Potential Router List 327 A set of entries about potential routers for the site; used to 328 support the mechanisms specified in Section 6.2.3. Each entry 329 ("PRL(i)") has an associated timer ("TIMER(i)"), and an IPv4 330 address ("V4ADDR(i)") that represents a router's advertising 331 ISATAP interface. 333 6.2 Router and Prefix Discovery 335 6.2.1 Message Validation 337 6.2.1.1 Validation of Router Solicitation Messages 339 To the list of validity checks for Router Soliciation messages 340 ([RFC2461], section 6.1.1), ISATAP interfaces add: 342 o If the message includes a Source Link Layer Address Option, the 343 message also includes an IP authentication Header. 345 6.2.1.2 Validation of Router Advertisement Messages 347 To the list of validity checks for Router Advertisement messages 348 ([RFC2461], section 6.1.1), ISATAP interfaces add: 350 o IP Source Address is an ISATAP link-local address that embeds 351 V4ADDR(i) for some PRL(i). 353 o If the message includes a Source Link Layer Address Option, the 354 message also includes an IP authentication Header. 356 6.2.2 Router Specification 358 As permitted by ([RFC2461], section 6.2.6), advertising ISATAP 359 interfaces SHOULD unicast Router Advertisement messages to the 360 soliciting host's address when the solicitation's source address is 361 not the unspecified address. 363 6.2.3 Host Specification 365 6.2.3.1 Host Variables 367 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 368 interfaces add: 370 PrlRefreshInterval 371 Time in seconds between successive refreshments of the PRL after 372 initialization. It SHOULD be no less than 3600 seconds. The 373 designated value of all 1's (0xffffffff) represents infinity. 375 Default: 3600 seconds 377 MinRouterSolicitInterval 378 Minimum time in seconds between successive solicitations of the 379 same advertising ISATAP interface. It SHOULD be no less than 900 380 seconds. The designated value of alll 1's (0xffffffff) represents 381 infinity. 383 Default: 900 seconds 385 6.2.3.2 Interface Initialization 387 The host joins the all-nodes multicast address on ISATAP interfaces, 388 as for multicast-capable interfaces ([RFC2461], section 6.3.3). 390 Additionally, the host provisions the ISATAP interface's PRL with 391 IPv4 addresses it discovers via manual configuration, a DNS 392 fully-qualified domain name (FQDN) [RFC1035], a DHCPv4 option for 393 ISATAP [ISDHCP], a DHCPv4 vendor-specific option, or an unspecified 394 alternate method. (Support for manual configuration is REQUIRED; 395 other methods are OPTIONAL.) 396 When FQDNs are used, the host establishes the FQDN via manual 397 configuration or an unspecified alternate method. (Support for manual 398 configuration is REQUIRED; other methods are OPTIONAL.) The host 399 resolves the FQDN into IPv4 addresses through lookup in a static host 400 file, a site-specific name service, querying the site's DNS service, 401 or an unspecified alternate method. When DNS is used, client 402 resolvers use the IPv4 transport. 404 After the host provisions the ISATAP interface's PRL with IPv4 405 addresses, it sets PrlRefreshIntervalTimer to PrlRefreshInterval 406 seconds. The host re-initializes the PRL (i.e., as specified above) 407 when PrlRefreshIntervalTimer expires, or when an asynchronous 408 re-initialization event occurs. When the host re-initializes the PRL, 409 it resets PrlRefreshIntervalTimer to PrlRefreshInterval seconds. 411 6.2.3.3 Processing Received Router Advertisements 413 Router Advertisements (RAs) are processed exactly as specified in 414 ([RFC2461], section 6.3.4) except that, if the MTU option is present, 415 the option's value SHOULD be stored in a per-neighbor cache entry for 416 the source of the RA; it MUST NOT be copied into LinkMTU for the 417 ISATAP interface. 419 Additionally, hosts reset TIMER(i) to schedule the next solicitation 420 event (see: Section 6.2.3.4). Let "MIN_LIFETIME" be the minimum value 421 in the Router Lifetime or the lifetime(s) encoded in options included 422 in the RA message. Then, TIMER(i) is reset as follows: 424 TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) 426 6.2.3.4 Sending Router Solicitations 428 To the list of events after which RSs may be sent ([RFC2461], section 429 6.3.2), ISATAP interfaces add: 431 o TIMER(i) for some PRL(i) expires. 433 Additionally, hosts MAY send Router Solicitations to an ISATAP 434 link-local address that embeds V4ADDR(i) for some PRL(i) instead of 435 the All-Routers multicast address. 437 6.3 Address Resolution and Neighbor Unreachability Detection 439 6.3.1 Message Validation 440 6.3.1.1 Validation of Neighbor Solicitations 442 To the list of validity checks for Neighbor Solicitation (NS) 443 messages ([RFC2461], section 7.1.1), ISATAP interfaces add: 445 o If the message includes a Source Link Layer Address Option, the 446 message also includes an IP authentication Header. 448 6.3.1.2 Validation of Neighbor Solicitations 450 To the list of validity checks for Neighbor Advertisement (NA) 451 messages ([RFC2461], section 7.1.2), ISATAP interfaces add: 453 o If the message includes a Target Link Layer Address Option, the 454 message also includes an IP authentication Header. 456 6.3.2 Address Resolution 458 The specification in ([RFC2461], section 7.2) is used. NS and NA 459 messages MAY omit the source/target link layer address option when 460 the source/target is an ISATAP address. ISATAP addresses for which 461 the neighbor's link-layer address cannot otherwise be determined 462 (i.e., from the neighbor cache or a link layer address option in a 463 received packet) are resolved to link-layer addresses by a static 464 computation, i.e., the last four octets are treated as an IPv4 465 address. 467 Hosts SHOULD perform an initial reachability confirmation by sending 468 NS message(s) and receiving a NA message; NS messages are sent to the 469 target's unicast address. Routers MAY perform an initial reachability 470 confirmation, but this might not scale in all environments. 472 As specified in ([RFC2461], section 7.2.4), all nodes MUST send 473 solicited neighbor advertisements on ISATAP interfaces. 475 6.3.3 Neighbor Unreachability Detection 477 Hosts SHOULD perform Neighbor Unreachability Detection as specified 478 in ([RFC2461], section 7.3). Routers MAY perform neighbor 479 unreachability detection, but this might not scale in all 480 environments. 482 6.4 Redirect Function 484 To the list of validity checks for Redirect messages (([RFC2461], 485 section 8.1), ISATAP interfaces add: 487 o If the message includes a Target Link Layer Address Option, the 488 message also includes an IP authentication Header. 490 7. Address Autoconfiguration 492 ISATAP interfaces use the address autoconfiguration mechanisms 493 specified in [RFC2462] with the following exceptions: 495 7.1 Address Lifetime Expiry 497 The specification in ([RFC2462], section 5.5.4) is used, except that 498 an ISATAP address also becomes deprecated when the IPv4 address 499 embedded in its interface identifier is removed from an IPv4 500 interface over which the ISATAP interface is configured. (This 501 deprecation rule applies to all ISATAP addresses, including 502 link-local addresses.) 504 7.2 Stateful Address Autoconfiguration 506 When the site uses DHCPv6 [RFC3315] as the stateful address 507 autoconfiguration mechanism, the server/relay function MUST be 508 deployed equally on each router that is a member of the PRL. 510 8. IANA Considerations 512 The IANA is advised to specify construction rules for IEEE EUI-64 513 addresses formed from the Organizationally Unique Identifier (OUI) 514 "00-00-5E" in the IANA "ethernet-numbers" registry. The non-normative 515 text in Appendix B is offered as an example specification. 517 9. Security considerations 519 The security considerations in [RFC2461][RFC2462][MECH] apply. 521 Additionally, site administrators MUST ensure that lists of IPv4 522 addresses representing the advertising ISATAP interfaces of PRL 523 members are well maintained. 525 10. Acknowledgments 527 Most of the basic ideas in this document are not original; the 528 authors acknowledge the original architects of those ideas. Portions 529 of this work were sponsored through SRI International internal 530 projects and government contracts. Government sponsors include Monica 531 Farah-Stapleton and Russell Langan (U.S. Army CECOM ASEO), and Dr. 532 Allen Moshfegh (U.S. Office of Naval Research). SRI International 533 sponsors include Dr. Mike Frankel, J. Peter Marcotullio, Lou 534 Rodriguez, and Dr. Ambatipudi Sastry. 536 The following are acknowledged for providing peer review input: Jim 537 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 538 Ole Troan, Vlad Yasevich. 540 The following are acknowledged for their significant contributions: 541 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 542 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka 543 Savola, Margaret Wasserman, Brian Zill. 545 The authors acknowledge the work of Quang Nguyen [VET] under the 546 guidance of Dr. Lixia Zhang that proposed very similar ideas to those 547 that appear in this document. This work was first brought to the 548 authors' attention on September 20, 2002. 550 Normative References 552 [ADDR-ARCH] 553 Hinden, R. and S. Deering, "IP Version 6 Addressing 554 Architecture", draft-ietf-ipv6-addr-arch-v4-00 (work in 555 progress), October 2003. 557 [ICMPV6] Conta, A. and S. Deering, "Internet Control Message 558 Protocol (ICMPv6) for the Internet Protocol Version 6 559 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3 (work in 560 progress), November 2001. 562 [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms 563 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-00 564 (work in progress), February 2003. 566 [MIB] Thaler, D., "IP Tunnel MIB", draft-thaler-inet-tunnel-mib 567 (work in progress), September 2003. 569 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 570 1981. 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 576 (IPv6) Specification", RFC 2460, December 1998. 578 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 579 Discovery for IP Version 6 (IPv6)", RFC 2461, December 580 1998. 582 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 583 Autoconfiguration", RFC 2462, December 1998. 585 Informative References 587 [ISDHCP] Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 588 Option for the Intra-Site Automatic Tunnel Addressing 589 Protocol (ISATAP)", draft-templin-isatap-dhcp (work in 590 progress), October 2003. 592 [RFC1035] Mockapetris, P., "Domain names - implementation and 593 specification", STD 13, RFC 1035, November 1987. 595 [RFC1122] Braden, R., "Requirements for Internet Hosts - 596 Communication Layers", STD 3, RFC 1122, October 1989. 598 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 599 E. Lear, "Address Allocation for Private Internets", BCP 600 5, RFC 1918, February 1996. 602 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 603 over Non-Broadcast Multiple Access (NBMA) networks", RFC 604 2491, January 1999. 606 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 607 Domains without Explicit Tunnels", RFC 2529, March 1999. 609 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 610 Defeating Denial of Service Attacks which employ IP Source 611 Address Spoofing", BCP 38, RFC 2827, May 2000. 613 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 614 MIB", RFC 2863, June 2000. 616 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 617 Stateless Address Autoconfiguration in IPv6", RFC 3041, 618 January 2001. 620 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 621 M. Carney, "Dynamic Host Configuration Protocol for IPv6 622 (DHCPv6)", RFC 3315, July 2003. 624 [RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 625 Site-Multihoming Architectures", RFC 3582, August 2003. 627 [VET] Nguyen, Q., "http://irl.cs.ucla.edu/vet/report.ps", spring 628 1998. 630 Authors' Addresses 632 Fred L. Templin 633 Nokia 634 313 Fairchild Drive 635 Mountain View, CA 94110 636 US 638 Phone: +1 650 625 2331 639 EMail: ftemplin@iprg.nokia.com 641 Tim Gleeson 642 Cisco Systems K.K. 643 Shinjuku Mitsu Building 644 2-1-1 Nishishinjuku, Shinjuku-ku 645 Tokyo 163-0409 646 Japan 648 EMail: tgleeson@cisco.com 650 Mohit Talwar 651 Microsoft Corporation 652 One Microsoft Way 653 Redmond, WA> 98052-6399 654 US 656 Phone: +1 425 705 3131 657 EMail: mohitt@microsoft.com 659 Dave Thaler 660 Microsoft Corporation 661 One Microsoft Way 662 Redmond, WA 98052-6399 663 US 665 Phone: +1 425 703 8835 666 EMail: dthaler@microsoft.com 668 Appendix A. Major Changes 670 Major changes from earlier versions to version 16: 672 o dropped "underlying link" from terminology. 674 o specified multicast mappings. 676 o specified layer address option format. 678 o specified setting of "u" bit in interface id's. 680 o removed obsoleted appendix sections. 682 o re-organized major sections to match normative references. 684 o revised neighbor discovery, address autoconfiguration, security 685 considerations sections. Added new subsections on interface 686 management, decapsulation/filtering, address lifetime expiry. 688 Appendix B. Interface Identifier Construction 690 This section provides an example specification for constructing EUI64 691 addresses from the Organizationally-Unique Identifier (OUI) owned by 692 the Internet Assigned Numbers Authority (IANA). It can be used to 693 construct both modified EUI-64 format interface identifiers for IPv6 694 unicast addresses ([ADDR-ARCH], section 2.5.1) and "native" EUI64 695 addresses for future use: 697 |0 2|2 3|3 3|4 6| 698 |0 3|4 1|2 9|0 3| 699 +------------------------+--------+--------+------------------------+ 700 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 701 +------------------------+--------+--------+------------------------+ 703 Where the fields are: 705 OUI IANA's OUI: 00-00-5E with "u" and "g" bits (3 octets) 707 TYPE Type field; specifies use of (TSE, TSD) (1 octet) 709 TSE Type-Specific Extension (1 octet) 711 TSD Type-Specific Data (3 octets) 713 And the following interpretations are specified based on TYPE: 715 TYPE (TSE, TSD) Interpretation 716 ---- ------------------------- 717 0x00-0xFD RESERVED for future IANA use 718 0xFE (TSE, TSD) together contain an IPv4 address 719 0xFF TSD is interpreted based on TSE as follows: 721 TSE TSD Interpretation 722 --- ------------------ 723 0x00-0xFD RESERVED for future IANA use 724 0xFE TSD contains 24-bit EUI-48 intf id 725 0xFF RESERVED by IEEE/RAC 727 Using this example specification, if TYPE=0xFE, then TSE is an 728 extension of TSD. If TYPE=0xFF, then TSE is an extension of TYPE. 729 (Other values for TYPE, and other interpretations of TSE, TSD are 730 reserved for future IANA use.) When TYPE='0xFE' the EUI64 address 731 embeds an IPv4 address, encoded in network byte order. 733 For Modified EUI64 format interface identifiers in IPv6 unicast 734 addresses ([ADDR-ARCH], Appendix A) using IANA's OUI, when TYPE=0xFE 735 and the IPv4 address is a globally unique (i.e., provider-assigned) 736 unicast address, the "u" bit is set to 1 to indicate universal scope. 737 When TYPE=0xFE and the IPv4 address is from a private allocation, the 738 "u" bit is set to 0 to indicate local scope. Thus, when the first 739 four octets of the interface identifier in an IPv6 unicast address 740 are either: '02-00-5E-FE' or: '00-00-5E-FE', the next four octets 741 embed an IPv4 address and the interface identifier is said to be in 742 "ISATAP format". 744 Intellectual Property Statement 746 The IETF takes no position regarding the validity or scope of any 747 intellectual property or other rights that might be claimed to 748 pertain to the implementation or use of the technology described in 749 this document or the extent to which any license under such rights 750 might or might not be available; neither does it represent that it 751 has made any effort to identify any such rights. Information on the 752 IETF's procedures with respect to rights in standards-track and 753 standards-related documentation can be found in BCP-11. Copies of 754 claims of rights made available for publication and any assurances of 755 licenses to be made available, or the result of an attempt made to 756 obtain a general license or permission for the use of such 757 proprietary rights by implementors or users of this specification can 758 be obtained from the IETF Secretariat. 760 The IETF invites any interested party to bring to its attention any 761 copyrights, patents or patent applications, or other proprietary 762 rights which may cover technology that may be required to practice 763 this standard. Please address the information to the IETF Executive 764 Director. 766 The IETF has been notified of intellectual property rights claimed in 767 regard to some or all of the specification contained in this 768 document. For more information consult the online list of claimed 769 rights. 771 Full Copyright Statement 773 Copyright (C) The Internet Society (2003). All Rights Reserved. 775 This document and translations of it may be copied and furnished to 776 others, and derivative works that comment on or otherwise explain it 777 or assist in its implementation may be prepared, copied, published 778 and distributed, in whole or in part, without restriction of any 779 kind, provided that the above copyright notice and this paragraph are 780 included on all such copies and derivative works. However, this 781 document itself may not be modified in any way, such as by removing 782 the copyright notice or references to the Internet Society or other 783 Internet organizations, except as needed for the purpose of 784 developing Internet standards in which case the procedures for 785 copyrights defined in the Internet Standards process must be 786 followed, or as required to translate it into languages other than 787 English. 789 The limited permissions granted above are perpetual and will not be 790 revoked by the Internet Society or its successors or assignees. 792 This document and the information contained herein is provided on an 793 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 794 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 795 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 796 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 797 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 799 Acknowledgment 801 Funding for the RFC Editor function is currently provided by the 802 Internet Society.