idnits 2.17.1 draft-ietf-ngtrans-isatap-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1260. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1228), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 7346 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 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** 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 3315 (Obsoleted by RFC 8415) Summary: 23 errors (**), 0 flaws (~~), 4 warnings (==), 7 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-20.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 ISATAP nodes implement the addressing requirements found in 226 ([NODEREQ], section 4.5). [RFC2462][RFC3484][ADDR] MUST be supported, 227 and [RFC3041] SHOULD be supported (configurable on a per-connection 228 basis). 230 6.1 ISATAP Interface Identifiers 232 ISATAP interface identifiers are constructed in Modified EUI-64 233 format ([ADDR], appendix A). They are formed by concatenating the 234 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 235 32-bit IPv4 address in network byte order. 237 The format for ISATAP interface identifiers is given below (where 'u' 238 is the IEEE universal/local bit, 'g' is the IEEE group/individual 239 bit, and the 'm' bits represent the concatenated IPv4 address): 241 |0 1|1 3|3 4|4 6| 242 |0 5|6 1|2 7|8 3| 243 +----------------+----------------+----------------+----------------+ 244 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 245 +----------------+----------------+----------------+----------------+ 247 When the IPv4 address is known to be globally unique, the 'u' bit is 248 set to 1; otherwise, the 'u' bit is set to 0 ([ADDR], section 2.5.1). 249 See: Appendix C for additional non-normative details. 251 6.2 ISATAP Addresses 253 Any IPv6 unicast address ([ADDR], section 2.5) that contains an 254 ISATAP interface identifier constructed as specified in section 6.1 255 and an on-link prefix on an ISATAP interface is considered an ISATAP 256 address. 258 6.3 Multicast/Anycast 260 ISATAP interfaces recognize a node's required IPv6 multicast/anycast 261 addresses ([ADDR], section 2.8). 263 For IPv6 multicast addresses of interest to local applications, 264 ISATAP nodes join the corresponding Organization-Local Scope IPv4 265 multicast groups ([RFC2529], section 6) on each interface that 266 appears in an ISATAP interface's locator set (see: section 7.2). 268 IPv6 multicast addresses of interest include a node's required 269 multicast addresses, and may also include e.g, the 270 'All_DHCP_Relay_Agents_and_Servers' and 'All_DHCP_Servers' multicast 271 addresses (i.e., if the node is configured as a DHCPv6 server 272 [RFC3315][RFC3633]), etc. 274 Considerations for IPv6 anycast appear in [ANYCAST]. 276 6.4 Source/Target Link Layer Address Options 278 Source/Target Link Layer Address Options ([RFC2461], section 4.6.1) 279 for ISATAP have the following format: 281 +-------+-------+-------+-------+-------+-------+-------+--------+ 282 | Type |Length | 0 | 0 | IPv4 Address | 283 +-------+-------+-------+-------+-------+-------+-------+--------+ 285 Type: 286 1 for Source Link-layer address. 2 for Target Link-layer address. 288 Length: 289 1 (in units of 8 octets). 291 IPv4 Address: 292 A 32 bit IPv4 address, in network byte order. 294 ISATAP nodes use the specifications in ([MECH], section 3.8) that 295 pertain to sending and receiving Source/Target Link Layer Address 296 Options. 298 7. Configuration and Management Requirements 300 7.1 Network Management 302 This document defines no new MIB tables, nor extensions to any 303 existing MIB tables. Objects found in [FTMIB][IPMIB][TUNMIB] are 304 supported as described in the following subsections. 306 7.2 The ifRcvAddressTable 308 The ISATAP driver maintains ifRcvAddressTable as a bidirectional 309 association of locators with tunnel interfaces. Each locator in the 310 table includes an IPv4 address-to-interface mapping (i.e., an IPv4 311 ipAddressEntry in the node's ipAddressTable) and a list of associated 312 tunnel interfaces. Each tunnel interface in the table has a 313 tunnelIfEntry and a list of associated locators, i.e., a "locator 314 set". 316 The ISATAP driver implements the following conceptual functions to 317 manage and search the ifRcvAddressTable: 319 7.2.1 RcvTableAdd(locator, tunnel_interface) 321 Creates a bidirectional association in the ifRcvAddressTable between 322 the locator and tunnel interface, i.e., adds the locator to the 323 tunnel interface's locator set and adds the tunnel interface to the 324 locator's association list. 326 Returns success or failure. 328 7.2.2 RcvTableDel(locator, tunnel_interface) 330 Deletes ifRcvAddressTable entries according to the locator and tunnel 331 interface arguments as follows: 333 - if both arguments are NULL, garbage-collects the entire table. 335 - if both arguments are non-NULL, deletes the locator from the 336 tunnel interface's locator set and deletes the tunnel interface 337 from the locator's association list. 339 - if the locator is non-NULL and tunnel interface is NULL, deletes 340 the locator from the locator sets of all tunnel interfaces. 342 - if the locator is NULL and the tunnel interface is non-NULL, 343 deletes the tunnel interface from the association lists of all 344 locators. 346 Returns success or failure. 348 7.2.3 RcvTableLocate(packet) 350 Searches the ifRcvAddressTable to locate the correct tunnel interface 351 to decapsulate a packet. First, determines the locator that matches 352 the packet's IPv4 destination address and ifIndex for the interface 353 the packet arrived on. Next, checks each tunnel interface in the 354 locator's association list for exact matches of tunnelIfEncapsMethod 355 with the packet's encapsulation type and tunnelIfRemoteInetAddress 356 with the packet's IPv4 source address. 358 If there is no match on the packet's IPv4 source address, a tunnel 359 interface with a matching tunnelIfEncapsMethod and with 360 tunnelIfRemoteInetAddress set to 0.0.0.0 is selected. If there are 361 multiple matches, a tunnel interface with tunnelIfLocalInetAddress 362 that matches the packet's IPv4 destination address is preferred. 364 Returns a pointer to a tunnel interface if a match is found; else 365 NULL. 367 7.3 ISATAP Driver API 369 The ISATAP driver implements an API used by, e.g., the ISATAP daemon, 370 startup scripts, manual command line entry, kernel processes, etc. 371 Access MUST be restricted to privileged users and applications. 372 ISATAP nodes implement the basic and advanced APIs for IPv6 373 [RFC3493][RFC3542]. 375 7.4 ISATAP Interface Creation/Configuration 377 ISATAP interfaces are created via the tunnelIfConfigTable, which 378 results in simultaneous creation of a tunnelIfEntry and a companion 379 ipv6InterfaceEntry. Each ISATAP interface configures a locator set, 380 where each locator in the set represents an IPv4 address-to-interface 381 mapping for the same site (or, represents a mapping that is routable 382 on the global Internet). ISATAP interfaces MUST NOT configure a 383 locator set that spans multiple sites. 385 ISATAP interfaces configure the following values for objects in 386 tunnelIfEntry: 388 - tunnelIfEncapsMethod is set to an IANATunnelType for "isatap". 390 - tunnelIfLocalInetAddress is set to an IPv4 address from the 391 interface's locator set. 393 - tunnelIfRemoteInetAddress is set to 0.0.0.0 to denote wildcard 394 match for remote tunnel endpoints. 396 - other read-write objects in the tunnelIfEntry are configured as 397 for any tunnel interface. 399 ISATAP interfaces are configured as advertising IPv6 interfaces and 400 set the following values for objects in ipv6InterfaceEntry: 402 - ipv6InterfaceType is set to "tunnel". 404 - ipv6InterfacePhysicalAddress is set to an octet string of zero 405 length to indicate that this IPv6 interface does not have a 406 physical address. 408 - ipv6InterfaceForwarding and ip6Forwarding for the node are set to 409 "forwarding". 411 - other read-write objects in ipv6InterfaceEntry are configured as 412 for any IPv6 interface. 414 ISATAP interfaces create an ipv6RouterAdvertEntry and set its 415 ipv6RouterAdvertIfIndex object to the same value as 416 ipv6InterfaceIfIndex. Other objects in ipv6RouterAdvertEntry are 417 configured as for any IPv6 router. 419 7.5 Configured Tunnel Creation/Configuration 421 Configured tunnels are normally created by the ISATAP daemon in 422 dynamic response to a tunnel creation request as an ISATAP 423 interface's associated logical interface; they inherit the locator 424 set of their associated ISATAP interface. Configured tunnels set the 425 following values for objects in tunnelIfEntry: 427 - tunnelIfEncapsMethod is set to an appropriate IANATunnelType 428 value. 430 - tunnelIfLocalInetAddress is set to an IPv4 address from the 431 interface's locator set. 433 - tunnelIfRemoteInetAddress is set to an IPv4 address for the node 434 at the far end of the tunnel. 436 - other read-write objects in the tunnelIfEntry are configured as 437 for any tunnel interface. 439 Configured tunnels set values for objects in ipv6InterfaceEntry as 440 follows: 442 - ipv6InterfaceType is set to "tunnel". 444 - ipv6InterfacePhysicalAddress is set to an octet string of zero 445 length to indicate that this IPv6 interface does not have a 446 physical address. 448 - other read-write objects in ipv6InterfaceEntry are configured as 449 for any IPv6 interface. 451 7.6 Reconfigurations Due to IPv4 Address Changes 453 When an IPv4 address is removed from an interface, its corresponding 454 locator SHOULD be removed from all locator sets via 455 RcvTableDel(locator, NULL); tunnelIfEntrys that used the IPv4 address 456 as tunnelIfLocalInetAddress SHOULD also configure a different local 457 IPv4 address from their remaining locator set. 459 When a new IPv4 address is added to an IPv4 interface, the node MAY 460 add the corresponding new locator to a tunnel interface's locator set 461 via RcvTableAdd(locator, tunnel_interface), and MAY also set 462 tunnelIfLocalInetAddress for its tunnelIfEntry to the new address. 464 Methods for triggering the above changes are out of scope. 466 8. Automatic Tunneling 468 ISATAP nodes use the basic tunneling mechanisms specified in [MECH]. 469 The following additional specifications are also used: 471 8.1 Encapsulation 473 The ISATAP driver encapsulates IPv6 packets using various 474 encapsulation methods, including ip-protocol-41 (e.g., 6over4 475 [RFC2529], 6to4 [RFC3056], IPv6-in-IPv4 configured tunnels [MECH], 476 isatap, etc.), UDP [STD6] port 3544, and others. 478 Security processing (e.g., [RFC2402][RFC2406], etc.), upper layer 479 fragmentation [RFC3542] and header compression for the packet's inner 480 headers are performed prior to encapsulation. 482 8.1.1 NAT Traversal 484 Native IPv6 and/or ip-protocol-41 encapsulation provides sufficient 485 functionality to support communications between peers that reside 486 within the same site (i.e., the same enterprise network). When the 487 remote peer is in a different site, NAT traversal via UDP/IPv4 488 encapsulation MAY be necessary. 490 When an ISATAP node determines that NAT traversal is necessary to 491 reach a particular peer, it encapsulates IPv6 packets using UDP/IPv4 492 port 3544 encapsulation. This determination may come through, e.g., 493 first attempting communications via ip-protocol-41 then failing over 494 to UDP/IPv4 port 3544 encapsulation, administrative knowledge that a 495 NAT is on the path, etc. 497 8.1.2 Multicast 499 ISATAP interfaces encapsulate packets with IPv6 multicast destination 500 addresses using a mapped Organization-Local Scope IPv4 multicast 501 address ([RFC2529], section 6) as the destination address in the 502 encapsulating IPv4 header. 504 8.2 Tunnel MTU and Fragmentation 506 Encapsulated packets sent by the ISATAP driver may require host-based 507 IPv4 fragmentation in order to satisfy the 1280 byte IPv6 minimum 508 MTU, e.g., when the underlying link has a small IPv4 MTU [BCP48]. 509 While this intentional fragmentation is not considered harmful, 510 unmitigated IPv4 fragmentation caused by the network can cause poor 511 performance [FRAG]. For example, since the minimum IPv4 fragment 512 size is only 8 bytes [STD5], a single 1280 byte encapsulated packet 513 could be shredded by the network into as many as 160 IPv4 fragments 514 with obvious negative performance implications. 516 ISATAP uses the MTU and fragmentation specifications in ([MECH], 517 section 3.2) and the Maximum Reassembly Unit (MRU) specifications in 518 ([MECH], section 3.6), which provide sufficient measures for avoiding 519 excessive IPv4 fragmentation in certain controlled environments 520 (e.g., 3GPP operator networks, enterprise networks, etc). To minimize 521 IPv4 fragmentation and improve performance in general use case 522 scenarios, ISATAP nodes SHOULD add the following simple 523 instrumentation to the IPv4 reassembly cache: 525 When the initial fragment of an encapsulated packet arrives, the 526 packet's IPv4 reassembly timer is set to 1 second (i.e., the worst 527 case store-and-forward delay budget for a 1280 byte packet). If an 528 encapsulated packet's IPv4 reassembly timer expires: 530 - If enough contiguous leading bytes of the packet have arrived 531 (see: section 8.6), reassemble the packet using zero-filled or 532 heuristically-chosen replacement data bytes in place of any 533 missing fragments. (Otherwise, garbage-collect the reassembly 534 buffer and return from processing.) 536 - Mark the packet as "INCOMPLETE", and also mark it with an 537 "ACTUAL_BYTES" length that encodes the actual number of data bytes 538 in fragments that arrived. 540 - Deliver the packet to the ISATAP driver, and do not send an ICMPv4 541 "time exceeded" message [STD5]. 543 Appendix B provides informative text on the derivation of the 1280 544 byte IPv6 minimum MTU. 546 8.3 Handling ICMPv4 Errors 548 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 549 errors as link-specific information indicating that a path to a 550 neighbor may have failed ([RFC2461], section 7.3.3). 552 8.4 Link-Local Addresses 554 ISATAP interfaces use link local addresses constructed as specified 555 in section 6.1 of this document. 557 8.5 Neighbor Discovery over Tunnels 559 The specification in ([MECH], section 3.8) is used; the additional 560 specification for neighbor discovery in section 9 of this document 561 are also used. 563 8.6 Decapsulation/Filtering 565 ISATAP nodes typically arrange for the ISATAP driver to receive all 566 IPv4-encapsulated IPv6 packets that are addressed to one of the 567 node's IPv4 addresses. Examples include ip-protocol-41 (e.g., 6to4, 568 6over4, configured tunnels, isatap, etc.), UDP/IPv4 port 3544, and 569 others. The ISATAP driver uses the decapsulation and filtering 570 specifications in ([MECH], section 3.6), and processes each packet 571 according to the following steps: 573 1. Locate the correct tunnel interface to receive the packet (see: 574 section 7.2.3). If not found, silently discard the packet and 575 return from processing. 577 2. If the tunnel uses header compression, reconstitute headers. If 578 header reconstitution fails, silently discard the packet and 579 return from processing. 581 3. Verify that the packet's IPv4 source address is correct for the 582 encapsulated IPv6 source address. For packets received on a 583 configured tunnel interface, verification is exactly as specified 584 in ([MECH], section 3.6). 586 For packets received on an ISATAP interface, the IPv4 source 587 address is correct if: 589 - the IPv6 source address is an ISATAP address that embeds the 590 IPv4 source address in its interface identifier, or: 592 - the IPv6 source address is the address of an IPv6 neighbor on 593 an ISATAP interface associated with the locator that matched 594 the packet (see: section 7.2.3), or: 596 - the IPv4 source address is a member of the Potential Router 597 List (see: section 9.1). 599 If the IPv4 source address is incorrect, silently discard the 600 packet and return from processing. 602 4. Perform IPv4 ingress filtering (optional; disabled by default) 603 then decapsulate the packet but do not discard encapsulating 604 headers. If the IPv6 source address is invalid (see: [MECH], 605 section 3.6), silently discard the packet and return from 606 processing. 608 For UDP port 3544 packets received on an ISATAP interface, if the 609 IPv6 source address is an ISATAP link local address with the 'u' 610 bit set to 0 and an embedded IPv4 address that does not match the 611 IPv4 source address, rewrite the IPv6 source address to inform 612 upper layers of the sender's mapped UDP port number and IPv4 613 source address. Specific rules for rewriting the IPv6 source 614 address are established during ISATAP interface configuration. 616 5. Perform ingress filtering on the IPv6 source address (see: 617 [MECH], section 3.6). Next, determine the correct transport 618 protocol listener [FLOW] if the packet is destined to the 619 localhost; otherwise, perform an IPv6 forwarding table lookup and 620 site border/firewall filtering (see: [UNIQUE], section 6). 622 If the packet cannot be delivered, the driver SHOULD send an 623 ICMPv6 Destination Unreachable message ([RFC2463], section 3.2) 624 to the packet's source. The message SHOULD select as its source 625 address an IPv6 address from the outgoing interface (if the 626 packet was destined to the localhost) or an ingress-wise correct 627 IPv6 address from the interface that would have forwarded the 628 packet had it not been filtered. 630 The Code field of the message is set as follows: 632 - if there is no route to the destination, the Code field is set 633 to 0 (see: [RFC2463], section 3.1). 635 - if communication with the destination is administratively 636 prohibited, the Code field is set to 1 ([RFC2463], section 637 3.1). 639 - if the packet is destined to the localhost, but the transport 640 protocol has no listener, the Code field is set to 4 641 ([RFC2463], section 3.1). 643 - if the packet's destination is beyond the scope of the source 644 address, the Code field is set to 2 (see: IANA 645 Considerations). 647 - if the packet was dropped due to ingress filtering policies, 648 the Code field is set to 5 (see: IANA Considerations). 650 - if the packet is dropped due to a reject route, the Code field 651 is set to 6 (see: IANA Considerations). 653 - if the packet was received on a point-to-point link and 654 destined to an address within a subnet assigned to that same 655 link, or if the reason for the failure to deliver cannot be 656 mapped to any of the specific conditions listed above, the 657 Code field is set to 3 ([RFC2463], section 3.2). 659 After sending the ICMPv6 Destination Unreachable message, discard 660 the packet and return from processing. 662 6. If the packet is "INCOMPLETE" (see section 8.2) prepare an 663 authenticated, unsolicited Router Advertisement message 664 ([RFC2461], section 6.2.4) with an MTU option that encodes the 665 maximum of "ACTUAL_BYTES" and (68 bytes minus the size of 666 encapsulating headers.) 668 The IPv6 destination address in the Router Advertisement message 669 is set to the packet's IPv6 source address, and the message is 670 reverse-encapsulated and returned to the node that sent the 671 "INCOMPLETE" packet, i.e., it is NOT presented to the native IPv6 672 stack for transmission. 674 The 68 byte minimum MTU is due to the requirement that every 675 Internet module must be able to forward a datagram of 68 octets 676 without further fragmentation ([STD5], Internet Protocol, section 677 3.2). 679 7. Discard encapsulating headers. If the packet was destined to a 680 remote host, forward the packet and return from processing. 681 Otherwise, apply security processing (e.g., [RFC2402][RFC2406], 682 etc.), and place the packet in a buffer for upper layers. The 683 buffer may be, e.g., the IPv6 reassembly cache, an application's 684 mapped data buffer [RFC3542], etc. 686 If there is clear evidence that upper layer reassembly has 687 stalled, an ICMPv6 Packet Too Big message [RFC1981] MAY be sent 688 to the packet's source address with an MTU value likely to incur 689 successful reassembly. Some applications may realize greater 690 efficiency by accepting partial information from "INCOMPLETE" 691 packets (see: section 8.2) and requesting selective 692 retransmission of missing portions. 694 9. Neighbor Discovery for ISATAP Interfaces 696 ISATAP nodes use the neighbor discovery mechanisms specified in 697 [RFC2461] to create/change neighbor cache entries and to provide 698 control plane signaling for automatic tunnel configuration. Securing 699 mechanisms for neighbor discovery messages (e.g., [RFC2402], [SEND]) 700 are used according to the trust model appropriate for the given 701 deployment scenario [SENDPS]. ISATAP interfaces also implement the 702 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 Solicited Router Advertisements sent on ISATAP interfaces are sent 721 directly to the soliciting node, i.e., they might not be received by 722 other nodes on the link. 724 Router Advertisements sent on ISATAP interfaces MAY include 725 information delegated via DHCPv6 [RFC3633]. 727 Router Advertisements sent on ISATAP interfaces MUST NOT include a 728 prefix option containing a preferred lifetime greater than the valid 729 lifetime. 731 9.2.2 Host Specification 733 The Host Specification in ([RFC2461], section 6.3) is used. ISATAP 734 interfaces add the following specifications: 736 9.2.2.1 Host Variables 738 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 739 interfaces add: 741 PrlRefreshInterval 742 Time in seconds between successive refreshments of the PRL after 743 initialization. The designated value of all 1's (0xffffffff) 744 represents infinity. 745 Default: 3600 seconds 747 MinRouterSolicitInterval 748 Minimum time in seconds between successive solicitations of the 749 same advertising ISATAP interface. The designated value of all 1's 750 (0xffffffff) represents infinity. 752 9.2.2.2 Potential Router List Initialization 754 ISATAP nodes provision an ISATAP interface's PRL with IPv4 addresses 755 discovered via a DNS fully-qualified domain name (FQDN) [STD13], 756 manual configuration, a DHCPv4 option, a DHCPv4 vendor-specific 757 option, or an unspecified alternate method. 759 FQDNs are established via manual configuration or an unspecified 760 alternate method. FQDNs are resolved into IPv4 addresses through 761 querying the DNS service, querying a site-specific name service, 762 static host file lookup, or an unspecified alternate method. 764 When the node provisions an ISATAP interface's PRL with IPv4 765 addresses, it sets a timer for the interface (e.g., 766 PrlRefreshIntervalTimer) to PrlRefreshInterval seconds. The node re- 767 initializes the PRL as specified above when PrlRefreshIntervalTimer 768 expires, or when an asynchronous re-initialization event occurs. When 769 the node re-initializes the PRL, it resets PrlRefreshIntervalTimer to 770 PrlRefreshInterval seconds. 772 9.2.2.3 Processing Received Router Advertisements 774 To the list of checks for validating Router Advertisement messages 775 ([RFC2461], section 6.1.1), ISATAP interfaces add: 777 - IP Source Address is an ISATAP link-local address that embeds 778 V4ADDR(i) for some PRL(i). 780 Valid Router Advertisements received on an ISATAP interface are 781 processed exactly as specified in ([RFC2461], section 6.3.4). 782 [RFC3315] and [RFC3633] are stateful mechanisms associated with the M 783 and O bits. 785 For Router Advertisements that include an MTU option, the MTU value 786 does not alter the ISATAP interface LinkMTU. Instead, the MTU value 787 is recorded, e.g., in the IPv6 forwarding table. If the IPv6 788 destination address is one of the node's own unicast addresses, the 789 MTU value is recorded such that upper layer fragmentation [RFC3542] 790 will be used to reduce the size of the encapsulated packets sent via 791 the router. The recorded value is aged as for IPv6 path MTU 792 information [RFC1981]. 794 9.2.2.4 Sending Router Solicitations 796 To the list of events after which Router Solicitation messages may be 797 sent ([RFC2461], section 6.3.7), ISATAP interfaces add: 799 - TIMER(i) for some PRL(i) expires. 801 Since unsolicited Router Advertisements may be incomplete and/or 802 absent, TIMER(i) MAY be used to schedule periodic Router Solicitation 803 events for certain PRL(i)'s. 805 When used, TIMER(i) SHOULD be set such that the next Router 806 Solicitation event will refresh remaining lifetimes stored for the 807 PRL(i), including Router Lifetime, Valid Lifetimes received in Prefix 808 Information Options, and Route Lifetimes received in Route 809 Information Options [DEFLT]. TIMER(i) MUST be set to no less than 810 MinRouterSolicitInterval seconds, where MinRouterSolicitInterval is 811 configurable for the node (or, for each PRL(i)) with a conservative 812 default value. 814 When TIMER(i) expires, Router Solicitation messages are sent as 815 specified in ([RFC2461], section 6.3.7) except that the messages are 816 sent directly to PRL(i), i.e., they might not be received by other 817 nodes on the link. While the node continues to use PRL(i) as a router 818 (and, while PRL(i) continues to act as a router), the node resets 819 TIMER(i) after each expiration as described above. 821 9.3 Address Resolution and Neighbor Unreachability Detection 823 9.3.1 Address Resolution 825 The specification in ([RFC2461], section 7.2) is used. ISATAP 826 addresses for which the neighbor's link-layer address cannot 827 otherwise be determined (e.g., from a neighbor cache entry) are 828 resolved to link-layer addresses by a static computation, i.e., the 829 last four octets are treated as an IPv4 address. 831 Hosts SHOULD perform an initial reachability confirmation by sending 832 Neighbor Solicitation message(s) and receiving a Neighbor 833 Advertisement message. Routers MAY perform this initial reachability 834 confirmation, but this might not scale in all environments. 836 9.3.2 Neighbor Unreachability Detection 838 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 839 section 7.3). Routers MAY perform neighbor unreachability detection, 840 but this might not scale in all environments. 842 10. Security considerations 844 The Security Considerations in the normative references, and in 845 ([NODEREQ], section 8) apply. Also: 847 - ISATAP nodes observe the security considerations outlined in 848 [SENDPS]; use of IPsec (e.g., [RFC2402][RFC2406], etc.) is not 849 always feasible. 851 - site border routers SHOULD install a reject route for the IPv6 852 prefix FC00::/7 [UNIQUE] to insure that packets with local IPv6 853 destination addresses will not be forwarded outside of the site 854 via a default route. 856 - administrators MUST ensure that lists of IPv4 addresses 857 representing the advertising ISATAP interfaces of PRL members are 858 well maintained. 860 11. IANA Considerations 862 The IANA is instructed to specify the format for Modified EUI-64 863 address construction ([ADDR], Appendix A) in the IANA Ethernet 864 Address Block. The text in Appendix C of this document is offered as 865 an example specification. The current version of the IANA registry 866 for Ether Types can be accessed at: 867 http://www.iana.org/assignments/ethernet-numbers. 869 The IANA is instructed to assign the new ICMPv6 code field types 870 found in Appendix D of this document for the ICMPv6 Destination 871 Unreachable message. The policy for assigning new ICMPv6 code field 872 types is First Come First Served, as defined in [BCP26]. The current 873 version of the IANA registry for ICMPv6 type numbers can be accessed 874 at: 875 http://www.iana.org/assignments/icmpv6-parameters. 877 12. IAB Considerations 879 [RFC3424] ("IAB Considerations for UNilateral Self-Address Fixing 880 (UNSAF) Across Network Address Translation") section 4 requires that 881 any proposal supporting NAT traversal must explicitly address the 882 following considerations: 884 12.1 Problem Definition 886 The specific problem being solved is enabling IPv6 connectivity for 887 ISATAP nodes that are unable to communicate via ip-protocol-41 or 888 native IPv6. 890 12.2 Exit Strategy 892 ISATAP nodes use UDP/IPv4 encapsulation for NAT traversal as a last 893 resort. As soon as native IPv6 or ip-protocol-41 support becomes 894 available, ISATAP nodes will naturally cease using UDP/IPv4 895 encapsulation. 897 12.3 Brittleness 899 UDP/IPv4 encapsulation with ISATAP introduces brittleness into the 900 system in several ways: the discovery process assumes a certain 901 classification of devices based on their treatment of UDP; the 902 mappings need to be continuously refreshed, and addressing structure 903 may cause some hosts located beyond a common NAT to be unreachable 904 from each other. 906 ISATAP assumes a certain classification of devices based on their 907 treatment of UDP. There could be devices that would not fit into one 908 of these molds, and hence would be improperly classified by ISATAP. 910 The bindings allocated from the NAT need to be continuously 911 refreshed. Since the timeouts for these bindings is very 912 implementation specific, the refresh interval cannot easily be 913 determined. When the binding is not being actively used to receive 914 traffic, but to wait for an incoming message, the binding refresh 915 will needlessly consume network bandwidth. 917 12.4 Requirements for a Long Term Solution 919 The devices that implement the IPv4 NAT service should in the future 920 also become IPv6 routers. 922 13. Acknowledgments 924 The ideas in this document are not original, and the authors 925 acknowledge the original architects. Portions of this work were 926 sponsored through SRI International internal projects and government 927 contracts. Government sponsors include Monica Farah-Stapleton and 928 Russell Langan (U.S. Army CECOM ASEO), and Dr. Allen Moshfegh (U.S. 929 Office of Naval Research). SRI International sponsors include Dr. 930 Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi 931 Sastry. 933 The following are acknowledged for providing peer review input: Jim 934 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 935 Ole Troan, Vlad Yasevich. 937 The following are acknowledged for their significant contributions: 938 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 939 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka 940 Savola, Margaret Wasserman, Brian Zill. 942 The authors acknowledge the work of Quang Nguyen on "Virtual 943 Ethernet" under the guidance of Dr. Lixia Zhang that proposed very 944 similar ideas to those that appear in this document. This work was 945 first brought to the authors' attention on September 20, 2002. 947 IAB considerations are the same as for Teredo. The diagram in section 948 4 was inspired by a similar diagram in RFC 3371. 950 The following individuals are acknowledged for their helpful insights 951 on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound, 952 Ralph Droms, Alain Durand, Jun-ichiro itojun Hagino, Brian Haberman, 953 Bob Hinden, Christian Huitema, Kevin Lahey, Hakgoo Lee, Matt Mathis, 954 Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel, 955 Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave 956 Thaler, Michael Welzl, Lixia Zhang and the members of the Nokia NRC/ 957 COM Mountain View team. 959 "...and I'm one step ahead of the shoe shine, 960 Two steps away from the county line, 961 Just trying to keep my customers satisfied, 962 Satisfi-i-ied!" - Paul Simon, 1969 964 Appendix A. Major Changes 966 Major changes from earlier versions to version 17: 968 - new section on configuration/management. 970 - new appendices on IPv6 minimum MTU; IANA considerations. 972 - expanded section on MTU and fragmentation. 974 - expanded sections on encapsulation/decapsulation. 976 - specified relation to IPv6 Node Requirements. 978 - introduced distinction between control; forwarding planes. 980 - specified multicast mappings. 982 - revised neighbor discovery, address autoconfiguration, IANA 983 considerations and security considerations sections. 985 Appendix B. The IPv6 minimum MTU 987 The 1280 byte IPv6 minimum MTU was proposed by Steve Deering and 988 agreed through working group consensus in November 1997 discussions 989 on the IPv6 mailing list. The size was chosen to allow extra room for 990 link layer encapsulations without exceeding the Ethernet MTU of 1500 991 bytes, i.e., the practical physical cell size of the Internet. The 992 1280 byte MTU also provides a fixed upper bound for the size of IPv6 993 packets/fragments with a maximum store-and-forward delay budget of ~1 994 second assuming worst-case link speeds of ~10Kbps [BCP48], thus 995 providing a convenient value for use in reassembly buffer timer 996 settings. Finally, the 1280 byte MTU allows transport connections 997 (e.g., TCP) to configure a large-enough maximum segment size for 998 improved performance even if the IPv4 interface that will send the 999 tunneled packets uses a smaller MTU. 1001 Appendix C. Modified EUI-64 Addresses in the IANA Ethernet Address Block 1003 Modified EUI-64 addresses ([ADDR], Appendix A) in the IANA Ethernet 1004 Address Block are formed as the concatenation of the 24-bit IANA OUI 1005 (00-00-5E) with a 40-bit extension identifier. They have the 1006 following appearance in memory (bits transmitted right-to-left within 1007 octets, octets transmitted left-to-right): 1009 0 23 63 1010 | OUI | extension identifier | 1011 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 1013 When the first two octets of the extension identifier encode the 1014 hexadecimal value 0xFFFE, the remainder of the extension identifier 1015 encodes a 24-bit vendor-supplied id as follows: 1017 0 23 39 63 1018 | OUI | 0xFFFE | vendor-supplied id | 1019 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx 1021 When the first octet of the extension identifier encodes the 1022 hexadecimal value 0xFE, the remainder of the extension identifier 1023 encodes a 32-bit IPv4 address as follows: 1025 0 23 31 63 1026 | OUI | 0xFE | IPv4 address | 1027 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 1029 Modified EUI-64 format interface identifiers are formed by inverting 1030 the "u" bit, i.e., the "u" bit is set to one (1) to indicate 1031 universal scope and it is set to zero (0) to indicate local scope 1032 ([ADDR], section 2.5.1). 1034 Appendix D. Proposed ICMPv6 Code Field Types 1036 Three new ICMPv6 Code Field Type definitions are proposed for the 1037 ICMPv6 Destination Unreachable message. The first proposes a new 1038 definition for a currently-unassigned code type (2) in the ICMPv6 1039 Type Numbers registry; the others propose new definitions for code 1040 types (5) and (6). The code type field definition proposals appear 1041 below: 1043 Type Name Reference 1044 ---- ------------------------- --------- 1045 1 Destination Unreachable [RFC2463] 1046 Code 2 - beyond the scope of source address 1047 5 - source address failed ingress policy 1048 6 - reject route to destination 1050 Normative References 1052 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1053 Requirement Levels", BCP 14, RFC 2119, March 1997. 1055 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1056 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1058 [STD3] Braden, R., "Requirements for Internet Hosts - Communication 1059 Layers", STD 3, RFC 1122, October 1989. 1061 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1062 1981. 1064 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1065 1980. 1067 [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 1068 IP version 6", RFC 1981, August 1996. 1070 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 1071 2402, November 1998. 1073 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1074 (ESP)", RFC 2406, November 1998. 1076 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1077 (IPv6) Specification", RFC 2460, December 1998. 1079 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1080 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1082 [RFC2462] Thomson, S., and T. Narten, "IPv6 Stateless Address 1083 Autoconfiguration", RFC 2462, December 1998. 1085 [RFC2463] Conta, A., and S. Deering, "Internet Control Message Protocol 1086 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", 1087 RFC 2463, December 1998. 1089 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1090 Domains without Explicit Tunnels", RFC 2529, March 1999. 1092 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1093 Address Autoconfiguration in IPv6", RFC 3041, January, 2001. 1095 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1096 Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, 1097 November 2002. 1099 [RFC3484] Draves, R., "Default Address Selection for Internet Protocol 1100 version 6 (IPv6)", RFC 3484, February 2003. 1102 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1103 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 1104 February 2003. 1106 [RFC3542] Stevens, W., Thomas, M., Nordmark, E. and T. Jinmei, 1107 "Advanced Sockets Application Program Interface (API) for IPv6", RFC 1108 3542, May 2003. 1110 [RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site- 1111 Multihoming Architectures", RFC 3582, August 2003. 1113 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1114 Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 1116 [ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing 1117 Architecture", draft-ietf-ipv6-addr-arch-v4, Work in Progress, 1118 October 2003. 1120 [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and 1121 More-Specific Routes", draft-ietf-ipv6-router-selection, Work in 1122 Progress, December 2003. 1124 [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms 1125 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2, Work in 1126 Progress, February 2003. 1128 [NODEREQ] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node- 1129 requirements, Work in Progress, October 2003. 1131 [UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1132 Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress, 1133 January 2004. 1135 Informative References 1137 [BCP48] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End- 1138 to-end Performance Implications of Slow Links", BCP 48, RFC 3150, 1139 July 2001. 1141 [STD13] Mockapetris, P., "Domain names - implementation and 1142 specification", STD 13, RFC 1035, November 1987. 1144 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 1145 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, 1146 January 1999. 1148 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 1149 Networks", RFC 2492, January 1999. 1151 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 1152 IPv4 Clouds", RFC 3056, February 2001. 1154 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 1155 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 1156 3315, July 2003. 1158 [ANYCAST] Hagino, J. and K. Ettikan, "An Analysis of IPv6 Anycast", 1159 draft-ietf-ipngwg-ipv6-anycast-analysis, Work in Progress, June 2003. 1161 [FLOW] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, 1162 "IPv6 Flow Label Specification", draft-ietf-ipv6-flow-label, Work in 1163 Progress, December 2003. 1165 [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful", In 1166 Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications 1167 Technology. August, 1987. 1169 [FTMIB] Haberman, B. and M. Wasserman, "IP Forwarding Table MIB", 1170 draft-ietf-ipv6-rfc2096-update, Work in Progress, August 2003. 1172 [IPMIB] Routhier, S., "Management Information Base for the Internet 1173 Protocol (IP)", draft-ietf-ipv6-rfc2011-update, Work in Progress, 1174 September 2003. 1176 [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. 1177 Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt, 1178 Work in Progress, October 2003. 1180 [SENDPS] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1181 Discovery Trust Models and Threats", draft-ietf-send-psreq, Work in 1182 Progress, October 2003. 1184 [TUNMIB] Thaler, D., "IP Tunnel MIB", draft-ietf-ipv6-inet-tunnel-mib, 1185 Work in Progress, January 2004. 1187 Authors' Addresses 1189 Fred L. Templin 1190 Nokia 1191 313 Fairchild Drive 1192 Mountain View, CA 94110 1193 US 1195 Phone: +1 650 625 2331 1196 EMail: ftemplin@iprg.nokia.com 1198 Tim Gleeson 1199 Cisco Systems K.K. 1200 Shinjuku Mitsu Building 1201 2-1-1 Nishishinjuku, Shinjuku-ku 1202 Tokyo 163-0409 1203 Japan 1205 EMail: tgleeson@cisco.com 1207 Mohit Talwar 1208 Microsoft Corporation 1209 One Microsoft Way 1210 Redmond, WA 98052-6399 1211 US 1213 Phone: +1 425 705 3131 1214 EMail: mohitt@microsoft.com 1215 Dave Thaler 1216 Microsoft Corporation 1217 One Microsoft Way 1218 Redmond, WA 98052-6399 1219 US 1221 Phone: +1 425 703 8835 1222 EMail: dthaler@microsoft.com 1224 Full Copyright Statement 1226 Copyright (C) The Internet Society (2004). This document is subject to 1227 the rights, licenses and restrictions contained in BCP 78 and except as 1228 set forth therein, the authors retain all their rights. 1230 This document and the information contained herein are provided on an 1231 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1232 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1233 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1234 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1235 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1236 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1238 Intellectual Property 1240 The IETF takes no position regarding the validity or scope of any 1241 Intellectual Property Rights or other rights that might be claimed to 1242 pertain to the implementation or use of the technology described in this 1243 document or the extent to which any license under such rights might or 1244 might not be available; nor does it represent that it has made any 1245 independent effort to identify any such rights. Information on the 1246 procedures with respect to rights in RFC documents can be found in BCP 1247 78 and BCP 79. 1249 Copies of IPR disclosures made to the IETF Secretariat and any 1250 assurances of licenses to be made available, or the result of an attempt 1251 made to obtain a general license or permission for the use of such 1252 proprietary rights by implementers or users of this specification can be 1253 obtained from the IETF on-line IPR repository at 1254 http://www.ietf.org/ipr. 1256 The IETF invites any interested party to bring to its attention any 1257 copyrights, patents or patent applications, or other proprietary rights 1258 that may cover technology that may be required to implement this 1259 standard. Please address the information to the IETF at ietf- 1260 ipr@ietf.org. 1262 Acknowledgment 1264 Funding for the RFC Editor function is currently provided by the 1265 Internet Society.