idnits 2.17.1 draft-ietf-ngtrans-isatap-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (January 27, 2005) is 7022 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) == Unused Reference: 'RFC2434' is defined on line 511, 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 2434 (Obsoleted by RFC 5226) ** 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 3513 (Obsoleted by RFC 4291) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-router-selection-06 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft Consultant 4 Expires: July 31, 2005 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 January 27, 2005 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-24.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 31, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects 48 IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network 49 as a link layer for IPv6 and views other nodes on the network as 50 potential IPv6 hosts/routers. ISATAP supports an automatic tunneling 51 abstraction similar to the Non-Broadcast Multiple Access (NBMA) 52 model. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Domain of Applicability . . . . . . . . . . . . . . . . . . 4 60 5. Node Requirements . . . . . . . . . . . . . . . . . . . . . 4 61 6. Addressing Requirements . . . . . . . . . . . . . . . . . . 4 62 7. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . 5 63 8. Neighbor Discovery for ISATAP Interfaces . . . . . . . . . . 7 64 9. Site Administration Considerations . . . . . . . . . . . . . 9 65 10. Summary of Impact on Routing . . . . . . . . . . . . . . . . 9 66 11. Security considerations . . . . . . . . . . . . . . . . . . 10 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 68 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 14.1 Normative References . . . . . . . . . . . . . . . . . . 12 71 14.2 Informative References . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 73 A. Modified EUI-64 Addresses in the IANA Ethernet Address 74 Block . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 B. Changes since -22 . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . 16 78 1. Introduction 80 This document specifies a simple mechanism called the Intra-Site 81 Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 82 hosts/routers over IPv4 networks. Dual-stack (IPv6/IPv4) nodes use 83 ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP 84 views the IPv4 network as a link layer for IPv6 and views other nodes 85 on the network as potential IPv6 hosts/routers. 87 ISATAP enables automatic tunneling whether global or private IPv4 88 addresses are used, and presents a Non-Broadcast Multiple Access 89 (NBMA) abstraction similar to [RFC2491][RFC2492][RFC2529][RFC3056]. 91 The main objectives of this document are to: 1) describe the domain 92 of applicability, 2) specify addressing requirements, 3) specify 93 automatic tunneling using ISATAP, 4) specify the operation of IPv6 94 Neighbor Discovery over ISATAP interfaces, and 5) discuss Site 95 Administration, Security and IANA considerations. 97 2. Requirements 99 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 100 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 101 document, are to be interpreted as described in [RFC2119]. 103 This document also makes use of internal conceptual variables to 104 describe protocol behavior and external variables that an 105 implementation must allow system administrators to change. The 106 specific variable names, how their values change, and how their 107 settings influence protocol behavior are provided to demonstrate 108 protocol behavior. An implementation is not required to have them in 109 the exact form described here, so long as its external behavior is 110 consistent with that described in this document. 112 3. Terminology 114 The terminology of [RFC2460][RFC2461] applies to this document. The 115 following additional terms are defined: 117 site: 118 a connected, self-contained, single administrative domain network 119 surrounded by zero or more border-filtering routers and containing 120 interior routers and links with their attached interfaces. 122 ISATAP node: 123 a node that implements the specifications in this document. 125 ISATAP interface: 126 an ISATAP node's non-broadcast multi-access (NBMA) IPv6 interface 127 used for automatic tunneling of IPv6 packets in IPv4. 129 ISATAP interface identifier: 130 an IPv6 interface identifier with an embedded IPv4 address 131 constructed as specified in Section 6.1. 133 ISATAP address: 134 an IPv6 unicast address that matches an on-link prefix on an 135 ISATAP interface of the node, and includes an ISATAP interface 136 identifier. 138 locator: 139 an IPv4 address-to-interface mapping, i.e., a node's IPv4 address 140 and its associated interface. 142 locator set: 143 a set of locators associated with an ISATAP interface, where each 144 locator in the set belongs to the same site. 146 4. Domain of Applicability 148 The domain of applicability for this technical specification is 149 automatic tunneling of IPv6 packets in IPv4 for ISATAP nodes within 150 sites that observe the Security Considerations found in this 151 document, including host-to-router, router-to-host, and host-to-host 152 automatic tunneling in certain enterprise networks and 3GPP/3GPP2 153 wireless operator networks. (Other scenarios with sufficient trust 154 basis ensured by the mechanisms specified in this document also fall 155 within this domain of applicability.) 157 Extensions to the above domain of applicability (e.g., by combining 158 the mechanisms in this document with other technical specifications) 159 are out of scope. 161 5. Node Requirements 163 ISATAP nodes observe the common functionality requirements for IPv6 164 nodes found in [NODEREQ] and the requirements for dual IP layer 165 operation found in ([MECH], section 2). They also implement the 166 additional features specified in this document. 168 6. Addressing Requirements 169 6.1 ISATAP Interface Identifiers 171 ISATAP interface identifiers are constructed in Modified EUI-64 172 format ([RFC3513], section 2.5.1 and appendix A) by concatenating the 173 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 174 32-bit IPv4 address in network byte order as follows: 176 |0 1|1 3|3 6| 177 |0 5|6 1|2 3| 178 +----------------+----------------+--------------------------------+ 179 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm| 180 +----------------+----------------+--------------------------------+ 182 When the IPv4 address is known to be globally unique, the "u" bit 183 (universal/local) is set to 1; otherwise, the "u" bit is set to 0. 184 "g" is the individual/group bit, and "m" are the bits of the IPv4 185 address. 187 6.2 ISATAP Interface Address Configuration 189 Each ISATAP interface configures a set of locators consisting of IPv4 190 address-to-interface mappings from a single site, i.e., an ISATAP 191 interface's locator set MUST NOT span multiple sites. 193 When an IPv4 address is removed from an interface, the corresponding 194 locator SHOULD be removed from its associated locator set(s). When a 195 new IPv4 address is assigned to an interface, the corresponding 196 locator MAY be added to the appropriate locator set(s). 198 ISATAP interfaces form ISATAP interface identifiers from IPv4 199 addresses in their locator set and use them to create link-local 200 ISATAP addresses ([RFC2462], section 5.3). 202 6.3 Multicast/Anycast 204 It is not possible to assume the general availability of wide-area 205 IPv4 multicast, so (unlike 6over4 [RFC2529]) ISATAP must assume only 206 unicast capability in its underlying IPv4 carrier network. Support 207 for IPv6 multicast over ISATAP interfaces is not described in this 208 document. 210 Similarly, support for Reserved IPv6 Subnet Anycast Addresses is not 211 described in this document. 213 7. Automatic Tunneling 215 ISATAP interfaces use the basic tunneling mechanisms specified in 216 ([MECH], section 3). The following additional specifications are 217 also used: 219 7.1 Encapsulation 221 ISATAP addresses are mapped to a link-layer address by a static 222 computation, i.e., the last four octets are treated as an IPv4 223 address. 225 7.2 Handling IPv4 ICMP Errors 227 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 228 errors as link-specific information indicating that a path to a 229 neighbor may have failed ([RFC2461], section 7.3.3). 231 7.3 Decapsulation 233 The specification in ([MECH], section 3.6) is used. Additionally, 234 when an ISATAP node receives an IPv4 protocol 41 datagram that does 235 not belong to a configured tunnel interface, it determines whether 236 the packet's IPv4 destination address and arrival interface match a 237 locator configured in an ISATAP interface's locator set. 239 If an ISATAP interface that configures a matching locator is found, 240 the decapsulator MUST verify that the packet's IPv4 source address is 241 correct for the encapsulated IPv6 source address. The IPv4 source 242 address is correct if: 244 o the IPv6 source address is an ISATAP address that embeds the IPv4 245 source address in its interface identifier, or: 247 o the IPv4 source address is a member of the Potential Router List 248 (see: section 8.1). 250 Packets for which the IPv4 source address is incorrect for this 251 ISATAP interface are checked to determine whether they belong to 252 another tunnel interface. 254 7.4 Link-Local Addresses 256 ISATAP interfaces use link local addresses constructed as specified 257 in section 6 of this document. 259 7.5 Neighbor Discovery over Tunnels 261 ISATAP interfaces use the specifications for neighbor discovery found 262 in section 8 of this document. 264 8. Neighbor Discovery for ISATAP Interfaces 266 ISATAP interfaces use the neighbor discovery mechanisms specified in 267 [RFC2461] and also implement the following specifications: 269 8.1 Conceptual Model Of A Host 271 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 272 ISATAP interfaces add: 274 Potential Router List 275 A set of entries about potential routers; used to support router 276 and prefix discovery. Each entry ("PRL(i)") has an associated 277 timer ("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that 278 represents a router's advertising ISATAP interface. 280 8.2 Router and Prefix Discovery - Router Specification 282 Advertising ISATAP interfaces send Solicited Router Advertisement 283 messages as specified in ([RFC2461], section 6.2.6) except that the 284 messages are sent directly to the soliciting node, i.e., they might 285 not be received by other nodes on the link. 287 8.3 Router and Prefix Discovery - Host Specification 289 The Host Specification in ([RFC2461], section 6.3) is used. ISATAP 290 interfaces add the following specifications: 292 8.3.1 Host Variables 294 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 295 interfaces add: 297 PrlRefreshInterval 298 Time in seconds between successive refreshments of the PRL after 299 initialization. The designated value of all 1's (0xffffffff) 300 represents infinity. 302 Default: 3600 seconds 304 MinRouterSolicitInterval 305 Minimum time in seconds between successive solicitations of the 306 same advertising ISATAP interface. The designated value of all 307 1's (0xffffffff) represents infinity. 309 8.3.2 Potential Router List Initialization 311 ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses 312 discovered via manual configuration, a DNS fully-qualified domain 313 name (FQDN) [RFC1035], a DHCPv4 option, a DHCPv4 vendor-specific 314 option, or an unspecified alternate method. FQDNs are established 315 via manual configuration or an unspecified alternate method. FQDNs 316 are resolved into IPv4 addresses through a static host file lookup, 317 querying the DNS service, querying a site-specific name service, or 318 an unspecified alternate method. 320 After initializing an ISATAP interface's PRL, if the PRL is empty the 321 node SHOULD disable the interface. Otherwise, the node sets a timer 322 for the interface to PrlRefreshInterval seconds and re-initializes 323 the interface's PRL as specified above when the timer expires. When 324 an FQDN is used, and when it is resolved via a service that includes 325 TTLs with the IPv4 addresses returned (e.g., DNS 'A' resource records 326 [RFC1035]), the timer SHOULD be set to the minimum of 327 PrlRefreshInterval and the minimum TTL returned. (Zero-valued TTLs 328 are interpreted to mean that the PRL is re-initialized before each 329 Router Solicitation event - see: section 8.3.4). 331 8.3.3 Processing Received Router Advertisements 333 To the list of checks for validating Router Advertisement messages 334 ([RFC2461], section 6.1.1), ISATAP interfaces add: 336 o IP Source Address is a link-local ISATAP address that embeds 337 V4ADDR(i) for some PRL(i). 339 Valid Router Advertisements received on an ISATAP interface are 340 processed as specified in ([RFC2461], section 6.3.4). 342 8.3.4 Sending Router Solicitations 344 To the list of events after which Router Solicitation messages may be 345 sent ([RFC2461], section 6.3.7), ISATAP interfaces add: 347 o TIMER(i) for some PRL(i) expires. 349 Since unsolicited Router Advertisements may be incomplete and/or 350 absent, ISATAP nodes MAY schedule periodic Router Solicitation events 351 for certain PRL(i)'s by setting the corresponding TIMER(i). 353 When periodic Router Solicitation events are scheduled, the node 354 SHOULD set TIMER(i) such that the next event will refresh remaining 355 lifetimes stored for PRL(i) before they expire, including the Router 356 Lifetime, Valid Lifetimes received in Prefix Information Options, and 357 Route Lifetimes received in Route Information Options [DEFLT]. 358 TIMER(i) MUST be set to no less than MinRouterSolicitInterval seconds 359 where MinRouterSolicitInterval is configurable for the node, or for a 360 specific PRL(i), with a conservative default value (e.g., 2 minutes). 362 When TIMER(i) expires, the node sends Router Solicitation messages as 363 specified in ([RFC2461], section 6.3.7) except that the messages are 364 sent directly to PRL(i), i.e., they might not be received by other 365 routers. While the node continues to require periodic Router 366 Solicitation events for PRL(i), and while PRL(i) continues to act as 367 a router, the node resets TIMER(i) after each expiration event as 368 described above. 370 8.4 Neighbor Unreachability Detection 372 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 373 section 7.3). Routers MAY perform neighbor unreachability detection, 374 but this might not scale in all environments. 376 After address resolution, hosts SHOULD perform an initial 377 reachability confirmation by sending Neighbor Solicitation message(s) 378 and receiving a Neighbor Advertisement message. Routers MAY perform 379 this initial reachability confirmation, but this might not scale in 380 all environments. 382 9. Site Administration Considerations 384 Site administrators maintain a Potential Router List (PRL) of IPv4 385 addresses representing advertising ISATAP interfaces of routers. 387 The PRL is commonly maintained as an FQDN for the ISATAP service in 388 the site's name service (see: section 8.3.2). There are no mandatory 389 rules for the selection of the FQDN, but site administrators are 390 encouraged to use the convention "isatap.domainname" (e.g., 391 isatap.example.com). 393 When the site's name service includes TTLs with the IPv4 addresses 394 returned, site administrators SHOULD configure the TTLs with 395 conservative values to minimize control traffic. 397 10. Summary of Impact on Routing 399 As stated in Section 4, this document focuses on connectivity to 400 hosts. Router-to-router protocols which rely on the use of multicast 401 will not work over an ISATAP link, but this is not required for 402 ISATAP's domain of applicability. For router-to-host communication, 403 the impact on Neighbor Discovery/Router Discovery is covered in 404 Section 8. 406 Finally, there is no impact on existing routing protocols outside of 407 the ISATAP link, as any arbitrary prefix can be used, as with most 408 other link-layer protocols. 410 11. Security considerations 412 Implementors should be aware that, in addition to possible attacks 413 against IPv6, security attacks against IPv4 must also be considered. 414 Use of IP security at both IPv4 and IPv6 levels should nevertheless 415 be avoided, for efficiency reasons. For example, if IPv6 is running 416 encrypted, encryption of IPv4 would be redundant except if traffic 417 analysis is felt to be a threat. If IPv6 is running authenticated, 418 then authentication of IPv4 will add little. Conversely, IPv4 419 security will not protect IPv6 traffic once it leaves the ISATAP 420 domain. Therefore, implementing IPv6 security is required even if 421 IPv4 security is available. 423 There is a possible spoofing attack in which an attacker outside the 424 IPv4 site spoofs an IPv6 source address which appears to be an 425 on-link ISATAP address, and encapsulates it to an ISATAP node. Since 426 an ISATAP link spans an entire IPv4 site, restricting access to the 427 link can be achieved by restricting access to the site, i.e., by 428 having site border routers implement IPv4 ingress filtering and 429 ip-protocol-41 filtering. 431 Another possible spoofing attack involves spurious ip-protocol-41 432 packets injected from within an ISATAP link by a node pretending to 433 be a router. The Potential Router List (PRL) provides a list of IPv4 434 addresses representing advertising ISATAP interfaces of routers that 435 hosts use in filtering decisions. Site administrators should ensure 436 that the PRL is kept up to date, and that the resolution mechanism 437 (see: section 9) cannot be subverted. ISATAP SHOULD NOT be used when 438 the PRL is empty (see: section 8.3.2). 440 ISATAP has unique characteristics that do not exist in other 441 tunneling solutions such as 6to4 [RFC3056] and result in avoiding 442 most security issues that exist in those protocols. Unlike such 443 protocols, ISATAP is only to be used within a site with border 444 routers which filter ip-protocol-41 packets, as noted above. This 445 reduces the scope of spoofing attacks to other attackers inside the 446 site. Also unlike such protocols, ISATAP will not accept packets 447 from arbitrary routers, only from routers in the Potential Router 448 List it knows, as noted above. This avoids spoofing attacks that 449 would otherwise be possible by an attacker pretending to be a router, 450 but relies on the security of the PRL resolution method used. 451 Together, these characteristics mean that spoofing an IPv6 source 452 address requires either spoofing the IPv4 address embedded in an 453 ISATAP address, or spoofing an IPv4 address in the PRL. This is 454 hence no worse than IPv4 without ISATAP in this respect. 456 The threats associated with IPv6 Neighbor Discovery are described in 457 [RFC3756]. 459 The use of temporary addresses [RFC3041] and Cryptographically 460 Generated Addresses [CGA] on ISATAP interfaces is outside the scope 461 of this specification. 463 12. IANA Considerations 465 The IANA is requested to specify the format for Modified EUI-64 466 address construction ([RFC3513], Appendix A) in the IANA Ethernet 467 Address Block. The text in Appendix B of this document is offered as 468 an example specification. The current version of the IANA registry 469 for Ether Types can be accessed at: 471 http://www.iana.org/assignments/ethernet-numbers 473 13. Acknowledgments 475 The ideas in this document are not original, and the authors 476 acknowledge the original architects. Portions of this work were 477 sponsored through U.S. government contracts and internal projects at 478 SRI International and Nokia. Government sponsors include Monica 479 Farah-Stapleton and Russell Langan (U.S. Army CECOM ASEO), and Dr. 480 Allen Moshfegh (U.S. Office of Naval Research). SRI International 481 sponsors include Dr. Mike Frankel, J. Peter Marcotullio, Lou 482 Rodriguez, and Dr. Ambatipudi Sastry. 484 The following are acknowledged for providing peer review input: Jim 485 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 486 Ole Troan, Vlad Yasevich. 488 The following are acknowledged for their significant contributions: 489 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 490 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, 491 Markku Savela, Pekka Savola, Margaret Wasserman, Brian Zill. 493 The authors acknowledge the work of Quang Nguyen on "Virtual 494 Ethernet" under the guidance of Dr. Lixia Zhang that proposed very 495 similar ideas to those that appear in this document. This work was 496 first brought to the authors' attention on September 20, 2002. 498 14. References 499 14.1 Normative References 501 [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms 502 for IPv6 Hosts and Routers", 503 Internet-Draft draft-ietf-v6ops-mech-v2-00, February 2003. 505 [RFC1035] Mockapetris, P., "Domain names - implementation and 506 specification", STD 13, RFC 1035, November 1987. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997. 511 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 512 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 513 October 1998. 515 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 516 (IPv6) Specification", RFC 2460, December 1998. 518 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 519 Discovery for IP Version 6 (IPv6)", RFC 2461, December 520 1998. 522 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 523 Autoconfiguration", RFC 2462, December 1998. 525 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 526 (IPv6) Addressing Architecture", RFC 3513, April 2003. 528 14.2 Informative References 530 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 531 Internet-Draft draft-ietf-send-cga, April 2004. 533 [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and 534 More-Specific Routes", 535 Internet-Draft draft-ietf-ipv6-router-selection-06.txt, 536 October 2003. 538 [NODEREQ] Loughney, J., "IPv6 Node Requirements", 539 Internet-Draft draft-ietf-ipv6-node-requirements, August 540 2004. 542 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 543 over Non-Broadcast Multiple Access (NBMA) networks", 544 RFC 2491, January 1999. 546 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 547 Networks", RFC 2492, January 1999. 549 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 550 Domains without Explicit Tunnels", RFC 2529, March 1999. 552 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 553 Stateless Address Autoconfiguration in IPv6", RFC 3041, 554 January 2001. 556 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 557 via IPv4 Clouds", RFC 3056, February 2001. 559 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 560 Discovery (ND) Trust Models and Threats", RFC 3756, May 561 2004. 563 Authors' Addresses 565 Fred L. Templin 566 Consultant 568 Email: fltemplin@acm.org 570 Tim Gleeson 571 Cisco Systems K.K. 572 Shinjuku Mitsu Building 573 2-1-1 Nishishinjuku, Shinjuku-ku 574 Tokyo 163-0409 575 Japan 577 Email: tgleeson@cisco.com 579 Mohit Talwar 580 Microsoft Corporation 581 One Microsoft Way 582 Redmond, WA> 98052-6399 583 US 585 Phone: +1 425 705 3131 586 Email: mohitt@microsoft.com 587 Dave Thaler 588 Microsoft Corporation 589 One Microsoft Way 590 Redmond, WA 98052-6399 591 US 593 Phone: +1 425 703 8835 594 Email: dthaler@microsoft.com 596 Appendix A. Modified EUI-64 Addresses in the IANA Ethernet Address 597 Block 599 Modified EUI-64 addresses ([RFC3513], section 2.5.1 and Appendix A) 600 in the IANA Ethernet Address Block are formed by concatenating the 601 24-bit IANA OUI (00-00-5E) with a 40-bit extension identifier and 602 inverting the "u" bit, i.e., the "u" bit is set to one (1) to 603 indicate universal scope and it is set to zero (0) to indicate local 604 scope. 606 Modified EUI-64 addresses have the following appearance in memory 607 (bits transmitted right-to-left within octets, octets transmitted 608 left-to-right): 610 0 23 63 611 | OUI | extension identifier | 612 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 614 When the first two octets of the extension identifier encode the 615 hexadecimal value 0xFFFE, the remainder of the extension identifier 616 encodes a 24-bit vendor-supplied id as follows: 618 0 23 39 63 619 | OUI | 0xFFFE | vendor-supplied id | 620 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx 622 When the first octet of the extension identifier encodes the 623 hexadecimal value 0xFE, the remainder of the extension identifier 624 encodes a 32-bit IPv4 address as follows: 626 0 23 31 63 627 | OUI | 0xFE | IPv4 address | 628 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 630 Appendix B. Changes since -22 632 NOTE: This section to be removed before publication as an RFC. 634 o added definition for the term "site" 636 o added new section on summary of impact on routing 638 o added 6to4 comparision paragraph in Security Considerations 640 o clarified security considerations statement on possible spoofing 641 attacks from a node outside the site 643 o added "ISATAP SHOULD NOT be used when the PRL is empty" to section 644 8.3.2 and security considerations 646 o mentioned Nokia internal project work under acknowledgements 648 Intellectual Property Statement 650 The IETF takes no position regarding the validity or scope of any 651 Intellectual Property Rights or other rights that might be claimed to 652 pertain to the implementation or use of the technology described in 653 this document or the extent to which any license under such rights 654 might or might not be available; nor does it represent that it has 655 made any independent effort to identify any such rights. Information 656 on the procedures with respect to rights in RFC documents can be 657 found in BCP 78 and BCP 79. 659 Copies of IPR disclosures made to the IETF Secretariat and any 660 assurances of licenses to be made available, or the result of an 661 attempt made to obtain a general license or permission for the use of 662 such proprietary rights by implementers or users of this 663 specification can be obtained from the IETF on-line IPR repository at 664 http://www.ietf.org/ipr. 666 The IETF invites any interested party to bring to its attention any 667 copyrights, patents or patent applications, or other proprietary 668 rights that may cover technology that may be required to implement 669 this standard. Please address the information to the IETF at 670 ietf-ipr@ietf.org. 672 The IETF has been notified of intellectual property rights claimed in 673 regard to some or all of the specification contained in this 674 document. For more information consult the online list of claimed 675 rights. 677 Disclaimer of Validity 679 This document and the information contained herein are provided on an 680 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 681 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 682 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 683 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 684 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 685 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 687 Copyright Statement 689 Copyright (C) The Internet Society (2005). This document is subject 690 to the rights, licenses and restrictions contained in BCP 78, and 691 except as set forth therein, the authors retain all their rights. 693 Acknowledgment 695 Funding for the RFC Editor function is currently provided by the 696 Internet Society.