idnits 2.17.1 draft-ietf-ngtrans-isatap-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 24, 2003) is 7734 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) -- Looks like a reference, but probably isn't: 'NTL' on line 192 -- Looks like a reference, but probably isn't: 'STL' on line 192 ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '4') (Obsoleted by RFC 4861) -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch-v3 is -10, but you're referring to -11. -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2463 (ref. '8') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2462 (ref. '9') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. '13') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-04) exists of draft-ietf-itrace-03 == Outdated reference: A later version (-04) exists of draft-ietf-send-psreq-01 -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '22') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 1981 (ref. '29') (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '30') (Obsoleted by RFC 7323) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 10 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: July 25, 2003 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 January 24, 2003 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-12.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 July 25, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). 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 treats the site's IPv4 infrastructure as a link layer 46 for IPv6 with no requirement for IPv4 multicast. ISATAP enables 47 intra-site automatic IPv6-in-IPv4 tunneling whether globally assigned 48 or private IPv4 addresses are used. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Basic IPv6 Operation . . . . . . . . . . . . . . . . . . . . . 4 57 6. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 5 58 7. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 7 59 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 10. Security considerations . . . . . . . . . . . . . . . . . . . 11 62 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 63 Normative References . . . . . . . . . . . . . . . . . . . . . 12 64 Informative References . . . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 66 A. Major Changes . . . . . . . . . . . . . . . . . . . . . . . . 16 67 B. Rationale for Interface Identifier Construction . . . . . . . 17 68 C. ISATAP Interface MTU Considerations . . . . . . . . . . . . . 18 69 Intellectual Property and Copyright Statements . . . . . . . . 23 71 1. Introduction 73 This document presents a simple approach called the Intra-Site 74 Automatic Tunnel Addressing Protocol (ISATAP) that enables 75 incremental deployment of IPv6 [1] within IPv4 [2] sites. ISATAP 76 allows dual-stack nodes that do not share a physical link with an 77 IPv6 router to automatically tunnel packets to the IPv6 next-hop 78 address through IPv4, i.e., the site's IPv4 infrastructure is treated 79 as a link layer for IPv6. 81 Specific details for the operation of IPv6 and automatic tunneling 82 over ISATAP links are given, including an interface identifier format 83 that embeds an IPv4 address. This format supports IPv6 address 84 configuration and simple link-layer address mapping. Also specified 85 is the operation of IPv6 Neighbor Discovery and deployment/security 86 considerations. 88 2. Applicability Statement 90 ISATAP provides the following features: 92 o treats site's IPv4 infrastructure as a link layer for IPv6 using 93 automatic IPv6-in-IPv4 tunneling 95 o enables incremental deployment of IPv6 hosts within IPv4 sites 96 with no aggregation scaling issues at border gateways 98 o requires no special IPv4 services within the site (e.g., 99 multicast) 101 o supports both stateless address autoconfiguration and manual 102 configuration 104 o supports networks that use non-globally unique IPv4 addresses 105 (e.g., when private address allocations [10] are used) 107 o compatible with other NGTRANS mechanisms (e.g., 6to4 [11]) 109 3. Requirements 111 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 112 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 113 document, are to be interpreted as described in [3]. 115 This document also makes use of internal conceptual variables to 116 describe protocol behavior and external variables that an 117 implementation must allow system administrators to change. The 118 specific variable names, how their values change, and how their 119 settings influence protocol behavior are provided to demonstrate 120 protocol behavior. An implementation is not required to have them in 121 the exact form described here, so long as its external behavior is 122 consistent with that described in this document. 124 4. Terminology 126 The terminology of RFC 2460 [1] applies to this document. The 127 following additional terms are defined: 129 link, on-link, off-link: 130 same definitions as ([4], section 2.1). 132 underlying link: 133 a link layer that supports IPv4 (for ISATAP), and MAY also support 134 IPv6 natively. 136 ISATAP link: 137 one or more underlying links used for tunneling. The IPv4 network 138 layer addresses of the underlying links are used as link-layer 139 addresses on the ISATAP link. 141 ISATAP interface: 142 a node's attachment to an ISATAP link. 144 advertising ISATAP interface: 145 same meaning as "advertising interface" in ([4], section 6.2.2). 147 ISATAP address: 148 an on-link address on an ISATAP interface and with an interface 149 identifier constructed as specified in Section 5.1 151 5. Basic IPv6 Operation 153 ISATAP links transmit IPv6 packets via automatic tunnels using the 154 site's IPv4 infrastructure as a link layer for IPv6, i.e., IPv6 155 treats the site's IPv4 infrastructure as a Non-Broadcast, Multiple 156 Access (NBMA) link layer. The following considerations for IPv6 on 157 ISATAP links are noted: 159 5.1 Interface Identifiers and Unicast Addresses 161 ISATAP interface identifiers use "modified EUI-64" format ([5], 162 section 2.5.1) and are formed by appending an IPv4 address on the 163 ISATAP link to the 32-bit string '00-00-5E-FE'. Appendix B includes 164 non-normative rationale for this construction rule. 166 With reference to ([5], sections 2.5.4, 2.5.6), global and local-use 167 ISATAP addresses are constructed as follows: 169 | 64 bits | 32 bits | 32 bits | 170 +------------------------------+---------------+----------------+ 171 | global or local-use unicast | 0000:5EFE | IPv4 Address | 172 | prefix | | of ISATAP link | 173 +------------------------------+---------------+----------------+ 175 5.2 ISATAP Link/Interface Configuration 177 ISATAP links consist of one or more underlying links that support 178 IPv4 for tunneling within a site. 180 ISATAP interfaces are configured over ISATAP links; each IPv4 address 181 assigned to an underlying link is seen as a link-layer address for 182 ISATAP. 184 Neighbor discovery on ISATAP links (see: Section 7) provides the 185 functional equivalent of unicast virtual circuits (VCs) required for 186 other NBMA media types ([6], section 4.6). Neighbor state 187 information MAY be kept in the Conceptual Neighbor Cache ([4], 188 section 5.1). 190 5.3 Link Layer Address Options 192 With reference to ([6], section 5.2), when the [NTL] and [STL] fields 193 in an ISATAP link layer address option encode 0, the [NBMA Number] 194 field encodes a 4-octet IPv4 address. 196 5.4 Multicast and Anycast 198 ISATAP interfaces recognize a node's required addresses as specified 199 in ([5], section 2.8). 201 Mechanisms for multicast/anycast emulation on ISATAP links (e.g., 202 adaptations of MLD [12], PIM-SM [13], MARS [14], etc.) are subject 203 for future companion document(s). 205 6. Automatic Tunneling 207 The common tunneling mechanisms specified in ([7], sections 2 and 3) 208 are used, with the following noted considerations for ISATAP: 210 6.1 Dual IP Layer Operation 212 ISATAP uses the same specification found in ([7], section 2). That 213 is, ISATAP nodes provide complete IPv4 and IPv6 implementations and 214 are able to send and receive both IPv4 and IPv6 packets. 216 Address configuration and DNS considerations are the same as ([7], 217 sections 2.1 through 2.3). 219 6.2 Encapsulation/Decapsulation 221 The specifications in ([7], sections 3.1 and 3.6) are used. 222 Additionally, the IPv6 next-hop address for packets encapsulated on 223 an ISATAP link MUST be an ISATAP address; other packets are discarded 224 and an ICMPv6 destination unreachable indication with code 3 (Address 225 Unreachable) ([8], section 3.1) is returned to the source. 227 6.3 Tunnel MTU and Fragmentation 229 ISATAP automatic tunnel interfaces may be configured over multiple 230 underlying links with diverse maximum transmission units (MTUs). The 231 minimum MTU for IPv6 interfaces is 1280 bytes ([1], Section 5), but 232 the following considerations apply for ISATAP interfaces: 234 o Nearly all IPv4 nodes connect to physical links with MTUs of 1500 235 bytes or larger (e.g., Ethernet) 237 o Sub-IPv4 layer encapsulations (e.g., VPN) may occur on some paths 239 o Commonly-deployed VPN interfaces use an MTU of 1400 bytes 241 To maximize efficiency and minimize IPv4 fragmentation for the 242 predominant deployment case, the ISATAP interface MTU, or "LinkMTU" 243 (see: [4], Section 6.3.2 ), SHOULD be set to no more than 1380 bytes 244 (1400 minus 20 bytes for IPv4 encapsulation). LinkMTU MAY be set to 245 larger values when a dynamic link layer MTU discovery mechanism is 246 used or when a static MTU assignment is used and additional 247 fragmentation in the site's IPv4 network is deemed acceptable. See 248 Appendix C for non-normative ISATAP interface MTU considerations. 250 When a dynamic MTU discovery mechanism is not used, the ISATAP link 251 layer encapsulates IPv6 packets with the Don't Fragment (DF) bit not 252 set in the encapsualting IPv4 header. 254 6.4 Handling IPv4 ICMP Errors 256 IPv4 ICMP errors and ARP failures are processed as link error 257 notifications. 259 6.5 Local-Use IPv6 Unicast Addresses 260 The specification in ([7], section 3.7) is not used. Instead, local 261 use IPv6 unicast addresses are formed as specified in Section 5.1. 263 6.6 Ingress Filtering 265 The specification in ([7], section 3.9) is used. In particular, 266 ISATAP nodes that forward decapsulated packets MUST verify the tunnel 267 source address is acceptable. 269 7. Neighbor Discovery 271 The specification in ([7], section 3.8) applies only to configured 272 tunnels. RFC 2461 [4] provides the following guidelines for 273 non-broadcast multiple access (NBMA) link support: 275 "Redirect, Neighbor Unreachability Detection and next-hop 276 determination should be implemented as described in this document. 277 Address resolution and the mechanism for delivering Router 278 Solicitations and Advertisements on NBMA links is not specified in 279 this document." 281 ISATAP links SHOULD implement Redirect, Neighbor Unreachability 282 Detection, and next-hop determination exactly as specified in [4]. 283 Address resolution and the mechanisms for delivering Router 284 Solicitations and Advertisements for ISATAP links are not specified 285 by [4]; instead, they are specified in the following sections of this 286 document. 288 7.1 Address Resolution and Neighbor Unreachability Detection 290 ISATAP addresses are resolved to link-layer addresses (IPv4) by a 291 static computation, i.e., the last four octets are treated as an IPv4 292 address. 294 Following static address resolution, hosts SHOULD perform an initial 295 reachability confirmation by sending Neighbor Solicitation (NS) 296 message(s) and receiving a Neighbor Advertisement (NA) message using 297 the mechanisms specified in ([4], section 7.2.). When the ISATAP 298 interface provides a multicast emulation mechanism (see: Section 5.4) 299 solicitations are sent to the solicited-node multicast address 300 corresponding to the target address. Otherwise, the solicitation is 301 sent to the target's unicast address. 303 Hosts SHOULD additionally perform Neighbor Unreachability Detection 304 (NUD) as specified in ([4], section 7.3). Routers MAY perform the 305 above-specified reachability detection and NUD procedures, but this 306 might not scale in all environments. 308 All ISATAP nodes MUST send solicited neighbor advertisements ([4], 309 section 7.2.4). 311 7.2 Duplicate Address Detection 313 Duplicate Address Detection ([9], section 5.4) is not required for 314 ISATAP addresses, since duplicate address detection is assumed 315 already performed for the IPv4 addresses from which they derive. 317 7.3 Router and Prefix Discovery 319 The following sections describe mechanisms to support the router and 320 prefix discovery process ([4], section 6) on ISATAP links: 322 7.3.1 Conceptual Data Structures 324 ISATAP nodes use the conceptual data structures Prefix List and 325 Default Router List exactly as in ([4], section 5.1). ISATAP links 326 add a new conceptual data structure "Potential Router List" (PRL) and 327 the following new configuration variable: 329 PrlRefreshInterval 330 Time in seconds between successive refreshments of the PRL after 331 initialization. SHOULD be no less than 3,600 seconds. 333 Default: 3,600 seconds 335 A PRL is associated with every ISATAP link. Each entry in the PRL 336 ("PRL(i)") has an IPv4 address ("V4ADDR(i)") that represents an 337 advertising ISATAP interface and an associated timer ("TIMER(i)"). 338 The process for initializing and refreshing the PRL is described 339 below: 341 When a node enables an ISATAP link, it initializes the PRL with IPv4 342 addresses. The addresses MAY be discovered via a DHCPv4 [15] option 343 for ISATAP (option code TBD), manual configuration, or an unspecified 344 alternate method (e.g., DHCPv4 vendor-specific option). 346 When no other mechanisms are available, a DNS fully-qualified domain 347 name (FQDN) [16] established by an out-of-band method (e.g., DHCPv4, 348 manual configuration, etc.) MAY be used. The FQDN is resolved into 349 IPv4 addresses for the PRL through a static host file, a 350 site-specific name service, querying a DNS server within the site, or 351 an unspecified alternate method. There are no mandatory rules for 352 the selection of a FQDN, but manual configuration MUST be supported. 353 When DNS is used, client resolvers use the IPv4 transport. 355 After initialization, nodes periodically refresh the PRL (i.e., using 356 one or more of the methods described above) after PrlRefreshInterval. 358 7.3.2 Validation of Router Advertisements Messages 360 The specification in ([4], section 6.1.2) is used. 362 Additionally, received RA messages that contain Prefix Information 363 options and/or encode non-zero values in the Cur Hop Limit, Router 364 Lifetime, Reachable Time, or Retrans Timer fields (see: [4], section 365 4.2) MUST satisfy the following validity check for ISATAP: 367 o the network-layer (IPv6) source address is an ISATAP address and 368 embeds V4ADDR(i) for some PRL(i) 370 7.3.3 Router Specification 372 Routers with advertising ISATAP interfaces behave the same as 373 described in ([4], section 6.2). As permitted by ([4], section 374 6.2.6), advertising ISATAP interfaces SHOULD send unicast RA messages 375 to a soliciting host's address when the solicitation's source address 376 is not the unspecified address. 378 7.3.4 Host Specification 380 When no unsolicited RA messages containing prefix information options 381 and/or non-zero router lifetime values are received, hosts MAY send 382 Router Solicitation (RS) messages using the specification in Section 383 7.3.4.1. RA messages (whether solicited or unsolicited) are 384 processed using the specification in Section 7.3.4.2. 386 7.3.4.1 Sending Router Solicitations 388 All PRL(i)'s are assumed to represent active advertising ISATAP 389 interfaces within the site, i.e., the PRL provides trust basis only; 390 not reachability detection. Hosts periodically solicit information 391 from one or more PRL(i) by sending Router Solicitation (RS) messages. 392 The manner of selecting a PRL(i) for solicitation and/or deprecating 393 a previously-selected PRL(i) is outside the scope of this 394 specification. Hosts add the following variable to support the 395 solicitation process: 397 MinRouterSolicitInterval 398 Minimum time in seconds between successive solicitations of the 399 same advertising ISATAP interface. SHOULD be no less than 900 400 seconds. 402 Default: 900 seconds 404 Solicitation consists of sending RS messages using the interface's 405 link-local unicast addresses as the source address. When the ISATAP 406 interface provides a multicast emulation mechanism (see: Section 407 5.4), RS messages are sent to the All-Routers multicast address. 408 Otherwise, they are sent to the link-local ISATAP address constructed 409 from V4ADDR(i) for some PRL(i) selected for solicitation. The RS 410 messages are otherwise sent exactly as in ([4], section 6.3.7). 412 7.3.4.2 Processing Router Advertisements 414 Hosts process received RA messages exactly as in ([4], section 6.3.4) 415 and ([9], section 5.5.3). (But, see Appendix C for non-normative 416 considerations for RA messages containing MTU options.) 418 When the source address of the RA message is an ISATAP address that 419 embeds V4ADDR(i) for some PRL(i) selected for solicitation, hosts 420 additionally reset TIMER(i). Let "MIN_LIFETIME" be the minimum value 421 in the router lifetime or the lifetime(s) encoded in options included 422 in the RA message. Then, TIMER(i) is reset to: 424 MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) 426 8. Deployment Considerations 428 8.1 Host And Router Deployment Considerations 430 For hosts, if an underlying link supports both IPv4 (over which 431 ISATAP is implemented) and also supports IPv6 natively, then ISATAP 432 MAY be enabled if the native IPv6 layer does not receive Router 433 Advertisements (i.e., does not have connection with an IPv6 router). 434 After a non-link-local address has been configured and a default 435 router acquired on the native link, the host SHOULD discontinue the 436 router solicitation process described in the Host Specification 437 (Section 7.3.4) and allow existing ISATAP address configurations to 438 expire as specified in ([4], section 5.3) and ([9], section 5.5.4). 439 Any ISATAP addresses added to the DNS for this host should also be 440 removed. In this way, ISATAP use will gradually diminish as IPv6 441 routers are widely deployed throughout the site. 443 Routers MAY configure both a native IPv6 and ISATAP interface over 444 the same physical link. Routing will operate as usual between these 445 two domains. Note that the prefixes used on the ISATAP and native 446 IPv6 interfaces will be distinct. The IPv4 address(es) configured on 447 a router's advertising ISATAP interface(s) SHOULD be added (either 448 automatically or manually) to the site's address records for 449 advertising ISATAP interfaces. 451 8.2 Site Administration Considerations 453 The following considerations are noted for sites that deploy ISATAP: 455 o ISATAP links are administratively defined by a set of advertising 456 ISATAP interfaces and set of nodes which discover those interface 457 addresses. Thus, ISATAP links are defined by administrative (not 458 physical) boundaries. 460 o Hosts and routers that use ISATAP can be deployed in an ad-hoc 461 fashion. In particular, hosts can be deployed with little/no 462 advanced knowledge of existing routers, and routers can be 463 deployed with no reconfiguration requirements for hosts. 465 o Site administrators maintain a list of IPv4 addresses representing 466 advertising ISATAP interfaces and make them available via one or 467 more of the mechanisms described in Section 7.3.1. ISATAP nodes 468 use this list to initialize and periodically refresh the PRL. 469 Responsible site administration can reduce the control traffic. 470 At a minimum, administrators SHOULD ensure that dynamically 471 advertised information for the site's PRL is well maintained. 473 9. IANA Considerations 475 A DHCPv4 option code for ISATAP (TBD) [17] may be requested in the 476 event that this document or a derivative thereof is moved to 477 standards track. 479 Modifications to the IANA "ethernet-numbers" registry (e.g., based on 480 text in Appendix B) may be requested in the event that this document 481 or a derivative thereof is moved to standards track. 483 10. Security considerations 485 ISATAP site border routers and firewalls MUST implement IPv6 ingress 486 filtering and MUST NOT forward packets with site-local source and/or 487 destination addresses outside of the site [18]. 489 In addition to possible attacks against IPv6, security attacks 490 against IPv4 must also be considered. In particular, border routers 491 and firewalls MUST implement IPv4 ingress filtering and 492 ip-protocol-41 filtering. 494 Even with IPv4 and IPv6 ingress filtering, reflection attacks can 495 originate from compromised nodes within an ISATAP site that spoof 496 IPv6 source addresses. Security mechanisms for reflection attack 497 mitigation (e.g., [19], [20], etc.) SHOULD be used in routers with 498 advertising ISATAP interfaces. At a minimum, ISATAP site border 499 gateways MUST log potential source address spoofing cases. 501 IPv6 Neighbor Discovery trust models and threats [21] apply also to 502 ISATAP. However, ([21], section 4.4.) shows that most of these 503 threats are mitigated in corporate networks that implement site 504 security mechanisms, i.e., the applicability space for ISATAP. 506 ISATAP addresses do not support privacy extensions for stateless 507 address autoconfiguration [22]. However, since the ISATAP interface 508 identifier is derived from the node's IPv4 address, ISATAP addresses 509 do not have the same level of privacy concerns as IPv6 addresses that 510 use an interface identifier derived from the MAC address. (This is 511 especially true when private address allocations [10] are used.) 513 11. Acknowledgements 515 Some of the ideas presented in this draft were derived from work at 516 SRI with internal funds and contractual support. Government sponsors 517 who supported the work include Monica Farah-Stapleton and Russell 518 Langan from U.S. Army CECOM ASEO, and Dr. Allen Moshfegh from U.S. 519 Office of Naval Research. Within SRI, Dr. Mike Frankel, J. Peter 520 Marcotullio, Lou Rodriguez, and Dr. Ambatipudi Sastry supported the 521 work and helped foster early interest. 523 The following peer reviewers are acknowledged for taking the time to 524 review a pre-release of this document and provide input: Jim Bound, 525 Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, Ole 526 Troan, Vlad Yasevich. 528 The authors acknowledge members of the NGTRANS community who have 529 made significant contributions to this effort, including Rich Draves, 530 Alain Durand, Nathan Lutchansky, Karen Nielsen, Art Shelest, Margaret 531 Wasserman, and Brian Zill. 533 The authors also wish to acknowledge the work of Quang Nguyen [23] 534 under the guidance of Dr. Lixia Zhang that proposed very similar 535 ideas to those that appear in this document. This work was first 536 brought to the authors' attention on September 20, 2002. 538 Normative References 540 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 541 Specification", RFC 2460, December 1998. 543 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 545 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 546 Levels", BCP 14, RFC 2119, March 1997. 548 [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 549 IP Version 6 (IPv6)", RFC 2461, December 1998. 551 [5] Hinden, R. and S. Deering, "IP Version 6 Addressing 552 Architecture", draft-ietf-ipngwg-addr-arch-v3-11 (work in 553 progress), October 2002. 555 [6] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over 556 Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, 557 January 1999. 559 [7] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms for 560 IPv6 Hosts and Routers", draft-ietf-ngtrans-mech-v2-01 (work in 561 progress), November 2002. 563 [8] Conta, A. and S. Deering, "Internet Control Message Protocol 564 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 565 Specification", RFC 2463, December 1998. 567 [9] Thomson, S. and T. Narten, "IPv6 Stateless Address 568 Autoconfiguration", RFC 2462, December 1998. 570 Informative References 572 [10] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 573 Lear, "Address Allocation for Private Internets", BCP 5, RFC 574 1918, February 1996. 576 [11] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 577 IPv4 Clouds", RFC 3056, February 2001. 579 [12] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 580 Discovery (MLD) for IPv6", RFC 2710, October 1999. 582 [13] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 583 Handley, M. and V. Jacobson, "Protocol Independent 584 Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 585 2362, June 1998. 587 [14] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM 588 Networks", RFC 2022, November 1996. 590 [15] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 591 March 1997. 593 [16] Mockapetris, P., "Domain names - implementation and 594 specification", STD 13, RFC 1035, November 1987. 596 [17] Droms, R., "Procedures and IANA Guidelines for Definition of 597 New DHCP Options and Message Types", BCP 43, RFC 2939, 598 September 2000. 600 [18] Hinden, R., "IPv6 Globally Unique Site-Local Addresses", 601 draft-hinden-ipv6-global-site-local-00 (work in progress), 602 December 2002. 604 [19] Savola, P., "Security Considerations for 6to4", 605 draft-savola-ngtrans-6to4-security-01 (work in progress), March 606 2002. 608 [20] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback 609 Messages", draft-ietf-itrace-03 (work in progress), January 610 2003. 612 [21] Nikander, P., "IPv6 Neighbor Discovery trust models and 613 threats", draft-ietf-send-psreq-01 (work in progress), January 614 2003. 616 [22] Narten, T. and R. Draves, "Privacy Extensions for Stateless 617 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 619 [23] Nguyen, Q., "http://irl.cs.ucla.edu/vet/report.ps", spring 620 1998. 622 [24] Braden, R., "Requirements for Internet Hosts - Communication 623 Layers", STD 3, RFC 1122, October 1989. 625 [25] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 626 November 1990. 628 [26] Postel, J., "Internet Control Message Protocol", STD 5, RFC 629 792, September 1981. 631 [27] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 632 June 1995. 634 [28] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 635 September 2000. 637 [29] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 638 IP version 6", RFC 1981, August 1996. 640 [30] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for 641 High Performance", RFC 1323, May 1992. 643 [31] Templin, F., "Neighbor Affiliation Protocol for 644 IPv6-over-(foo)-over-IPv4", draft-templin-v6v4-ndisc-01 (work 645 in progress), November 2002. 647 Authors' Addresses 649 Fred L. Templin 650 Nokia 651 313 Fairchild Drive 652 Mountain View, CA 94110 653 US 655 Phone: +1 650 625 2331 656 EMail: ftemplin@iprg.nokia.com 658 Tim Gleeson 659 Cisco Systems K.K. 660 Shinjuku Mitsu Building 661 2-1-1 Nishishinjuku, Shinjuku-ku 662 Tokyo 163-0409 663 Japan 665 EMail: tgleeson@cisco.com 667 Mohit Talwar 668 Microsoft Corporation 669 One Microsoft Way 670 Redmond, WA> 98052-6399 671 US 673 Phone: +1 425 705 3131 674 EMail: mohitt@microsoft.com 676 Dave Thaler 677 Microsoft Corporation 678 One Microsoft Way 679 Redmond, WA 98052-6399 680 US 682 Phone: +1 425 703 8835 683 EMail: dthaler@microsoft.com 685 Appendix A. Major Changes 687 changes from version 11 to version 12: 689 o Added comments from co-authors 691 o Revised PRL initialization 693 o Updated MTU section 695 changes from version 10 to version 11: 697 o Added multicast/anycast subsection 699 o Revised PRL initialization 701 o Updated neighbor discovery, security consideration sections 703 o Updated MTU section 705 changes from version 09 to version 10: 707 o Rearranged/revised sections 5, 6, 7 709 o updated MTU section 711 changes from version 08 to version 09: 713 o Added stateful autoconfiguration mechanism 715 o Normative references to RFC 2491, RFC 2462 717 o Moved non-normative MTU text to appendix C 719 changes from version 07 to version 08: 721 o updated MTU section 723 changes from version 06 to version 07: 725 o clarified address resolution, Neighbor Unreachability Detection 727 o specified MTU/MRU requirements 729 changes from earlier versions to version 06: 731 o Addressed operational issues identified in 05 based on discussion 732 between co-authors 734 o Clarified ambiguous text per comments from Hannu Flinck; Jason 735 Goldschmidt 737 o Moved historical text in section 4.1 to Appendix B in response to 738 comments from Pekka Savola 740 o Identified operational issues for anticipated deployment scenarios 742 o Included reference to Quang Nguyen work 744 Appendix B. Rationale for Interface Identifier Construction 746 ISATAP specifies an EUI64-format address construction for the 747 Organizationally-Unique Identifier (OUI) owned by the Internet 748 Assigned Numbers Authority (IANA). This format (given below) is used 749 to construct both native EUI64 addresses for general use and modified 750 EUI-64 format interface identifiers for IPv6 unicast addresses: 752 |0 2|2 3|3 3|4 6| 753 |0 3|4 1|2 9|0 3| 754 +------------------------+--------+--------+------------------------+ 755 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 756 +------------------------+--------+--------+------------------------+ 758 Where the fields are: 760 OUI IANA's OUI: 00-00-5E with 'u' and 'g' bits (3 octets) 762 TYPE Type field; specifies use of (TSE, TSD) (1 octet) 764 TSE Type-Specific Extension (1 octet) 766 TSD Type-Specific Data (3 octets) 768 And the following interpretations are specified based on TYPE: 770 TYPE (TSE, TSD) Interpretation 771 ---- ------------------------- 772 0x00-0xFD RESERVED for future IANA use 773 0xFE (TSE, TSD) together contain an embedded IPv4 address 774 0xFF TSD is interpreted based on TSE as follows: 776 TSE TSD Interpretation 777 --- ------------------ 778 0x00-0xFD RESERVED for future IANA use 779 0xFE TSD contains 24-bit EUI-48 intf id 780 0xFF RESERVED by IEEE/RAC 782 Thus, if TYPE=0xFE, TSE is an extension of TSD. If TYPE=0xFF, TSE is 783 an extension of TYPE. Other values for TYPE (thus, other 784 interpretations of TSE, TSD) are reserved for future IANA use. 786 The above specification is compatible with all aspects of EUI64, 787 including support for encapsulating legacy EUI-48 interface 788 identifiers (e.g., an IANA EUI-48 format multicast address such as: 789 '01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03'). 790 But, the specification also provides a special TYPE (0xFE) to 791 indicate an IPv4 address is embedded. Thus, when the first four 792 octets of an IPv6 interface identifier are: '00-00-5E-FE' (note: the 793 'u/l' bit MUST be 0) the interface identifier is said to be in 794 "ISATAP format" and the next four octets embed an IPv4 address 795 encoded in network byte order. 797 Appendix C. ISATAP Interface MTU Considerations 799 ISATAP encapsulators and decapsulators are IPv6 neighbors that may be 800 separated by multiple link layer (IPv4) forwarding hops. Thus, the 801 path MTU of the underlying IPv4 network may determine the uni- 802 directional IPv6 per-neighbor MTU from the encapsulator to the 803 decapsulator. (Note that this constitutes the MTU of only one hop in 804 what may be a multiple-hop IPv6 path.) When the encapsulator's ISATAP 805 interface configures a large LinkMTU value (see: Section 6.3), 806 special considerations apply as described in the following 807 non-normative sections: 809 C.1 Stateless (Static) MTU Assignment 811 Nodes that connect to the Internet should be able to reassemble and/ 812 or discard IPv4 packets up to 64KB in length when the DF bit is not 813 set in the encapsulating IPv4 header. Nodes that cannot reassemble/ 814 discard maximum-length IPv4 packets are vulnerable to buffer overrun 815 attacks. This issue may be obviated for nodes that are accessed only 816 within a site (i.e., do not connect directly to the Internet) since 817 site border gateways, etc. can filter and discard fragments of large 818 packets before they reach constrained node(s). 820 When the ISATAP encapsulator does not implement a dynamic link layer 821 mechanism to determine per-neighbor MTUs, all IPv6 packets are 822 encapsulated with the DF bit not set in the IPv4 header. 823 Additionally, LinkMTU may be set to a value that is no more than the 824 smallest Effective MTU to Receive (EMTU_R) (see: RFC 1122 [24], 825 section 3.3.2) for all potential decapsulators in the site. The 826 value chosen for LinkMTU must be at least 1280 bytes (the minimum 827 IPv6 MTU) and such that the potential worst-case level of 828 fragmentation in the underlying IPv4 network is deemed "acceptable" 829 by the site's standards. 831 For example, when all decapsulators in the site are known to have an 832 EMTU_R of 10KB and the site's IPv4 routers are optimized for IPv4 833 fragmentation, encapsulators may be able to use LinkMTU values as 834 large as 10KB (minus 20 bytes for IPv4 encapsulation). Conversely, 835 when IPv4 fragmentation causes performance degradation along some 836 paths, LinkMTU should be set to a smaller value. 838 Nodes that use a static MTU assignment SHOULD copy the value in an 839 MTU option received in any Router Advertisement message into LinkMTU 840 for the ISATAP interface as specified in ([4], section 6.3.4). 842 C.2 Stateful (Dynamic) MTU Determination 844 When the encapsulator implements a dynamic MTU determination 845 mechanism it keeps a link layer cache of per-neighbor MTU values 846 (e.g., as ancillary data in the IPv6 neighbor cache, in the IPv4 path 847 MTU discovery cache, etc.). IPv4 path MTU discovery [25] uses ICMPv4 848 "fragmentation needed" messages, but these generally do not provide 849 enough information for stateless translation to ICMPv6 "packet too 850 big" messages (see: RFC 792 [26] and RFC 1812 [27], section 4.3.2.3). 851 Additionally, ICMPv4 "fragmentation needed" messages can be spoofed, 852 filtered, or not sent at all by some forwarding nodes. Thus, IPv4 853 Path MTU discovery used alone may be inadequate and can result in 854 black holes that are difficult to diagnose [28]. 856 Alternate methods for determining per-neighbor MTUs should be used 857 when RFC 1191 path MTU discovery is deemed inadequate. In these 858 methods, the encapsulator uses periodic and/or on-demand probing of 859 the IPv4 path to the decapsulator to initialize and update cache 860 entries. The following three probing methods (among others) are 861 possible: 863 1. Encapsulator-driven - the encapsulator periodically sends probe 864 packets with the DF bit set in the IPv4 header and waits for a 865 positive acknowledgement from the decapsulator that the probe was 866 received 868 2. Decapsulator-driven - the encapsulator sends all packets with the 869 DF bit NOT set in the IPv4 header unless and until the 870 decapsulator sends a "Fragmentation Experienced" indication(s) 872 3. Hybrid - the encapsulator and decapsulator engage in a dialogue 873 and use "intelligent" probing to monitor the path MTU 875 These methods are discussed in detail in the following subsections: 877 C.2.1 Encapsulator-driven Method 878 In this method, the encapsulator sets the DF bit in the IPv4 header 879 of probe packets. Probe packets may be sent either when the 880 encapsulator's link layer forwards a large data packet to the 881 decapsulator (i.e., on-demand) or when the path MTU for the 882 decapsulator has not been verified for some time (i.e., periodic). 883 IPv6 Neighbor Solicitation (NS) or ICMPv6 ECHO_REQUEST packets with 884 padding bytes added could be used for this purpose, since successful 885 delivery results in a positive acknowledgement that the probe 886 succeeded vis-a-vis a response from the decapsulator. 888 While probing, the encapsulator maintains a queue of packets that 889 have the decapsulator as the IPv6 next-hop address. If the probe 890 succeeds, packets in the queue that are no larger than the probe size 891 are sent to the decapsulator. If the probe fails, packets that are 892 larger than the last known successful probe are dropped and an ICMPv6 893 "packet too big" message returned to the sender [29]. The queue 894 should be large enough to buffer the (delay*bandwidth) product for 895 the round-trip time to the decapsulator. When smaller queues are 896 used, loss of packets that are too big for the yet-to-be-determined 897 path MTU may occur with no ICMPv6 "packet too big" message returned. 898 Such loss may occur only in rare instances, but may result in 899 unpredictable behavior in senders that base their adaptation solely 900 on ICMPv6 "packet too big" messages. 902 This method has the advantage that the decapsulator need not 903 implement any special mechanisms, since standard IPv6 request/ 904 response mechanisms are used. Additionally, the encapsulator is 905 assured that any packets that are too large for the decapsulator to 906 receive will be dropped by the network. Disadvantages for this 907 method include the fact that probe packets do not carry data and thus 908 consume network resources. Additionally, queues may become large on 909 Long, Fat Networks (LFNs) (see: RFC 1323 [30]). 911 C.2.2 Decapsulator-driven Method 913 In this method, the encapsulator sends all packets with the DF bit 914 NOT set in the IPv4 header with the expectation that the decapsulator 915 will send a "Fragmentation Experienced" indication if the IPv4 916 network fragments packets. In other words, the decapsulator simply 917 sends all packets that are no larger than LinkMTU unless and until it 918 receives "Fragmentation Experienced" messages from the decapsulator. 919 The decapsulator can use IPv6 Router Advertisement (RA) messages with 920 an MTU option as the means for both reporting fragmentation and 921 informing the encapsulator of a new MTU value to use. 923 This method has the advantage that the data packets themselves are 924 used as probes and no queuing on the encapsulator is necessary. 925 (When large data packets for probing are not available, smaller data 926 packets can be null-padded to the desired probe size by artificially 927 inflating the length field in the IPv4 header; leaving the IPv6 928 length unchanged.) An additional advantage is that fewer packets will 929 be lost since the decapsulator will quite often be able to reassemble 930 packets fragmented by the network. The primary disadvantage for this 931 method is that, using the current specifications, the encapsulator 932 has no way of knowing whether a particular decapsulator implements 933 the "fragmentation experienced" signaling capability. However, the 934 "fragmentation experienced" indication can be trivially implemented 935 in an application on the decapsulator that uses the Berkeley Packet 936 Filter (aka, libpcap) to listen for fragmented packets from 937 encapsulators. 939 When fragmented packets arrive, the decapsulator sends IPv6 RA 940 messages with an MTU option to inform the encapsulator that 941 fragmentation has been experienced and a new value for the neighbor's 942 MTU should be used. The decapsulator additionally sends ICMPv6 943 "packet too big" messages to the original source when a fragmented 944 packet is not correctly reassembled. This function need not be built 945 into the decapsulator's operating system and can be added as an 946 after-market feature. Finally, simply adding an extra bit in a 947 neighbor discovery message header would provide a means for the 948 decapsulator to inform the encapsulator that dynamic MTU discovery is 949 supported. 951 C.2.3 Hybrid Method 953 In this method, the encapsulator and decapsulator engage in a 954 "neighbor affiliation" protocol to negotiate link-layer parameters 955 such as MTU. (See: [31] for an example of such an approach.) This 956 approach has the advantage that bi-directional links are used and 957 both ends of the link have unambiguous knowledge that the other end 958 implements the protocol. However, the signaling protocol between the 959 endpoints is complicated and additional state is required in both the 960 encapsulator and decapsultor. The hybrid method seems best suited to 961 implementation in a reliable transport-layer protocol rather than at 962 the network/link layer. 964 C.2.4 Additional Notes 966 o In all dynamic methods, some packet loss due to link/buffer 967 restrictions may occur with no ICMPv6 "packet too big" message 968 returned to the sender. Unenlightened senders will interpret such 969 loss as loss due to congestion, which may result in longer 970 convergence to the actual path MTU. Enlightened senders will 971 interpret the loss as due to link/buffer restrictions and 972 immediately reduce their MTU estimate. 974 o In all dynamic methods, when a Router Advertisement (RA) message 975 includes an MTU option hosts SHOULD NOT copy the option's value 976 into LinkMTU for the ISATAP interface. Instead, when the ISATAP 977 interface uses a per-neighbor path MTU cache, hosts SHOULD copy 978 the MTU option's value into the cache entry for the neighbor that 979 sent the RA message. This leaves an ambiguous interpretation for 980 processing received RA messages which could be eliminated if [4] 981 were modified to allow Neighbor Advertisement (NA) messages to 982 carry MTU options. 984 o In all methods, a "minimum MTU" must be supported by all nodes for 985 multicast (i.e., even when multicast is emulated on the NBMA IPv4 986 network.) The mechanisms described above speak only to the unicast 987 case for MTU determination. 989 o To avoid denial-of-service attacks that would cause superfluous 990 probing based on counting down/up by small increments, plateau 991 tables (e.g., [25], section 7) should be used when the actual MTU 992 value is indeterminant. 994 o ICMPv4 "fragmentation needed" messages may result when a link 995 restriction is encountered but may also come from denial of 996 service attacks. Implementations should treat ICMPv4 997 "fragmentation needed" messages as "tentative" negative 998 acknowledgments and apply heuristics to determine when to suspect 999 an actual link restriction and when to ignore the messages. IPv6 1000 packets lost due actual link restrictions are perceived as lost 1001 due to congestion by the original source, but robust 1002 implementations minimize instances of such packet loss without 1003 ICMPv6 "packet too big" messages returned to the sender. 1005 Intellectual Property Statement 1007 The IETF takes no position regarding the validity or scope of any 1008 intellectual property or other rights that might be claimed to 1009 pertain to the implementation or use of the technology described in 1010 this document or the extent to which any license under such rights 1011 might or might not be available; neither does it represent that it 1012 has made any effort to identify any such rights. Information on the 1013 IETF's procedures with respect to rights in standards-track and 1014 standards-related documentation can be found in BCP-11. Copies of 1015 claims of rights made available for publication and any assurances of 1016 licenses to be made available, or the result of an attempt made to 1017 obtain a general license or permission for the use of such 1018 proprietary rights by implementors or users of this specification can 1019 be obtained from the IETF Secretariat. 1021 The IETF invites any interested party to bring to its attention any 1022 copyrights, patents or patent applications, or other proprietary 1023 rights which may cover technology that may be required to practice 1024 this standard. Please address the information to the IETF Executive 1025 Director. 1027 The IETF has been notified of intellectual property rights claimed in 1028 regard to some or all of the specification contained in this 1029 document. For more information consult the online list of claimed 1030 rights. 1032 Full Copyright Statement 1034 Copyright (C) The Internet Society (2003). All Rights Reserved. 1036 This document and translations of it may be copied and furnished to 1037 others, and derivative works that comment on or otherwise explain it 1038 or assist in its implementation may be prepared, copied, published 1039 and distributed, in whole or in part, without restriction of any 1040 kind, provided that the above copyright notice and this paragraph are 1041 included on all such copies and derivative works. However, this 1042 document itself may not be modified in any way, such as by removing 1043 the copyright notice or references to the Internet Society or other 1044 Internet organizations, except as needed for the purpose of 1045 developing Internet standards in which case the procedures for 1046 copyrights defined in the Internet Standards process must be 1047 followed, or as required to translate it into languages other than 1048 English. 1050 The limited permissions granted above are perpetual and will not be 1051 revoked by the Internet Society or its successors or assignees. 1053 This document and the information contained herein is provided on an 1054 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1055 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1056 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1057 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1058 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1060 Acknowledgement 1062 Funding for the RFC Editor function is currently provided by the 1063 Internet Society.