NGtrans T. Hain Internet Draft Microsoft Document: draft-hain-6to4-scaling-00.txt July 2000 Category: 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 mechanism for 6to4-router scaling described in the 6to4 draft [2][6to4] raises concerns when the matrix of IPv4 connected systems, communicating across to the native IPv6 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 the scenario for link-local addressing postulated in section 3.1. Hain Expires December 2000 1 6to4 router discovery and scaling July 2000 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 Terms..............................................................2 Overview and assumptions...........................................3 Scenarios..........................................................5 Fig. 1...........................................................5 Sequence Scenario 1:.............................................6 Sequence Scenario 2:.............................................7 NS syntax..........................................................9 NA syntax..........................................................9 Redirect syntax...................................................10 Protection from random redirects:...............................11 Additional Requirements...........................................11 Additional Thoughts...............................................12 Security Considerations...........................................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 (expanding slightly on the definitions in [6to4]) 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, but in all other respects it is a standard IPv6 host. Hain Expires December 2000 2 6to4 router discovery and scaling July 2000 Overview and assumptions The intent of this approach is to use the mechanism defined in [6to4] as a simplifier for providing IPv6 services to any node with a public IPv4 address. (While IPv4-compatible IPv6 addresses would be another option, there have been questions raised related to their use and the scaling impact on the IPv6 routing tables.) The technical aspects of creating the appropriate addresses are not an issue, but there is an area of concern related to discovery of the path from 6to4 nodes to native-IPv6 nodes. Several schemes have been proposed, and the approach described here does not preclude any of them. What it does is provide an alternative that automates the process on a massive scale, without requiring the 6to4 routers to participate directly in a global routing process. One way to look at this approach is an automated tunnel broker that is tied to the current routing infrastructure. Existing tunnel broker models expect manual interaction and basically set up a default route to the entire native IPv6 infrastructure. If the native IPv6 network partitions, the communications will fail even though the IPv4 network is intact. The approach presented here would theoretically allow for islands of native IPv6 to exist around the edge of the IPv4 cloud, as long as the regional relays know the current prefix to IPv4 mapping for the relays. Another way to look at this approach is a default route that only handles one packet per prefix, and then redirects each node directly attached to the IPv4 network to the appropriate native-IPv6-ISP 6to4-relay for subsequent packets. The default route approach works because from the perspective of the 6to4-router (or integrated host), the entire IPv4 Internet appears to be a single-subnet link-layer. While section 3.1 of [6to4] discusses the formation of addresses in a link-local context, it questions the utility of such addresses. The mechanism described here answers the question by taking advantage of the format for communicating with a well-known relay, as well as in the redirect messages sent by relays. A final point to make is that in addition to appearing as a single link-layer, the IPv4 Internet does not provide multicast to all points, so it should be considered an NBMA network. Since the IPv4 Internet appears to be a single link to 6to4 nodes, all rules in section 8 of [4][ND] apply to redirects described here, EXCEPT the one at the end of 8.2 that prohibits routers from updating routes based on redirects. It should also be noted that part of a previously reserved field is now defined. A basic assumption is that a 6to4 based IPv6 deployment will not rely on ANY support from IPv4 only ISP's. If a 6to4-relay (willing to take the traffic) exists, a site 6to4-router may be configured to use that path as the default route to the native IPv6 infrastructure through a tunnel broker, or other means. If there is no configured relay, the default behavior of 6to4-routers SHOULD be to use a well- Hain Expires December 2000 3 6to4 router discovery and scaling July 2000 known starting point to find a 6to4-relay that will get it to the native IPv6 endpoint. Another assumption is that each ISP providing native IPv6 services will be motivated to provide a relay service for their customers to communicate with 6to4 sites. At the same time, these ISPs will generally not want to be the 'default' route between 6to4 & 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). Once a 6to4-router (integrated host) acquires a prefix to relay mapping, it SHOULD send NS messages to maintain the mapping until idle for 2 lifetimes. To aid with scaling, there is no need for the relay to maintain a mapping to the 6to4-router (integrated host) as the required information is in the destination address of each packet header. Consumer systems (ie:dial-up) will be completely automated 6to4 integrated hosts. To make this automation work, a well-known relay service needs to exist and be capable of handling greater than 10M clients. This results in scaling issues that are comparable to the DNS root. Maintaining a static database with full IPv6 addresses of the current ISP relays is operationally complex. As only the IPv4 address are required when using link-local [FE80::IPv4] format addresses, this has better scaling properties for database maintenance. (The Anycast address [2002:IPv4::0] would be a comparable alternative, but redirect messages require use of a link- local address). The regional access relays described below are currently assumed to be geographical, but the native-IPv6-ISP ones they redirect to are assumed to be topologically near the native IPv6 end. Hain Expires December 2000 4 6to4 router discovery and scaling July 2000 Scenarios 1. A Consumer system 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 (non-2002::). The consumer system forwards the first packet to the well-known relay 6to4-relay.ipv6.org, and verifies the redirect it receives for the destination prefix. Further communications are directed to the native-IPv6-ISP 6to4- relay. NS messages SHOULD be sent to the native-IPv6-ISP 6to4-relay to maintain this Prefix / IPv4 address / Lifetime mapping until idle for at least two lifetimes. 2. An IPv6 only system initiates a connection to a 6to4 web site. The native-IPv6-ISP 6to4-relay extracts the IPv4 address from the destination IPv6 address, and tunnels per the 6to4 specification. The 6to4-router will use the response from the web site to establish the mapping between the native-IPv6 prefix, and its 6to4-relay via the well-known 6to4-relay. NS messages SHOULD be sent to the native- IPv6-ISP 6to4-relay to maintain this Prefix / IPv4 address / Lifetime mapping information until idle for at least two lifetimes. ----- ------------ | | | 6to4-relay.| | DNS | |AR.ipv6.org | ----- ------------ | | ------------- ------------ ----------- ---------- | Native IPv6 | | 6to4-relay | | IPv4 only | | Consumer | | system |-/-| IPv6 ISP |---| Internet |-/-| system | ------------- ------------ ----------- ---------- | ------------- ----- | 6to4-router | | Web | | |---| site| ------------- ----- ----- Fig. 1 Hain Expires December 2000 5 6to4 router discovery and scaling July 2000 Sequence Scenario 1: 1) The 6to4 process in a consumer system automatically looks up the IPv4 address of the well-known relay 6to4-relay.ipv6.org for any non-2002:: destination that does not match a prefix in the routing cache, using IPv4. 2) DNS returns a Cname based on the RIR of the requestors IPv4. 3) The 6to4 process then automatically looks up 6to4- relay.RIR.ipv6.org 4) DNS returns a traditional IPv4 round-robin for relays per region. 5) The 6to4 process uses 6to4 rules for link-local and tunnels the initial packet to the regional relay. 6) Regional Registries have collected IPv4 addresses of ISP 6to4-relays as each IPv6 prefix is allocated. 7) Regional access and ISP relays participate in the global BGP mesh. 8) Regional access relay sends IPv6 prefix-based redirect to the Consumer system, pointing it to the native-IPv6-ISP 6to4- relay having the longest match. It then forwards the original packet to the identified native-IPv6-ISP 6to4-relay. 9) The 6to4 process builds a routing table cache from the redirect messages. It first verifies the redirect through the new 'Tunnel Ident' field (IPv4 Identifier in original tunnel packet). Subsequent tunneling is based on longest match on prefix. Once it knows the neighbor, the 6to4-router, or integrated host, SHOULD send NS to the ISP relay it was redirected to for maintenance of the mapping. 10) The 6to4 process resends first packet, now tunneled to the native-IPv6-ISP 6to4-relay topologically closest to the native IPv6 end of this traffic flow. 11) Destination ISP relay forwards within the IPv6 network. (It SHOULD already be advertising the return route to 2002::/16.) 12) The Native-IPv6 system sends an Ack for first packet via the nearest relay advertising 2002::/16. 13) The Native-IPv6-ISP 6to4-relay extracts the IPv4 from destination in packet header and tunnels the packet across the IPv4 logical link. ------ Hain Expires December 2000 6 6to4 router discovery and scaling July 2000 Sequence Scenario 2: 1. The Native-IPv6 system looks up the name 6to4-web-site. 2. DNS MAY return a 2002:: record 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 native-IPv6-ISP 6to4-relay extracts the IPv4 from destination in packet header and tunnels the packet across the IPv4 logical link. 5. The 6to4-router for the web site forwards the packet to the destination web site. 6. The Web site sends an ACK via its 6to4-router. 7. The 6to4 process in the 6to4-router looks up the IPv4 address of the well-known relay 6to4-relay.ipv6.org for any non- 2002:: destination that does not match a prefix in the routing cache, using IPv4. 8. DNS returns a Cname based on the RIR of the requestors IPv4. 9. The 6to4 process then automatically looks up 6to4- relay.RIR.ipv6.org 10. DNS returns a traditional IPv4 round-robin for relays per region. 11. The 6to4 process uses 6to4 rules for link-local and tunnels the packet to the regional relay. 12. Regional Registries have collected IPv4 addresses of ISP 6to4-relays as each IPv6 prefix is allocated. 13. Regional access and ISP relays participate in the global BGP mesh. 14. Regional access relay sends IPv6 prefix-based redirect to the 6to4 router, pointing it to the native-IPv6-ISP 6to4-relay having the longest match. 15. The 6to4-router builds a routing table cache from the redirect messages. It first verifies the redirect through the new 'Tunnel Ident' field (IPv4 Identifier in original tunnel packet). Subsequent tunneling is based on longest match on prefix. Once it knows the neighbor, the 6to4-router, or integrated host, SHOULD send NS to the ISP relay it was redirected to for maintenance of the mapping. Hain Expires December 2000 7 6to4 router discovery and scaling July 2000 *** This creates a perceived problem : -router responding to redirect- Actually RFC 1812 [5][routerreq] 5.2.7.2 states 'MAY consider redirect when not running a routing protocol', which is the case at hand; at least with other parties involved with this logical link. 16. 6to4-router forwards to native-IPv6-ISP 6to4-relay based on the longest match. 17. Native-IPv6-ISP 6to4-relay forwards to Native-IPv6 system. ------- Hain Expires December 2000 8 6to4 router discovery and scaling July 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 (FE80::IPv4) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 December 2000 9 6to4 router discovery and scaling July 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 | Tunnel 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 'Tunnel Ident' is used for spoof protection, and is filled in from the Identity field from the IPv4 header of the 6to4 packet. Hain Expires December 2000 10 6to4 router discovery and scaling July 2000 Protection from random redirects: For simple spoof protection, the upper 16 bits of the 'Tunnel Ident' field (previously reserved) in the Redirected Header option are used to reflect the Identifier field from the outer IPv4 header of the original packet sent to the Regional Relay. 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. Additional Requirements Regional relays are run as ipv6.org named service by the Regional Internet Registries (RIRs). Registration of native-IPv6-ISP relays is handled through RIRs, because a trust model exists and it appears to be an easy addition to the allocation process. Regional relays SHOULD address scaling to support the number of directly attached IPv4 systems in their area, and forward any packets received to the same ISP relay it identified in the prefix- based redirect defined above. Severe rate limiting MAY be imposed to discourage 6to4-routers and integrated hosts from ignoring these redirect messages. 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-routers SHOULD establish NUD (as defined in section 3.8 of [6][mech]) with 6to4-relays they are redirected to, and avoid thrashing if multiple relays exist for a given prefix. The ISP 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 the an individual IPv4 address. 6to4-routers MAY choose to time out this 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 not directly identified via BGP. 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. Hain Expires December 2000 11 6to4 router discovery and scaling July 2000 Additional Thoughts Separate regional relays are not required if native-IPv6-ISPs are willing to have their relays act as the first packet top-level redirectors for non-customers. The only requirements are establishing who manages the round-robin DNS entries for each regions relay name; and that all systems in that list be participants in the global BGP mesh, as well as willing and capable of generating the prefix based redirects. Security Considerations 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 against the common infrastructure in the Regional Relays. If such an attack is detected the targeted relay MAY choose to stop forwarding packets and only issue redirects. This will impact application responsiveness as packets are discarded, but not as dramatically as loosing all ability to find the native IPv6 relays should the regional relays become inundated. Denial-of-service attacks against other components described here are beyond the scope of this document, as those components are not common infrastructure and their defense is a local matter. 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-06.txt, June 2000 3 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 [ND], Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for IP Version 6", RFC 2461, December 1998 5 [routerreq] Baker, F., "Requirements for IP Version 4 Routers", RFC-1812, June 1995 Hain Expires December 2000 12 6to4 router discovery and scaling July 2000 6 [mech], Nordmark, E., Gilligan, R. E., "Transition Mechanisms for IPv6 Hosts and Routers", April 14, 2000 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 December 2000 13