idnits 2.17.1 draft-ietf-ngtrans-isatap-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (August 25, 2003) is 7550 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NTL' is mentioned on line 156, but not defined == Missing Reference: 'STL' is mentioned on line 156, but not defined == Unused Reference: 'RFC2463' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 476, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft Nokia 4 Expires: February 23, 2004 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 August 25, 2003 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-14.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 other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 23, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document specifies an Intra-Site Automatic Tunnel Addressing 43 Protocol (ISATAP) that connects IPv6 hosts and routers within IPv4 44 sites. ISATAP treats the site's IPv4 infrastructure as a link layer 45 for IPv6 with no requirement for IPv4 multicast. ISATAP enables 46 intra-site automatic IPv6-in-IPv4 tunneling whether globally assigned 47 or private IPv4 addresses are used. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Basic IPv6 Operation . . . . . . . . . . . . . . . . . . . . . 4 55 5. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 5 56 6. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 6 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 8. Security considerations . . . . . . . . . . . . . . . . . . . 9 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 60 Normative References . . . . . . . . . . . . . . . . . . . . . 10 61 Informative References . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 63 A. Major Changes . . . . . . . . . . . . . . . . . . . . . . . . 12 64 B. Rationale for Interface Identifier Construction . . . . . . . 14 65 C. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 66 D. Site Administration Considerations . . . . . . . . . . . . . . 15 67 Intellectual Property and Copyright Statements . . . . . . . . 17 69 1. Introduction 71 This document presents a simple approach called the Intra-Site 72 Automatic Tunnel Addressing Protocol (ISATAP) that enables 73 incremental deployment of IPv6 [RFC2460] within IPv4 [RFC0791] sites. 74 ISATAP allows dual-stack nodes that do not share a physical link with 75 an IPv6 router to automatically tunnel packets to the IPv6 next-hop 76 address through IPv4, i.e., the site's IPv4 infrastructure is treated 77 as a link layer for IPv6. 79 Specific details for the operation of IPv6 and automatic tunneling 80 using ISATAP are given, including an interface identifier format that 81 embeds an IPv4 address. This format supports IPv6 address 82 configuration and simple link-layer address mapping. Also specified 83 is the operation of IPv6 Neighbor Discovery and deployment/security 84 considerations. 86 2. Requirements 88 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 89 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 90 document, are to be interpreted as described in [RFC2119]. 92 This document also makes use of internal conceptual variables to 93 describe protocol behavior and external variables that an 94 implementation must allow system administrators to change. The 95 specific variable names, how their values change, and how their 96 settings influence protocol behavior are provided to demonstrate 97 protocol behavior. An implementation is not required to have them in 98 the exact form described here, so long as its external behavior is 99 consistent with that described in this document. 101 3. Terminology 103 The terminology of [RFC2460] applies to this document. The following 104 additional terms are defined: 106 link, on-link, off-link: 107 same definitions as ([RFC2461], section 2.1). 109 underlying link: 110 a link layer that supports IPv4 (for ISATAP), and MAY also support 111 IPv6 natively. 113 ISATAP interface: 114 an interface configured over one or more underling links. 116 advertising ISATAP interface: 117 same meaning as "advertising interface" in ([RFC2461], section 118 6.2.2). 120 ISATAP address: 121 an address with an on-link prefix on an ISATAP interface and with 122 an interface identifier constructed as specified in Section 4.1 124 4. Basic IPv6 Operation 126 ISATAP interfaces automatically tunnel IPv6 packets using the site's 127 IPv4 infrastructure as a link layer for IPv6, i.e., IPv6 treats the 128 site's IPv4 infrastructure as a Non-Broadcast, Multiple Access (NBMA) 129 link layer. The mechanisms in [RFC2491] are used, with the following 130 noted exceptions for ISATAP: 132 4.1 Interface Identifiers and Unicast Addresses 134 ISATAP interface identifiers use "modified EUI-64" format ([RFC3513], 135 section 2.5.1) and are formed by appending an IPv4 address assigned 136 to an underlying link to the 32-bit string '00-00-5E-FE'. Appendix B 137 includes non-normative rationale for this construction rule. 139 IPv6 global and local-use ([RFC3513], sections 2.5.4, 2.5.6) ISATAP 140 addresses are constructed as follows: 142 | 64 bits | 32 bits | 32 bits | 143 +------------------------------+---------------+----------------+ 144 | global/local unicast prefix | 0000:5EFE | IPv4 Address | 145 +------------------------------+---------------+----------------+ 147 4.2 ISATAP Interface Configuration 149 ISATAP interfaces are configured over one or more underlying links 150 that support IPv4 for tunneling within a site; each IPv4 address 151 assigned to an underlying link is seen as a link-layer address for 152 ISATAP. 154 4.3 Link Layer Address Options 156 With reference to ([RFC2491], section 5.2), when the [NTL] and [STL] 157 fields in an ISATAP link layer address option encode 0, the [NBMA 158 Number] field encodes a 4-octet IPv4 address. 160 4.4 Multicast and Anycast 161 ISATAP interfaces recognize an IPv6 node's required addresses 162 ([RFC3513], section 2.8), including certain multicast/anycast 163 addresses. 165 Mechanisms for multicast/anycast emulation on ISATAP interfaces 166 (e.g., adaptations of MLD [RFC2710], PIM-SM [RFC2362], MARS 167 [RFC2022], etc.) are subject for future companion document(s). 169 5. Automatic Tunneling 171 The common tunneling mechanisms specified in ([MECH], sections 2 and 172 3) are used, with the following noted considerations for ISATAP: 174 5.1 Tunnel MTU and Fragmentation 176 ISATAP automatic tunnel interfaces may be configured over multiple 177 underlying links with diverse maximum transmission units (MTUs). The 178 minimum MTU for IPv6 interfaces is 1280 bytes ([RFC2460], Section 5), 179 but the following considerations apply for ISATAP interfaces: 181 o Nearly all IPv4 nodes connect to physical links with MTUs of 1500 182 bytes or larger (e.g., Ethernet) 184 o Sub-IPv4 layer encapsulations (e.g., VPN) may occur on some paths 186 o Commonly-deployed VPN interfaces use an MTU of 1400 bytes 188 To maximize efficiency and minimize IPv4 fragmentation for the 189 predominant deployment case, the ISATAP interface MTU, or "LinkMTU" 190 (see: [RFC2461], Section 6.3.2), SHOULD be set to no more than 1380 191 bytes (1400 minus 20 bytes for IPv4 encapsulation). LinkMTU MAY be 192 set to larger values when a dynamic link layer MTU discovery 193 mechanism is used or when a static MTU assignment is used and 194 additional fragmentation in the site's IPv4 network is deemed 195 acceptable. 197 When a dynamic IPv4 MTU discovery mechanism is not used, the ISATAP 198 interface encapsulates IPv6 packets with the Don't Fragment (DF) bit 199 not set in the encapsulating IPv4 header. 201 5.2 Handling IPv4 ICMP Errors 203 ARP failures and persistent ICMPv4 errors SHOULD be processed as 204 link-specific information indicating that a path to a neighbor has 205 failed ([RFC2461], section 7.3.3). 207 5.3 Local-Use IPv6 Unicast Addresses 208 The specification in ([MECH], section 3.7) is not used; the 209 specification in Section 4.1 is used instead. 211 6. Neighbor Discovery 213 The specification in ([MECH], section 3.8) applies only to configured 214 tunnels. [RFC2461] provides the following guidelines for 215 non-broadcast multiple access (NBMA) link support: 217 "Redirect, Neighbor Unreachability Detection and next-hop 218 determination should be implemented as described in this document. 219 Address resolution and the mechanism for delivering Router 220 Solicitations and Advertisements on NBMA links is not specified in 221 this document." 223 ISATAP interfaces SHOULD implement Redirect, Neighbor Unreachability 224 Detection, and next-hop determination exactly as specified in 225 [RFC2461]. Address resolution and the mechanisms for delivering 226 Router Solicitations and Advertisements are not specified by 227 [RFC2461]; instead, they are specified in the following sections of 228 this document. 230 6.1 Address Resolution and Neighbor Unreachability Detection 232 ISATAP addresses are resolved to link-layer (IPv4) addresses by a 233 static computation, i.e., the last four octets are treated as an IPv4 234 address. 236 Hosts SHOULD perform an initial reachability confirmation by sending 237 Neighbor Solicitation (NS) message(s) and receiving a Neighbor 238 Advertisement (NA) message as specified in ([RFC2461], section 7.2). 239 Unless otherwise specified in a future document, solicitations are 240 sent to the target's unicast address. 242 Hosts SHOULD additionally perform Neighbor Unreachability Detection 243 (NUD) as specified in ([RFC2461], section 7.3). Routers MAY perform 244 these reachability confirmation and NUD procedures, but this might 245 not scale in all environments. 247 All ISATAP nodes MUST send solicited neighbor advertisements 248 ([RFC2461], section 7.2.4). 250 6.2 Duplicate Address Detection 252 Duplicate Address Detection ([RFC2462], section 5.4) is not required 253 for ISATAP addresses, since duplicate address detection is assumed 254 already performed for the IPv4 addresses from which they derive. 256 6.3 Router and Prefix Discovery 258 The following sections describe mechanisms to support the router and 259 prefix discovery process ([RFC2461], section 6): 261 6.3.1 Conceptual Data Structures 263 ISATAP nodes use the conceptual data structures Prefix List and 264 Default Router List exactly as in ([RFC2461], section 5.1). ISATAP 265 adds a new conceptual data structure "Potential Router List" (PRL) 266 and the following new configuration variable: 268 PrlRefreshInterval 269 Time in seconds between successive refreshments of the PRL after 270 initialization. SHOULD be no less than 3,600 seconds. 272 Default: 3,600 seconds 274 A PRL is associated with every ISATAP interface. Each entry in the 275 PRL ("PRL(i)") has an IPv4 address ("V4ADDR(i)") that represents an 276 advertising ISATAP interface and an associated timer ("TIMER(i)"). 278 When a node enables an ISATAP interface, it initializes the PRL with 279 IPv4 addresses. The addresses MAY be discovered via a DHCPv4 280 [RFC2131] option for ISATAP, manual configuration, or an unspecified 281 alternate method (e.g., DHCPv4 vendor-specific option). 283 When no other mechanisms are available, a DNS fully-qualified domain 284 name (FQDN) [RFC1035] established by an out-of-band method (e.g., 285 DHCPv4, manual configuration, etc.) MAY be used. The FQDN is resolved 286 into IPv4 addresses for the PRL through a static host file, a 287 site-specific name service, querying a DNS server within the site, or 288 an unspecified alternate method. There are no mandatory rules for the 289 selection of a FQDN, but manual configuration MUST be supported. When 290 DNS is used, client resolvers use the IPv4 transport. 292 After initialization, nodes periodically refresh the PRL (i.e., using 293 one or more of the methods described above) after PrlRefreshInterval. 295 6.3.2 Validation of Router Advertisements Messages 297 The specification in ([RFC2461], section 6.1.2) is used. 299 Additionally, received RA messages that contain Prefix Information 300 options and/or encode non-zero values in the Cur Hop Limit, Router 301 Lifetime, Reachable Time, or Retrans Timer fields (see: [RFC2461], 302 section 4.2) MUST satisfy the following validity check for ISATAP: 304 o the network-layer (IPv6) source address is an ISATAP address and 305 embeds V4ADDR(i) for some PRL(i) 307 6.3.3 Router Specification 309 Routers with advertising ISATAP interfaces behave the same as 310 described in ([RFC2461], section 6.2). As permitted by ([RFC2461], 311 section 6.2.6), advertising ISATAP interfaces SHOULD send unicast RA 312 messages to a soliciting host's unicast address when the 313 solicitation's source address is not the unspecified address. 315 6.3.4 Host Specification 317 Hosts behave the same as described in ([RFC2461], section 6.3) and 318 ([RFC2462], section 5.5) with the following additional considerations 319 for ISATAP: 321 6.3.4.1 Soliciting Router Advertisements 323 Hosts solicit Router Advertisements (RAs) by sending Router 324 Solicitations (RSs) to advertising ISATAP interfaces in the PRL. The 325 manner of selecting PRL(i)'s for solicitation is up to the 326 implementation. Hosts add the following variable to support the 327 solicitation process: 329 MinRouterSolicitInterval 330 Minimum time in seconds between successive solicitations of the 331 same advertising ISATAP interface. SHOULD be no less than 900 332 seconds. 334 Default: 900 seconds 336 RS messages use a link-local unicast address from the ISATAP 337 interface as the IPv6 source address. Unless otherwise specified in a 338 future document, RS messages use the link-local ISATAP address 339 constructed from V4ADDR(i) for the PRL(i) being solicited as the IPv6 340 destination address. 342 6.3.4.2 Router Advertisement Processing 344 RA processing is exactly as specified in ([RFC2461], section 6.3.4). 345 Prefix options in RAs with the "L" bit not set contain prefixes that 346 are not considered on-link with the ISATAP interface and MAY be used 347 to configure non-ISATAP addresses, e.g., using [RFC2462] mechanisms. 349 When the source address of an RA message is an ISATAP address that 350 embeds V4ADDR(i) for some PRL(i), hosts reset TIMER(i) to schedule 351 the next solicitation event (see: Section 6.3.4.1). Let 352 "MIN_LIFETIME" be the minimum value in the router lifetime or the 353 lifetime(s) encoded in options included in the RA message. Then, 354 TIMER(i) is reset as follows: 356 TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) 358 6.3.4.3 Stateful Autoconfiguration 360 If stateful autoconfiguration is invoked ([RFC2462], sections 5.5.2, 361 5.5.3), the "All_DHCP_Relay_Agents_and_Servers" multicast address 362 ([RFC3315], section 5.1) is resolved to V4ADDR(i) for some PRL(i). 364 7. IANA Considerations 366 Modifications to the IANA "ethernet-numbers" registry (e.g., based on 367 text in Appendix B) are requested. 369 8. Security considerations 371 ISATAP site border routers and firewalls MUST implement IPv6 and IPv4 372 ingress filtering, including ip-protocol-41 filtering. Packets with 373 local-use source and/or destination addresses MUST NOT be forwarded 374 outside of the site. 376 Even with IPv4 and IPv6 ingress filtering, reflection attacks can 377 originate from compromised nodes within an ISATAP site that spoof 378 IPv6 source addresses. Security mechanisms for reflection attack 379 mitigation SHOULD be used in routers with advertising ISATAP 380 interfaces. At a minimum, border gateways SHOULD log potential source 381 address spoofing cases. 383 ISATAP addresses do not support privacy extensions for stateless 384 address autoconfiguration [RFC3041]. 386 9. Acknowledgements 388 Portions of this work were derived from SRI International internal 389 funds and government contracts. Government sponsors include Monica 390 Farah-Stapleton and Russell Langan (U.S. Army CECOM ASEO), and Dr. 391 Allen Moshfegh (U.S. Office of Naval Research). SRI International 392 sponsors include Dr. Mike Frankel, J. Peter Marcotullio, Lou 393 Rodriguez, and Dr. Ambatipudi Sastry. 395 The following are acknowledged for providing peer review input: Jim 396 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 397 Ole Troan, Vlad Yasevich. 399 The following additional individuals are acknowledged for their 400 contributions: Rich Draves, Alain Durand, Nathan Lutchansky, Karen 401 Nielsen, Mohan Parthasarathy, Art Shelest, Margaret Wasserman, Brian 402 Zill. 404 The authors also acknowledge the work of Quang Nguyen [VET] under the 405 guidance of Dr. Lixia Zhang that proposed very similar ideas to those 406 that appear in this document. This work was first brought to the 407 authors' attention on September 20, 2002. 409 Normative References 411 [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms 412 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-00 413 (work in progress), February 2003. 415 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 416 1981. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 422 (IPv6) Specification", RFC 2460, December 1998. 424 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 425 Discovery for IP Version 6 (IPv6)", RFC 2461, December 426 1998. 428 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 429 Autoconfiguration", RFC 2462, December 1998. 431 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 432 Protocol (ICMPv6) for the Internet Protocol Version 6 433 (IPv6) Specification", RFC 2463, December 1998. 435 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 436 over Non-Broadcast Multiple Access (NBMA) networks", RFC 437 2491, January 1999. 439 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 440 (IPv6) Addressing Architecture", RFC 3513, April 2003. 442 Informative References 444 [RFC1035] Mockapetris, P., "Domain names - implementation and 445 specification", STD 13, RFC 1035, November 1987. 447 [RFC1546] Partridge, C., Mendez, T. and W. Milliken, "Host 448 Anycasting Service", RFC 1546, November 1993. 450 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 451 E. Lear, "Address Allocation for Private Internets", BCP 452 5, RFC 1918, February 1996. 454 [RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1 455 based ATM Networks", RFC 2022, November 1996. 457 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 458 2131, March 1997. 460 [RFC2185] Callon, R. and D. Haskin, "Routing Aspects Of IPv6 461 Transition", RFC 2185, September 1997. 463 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 464 S., Handley, M. and V. Jacobson, "Protocol Independent 465 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 466 RFC 2362, June 1998. 468 [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast 469 Listener Discovery (MLD) for IPv6", RFC 2710, October 470 1999. 472 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 473 Stateless Address Autoconfiguration in IPv6", RFC 3041, 474 January 2001. 476 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 477 via IPv4 Clouds", RFC 3056, February 2001. 479 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 480 M. Carney, "Dynamic Host Configuration Protocol for IPv6 481 (DHCPv6)", RFC 3315, July 2003. 483 [VET] Nguyen, Q., "http://irl.cs.ucla.edu/vet/report.ps", spring 484 1998. 486 Authors' Addresses 488 Fred L. Templin 489 Nokia 490 313 Fairchild Drive 491 Mountain View, CA 94110 492 US 494 Phone: +1 650 625 2331 495 EMail: ftemplin@iprg.nokia.com 497 Tim Gleeson 498 Cisco Systems K.K. 499 Shinjuku Mitsu Building 500 2-1-1 Nishishinjuku, Shinjuku-ku 501 Tokyo 163-0409 502 Japan 504 EMail: tgleeson@cisco.com 506 Mohit Talwar 507 Microsoft Corporation 508 One Microsoft Way 509 Redmond, WA> 98052-6399 510 US 512 Phone: +1 425 705 3131 513 EMail: mohitt@microsoft.com 515 Dave Thaler 516 Microsoft Corporation 517 One Microsoft Way 518 Redmond, WA 98052-6399 519 US 521 Phone: +1 425 703 8835 522 EMail: dthaler@microsoft.com 524 Appendix A. Major Changes 526 changes from version 13 to version 14: 528 o removed applicability statement; applicability TBD by v6ops 530 o updated deployment/site admin sections; moved to appendices 531 o new text on "L" bit in prefix options in section 7.3.4.2 533 o removed extraneous text in Security Considerations 535 o fixed "layering bug" in section 7.3.4.3 537 o revised "ISATAP address" definition 539 o updated references for RFC 3315; 3513 541 changes from version 12 to version 13: 543 o Added comments from co-authors 545 o Text cleanup; removed extraneous text 547 o Revised ISATAP interface/link terminology 549 o Returned to using symbolic reference names 551 o Revised MTU section; moved non-normative MTU text to separate 552 document 554 changes from earlier versions to version 12: 556 o Added multicast/anycast subsection 558 o Revised PRL initialization 560 o Updated neighbor discovery, security consideration sections 562 o Rearranged/revised sections 5, 6, 7 564 o Added stateful autoconfiguration mechanism 566 o Normative references to RFC 2491, RFC 2462 568 o Moved non-normative MTU text to appendix C 570 o clarified address resolution, Neighbor Unreachability Detection 572 o specified MTU/MRU requirements 574 o Addressed operational issues identified in 05 based on discussion 575 between co-authors 577 o Clarified ambiguous text per comments from Hannu Flinck; Jason 578 Goldschmidt 580 o Moved historical text in section 4.1 to Appendix B in response to 581 comments from Pekka Savola 583 o Identified operational issues for anticipated deployment scenarios 585 o Included reference to Quang Nguyen work 587 Appendix B. Rationale for Interface Identifier Construction 589 ISATAP specifies an EUI64-format address construction for the 590 Organizationally-Unique Identifier (OUI) owned by the Internet 591 Assigned Numbers Authority (IANA). This format (given below) is used 592 to construct both native EUI64 addresses for general use and modified 593 EUI-64 format interface identifiers for IPv6 unicast addresses: 595 |0 2|2 3|3 3|4 6| 596 |0 3|4 1|2 9|0 3| 597 +------------------------+--------+--------+------------------------+ 598 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 599 +------------------------+--------+--------+------------------------+ 601 Where the fields are: 603 OUI IANA's OUI: 00-00-5E with 'u' and 'g' bits (3 octets) 605 TYPE Type field; specifies use of (TSE, TSD) (1 octet) 607 TSE Type-Specific Extension (1 octet) 609 TSD Type-Specific Data (3 octets) 611 And the following interpretations are specified based on TYPE: 613 TYPE (TSE, TSD) Interpretation 614 ---- ------------------------- 615 0x00-0xFD RESERVED for future IANA use 616 0xFE (TSE, TSD) together contain an embedded IPv4 address 617 0xFF TSD is interpreted based on TSE as follows: 619 TSE TSD Interpretation 620 --- ------------------ 621 0x00-0xFD RESERVED for future IANA use 622 0xFE TSD contains 24-bit EUI-48 intf id 623 0xFF RESERVED by IEEE/RAC 625 Thus, if TYPE=0xFE, TSE is an extension of TSD. If TYPE=0xFF, TSE is 626 an extension of TYPE. Other values for TYPE (thus, other 627 interpretations of TSE, TSD) are reserved for future IANA use. 629 The above specification is compatible with all aspects of EUI64, 630 including support for encapsulating legacy EUI-48 interface 631 identifiers (e.g., an IANA EUI-48 format multicast address such as: 632 '01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03'). 633 But, the specification also provides a special TYPE (0xFE) to 634 indicate an IPv4 address is embedded. Thus, when the first four 635 octets of an IPv6 interface identifier are: '00-00-5E-FE' (note: the 636 'u/l' bit MUST be 0) the interface identifier is said to be in 637 "ISATAP format" and the next four octets embed an IPv4 address 638 encoded in network byte order. 640 Appendix C. Deployment Considerations 642 Hosts can enable ISATAP, e.g., when native IPv6 service is 643 unavailable. When native IPv6 service is acquired, hosts can 644 discontinue the ISATAP router solicitation process (Section 6.3.4) 645 and/or allow associated state to expire (see: [RFC2461], section 5.3 646 and [RFC2462], section 5.5.4). In this case, any associated addresses 647 added to the DNS should also be removed. 649 Routers can configure both native IPv6 and ISATAP interfaces over the 650 same physical link. The prefixes used on each interface will be 651 distinct, and normal IPv6 routing between the interfaces can occur. 653 Routers can include prefix options with the "L" bit not set in RAs 654 sent on ISATAP interfaces provided the routers maintain a table of 655 IPv6 host routes for addresses configured from the prefixes. Routers 656 maintain host routes through, e.g., an IPv6 routing protocol, manual 657 configuration, etc. Hosts can learn the routes through, e.g., IPv6 658 ICMP redirects, manual configuration, etc. 660 Routers can obtain IPv6 prefix delegations from a server via an 661 ISATAP interface and advertise the delegated prefix(es) on other IPv6 662 interface(s). 664 When stateful autoconfiguration is enabled, the DHCPv6 [RFC3315] 665 server/relay function should be deployed equally on each ISATAP 666 router. 668 Appendix D. Site Administration Considerations 670 ISATAP sites are administratively defined by a set of advertising 671 interfaces and set of nodes that solicit those interfaces. Thus, 672 ISATAP sites are defined by administrative (not physical) boundaries. 674 Site administrators maintain a list of IPv4 addresses representing 675 advertising ISATAP interfaces and make them available via one or more 676 of the mechanisms described in Section 6.3.1. The list can include 677 IPv4 anycast address(es) (e.g., for use as described in [RFC2185], 678 section 3.3.2.1) but administrators are advised to consider 679 operational implications of anycast (e.g., see: [RFC1546]). 680 Responsible administration can reduce control traffic overhead 681 associated with router and prefix discovery. 683 Intellectual Property Statement 685 The IETF takes no position regarding the validity or scope of any 686 intellectual property or other rights that might be claimed to 687 pertain to the implementation or use of the technology described in 688 this document or the extent to which any license under such rights 689 might or might not be available; neither does it represent that it 690 has made any effort to identify any such rights. Information on the 691 IETF's procedures with respect to rights in standards-track and 692 standards-related documentation can be found in BCP-11. Copies of 693 claims of rights made available for publication and any assurances of 694 licenses to be made available, or the result of an attempt made to 695 obtain a general license or permission for the use of such 696 proprietary rights by implementors or users of this specification can 697 be obtained from the IETF Secretariat. 699 The IETF invites any interested party to bring to its attention any 700 copyrights, patents or patent applications, or other proprietary 701 rights which may cover technology that may be required to practice 702 this standard. Please address the information to the IETF Executive 703 Director. 705 The IETF has been notified of intellectual property rights claimed in 706 regard to some or all of the specification contained in this 707 document. For more information consult the online list of claimed 708 rights. 710 Full Copyright Statement 712 Copyright (C) The Internet Society (2003). All Rights Reserved. 714 This document and translations of it may be copied and furnished to 715 others, and derivative works that comment on or otherwise explain it 716 or assist in its implementation may be prepared, copied, published 717 and distributed, in whole or in part, without restriction of any 718 kind, provided that the above copyright notice and this paragraph are 719 included on all such copies and derivative works. However, this 720 document itself may not be modified in any way, such as by removing 721 the copyright notice or references to the Internet Society or other 722 Internet organizations, except as needed for the purpose of 723 developing Internet standards in which case the procedures for 724 copyrights defined in the Internet Standards process must be 725 followed, or as required to translate it into languages other than 726 English. 728 The limited permissions granted above are perpetual and will not be 729 revoked by the Internet Society or its successors or assignees. 731 This document and the information contained herein is provided on an 732 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 733 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 734 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 735 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 736 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 738 Acknowledgment 740 Funding for the RFC Editor function is currently provided by the 741 Internet Society.