idnits 2.17.1 draft-ietf-ngtrans-isatap-21.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.5 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 600. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 568), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 5) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 (April 16, 2004) is 7309 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) ** 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 (~~), 5 warnings (==), 7 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 Expires: October 16, 2004 T. Gleeson 4 Cisco Systems K.K. 5 M. Talwar 6 D. Thaler 7 Microsoft Corporation 8 April 16, 2004 10 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 11 draft-ietf-ngtrans-isatap-21.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 16, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects 42 IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network 43 as a link layer for IPv6 and views other nodes on the network as 44 potential IPv6 hosts/routers. ISATAP supports an automatic tunneling 45 abstraction similar to the Non-Broadcast, Multiple Access (NBMA) 46 model. 48 1. Introduction 50 This document specifies a simple mechanism called the Intra-Site 51 Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 52 hosts/routers over IPv4 networks. Dual-stack (IPv6/IPv4) nodes use 53 ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP 54 views the IPv4 network as a link layer for IPv6 and views other nodes 55 on the network as potential IPv6 hosts/routers. 57 ISATAP enables automatic tunneling whether global or private IPv4 58 addresses are used, and presents a Non-Broadcast, Multiple Access 59 (NBMA) abstraction similar to [RFC2491][RFC2492][RFC2529][RFC3056]. 61 The main objectives of this document are to: 1) describe the domain 62 of applicability, 2) specify addressing requirements, 3) specify 63 automatic tunneling using ISATAP, 4) specify the operation of IPv6 64 Neighbor Discovery over ISATAP interfaces, and 5) discuss Site 65 Administration, Security and IANA considerations. 67 2. Requirements 69 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 70 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 71 document, are to be interpreted as described in [BCP14]. 73 This document also makes use of internal conceptual variables to 74 describe protocol behavior and external variables that an 75 implementation must allow system administrators to change. The 76 specific variable names, how their values change, and how their 77 settings influence protocol behavior are provided to demonstrate 78 protocol behavior. An implementation is not required to have them in 79 the exact form described here, so long as its external behavior is 80 consistent with that described in this document. 82 3. Terminology 84 The terminology of [RFC2460][RFC2461] applies to this document. The 85 following additional terms are defined: 87 ISATAP node: 88 a node that implements the specifications in this document. 90 ISATAP interface: 91 an ISATAP node's point-to-multipoint IPv6 interface used for 92 automatic tunneling of IPv6 packets in IPv4. 94 ISATAP interface identifier: 95 an IPv6 interface identifier with an embedded IPv4 address 96 constructed as specified in section 6.1. 98 ISATAP address: 99 an IPv6 unicast address that matches an on-link prefix on an 100 ISATAP interface of the node, and includes an ISATAP interface 101 identifier. 103 locator: 104 an IPv4 address-to-interface mapping, i.e., a node's IPv4 address 105 and its associated interface. 107 locator set: 108 a set of locators associated with an ISATAP interface, where each 109 locator in the set belongs to the same site. 111 4. Domain of Applicability 113 The domain of applicability for this technical specification is 114 automatic tunneling of IPv6 packets in IPv4 for ISATAP nodes within 115 sites that observe the Security Considerations found in this 116 document, including host-to-router, router-to-host, and host-to-host 117 automatic tunneling in certain enterprise networks and 3GPP/3GPP2 118 wireless operator networks. (Other scenarios with sufficient trust 119 basis ensured by the mechanisms specified in this document also fall 120 within this domain of applicability.) 122 Extensions to the above domain of applicability (e.g., by combining 123 the mechanisms in this document with other technical specifications) 124 are out of scope. 126 5. Node Requirements 128 ISATAP nodes observe the common functionality requirements for IPv6 129 nodes found in [NODEREQ] and the requirements for dual IP layer 130 operation found in ([MECH], section 2). They also implement the 131 additional features specified in this document. 133 6. Addressing Requirements 135 6.1 ISATAP Interface Identifiers 137 ISATAP interface identifiers are constructed in Modified EUI-64 138 format ([RFC3513], section 2.5.1 and appendix A) by concatenating the 139 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 140 32-bit IPv4 address in network byte order as follows: 142 |0 1|1 3|3 6| 143 |0 5|6 1|2 3| 144 +----------------+----------------+--------------------------------+ 145 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm| 146 +----------------+----------------+--------------------------------+ 148 When the IPv4 address is known to be globally unique, the "u" bit 149 (universal/local) is set to 1; otherwise, the "u" bit is set to 0. 150 "g" is the individual/group bit, and "m" are the bits of the IPv4 151 address. 153 6.2 ISATAP Interface Address Configuration 155 Each ISATAP interface configures a set of locators consisting of IPv4 156 address-to-interface mappings from a single site, i.e., an ISATAP 157 interface's locator set MUST NOT span multiple sites. 159 When an IPv4 address is removed from an interface, the corresponding 160 locator SHOULD be removed from its associated locator set(s). When a 161 new IPv4 address is assigned to an interface, the corresponding 162 locator MAY be added to the appropriate locator set(s). 164 ISATAP interfaces form ISATAP interface identifiers from IPv4 165 addresses in their locator set and use them to create link-local 166 ISATAP addresses ([RFC2462], section 5.3). 168 6.3 Multicast/Anycast 170 ISATAP interfaces recognize a node's required IPv6 multicast/anycast 171 addresses ([RFC3513], section 2.8). 173 7. Automatic Tunneling 175 ISATAP interfaces use the basic tunneling mechanisms specified in 176 ([MECH], section 3). The following additional specifications are also 177 used: 179 7.1 Handling ICMPv4 Errors 181 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 182 errors as link-specific information indicating that a path to a 183 neighbor may have failed ([RFC2461], section 7.3.3). 185 7.2 Decapsulation 187 The specification in ([MECH], section 3.6) is used. Additionally, 188 when an ISATAP node receives an IPv4 protocol 41 datagram that does 189 not belong to a configured tunnel interface, it determines whether 190 the packet's IPv4 destination address and arrival interface match a 191 locator configured in an ISATAP interface's locator set. 193 If an ISATAP interface that configures a matching locator is found, 194 the decapsulator MUST verify that the packet's IPv4 source address is 195 correct for the encapsulated IPv6 source address. The IPv4 source 196 address is correct if: 198 - the IPv6 source address is an ISATAP address that embeds the 199 IPv4 source address in its interface identifier, or: 201 - the IPv4 source address is a member of the Potential Router 202 List (see: section 8.1). 204 Packets for which the IPv4 source address is incorrect for this 205 ISATAP interface are checked to determine whether they belong to 206 another tunnel interface. 208 7.3 Link-Local Addresses 210 ISATAP interfaces use link local addresses constructed as specified 211 in section 6 of this document. 213 7.4 Neighbor Discovery over Tunnels 215 ISATAP interfaces use the specifications for neighbor discovery found 216 in the following section of this document. 218 8. Neighbor Discovery for ISATAP Interfaces 220 ISATAP nodes use the neighbor discovery mechanisms specified in 221 [RFC2461] to create/change neighbor cache entries. ISATAP interfaces 222 also implement the following specifications: 224 8.1 Conceptual Model Of A Host 226 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 227 ISATAP interfaces add: 229 Potential Router List (PRL) 230 A set of entries about potential routers; used to support router 231 and prefix discovery. Each entry ("PRL(i)") has an associated 232 timer ("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that 233 represents a router's advertising ISATAP interface. 235 8.2 Router and Prefix Discovery - Router Specification 237 Advertising ISATAP interfaces send Solicited Router Advertisement 238 messages as specified in ([RFC2461], section 6.2.6) except that the 239 messages are sent directly to the soliciting node, i.e., they might 240 not be received by other nodes on the link. 242 8.3 Router and Prefix Discovery - Host Specification 244 The Host Specification in ([RFC2461], section 6.3) is used. ISATAP 245 interfaces add the following specifications: 247 8.3.1 Host Variables 249 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 250 interfaces add: 252 PrlRefreshInterval 253 Time in seconds between successive refreshments of the PRL after 254 initialization. The designated value of all 1's (0xffffffff) 255 represents infinity. 256 Default: 3600 seconds 258 MinRouterSolicitInterval 259 Minimum time in seconds between successive solicitations of the 260 same advertising ISATAP interface. The designated value of all 1's 261 (0xffffffff) represents infinity. 263 8.3.2 Potential Router List Initialization 265 ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses 266 discovered via manual configuration, a DNS fully-qualified domain 267 name (FQDN) [STD13], a DHCPv4 option, a DHCPv4 vendor-specific 268 option, or an unspecified alternate method. FQDNs are established via 269 manual configuration or an unspecified alternate method. FQDNs are 270 resolved into IPv4 addresses through a static host file lookup, 271 querying the DNS service, querying a site-specific name service, or 272 an unspecified alternate method. 274 After initializing an ISATAP interface's PRL, the node sets a timer 275 for the interface to PrlRefreshInterval seconds and re-initializes 276 the interface's PRL as specified above when the timer expires. When a 277 FQDN is used, and when it is resolved via a service that includes 278 TTLs with the IPv4 addresses returned (e.g., DNS 'A' resource records 279 [STD13]), the timer SHOULD be set to the minimum of 280 PrlRefreshInterval and the minimum TTL returned. (Zero-valued TTLs 281 are interpreted to mean that the PRL is re-initialized before each 282 Router Solicitation event - see: section 8.3.4). 284 8.3.3 Processing Received Router Advertisements 286 To the list of checks for validating Router Advertisement messages 287 ([RFC2461], section 6.1.1), ISATAP interfaces add: 289 - IP Source Address is a link-local ISATAP address that embeds 290 V4ADDR(i) for some PRL(i). 292 Valid Router Advertisements received on an ISATAP interface are 293 processed as specified in ([RFC2461], section 6.3.4). 295 8.3.4 Sending Router Solicitations 297 To the list of events after which Router Solicitation messages may be 298 sent ([RFC2461], section 6.3.7), ISATAP interfaces add: 300 - TIMER(i) for some PRL(i) expires. 302 Since unsolicited Router Advertisements may be incomplete and/or 303 absent, ISATAP nodes MAY schedule periodic Router Solicitation events 304 for certain PRL(i)'s by setting the corresponding TIMER(i). 306 When periodic Router Solicitation events are scheduled, the node 307 SHOULD set TIMER(i) such that the next event will refresh remaining 308 lifetimes stored for PRL(i) before they expire, including the Router 309 Lifetime, Valid Lifetimes received in Prefix Information Options, and 310 Route Lifetimes received in Route Information Options [DEFLT]. 312 TIMER(i) MUST be set to no less than MinRouterSolicitInterval seconds 313 where MinRouterSolicitInterval is configurable for the node, or for a 314 specific PRL(i), with a conservative default value (e.g. 2 minutes). 316 When TIMER(i) expires, the node sends Router Solicitation messages as 317 specified in ([RFC2461], section 6.3.7) except that the messages are 318 sent directly to PRL(i), i.e., they might not be received by other 319 routers. While the node continues to require periodic Router 320 Solicitation events for PRL(i), and while PRL(i) continues to act as 321 a router, the node resets TIMER(i) after each expiration event as 322 described above. 324 8.4 Address Resolution 326 The specification in ([RFC2461], section 7.2) is used. ISATAP 327 addresses for which the neighbor's link-layer address cannot 328 otherwise be determined (e.g., from a neighbor cache entry) are 329 resolved to link-layer addresses by a static computation, i.e., the 330 last four octets are treated as an IPv4 address. 332 Hosts SHOULD perform an initial reachability confirmation by sending 333 Neighbor Solicitation message(s) and receiving a Neighbor 334 Advertisement message. Routers MAY perform this initial reachability 335 confirmation, but this might not scale in all environments. 337 8.5 Neighbor Unreachability Detection 339 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 340 section 7.3). Routers MAY perform neighbor unreachability detection, 341 but this might not scale in all environments. 343 9. Site Administration Considerations 345 Site administrators maintain a Potential Router List (PRL) of IPv4 346 addresses representing advertising ISATAP interfaces of routers. 348 The PRL is commonly maintained as a FQDN for the ISATAP service in 349 the site's name service (see: section 8.3.2). There are no mandatory 350 rules for the selection of the FQDN, but site administrators are 351 encouraged to use the convention "isatap.domainname" (e.g., 352 isatap.example.com). 354 When the site's name service includes TTLs with the IPv4 addresses 355 returned, site administrators SHOULD configure the TTLs with 356 conservative values to minimize control traffic. 358 10. Security considerations 360 Implementors should be aware that, in addition to possible attacks 361 against IPv6, security attacks against IPv4 must also be considered. 362 Use of IP security at both IPv4 and IPv6 levels should nevertheless 363 be avoided, for efficiency reasons. For example, if IPv6 is running 364 encrypted, encryption of IPv4 would be redundant except if traffic 365 analysis is felt to be a threat. If IPv6 is running authenticated, 366 then authentication of IPv4 will add little. Conversely, IPv4 367 security will not protect IPv6 traffic once it leaves the ISATAP 368 domain. Therefore, implementing IPv6 security is required even if 369 IPv4 security is available. 371 The threats associated with IPv6 Neighbor Discovery are described in 372 [SENDPS]. 374 There is a possible spoofing attack in which spurious ip-protocol-41 375 packets are injected into an ISATAP link from outside. Since an 376 ISATAP link spans an entire IPv4 site, restricting access to the link 377 can be achieved by restricting access to the site, i.e., by having 378 site border routers implement IPv4 ingress filtering and 379 ip-protocol-41 filtering. 381 Another possible spoofing attack involves spurious ip-protocol-41 382 packets injected from within an ISATAP link by a node pretending to 383 be a router. The Potential Router List (PRL) provides a list of IPv4 384 addresses representing advertising ISATAP interfaces of routers that 385 hosts use in filtering decisions. Site administrators should ensure 386 that the PRL is kept up to date, and that the resolution mechanism 387 (see: section 9) cannot be subverted. 389 The use of temporary addresses [RFC3041] and Cryptographically 390 Generated Addresses [CGA] on ISATAP interfaces is outside the scope 391 of this specification. 393 11. IANA Considerations 395 The IANA is requested to specify the format for Modified EUI-64 396 address construction ([RFC3513], Appendix A) in the IANA Ethernet 397 Address Block. The text in Appendix B of this document is offered as 398 an example specification. The current version of the IANA registry 399 for Ether Types can be accessed at: 401 http://www.iana.org/assignments/ethernet-numbers 403 12. Acknowledgments 405 The ideas in this document are not original, and the authors 406 acknowledge the original architects. Portions of this work were 407 sponsored through SRI International internal projects and government 408 contracts. Government sponsors include Monica Farah-Stapleton and 409 Russell Langan (U.S. Army CECOM ASEO), and Dr. Allen Moshfegh (U.S. 410 Office of Naval Research). SRI International sponsors include Dr. 411 Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi 412 Sastry. 414 The following are acknowledged for providing peer review input: Jim 415 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 416 Ole Troan, Vlad Yasevich. 418 The following are acknowledged for their significant contributions: 419 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 420 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka 421 Savola, Margaret Wasserman, Brian Zill. 423 The authors acknowledge the work of Quang Nguyen on "Virtual 424 Ethernet" under the guidance of Dr. Lixia Zhang that proposed very 425 similar ideas to those that appear in this document. This work was 426 first brought to the authors' attention on September 20, 2002. 428 Appendix A. Major Changes since version 20: 430 - moved extensions into separate document. 432 - added Site Administration Considerations section. 434 - updated neighbor discovery, IANA considerations, security 435 considerations sections to match widely-deployed implementations. 437 Appendix B. Modified EUI-64 Addresses in the IANA Ethernet Address Block 439 Modified EUI-64 addresses ([RFC3513], section 2.5.1 and Appendix A) 440 in the IANA Ethernet Address Block are formed by concatenating the 441 24-bit IANA OUI (00-00-5E) with a 40-bit extension identifier and 442 inverting the "u" bit, i.e., the "u" bit is set to one (1) to 443 indicate universal scope and it is set to zero (0) to indicate local 444 scope. 446 Modified EUI-64 addresses have following appearance in memory (bits 447 transmitted right-to-left within octets, octets transmitted left-to- 448 right): 450 0 23 63 451 | OUI | extension identifier | 452 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 454 When the first two octets of the extension identifier encode the 455 hexadecimal value 0xFFFE, the remainder of the extension identifier 456 encodes a 24-bit vendor-supplied id as follows: 458 0 23 39 63 459 | OUI | 0xFFFE | vendor-supplied id | 460 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx 462 When the first octet of the extension identifier encodes the 463 hexadecimal value 0xFE, the remainder of the extension identifier 464 encodes a 32-bit IPv4 address as follows: 466 0 23 31 63 467 | OUI | 0xFE | IPv4 address | 468 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 470 Normative References 472 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [STD13] Mockapetris, P., "Domain Names - Implementation and 476 Specification", STD 13, RFC 1035, November 1987. 478 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 479 (IPv6) Specification", RFC 2460, December 1998. 481 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 482 for IP Version 6 (IPv6)", RFC 2461, December 1998. 484 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 485 Autoconfiguration", RFC 2462, December 1998. 487 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 488 (IPv6) Addressing Architecture", RFC 3513, April 2003. 490 [MECH] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 491 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2, Work in 492 Progress, January 2004. 494 Informative References 496 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 497 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, 498 January 1999. 500 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 501 Networks", RFC 2492, January 1999. 503 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 504 Domains without Explicit Tunnels", RFC 2529, March 1999. 506 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless 507 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 509 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 510 IPv4 Clouds", RFC 3056, February 2001. 512 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 513 draft-ietf-send-cga, Work in Progress, February 2004. 515 [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and 516 More-Specific Routes", draft-ietf-ipv6-router-selection, Work in 517 Progress, December 2003. 519 [NODEREQ] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node- 520 requirements, Work in Progress, January 2004. 522 [SENDPS] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 523 Discovery Trust Models and Threats", draft-ietf-send-psreq, Work in 524 Progress, October 2003. 526 Authors' Addresses 528 Fred L. Templin 529 Nokia 530 313 Fairchild Drive 531 Mountain View, CA 94110 532 US 534 Phone: +1 650 625 2331 535 EMail: ftemplin@iprg.nokia.com 537 Tim Gleeson 538 Cisco Systems K.K. 539 Shinjuku Mitsu Building 540 2-1-1 Nishishinjuku, Shinjuku-ku 541 Tokyo 163-0409 542 Japan 544 EMail: tgleeson@cisco.com 546 Mohit Talwar 547 Microsoft Corporation 548 One Microsoft Way 549 Redmond, WA 98052-6399 550 US 552 Phone: +1 425 705 3131 553 EMail: mohitt@microsoft.com 555 Dave Thaler 556 Microsoft Corporation 557 One Microsoft Way 558 Redmond, WA 98052-6399 559 US 561 Phone: +1 425 703 8835 562 EMail: dthaler@microsoft.com 564 Full Copyright Statement 566 Copyright (C) The Internet Society (2004). This document is subject to 567 the rights, licenses and restrictions contained in BCP 78 and except as 568 set forth therein, the authors retain all their rights. 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 572 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 573 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 574 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 575 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Intellectual Property 580 The IETF takes no position regarding the validity or scope of any 581 Intellectual Property Rights or other rights that might be claimed to 582 pertain to the implementation or use of the technology described in this 583 document or the extent to which any license under such rights might or 584 might not be available; nor does it represent that it has made any 585 independent effort to identify any such rights. Information on the 586 procedures with respect to rights in RFC documents can be found in BCP 587 78 and BCP 79. 589 Copies of IPR disclosures made to the IETF Secretariat and any 590 assurances of licenses to be made available, or the result of an attempt 591 made to obtain a general license or permission for the use of such 592 proprietary rights by implementers or users of this specification can be 593 obtained from the IETF on-line IPR repository at 594 http://www.ietf.org/ipr. 596 The IETF invites any interested party to bring to its attention any 597 copyrights, patents or patent applications, or other proprietary rights 598 that may cover technology that may be required to implement this 599 standard. Please address the information to the IETF at ietf- 600 ipr@ietf.org. 602 Acknowledgment 604 Funding for the RFC Editor function is currently provided by the 605 Internet Society.