idnits 2.17.1 draft-ietf-ngtrans-isatap-18.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 == Line 655 has weird spacing: '...fied in secti...' == 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 (February 4, 2004) is 7386 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: 'BCP0014' is mentioned on line 105, but not defined == Unused Reference: 'RFC2119' is defined on line 1100, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 3424 ** Downref: Normative reference to an Informational RFC: RFC 3542 ** Downref: Normative reference to an Informational RFC: RFC 3582 ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational draft: draft-rfc-editor-rfc2223bis (ref. 'AUTH') ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-isatap (ref. 'ISATAP') ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-mdns (ref. 'LLMNR') ** Downref: Normative reference to an Informational draft: draft-ietf-ipv6-node-requirements (ref. 'NODEREQ') -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Duplicate reference: draft-ietf-ipv6-rfc2012-update, mentioned in 'UDPMIB', was also mentioned in 'TCPMIB'. Summary: 14 errors (**), 0 flaws (~~), 6 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: August 4, 2004 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 February 4, 2004 11 Internet/Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-18.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 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 August 4, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 The Internet/Site Automatic Tunnel Addressing Protocol (ISATAP) 43 connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 44 network as a link layer for IPv6 and views other nodes on the network 45 as potential IPv6 hosts/routers. ISATAP supports automatic tunneling 46 and a tunnel interface management abstraction similar to the Non- 47 Broadcast, Multiple Access (NBMA) and ATM Permanent/Switched Virtual 48 Circuit (PVC/SVC) models. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. ISATAP Conceptual Model . . . . . . . . . . . . . . . . . . . 4 56 5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Addressing Requirements . . . . . . . . . . . . . . . . . . . 5 58 7. Configuration and Management Requirements . . . . . . . . . . 6 59 8. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 10 60 9. Neighbor Discovery for ISATAP Interfaces . . . . . . . . . . . 15 61 10. Other Requirements for Control Plane Signaling . . . . . . . . 18 62 11. Security considerations . . . . . . . . . . . . . . . . . . . 18 63 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 64 13. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 19 65 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 66 A. Major Changes . . . . . . . . . . . . . . . . . . . . . . . . 21 67 B. Example ISATAP Driver API . . . . . . . . . . . . . . . . . . 21 68 C. The IPv6 Minimum MTU . . . . . . . . . . . . . . . . . . . . . 24 69 D. Modified EUI-64 Addresses in the IANA Ethernet Address Block . 24 70 E. Proposed ICMPv6 Code Field Types . . . . . . . . . . . . . . . 25 71 Normative References . . . . . . . . . . . . . . . . . . . . . 25 72 Informative References . . . . . . . . . . . . . . . . . . . . 27 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 74 Intellectual Property and Copyright Statements . . . . . . . . 30 76 1. Introduction 78 This document specifies a simple mechanism called the Internet/Site 79 Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 80 [RFC2460] hosts/routers over IPv4 [STD0005] networks. Dual-stack 81 (IPv6/IPv4) nodes use ISATAP to automatically tunnel IPv6 packets in 82 IPv4, i.e., ISATAP views the IPv4 network as a link layer for IPv6 83 and views other nodes on the network as potential IPv6 hosts/routers. 85 ISATAP enables automatic tunneling whether global or private IPv4 86 addresses are used, and supports a tunnel interface management 87 abstraction similar to the Non-Broadcast, Multiple Access (NBMA) 88 [RFC2491] and ATM Permanent/Switched Virtual Circuit (PVC/SVC) 89 [RFC2492] models. 91 The main objectives of this document are to: 1) describe the ISATAP 92 conceptual model, 2) specify addressing requirements, 3) discuss 93 configuration and management requirements, 4) specify automatic 94 tunneling using ISATAP, 5) specify operational aspects of IPv6 95 Neighbor Discovery, and 6) discuss IANA and Security considerations. 97 This document surveys all IETF v6ops WG documents current up to 98 February 4, 2004. 100 2. Requirements 102 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 103 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 104 document, are to be interpreted as described in [BCP0014]. 106 3. Terminology 108 The terminology of [STD0003][RFC2460][RFC2461][RFC3582] applies to 109 this document. The following additional terms are defined: 111 ISATAP node: 112 a node that implements the specifications in this document. 114 ISATAP daemon: 115 an ISATAP node's server application that uses an ISATAP driver API 116 for control plane signaling and tunnel interface 117 configuration/management. 119 ISATAP driver: 120 an ISATAP node's network driver module that provides an API for 121 control plane signaling and tunnel interface configuration/ 122 management. Also provides an engine for tunneled packet 123 encapsulation, decapsulation and forwarding. 125 logical interface: 126 an IPv6 address or a configured tunnel interface associated with 127 an ISATAP interface. 129 ISATAP interface: 130 an ISATAP node's point-to-multipoint IPv6 interface for automatic 131 IPv6-in-IPv4 tunneling. Provides a control plane interface for the 132 ISATAP daemon and a user plane nexus for its associated logical 133 interfaces. 135 ISATAP interface identifier: 136 an IPv6 interface identifier with an embedded IPv4 address 137 constructed as specified in section 6.1. 139 ISATAP address: 140 an IPv6 unicast address assigned on an ISATAP interface with an 141 on-link prefix and an ISATAP interface identifier. 143 locator: 144 an IPv4 address-to-interface mapping, i.e., a node's IPv4 address 145 and the index for it's associated interface. 147 locator set: 148 a set of locators associated with a tunnel interface, where each 149 locator in the set belongs to the same site. 151 4. ISATAP Conceptual Model 153 ISATAP nodes typically act as a host on some interfaces and as a 154 router on other interfaces; the distinction between host and router 155 is made per advertising interface. 157 ISATAP interfaces provide a point-to-multipoint abstraction for 158 IPv6-in-IPv4 tunneling. They provide a user plane nexus for tunneling 159 packets on behalf of their associated logical interfaces. They also 160 provide a control plane interface for tunnel configuration signaling 161 between the ISATAP daemon and prospective peers (e.g., via IPv6 162 Neighbor Discovery messages, DNS queries, etc.). 164 The ISATAP driver sends tunneled packets via the node's IPv4 stack 165 according to the sending interface's encapsulation parameters. It 166 also determines the correct interface to receive each tunneled packet 167 after decapsulation via a forwarding table lookup. 169 The ISATAP daemon configures and manages tunnels via an ISATAP driver 170 API. Each such configured tunnel provides a nexus for multiple 171 applications using IPv6 addresses as application identifiers. Each 172 such application identifier provides a nexus for multiple sessions. 173 In summary, each configured tunnel provides a point-to-point 174 connection between peers that can support multiple applications and 175 multiple instances of each application. 177 5. Node Requirements 179 ISATAP nodes implement the common functionality required by [NODEREQ] 180 as well as the additional features specified in this document. 182 6. Addressing Requirements 184 6.1 ISATAP Interface Identifiers 186 ISATAP interface identifiers are constructed in Modified EUI-64 187 format ([ADDR], appendix A). They are formed by concatenating the 188 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 189 32-bit IPv4 address in network byte order ([AUTH], section 3.4). 191 The format for ISATAP interface identifiers is given below (where 'u' 192 is the IEEE univeral/local bit, 'g' is the IEEE group/individual bit, 193 and the 'm' bits represent the concatenated IPv4 address): 195 |0 1|1 3|3 4|4 6| 196 |0 5|6 1|2 7|8 3| 197 +----------------+----------------+----------------+----------------+ 198 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 199 +----------------+----------------+----------------+----------------+ 201 When the IPv4 address is known to be globally unique, the 'u' bit is 202 set to 1; otherwise, the 'u' bit is set to 0 ([ADDR], section 2.5.1). 203 See: Appendix D for additional non-normative details. 205 6.2 ISATAP Addresses 207 Any IPv6 unicast address ([ADDR], section 2.5) that contains an 208 ISATAP interface identifier constructed as specified in section 6.1 209 and an on-link prefix on an ISATAP interface is considered an ISATAP 210 address. 212 6.3 Multicast/Anycast 214 ISATAP interfaces recognize a node's required IPv6 multicast/anycast 215 addresses ([ADDR], section 2.8). 217 For IPv6 multicast addresses of interest to local applications, 218 ISATAP nodes join the corresponding Organization-Local Scope IPv4 219 multicast groups ([RFC2529], section 6) on each interface that 220 appears in an ISATAP interface's locator set (see: section 7.2). 222 IPv6 multicast addresses of interest include a node's required 223 multicast addresses, the 'All_DHCP_Relay_Agents_and_Servers' and 224 'All_DHCP_Servers' multicast addresses (i.e., if the node is 225 configured as a DHCPv6 server [RFC3315][RFC3633]), multicast 226 addresses discovered via MLD [RFC2710], etc. 228 Considerations for IPv6 anycast appear in [ANYCAST]. 230 6.4 Source/Target Link Layer Address Options 232 Source/Target Link Layer Address Options ([RFC2461], section 4.6.1) 233 for ISATAP have the following format: 235 +-------+-------+-------+-------+-------+-------+-------+--------+ 236 | Type |Length | 0 | 0 | IPv4 Address | 237 +-------+-------+-------+-------+-------+-------+-------+--------+ 239 Type: 240 1 for Source Link-layer address. 2 for Target Link-layer address. 242 Length: 243 1 (in units of 8 octets). 245 IPv4 Address: 246 A 32 bit IPv4 address, in network byte order ([AUTH], section 247 3.4). 249 ISATAP nodes use the specifications in ([MECH], section 3.8) that 250 pertain to sending and receiving Source/Target Link Layer Address 251 Options. 253 7. Configuration and Management Requirements 255 7.1 Network Management 257 ISATAP nodes MAY support network management; those that do SHOULD 258 support the following MIBs: [FTMIB][IPMIB][TUNMIB][TCPMIB][UDPMIB]. 260 This document defines no new MIB tables, nor extensions to any 261 existing MIB tables. Objects found in the MIBs listed above are 262 supported as described in the following subsections. 264 7.2 The ifRcvAddressTable 266 The ISATAP driver maintains ifRcvAddressTable as a bidirectional 267 association of locators with tunnel interfaces. Each locator in the 268 table includes a preferred IPv4 address-to-interface mapping (i.e., a 269 preferred IPv4 ipAddressEntry in the node's ipAddressTable) and a 270 list of associated tunnel interfaces. Each tunnel interface in the 271 table has a tunnelIfEntry and a list of associated locators, i.e., a 272 "locator set". 274 The ISATAP driver implements the following conceptual functions to 275 manage and search the ifRcvAddressTable: 277 7.2.1 RcvTableAdd(locator, tunnel_interface) 279 Creates a bidirectional association in the ifRcvAddressTable between 280 the locator and tunnel interface, i.e., adds the locator to the 281 tunnel interface's locator set and adds the tunnel interface to the 282 locator's association list. 284 Returns success or failure. 286 7.2.2 RcvTableDel(locator, tunnel_interface) 288 Deletes ifRcvAddressTable entries according to the locator and tunnel 289 interface calling arguments as follows: 291 - if both arguments are NULL, garbage-collects the entire table. 293 - if both arguments are non-NULL, deletes the locator from the 294 tunnel interface's locator set and deletes the tunnel interface 295 from the locator's association list. 297 - if the locator is non-NULL and tunnel interface is NULL, deletes 298 the locator from the locator sets of all tunnel interfaces. 300 - if the locator is NULL and the tunnel interface is non-NULL, 301 deletes the tunnel interface from the association lists of all 302 locators. 304 Returns success or failure. 306 7.2.3 RcvTableLocate(packet) 308 Searches the ifRcvAddressTable to locate the correct tunnel interface 309 to decapsulate a packet. First, determines the locator that matches 310 the packet's IPv4 destination address and ifIndex for the interface 311 the packet arrived on. Next, checks each tunnel interface in the 312 locator's association list for an exact match of tunnelIfEncapsMethod 313 with the packet's encapsulation type and an exact match of 314 tunnelIfRemoteInetAddress with the packet's IPv4 source address. 316 If there is no match on the packet's IPv4 source address, a tunnel 317 interface with a matching tunnelIfEncapsMethod and with 318 tunnelIfRemoteInetAddress set to 0.0.0.0 is selected. If there are 319 multiple matches, a tunnel interface with tunnelIfLocalInetAddress 320 that matches the packet's IPv4 destination address is preferred. 322 Returns a pointer to a tunnel interface if a match is found; else 323 NULL. 325 7.3 ISATAP Driver API 327 The ISATAP driver implements an API for calling processes, e.g., 328 ISATAP daemons, startup scripts, manual command line entry, kernel 329 processes, etc. Access MUST be restricted to privileged users and 330 applications. The API provides primitives for sending/receiving 331 control plane messages as well as creating, deleting, modifying, and 332 otherwise managing tunnel interfaces. An example (i.e., non- 333 normative) API is given in Appendix B. 335 7.4 ISATAP Interface Creation/Configuration 337 ISATAP interfaces are created via the tunnelIfConfigTable, which 338 results in simultaneous creation of a tunnelIfEntry and a companion 339 ipv6InterfaceEntry. Each ISATAP interface configures a locator set, 340 where each locator in the set represents an IPv4 address-to- 341 interface mapping for the same site (or, represents a mapping that is 342 routable on the global Internet). An ISATAP interface MUST NOT 343 configure a locator set that spans multiple sites. 345 ISATAP interfaces configure the following objects in tunnelIfEntry: 347 - tunnelIfEncapsMethod is set to an IANATunnelType for "isatap". 349 - tunnelIfLocalInetAddress is set to an IPv4 address from the 350 interface's locator set. 352 - tunnelIfRemoteInetAddress is set to 0.0.0.0 to denote wildcard 353 match for remote tunnel endpoints. 355 - other read-write objects in the tunnelIfEntry are configured as 356 for any tunnel interface. 358 ISATAP interfaces also configure the following objects in 359 ipv6InterfaceEntry: 361 - ipv6InterfaceType is set to "tunnel". 363 - ipv6InterfacePhysicalAddress is set to an octet string of zero 364 length to indicate that this IPv6 interface does not have a 365 physical address. 367 - ipv6InterfaceForwarding and, if necessary, ip6Forwarding for the 368 node are set to "forwarding". 370 - other read-write objects in ipv6InterfaceEntry are configured as 371 for any IPv6 interface. 373 Finally, an ipv6RouterAdvertEntry for the ISATAP interface is created 374 in ipv6RouterAdvertTable and its ipv6RouterAdvertIfIndex object is 375 set to the same value as ipv6InterfaceIfIndex. Other objects in 376 ipv6RouterAdvertEntry are configured as for any IPv6 router. 378 7.5 Dynamic Creation of Configured Tunnels 380 Configured tunnels are normally created by the ISATAP daemon in 381 dynamic response to a tunnel creation request. Configured tunnel 382 interfaces are configured as for ISATAP interfaces (see: section 383 7.4), except that tunnelIfRemoteInetAddress is normally set to a 384 specific IPv4 address for a remote node at the far end of the tunnel, 385 i.e., configured tunnels are normally configured as point-to-point. 386 Also, tunnelIfEncapsMethod for the new entry is set to an 387 IANATunnelType appropriate for the method of encapsulation. 389 Configured tunnels MAY be "bound" to an ISATAP interface such that 390 they inherit the ISATAP interface's locator set, e.g., for ease of 391 management and to avoid misconfigurations. 393 Configured tunnels MAY also be created as independent entities and 394 configure their own locator set, but (as for ISATAP interfaces) they 395 MUST NOT configure a locator set that spans multiple sites. 397 7.6 Reconfigurations Due to IPv4 Address Changes 399 When a locator becomes deprecated (e.g., when an IPv4 address is 400 removed from an IPv4 interface) the locator SHOULD be removed from 401 all tunnel interface associations via RcvTableDel(locator, NULL). 402 Also, all tunnel interfaces that used the deprecated IPv4 address as 403 tunnelIfLocalInetAddress SHOULD configure a different local IPv4 404 address from their remaining locator set. 406 When a new IPv4 address is added to an IPv4 interface, the node MAY 407 add the corresponding new locator to the locator set for one or more 408 tunnel interfaces via RcvTableAdd(locator, tunnel_interface), and MAY 409 set tunnelIfLocalInetAddress for tunnel interfaces referenced by the 410 updated forwarding entries to the new address. 412 Methods for triggering the above changes, and for communicating IPv4 413 address changes to remote nodes, are out of scope. 415 8. Automatic Tunneling 417 ISATAP nodes use the basic tunneling mechanisms specified in [MECH]. 418 The following additional specifications are also used: 420 8.1 Encapsulation 422 The ISATAP driver encapsulates IPv6 packets in IPv4 using various 423 encapsulation methods, including ip-protocol-41 (e.g., 6over4 424 [RFC2529], 6to4 [RFC3056], IPv6-in-IPv4 configured tunnels [MECH], 425 isatap, etc.), UDP [STD0006] port 3544, and others. 427 AH [RFC2402] and/or ESP [RFC2406] processing and header compression 428 for the packet's inner headers are performed prior to encapsulation. 430 8.1.1 NAT Traversal 432 Native IPv6 and/or ip-protocol-41 encapsulation provides sufficient 433 functionality to support peer-to-peer communications when both peers 434 reside within the same site (i.e., the same enterprise network). When 435 the remote peer resides within a different site, NAT traversal via 436 UDP/IPv4 encapsulation MAY be necessary. 438 When an ISATAP node determines that NAT traversal is necessary to 439 reach a particular peer, it encapsulates IPv6 packets using UDP/IPv4 440 encapsulation with a UDP destination port of 3544. This determination 441 may come through, e.g., first attempting communications via ip- 442 protocol-41 then failing over to UDP/IPv4 port 3544 encapsulation, 443 administrative knowledge that a NAT traversal will occur along the 444 path, etc. 446 When UDP/IPv4 port 3544 encapsulation is used, the specifications in 447 this document apply the same as for any form of encapsulation 448 supported by ISATAP. 450 8.1.2 Multicast 452 ISATAP interfaces encapsulate packets with IPv6 multicast destination 453 addresses using a mapped Organization-Local Scope IPv4 multicast 454 address ([RFC2529], section 6) as the destination address in the 455 encapsulating IPv4 header. 457 8.2 Tunnel MTU and Fragmentation 459 Encapsulated packets may incur host-based IPv4 fragmentation, e.g., 460 when the underlying physical link has a small IPv4 MTU [BCP0048]. In 461 such cases, host-based IPv4 fragmentation is required to satisfy the 462 1280 byte IPv6 minimum MTU, and is not considered harmful [FRAG]. On 463 the other hand, unmitigated IPv4 fragmentation caused by the network 464 can cause poor performance. For example, since the minimum IPv4 465 fragment size is only 8 bytes [STD0005], network middleboxes could 466 shred a 1280 byte tunneled packet into as many as 160 IPv4 fragments. 468 ISATAP uses the MTU and fragmentation specifications in ([MECH], 469 section 3.2) and the Maximum Reassembly Unit (MRU) specifications in 470 ([MECH], section 3.6), which provide sufficient measures for avoiding 471 excessive IPv4 fragmentation in certain controlled environments 472 (e.g., 3GPP operator networks, enterprise networks, etc). To minimize 473 IPv4 fragmentation and improve performance in general use case 474 scenarios, ISATAP nodes SHOULD add the following simple 475 instrumentation to the IPv4 reassembly cache: 477 When the initial fragment of an encapsulated packet arrives, the 478 packet's IPv4 reassembly timer is set to 1 second (i.e., the worst 479 case store-and-forward delay budget for a 1280 byte packet). If an 480 encapsulated packet's IPv4 reassembly timer expires: 482 - If enough contiguous leading bytes of the packet have arrived 483 (see: section 8.6), reassemble the packet from all fragments 484 received. (Otherwise, garbage-collect the reassembly buffer and 485 return from processing.) During reassembly, copy zero-filled or, 486 heuristically-chosen replacement data bytes in place of any 487 missing fragments. 489 - Mark the packet as "INCOMPLETE", and also mark it with a 490 "TOTAL_BYTES" length that encodes the total number of data bytes 491 in fragments that arrived. 493 - Deliver the packet to the ISATAP driver as though reassembly had 494 succeeded. 496 - Do not send an ICMPv4 "time exceeded" message [STD0005]. 498 Appendix C provides informative text on the derivation of the 1280 499 byte IPv6 minimum MTU. 501 8.3 Handling ICMPv4 Errors 503 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 504 errors as link-specific information indicating that a path to a 505 neighbor may have failed ([RFC2461], section 7.3.3). 507 8.4 Link-Local Addresses 509 ISATAP interfaces use link local addresses constructed as specified 510 in section 6.1 of this document. 512 8.5 Neighbor Discovery over Tunnels 514 The specification in ([MECH], section 3.8) is used; the additional 515 specification for neighbor discovery in section 9 of this document 516 are also used. 518 8.6 Decapsulation/Filtering 520 ISATAP nodes typically arrange for the ISATAP driver to receive all 521 IPv4-encapsulated IPv6 packets that are addressed to one of the 522 node's IPv4 addresses. Examples include ip-protocol-41 (e.g., 6to4, 523 6over4, configured tunnels, isatap, etc.), UDP/IPv4 port 3544, and 524 others. The ISATAP driver uses the decapsulation and filtering 525 specifications in ([MECH], section 3.6), and processes each packet 526 according to the following steps: 528 1. Locate the correct tunnel interface to receive the packet (see: 529 section 7.2.3). If not found, silently discard the packet and 530 return from processing. 532 2. If the tunnel uses header compression, reconstitute headers. If 533 header reconstitution fails, silently discard the packet and 534 return from processing. 536 3. Verify that the packet's IPv4 source address is correct for the 537 encapsulated IPv6 source address. For packets received on a 538 configured tunnel interface, verification is exactly as specified 539 in ([MECH], section 3.6). 541 For packets received on an ISATAP interface, the IPv4 source 542 address is correct if: 544 - the IPv6 source address is an ISATAP address that embeds the 545 IPv4 source address in its interface identifier, or: 547 - the IPv6 source address is the address of an IPv6 neighbor on 548 an ISATAP interface associated with the locator that matched 549 the packet (see: section 7.2.3), or: 551 - the IPv4 source address is a member of the Potential Router 552 List (see: section 9.1). 554 If the IPv4 source address is incorrect, silently discard the 555 packet and return from processing. 557 4. Perform IPv4 ingress filtering (optional; disabled by default) 558 then decapsulate the packet. If the IPv6 source address is 559 invalid (see: [MECH], section 3.6), silently discard the packet 560 and return from processing. 562 For UDP port 3544 packets received on an ISATAP interface, if the 563 IPv6 source address is an ISATAP link local address with the 'u' 564 bit set to 0 and an embedded IPv4 address that does not match the 565 IPv4 source address (see: section 6), rewrite the IPv6 source 566 address to inform upper layers of the sender's mapped UDP port 567 number and IPv4 source address. Specific rules for rewriting the 568 IPv6 source address are established during ISATAP interface 569 configuration. 571 Next, discard encapsulating headers and continue processing the 572 encapsulated IPv6 packet. 574 5. Perform ingress filtering on the IPv6 source address (see: 575 [MECH], section 3.6). Next, determine the correct transport 576 protocol listener [FLOW] if the packet is destined to the 577 localhost; otherwise, perform an IPv6 forwarding table lookup and 578 site border/firewall filtering (see: [UNIQUE], section 6). 580 If the packet cannot be delivered, the driver SHOULD send an 581 ICMPv6 Destination Unreachable message ([RFC2463], section 3.2) 582 to the packet's source. The message SHOULD select as its source 583 address an IPv6 address from the outgoing interface (if the 584 packet was destined to the localhost) or an ingress-wise correct 585 IPv6 address from the interface that would have forwarded the 586 packet had it not been filtered. 588 The Code field of the message is set as follows: 590 - if there is no route to the destination, the Code field is set 591 to 0 (see: [RFC2463], section 3.1). 593 - if communication with the destination is administratively 594 prohibited, the Code field is set to 1 ([RFC2463], section 595 3.1). 597 - if the packet is destined to the localhost, but the transport 598 protocol has no listener, the Code field is set to 4 599 ([RFC2463], section 3.1). 601 - if the packet's destination is beyond the scope of the source 602 address, the Code field is set to 2 (see: IANA 603 Considerations). 605 - if the packet was dropped due to ingress filtering policies, 606 the Code field is set to 5 (see: IANA Considerations). 608 - if the packet is dropped due to a reject route, the Code field 609 is set to 6 (see: IANA Considerations). 611 - if the packet was received on a point-to-point link and 612 destined to an address within a subnet assigned to that same 613 link, or if the reason for the failure to deliver cannot be 614 mapped to any of the specific conditions listed above, the 615 Code field is set to 3 ([RFC2463], section 3.2). 617 After sending the ICMPv6 Destination Unreachable message, discard 618 the packet and return from processing. 620 6. If the packet is "INCOMPLETE" (see section 8.2) send an 621 authenticated, unsolicited Router Advertisement message 622 ([RFC2461], section 6.2.4) to the packet's IPv6 source address 623 with an MTU option that encodes "TOTAL_BYTES". 625 7. If the packet was destined to a remote host, forward the packet 626 and return from processing. Otherwise, apply AH [RFC2402] or ESP 627 [RFC2406] processing (if necessary), and deliver the decapsulated 628 packet by placing it in a buffer for upper layers. The buffer may 629 be, e.g., the IPv6 reassembly cache, an application's mapped data 630 buffer [RFC3542], etc. 632 If there is clear evidence that upper layer reassembly has 633 stalled, an ICMPv6 Packet Too Big message [RFC1981] MAY be sent 634 to the packet's source address with an MTU value indicating a 635 size that is likely to incur successful reassembly. Some 636 applications may realize greater efficiency by accepting partial 637 information from "INCOMPLETE" packets (see: section 8.2) and 638 requesting selective retransmission of missing portions. 640 9. Neighbor Discovery for ISATAP Interfaces 642 ISATAP nodes use the neighbor discovery mechanisms specified in 643 [RFC2461] along with securing mechanisms (e.g., [SEND]) to create/ 644 change neighbor cache entries and to provide control plane signaling 645 for automatic tunnel configuration. ISATAP interfaces also implement 646 the following specifications: 648 9.1 Conceptual Model Of A Host 650 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 651 ISATAP interfaces add: 653 Potential Router List 654 A set of entries about potential routers; used to support the 655 mechanisms specified in section 9.2.2.1. Each entry ("PRL(i)") 656 has an associated timer ("TIMER(i)"), and an IPv4 address 657 ("V4ADDR(i)") that represents a router's advertising ISATAP 658 interface. 660 9.2 Router and Prefix Discovery 662 9.2.1 Router Specification 664 As permitted by ([RFC2461], section 6.2.6), the ISATAP daemon SHOULD 665 send unicast Router Advertisement messages to the soliciting node's 666 address when the solicitation's source address is not the unspecified 667 address. (Router Advertisements MAY include information delegated via 668 DHCPv6 [RFC3633]). 670 Routers MUST NOT send prefix options containing a preferred lifetime 671 greater than the valid lifetime. 673 9.2.2 Host Specification 675 9.2.2.1 Host Variables 677 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 678 interfaces add: 680 PrlRefreshInterval 681 Time in seconds between successive refreshments of the PRL after 682 initialization. It SHOULD be no less than 3600 seconds. The 683 designated value of all 1's (0xffffffff) represents infinity. 684 Default: 3600 seconds 686 MinRouterSolicitInterval 687 Minimum time in seconds between successive solicitations of the 688 same advertising ISATAP interface. The designated value of all 1's 689 (0xffffffff) represents infinity. 690 Default: 900 seconds 692 9.2.2.2 Potential Router List Initialization 694 ISATAP nodes provision an ISATAP interface's PRL with IPv4 addresses 695 discovered via manual configuration, a DNS fully-qualified domain 696 name (FQDN) [STD0013], a DHCPv4 option, a DHCPv4 vendor-specific 697 option, or an unspecified alternate method. 699 FQDNs are established via manual configuration or an unspecified 700 alternate method. FQDNs are resolved into IPv4 addresses through 701 lookup in a static host file, querying the DNS service, or an 702 unspecified alternate method. 704 When the node provisions an ISATAP interface's PRL with IPv4 705 addresses, it sets a timer for the interface (e.g., 706 PrlRefreshIntervalTimer) to PrlRefreshInterval seconds. The node re- 707 initializes the PRL as specified above when PrlRefreshIntervalTimer 708 expires, or when an asynchronous re-initialization event occurs. When 709 the node re-initializes the PRL, it resets PrlRefreshIntervalTimer to 710 PrlRefreshInterval seconds. 712 9.2.2.3 Processing Received Router Advertisements 714 The ISATAP daemon processes Router Advertisements (RAs) exactly as 715 specified in ([RFC2461], section 6.3.4). The DHCPv6 specification 716 [RFC3315] is the stateful mechanism associated with the M and O bits. 718 When the ISATAP daemon receives a Router Advertisement with an MTU 719 option from a router at the far end of a tunnel, it records the 720 advertised MTU value, e.g., in the node's IPv6 routing table. If the 721 MTU value is less than the MTU of the tunnel interface, the value is 722 recorded in such a way that the node will perform upper layer 723 fragmentation (i.e., above the IPv4 link layer) to reduce the size of 724 the IPv4 encapsulated packets it sends via the router. The recorded 725 value is aged as for IPv6 path MTU information [RFC1981]. 727 For Router Advertisement messages that include prefix options, Route 728 information options [DEFLT] and/or non-zero values in the Router 729 Lifetime, the ISATAP daemon resets TIMER(i) to schedule the next 730 solicitation event (see: section 9.2.2.4). Let "MIN_LIFETIME" be the 731 minimum value in the Router Lifetime or the lifetime(s) encoded in 732 options included in the RA message. Then, TIMER(i) is reset as 733 follows: 735 TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) 737 9.2.2.4 Sending Router Solicitations 739 To the list of events after which RSs may be sent ([RFC2461], section 740 6.3.2), ISATAP interfaces add: 742 - TIMER(i) for some PRL(i) expires. 744 Router Solicitations MAY be sent to an ISATAP link-local address that 745 embeds V4ADDR(i) for some PRL(i) instead of the All-Routers multicast 746 address. 748 9.3 Address Resolution and Neighbor Unreachability Detection 750 9.3.1 Address Resolution 752 The specification in ([RFC2461], section 7.2) is used. ISATAP 753 addresses for which the neighbor/router's link-layer address cannot 754 otherwise be determined (e.g., from a neighbor cache entry) are 755 resolved to link-layer addresses by a static computation, i.e., the 756 last four octets are treated as an IPv4 address. 758 Hosts SHOULD perform an initial reachability confirmation by sending 759 Neighbor Solicitation message(s) and receiving a Neighbor 760 Advertisement message (NS messages are sent to the target's unicast 761 address). Routers MAY perform this initial reachability confirmation, 762 but this might not scale in all environments. 764 All nodes MUST send solicited Neighbor Advertisements on ISATAP 765 interfaces ([RFC2461], section 7.2.4). 767 9.3.2 Neighbor Unreachability Detection 769 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 770 section 7.3). Routers MAY perform neighbor unreachability detection, 771 but this might not scale in all environments. 773 10. Other Requirements for Control Plane Signaling 775 10.1 Domain Name System (DNS) 777 The specifications in ([MECH], section 2.2) are used. Additional 778 considerations are found in [DNSOPV6]. 780 10.2 Linklocal Multicast Name Resolution (LLMNR) 782 ISATAP nodes SHOULD implement Link Local Multicast Name Resolution 783 [LLMNR], since they will commonly be deployed in environments (e.g., 784 home networks, ad-hoc networks, etc.) with no DNS service. 786 10.3 Node Information Queries 788 ISATAP nodes MAY implement Node Information Queries as specified in 789 [NIQUERY], since they may help the querier discover some subset of 790 the responder's addresses. 792 11. Security considerations 794 The security considerations in the normative references apply; also: 796 - site border routers SHOULD install a black hole route for the IPv6 797 prefix FC00::/7 to insure that packets with local IPv6 destination 798 addresses will not be forwarded outside of the site via a default 799 route. 801 - administrators MUST ensure that lists of IPv4 addresses 802 representing the advertising ISATAP interfaces of PRL members are 803 well maintained. 805 12. IANA Considerations 807 The IANA is instructed to specify the format for Modified EUI-64 808 address construction ([ADDR], Appendix A) in the IANA Ethernet 809 Address Block. The text in Appendix D of this document is offered as 810 an example specification. 811 The current version of the IANA registry for Ether Types can be 812 accessed at http://www.iana.org/assignments/ethernet-numbers. 814 The IANA is instructed to assign the new ICMPv6 code field types 815 found in Appendix E of this document for the ICMPv6 Destination 816 Unreachable message. The policy for assigning new ICMPv6 code field 817 types is First Come First Served, as defined in [RFC2434]. The 818 current version of the IANA registry for ICMPv6 type numbers can be 819 accessed at http://www.iana.org/assignments/icmpv6-parameters. 821 13. IAB Considerations 823 [RFC3424] ("IAB Considerations for UNilateral Self-Address Fixing 824 (UNSAF) Across Network Address Translation") section 4 requires that 825 any proposal supporting NAT traversal must explicitly address the 826 following considerations: 828 13.1 Problem Definition 830 The specific problem being solved is enabling IPv6 connectivity for 831 ISATAP nodes that are unable to communicate via ip-protocol-41 or 832 native IPv6. 834 13.2 Exit Strategy 836 ISATAP nodes use UDP/IPv4 encapsulation for NAT traversal as a last 837 resort. As soon as native IPv6 or ip-protocol-41 support becomes 838 available, ISATAP nodes will naturally cease using UDP/IPv4 839 encapsulation. 841 13.3 Brittleness 843 UDP/IPv4 encapsulation with ISATAP introduces brittleness into the 844 system in several ways: the discovery process assumes a certain 845 classification of devices based on their treatment of UDP; the 846 mappings need to be continuously refreshed, and addressing structure 847 may cause some hosts located beyond a common NAT to be unreachable 848 from each other. 850 ISATAP assumes a certain classification of devices based on their 851 treatment of UDP. There could be devices that would not fit into one 852 of these molds, and hence would be improperly classified by ISATAP. 854 The bindings allocated from the NAT need to be continuously 855 refreshed. Since the timeouts for these bindings is very 856 implementation specific, the refresh interval cannot easily be 857 determined. When the binding is not being actively used to receive 858 traffic, but to wait for an incoming message, the binding refresh 859 will needlessly consume network bandwidth. 861 13.4 Requirements for a Long Term Solution 863 The devices that implement the IPv4 NAT service should in the future 864 also become IPv6 routers. 866 14. Acknowledgments 868 The ideas in this document are not original, and the authors 869 acknowledge the original architects. Portions of this work were 870 sponsored through SRI International internal projects and government 871 contracts. Government sponsors include Monica Farah-Stapleton and 872 Russell Langan (U.S. Army CECOM ASEO), and Dr. Allen Moshfegh (U.S. 873 Office of Naval Research). SRI International sponsors include Dr. 874 Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi 875 Sastry. 877 The following are acknowledged for providing peer review input: Jim 878 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 879 Ole Troan, Vlad Yasevich. 881 The following are acknowledged for their significant contributions: 882 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 883 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka 884 Savola, Margaret Wasserman, Brian Zill. 886 The authors acknowledge the work of Quang Nguyen on "Virtual 887 Ethernet" under the guidance of Dr. Lixia Zhang that proposed very 888 similar ideas to those that appear in this document. This work was 889 first brought to the authors' attention on September 20, 2002. 891 IAB considerations are the same as for Teredo. 893 The following individuals are acknowledged for their helpful insights 894 on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound, 895 Ralph Droms, Alain Durand, Jun-ichiro itojun Hagino, Brian Haberman, 896 Bob Hinden, Christian Huitema, Kevin Lahey, Hakgoo Lee, Matt Mathis, 897 Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel, 898 Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave 899 Thaler, Michael Welzl, Lixia Zhang and the members of the Nokia NRC/ 900 COM Mountain View team. 902 "...and I'm one step ahead of the shoe shine, 903 Two steps away from the county line, 904 Just trying to keep my customers satisfied, 905 Satisfi-i-ied!" - Paul Simon, 1969 907 Appendix A. Major Changes 909 Major changes from earlier versions to version 17: 911 - changed first words in title from "Intra-site" to "Internet/site" 912 to more accurately represent the functionality. 914 - new section on configuration/management. 916 - new appendices on tunnel driver API; IANA considerations. 918 - expanded section on MTU and fragmentation. 920 - expanded sections on encapsulation/decapsulation. 922 - specified relation to IPv6 Node Requirements. 924 - introduced distinction between control; user planes. 926 - specified multicast mappings. 928 - revised neighbor discovery, address autoconfiguration, IANA 929 considerations and security considerations sections. 931 Appendix B. Example ISATAP Driver API 933 An ISATAP driver API should include primitives for sending and 934 receiving control plane messages as well as primitives for tunnel 935 configuration/management such as the following non-normative 936 examples: 938 B.1 ISATAP_SEND, ISATAP_RECEIVE Primitives 940 Description: 941 Sends/Receives control plane messages via the 942 ISATAP driver (e.g., via a routing socket, etc.) 944 B.2 ISATAP_CREATE Primitive 946 Description: 947 Creates a new tunnel interface and an associated IP 948 interface by creating a row in tunnelIfConfigTable. 949 Also optionally configures read-write objects for the 950 tunnel interface and adds locators to the receive address 951 table via RcvTableAdd(locator, tunnel_interface). 952 Required parameter: 953 - tunnelIfEncapsMethod. 954 Optional parameters: 955 - attributes for configuring read-write objects. 956 - list of locators to associate with tunnel interface. 957 Returns: 958 - ifIndex for the new tunnel interface, or a failure code. 960 B.3 ISATAP_DELETE Primitive 962 Description: 963 Deletes an existing tunnel interface by deleting the 964 corresponding row in tunnelIfConfigTable. Also frees 965 its locators via RcvTableDel(NULL, tunnel_interface). 966 Required parameter: 967 - ifIndex. 968 Returns: 969 - success or a failure code. 971 B.4 ISATAP_CONFIG Primitive 973 Description: 974 Configures attributes for an existing tunnel interface. 975 Also adds new locators via RcvTableAdd(locator, 976 tunnel_interface) and deletes old locators via 977 RcvTableDel(locator, tunnel_interface). 978 Required parameter: 979 - ifIndex. 980 Optional parameters: 981 - read-write objects for the tunnel interface. 982 - list of locators to associate with tunnel interface. 983 - list of locators to delete from association. 984 Returns: 985 - success or a failure code. 987 B.5 ISATAP_BIND Primitive 989 Description: 990 Binds (or, creates then binds) a configured tunnel interface 991 to an ISATAP interface. The configured tunnel interface 992 inherits the ISATAP interface's locator set and the ISATAP 993 interface uses the encapsulation parameters associated with 994 the bound configured tunnel interface. 995 Required parameter: 996 - ifIndex for the ISATAP interface. 997 - ifIndex for the configured tunnel interface, or NULL. 998 Conditional parameter: 999 - if ifIndex for the configured tunnel is NULL, 1000 tunnelIfEncapsMethod. 1001 Optional parameters: 1002 - attributes for configuring read-write objects for the 1003 configured tunnel interface. 1004 Returns: 1005 - ifIndex for the configured tunnel, or a failure code. 1007 B.6 ISATAP_GET Primitive 1009 Description: 1010 Copies configuration attributes from system table entries 1011 associated with the specified tunnel interface into a 1012 calling process' buffer. 1013 Required parameter: 1014 - ifIndex 1015 - address of a buffer in calling process's memory. 1016 - number of bytes available in the user's buffer. 1017 Returns: 1018 - Number of bytes written into the calling process' 1019 buffer, or a failure code. 1021 Appendix C. The IPv6 minimum MTU 1023 The 1280 byte IPv6 minimum MTU was proposed by Steve Deering and 1024 agreed through working group consensus in November 1997 discussions 1025 on the IPv6 mailing list. The size was chosen to allow extra room for 1026 link layer encapsulations without exceeding the Ethernet MTU of 1500 1027 bytes, i.e., the practical physical cell size of the Internet. The 1028 1280 byte MTU also provides a fixed upper bound for the size of IPv6 1029 packets/fragments with a maximum store-and-forward delay budget of ~1 1030 second assuming worst-case link speeds of ~10Kbps [BCP0048], thus 1031 providing a convenient value for use in reassembly buffer timer 1032 settings. Finally, the 1280 byte MTU allows transport connections 1033 (e.g., TCP) to configure a large-enough maximum segment size for 1034 improved performance even if the IPv4 interface that will send the 1035 tunneled packets uses a smaller MTU. 1037 Appendix D. Modified EUI-64 Addresses in the IANA Ethernet Address Block 1039 Modified EUI-64 addresses ([ADDR], Appendix A) in the IANA Ethernet 1040 Address Block are formed as the concatenation of the 24-bit IANA OUI 1041 (00-00-5E) with a 40-bit extension identifier. They have the 1042 following appearance in memory (bits transmitted right-to-left within 1043 octets, octets transmitted left-to-right): 1045 0 23 63 1046 | OUI | extension identifier | 1047 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 1049 When the first two octets of the extension identifier encode the 1050 hexadecimal value 0xFFFE, the remainder of the extension identifier 1051 encodes a 24-bit vendor-supplied id as follows: 1053 0 23 39 63 1054 | OUI | 0xFFFE | vendor-supplied id | 1055 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx 1056 When the first octet of the extension identifier encodes the 1057 hexadecimal value 0xFE, the remainder of the extension identifier 1058 encodes a 32-bit IPv4 address, as specified in ([ISATAP], section 1059 6.1) and as follows: 1061 0 23 31 63 1062 | OUI | 0xFE | IPv4 address | 1063 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 1065 Modified EUI-64 format interface identifiers are formed by inverting 1066 the "u" bit, i.e., the "u" bit is set to one (1) to indicate 1067 universal scope and it is set to zero (0) to indicate local scope 1068 ([ADDR], section 2.5.1). 1070 Appendix E. Proposed ICMPv6 Code Field Types 1072 Three new ICMPv6 Code Field Type definitions are proposed for the 1073 ICMPv6 Destination Unreachable message. The first proposes a new 1074 definition for a currently-unassigned code type (2) in the ICMPv6 1075 Type Numbers registry; the others propose new definitions for code 1076 types (5) and (6). The code type field definition proposals appear 1077 below: 1079 Type Name Reference 1080 ---- ------------------------- --------- 1081 1 Destination Unreachable [RFC2463] 1082 Code 2 - beyond the scope of source address 1083 5 - source address failed ingress policy 1084 6 - reject route to destination 1086 Normative References 1088 [STD0003] Braden, R., "Requirements for Internet Hosts - Communication 1089 Layers", STD 3, RFC 1122, October 1989. 1091 [STD0005] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1092 1981. 1094 [STD0006] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1095 1980. 1097 [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 1098 IP version 6", RFC 1981, August 1996. 1100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1101 Requirement Levels", BCP 14, RFC 2119, March 1997. 1103 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1104 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1106 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1107 (IPv6) Specification", RFC 2460, December 1998. 1109 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1110 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1112 [RFC2463] Conta, A., and S. Deering, "Internet Control Message Protocol 1113 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", 1114 RFC 2463, December 1998. 1116 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1117 Domains without Explicit Tunnels", RFC 2529, March 1999. 1119 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1120 Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, 1121 November 2002. 1123 [RFC3542] Stevens, W., Thomas, M., Nordmark, E. and T. Jinmei, 1124 "Advanced Sockets Application Program Interface (API) for IPv6", RFC 1125 3542, May 2003. 1127 [RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site- 1128 Multihoming Architectures", RFC 3582, August 2003. 1130 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1131 Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 1133 [ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing 1134 Architecture", draft-ietf-ipv6-addr-arch-v4 (work in progress), 1135 October 2003. 1137 [AUTH] Reynolds, J. and R. Braden, "Instructions to Request for 1138 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis (work in 1139 progress), August 2003. 1141 [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and 1142 More-Specific Routes", draft-ietf-ipv6-router-selection (work in 1143 progress), December 2003. 1145 [ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, 1146 "Internet/Site Automatic Tunnel Addressing Protocol", draft-ietf- 1147 ngtrans-isatap (work in progress), February 2004. 1149 [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast 1150 Name Resolution", draft-ietf-dnsext-mdns (work in progress), January 1151 2004. 1153 [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms 1154 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2 (work in 1155 progress), February 2003. 1157 [NODEREQ] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node- 1158 requirements (work in progress), October 2003. 1160 [UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1161 Addresses", draft-ietf-ipv6-unique-local-addr (work in progress), 1162 January 2004. 1164 Informative References 1166 [BCP0048] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End- 1167 to-end Performance Implications of Slow Links", BCP 48, RFC 3150, 1168 July 2001. 1170 [STD0013] Mockapetris, P., "Domain names - implementation and 1171 specification", STD 13, RFC 1035, November 1987. 1173 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 1174 2402, November 1998. 1176 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1177 (ESP)", RFC 2406, November 1998. 1179 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 1180 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, 1181 January 1999. 1183 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 1184 Networks", RFC 2492, January 1999. 1186 [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 1187 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1189 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 1190 IPv4 Clouds", RFC 3056, February 2001. 1192 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 1193 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 1194 3315, July 2003. 1196 [ANYCAST] Hagino, J. and K. Ettikan, "An Analysis of IPv6 Anycast", 1197 draft-ietf-ipngwg-ipv6-anycast-analysis (work in progress), June 1198 2003. 1200 [DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational 1201 Considerations and Issues with IPv6 DNS", draft-ietf-dnsop-ipv6-dns- 1202 issues, work-in-progress, January 2004. 1204 [FLOW] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, 1205 "IPv6 Flow Label Specification", draft-ietf-ipv6-flow-label (work in 1206 progress), December 2003. 1208 [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful", In 1209 Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications 1210 Technology. August, 1987. 1212 [FTMIB] Haberman, B. and M. Wasserman, "IP Forwarding Table MIB", 1213 draft-ietf-ipv6-rfc2096-update (work in progress), August 2003. 1215 [IPMIB] Routhier, S., "Management Information Base for the Internet 1216 Protocol (IP)", draft-ietf-ipv6-rfc2011-update (work in progress), 1217 September 2003. 1219 [NIQUERY] Crawford, M., "IPv6 Node Information Queries", draft-ietf- 1220 ipngwg-icmp-name-lookups (work in progress), June 2003. 1222 [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. 1223 Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt 1224 (work in progress), October 2003. 1226 [TCPMIB] Raghunarayan, R., "Management Information Base for the 1227 Transmission Control Protocol (TCP)", draft-ietf-ipv6-rfc2012-update 1228 (work in progress), November 2003. 1230 [TUNMIB] Thaler, D., "IP Tunnel MIB", draft-ietf-ipv6-inet-tunnel-mib 1231 (work in progress), January 2004. 1233 [UDPMIB] Raghunarayan, R., "Management Information Base for the 1234 Transmission Control Protocol (TCP)", draft-ietf-ipv6-rfc2012-update 1235 (work in progress), November 2003. 1237 Authors' Addresses 1239 Fred L. Templin 1240 Nokia 1241 313 Fairchild Drive 1242 Mountain View, CA 94110 1243 US 1245 Phone: +1 650 625 2331 1246 EMail: ftemplin@iprg.nokia.com 1248 Tim Gleeson 1249 Cisco Systems K.K. 1250 Shinjuku Mitsu Building 1251 2-1-1 Nishishinjuku, Shinjuku-ku 1252 Tokyo 163-0409 1253 Japan 1255 EMail: tgleeson@cisco.com 1257 Mohit Talwar 1258 Microsoft Corporation 1259 One Microsoft Way 1260 Redmond, WA 98052-6399 1261 US 1263 Phone: +1 425 705 3131 1264 EMail: mohitt@microsoft.com 1266 Dave Thaler 1267 Microsoft Corporation 1268 One Microsoft Way 1269 Redmond, WA 98052-6399 1270 US 1272 Phone: +1 425 703 8835 1273 EMail: dthaler@microsoft.com 1274 Intellectual Property Statement 1276 The IETF takes no position regarding the validity or scope of any 1277 intellectual property or other rights that might be claimed to pertain 1278 to the implementation or use of the technology described in this 1279 document or the extent to which any license under such rights 1280 might or might not be available; neither does it represent that it has 1281 made any effort to identify any such rights. Information on the IETF's 1282 procedures with respect to rights in standards-track and standards- 1283 related documentation can be found in BCP-11. Copies of claims of rights 1284 made available for publication and any assurances of licenses to be made 1285 available, or the result of an attempt made to obtain a general license 1286 or permission for the use of such proprietary rights by implementors or 1287 users of this specification can be obtained from the IETF Secretariat. 1289 The IETF invites any interested party to bring to its attention any 1290 copyrights, patents or patent applications, or other proprietary rights 1291 which may cover technology that may be required to practice this 1292 standard. Please address the information to the IETF Executive Director. 1294 The IETF has been notified of intellectual property rights claimed in 1295 regard to some or all of the specification contained in this document. 1296 For more information consult the online list of claimed rights. 1298 Full Copyright Statement 1300 Copyright (C) The Internet Society (2004). All Rights Reserved. 1302 This document and translations of it may be copied and furnished to 1303 others, and derivative works that comment on or otherwise explain it or 1304 assist in its implementation may be prepared, copied, published 1305 and distributed, in whole or in part, without restriction of any kind, 1306 provided that the above copyright notice and this paragraph are included 1307 on all such copies and derivative works. However, this document itself 1308 may not be modified in any way, such as by removing the copyright notice 1309 or references to the Internet Society or other Internet organizations, 1310 except as needed for the purpose of developing Internet standards in 1311 which case the procedures for copyrights defined in the Internet 1312 Standards process must be followed, or as required to translate it into 1313 languages other than English. 1315 The limited permissions granted above are perpetual and will not be 1316 revoked by the Internet Society or its successors or assignees. This 1317 document and the information contained herein is provided on an "AS IS" 1318 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1319 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1320 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1321 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1322 PARTICULAR PURPOSE. 1324 Acknowledgment 1326 Funding for the RFC Editor function is currently provided by the 1327 Internet Society.