idnits 2.17.1 draft-ietf-ngtrans-isatap-22.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 619. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 587), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (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) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 11 errors (**), 0 flaws (~~), 3 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 Nokia 4 May 26, 2004 T. Gleeson 5 Expires: November 26, 2004 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 10 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 11 draft-ietf-ngtrans-isatap-22.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as 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 30 http://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 November 26, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects 44 IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network 45 as a link layer for IPv6 and views other nodes on the network as 46 potential IPv6 hosts/routers. ISATAP supports an automatic tunneling 47 abstraction similar to the Non-Broadcast Multiple Access (NBMA) 48 model. 50 1. Introduction 52 This document specifies a simple mechanism called the Intra-Site 53 Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 54 hosts/routers over IPv4 networks. Dual-stack (IPv6/IPv4) nodes use 55 ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP 56 views the IPv4 network as a link layer for IPv6 and views other nodes 57 on the network as potential IPv6 hosts/routers. 59 ISATAP enables automatic tunneling whether global or private IPv4 60 addresses are used, and presents a Non-Broadcast Multiple Access 61 (NBMA) abstraction similar to [RFC2491][RFC2492][RFC2529][RFC3056]. 63 The main objectives of this document are to: 1) describe the domain 64 of applicability, 2) specify addressing requirements, 3) specify 65 automatic tunneling using ISATAP, 4) specify the operation of IPv6 66 Neighbor Discovery over ISATAP interfaces, and 5) discuss Site 67 Administration, Security and IANA considerations. 69 2. Requirements 71 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 72 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 73 document, are to be interpreted as described in [BCP14]. 75 This document also makes use of internal conceptual variables to 76 describe protocol behavior and external variables that an 77 implementation must allow system administrators to change. The 78 specific variable names, how their values change, and how their 79 settings influence protocol behavior are provided to demonstrate 80 protocol behavior. An implementation is not required to have them in 81 the exact form described here, so long as its external behavior is 82 consistent with that described in this document. 84 3. Terminology 86 The terminology of [RFC2460][RFC2461] applies to this document. The 87 following additional terms are defined: 89 ISATAP node: 90 a node that implements the specifications in this document. 92 ISATAP interface: 93 an ISATAP node's non-broadcast multi-access (NBMA) IPv6 interface 94 used for automatic tunneling of IPv6 packets in IPv4. 96 ISATAP interface identifier: 97 an IPv6 interface identifier with an embedded IPv4 address 98 constructed as specified in section 6.1. 100 ISATAP address: 101 an IPv6 unicast address that matches an on-link prefix on an 102 ISATAP interface of the node, and includes an ISATAP interface 103 identifier. 105 locator: 106 an IPv4 address-to-interface mapping, i.e., a node's IPv4 address 107 and its associated interface. 109 locator set: 110 a set of locators associated with an ISATAP interface, where each 111 locator in the set belongs to the same site. 113 4. Domain of Applicability 115 The domain of applicability for this technical specification is 116 automatic tunneling of IPv6 packets in IPv4 for ISATAP nodes within 117 sites that observe the Security Considerations found in this 118 document, including host-to-router, router-to-host, and host-to-host 119 automatic tunneling in certain enterprise networks and 3GPP/3GPP2 120 wireless operator networks. (Other scenarios with sufficient trust 121 basis ensured by the mechanisms specified in this document also fall 122 within this domain of applicability.) 124 Extensions to the above domain of applicability (e.g., by combining 125 the mechanisms in this document with other technical specifications) 126 are out of scope. 128 5. Node Requirements 130 ISATAP nodes observe the common functionality requirements for IPv6 131 nodes found in [NODEREQ] and the requirements for dual IP layer 132 operation found in ([MECH], section 2). They also implement the 133 additional features specified in this document. 135 6. Addressing Requirements 137 6.1 ISATAP Interface Identifiers 139 ISATAP interface identifiers are constructed in Modified EUI-64 140 format ([RFC3513], section 2.5.1 and appendix A) by concatenating the 141 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 142 32-bit IPv4 address in network byte order as follows: 144 |0 1|1 3|3 6| 145 |0 5|6 1|2 3| 146 +----------------+----------------+--------------------------------+ 147 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm| 148 +----------------+----------------+--------------------------------+ 150 When the IPv4 address is known to be globally unique, the "u" bit 151 (universal/local) is set to 1; otherwise, the "u" bit is set to 0. 152 "g" is the individual/group bit, and "m" are the bits of the IPv4 153 address. 155 6.2 ISATAP Interface Address Configuration 157 Each ISATAP interface configures a set of locators consisting of IPv4 158 address-to-interface mappings from a single site, i.e., an ISATAP 159 interface's locator set MUST NOT span multiple sites. 161 When an IPv4 address is removed from an interface, the corresponding 162 locator SHOULD be removed from its associated locator set(s). When a 163 new IPv4 address is assigned to an interface, the corresponding 164 locator MAY be added to the appropriate locator set(s). 166 ISATAP interfaces form ISATAP interface identifiers from IPv4 167 addresses in their locator set and use them to create link-local 168 ISATAP addresses ([RFC2462], section 5.3). 170 6.3 Multicast/Anycast 172 It is not possible to assume the general availability of wide-area 173 IPv4 multicast, so (unlike 6over4 [RFC2529]) ISATAP must assume only 174 unicast capability in its underlying IPv4 carrier network. Support 175 for IPv6 multicast over ISATAP interfaces is not described in this 176 document. 178 Similarly, support for Reserved IPv6 Subnet Anycast Addresses is not 179 described in this document. 181 7. Automatic Tunneling 183 ISATAP interfaces use the basic tunneling mechanisms specified in 184 ([MECH], section 3). The following additional specifications are also 185 used: 187 7.1 Encapsulation 189 ISATAP addresses are mapped to a link-layer address by a static 190 computation, i.e., the last four octets are treated as an IPv4 191 address. 193 7.2 Handling ICMPv4 Errors 195 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 196 errors as link-specific information indicating that a path to a 197 neighbor may have failed ([RFC2461], section 7.3.3). 199 7.3 Decapsulation 201 The specification in ([MECH], section 3.6) is used. Additionally, 202 when an ISATAP node receives an IPv4 protocol 41 datagram that does 203 not belong to a configured tunnel interface, it determines whether 204 the packet's IPv4 destination address and arrival interface match a 205 locator configured in an ISATAP interface's locator set. 207 If an ISATAP interface that configures a matching locator is found, 208 the decapsulator MUST verify that the packet's IPv4 source address is 209 correct for the encapsulated IPv6 source address. The IPv4 source 210 address is correct if: 212 - the IPv6 source address is an ISATAP address that embeds the 213 IPv4 source address in its interface identifier, or: 215 - the IPv4 source address is a member of the Potential Router 216 List (see: section 8.1). 218 Packets for which the IPv4 source address is incorrect for this 219 ISATAP interface are checked to determine whether they belong to 220 another tunnel interface. 222 7.4 Link-Local Addresses 224 ISATAP interfaces use link local addresses constructed as specified 225 in section 6 of this document. 227 7.5 Neighbor Discovery over Tunnels 229 ISATAP interfaces use the specifications for neighbor discovery found 230 in the following section of this document. 232 8. Neighbor Discovery for ISATAP Interfaces 234 ISATAP interfaces use the neighbor discovery mechanisms specified in 235 [RFC2461] and also implement the following specifications: 237 8.1 Conceptual Model Of A Host 239 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 240 ISATAP interfaces add: 242 Potential Router List (PRL) 243 A set of entries about potential routers; used to support router 244 and prefix discovery. Each entry ("PRL(i)") has an associated 245 timer ("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that 246 represents a router's advertising ISATAP interface. 248 8.2 Router and Prefix Discovery - Router Specification 250 Advertising ISATAP interfaces send Solicited Router Advertisement 251 messages as specified in ([RFC2461], section 6.2.6) except that the 252 messages are sent directly to the soliciting node, i.e., they might 253 not be received by other nodes on the link. 255 8.3 Router and Prefix Discovery - Host Specification 257 The Host Specification in ([RFC2461], section 6.3) is used. ISATAP 258 interfaces add the following specifications: 260 8.3.1 Host Variables 262 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 263 interfaces add: 265 PrlRefreshInterval 266 Time in seconds between successive refreshments of the PRL after 267 initialization. The designated value of all 1's (0xffffffff) 268 represents infinity. 269 Default: 3600 seconds 271 MinRouterSolicitInterval 272 Minimum time in seconds between successive solicitations of the 273 same advertising ISATAP interface. The designated value of all 1's 274 (0xffffffff) represents infinity. 276 8.3.2 Potential Router List Initialization 278 ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses 279 discovered via manual configuration, a DNS fully-qualified domain 280 name (FQDN) [STD13], a DHCPv4 option, a DHCPv4 vendor-specific 281 option, or an unspecified alternate method. FQDNs are established via 282 manual configuration or an unspecified alternate method. FQDNs are 283 resolved into IPv4 addresses through a static host file lookup, 284 querying the DNS service, querying a site-specific name service, or 285 an unspecified alternate method. 287 After initializing an ISATAP interface's PRL, the node sets a timer 288 for the interface to PrlRefreshInterval seconds and re-initializes 289 the interface's PRL as specified above when the timer expires. When 290 an FQDN is used, and when it is resolved via a service that includes 291 TTLs with the IPv4 addresses returned (e.g., DNS 'A' resource records 292 [STD13]), the timer SHOULD be set to the minimum of 293 PrlRefreshInterval and the minimum TTL returned. (Zero-valued TTLs 294 are interpreted to mean that the PRL is re-initialized before each 295 Router Solicitation event - see: section 8.3.4). 297 8.3.3 Processing Received Router Advertisements 299 To the list of checks for validating Router Advertisement messages 300 ([RFC2461], section 6.1.1), ISATAP interfaces add: 302 - IP Source Address is a link-local ISATAP address that embeds 303 V4ADDR(i) for some PRL(i). 305 Valid Router Advertisements received on an ISATAP interface are 306 processed as specified in ([RFC2461], section 6.3.4). 308 8.3.4 Sending Router Solicitations 310 To the list of events after which Router Solicitation messages may be 311 sent ([RFC2461], section 6.3.7), ISATAP interfaces add: 313 - TIMER(i) for some PRL(i) expires. 315 Since unsolicited Router Advertisements may be incomplete and/or 316 absent, ISATAP nodes MAY schedule periodic Router Solicitation events 317 for certain PRL(i)'s by setting the corresponding TIMER(i). 319 When periodic Router Solicitation events are scheduled, the node 320 SHOULD set TIMER(i) such that the next event will refresh remaining 321 lifetimes stored for PRL(i) before they expire, including the Router 322 Lifetime, Valid Lifetimes received in Prefix Information Options, and 323 Route Lifetimes received in Route Information Options [DEFLT]. 324 TIMER(i) MUST be set to no less than MinRouterSolicitInterval seconds 325 where MinRouterSolicitInterval is configurable for the node, or for a 326 specific PRL(i), with a conservative default value (e.g., 2 minutes). 328 When TIMER(i) expires, the node sends Router Solicitation messages as 329 specified in ([RFC2461], section 6.3.7) except that the messages are 330 sent directly to PRL(i), i.e., they might not be received by other 331 routers. While the node continues to require periodic Router 332 Solicitation events for PRL(i), and while PRL(i) continues to act as 333 a router, the node resets TIMER(i) after each expiration event as 334 described above. 336 8.4 Neighbor Unreachability Detection 338 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 339 section 7.3). Routers MAY perform neighbor unreachability detection, 340 but this might not scale in all environments. 342 After address resolution, hosts SHOULD perform an initial 343 reachability confirmation by sending Neighbor Solicitation message(s) 344 and receiving a Neighbor Advertisement message. Routers MAY perform 345 this initial reachability confirmation, but this might not scale in 346 all environments. 348 9. Site Administration Considerations 350 Site administrators maintain a Potential Router List (PRL) of IPv4 351 addresses representing advertising ISATAP interfaces of routers. 353 The PRL is commonly maintained as an FQDN for the ISATAP service in 354 the site's name service (see: section 8.3.2). There are no mandatory 355 rules for the selection of the FQDN, but site administrators are 356 encouraged to use the convention "isatap.domainname" (e.g., 357 isatap.example.com). 359 When the site's name service includes TTLs with the IPv4 addresses 360 returned, site administrators SHOULD configure the TTLs with 361 conservative values to minimize control traffic. 363 10. Security considerations 365 Implementors should be aware that, in addition to possible attacks 366 against IPv6, security attacks against IPv4 must also be considered. 367 Use of IP security at both IPv4 and IPv6 levels should nevertheless 368 be avoided, for efficiency reasons. For example, if IPv6 is running 369 encrypted, encryption of IPv4 would be redundant except if traffic 370 analysis is felt to be a threat. If IPv6 is running authenticated, 371 then authentication of IPv4 will add little. Conversely, IPv4 372 security will not protect IPv6 traffic once it leaves the ISATAP 373 domain. Therefore, implementing IPv6 security is required even if 374 IPv4 security is available. 376 The threats associated with IPv6 Neighbor Discovery are described in 377 [RFC3756]. 379 There is a possible spoofing attack in which spurious ip-protocol-41 380 packets are injected into an ISATAP link from outside. Since an 381 ISATAP link spans an entire IPv4 site, restricting access to the link 382 can be achieved by restricting access to the site, i.e., by having 383 site border routers implement IPv4 ingress filtering and 384 ip-protocol-41 filtering. 386 Another possible spoofing attack involves spurious ip-protocol-41 387 packets injected from within an ISATAP link by a node pretending to 388 be a router. The Potential Router List (PRL) provides a list of IPv4 389 addresses representing advertising ISATAP interfaces of routers that 390 hosts use in filtering decisions. Site administrators should ensure 391 that the PRL is kept up to date, and that the resolution mechanism 392 (see: section 9) cannot be subverted. 394 The use of temporary addresses [RFC3041] and Cryptographically 395 Generated Addresses [CGA] on ISATAP interfaces is outside the scope 396 of this specification. 398 11. IANA Considerations 400 The IANA is requested to specify the format for Modified EUI-64 401 address construction ([RFC3513], Appendix A) in the IANA Ethernet 402 Address Block. The text in Appendix B of this document is offered as 403 an example specification. The current version of the IANA registry 404 for Ether Types can be accessed at: 406 http://www.iana.org/assignments/ethernet-numbers 408 12. Acknowledgments 410 The ideas in this document are not original, and the authors 411 acknowledge the original architects. Portions of this work were 412 sponsored through SRI International internal projects and government 413 contracts. Government sponsors include Monica Farah-Stapleton and 414 Russell Langan (U.S. Army CECOM ASEO), and Dr. Allen Moshfegh (U.S. 415 Office of Naval Research). SRI International sponsors include Dr. 416 Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi 417 Sastry. 419 The following are acknowledged for providing peer review input: Jim 420 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 421 Ole Troan, Vlad Yasevich. 423 The following are acknowledged for their significant contributions: 424 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 425 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, 426 Markku Savela, Pekka Savola, Margaret Wasserman, Brian Zill. 428 The authors acknowledge the work of Quang Nguyen on "Virtual 429 Ethernet" under the guidance of Dr. Lixia Zhang that proposed very 430 similar ideas to those that appear in this document. This work was 431 first brought to the authors' attention on September 20, 2002. 433 Appendix A. Major Changes 435 Changes since version 21: 437 - incorporated proposed text from ISATAP Issue Tracker 438 issues 14, 22, 23 440 - revised section 6.3 to follow RFC 3056 precedent 442 - editorial changes 444 Changes since version 20: 446 - moved extensions into separate document. 448 - added Site Administration Considerations section. 450 - updated neighbor discovery, IANA considerations, security 451 considerations sections to match widely-deployed implementations. 453 Appendix B. Modified EUI-64 Addresses in the IANA Ethernet Address Block 455 Modified EUI-64 addresses ([RFC3513], section 2.5.1 and Appendix A) 456 in the IANA Ethernet Address Block are formed by concatenating the 457 24-bit IANA OUI (00-00-5E) with a 40-bit extension identifier and 458 inverting the "u" bit, i.e., the "u" bit is set to one (1) to 459 indicate universal scope and it is set to zero (0) to indicate local 460 scope. 462 Modified EUI-64 addresses have the following appearance in memory 463 (bits transmitted right-to-left within octets, octets transmitted 464 left-to-right): 466 0 23 63 467 | OUI | extension identifier | 468 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 470 When the first two octets of the extension identifier encode the 471 hexadecimal value 0xFFFE, the remainder of the extension identifier 472 encodes a 24-bit vendor-supplied id as follows: 474 0 23 39 63 475 | OUI | 0xFFFE | vendor-supplied id | 476 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx 478 When the first octet of the extension identifier encodes the 479 hexadecimal value 0xFE, the remainder of the extension identifier 480 encodes a 32-bit IPv4 address as follows: 482 0 23 31 63 483 | OUI | 0xFE | IPv4 address | 484 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 486 Normative References 488 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [STD13] Mockapetris, P., "Domain Names - Implementation and 492 Specification", STD 13, RFC 1035, November 1987. 494 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 495 (IPv6) Specification", RFC 2460, December 1998. 497 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 498 Discovery for IP Version 6 (IPv6)", RFC 2461, December 499 1998. 501 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 502 Autoconfiguration", RFC 2462, December 1998. 504 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 505 (IPv6) Addressing Architecture", RFC 3513, April 2003. 507 [MECH] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 508 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2, 509 Work in Progress, January 2004. 511 Informative References 513 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 514 over Non-Broadcast Multiple Access (NBMA) networks", RFC 515 2491, January 1999. 517 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 518 Networks", RFC 2492, January 1999. 520 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 521 Domains without Explicit Tunnels", RFC 2529, March 1999. 523 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 524 Stateless Address Autoconfiguration in IPv6", RFC 3041, 525 January 2001. 527 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 528 via IPv4 Clouds", RFC 3056, February 2001. 530 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 531 Discovery (ND) Trust Models and Threats", RFC 3756, May 532 2004. 534 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 535 draft-ietf-send-cga, Work in Progress, February 2004. 537 [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and 538 More-Specific Routes", draft-ietf-ipv6-router-selection, 539 Work in Progress, December 2003. 541 [NODEREQ] Loughney, J., "IPv6 Node Requirements", 542 draft-ietf-ipv6-node-requirements, 543 Work in Progress, May 2004. 545 Authors' Addresses 547 Fred L. Templin 548 Nokia 549 313 Fairchild Drive 550 Mountain View, CA 94110 551 US 553 Phone: +1 650 625 2331 554 EMail: ftemplin@iprg.nokia.com 556 Tim Gleeson 557 Cisco Systems K.K. 558 Shinjuku Mitsu Building 559 2-1-1 Nishishinjuku, Shinjuku-ku 560 Tokyo 163-0409 561 Japan 563 EMail: tgleeson@cisco.com 565 Mohit Talwar 566 Microsoft Corporation 567 One Microsoft Way 568 Redmond, WA 98052-6399 569 US 571 Phone: +1 425 705 3131 572 EMail: mohitt@microsoft.com 574 Dave Thaler 575 Microsoft Corporation 576 One Microsoft Way 577 Redmond, WA 98052-6399 578 US 580 Phone: +1 425 703 8835 581 EMail: dthaler@microsoft.com 583 Full Copyright Statement 585 Copyright (C) The Internet Society (2004). This document is subject 586 to the rights, licenses and restrictions contained in BCP 78 and 587 except as set forth therein, the authors retain all their rights. 589 This document and the information contained herein are provided on an 590 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 591 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 592 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 593 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 594 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 595 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 597 Intellectual Property 599 The IETF takes no position regarding the validity or scope of any 600 Intellectual Property Rights or other rights that might be claimed to 601 pertain to the implementation or use of the technology described in 602 this document or the extent to which any license under such rights 603 might or might not be available; nor does it represent that it has 604 made any independent effort to identify any such rights. Information 605 on the procedures with respect to rights in RFC documents can be 606 found in BCP 78 and BCP 79. 608 Copies of IPR disclosures made to the IETF Secretariat and any 609 assurances of licenses to be made available, or the result of an 610 attempt made to obtain a general license or permission for the use of 611 such proprietary rights by implementers or users of this 612 specification can be obtained from the IETF on-line IPR repository at 613 http://www.ietf.org/ipr. 615 The IETF invites any interested party to bring to its attention any 616 copyrights, patents or patent applications, or other proprietary 617 rights that may cover technology that may be required to implement 618 this standard. Please address the information to the IETF at 619 ietf-ipr@ietf.org. 621 Acknowledgment 623 Funding for the RFC Editor function is currently provided by the 624 Internet Society.