idnits 2.17.1 draft-ietf-ngtrans-isatap-23.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 586), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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. -------------------------------------------------------------------------------- 1 Network Working Group F. Templin 2 Internet-Draft Nokia 3 December 10, 2004 T. Gleeson 4 Expires: June 10, 2005 Cisco Systems K.K. 5 M. Talwar 6 D. Thaler 7 Microsoft Corporation 9 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 10 draft-ietf-ngtrans-isatap-23.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 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 29 http://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 June 10, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects 43 IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network 44 as a link layer for IPv6 and views other nodes on the network as 45 potential IPv6 hosts/routers. ISATAP supports an automatic tunneling 46 abstraction similar to the Non-Broadcast Multiple Access (NBMA) 47 model. 49 1. Introduction 51 This document specifies a simple mechanism called the Intra-Site 52 Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 53 hosts/routers over IPv4 networks. Dual-stack (IPv6/IPv4) nodes use 54 ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP 55 views the IPv4 network as a link layer for IPv6 and views other nodes 56 on the network as potential IPv6 hosts/routers. 58 ISATAP enables automatic tunneling whether global or private IPv4 59 addresses are used, and presents a Non-Broadcast Multiple Access 60 (NBMA) abstraction similar to [RFC2491][RFC2492][RFC2529][RFC3056]. 62 The main objectives of this document are to: 1) describe the domain 63 of applicability, 2) specify addressing requirements, 3) specify 64 automatic tunneling using ISATAP, 4) specify the operation of IPv6 65 Neighbor Discovery over ISATAP interfaces, and 5) discuss Site 66 Administration, Security and IANA considerations. 68 2. Requirements 70 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 71 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 72 document, are to be interpreted as described in [BCP14]. 74 This document also makes use of internal conceptual variables to 75 describe protocol behavior and external variables that an 76 implementation must allow system administrators to change. The 77 specific variable names, how their values change, and how their 78 settings influence protocol behavior are provided to demonstrate 79 protocol behavior. An implementation is not required to have them in 80 the exact form described here, so long as its external behavior is 81 consistent with that described in this document. 83 3. Terminology 85 The terminology of [RFC2460][RFC2461] applies to this document. The 86 following additional terms are defined: 88 ISATAP node: 89 a node that implements the specifications in this document. 91 ISATAP interface: 92 an ISATAP node's non-broadcast multi-access (NBMA) IPv6 interface 93 used for automatic tunneling of IPv6 packets in IPv4. 95 ISATAP interface identifier: 96 an IPv6 interface identifier with an embedded IPv4 address 97 constructed as specified in section 6.1. 99 ISATAP address: 100 an IPv6 unicast address that matches an on-link prefix on an 101 ISATAP interface of the node, and includes an ISATAP interface 102 identifier. 104 locator: 105 an IPv4 address-to-interface mapping, i.e., a node's IPv4 address 106 and its associated interface. 108 locator set: 109 a set of locators associated with an ISATAP interface, where each 110 locator in the set belongs to the same site. 112 4. Domain of Applicability 114 The domain of applicability for this technical specification is 115 automatic tunneling of IPv6 packets in IPv4 for ISATAP nodes within 116 sites that observe the Security Considerations found in this 117 document, including host-to-router, router-to-host, and host-to-host 118 automatic tunneling in certain enterprise networks and 3GPP/3GPP2 119 wireless operator networks. (Other scenarios with sufficient trust 120 basis ensured by the mechanisms specified in this document also fall 121 within this domain of applicability.) 123 Extensions to the above domain of applicability (e.g., by combining 124 the mechanisms in this document with other technical specifications) 125 are out of scope. 127 5. Node Requirements 129 ISATAP nodes observe the common functionality requirements for IPv6 130 nodes found in [NODEREQ] and the requirements for dual IP layer 131 operation found in ([MECH], section 2). They also implement the 132 additional features specified in this document. 134 6. Addressing Requirements 136 6.1 ISATAP Interface Identifiers 138 ISATAP interface identifiers are constructed in Modified EUI-64 139 format ([RFC3513], section 2.5.1 and appendix A) by concatenating the 140 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 141 32-bit IPv4 address in network byte order as follows: 143 |0 1|1 3|3 6| 144 |0 5|6 1|2 3| 145 +----------------+----------------+--------------------------------+ 146 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm| 147 +----------------+----------------+--------------------------------+ 149 When the IPv4 address is known to be globally unique, the "u" bit 150 (universal/local) is set to 1; otherwise, the "u" bit is set to 0. 151 "g" is the individual/group bit, and "m" are the bits of the IPv4 152 address. 154 6.2 ISATAP Interface Address Configuration 156 Each ISATAP interface configures a set of locators consisting of IPv4 157 address-to-interface mappings from a single site, i.e., an ISATAP 158 interface's locator set MUST NOT span multiple sites. 160 When an IPv4 address is removed from an interface, the corresponding 161 locator SHOULD be removed from its associated locator set(s). When a 162 new IPv4 address is assigned to an interface, the corresponding 163 locator MAY be added to the appropriate locator set(s). 165 ISATAP interfaces form ISATAP interface identifiers from IPv4 166 addresses in their locator set and use them to create link-local 167 ISATAP addresses ([RFC2462], section 5.3). 169 6.3 Multicast/Anycast 171 It is not possible to assume the general availability of wide-area 172 IPv4 multicast, so (unlike 6over4 [RFC2529]) ISATAP must assume only 173 unicast capability in its underlying IPv4 carrier network. Support 174 for IPv6 multicast over ISATAP interfaces is not described in this 175 document. 177 Similarly, support for Reserved IPv6 Subnet Anycast Addresses is not 178 described in this document. 180 7. Automatic Tunneling 182 ISATAP interfaces use the basic tunneling mechanisms specified in 183 ([MECH], section 3). The following additional specifications are also 184 used: 186 7.1 Encapsulation 188 ISATAP addresses are mapped to a link-layer address by a static 189 computation, i.e., the last four octets are treated as an IPv4 190 address. 192 7.2 Handling ICMPv4 Errors 194 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 195 errors as link-specific information indicating that a path to a 196 neighbor may have failed ([RFC2461], section 7.3.3). 198 7.3 Decapsulation 200 The specification in ([MECH], section 3.6) is used. Additionally, 201 when an ISATAP node receives an IPv4 protocol 41 datagram that does 202 not belong to a configured tunnel interface, it determines whether 203 the packet's IPv4 destination address and arrival interface match a 204 locator configured in an ISATAP interface's locator set. 206 If an ISATAP interface that configures a matching locator is found, 207 the decapsulator MUST verify that the packet's IPv4 source address is 208 correct for the encapsulated IPv6 source address. The IPv4 source 209 address is correct if: 211 - the IPv6 source address is an ISATAP address that embeds the 212 IPv4 source address in its interface identifier, or: 214 - the IPv4 source address is a member of the Potential Router 215 List (see: section 8.1). 217 Packets for which the IPv4 source address is incorrect for this 218 ISATAP interface are checked to determine whether they belong to 219 another tunnel interface. 221 7.4 Link-Local Addresses 223 ISATAP interfaces use link local addresses constructed as specified 224 in section 6 of this document. 226 7.5 Neighbor Discovery over Tunnels 228 ISATAP interfaces use the specifications for neighbor discovery found 229 in the following section of this document. 231 8. Neighbor Discovery for ISATAP Interfaces 233 ISATAP interfaces use the neighbor discovery mechanisms specified in 234 [RFC2461] and also implement the following specifications: 236 8.1 Conceptual Model Of A Host 238 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 239 ISATAP interfaces add: 241 Potential Router List (PRL) 242 A set of entries about potential routers; used to support router 243 and prefix discovery. Each entry ("PRL(i)") has an associated 244 timer ("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that 245 represents a router's advertising ISATAP interface. 247 8.2 Router and Prefix Discovery - Router Specification 249 Advertising ISATAP interfaces send Solicited Router Advertisement 250 messages as specified in ([RFC2461], section 6.2.6) except that the 251 messages are sent directly to the soliciting node, i.e., they might 252 not be received by other nodes on the link. 254 8.3 Router and Prefix Discovery - Host Specification 256 The Host Specification in ([RFC2461], section 6.3) is used. ISATAP 257 interfaces add the following specifications: 259 8.3.1 Host Variables 261 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 262 interfaces add: 264 PrlRefreshInterval 265 Time in seconds between successive refreshments of the PRL after 266 initialization. The designated value of all 1's (0xffffffff) 267 represents infinity. 268 Default: 3600 seconds 270 MinRouterSolicitInterval 271 Minimum time in seconds between successive solicitations of the 272 same advertising ISATAP interface. The designated value of all 1's 273 (0xffffffff) represents infinity. 275 8.3.2 Potential Router List Initialization 277 ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses 278 discovered via manual configuration, a DNS fully-qualified domain 279 name (FQDN) [STD13], a DHCPv4 option, a DHCPv4 vendor-specific 280 option, or an unspecified alternate method. FQDNs are established via 281 manual configuration or an unspecified alternate method. FQDNs are 282 resolved into IPv4 addresses through a static host file lookup, 283 querying the DNS service, querying a site-specific name service, or 284 an unspecified alternate method. 286 After initializing an ISATAP interface's PRL, the node sets a timer 287 for the interface to PrlRefreshInterval seconds and re-initializes 288 the interface's PRL as specified above when the timer expires. When 289 an FQDN is used, and when it is resolved via a service that includes 290 TTLs with the IPv4 addresses returned (e.g., DNS 'A' resource records 291 [STD13]), the timer SHOULD be set to the minimum of 292 PrlRefreshInterval and the minimum TTL returned. (Zero-valued TTLs 293 are interpreted to mean that the PRL is re-initialized before each 294 Router Solicitation event - see: section 8.3.4). 296 8.3.3 Processing Received Router Advertisements 298 To the list of checks for validating Router Advertisement messages 299 ([RFC2461], section 6.1.1), ISATAP interfaces add: 301 - IP Source Address is a link-local ISATAP address that embeds 302 V4ADDR(i) for some PRL(i). 304 Valid Router Advertisements received on an ISATAP interface are 305 processed as specified in ([RFC2461], section 6.3.4). 307 8.3.4 Sending Router Solicitations 309 To the list of events after which Router Solicitation messages may be 310 sent ([RFC2461], section 6.3.7), ISATAP interfaces add: 312 - TIMER(i) for some PRL(i) expires. 314 Since unsolicited Router Advertisements may be incomplete and/or 315 absent, ISATAP nodes MAY schedule periodic Router Solicitation events 316 for certain PRL(i)'s by setting the corresponding TIMER(i). 318 When periodic Router Solicitation events are scheduled, the node 319 SHOULD set TIMER(i) such that the next event will refresh remaining 320 lifetimes stored for PRL(i) before they expire, including the Router 321 Lifetime, Valid Lifetimes received in Prefix Information Options, and 322 Route Lifetimes received in Route Information Options [DEFLT]. 323 TIMER(i) MUST be set to no less than MinRouterSolicitInterval seconds 324 where MinRouterSolicitInterval is configurable for the node, or for a 325 specific PRL(i), with a conservative default value (e.g., 2 minutes). 327 When TIMER(i) expires, the node sends Router Solicitation messages as 328 specified in ([RFC2461], section 6.3.7) except that the messages are 329 sent directly to PRL(i), i.e., they might not be received by other 330 routers. While the node continues to require periodic Router 331 Solicitation events for PRL(i), and while PRL(i) continues to act as 332 a router, the node resets TIMER(i) after each expiration event as 333 described above. 335 8.4 Neighbor Unreachability Detection 337 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 338 section 7.3). Routers MAY perform neighbor unreachability detection, 339 but this might not scale in all environments. 341 After address resolution, hosts SHOULD perform an initial 342 reachability confirmation by sending Neighbor Solicitation message(s) 343 and receiving a Neighbor Advertisement message. Routers MAY perform 344 this initial reachability confirmation, but this might not scale in 345 all environments. 347 9. Site Administration Considerations 349 Site administrators maintain a Potential Router List (PRL) of IPv4 350 addresses representing advertising ISATAP interfaces of routers. 352 The PRL is commonly maintained as an FQDN for the ISATAP service in 353 the site's name service (see: section 8.3.2). There are no mandatory 354 rules for the selection of the FQDN, but site administrators are 355 encouraged to use the convention "isatap.domainname" (e.g., 356 isatap.example.com). 358 When the site's name service includes TTLs with the IPv4 addresses 359 returned, site administrators SHOULD configure the TTLs with 360 conservative values to minimize control traffic. 362 10. Security considerations 364 Implementors should be aware that, in addition to possible attacks 365 against IPv6, security attacks against IPv4 must also be considered. 366 Use of IP security at both IPv4 and IPv6 levels should nevertheless 367 be avoided, for efficiency reasons. For example, if IPv6 is running 368 encrypted, encryption of IPv4 would be redundant except if traffic 369 analysis is felt to be a threat. If IPv6 is running authenticated, 370 then authentication of IPv4 will add little. Conversely, IPv4 371 security will not protect IPv6 traffic once it leaves the ISATAP 372 domain. Therefore, implementing IPv6 security is required even if 373 IPv4 security is available. 375 The threats associated with IPv6 Neighbor Discovery are described in 376 [RFC3756]. 378 There is a possible spoofing attack in which spurious ip-protocol-41 379 packets are injected into an ISATAP link from outside. Since an 380 ISATAP link spans an entire IPv4 site, restricting access to the link 381 can be achieved by restricting access to the site, i.e., by having 382 site border routers implement IPv4 ingress filtering and 383 ip-protocol-41 filtering. 385 Another possible spoofing attack involves spurious ip-protocol-41 386 packets injected from within an ISATAP link by a node pretending to 387 be a router. The Potential Router List (PRL) provides a list of IPv4 388 addresses representing advertising ISATAP interfaces of routers that 389 hosts use in filtering decisions. Site administrators should ensure 390 that the PRL is kept up to date, and that the resolution mechanism 391 (see: section 9) cannot be subverted. 393 The use of temporary addresses [RFC3041] and Cryptographically 394 Generated Addresses [CGA] on ISATAP interfaces is outside the scope 395 of this specification. 397 11. IANA Considerations 399 The IANA is requested to specify the format for Modified EUI-64 400 address construction ([RFC3513], Appendix A) in the IANA Ethernet 401 Address Block. The text in Appendix B of this document is offered as 402 an example specification. The current version of the IANA registry 403 for Ether Types can be accessed at: 405 http://www.iana.org/assignments/ethernet-numbers 407 12. Acknowledgments 409 The ideas in this document are not original, and the authors 410 acknowledge the original architects. Portions of this work were 411 sponsored through SRI International internal projects and government 412 contracts. Government sponsors include Monica Farah-Stapleton and 413 Russell Langan (U.S. Army CECOM ASEO), and Dr. Allen Moshfegh (U.S. 414 Office of Naval Research). SRI International sponsors include Dr. 415 Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi 416 Sastry. 418 The following are acknowledged for providing peer review input: Jim 419 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 420 Ole Troan, Vlad Yasevich. 422 The following are acknowledged for their significant contributions: 423 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 424 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, 425 Markku Savela, Pekka Savola, Margaret Wasserman, Brian Zill. 427 The authors acknowledge the work of Quang Nguyen on "Virtual 428 Ethernet" under the guidance of Dr. Lixia Zhang that proposed very 429 similar ideas to those that appear in this document. This work was 430 first brought to the authors' attention on September 20, 2002. 432 Appendix A. Major Changes 434 Changes since version 21: 436 - incorporated proposed text from ISATAP Issue Tracker 437 issues 14, 22, 23 439 - revised section 6.3 to follow RFC 3056 precedent 441 - editorial changes 443 Changes since version 20: 445 - moved extensions into separate document. 447 - added Site Administration Considerations section. 449 - updated neighbor discovery, IANA considerations, security 450 considerations sections to match widely-deployed implementations. 452 Appendix B. Modified EUI-64 Addresses in the IANA Ethernet Address Block 454 Modified EUI-64 addresses ([RFC3513], section 2.5.1 and Appendix A) 455 in the IANA Ethernet Address Block are formed by concatenating the 456 24-bit IANA OUI (00-00-5E) with a 40-bit extension identifier and 457 inverting the "u" bit, i.e., the "u" bit is set to one (1) to 458 indicate universal scope and it is set to zero (0) to indicate local 459 scope. 461 Modified EUI-64 addresses have the following appearance in memory 462 (bits transmitted right-to-left within octets, octets transmitted 463 left-to-right): 465 0 23 63 466 | OUI | extension identifier | 467 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 469 When the first two octets of the extension identifier encode the 470 hexadecimal value 0xFFFE, the remainder of the extension identifier 471 encodes a 24-bit vendor-supplied id as follows: 473 0 23 39 63 474 | OUI | 0xFFFE | vendor-supplied id | 475 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx 477 When the first octet of the extension identifier encodes the 478 hexadecimal value 0xFE, the remainder of the extension identifier 479 encodes a 32-bit IPv4 address as follows: 481 0 23 31 63 482 | OUI | 0xFE | IPv4 address | 483 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 485 Normative References 487 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [STD13] Mockapetris, P., "Domain Names - Implementation and 491 Specification", STD 13, RFC 1035, November 1987. 493 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 494 (IPv6) Specification", RFC 2460, December 1998. 496 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 497 Discovery for IP Version 6 (IPv6)", RFC 2461, December 498 1998. 500 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 501 Autoconfiguration", RFC 2462, December 1998. 503 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 504 (IPv6) Addressing Architecture", RFC 3513, April 2003. 506 [MECH] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 507 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2, 508 Work in Progress, January 2004. 510 Informative References 512 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 513 over Non-Broadcast Multiple Access (NBMA) networks", RFC 514 2491, January 1999. 516 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 517 Networks", RFC 2492, January 1999. 519 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 520 Domains without Explicit Tunnels", RFC 2529, March 1999. 522 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 523 Stateless Address Autoconfiguration in IPv6", RFC 3041, 524 January 2001. 526 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 527 via IPv4 Clouds", RFC 3056, February 2001. 529 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 530 Discovery (ND) Trust Models and Threats", RFC 3756, May 531 2004. 533 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 534 draft-ietf-send-cga, Work in Progress, February 2004. 536 [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and 537 More-Specific Routes", draft-ietf-ipv6-router-selection, 538 Work in Progress, December 2003. 540 [NODEREQ] Loughney, J., "IPv6 Node Requirements", 541 draft-ietf-ipv6-node-requirements, 542 Work in Progress, May 2004. 544 Authors' Addresses 546 Fred L. Templin 547 Nokia 548 313 Fairchild Drive 549 Mountain View, CA 94110 550 US 552 Phone: +1 650 625 2331 553 EMail: ftemplin@iprg.nokia.com 555 Tim Gleeson 556 Cisco Systems K.K. 557 Shinjuku Mitsu Building 558 2-1-1 Nishishinjuku, Shinjuku-ku 559 Tokyo 163-0409 560 Japan 562 EMail: tgleeson@cisco.com 564 Mohit Talwar 565 Microsoft Corporation 566 One Microsoft Way 567 Redmond, WA 98052-6399 568 US 570 Phone: +1 425 705 3131 571 EMail: mohitt@microsoft.com 573 Dave Thaler 574 Microsoft Corporation 575 One Microsoft Way 576 Redmond, WA 98052-6399 577 US 579 Phone: +1 425 703 8835 580 EMail: dthaler@microsoft.com 582 Full Copyright Statement 584 Copyright (C) The Internet Society (2004). This document is subject 585 to the rights, licenses and restrictions contained in BCP 78 and 586 except as set forth therein, the authors retain all their rights. 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 591 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 592 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 593 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Intellectual Property 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Acknowledgment 622 Funding for the RFC Editor function is currently provided by the 623 Internet Society.