idnits 2.17.1 draft-ietf-ngtrans-isatap-19.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 711 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 16, 2004) is 7374 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) ** Obsolete normative reference: RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** 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 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 3493 ** 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-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) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 15, 2004 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 February 16, 2004 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-19.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 15, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects 43 IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network 44 as a link layer for IPv6 and views other nodes on the network as 45 potential IPv6 hosts/routers. ISATAP supports automatic tunneling and 46 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 . . . . . . . . . . . . . . . . . . . 5 56 5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Addressing Requirements . . . . . . . . . . . . . . . . . . . 7 58 7. Configuration and Management Requirements . . . . . . . . . . 8 59 8. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 12 60 9. Neighbor Discovery for ISATAP Interfaces . . . . . . . . . . . 17 61 10. Security considerations . . . . . . . . . . . . . . . . . . . 20 62 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 63 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20 64 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 65 A. Major Changes . . . . . . . . . . . . . . . . . . . . . . . . 23 66 B. The IPv6 Minimum MTU . . . . . . . . . . . . . . . . . . . . . 23 67 C. Modified EUI-64 Addresses in the IANA Ethernet Address Block . 24 68 D. Proposed ICMPv6 Code Field Types . . . . . . . . . . . . . . . 25 69 Normative References . . . . . . . . . . . . . . . . . . . . . 25 70 Informative References . . . . . . . . . . . . . . . . . . . . 27 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 72 Intellectual Property and Copyright Statements . . . . . . . . 29 74 1. Introduction 76 This document specifies a simple mechanism called the Intra-Site 77 Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 78 [RFC2460] hosts/routers over IPv4 [STD5] networks. Dual-stack 79 (IPv6/IPv4) nodes use ISATAP to automatically tunnel IPv6 packets in 80 IPv4, i.e., ISATAP views the IPv4 network as a link layer for IPv6 81 and views other nodes on the network as potential IPv6 hosts/routers. 83 ISATAP enables automatic tunneling whether global or private IPv4 84 addresses are used, and supports a tunnel interface management 85 abstraction similar to the Non-Broadcast, Multiple Access (NBMA) 86 [RFC2491] and ATM Permanent/Switched Virtual Circuit (PVC/SVC) 87 [RFC2492] models. 89 The main objectives of this document are to: 1) describe the ISATAP 90 conceptual model, 2) specify addressing requirements, 3) discuss 91 configuration and management requirements, 4) specify automatic 92 tunneling using ISATAP, 5) specify operational aspects of IPv6 93 Neighbor Discovery, and 6) discuss IANA and Security considerations. 95 This document surveys all IETF v6ops WG documents current up to 96 February 16, 2004. 98 2. Requirements 100 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 101 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 102 document, are to be interpreted as described in [BCP14]. 104 This document also makes use of internal conceptual variables to 105 describe protocol behavior and external variables that an 106 implementation must allow system administrators to change. The 107 specific variable names, how their values change, and how their 108 settings influence protocol behavior are provided to demonstrate 109 protocol behavior. An implementation is not required to have them in 110 the exact form described here, so long as its external behavior is 111 consistent with that described in this document. 113 3. Terminology 115 The terminology of [STD3][RFC2460][RFC2461][RFC3582] applies to this 116 document. The following additional terms are defined: 118 ISATAP node: 119 a node that implements the specifications in this document. 121 ISATAP daemon: 122 an ISATAP node's server application that uses an API for control 123 plane signaling and tunnel interface configuration/management. 125 ISATAP driver: 126 an ISATAP node's network module that provides an API for control 127 plane signaling and tunnel interface configuration/management. 128 Also provides a packet encapsulation/decapsulation engine, and an 129 embedded gateway function (see: [STD3], section 3.3.4.2). 131 logical interface: 132 an IPv6 address or a configured tunnel interface associated with 133 an ISATAP interface (see: [STD3], section 3.3.4.1). 135 ISATAP interface: 136 an ISATAP node's point-to-multipoint interface that provides a 137 control plane interface for the ISATAP daemon and a forwarding 138 plane nexus for its associated logical interfaces. 140 ISATAP interface identifier: 141 an IPv6 interface identifier with an embedded IPv4 address 142 constructed as specified in section 6.1. 144 ISATAP address: 145 an IPv6 unicast address assigned on an ISATAP interface with an 146 on-link prefix and an ISATAP interface identifier. 148 locator: 149 an IPv4 address-to-interface mapping, i.e., a node's IPv4 address 150 and the index for it's associated interface. 152 locator set: 153 a set of locators associated with a tunnel interface, where each 154 locator in the set belongs to the same site. 156 4. ISATAP Conceptual Model 158 ISATAP interfaces are advertising IPv6 interfaces that provide a 159 point-to-multipoint abstraction for IPv6-in-IPv4 tunneling. They 160 provide a forwarding plane nexus (used by the ISATAP driver) for 161 their associated logical interfaces. They also provide a control 162 plane interface (used by the ISATAP daemon) for tunnel configuration 163 signaling. 165 The ISATAP driver encapsulates packets for transmission according to 166 parameters associated with its logical interfaces. It also determines 167 the correct interface to receive each tunneled packet after 168 decapsulation, and provides an embedded gateway function. 170 The ISATAP daemon configures and manages tunnels via an API provided 171 by the ISATAP driver. Each such configured tunnel provides a nexus 172 for multiple applications using IPv6 addresses as application 173 identifiers. Each such application identifier provides a nexus for 174 multiple sessions. In summary, each configured tunnel provides a 175 point-to-point connection between peers that can support multiple 176 applications and multiple instances of each application. 178 The following example diagram depicts the ISATAP conceptual model: 180 <-- IPv6-enabled applications --> 181 +----+ +---------------------------------------------+ 182 |I D| | IPv6 Stack | 183 |S a| | | 184 |A e| | <-- IPv6 addresses --> | 185 |T m| | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | 186 |A o| | |v6| |v6| |v6| |v6| |v6| |v6| |v6| ... |v6| | 187 |P n| | +--+ +-++ ++-+ ++-+ ++++ ++-+ +-++ +-++ | 188 +-+--+ +---/---/----|----|---/-|--|-\----|--------|--+ 189 | / / | | / | | \ | | <----+ 190 x / / | | / | | \ | | I | 191 / / +--++ +++-+ +--++ ++-++ +-+-+ S | 192 / / |tun| |tun| |tun| |tun| ... |tun| A | 193 / / +-+-+ +--++ +-+-+ ++--+ +-+-+ T | 194 / / | \ | / | A | 195 x / / x | x \ | / x | P | 196 | / / | | | \ | / | | | 197 +--+---+---+ +------+---+ +-----+-+-++ +--------+-+ D | 198 |ISATAP I/F| |ISATAP I/F| |ISATAP I/F| .. |ISATAP I/F| r | 199 | (site 1) | | (site 1) | | (site 3) | | (site n) | i | 200 +---+----+++ +-++-----+-+ +-+-----+-++ +------+---+ v | 201 | | \ / | | | | \ | e | 202 | | \/ | | | | \ | r | 203 | | /\ | | | | \ | <----+ 204 +---|----|-/--\-|-----|-----|-----|-----\ -------|---+ 205 | +-+-+ +++-+ +++-+ +-+-+ +-+-+ +-+-+ +--++ +-+-+ | 206 | |loc| |loc| |loc| |loc| |loc| |loc| |loc| .. |loc| | 207 | +-+-+ +--++ +---+ +---+ +-+-+ +-+-+ +-+-+ +-+-+ | 208 | | / / / \ | / / | 209 | | / / +---+ \ | / / | 210 | | / / / \ | / / | 211 | | / / / IPv4 Stack \ | / / | 212 +-+-+-+--+-+--+--------+--+------+++------+-+------+-+ 213 |IPv4 I/F| |IPv4 I/F| |IPv4 I/F| .... |IPv4 I/F| 214 |(site 1)| |(site 2)| |(site 3)| |(site n)| 215 +--------+ +--------+ +--------+ +--------+ 217 5. Node Requirements 219 ISATAP nodes observe the common functionality requirements in 220 [NODEREQ] and the DNS requirements in ([MECH], section 2.2). They 221 also implement the additional features specified in this document. 223 6. Addressing Requirements 225 6.1 ISATAP Interface Identifiers 227 ISATAP interface identifiers are constructed in Modified EUI-64 228 format ([ADDR], appendix A). They are formed by concatenating the 229 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 230 32-bit IPv4 address in network byte order. 232 The format for ISATAP interface identifiers is given below (where 'u' 233 is the IEEE univeral/local bit, 'g' is the IEEE group/individual bit, 234 and the 'm' bits represent the concatenated IPv4 address): 236 |0 1|1 3|3 4|4 6| 237 |0 5|6 1|2 7|8 3| 238 +----------------+----------------+----------------+----------------+ 239 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 240 +----------------+----------------+----------------+----------------+ 242 When the IPv4 address is known to be globally unique, the 'u' bit is 243 set to 1; otherwise, the 'u' bit is set to 0 ([ADDR], section 2.5.1). 244 See: Appendix C for additional non-normative details. 246 6.2 ISATAP Addresses 248 Any IPv6 unicast address ([ADDR], section 2.5) that contains an 249 ISATAP interface identifier constructed as specified in section 6.1 250 and an on-link prefix on an ISATAP interface is considered an ISATAP 251 address. 253 6.3 Multicast/Anycast 255 ISATAP interfaces recognize a node's required IPv6 multicast/anycast 256 addresses ([ADDR], section 2.8). 258 For IPv6 multicast addresses of interest to local applications, 259 ISATAP nodes join the corresponding Organization-Local Scope IPv4 260 multicast groups ([RFC2529], section 6) on each interface that 261 appears in an ISATAP interface's locator set (see: section 7.2). 263 IPv6 multicast addresses of interest include a node's required 264 multicast addresses, and may also include e.g, the 265 'All_DHCP_Relay_Agents_and_Servers' and 'All_DHCP_Servers' multicast 266 addresses (i.e., if the node is configured as a DHCPv6 server 267 [RFC3315][RFC3633]), etc. 269 Considerations for IPv6 anycast appear in [ANYCAST]. 271 6.4 Source/Target Link Layer Address Options 273 Source/Target Link Layer Address Options ([RFC2461], section 4.6.1) 274 for ISATAP have the following format: 276 +-------+-------+-------+-------+-------+-------+-------+--------+ 277 | Type |Length | 0 | 0 | IPv4 Address | 278 +-------+-------+-------+-------+-------+-------+-------+--------+ 280 Type: 281 1 for Source Link-layer address. 2 for Target Link-layer address. 283 Length: 284 1 (in units of 8 octets). 286 IPv4 Address: 287 A 32 bit IPv4 address, in network byte order. 289 ISATAP nodes use the specifications in ([MECH], section 3.8) that 290 pertain to sending and receiving Source/Target Link Layer Address 291 Options. 293 7. Configuration and Management Requirements 295 7.1 Network Management 297 This document defines no new MIB tables, nor extensions to any 298 existing MIB tables. Objects found in [FTMIB][IPMIB][TUNMIB] are 299 supported as described in the following subsections. 301 7.2 The ifRcvAddressTable 303 The ISATAP driver maintains ifRcvAddressTable as a bidirectional 304 association of locators with tunnel interfaces. Each locator in the 305 table includes an IPv4 address-to-interface mapping (i.e., an IPv4 306 ipAddressEntry in the node's ipAddressTable) and a list of associated 307 tunnel interfaces. Each tunnel interface in the table has a 308 tunnelIfEntry and a list of associated locators, i.e., a "locator 309 set". 311 The ISATAP driver implements the following conceptual functions to 312 manage and search the ifRcvAddressTable: 314 7.2.1 RcvTableAdd(locator, tunnel_interface) 316 Creates a bidirectional association in the ifRcvAddressTable between 317 the locator and tunnel interface, i.e., adds the locator to the 318 tunnel interface's locator set and adds the tunnel interface to the 319 locator's association list. 321 Returns success or failure. 323 7.2.2 RcvTableDel(locator, tunnel_interface) 325 Deletes ifRcvAddressTable entries according to the locator and tunnel 326 interface arguments as follows: 328 - if both arguments are NULL, garbage-collects the entire table. 330 - if both arguments are non-NULL, deletes the locator from the 331 tunnel interface's locator set and deletes the tunnel interface 332 from the locator's association list. 334 - if the locator is non-NULL and tunnel interface is NULL, deletes 335 the locator from the locator sets of all tunnel interfaces. 337 - if the locator is NULL and the tunnel interface is non-NULL, 338 deletes the tunnel interface from the association lists of all 339 locators. 341 Returns success or failure. 343 7.2.3 RcvTableLocate(packet) 345 Searches the ifRcvAddressTable to locate the correct tunnel interface 346 to decapsulate a packet. First, determines the locator that matches 347 the packet's IPv4 destination address and ifIndex for the interface 348 the packet arrived on. Next, checks each tunnel interface in the 349 locator's association list for exact matches of tunnelIfEncapsMethod 350 with the packet's encapsulation type and tunnelIfRemoteInetAddress 351 with the packet's IPv4 source address. 353 If there is no match on the packet's IPv4 source address, a tunnel 354 interface with a matching tunnelIfEncapsMethod and with 355 tunnelIfRemoteInetAddress set to 0.0.0.0 is selected. If there are 356 multiple matches, a tunnel interface with tunnelIfLocalInetAddress 357 that matches the packet's IPv4 destination address is preferred. 359 Returns a pointer to a tunnel interface if a match is found; else 360 NULL. 362 7.3 ISATAP Driver API 364 The ISATAP driver implements an API used by, e.g., the ISATAP daemon, 365 startup scripts, manual command line entry, kernel processes, etc. 366 Access MUST be restricted to privileged users and applications. 367 ISATAP nodes implement the basic and advanced APIs for IPv6 368 [RFC3493][RFC3542]. 370 7.4 ISATAP Interface Creation/Configuration 372 ISATAP interfaces are created via the tunnelIfConfigTable, which 373 results in simultaneous creation of a tunnelIfEntry and a companion 374 ipv6InterfaceEntry. Each ISATAP interface configures a locator set, 375 where each locator in the set represents an IPv4 address-to-interface 376 mapping for the same site (or, represents a mapping that is routable 377 on the global Internet). ISATAP interfaces MUST NOT configure a 378 locator set that spans multiple sites. 380 ISATAP interfaces configure the following values for objects in 381 tunnelIfEntry: 383 - tunnelIfEncapsMethod is set to an IANATunnelType for "isatap". 385 - tunnelIfLocalInetAddress is set to an IPv4 address from the 386 interface's locator set. 388 - tunnelIfRemoteInetAddress is set to 0.0.0.0 to denote wildcard 389 match for remote tunnel endpoints. 391 - other read-write objects in the tunnelIfEntry are configured as 392 for any tunnel interface. 394 ISATAP interfaces are configured as advertising IPv6 interfaces and 395 set the following values for objects in ipv6InterfaceEntry: 397 - ipv6InterfaceType is set to "tunnel". 399 - ipv6InterfacePhysicalAddress is set to an octet string of zero 400 length to indicate that this IPv6 interface does not have a 401 physical address. 403 - ipv6InterfaceForwarding and ip6Forwarding for the node are set to 404 "forwarding". 406 - other read-write objects in ipv6InterfaceEntry are configured as 407 for any IPv6 interface. 409 ISATAP interfaces create an ipv6RouterAdvertEntry and set its 410 ipv6RouterAdvertIfIndex object to the same value as 411 ipv6InterfaceIfIndex. Other objects in ipv6RouterAdvertEntry are 412 configured as for any IPv6 router. 414 IPv6 address selection rules for ISATAP interfaces are specified in 415 [RFC3484]. 417 7.5 Configured Tunnel Creation/Configuration 419 Configured tunnels are normally created by the ISATAP daemon in 420 dynamic response to a tunnel creation request as an ISATAP 421 interface's associated logical interface; they inherit the locator 422 set of their associated ISATAP interface. Configured tunnels set the 423 following values for objects in tunnelIfEntry: 425 - tunnelIfEncapsMethod is set to an appropriate IANATunnelType 426 value. 428 - tunnelIfLocalInetAddress is set to an IPv4 address from the 429 interface's locator set. 431 - tunnelIfRemoteInetAddress is set to an IPv4 address for the node 432 at the far end of the tunnel. 434 - other read-write objects in the tunnelIfEntry are configured as 435 for any tunnel interface. 437 Configured tunnels set values for objects in ipv6InterfaceEntry as 438 follows: 440 - ipv6InterfaceType is set to "tunnel". 442 - ipv6InterfacePhysicalAddress is set to an octet string of zero 443 length to indicate that this IPv6 interface does not have a 444 physical address. 446 - other read-write objects in ipv6InterfaceEntry are configured as 447 for any IPv6 interface. 449 IPv6 address selection rules for configured tunnel interfaces are 450 specified in [RFC3484]. 452 7.6 Reconfigurations Due to IPv4 Address Changes 454 When an IPv4 address is removed from an interface, its corresponding 455 locator SHOULD be removed from all locator sets via 456 RcvTableDel(locator, NULL); tunnelIfEntrys that used the IPv4 address 457 as tunnelIfLocalInetAddress SHOULD also configure a different local 458 IPv4 address from their remaining locator set. 460 When a new IPv4 address is added to an IPv4 interface, the node MAY 461 add the corresponding new locator to a tunnel interface's locator set 462 via RcvTableAdd(locator, tunnel_interface), and MAY also set 463 tunnelIfLocalInetAddress for its tunnelIfEntry to the new address. 465 Methods for triggering the above changes are out of scope. 467 8. Automatic Tunneling 469 ISATAP nodes use the basic tunneling mechanisms specified in [MECH]. 470 The following additional specifications are also used: 472 8.1 Encapsulation 474 The ISATAP driver encapsulates IPv6 packets using various 475 encapsulation methods, including ip-protocol-41 (e.g., 6over4 476 [RFC2529], 6to4 [RFC3056], IPv6-in-IPv4 configured tunnels [MECH], 477 isatap, etc.), UDP [STD6] port 3544, and others. 479 Security processing (e.g., [RFC2402][RFC2406], etc.), upper layer 480 fragmentation [RFC3542] and header compression for the packet's inner 481 headers are performed prior to encapsulation. 483 8.1.1 NAT Traversal 485 Native IPv6 and/or ip-protocol-41 encapsulation provides sufficient 486 functionality to support communications between peers that reside 487 within the same site (i.e., the same enterprise network). When the 488 remote peer is in a different site, NAT traversal via UDP/IPv4 489 encapsulation MAY be necessary. 491 When an ISATAP node determines that NAT traversal is necessary to 492 reach a particular peer, it encapsulates IPv6 packets using UDP/IPv4 493 port 3544 encapsulation. This determination may come through, e.g., 494 first attempting communications via ip-protocol-41 then failing over 495 to UDP/IPv4 port 3544 encapsulation, administrative knowledge that a 496 NAT is on the path, etc. 498 8.1.2 Multicast 500 ISATAP interfaces encapsulate packets with IPv6 multicast destination 501 addresses using a mapped Organization-Local Scope IPv4 multicast 502 address ([RFC2529], section 6) as the destination address in the 503 encapsulating IPv4 header. 505 8.2 Tunnel MTU and Fragmentation 507 Encapsulated packets sent by the ISATAP driver may require host-based 508 IPv4 fragmentation in order to satisfy the 1280 byte IPv6 minimum 509 MTU, e.g., when the underlying link has a small IPv4 MTU [BCP48]. 510 While this intentional fragmentation is not considered harmful, 511 unmitigated IPv4 fragmentation caused by the network can cause poor 512 performance [FRAG]. For example, since the minimum IPv4 fragment 513 size is only 8 bytes [STD5], a single 1280 byte encapsulated packet 514 could be shredded by the network into as many as 160 IPv4 fragments 515 with obvious negative performance implications. 517 ISATAP uses the MTU and fragmentation specifications in ([MECH], 518 section 3.2) and the Maximum Reassembly Unit (MRU) specifications in 519 ([MECH], section 3.6), which provide sufficient measures for avoiding 520 excessive IPv4 fragmentation in certain controlled environments 521 (e.g., 3GPP operator networks, enterprise networks, etc). To minimize 522 IPv4 fragmentation and improve performance in general use case 523 scenarios, ISATAP nodes SHOULD add the following simple 524 instrumentation to the IPv4 reassembly cache: 526 When the initial fragment of an encapsulated packet arrives, the 527 packet's IPv4 reassembly timer is set to 1 second (i.e., the worst 528 case store-and-forward delay budget for a 1280 byte packet). If an 529 encapsulated packet's IPv4 reassembly timer expires: 531 - If enough contiguous leading bytes of the packet have arrived 532 (see: section 8.6), reassemble the packet using zero-filled or 533 heuristically-chosen replacement data bytes in place of any 534 missing fragments. (Otherwise, garbage-collect the reassembly 535 buffer and return from processing.) 537 - Mark the packet as "INCOMPLETE", and also mark it with an 538 "ACTUAL_BYTES" length that encodes the actual number of data bytes 539 in fragments that arrived. 541 - Deliver the packet to the ISATAP driver, and do not send an ICMPv4 542 "time exceeded" message [STD5]. 544 Appendix B provides informative text on the derivation of the 1280 545 byte IPv6 minimum MTU. 547 8.3 Handling ICMPv4 Errors 549 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 550 errors as link-specific information indicating that a path to a 551 neighbor may have failed ([RFC2461], section 7.3.3). 553 8.4 Link-Local Addresses 555 ISATAP interfaces use link local addresses constructed as specified 556 in section 6.1 of this document. 558 8.5 Neighbor Discovery over Tunnels 560 The specification in ([MECH], section 3.8) is used; the additional 561 specification for neighbor discovery in section 9 of this document 562 are also used. 564 8.6 Decapsulation/Filtering 566 ISATAP nodes typically arrange for the ISATAP driver to receive all 567 IPv4-encapsulated IPv6 packets that are addressed to one of the 568 node's IPv4 addresses. Examples include ip-protocol-41 (e.g., 6to4, 569 6over4, configured tunnels, isatap, etc.), UDP/IPv4 port 3544, and 570 others. The ISATAP driver uses the decapsulation and filtering 571 specifications in ([MECH], section 3.6), and processes each packet 572 according to the following steps: 574 1. Locate the correct tunnel interface to receive the packet (see: 575 section 7.2.3). If not found, silently discard the packet and 576 return from processing. 578 2. If the tunnel uses header compression, reconstitute headers. If 579 header reconstitution fails, silently discard the packet and 580 return from processing. 582 3. Verify that the packet's IPv4 source address is correct for the 583 encapsulated IPv6 source address. For packets received on a 584 configured tunnel interface, verification is exactly as specified 585 in ([MECH], section 3.6). 587 For packets received on an ISATAP interface, the IPv4 source 588 address is correct if: 590 - the IPv6 source address is an ISATAP address that embeds the 591 IPv4 source address in its interface identifier, or: 593 - the IPv6 source address is the address of an IPv6 neighbor on 594 an ISATAP interface associated with the locator that matched 595 the packet (see: section 7.2.3), or: 597 - the IPv4 source address is a member of the Potential Router 598 List (see: section 9.1). 600 If the IPv4 source address is incorrect, silently discard the 601 packet and return from processing. 603 4. Perform IPv4 ingress filtering (optional; disabled by default) 604 then decapsulate the packet but do not discard encapsulating 605 headers. If the IPv6 source address is invalid (see: [MECH], 606 section 3.6), silently discard the packet and return from 607 processing. 609 For UDP port 3544 packets received on an ISATAP interface, if the 610 IPv6 source address is an ISATAP link local address with the 'u' 611 bit set to 0 and an embedded IPv4 address that does not match the 612 IPv4 source address (see: section 6), rewrite the IPv6 source 613 address to inform upper layers of the sender's mapped UDP port 614 number and IPv4 source address. Specific rules for rewriting the 615 IPv6 source address are established during ISATAP interface 616 configuration. 618 5. Perform ingress filtering on the IPv6 source address (see: 619 [MECH], section 3.6). Next, determine the correct transport 620 protocol listener [FLOW] if the packet is destined to the 621 localhost; otherwise, perform an IPv6 forwarding table lookup and 622 site border/firewall filtering (see: [UNIQUE], section 6). 624 If the packet cannot be delivered, the driver SHOULD send an 625 ICMPv6 Destination Unreachable message ([RFC2463], section 3.2) 626 to the packet's source. The message SHOULD select as its source 627 address an IPv6 address from the outgoing interface (if the 628 packet was destined to the localhost) or an ingress-wise correct 629 IPv6 address from the interface that would have forwarded the 630 packet had it not been filtered. 632 The Code field of the message is set as follows: 634 - if there is no route to the destination, the Code field is set 635 to 0 (see: [RFC2463], section 3.1). 637 - if communication with the destination is administratively 638 prohibited, the Code field is set to 1 ([RFC2463], section 639 3.1). 641 - if the packet is destined to the localhost, but the transport 642 protocol has no listener, the Code field is set to 4 643 ([RFC2463], section 3.1). 645 - if the packet's destination is beyond the scope of the source 646 address, the Code field is set to 2 (see: IANA 647 Considerations). 649 - if the packet was dropped due to ingress filtering policies, 650 the Code field is set to 5 (see: IANA Considerations). 652 - if the packet is dropped due to a reject route, the Code field 653 is set to 6 (see: IANA Considerations). 655 - if the packet was received on a point-to-point link and 656 destined to an address within a subnet assigned to that same 657 link, or if the reason for the failure to deliver cannot be 658 mapped to any of the specific conditions listed above, the 659 Code field is set to 3 ([RFC2463], section 3.2). 661 After sending the ICMPv6 Destination Unreachable message, discard 662 the packet and return from processing. 664 6. If the packet is "INCOMPLETE" (see section 8.2) prepare an 665 authenticated, unsolicited Router Advertisement message 666 ([RFC2461], section 6.2.4) with an MTU option that encodes the 667 maximum of "ACTUAL_BYTES" and (68 bytes minus the size of 668 encapsulating headers.) 670 The IPv6 destination address in the Router Advertisement message 671 is set to the packet's IPv6 source address, and the message is 672 reverse-encapsulated and returned to the node that sent the 673 "INCOMPLETE" packet, i.e., it is NOT presented to the native IPv6 674 stack for transmission. 676 The 68 byte minimum MTU is due to the requirement that every 677 Internet module must be able to forward a datagram of 68 octets 678 without further fragmentation ([STD5], Internet Protocol, section 679 3.2). 681 7. Discard encapsulating headers. If the packet was destined to a 682 remote host, forward the packet and return from processing. 683 Otherwise, apply security processing (e.g., [RFC2402][RFC2406], 684 etc.), and place the packet in a buffer for upper layers. The 685 buffer may be, e.g., the IPv6 reassembly cache, an application's 686 mapped data buffer [RFC3542], etc. 688 If there is clear evidence that upper layer reassembly has 689 stalled, an ICMPv6 Packet Too Big message [RFC1981] MAY be sent 690 to the packet's source address with an MTU value likely to incur 691 successful reassembly. Some applications may realize greater 692 efficiency by accepting partial information from "INCOMPLETE" 693 packets (see: section 8.2) and requesting selective 694 retransmission of missing portions. 696 9. Neighbor Discovery for ISATAP Interfaces 698 ISATAP nodes use the neighbor discovery mechanisms specified in 699 [RFC2461] along with securing mechanisms (e.g., [SEND]) to create/ 700 change neighbor cache entries and to provide control plane signaling 701 for automatic tunnel configuration. ISATAP interfaces also implement 702 the following specifications: 704 9.1 Conceptual Model Of A Host 706 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 707 ISATAP interfaces add: 709 Potential Router List 710 A set of entries about potential routers; used to support the 711 mechanisms specified in section 9.2.2.1. Each entry ("PRL(i)") 712 has an associated timer ("TIMER(i)"), and an IPv4 address 713 ("V4ADDR(i)") that represents a router's advertising ISATAP 714 interface. 716 9.2 Router and Prefix Discovery 718 9.2.1 Router Specification 720 The Router Specification in ([RFC2461], section 6.2) is used. Router 721 Advertisements sent on ISATAP interfaces MAY include information 722 delegated via DHCPv6 [RFC3633]). Router Advertisements sent on ISATAP 723 interfaces MUST NOT include a prefix option containing a preferred 724 lifetime greater than the valid lifetime. 726 9.2.2 Host Specification 728 The Host Specification in ([RFC2461], section 6.3) is used. ISATAP 729 interfaces add the following specifications: 731 9.2.2.1 Host Variables 733 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 734 interfaces add: 736 PrlRefreshInterval 737 Time in seconds between successive refreshments of the PRL after 738 initialization. The designated value of all 1's (0xffffffff) 739 represents infinity. 740 Default: 3600 seconds 742 MinRouterSolicitInterval 743 Minimum time in seconds between successive solicitations of the 744 same advertising ISATAP interface. The designated value of all 1's 745 (0xffffffff) represents infinity. 747 9.2.2.2 Potential Router List Initialization 749 ISATAP nodes provision an ISATAP interface's PRL with IPv4 addresses 750 discovered via a DNS fully-qualified domain name (FQDN) [STD13], 751 manual configuration, a DHCPv4 option, a DHCPv4 vendor-specific 752 option, or an unspecified alternate method. 754 FQDNs are established via manual configuration or an unspecified 755 alternate method. FQDNs are resolved into IPv4 addresses through 756 querying the DNS service, querying a site-specific name service, 757 static host file lookup, or an unspecified alternate method. 759 When the node provisions an ISATAP interface's PRL with IPv4 760 addresses, it sets a timer for the interface (e.g., 761 PrlRefreshIntervalTimer) to PrlRefreshInterval seconds. The node re- 762 initializes the PRL as specified above when PrlRefreshIntervalTimer 763 expires, or when an asynchronous re-initialization event occurs. When 764 the node re-initializes the PRL, it resets PrlRefreshIntervalTimer to 765 PrlRefreshInterval seconds. 767 9.2.2.3 Processing Received Router Advertisements 769 To the list of checks for validating Router Advertisement messages 770 ([RFC2461], section 6.1.1), ISATAP interfaces add: 772 - IP Source Address is an ISATAP link-local address that embeds 773 V4ADDR(i) for some PRL(i). 775 Valid Router Advertisements received on an ISATAP interface are 776 processed exactly as specified in ([RFC2461], section 6.3.4) except 777 that, for unicast Router Advertisements that include an MTU option, 778 the MTU value does not alter the ISATAP interface LinkMTU. Instead, 779 the MTU value is recorded, e.g., in the IPv6 forwarding table. If the 780 IPv6 destination address is one of the node's own unicast addresses, 781 the MTU value is recorded such that upper layer fragmentation 782 [RFC3542] will be used to reduce the size of the encapsulated packets 783 sent via the router. The recorded value is aged as for IPv6 path MTU 784 information [RFC1981]. 786 9.2.2.4 Sending Router Solicitations 788 To the list of events after which Router Solicitation messages may be 789 sent ([RFC2461], section 6.3.7), ISATAP interfaces add: 791 - TIMER(i) for some PRL(i) expires. 793 Since unsolicited Router Advertisements may be incomplete (and, since 794 multicast unsolicited Router Advertisements may not arrive) ISATAP 795 nodes schedule periodic events to solicit Router Advertisements from 796 certain PRL(i)'s. When this periodic solicitation is used, after 797 sending the initial solicitation and receiving a valid Router 798 Advertisement message from PRL(i) with a non-zero Router Lifetime the 799 node sets TIMER(i) to schedule the first periodic event. 801 The TIMER(i) value SHOULD be set such that the next periodic event 802 will trigger a solicited Router Advertisement message before the 803 expiration of remaining lifetimes stored for this PRL(i), including 804 the Router Lifetime, Valid Lifetimes received in Prefix Information 805 Options, and Route Lifetimes received in Route Information Options 806 [DEFLT]. The TIMER(i) value MUST be set to no less than 807 MinRouterSolicitInterval seconds, where MinRouterSolicitInterval is 808 configurable for the node with a conservative default value. 810 When TIMER(i) expires, the node sends Router Solicitation messages as 811 specified in ([RFC2461], section 6.3.7) except that the messages use 812 an ISATAP link-local address that embeds V4ADDR(i) as the IPv6 813 destination address (i.e., instead of the All-Routers multicast 814 address). If remaining lifetimes for this PRL(i) have not yet expired 815 and the PRL(i) is still in use, TIMER(i) is reset as described above. 817 9.3 Address Resolution and Neighbor Unreachability Detection 819 9.3.1 Address Resolution 821 The specification in ([RFC2461], section 7.2) is used. ISATAP 822 addresses for which the neighbor's link-layer address cannot 823 otherwise be determined (e.g., from a neighbor cache entry) are 824 resolved to link-layer addresses by a static computation, i.e., the 825 last four octets are treated as an IPv4 address. 827 Hosts SHOULD perform an initial reachability confirmation by sending 828 Neighbor Solicitation message(s) and receiving a Neighbor 829 Advertisement message. Routers MAY perform this initial reachability 830 confirmation, but this might not scale in all environments. 832 9.3.2 Neighbor Unreachability Detection 834 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 835 section 7.3). Routers MAY perform neighbor unreachability detection, 836 but this might not scale in all environments. 838 10. Security considerations 840 Security considerations in the normative references apply. Also: 842 - ISATAP nodes observe the security considerations outlined in 843 [SENDPS]; use of (e.g., [RFC2402][RFC2406], etc.) is not always 844 feasible. 846 - site border routers SHOULD install a reject route for the IPv6 847 prefix FC00::/7 to insure that packets with local IPv6 destination 848 addresses will not be forwarded outside of the site via a default 849 route. 851 - administrators MUST ensure that lists of IPv4 addresses 852 representing the advertising ISATAP interfaces of PRL members are 853 well maintained. 855 11. IANA Considerations 857 The IANA is instructed to specify the format for Modified EUI-64 858 address construction ([ADDR], Appendix A) in the IANA Ethernet 859 Address Block. The text in Appendix C of this document is offered as 860 an example specification. The current version of the IANA registry 861 for Ether Types can be accessed at: 862 http://www.iana.org/assignments/ethernet-numbers. 864 The IANA is instructed to assign the new ICMPv6 code field types 865 found in Appendix D of this document for the ICMPv6 Destination 866 Unreachable message. The policy for assigning new ICMPv6 code field 867 types is First Come First Served, as defined in [BCP26]. The current 868 version of the IANA registry for ICMPv6 type numbers can be accessed 869 at: 870 http://www.iana.org/assignments/icmpv6-parameters. 872 12. IAB Considerations 874 [RFC3424] ("IAB Considerations for UNilateral Self-Address Fixing 875 (UNSAF) Across Network Address Translation") section 4 requires that 876 any proposal supporting NAT traversal must explicitly address the 877 following considerations: 879 12.1 Problem Definition 881 The specific problem being solved is enabling IPv6 connectivity for 882 ISATAP nodes that are unable to communicate via ip-protocol-41 or 883 native IPv6. 885 12.2 Exit Strategy 887 ISATAP nodes use UDP/IPv4 encapsulation for NAT traversal as a last 888 resort. As soon as native IPv6 or ip-protocol-41 support becomes 889 available, ISATAP nodes will naturally cease using UDP/IPv4 890 encapsulation. 892 12.3 Brittleness 894 UDP/IPv4 encapsulation with ISATAP introduces brittleness into the 895 system in several ways: the discovery process assumes a certain 896 classification of devices based on their treatment of UDP; the 897 mappings need to be continuously refreshed, and addressing structure 898 may cause some hosts located beyond a common NAT to be unreachable 899 from each other. 901 ISATAP assumes a certain classification of devices based on their 902 treatment of UDP. There could be devices that would not fit into one 903 of these molds, and hence would be improperly classified by ISATAP. 905 The bindings allocated from the NAT need to be continuously 906 refreshed. Since the timeouts for these bindings is very 907 implementation specific, the refresh interval cannot easily be 908 determined. When the binding is not being actively used to receive 909 traffic, but to wait for an incoming message, the binding refresh 910 will needlessly consume network bandwidth. 912 12.4 Requirements for a Long Term Solution 914 The devices that implement the IPv4 NAT service should in the future 915 also become IPv6 routers. 917 13. Acknowledgments 919 The ideas in this document are not original, and the authors 920 acknowledge the original architects. Portions of this work were 921 sponsored through SRI International internal projects and government 922 contracts. Government sponsors include Monica Farah-Stapleton and 923 Russell Langan (U.S. Army CECOM ASEO), and Dr. Allen Moshfegh (U.S. 924 Office of Naval Research). SRI International sponsors include Dr. 925 Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi 926 Sastry. 928 The following are acknowledged for providing peer review input: Jim 929 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 930 Ole Troan, Vlad Yasevich. 932 The following are acknowledged for their significant contributions: 933 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 934 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka 935 Savola, Margaret Wasserman, Brian Zill. 937 The authors acknowledge the work of Quang Nguyen on "Virtual 938 Ethernet" under the guidance of Dr. Lixia Zhang that proposed very 939 similar ideas to those that appear in this document. This work was 940 first brought to the authors' attention on September 20, 2002. 942 IAB considerations are the same as for Teredo. The diagram in section 943 4 was inspired by a similar diagram in RFC 3371. 945 The following individuals are acknowledged for their helpful insights 946 on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound, 947 Ralph Droms, Alain Durand, Jun-ichiro itojun Hagino, Brian Haberman, 948 Bob Hinden, Christian Huitema, Kevin Lahey, Hakgoo Lee, Matt Mathis, 949 Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel, 950 Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave 951 Thaler, Michael Welzl, Lixia Zhang and the members of the Nokia NRC/ 952 COM Mountain View team. 954 "...and I'm one step ahead of the shoe shine, 955 Two steps away from the county line, 956 Just trying to keep my customers satisfied, 957 Satisfi-i-ied!" - Paul Simon, 1969 959 Appendix A. Major Changes 961 Major changes from earlier versions to version 17: 963 - new section on configuration/management. 965 - new appendices on IPv6 minimum MTU; IANA considerations. 967 - expanded section on MTU and fragmentation. 969 - expanded sections on encapsulation/decapsulation. 971 - specified relation to IPv6 Node Requirements. 973 - introduced distinction between control; forwarding planes. 975 - specified multicast mappings. 977 - revised neighbor discovery, address autoconfiguration, IANA 978 considerations and security considerations sections. 980 Appendix B. The IPv6 minimum MTU 982 The 1280 byte IPv6 minimum MTU was proposed by Steve Deering and 983 agreed through working group consensus in November 1997 discussions 984 on the IPv6 mailing list. The size was chosen to allow extra room for 985 link layer encapsulations without exceeding the Ethernet MTU of 1500 986 bytes, i.e., the practical physical cell size of the Internet. The 987 1280 byte MTU also provides a fixed upper bound for the size of IPv6 988 packets/fragments with a maximum store-and-forward delay budget of ~1 989 second assuming worst-case link speeds of ~10Kbps [BCP48], thus 990 providing a convenient value for use in reassembly buffer timer 991 settings. Finally, the 1280 byte MTU allows transport connections 992 (e.g., TCP) to configure a large-enough maximum segment size for 993 improved performance even if the IPv4 interface that will send the 994 tunneled packets uses a smaller MTU. 996 Appendix C. Modified EUI-64 Addresses in the IANA Ethernet Address Block 998 Modified EUI-64 addresses ([ADDR], Appendix A) in the IANA Ethernet 999 Address Block are formed as the concatenation of the 24-bit IANA OUI 1000 (00-00-5E) with a 40-bit extension identifier. They have the 1001 following appearance in memory (bits transmitted right-to-left within 1002 octets, octets transmitted left-to-right): 1004 0 23 63 1005 | OUI | extension identifier | 1006 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 1008 When the first two octets of the extension identifier encode the 1009 hexadecimal value 0xFFFE, the remainder of the extension identifier 1010 encodes a 24-bit vendor-supplied id as follows: 1012 0 23 39 63 1013 | OUI | 0xFFFE | vendor-supplied id | 1014 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx 1016 When the first octet of the extension identifier encodes the 1017 hexadecimal value 0xFE, the remainder of the extension identifier 1018 encodes a 32-bit IPv4 address as follows: 1020 0 23 31 63 1021 | OUI | 0xFE | IPv4 address | 1022 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 1024 Modified EUI-64 format interface identifiers are formed by inverting 1025 the "u" bit, i.e., the "u" bit is set to one (1) to indicate 1026 universal scope and it is set to zero (0) to indicate local scope 1027 ([ADDR], section 2.5.1). 1029 Appendix D. Proposed ICMPv6 Code Field Types 1031 Three new ICMPv6 Code Field Type definitions are proposed for the 1032 ICMPv6 Destination Unreachable message. The first proposes a new 1033 definition for a currently-unassigned code type (2) in the ICMPv6 1034 Type Numbers registry; the others propose new definitions for code 1035 types (5) and (6). The code type field definition proposals appear 1036 below: 1038 Type Name Reference 1039 ---- ------------------------- --------- 1040 1 Destination Unreachable [RFC2463] 1041 Code 2 - beyond the scope of source address 1042 5 - source address failed ingress policy 1043 6 - reject route to destination 1045 Normative References 1047 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1048 Levels", BCP 14, RFC 2119, March 1997. 1050 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1051 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1053 [STD3] Braden, R., "Requirements for Internet Hosts - Communication 1054 Layers", STD 3, RFC 1122, October 1989. 1056 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 1058 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1059 1980. 1061 [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 1062 IP version 6", RFC 1981, August 1996. 1064 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1065 (IPv6) Specification", RFC 2460, December 1998. 1067 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1068 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1070 [RFC2463] Conta, A., and S. Deering, "Internet Control Message Protocol 1071 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", 1072 RFC 2463, December 1998. 1074 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1075 Domains without Explicit Tunnels", RFC 2529, March 1999. 1077 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1078 Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, 1079 November 2002. 1081 [RFC3484] Draves, R., "Default Address Selection for Internet Protocol 1082 version 6 (IPv6)", RFC 3484, February 2003. 1084 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1085 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 1086 February 2003. 1088 [RFC3542] Stevens, W., Thomas, M., Nordmark, E. and T. Jinmei, 1089 "Advanced Sockets Application Program Interface (API) for IPv6", RFC 1090 3542, May 2003. 1092 [RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site- 1093 Multihoming Architectures", RFC 3582, August 2003. 1095 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1096 Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 1098 [ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing 1099 Architecture", draft-ietf-ipv6-addr-arch-v4, Work in Progress, 1100 October 2003. 1102 [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and 1103 More-Specific Routes", draft-ietf-ipv6-router-selection, Work in 1104 Progress, December 2003. 1106 [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms 1107 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2, Work in 1108 Progress, February 2003. 1110 [NODEREQ] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node- 1111 requirements, Work in Progress, October 2003. 1113 [UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1114 Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress, 1115 January 2004. 1117 Informative References 1119 [BCP48] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to- 1120 end Performance Implications of Slow Links", BCP 48, RFC 3150, July 1121 2001. 1123 [STD13] Mockapetris, P., "Domain names - implementation and 1124 specification", STD 13, RFC 1035, November 1987. 1126 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 1127 2402, November 1998. 1129 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1130 (ESP)", RFC 2406, November 1998. 1132 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 1133 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, 1134 January 1999. 1136 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 1137 Networks", RFC 2492, January 1999. 1139 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 1140 IPv4 Clouds", RFC 3056, February 2001. 1142 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 1143 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 1144 3315, July 2003. 1146 [ANYCAST] Hagino, J. and K. Ettikan, "An Analysis of IPv6 Anycast", 1147 draft-ietf-ipngwg-ipv6-anycast-analysis, Work in Progress, June 2003. 1149 [FLOW] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, 1150 "IPv6 Flow Label Specification", draft-ietf-ipv6-flow-label, Work in 1151 Progress, December 2003. 1153 [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful", In 1154 Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications 1155 Technology. August, 1987. 1157 [FTMIB] Haberman, B. and M. Wasserman, "IP Forwarding Table MIB", 1158 draft-ietf-ipv6-rfc2096-update, Work in Progress, August 2003. 1160 [IPMIB] Routhier, S., "Management Information Base for the Internet 1161 Protocol (IP)", draft-ietf-ipv6-rfc2011-update, Work in Progress, 1162 September 2003. 1164 [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. 1166 Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt, 1167 Work in Progress, October 2003. 1169 [SENDPS] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1170 Discovery Trust Models and Threats", draft-ietf-send-psreq, Work in 1171 Progress, October 2003. 1173 [TUNMIB] Thaler, D., "IP Tunnel MIB", draft-ietf-ipv6-inet-tunnel-mib, 1174 Work in Progress, January 2004. 1176 Authors' Addresses 1178 Fred L. Templin 1179 Nokia 1180 313 Fairchild Drive 1181 Mountain View, CA 94110 1182 US 1184 Phone: +1 650 625 2331 1185 EMail: ftemplin@iprg.nokia.com 1187 Tim Gleeson 1188 Cisco Systems K.K. 1189 Shinjuku Mitsu Building 1190 2-1-1 Nishishinjuku, Shinjuku-ku 1191 Tokyo 163-0409 1192 Japan 1194 EMail: tgleeson@cisco.com 1196 Mohit Talwar 1197 Microsoft Corporation 1198 One Microsoft Way 1199 Redmond, WA 98052-6399 1200 US 1202 Phone: +1 425 705 3131 1203 EMail: mohitt@microsoft.com 1204 Dave Thaler 1205 Microsoft Corporation 1206 One Microsoft Way 1207 Redmond, WA 98052-6399 1208 US 1210 Phone: +1 425 703 8835 1211 EMail: dthaler@microsoft.com 1213 Intellectual Property Statement 1215 The IETF takes no position regarding the validity or scope of any 1216 intellectual property or other rights that might be claimed to pertain 1217 to the implementation or use of the technology described in this 1218 document or the extent to which any license under such rights 1219 might or might not be available; neither does it represent that it has 1220 made any effort to identify any such rights. Information on the IETF's 1221 procedures with respect to rights in standards-track and standards- 1222 related documentation can be found in BCP-11. Copies of claims of rights 1223 made available for publication and any assurances of licenses to be made 1224 available, or the result of an attempt made to obtain a general license 1225 or permission for the use of such proprietary rights by implementors or 1226 users of this specification can be obtained from the IETF Secretariat. 1228 The IETF invites any interested party to bring to its attention any 1229 copyrights, patents or patent applications, or other proprietary rights 1230 which may cover technology that may be required to practice this 1231 standard. Please address the information to the IETF Executive Director. 1233 The IETF has been notified of intellectual property rights claimed in 1234 regard to some or all of the specification contained in this document. 1235 For more information consult the online list of claimed rights. 1237 Full Copyright Statement 1239 Copyright (C) The Internet Society (2004). All Rights Reserved. 1241 This document and translations of it may be copied and furnished to 1242 others, and derivative works that comment on or otherwise explain it or 1243 assist in its implementation may be prepared, copied, published 1244 and distributed, in whole or in part, without restriction of any kind, 1245 provided that the above copyright notice and this paragraph are included 1246 on all such copies and derivative works. However, this document itself 1247 may not be modified in any way, such as by removing the copyright notice 1248 or references to the Internet Society or other Internet organizations, 1249 except as needed for the purpose of developing Internet standards in 1250 which case the procedures for copyrights defined in the Internet 1251 Standards process must be followed, or as required to translate it into 1252 languages other than English. 1254 The limited permissions granted above are perpetual and will not be 1255 revoked by the Internet Society or its successors or assignees. This 1256 document and the information contained herein is provided on an "AS IS" 1257 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1258 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1259 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1260 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1261 PARTICULAR PURPOSE. 1263 Acknowledgment 1265 Funding for the RFC Editor function is currently provided by the 1266 Internet Society.