idnits 2.17.1 draft-ietf-ngtrans-isatap-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 24 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '...Pv4 (for ISATAP), and MAY also support...' RFC 2119 keyword, line 121: '... MUST NOT be duplicated on native...' RFC 2119 keyword, line 194: '... SHOULD be added to the Potential Ro...' RFC 2119 keyword, line 198: '...packets sent on an ISATAP link MUST be...' RFC 2119 keyword, line 199: '...at do not satisfy this constraint MUST...' (40 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (December 13, 2002) is 7798 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 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (ref. '4') (Obsoleted by RFC 3587) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2462 (ref. '6') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 1631 (ref. '9') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 2893 (ref. '10') (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 2463 (ref. '11') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 1981 (ref. '12') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2960 (ref. '14') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '19') (Obsoleted by RFC 4941) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NGTRANS Working Group F. Templin 3 Internet-Draft Nokia 4 Expires: June 13, 2003 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 December 13, 2002 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-07.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 13, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 This document specifies an Intra-Site Automatic Tunnel Addressing 44 Protocol (ISATAP) that connects IPv6 hosts and routers within IPv4 45 sites. ISATAP is a transition mechanism that treats the site's IPv4 46 infrastructure as a Non-Broadcast Multiple Access (NBMA) link layer 47 for IPv6 with no requirement for IPv4 multicast. ISATAP enables 48 intra-site automatic IPv6-in-IPv4 tunneling whether globally assigned 49 or private IPv4 addresses are used. 51 1. Introduction 53 This document presents a simple approach that enables incremental 54 deployment of IPv6 [1] within IPv4-based [2] sites in a manner that 55 is compatible with inter-domain transition mechanisms, e.g., RFC 3056 56 (6to4) [17]. We refer to this approach as the Intra-Site Automatic 57 Tunnel Addressing Protocol, or ISATAP (pronounced: "ice-a-tap"). 58 ISATAP allows dual-stack nodes that do not share a common link with 59 an IPv6 router to automatically tunnel packets to the IPv6 next-hop 60 address through IPv4, i.e., the site's IPv4 infrastructure is treated 61 as an NBMA link layer. 63 This document specifies details for the transmission of IPv6 packets 64 over ISATAP links (i.e., automatic IPv6-in-IPv4 tunneling), including 65 a new EUI-64 based interface identifier format [3][4][5] that embeds 66 an IPv4 address. This format supports configuration of global, 67 site-local and link-local addresses as specified in RFC 2462 [6] as 68 well as simple link-layer address mapping. Simple validity checks 69 for received packets are given. Also specified in this document is 70 the operation of IPv6 Neighbor Discovery for ISATAP, as permitted for 71 NBMA links by RFC 2461 [7]. The document finally presents deployment 72 and security considerations for ISATAP. 74 2. Applicability Statement 76 ISATAP provides the following features: 78 o treats site's IPv4 infrastructure as an NBMA link layer using 79 automatic IPv6-in-IPv4 tunneling (i.e., no configured tunnel 80 state) 82 o enables incremental deployment of IPv6 hosts within IPv4 sites 83 with no aggregation scaling issues at border gateways 85 o requires no special IPv4 services within the site (e.g., 86 multicast) 88 o supports both stateless address autoconfiguration and manual 89 configuration 91 o supports networks that use non-globally unique IPv4 addresses 92 (e.g., when private address allocations [8] are used), but does 93 not allow the virtual ISATAP link to span a Network Address 94 Translator [9] 96 o compatible with other NGTRANS mechanisms (e.g., 6to4 [17]) 98 3. Terminology 100 The terminology of RFC 2460 [1] applies to this document. The 101 following additional terms are defined: 103 link: 104 same definition as [6][7]. 106 underlying link: 107 a link layer that supports IPv4 (for ISATAP), and MAY also support 108 IPv6 natively. 110 ISATAP link: 111 one or more underlying links used for tunneling. The IPv4 network 112 layer addresses of the underlying links are used as link-layer 113 addresses on the ISATAP link. 115 ISATAP interface: 116 a node's attachment to an ISATAP link. 118 ISATAP prefix: 119 a prefix used to configure an address on the ISATAP interface. 120 This prefix is administratively assigned to the ISATAP link and 121 MUST NOT be duplicated on native IPv6 links. 123 ISATAP address: 124 an IPv6 address with an ISATAP prefix and an ISATAP format 125 interface identifier constructed as specified in section 4. 127 ISATAP router: 128 an IPv6 node that has an ISATAP interface over which it forwards 129 packets not explicitly addressed to itself. 131 ISATAP host: 132 any node that has an ISATAP interface and is not an ISATAP router. 134 4. Transmission of IPv6 Packets on ISATAP Links 136 ISATAP links transmit IPv6 packets via automatic tunnels using the 137 site's IPv4 infrastructure as an NBMA link layer. IPv4 ICMP errors 138 and ARP failures may be processed as link error notifications, as 139 allowed by RFC 2461 [7]. The common tunneling mechanisms specified 140 in Section 3 of RFC 2893 [10] are used, with the following noted 141 specific considerations for ISATAP links and automatic tunnels: 143 4.1 ISATAP Interface Identifier Construction 145 IPv6 unicast addresses [3][4] include a 64-bit interface identifier 146 field in "modified EUI-64 format", based on the IEEE EUI-64 [5] 147 specification. (Modified EUI-64 format inverts the sense of the 'u/ 148 l' bit from its specification in [5], i.e., 'u/l' = 0 indicates 149 local-use.) ISATAP interface identifiers are constructed by 150 prepending the 32-bit string '00-00-5E-FE' with an IPv4 address (see 151 the following section for examples). Appendix B includes text 152 explaining the rationale for this construction rule. 154 4.2 Stateless Autoconfiguration and Link-Local Addresses 156 ISATAP addresses are unicast addresses that use ISATAP format 157 interface identifiers as follows: 159 | 64 bits | 32 bits | 32 bits | 160 +------------------------------+---------------+----------------+ 161 | link-local, site-local or | 0000:5EFE | IPv4 Address | 162 | global unicast prefix | | of ISATAP link | 163 +------------------------------+---------------+----------------+ 165 Figure 1 167 Link-local, site-local, and global ISATAP addresses can be created 168 exactly as specified in [3], (e.g., by auto-configuration [6] or 169 manual configuration). For example, the IPv6 address: 171 3FFE:1A05:510:1111:0:5EFE:8CAD:8108 173 has a prefix of '3FFE:1A05:510:1111::/64' and an ISATAP format 174 interface identifier with embedded IPv4 address: '140.173.129.8'. 175 The address is alternately written as: 177 3FFE:1A05:510:1111:0:5EFE:140.173.129.8 179 The link-local and site-local variants (respectively) are: 181 FE80::0:5EFE:140.173.129.8 182 FEC0::1111:0:5EFE:140.173.129.8 184 4.3 ISATAP Link/Interface Configuration 186 An ISATAP link consists of one or more underlying links that support 187 IPv4 for tunneling within a site. 189 ISATAP interfaces are configured over ISATAP links; each IPv4 address 190 assigned to an underlying link is seen as a link-layer address for 191 ISATAP. 193 At least one link-layer address per each ISATAP router interface 194 SHOULD be added to the Potential Routers List (see Section 5.2.1). 196 4.4 Sending Rules and Address Mapping 198 The IPv6 next-hop address for packets sent on an ISATAP link MUST be 199 an ISATAP address. Packets that do not satisfy this constraint MUST 200 be discarded and an ICMPv6 destination unreachable indication with 201 code 3 (Address Unreachable) [11] MUST be returned. No other sending 202 rules are necessary. 204 The procedure for mapping unicast addresses into link-layer addresses 205 is to simply treat the last four octets of the ISATAP address as an 206 IPv4 address (in network byte order). No multicast address mappings 207 are specified. 209 4.5 Validity Checks for Received Packets 211 Packets received on ISATAP interfaces MUST satisfy at least one 212 (i.e., one or both) of the following validity checks: 214 o the network-layer (IPv6) source address has a prefix configured on 215 the ISATAP interface and an ISATAP-format interface identifier 216 that embeds the link-layer (IPv4) source address, i.e., source is 217 on-link 219 o the link-layer (IPv4) source address is in the Potential Routers 220 List (see Section 5.2.1), i.e., previous hop is an on-link ISATAP 221 router 223 Packets that do not satisfy at least one of the above checks are 224 silently discarded. 226 4.6 Tunnel MTU and Fragmentation 228 ISATAP interfaces implement automatic tunnels that may be configured 229 over multiple underlying links with diverse MTUs. The ISATAP 230 interface MTU (ISATAP_MTU) SHOULD be no larger than the largest MTU 231 of all underlying links (LINK_MTU), minus 20 bytes for IPv4 232 encapsulation. 234 The minimum value (ISATAP_MINMTU) MUST be at least 1280 bytes [1], 235 but SHOULD be set to 1380 bytes (see note 1). The maximum value used 236 for ISATAP_MTU SHOULD be 4140 bytes (see note 2). The maximum 237 receive unit (ISATAP_MRU) MUST be at least 4400 bytes. 239 IPv6 path MTU discovery [12] is required for IPv6 interfaces that 240 send packets larger than 1280 bytes. The following considerations 241 for ISATAP interfaces are noted: 243 o ISATAP encapsulators and decapsulators are IPv6 neighbors since 244 they share a common link layer, i.e., the ISATAP link 246 o ISATAP neighbors may be separated by multiple IPv4 hops requiring 247 IPv4 path MTU discovery [13] to establish per-neighbor MTUs 248 (NBR_MTU) 250 o NBR_MTU information is stored as link-layer (IPv4) information 251 (e.g., in the IPv4 path MTU discovery cache), thus it may not be 252 visible to upper layers in all implementations 254 o NBR_MTU information may not always be available for each neighbor 255 due to finite storage limitations 257 o IPv4 path MTU discovery delivers ICMPv4 "fragmentation needed" 258 messages, but these cannot be translated into ICMPv6 "packet too 259 big" messages. Thus, encapsulated packets MUST be sent with the 260 DF flag in the IPv4 header NOT set unless additional state is 261 maintained in the encapsulator (see note 3) 263 Traditional packetization and network (IPv6) layer implementations 264 view ISATAP interfaces as ordinary IPv6 interfaces with a single MTU 265 (ISATAP_MTU). Such implementations forward only those IPv6 packets 266 of size ISATAP_MTU or smaller to the ISATAP interface. All other 267 packets are dropped, and an IPv6 ICMP "packet too big" message with 268 MTU = ISATAP_MTU is returned. 270 Modified packetization and network (IPv6) layer implementations MAY 271 look into the ISATAP link layer for per-neighbor MTU information. 272 When available, this information supersedes ISATAP_MTU in determining 273 whether to forward the packet or return an ICMPv6 "packet too big" 274 (see above). 276 For IPv6 packets forwarded to the ISATAP interface, all 277 implementations employ the following algorithm at the link layer to 278 determine when to perform IPv6-in-IPv4 encapsulation and when to 279 return an IPv6 ICMP "packet too big" message: 281 Determine per-neighbor LINK_MTU; NBR_MTU, e.g., by consulting IPv4 282 forwarding table and/or IPv4 path MTU discovery cache, then: 284 if NBR_MTU information exists 285 if packet is larger than NBR_MTU - 20 and packet 286 is larger than ISATAP_MINMTU 287 Send IPv6 ICMP "packet too big" with 288 MTU = MAX(NBR_MTU - 20, ISATAP_MINMTU) 289 Drop packet 290 else 291 Encapsulate but do not set the Don't Fragment 292 flag in the IPv4 header 293 endif 294 else 295 if packet is larger than LINK_MTU - 20 and packet is 296 larger than ISATAP_MINMTU 297 Send IPv6 ICMP "packet too big" with 298 MTU = ISATAP_MINMTU 299 Drop packet 300 else 301 if IPv6 neighbor is an IPv4 neighbor on the 302 underlying link, or packet is less than 303 or == ISATAP_MINMTU 304 Encapsulate but do not set the Don't 305 Fragment flag in the IPv4 hdr 306 else 307 send ICMPv6 "packet too big" with 308 MTU = ISATAP_MINMTU 309 Drop packet 310 endif 311 endif 312 endif 314 Figure 2 316 NOTES: 318 1. Nearly all IPv4 routers can forward 1500 byte packets without 319 fragmentation. However, sub-IPv4 layer encapsulation (e.g., for 320 VPNs) may occur on some paths. Commonly-deployed VPNs use an MTU 321 of 1400 bytes, thus 1380 bytes SHOULD be used as ISATAP_MINMTU. 323 2. TCP adapts to an overestimated MSS by reducing the segment size 324 based on IPv6 "packet too big" messages ([12], section 5.4), thus 325 setting ISATAP_MTU to the largest MTU of all underlying links 326 would optimize performance for asymmetric paths. 328 SCTP ([14], section 7.3) and other packetization layers ([12], 329 section 5.5), perform upper-layer fragmentation based on IPv6 330 "packet too big" messages, which may result in unacceptable loss 331 when the initial MTU estimate is too large. 333 4140 is the RECOMMENDED maximum value for ISATAP_MTU, since: 335 * 4140 bytes makes efficient use of common larger-than- ethernet 336 MTUs in the internet (e.g., FDDI) 338 * Locally-generated ICMPv6 "packet too big" messages are likely 339 to advertise an MTU of 1380, resulting in at most three 340 fragments and limiting loss probability 342 3. Implementations MAY cache recently-sent IPv6 packets to provide 343 state for translating ICMPv4 "fragmentation needed" messages into 344 ICMPv6 "packet too big" messages. Such implementations MAY set 345 the DF flag in the IPv4 header in the above algorithm for packets 346 that will be retained in the cache at least as long as the 347 round-trip time (RTT) between the encapsulator and decapsulator. 349 5. Neighbor Discovery for ISATAP Links 351 Section 3.2 of RFC 2461 [7] provides the following guidelines for 352 non-broadcast multiple access (NBMA) link support: 354 "Redirect, Neighbor Unreachability Detection and next-hop 355 determination should be implemented as described in this document. 356 Address resolution and the mechanism for delivering Router 357 Solicitations and Advertisements on NBMA links is not specified in 358 this document." 360 ISATAP links SHOULD implement Redirect, Neighbor Unreachability 361 Detection, and next-hop determination exactly as specified in [7]. 362 Address resolution and the mechanisms for delivering Router 363 Solicitations and Advertisements for ISATAP links are not specified 364 by [7]; instead, they are specified in this document. (Note that 365 these mechanisms MAY potentially apply to other types of NBMA links 366 in the future.) 368 5.1 Address Resolution 370 Protocol addresses (IPv6) in ISATAP are resolved to link-layer 371 addresses (IPv4) by a static computation, i.e., the last four octets 372 are treated as an IPv4 address. 374 ISATAP hosts SHOULD enhance the static address resolution computation 375 with a unicast Neighbor Solicitation(NS)/Neighbor Advertisement(NA) 376 exchange to ensure IPv6 level reachability of the neighbor and also 377 SHOULD perform Neighbor Unreachability Detection (NUD) as specified 378 in (RFC 2461 [7], section 7.3). ISATAP routers MAY implement the 379 enhanced address resolution and NUD, but this might not scale in all 380 environments. All ISATAP nodes MUST send solicited neighbor 381 advertisements ([7], section 7.2.4). 383 Link-layer address options ([7], section 4.6.1) for this 384 specification MUST have Length = 1 and a six-octet interface 385 identifier consisting of two zero octets followed by a four-octet 386 IPv4 address. Options of this form SHOULD NOT be sent in NS/NA 387 messages and MUST be silently ignored in received NS/NA messages. 389 5.2 Router and Prefix Discovery 391 Since the site's IPv4 infrastructure is treated as an NBMA link 392 layer, unsolicited Router Advertisements do not provide sufficient 393 means for router discovery on ISATAP links. Thus, alternate 394 mechanisms are required and specified below: 396 5.2.1 Conceptual Data Structures 398 ISATAP nodes use the conceptual data structures Prefix List and 399 Default Router List exactly as in ([7], section 5.1). ISATAP links 400 add a new conceptual data structure "Potential Router List" and the 401 following new configuration variable: 403 ResolveInterval 404 Time between name service resolutions. Default and suggested 405 minimum: 1hr 407 A Potential Router List (PRL) is associated with every ISATAP link. 408 The PRL provides a trust basis for router validation (see security 409 considerations). Each entry in the PRL has an IPv4 address and an 410 associated timer. The IPv4 address represents a router's ISATAP 411 interface (likely to be an "advertising interface"), and is used to 412 construct the ISATAP link-local address for that interface. The 413 following sections specify the process for initializing the PRL: 415 When a node enables an ISATAP link, it first discovers a DNS (RFC 416 1035 [20]) fully-qualified domain name for the site's ISATAP service. 417 The domain name MAY be established by a DHCPv4 [15] option for ISATAP 418 (option code TBD, see IANA Considerations), by manual configuration, 419 or by an unspecified alternative method. The DHCPv4 option for 420 ISATAP is implemented exactly as in RFC 3361 [16] with the following 421 noted exceptions: 423 o the DHCP option code for ISATAP (TBD) is used 425 o the encoding byte MUST be 0, i.e.; only FQDNs are accepted 427 o if multiple domain names occur, only the first is used 429 Next, the node initializes the link's PRL with IPv4 addresses 430 associated with the domain name discovered above. IPv4 addresses are 431 discovered through manual config or by querying the name service to 432 resolving the domain name into address records (e.g., DNS 'A' 433 resource records) containing IPv4 addresses. Unspecified alternative 434 methods may also be used. 436 Notes: 438 1. Site administrators maintain a domain name for the ISATAP service 439 and a list of IPv4 addresses representing ISATAP router 440 interfaces (normally as address records in the site's name 441 service). Administrators may also advertise the domain name in a 442 DHCPv4 option for ISATAP. 444 2. There are no mandatory rules for the selection of a domain name, 445 but administrators are encouraged to use the convention 446 "isatap.domainname" (e.g., isatap.example.com). 448 3. After initialization, nodes periodically re-initialize the PRL 449 (after ResolveInterval). When DNS is used, nodes MUST follow the 450 cache invalidation procedures in [20] when the DNS time-to-live 451 expires. 453 5.2.2 Validity Checks for Router Advertisements 455 A node MUST silently discard any Router Advertisement messages it 456 receives that do not satisfy both the validity checks in ([7], 457 section 6.1.2) and the following additional validity check for 458 ISATAP: 460 o the network-layer (IPv6) source address is an ISATAP address and 461 embeds an IPv4 address from the PRL 463 5.2.3 Router Specification 465 Advertising ISATAP interfaces of routers behave the same as 466 advertising interfaces described in ([7], section 6.2). However, 467 periodic unsolicited multicast Router Advertisements are not 468 required, thus the "interval timer" associated with advertising 469 interfaces is not used for that purpose. 471 When an ISATAP router receives a valid Router Solicitation on an 472 advertising ISATAP interface, it replies with a unicast Router 473 Advertisement to the address of the node which sent the Router 474 Solicitation. The source address of the Router Advertisement is a 475 link-local unicast address associated with the interface. This MAY 476 be the same as the destination address of the Router Solicitation. 477 ISATAP routers MAY engage in the solicitation process described under 478 Host Specification below, e.g., if Router Advertisement consistency 479 verification ([7], section 6.2.7) is desired. 481 5.2.4 Host Specification 483 All entries in the PRL are assumed to represent active ISATAP routers 484 within the site, i.e., the PRL provides trust basis only; not 485 reachability detection. Hosts periodically solicit information from 486 one or more entries in the PRL ("PRL(i)") by sending unicast Router 487 Solicitation messages using the IPv4 address ("V4ADDR_PRL(i)") and 488 associated timer in the entry. Hosts add the following variable to 489 support the solicitation process: 491 MinRouterSolicitInterval 492 Minimum time between sending Router Solicitations to any router. 493 Default and suggested minimum: 15min 495 When a PRL(i) is selected, the host sets its associated timer to 496 MinRouterSolicitInterval and initiates solicitation following a short 497 delay as in ([7], section 6.3.7). The solicitation process repeats 498 when the associated timer expires. 500 Solicitation consists of sending Router Solicitations to the ISATAP 501 link-local address constructed from the entry's IPv4 address, i.e., 502 they are sent to 'FE80::0:5EFE:V4ADDR_PRL(i)' instead of 'All-Routers 503 multicast'. They are otherwise sent exactly as in ([7], section 504 6.3.7). 506 Hosts process received Router Advertisements exactly as in ([7], 507 section 6.3.4). Hosts additionally reset the timer associated with 508 the V4ADDR_PRL(i) embedded in the network-layer source address in 509 each received Router Advertisement. The timer is reset to either 0.5 510 * (the minimum value in the router lifetime or valid lifetime of any 511 on-link prefixes advertised) or MinRouterSolicitInterval; whichever 512 is longer. 514 ([7], section 6.3.4) includes the following specification: 516 "To limit the storage needed for the Default Router List, a host 517 MAY choose not to store all of the router addresses discovered via 518 advertisements. However, a host MUST retain at least two 519 addresses and SHOULD retain more." 521 The router solicitation process for ISATAP nodes is analogous to 522 choosing which router addresses to store as in the above text. 523 ISATAP nodes may wish to consider the control traffic overhead of 524 this process when choosing how many routers to solict. The manner of 525 choosing particular routers in the PRL for solicitation is outside 526 the scope of this specification. 528 6. ISATAP Deployment Considerations 530 6.1 Host And Router Deployment Considerations 532 For hosts, if an underlying link supports both IPv4 (over which 533 ISATAP is implemented) and also supports IPv6 natively, then ISATAP 534 MAY be enabled if the native IPv6 layer does not receive Router 535 Advertisements (i.e., does not have connection with an IPv6 router). 536 After a non-link-local address has been configured and a default 537 router acquired on the native link, the host SHOULD discontinue the 538 router solicitation process described in the host specification and 539 allow existing ISATAP address configurations to expire as specified 540 in ([7], section 5.3) and ([6], section 5.5.4). Any ISATAP addresses 541 added to the DNS for this host should also be removed. In this way, 542 ISATAP use will gradually diminish as IPv6 routers are widely 543 deployed throughout the site. 545 Routers MAY configure an interface to simultaneously support both 546 native IPv6, and also ISATAP (over IPv4). Routing will operate as 547 usual between these two domains. Note that the prefixes used on the 548 ISATAP and native IPv6 interfaces will be distinct. The IPv4 549 address(es) configured on a router's ISATAP interface(s) SHOULD be 550 added (either automatically or manually) to the site's address 551 records for ISATAP router interfaces. 553 6.2 Site Administration Considerations 555 The following considerations are noted for sites that deploy ISATAP: 557 o ISATAP links are administratively defined by a set of router 558 interfaces, and set of nodes which have those interface addresses 559 in their potential router lists. Thus, ISATAP links are defined 560 by administrative (not physical) boundaries. 562 o ISATAP hosts and routers can be deployed in an ad-hoc and 563 independent fashion. In particular, ISATAP hosts can be deployed 564 with little/no advanced knowledge of existing ISATAP routers, and 565 ISATAP routers can deployed with no reconfiguration requirements 566 for hosts. 568 o ISATAP nodes periodically send Router Solicitations (RS) to one or 569 more members of the potential router list. When Router 570 Advertisements (RAs) are received, the Router Lifetime value 571 provides a timer for the next RS to be sent. Worst-case is for 572 small values of Router Lifetime which is bounded by 573 MinRouterSolicitInterval. 575 o ISATAP nodes periodically refresh the entries on the PRL, 576 typically by querying the DNS. Responsible site administration 577 can reduce the control traffic. At a minimum, administrators 578 SHOULD ensure that the site's address records for ISATAP router 579 interfaces are well maintained. 581 7. IANA Considerations 583 A DHCPv4 option assignment for ISATAP is requested, as outlined in 584 the procedures found in RFC 2939 [21], section 3. 586 Appendix B proposes a specification for managing the IEEE OUI 587 assigned to IANA for EUI-64 interface identifier construction. This 588 specification is made freely available to IANA for any purpose they 589 may find useful. 591 8. Security considerations 593 Site administrators are advised that, in addition to possible attacks 594 against IPv6, security attacks against IPv4 MUST also be considered. 595 Many security considerations in RFC 2529 [18], section 9 apply also 596 to ISATAP. 598 Responsible IPv4 site security management is strongly encouraged. In 599 particular, border gateways SHOULD implement filtering to detect 600 spoofed IPv4 source addresses at a minimum; ip-protocol-41 filtering 601 SHOULD also be implemented. 603 If IPv4 source address filtering is not correctly implemented, the 604 ISATAP validity checks will not be effective in preventing IPv6 605 source address spoofing. 607 If filtering for ip-protocol-41 is not correctly implemented, IPv6 608 source address spoofing is clearly possible, but this can be 609 eliminated if both IPv4 source address filtering, and the ISATAP 610 validity checks are implemented. 612 (RFC 2461 [7]), section 6.1.2 implies that nodes trust Router 613 Advertisements they receive from on-link routers, as indicated by a 614 value of 255 in the IPv6 'hop-limit' field. Since this field is not 615 decremented when ip-protocol-41 packets traverse multiple IPv4 hops 616 ([10], section 3), ISATAP links require a different trust model. In 617 particular, ONLY those Router Advertisements received from a member 618 of the Potential Routers List are trusted; all others are silently 619 discarded. This trust model is predicated on IPv4 source address 620 filtering, as described above. 622 The ISATAP address format does not support privacy extensions for 623 stateless address autoconfiguration [19]. However, since the ISATAP 624 interface identifier is derived from the node's IPv4 address, ISATAP 625 addresses do not have the same level of privacy concerns as IPv6 626 addresses that use an interface identifier derived from the MAC 627 address. (This issue is the same for NAT'd addresses.) 629 9. Acknowledgements 631 Some of the ideas presented in this draft were derived from work at 632 SRI with internal funds and contractual support. Government sponsors 633 who supported the work include Monica Farah-Stapleton and Russell 634 Langan from U.S. Army CECOM ASEO, and Dr. Allen Moshfegh from U.S. 635 Office of Naval Research. Within SRI, Dr. Mike Frankel, J. Peter 636 Marcotullio, Lou Rodriguez, and Dr. Ambatipudi Sastry supported the 637 work and helped foster early interest. 639 The following peer reviewers are acknowledged for taking the time to 640 review a pre-release of this document and provide input: Jim Bound, 641 Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, Ole 642 Troan, Vlad Yasevich. 644 The authors acknowledge members of the NGTRANS community who have 645 made significant contributions to this effort, including Rich Draves, 646 Alain Durand, Nathan Lutchansky, Karen Nielsen, Art Shelest, Margaret 647 Wasserman, and Brian Zill. 649 The authors also wish to acknowledge the work of Quang Nguyen [22] 650 under the guidance of Dr. Lixia Zhang that proposed very similar 651 ideas to those that appear in this document. This work was first 652 brought to the authors' attention on September 20, 2002. 654 Normative References 656 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 657 Specification", RFC 2460, December 1998. 659 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 660 1981. 662 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 663 Architecture", RFC 2373, July 1998. 665 [4] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast 666 Address Format", RFC 2374, July 1998. 668 [5] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ 669 EUI64.html", March 1997. 671 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 672 Autoconfiguration", RFC 2462, December 1998. 674 [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 675 for IP Version 6 (IPv6)", RFC 2461, December 1998. 677 [8] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 678 Lear, "Address Allocation for Private Internets", BCP 5, RFC 679 1918, February 1996. 681 [9] Egevang, K. and P. Francis, "The IP Network Address Translator 682 (NAT)", RFC 1631, May 1994. 684 [10] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 685 Hosts and Routers", RFC 2893, August 2000. 687 [11] Conta, A. and S. Deering, "Internet Control Message Protocol 688 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 689 Specification", RFC 2463, December 1998. 691 [12] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 692 IP version 6", RFC 1981, August 1996. 694 [13] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 695 November 1990. 697 [14] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 698 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 699 "Stream Control Transmission Protocol", RFC 2960, October 2000. 701 [15] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 702 March 1997. 704 [16] Schulzrinne, H., "Dynamic Host Configuration Protocol 705 (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) 706 Servers", RFC 3361, August 2002. 708 Informative References 710 [17] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 711 IPv4 Clouds", RFC 3056, February 2001. 713 [18] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 714 Domains without Explicit Tunnels", RFC 2529, March 1999. 716 [19] Narten, T. and R. Draves, "Privacy Extensions for Stateless 717 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 719 [20] Mockapetris, P., "Domain names - implementation and 720 specification", STD 13, RFC 1035, November 1987. 722 [21] Droms, R., "Procedures and IANA Guidelines for Definition of 723 New DHCP Options and Message Types", BCP 43, RFC 2939, 724 September 2000. 726 [22] Nguyen, Q., "http://irl.cs.ucla.edu/vet/report.ps", spring 727 1998. 729 Authors' Addresses 731 Fred L. Templin 732 Nokia 733 313 Fairchild Drive 734 Mountain View, CA 94110 735 US 737 Phone: +1 650 625 2331 738 EMail: ftemplin@iprg.nokia.com 740 Tim Gleeson 741 Cisco Systems K.K. 742 Shinjuku Mitsu Building 743 2-1-1 Nishishinjuku, Shinjuku-ku 744 Tokyo 163-0409 745 Japan 747 EMail: tgleeson@cisco.com 748 Mohit Talwar 749 Microsoft Corporation 750 One Microsoft Way 751 Redmond, WA> 98052-6399 752 US 754 Phone: +1 425 705 3131 755 EMail: mohitt@microsoft.com 757 Dave Thaler 758 Microsoft Corporation 759 One Microsoft Way 760 Redmond, WA 98052-6399 761 US 763 Phone: +1 425 703 8835 764 EMail: dthaler@microsoft.com 766 Appendix A. Major Changes 768 changes from version 06 to version 07: 770 o clarified address resolution, Neighbor Unreachability Detection 772 o specified MTU/MRU requirements 774 changes from version 05 to version 06: 776 o Addressed operational issues identified in 05 based on discussion 777 between co-authors 779 o Clarified ambiguous text per comments from Hannu Flinck; Jason 780 Goldschmidt 782 changes from version 04 to version 05: 784 o Moved historical text in section 4.1 to Appendix B in response to 785 comments from Pekka Savola 787 o Identified operational issues for anticipated deployment scenarios 789 o Included SRI IPR statement and contact information 791 o Included reference to Quang Nguyen work 793 changes from version 03 to version 04: 795 o Re-wrote section on Potential Router List initialization to 796 reference existing precedence in other documents 798 o several minor wording changes based on feedback from the community 800 changes from version 02 to version 03: 802 o Added contributing co-authors 804 o RSs are now sent to unicast addresses rather than 805 all-routers-multicast 807 o Brought draft into better alignment with other IPv6 808 standards-track documents 810 o Added applicability statement 812 changes from version 01 to version 02: 814 o Cleaned up text and tightened up terminology 816 o Changed "IPv6 destination address" to "IPv6 next-hop address" 817 under "sending rules" 819 o Changed definition of ISATAP prefix to include link and site-local 821 o Changed language in sections 4 and 5 823 changes from version 00 to version 01: 825 o Revised draft to require different /64 prefixes for ISATAP 826 addresses and native IPv6 addresses. Thus, a node's ISATAP 827 interface is assigned a /64 prefix that is distinct from the 828 prefixes assigned to any other interfaces attached to the node - 829 be they physical or logical interfaces. This approach eliminates 830 ISATAP-specific sending rules presented in earlier draft versions. 832 o Changed sense of 'u/l' bit in the ISATAP address interface 833 identifier to indicate "local scope", since ISATAP interface 834 identifiers are unique only within the scope of the ISATAP prefix. 835 (See section 4.) 837 changes from personal draft to version 00: 839 o Title change to provide higher-level description of field of use 840 addressed by this draft. Removed other extraneous text. 842 o Major new section on automatic discovery of off-link IPv6 routers 843 when IPv6-IPv4 compatibility addresses are used. 845 Appendix B. Rationale for Interface Identifier Construction Rules 847 ISATAP specifies an EUI64-format address construction for the 848 Organizationally-Unique Identifier (OUI) owned by the Internet 849 Assigned Numbers Authority (IANA). This format (given below) is used 850 to construct both native EUI64 addresses for general use and modified 851 EUI-64 format interface identifiers for use in IPv6 unicast 852 addresses: 854 |0 2|2 3|3 3|4 6| 855 |0 3|4 1|2 9|0 3| 856 +------------------------+--------+--------+------------------------+ 857 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 858 +------------------------+--------+--------+------------------------+ 860 Where the fields are: 862 OUI IANA's OUI: 00-00-5E with 'u' and 'g' bits (3 octets) 864 TYPE Type field; specifies interpretation of (TSE, TSD) (1 octet) 866 TSE Type-Specific Extension (1 octet) 868 TSD Type-Specific Data (3 octets) 870 And the following interpretations are specified based on TYPE: 872 TYPE (TSE, TSD) Interpretation 873 ---- ------------------------- 874 0x00-0xFD RESERVED for future IANA use 875 0xFE (TSE, TSD) together contain an embedded IPv4 address 876 0xFF TSD is interpreted based on TSE as follows: 878 TSE TSD Interpretation 879 --- ------------------ 880 0x00-0xFD RESERVED for future IANA use 881 0xFE TSD contains 24-bit EUI-48 intf id 882 0xFF RESERVED by IEEE/RAC 884 Figure 3 886 Thus, if TYPE=0xFE, TSE is an extension of TSD. If TYPE=0xFF, TSE is 887 an extension of TYPE. Other values for TYPE (thus, other 888 interpretations of TSE, TSD) are reserved for future IANA use. 890 The above specification is compatible with all aspects of EUI64, 891 including support for encapsulating legacy EUI-48 interface 892 identifiers (e.g., an IANA EUI-48 format multicast address such as: 894 '01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03'). 895 But, the specification also provides a special TYPE (0xFE) to 896 indicate an IPv4 address is embedded. Thus, when the first four 897 octets of an IPv6 interface identifier are: '00-00-5E-FE' (note: the 898 'u/l' bit MUST be 0) the interface identifier is said to be in 899 "ISATAP format" and the next four octets embed an IPv4 address 900 encoded in network byte order. 902 Appendix C. INTELLECTUAL PROPERTY 904 SRI International has notified the IETF of IPR considerations for 905 some aspects of this specification. For more information consult the 906 online list of claimed rights. 908 Intellectual Property Statement 910 The IETF takes no position regarding the validity or scope of any 911 intellectual property or other rights that might be claimed to 912 pertain to the implementation or use of the technology described in 913 this document or the extent to which any license under such rights 914 might or might not be available; neither does it represent that it 915 has made any effort to identify any such rights. Information on the 916 IETF's procedures with respect to rights in standards-track and 917 standards-related documentation can be found in BCP-11. Copies of 918 claims of rights made available for publication and any assurances of 919 licenses to be made available, or the result of an attempt made to 920 obtain a general license or permission for the use of such 921 proprietary rights by implementors or users of this specification can 922 be obtained from the IETF Secretariat. 924 The IETF invites any interested party to bring to its attention any 925 copyrights, patents or patent applications, or other proprietary 926 rights which may cover technology that may be required to practice 927 this standard. Please address the information to the IETF Executive 928 Director. 930 Full Copyright Statement 932 Copyright (C) The Internet Society (2002). All Rights Reserved. 934 This document and translations of it may be copied and furnished to 935 others, and derivative works that comment on or otherwise explain it 936 or assist in its implementation may be prepared, copied, published 937 and distributed, in whole or in part, without restriction of any 938 kind, provided that the above copyright notice and this paragraph are 939 included on all such copies and derivative works. However, this 940 document itself may not be modified in any way, such as by removing 941 the copyright notice or references to the Internet Society or other 942 Internet organizations, except as needed for the purpose of 943 developing Internet standards in which case the procedures for 944 copyrights defined in the Internet Standards process must be 945 followed, or as required to translate it into languages other than 946 English. 948 The limited permissions granted above are perpetual and will not be 949 revoked by the Internet Society or its successors or assignees. 951 This document and the information contained herein is provided on an 952 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 953 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 954 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 955 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 956 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 958 Acknowledgement 960 Funding for the RFC Editor function is currently provided by the 961 Internet Society.