NGtrans T. Hain Internet Draft Microsoft Document: draft-hain-6to4-scaling-01.txt November 2000 Expires: May 2001 6to4-relay discovery and scaling Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The transition mechanism described in the 6to4 draft [2] [6to4] raises scaling concerns when the matrix of IPv4 connected 6to4- router systems, communicating across to the native IPv6 only connected systems, are on the order of tens to hundreds of millions. This document will address those concerns, offer additional mechanisms for resolving them, and identify use for the scenario of link-local addressing postulated in section 3.1. Hain Expires May 2001 1 6to4 router discovery and scaling November 2000 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 Conventions used in this document................................2 Terms..............................................................2 Overview...........................................................3 Basic assumptions................................................3 Mechanism..........................................................4 Scenarios..........................................................6 Fig. 1...........................................................6 Sequence Scenario 1:.............................................7 Sequence Scenario 2:.............................................7 Syntax.............................................................8 RS/RA option syntax..............................................8 NS syntax........................................................9 NA syntax........................................................9 Redirect syntax...................................................10 Additional Requirements...........................................11 Security Considerations...........................................11 Protection from random Router Advertisements:...................12 Protection from random redirects:...............................12 References........................................................12 Acknowledgments...................................................13 Author's Addresses................................................13 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. Terms 6to4-router: an IPv6 router supporting a 6to4 pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network. When not acting as a relay, it advertises [2002:IPv4::/48] as an attached prefix on IPv6 enabled interfaces. Relay router: a 6to4-router configured to support transit routing between 6to4 addresses and native IPv6 addresses. Advertises the [2002::/16] as an attached prefix on native IPv6 enabled interfaces. (referred to as 6to4-relay in this document) 6to4-normal host: an IPv6 host, which happens to have at least one 6to4 address learned from a 6to4-router. In all other respects it is a standard IPv6 host. 6to4-integrated host: an IPv6 host that generates at least one 6to4 address and supporting 6to4 pseudo-interface from an IPv4 address. It interacts directly with relays and remote routers, but in all other respects it is a standard IPv6 host. Hain Expires May 2001 2 6to4 router discovery and scaling November 2000 Overview This document discusses scaling concerns of the mechanism defined in [6to4]. The intent of this approach is to use the 6to4 mechanism as a simplifier for providing IPv6 services to any node with a public IPv4 address. (While IPv4-compatible IPv6 addresses are another option, that mechanism raises concerns related to the scaling impact on the native-IPv6 domain routing tables.) The technical aspects of creating the appropriate addresses are not an issue, but there is an area of concern related to simple discovery of the path from 6to4 nodes to native-IPv6 routing domain. Several schemes have been proposed, and the approach described here does not preclude any of them. Rather it provides an alternative that automates the process on a massive scale. Most importantly it does so without requiring the 6to4-routers to participate directly in a global routing process. As each 6to4-router potentially represents a unique administrative domain, the complexity of establishing routing protocols at this scale is directly contradictory to the goal of simplicity. A 6to4-router when not manually configured for routes, or participating in a routing protocol over the 6to4 interface, finds its route to the native IPv6 domain identically to a 6to4-integrated host, thus for the purposes of this mechanism it will follow host rules. To minimize confusion between routers that are configured or participating in a routing protocol, and to maintain the context that host rules apply, the rest of this document will use the term '6to4-integrated host' when referring to hosts and routers that are automatically deriving the path to the native-IPv6 domain. Basic assumptions 1. A 6to4 based IPv6 deployment will not rely on ANY support from local IPv4 only ISP's. 2. Consumer systems will be completely automated 6to4-itegrated hosts. To make this automation work, a well-known relay service needs to exist and be capable of handling greater than 10M clients. 3. Greater than 10M nodes participating in a global EGP routing process would create additional scaling concerns. 4. From the perspective of the 6to4-integrated host, the entire IPv4 Internet appears to be a single-subnet NBMA link-layer. 5. RA's from 6to4-relay routers are solicited only. 6. Prefix options in the RA on the 6to4 subnet are invalid. Hain Expires May 2001 3 6to4 router discovery and scaling November 2000 Mechanism While it is reasonable to expect that each ISP providing native-IPv6 services will be motivated to provide a relay service for their customers to communicate with 6to4 sites, it is also expected that these ISPs will generally not want to be the 'default' route between 6to4 and native-IPv6 infrastructures. They will also not be excited about managing a massive manually configured tunnel array (no matter which end the manual effort is applied to). Automatic determination of a router on a link is normally accomplished via link scope multicast to the all-routers address (FF02::2). Since the IPv4 fabric appears as a logical NBMA link to 6to4-integrated hosts, identifying a router (specifically a 6to4- relay router) on that link requires a non-multicast techniques. One such technique would be use of a MARS system as defined in RFC 2491 [4]. This approach is administratively complex for the needs of router discovery, but may be appropriate in some environments. Another technique that maps well with the need for simplicity is changing the discovery logic to use the subnet-router anycast address. From RFC 2373 [5]: 'Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets which they have interfaces.' Using the anycast address is normally intended for off-link purposes, and on-link use is complicated due to the lack of a mapping to a link layer address. For the purposes of 6to4, there is a defined mapping to the IPv4 anycast for 6to4-relay routers as defined in [6] [6to4any]. This also resolves the unknown state raised in section 3.1 of [6to4]. While RFC 2491 defines IPv6 over NBMA networks, it is not a goal here to emulate multicast over the 6to4 Internet link. The goal here is to enable non-multicast based discovery. RFC 2526 [7] defines the subnet-router anycast as the subnet prefix followed by 0's. In this case, 2002::/128 identifies the IPv6 subnet-router anycast for any router on the IPv4 Internet logical link. This is not particularly useful, but further refinement to find the subset of routers that are acting as the relay to the native-IPv6 routing domain results in 2002:IPv4anycast::/128. Section 4.1 of [6to4any] defines the Default route in the 6to4 routers (::/0) as pointing to the 6to4 IPv6 anycast address. This SHOULD be the pre-configured state of the 6to4-integrated host, and treated as an alternate once an explicit 6to4-relay router is learned. Following the rules in section 6.3.7 of [8] [ND] (except destination address), to discover a 6to4-relay router a 6to4-integrated host sends a Router Solicitation message to the IPv6anycast/IPv4anycast using a source as the local 6to4 address. The nearest (IPv4 routing wise) 6to4-relay router will return the Router Advertisement from Hain Expires May 2001 4 6to4 router discovery and scaling November 2000 its individual address fe80::IPv4/IPv4 to the scope consistent fe80::IPv4/IPv4 of the 6to4-integrated host. This is necessary to comply with RFC 2461 section 6, which requires RA to be sourced from link local addresses. When a router has been discovered, normal unicast NUD processing is preformed. When this router has been determined unreachable, the process begins again to find a new relay. While that is taking place a 6to4-integrated host MAY choose to map all off-link destinations in its neighbor cache to the relay anycast, allowing any available relay to forward traffic, but SHOULD override those when a new 6to4- relay is learned to provide immunity to potential routing instability. There is no need for any 6to4-relay to maintain neighbor state with the 6to4-integrated hosts, as the required information for path determination is in the destination address of each packet header. The router lifetime in the RA SHOULD be set to update interval for the routing protocol in the native IPv6 domain, but MAY be set shorter. In any case, it MUST NOT be set to a period greater than the routing update interval. Since the IPv4 network appears as a link layer, all existing link layer rules apply including redirect. To reduce the volume of misdirected traffic, the redirect SHOULD apply to an entire prefix when known. Given the 6to4-relay routers MUST be participating in a routing protocol ([6to4] 5.2.3) to send routing entries for 2002::/16 into the native IPv6 network, they may be learning about other 6to4-relay routers and their attached prefix. In this case, a 6to4-relay MAY choose to send a redirect to the 6to4-integrated host for that prefix to optimize traffic flow symmetry. All rules in section 8 of [ND] apply to redirects described here, EXCEPT the one at the end of 8.2 that prohibits routers from updating routes based on redirects. This rule only applies when the 6to4-router is participating in a routing protocol, or there are configured routes over that interface. Note that for spoof protection part of a previously reserved field is now defined. As an alternative, simple devices MAY choose to set the neighbor cache entry for all native-IPv6 domain destinations to the IPv4anycast. If this option is chosen, there is no black-hole detection, and the packet sequence is subject to routing flaps. Another scaling issue is the expectation that all sources of RA's are trusted, or there is an SA for AH between each router and host. While this is reasonable for physical link technologies in a common administrative domain, a new mechanism is required to support logical link technologies like 6to4 where a logical link spans multiple administrative boundaries. A new option (6) is defined for both the RS and RA to provide some protection from spoofs by passing a random 16-bit value generated and verified by the 6to4-integrated host. Hain Expires May 2001 5 6to4 router discovery and scaling November 2000 Scenarios 1. A Consumer system (6to4-integrated host) dials into their preferred ISP and only receives IPv4 service. Using the 6to4 mechanisms as defined, the system creates IPv6 addresses for its interface. Later an application attempts to connect to a system that is connected to a native IPv6 network (global non-2002::). If no other entry exists, the consumer system forwards the first packet to the 6to4-relay anycast, and also sends an RS to that address. It uses the RA to update its default route, and any redirect it receives for the destination prefix. Further communications to systems sharing that prefix are directed to the learned 6to4-relay. NS messages SHOULD be sent to all known 6to4-relays to maintain the Prefix / IPv4 address / Lifetime mapping until the path is idle for at least two lifetimes, or the 6to4-relay is determined to be unreachable. 2. An IPv6 only system in the native-IPv6 domain initiates a connection to a web server in a 6to4 site. The nearest 6to4-relay extracts the IPv4 address from the destination IPv6 address, and tunnels per the 6to4 specification. The 6to4-router will use this inbound packet to establish a neighbor entry in the incomplete state, and then use the response from the web server to complete the mapping between the native-IPv6 prefix, and its 6to4-relay. The 6to4-router SHOULD send NS messages to the 6to4-relay to maintain this Prefix / IPv4 address / Lifetime mapping information until the path is idle for at least two lifetimes, or the 6to4-relay is determined to be unreachable. ------------- ------------ ----------- ------------- | Native IPv6 | | 6to4-relay | | IPv4 only | | 6to4-router | | system |-/-| IPv6 ISP |---| Internet |-/-| | ------------- ------------ ----------- ------------- | | ----------------- ----- | 6to4-integrated | | Web | | host | | site| ----------------- ----- ----- Fig. 1 Hain Expires May 2001 6 6to4 router discovery and scaling November 2000 Sequence Scenario 1: 1) The 6to4 process in a 6to4-integrated host automatically sends packets for any global non-2002:: destination (that does not match a prefix in the routing cache) to the 6to4- relay anycast along with an RS. 2) The nearest 6to4-relay returns an RA from its unique IPv4, and forwards packets within the IPv6 network. (It SHOULD already be advertising the return route to 2002::/16) 3) The 6to4-integrated host establishes NUD with the 6to4-relay. 4) The 6to4 process in the 6to4-integrated host builds a routing table cache from the redirect messages. It first verifies the redirect through the new 'Relay Ident' field (IPv4 Identifier in original tunnel packet). Subsequent tunneling is based on longest match on prefix. 5) The native-IPv6 system sends Ack's via the nearest relay advertising 2002::/16. 6) The native-IPv6 domain 6to4-relay extracts the IPv4 from destination in packet header and tunnels the packet across the IPv4 logical link. 7) The 6to4 process sends subsequent packets to the learned native-IPv6 domain 6to4-relay until it is determined unreachable. ------ Sequence Scenario 2: 1. The Native-IPv6 system looks up the name 6to4-web-site. 2. In this case DNS will return a 2002:: record, which MAY be in a traditional round-robin for the web site. 3. The native-IPv6 system sends its first packet via the nearest relay advertising 2002::/16. 4. The 6to4-relay extracts the IPv4 from destination in packet header and tunnels the packet across the IPv4 logical link using the 6to4 rules. 5. The 6to4-router for the web site forwards the packet to the destination web site, and creates an INCOMPLETE entry in its neighbor cache for the 6to4-relay. 6. The Web site sends an ACK via its 6to4-router. Hain Expires May 2001 7 6to4 router discovery and scaling November 2000 7. The 6to4 process in the 6to4-router completes the neighbor entry by sending an NS to the 6to4-relay. 8. The 6to4-router builds a routing table cache from the redirect messages. It first verifies the redirect through the new 'Relay Ident' field (IPv4 Identifier in original tunnel packet). Subsequent tunneling is based on longest match on prefix. *** This creates a perceived problem because a router is responding to redirect. *** Actually RFC 1812 [9][routerreq] 5.2.7.2 states 'MAY consider redirect when not running a routing protocol', which is the case at hand; at least across this logical link. 9. 6to4-router forwards packets to the appropriate 6to4-relay based on the longest match. 10. The 6to4-relay forwards to Native-IPv6 system. ------- Syntax RS/RA option syntax 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (6) | Length (1) | Relay Ident | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Relay Ident - 16 bit random number for spoof protection in RA and redirect Hain Expires May 2001 8 6to4 router discovery and scaling November 2000 NS syntax 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (135) | Code (0) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Target Address (2002::IPv4anycast) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2) | Length (1) | MUST be 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Layer Address (IPv4 of 6to4-router) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NA syntax 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (136) | Code (1) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Target Address (FE80::IPv4) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2) | Length (1) | MUST be 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Layer Address (IPv4 of 6to4-relay) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (3) | Length (4) | Prefix Length |L|A| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Prefix (from table for this target) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code is set to 1 to identify new message with prefix information R-bit is set as the 6to4-relay is logically a router S-bit is set in response to solicitation O-bit is cleared to prevent thrashing Hain Expires May 2001 9 6to4 router discovery and scaling November 2000 Redirect syntax (Expands scope for redirect from host to prefix) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (137) | Code (0) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Target Address (FE80::IPv4) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Destination Address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2) | Length (1) | MUST be 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Layer Address (IPv4 of 6to4-relay) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (3) | Length (4) | Prefix Length |L|A| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Prefix (from table for this target) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (4) | Length | Relay Ident | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IP header + data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP header + data is the original packet truncated to ensure that the size of the redirect message does not exceed 1280 octets. Valid lifetime and Preferred lifetime are set to the time remaining until next scheduled BGP update 'Relay Ident' is used for spoof protection, and is filled in from the 16 bits sent in the RS, also used in the Identity field of the IPv4 header of the 6to4 packet. Hain Expires May 2001 10 6to4 router discovery and scaling November 2000 Additional Requirements IPv4 anycast address range assigned for this purpose. 6to4 integrated hosts, routers, and relays MUST recognize and respond to ICMP messages targeted for [FE80::IPv4] that are received on the 6to4 interface. 6to4-integrated hosts SHOULD establish NUD (as defined in section 3.8 of [10][mech]) with 6to4-relays they are redirected to, and avoid thrashing if multiple relays exist for a given prefix. The 6to4-relays MAY establish NUD with the routers if desired, though this will create scaling concerns with the only marginal benefit being the rapid removal of access to nodes behind an individual IPv4 address. 6to4-integrated hosts MAY choose to time out a prefix entry if there is no traffic for two valid lifetimes. 6to4-relays SHOULD address scaling for both traffic handling and NUD exchanges. 6to4-relays MAY send prefix based redirects to provide load balancing among relays or optimize routing symmetry. Neighbor solicitation (type 135) is sent when the lifetime expires. The 6to4-relay SHOULD answer if it is still willing to forward with a Neighbor Advertisement (type 136) including the options defined for redirect. Security Considerations While the 6to4 subnet appears to be a single logical link layer it has an unusual characteristic where the members of the subnet are in different administrative and trust domains. Despite this, this document does not introduce any new security concerns, and attempts to add some level of protection from spoofed redirects received over the 6to4 interface. Basic protection from spoofed redirects is provided unless the routing path infrastructure is penetrated. Additional protection of the redirect is possible using IPsec. This approach is not used by default, as the case where it is necessary is rare, and the cost is relatively high. Denial-of-Service attacks are possible on 6to4-routers by consuming resources when they create INCOMPLETE state neighbor cache entries. This problem can be mitigated by aggressively clearing the entry if the state does not change due to valid traffic. Hain Expires May 2001 11 6to4 router discovery and scaling November 2000 Protection from random Router Advertisements: Simple spoof protection from random RA's is provided by passing a 16 bit random number through the RS / RA messages. This new option effectively requires access to the packet path to generate a valid spoof. Protection from random redirects: Simple spoof protection for redirects use the upper 16 bits of the 'Relay Ident' field (previously RESERVED) in the Redirected Header option are used to reflect the Identifier field from the outer IPv4 header of the original RS packet. This combined with the original packet contents mitigate guessing or flooding attacks, and virtually require access to the packet path to generate a valid spoof. References 1 [RFC-2026], Bradner, S., " The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 [6to4], Carpenter, B., "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-07.txt, September 2000 3 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 [RFC 2491], Armitage, G., "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999 5 [RFC 2373], Hinden, B., Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998 6 [6to4any], Huitema, C., "An anycast prefix for 6to4 relay routers", draft-huitema-6to4anycast-00.txt, November 2000 7 [RFC 2526], Johnson, D., Deering, S., "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999 8 [ND], Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for IP Version 6", RFC 2461, December 1998 9 [routerreq] Baker, F., "Requirements for IP Version 4 Routers", RFC-1812, June 1995 10 [mech], Nordmark, E., Gilligan, R. E., "Transition Mechanisms for IPv6 Hosts and Routers", April 14, 2000 Hain Expires May 2001 12 Acknowledgments Thanks for critique of this document provided by Christian Huitema, David Thaler, Fred Baker and Brian Carpenter. Author's Addresses Tony Hain Microsoft One Microsoft Way Redmond, Wa. USA 98052 Email: tonyhain@microsoft.com Hain Expires May 2001 13