IETF M. Richardson Internet Draft February 2001 Connection of IPv6 Domains via NAPT IPv4 Clouds Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract draft-ietf-richardson-ngtrans-6to4udp-01.txt This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution. The document is a near wholesale rip off of RFC3056. The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently can assign at least one globally unique IPv4 address and UDP port number, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain native IPv6 connectivity. It incidentally provides an interim globally unique IPv6 address prefix to any site with at least one globally unique IPv4 address/UDP port combination, particularly when the active host is behind an uncooperative IPv4 Network Address Port Translator (NAPT). Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Table of Contents: Status of this Memo.............................................1 1. Introduction.................................................4 1.1. Terminology................................................5 2. IPv6 Prefix Allocation.......................................6 2.1 Address Selection...........................................7 3. Encapsulation in IPv4........................................7 3.1. Link-Local Address and NUD.................................8 4. Maximum Transmission Unit....................................8 5. Unicast scenarios, scaling, and transition to normal prefixes9 5.1 Simple scenario - all sites work the same...................9 5.2 Mixed scenario with relay to native IPv6...................10 5.2.1 Variant scenario with ISP relay..........................12 5.2.2 Summary of relay router configuration....................12 5.2.2.1. BGP4+ not used........................................13 5.2.2.2. BGP4+ used............................................13 5.2.2.3. Relay router scaling..................................13 5.2.3 Unwilling to relay.......................................14 5.3 Sending and decapsulation rules............................14 5.4 Variant scenario with tunnel to IPv6 space.................14 5.5 Fragmented Scenarios.......................................15 5.6 Multihoming................................................17 5.7 Transition considerations..................................17 5.8 Coexistence with firewall, NAT or RSIP.....................17 5.9 Usage within Intranets.....................................18 5.10 Summary of impact on routing..............................18 5.11. Routing loop prevention..................................19 6. Multicast and Anycast.......................................19 7. ICMP messages...............................................19 8. IANA considerations.........................................20 9. Security considerations.....................................20 Acknowledgements...............................................20 References.....................................................22 Authors' Addresses.............................................23 Intellectual Property..........................................23 Full Copyright Statement.......................................23 Acknowledgement................................................24 1. Introduction This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution. The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. It also describes scenarios for using such prefixes during the co-existence phase of IPv4 to IPv6 transition. Note that the mechanism described here is considered to be a twice interim measure. It is intended for hosts that need IPv6 connectivity despite occasionally being located behind Network Address Port Translators. It is intended that such locations should eventually offer native IPv6 address allocation via the normal IPv6 mechanisms. They may get their IPv6 prefixes via the straight 6to4 mechanism, or via normal allocation. Note that these scenarios are only part of the total picture of transition to IPv6. Also note that this is considered to be an interim solution and that sites should migrate when possible to native IPv6 prefixes and native IPv6 connectivity. This will be possible as soon as the site's ISP offers native IPv6 connectivity. The basic mechanism described in the present document, which applies to sites rather than individual hosts, will scale indefinitely by limiting the number of sites served by a given relay router (see Section 5.2). It will introduce no new entries in the IPv4 routing table, and exactly one new entry in the native IPv6 routing table (see Section 5.10). Although the mechanism is specified for an IPv6 site, it will typically be be applied to an individual IPv6 host or very small site located behind a Network Address Port Translator (NAPT) that is not under the site's control, but which will pass UDP/IPv4 packets out. For example, a IPv6 user located in a hotel, airport, or other temporary connection. The motivation for this method is to allow isolated IPv6 sites or hosts, attached to a wide area network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration. IPv6 sites or hosts connected using this method do not require IPv4- compatible IPv6 addresses [MECH] or configured tunnels. In this way IPv6 gains considerable independence of the underlying wide area network and can step over many hops of IPv4 subnets. The abbreviated name of this mechanism is 6to4udp (not to be confused with [6OVER4] or 6to4). The 6to4udp mechanism is typically implemented almost entirely in hosts. It depends only upon NAPT having relatively weak security properties (see XXX). Sections 2 to 4 of this document specify the 6to4udp scheme technically. Section 5 discusses some, but not all, usage scenarios. Scenarioes for routing aspects are not discussed, as this is generally considered to be a host function. Sections 6 to 9 discuss other general considerations. 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 [RFC2119]. 1.1. Terminology The terminology of [IPV6] applies to this document. 6to4udp pseudo-interface: 6to4udp encapsulation of IPv6 packets inside IPv4 UDP packets occurs at a point that is logically equivalent to an IPv6 interface, with the link layer being the IPv4 UDP unicast network. This point is referred to as a pseudo-interface. Some implementors may treat it exactly like any other interface and others may treat it like a tunnel end-point. 6to4udp prefix: an IPv6 prefix constructed according to the rule in Section 2 below. 6to4udp address: an IPv6 address constructed using a 6to4udp prefix. Native IPv6 address: an IPv6 address constructed using another type of prefix than 6to4udp. 6to4udp router (or 6to4udp border router): an IPv6 router supporting a 6to4udp pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network. 6to4udp host: an IPv6 host which happens to have at least one 6to4udp address. In all other respects it is a standard IPv6 host. Note: an IPv6 node may in some cases use a 6to4udp address for a configured tunnel. Such a node may function as an IPv6 host using a 6to4udp address on its configured tunnel interface, and it may also serve as a IPv6 router for other hosts via a 6to4udp pseudo-interface, but these are distinct functions. 6to4udp site: a site running IPv6 internally using 6to4udp addresses, therefore containing at least one 6to4udp host and at least one 6to4udp router. Relay router: a 6to4udp router configured to support transit routing between 6to4udp addresses and native IPv6 addresses. 6to4udp exterior routing domain: a routing domain interconnecting a set of 6to4udp routers and relay routers. It is distinct from an IPv6 site's interior routing domain, and distinct from all native IPv6 exterior routing domains. 2. IPv6 Prefix Allocation Suppose that a subscriber host can send UDP packets out to the world that the world will see to have a unique 32-bit IPv4 address and unique 16-bit UDP source port number. This is true of directly connected hosts (with non-private addresses), and also true for hosts with RFC1918 assigned addresses that are behind Network Address Port Translator (NAPT). While the host will emit, for instance, 192.168.1.1, UDP port 1234, the world will see the address of the NAPT, call it V4ADDR with a new UDP source port, call it V4PORT. The NAPT will arrange for replies to this port to be forwarded to the host with the private network address. At this time, the IANA has not yet assigned a permanent 13-bit IPv4 Top Level Aggregator. For the purposes of this document, assume that they will. For simplicity, assume that it will assign 0x0003, i.e. it will can be expressed as 2003::/16 when expresses as an IPv6 address prefix. The subscriber site is then deemed to have the following IPv6 address prefix, without any further assignment procedures being necessary: Prefix length: 64 bits Format prefix: 001 TLA value: 0x0003 NLA value: V4ADDR SLA value: V4PORT This is illustrated as follows: | 3 | 13 | 32 | 16 | 64 bits | +---+------+-----------+--------+--------------------------------+ |FP | TLA | V4ADDR | V4PORT | Interface ID | |001|0x0003| | | | +---+------+-----------+--------+--------------------------------+ Thus, this prefix has exactly the same format as normal /64 prefixes assigned according to [AGGR]. It can be abbreviated as 2003:V4ADDR:V4PORT::/64. Within the subscriber site it can be used exactly like any other valid IPv6 prefix, e.g., for automated address assignment and discovery according to the normal mechanisms such as [CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism [6OVER4]. Note that if the IPv4 address is assigned dynamically, the corresponding IPv6 prefix will also be dynamic in nature, with the same lifetime. In general, a directly connected host will be able to see determine the values for V4ADDR and V4PORT. A host behind a NAPT will need to know the values that the NAPT will assign. As there may in fact be multiple layers of NAPT, and these may not be visible to the host, a discovery mechanism is needed. 2.1 Address Discovery To discovery the appropriate values for V4ADDR and V4PORT, a pre-configured server is need to correspond with. This server does not need to be capable of relaying any traffic to other native IPv6 prefixes, although there is no reason that it may not also be a relay router. The essential feature of this server is that it has a globally unique IPv4 address and listens on a well known IPv4 UDP port number. This server is termed the "UDP echo server" IANA permitting, it will listen on udp port 0x2003 (8195 decimal). To discover V4ADDR and V4PORT, a host sends a specially marked UDP packet with source port set to 0x2003 to the UDP echo server. The UDP echo server listens for packets with this mark, and when it sees them, it replies to them, putting the source address and source port that it has observed into the payload of the packet. When the client host gets the response, it examines the provided copies of V4ADDR and V4PORT and compares them against what it used. If there is no difference, then there is no NAPT between itself and the chosen relay node. It should not use 6to4udp to configure a primary address, although it may decide to become a local relay. If there is a difference only in V4ADDR, then it may be behind a Network Address Translator, in which case, standard 6to4 may be useable. Otherwise, it now knows the values for V4ADDR and V4PORT. Further, it has created some translation state on the NAPT. The client should send periodic requests to the echo server to: 1) maintain the translation state on the NAPT 2) detect if V4ADDR/V4PORT has changed #2 might be due to a reboot of the NAPT, a physical topology change, or some other expiration of the NAPT state. Either of these can be treated as having moved to a new foreign address with the use of mobile IPv6 to maintain a connection. The details of the packets are described in section 5.2/5.3. 2.2 Address Selection To ensure the correct operation of 6to4udp in complex topologies, source and destination address selection must be appropriately implemented. If the source IPv6 host sending a packet has at least one 2003:: address assigned to it, and if the set of IPv6 addresses returned by the DNS for the destination host contains at least one 2003:: address, then the source host must make an appropriate choice of the source and destination addresses to be used. The mechanisms for address selection in general are under study at the time of writing [SELECT]. Subject to those general mechanisms, the principle that will normally allow correct operation of 6to4 is this: If one host has only a 6to4udp address, and the other one has both a 6to4udp and a native IPv6 address, then the 6to4udp address should be used for both. (Note, for the purposes of 6to4udp, a straight 6to4 address is considered to be a "native" address) If both hosts have a 6to4udp address and a native IPv6 address, then either the 6to4udp address should be used for both, or the native IPv6 address should be used for both. The choice should be configurable. The default configuration should be native IPv6 for both. 3. Encapsulation in IPv4 IPv6 packets from a 6to4 site are encapsulated in IPv4 UDP payloads when they leave the site via its external IPv4 connection. Note that the IPv4 interface that is carrying the 6to4udp traffic is notionally equivalent to an IPv6 interface, and is referred to below as a pseudo-interface, although this phrase is not intended to define an implementation technique. IPv6 packets are transmitted in IPv4 UDP payloads [RFC 791],[RFC 768] with an IPv4 protocol type of 17, and a destination port number of 0x2003. This mechanism is not compatible with [MECH] for IPv6 packets that are tunneled inside of IPv4 frames. It is for this reason that straight 6to4 is preferred whenever possible. The IPv4 header contains the Destination and Source IPv4 addresses. Once the packet arrives on the globally unique, one or both of these will be identical to the V4ADDR field of an IPv6 prefix formed as specified above (see section 5 for more details). When the packet leaves a client host, it should have whatever the locally appropriate private network address that it was assigned in the source. When the packet arrives back at a client, it should have whatever the locally appropriate private network address that was assigned in the destination field. Following the IPv4 header, a UDP packet header. The destination port should be 0x2003. The source port should be V4PORT when on the globally unique Internet. The IPv4 UDP packet body contains the IPv6 header and payload. The UDP length and checksum fields should be calculated as per [RFC 768] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol 17 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP source port | UDP destination port 0x2003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP length | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ The IPv4 Time to Live will be set as normal [RFC 791], as will the encapsulated IPv6 hop limit [IPv6]. Other considerations are as described in Section 4.1.2 of [MECH]. 3.1. Link-Local Address and NUD The link-local address of a 6to4udp pseudo-interface performing 6to4 encapsulation would, if needed, be formed as described in Section 3.7 of [MECH]. However, no scenario is known in which such an address would be useful, since a peer 6to4udp gateway cannot determine the appropriate link-layer (IPv4) address to send to. Neighbor Unreachability Detection (NUD) is handled as described in Section 3.8 of [MECH]. 3.2. Address Discovery Packet An address discovery packet is sent from a client to the echo server to request an echo of V4ADDR and V4PORT values. It is formed as follows: The UDP length and checksum fields should be calculated as per [RFC 768] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol 17 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP source port 0x2003 | UDP destination port 0x2003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP length | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 4|0 0 0 1| cookie | +-------+-------+-----------------------------------------------+ 3.3. Address Responses Packet An address response packet is sent from a echo server to the client. The destination address and port numbers should be taken from the address discovery packet's source address and source port. They should not be assumed to be 0x2003. The UDP length and checksum fields should be calculated as per [RFC 768] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol 17 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP source port 0x2003 | UDP destination port ABCD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP length | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 4|0 0 0 2| cookie | +-------+-------+-----------------------------------------------+ | Source Address of Discovery packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP source port of discovery | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Maximum Transmission Unit MTU size considerations are as described for tunnels in [MECH]. If the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. This may confuse NAPT devices. It is suggested a maximum IPv6 MTU of 1400 be used. The IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating IPv4 header. 5. Unicast scenarios, scaling, and transition to normal prefixes 5.1 Simple scenario - all sites work the same The simplest deployment scenario for 6to4udp is to use it between a number of sites, each of which has at least one connection to a shared IPv4 Internet. This could be the global Internet, or it could be a corporate IP network. In the case of the global Internet, there is no requirement that the sites all connect to the same Internet service provider. The only requiremement is that any of the sites is able to send IPv4 UDP packets with source or destination port 0x2003 to any of the others. By definition, each site has an IPv6 prefix in the format defined in Section 2. It will therefore create DNS records for these addresses. For example, site A which owns IPv4 address 192.1.2.3 will create DNS records with the IPv6 prefix {FP=001,TLA=0x0003,NLA=192.1.2.3,SLA=0x2003}/64 (i.e., 2003:c001:0203:2003::/64). Site B which owns address 9.254.253.252 will create DNS records with the IPv6 prefix {FP=001,TLA=0x0003,NLA=9.254.253.252,SLA=0x2003}/64 (i.e., 2003:09fe:fdfc:2003::/48). When an IPv6 host on site B queries the DNS entry for a host on site A, or otherwise obtains its address, it obtains an address with the prefix {FP=001,TLA=0x0003,NLA=192.1.2.3,SLA=0x2003}/64 and whatever Interface ID applies. The converse applies when a host on site A queries the DNS for a host on site B. IPv6 packets are formed and transmitted in the normal way within both sites. _______________________________ | | | Wide Area IPv4 Network | |_______________________________| / \ 192.1.2.3/ 9.254.253.252\ _______________________________/_ ____________________\____________ | / | | \ | |IPv4 Site A ########## | |IPv4 Site B ########## | | ____________________# 6to4udp#_ | | ____________________# 6to4udp#_ | || # router # || || # router # || ||IPv6 Site A ########## || ||IPv6 Site B ########## || ||2003:c001:0203:2003::/64 || ||2003:09fe:fdfc:2003::/64 || ||_______________________________|| ||_______________________________|| | | | | |_________________________________| |_________________________________| Within a 6to4udp site, addresses with the 2003::/16 prefix, apart from those with the local 2003:V4ADDR:V4PORT::/64 prefix, will be handled like any other non-local IPv6 address, i.e., by a default or explicit route towards the 6to4udp border router. When an outgoing packet reaches the 6to4udp router, it is encapsulated as defined in Section 3, according to the additional sending rule defined in Section 5.3. Incoming packets are decapsulated according to the additional decapsulation rule defined in Section 5.3. The additional sending and decapsulation rules are the only changes to IPv6 forwarding, and they occur only at border routers. No IPv4 routing information is imported into IPv6 routing (nor vice versa). In this scenario, any number of 6to4udp sites can interoperate with no tunnel configuration, and no special requirements from the IPv4 service. All that is required is the appropriate DNS entries and the additional sending and decapsulation rules configured in the 6to4udp router. This router SHOULD also generate the appropriate IPv6 prefix announcements [CONF, DISC]. Although site A and site B will each need to run IPv6 routing internally, they do not need to run an IPv6 exterior routing protocol in this simple scenario; IPv4 exterior routing does the job for them. While this scenario is described for completeness, a site with a known IPv4 address should use [6to4] rather than 6to4udp. 5.1 Mixed scenarios - one site has an NAPT The typical deployment scenario for 6to4udp is for it to be used behind an NAPT that is outside of the client host's control. In this scenario, it is unlikely that a client would be able to maintain it's IPv6 address prefix for long periods of time. It is therefore likely that many addresses will not make it into any DNS. The unique IPv6 address that is created, however, can be used in any number of other protocols that would like peer to peer connectivity (IPsec, SIP, FTP, etc.) By definition, each site has an IPv6 prefix in the format defined in Section 2. It will therefore create DNS records for these addresses. Host A has address 10.1.2.3, and is currently sitting behind NAPT C. NAPT C has address 192.1.2.3 on the outside. NAPT C may be located in the basement of a hotel, while Host A is in a hotel room. For example, site B which owns IPv4 address 9.254.253.252 will create DNS records with the IPv6 prefix {FP=001,TLA=0x0003,NLA=9.254.253.252,SLA=0x2003}/64 (i.e., 2003:09fe:fdfc:2003::/64). When IPv6 host A queries the DNS entry for a host on site B, or otherwise obtains its address, it obtains an address with the prefix {FP=001,TLA=0x0003,NLA=9.254.253.252,SLA=0x2003}/64 and whatever Interface ID applies. IPv6 packets are transmitted via encapsulation by host A. IPv6 packets are formed and transmitted in the normal way within site B. _______________________________ | | | Wide Area IPv4 Network | |_______________________________| / \ 192.1.2.3 port 40293/ 9.254.253.252\ port 2003 ____________________________/_ ____________________\____________ | / | | \ | |IPv4 Site C ########## | |IPv4 Site B ########## | | _________________# IPv4 #_ | | ____________________# 6to4udp#_ | || # NAPT C # || || # router # || ||IPv6 Host A ########## || ||IPv6 Site B ########## || ||2003:c001:0203:9d65: || ||2003:09fe:fdfc:2003::/64 || || 2a0:24ff:feac:5c52 || || || ||____________________________|| ||_______________________________|| | | | | |______________________________| |_________________________________| Within host A, itself a 6to4udp router, all addresses with 2003::/16 prefix will be encapsulated as defined in Section 3. Within a 6to4udp site B, addresses with the 2003::/16 prefix, apart from those with the local 2003:V4ADDR:V4PORT::/64 prefix, will be handled like any other non-local IPv6 address, i.e., by a default or explicit route towards the 6to4udp border router. Once the packet leaves host A, and arrives at NAPT C, the source IPv4 address and source UDP port will get rewritten according the NAPT state table, and will emerge with V4ADDR and V4PORT on them. Incoming packets are decapsulated according to the additional decapsulation rule defined in Section 5.3. The additional sending and decapsulation rules are the only changes to IPv6 forwarding, and they occur only at border routers. No IPv4 routing information is imported into IPv6 routing (nor vice versa). In this scenario, any number of 6to4udp sites can interoperate with no tunnel configuration, and no special requirements from the IPv4 service. All that is required is the appropriate DNS entries and the additional sending and decapsulation rules configured in the 6to4udp router. This router SHOULD also generate the appropriate IPv6 prefix announcements [CONF, DISC]. Although site A will need to run IPv6 routing internally, site A will not need to run an IPv6 exterior routing protocol in this simple scenario; IPv4 exterior routing does the job for them. 5.2 Mixed scenario with relay to native IPv6 During the transition to IPv6 we can expect some sites to fit the model just described (isolated sites whose only connectivity is the IPv4 Internet), whereas others will be part of larger islands of native or tunnelled IPv6 using normal IPv6 TLA address space. The 6to4udp sites will need connectivity to these native IPv6 islands and vice versa. In the 6to4udp model, this connectivity is accomplished by IPv6 routers which possess both 6to4udp and native IPv6 addresses. Although they behave essentially as standard IPv6 routers, for the purposes of this document they are referred to as relay routers to distinguish them from routers supporting only 6to4udp, or only native IPv6. There must be at least one router acting as a relay between the 6to4udp domain and a given native IPv6 domain. There is nothing special about it; it is simply a normal router which happens to have at least one logical 6to4udp pseudo-interface and at least one other IPv6 interface. Since it is a 6to4udp router, it implements the additional sending and decapsulation rules defined in Section 5.3. We now have three distinct classes of routing domain to consider: 1. the internal IPv6 routing domain of each 6to4udp site; 2. an exterior IPv6 routing domain interconnecting a given set of 6to4 border routers, including relay routers, among themselves, i.e. a 6to4 exterior routing domain; 3. the exterior IPv6 routing domain of each native IPv6 island. 1. The internal routing domain of a 6to4udp site behaves as described in section 5.1. 2. There are two deployment options for a 6to4udp exterior routing domain: 2.1 No IPv6 exterior routing protocol is used. The 6to4udp routers using a given relay router each have a default IPv6 route pointing to the relay router. The relay router MAY apply source address based filters to accept traffic only from specific 6to4udp routers. 2.2 An IPv6 exterior routing protocol is used. The set of 6to4udp routers using a given relay router obtain native IPv6 routes from the relay router using a routing protocol such as BGP4+ [RFC 2283, BGP4+]. The relay router will advertise whatever native IPv6 routing prefixes are appropriate on its 6to4udp pseudo-interface. These prefixes will indicate the regions of native IPv6 topology that the relay router is willing to relay to. Their choice is a matter of routing policy. It is necessary for network operators to carefully consider desirable traffic patterns and topology when choosing the scope of such routing advertisements. The relay router will establish BGP peering only with specific 6to4 routers whose traffic it is willing to accept. Although this solution is more complex, it provides effective policy control, i.e. BGP4+ policy determines which 6to4udp routers are able to use which relay router. 3. A relay router MUST advertise a route to 2003::/16 into the native IPv6 exterior routing domain. It is a matter of routing policy how far this routing advertisement of 2003::/16 is propagated in the native IPv6 routing system. Since there will in general be multiple relay routers advertising it, network operators will require to filter it in a managed way. Incorrect policy in this area will lead to potential unreachability or to perverse traffic patterns. 6to4udp prefixes more specific than 2003::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing table by elements of the IPv4 routing table. Therefore, a 6to4udp site which also has a native IPv6 connection MUST NOT advertise its 2003::/48 routing prefix on that connection, and all native IPv6 network operators MUST filter out and discard any 2003:: routing prefix advertisements longer than /16. Sites which have at least one native IPv6 connection, in addition to a 6to4udp connection, will therefore have at least one IPv6 prefix which is not a 2003:: prefix. Such sites' DNS entries will reflect this and DNS lookups will return multiple addresses. If two such sites need to interoperate, whether the 6to4udp route or the native route will be used depends on IPv6 address selection by the individual hosts (or even applications). Now consider again the example of the previous section. Suppose an IPv6 host on site B queries the DNS entry for a host on site A, and the DNS returns multiple IPv6 addresses with different prefixes. ____________________________ ______________________ | | | | | Wide Area IPv4 Network | | Native IPv6 | | | | Wide Area Network | |____________________________| |______________________| / \ // 192.1.2.3, port 40293 9.254.253.252\port 2003 // 2001:0600::/48 ____________/_ ____________________\_________//_ / | | \ // | ########## | |IPv4 Site B ########## | __# IPv4 #_ | | ____________________# 6to4udp#_ | # NAPT C # || || # router # || ########## || ||IPv6 Site B ########## || || ||2003:09fe:fdfc:2003::/64 || __Host A_____|| ||2001:0600::/48_________________|| as before | | | ______________| |_________________________________| If the host picks the 6to4udp prefix according to some rule for multiple prefixes, it will simply send packets to an IPv6 address formed with the prefix {FP=002,TLA=0x0003,NLA=9.254.254.252,SLA=0x2003}/64. It is essential that they are sourced from the prefix {FP=002,TLA=0x0003,NLA=192.1.2.3,SLA=0x9D65}/64 for two-way connectivity to be possible. The address selection mechanism of Section 2.1 will ensure this. 5.2.1 Variant scenario with ISP relay The previous scenario assumes that the relay router is provided by a cooperative 6to4udp user site. A variant of this is for an Internet Service Provider, that already offers native IPv6 connectivity, to operate a relay router. Technically this is no different from the previous scenario; site B is simply an internal 6to4udp site of the ISP, possibly containing only one system, i.e. the relay router itself. 5.2.2 Summary of relay router configuration A relay router participates in IPv6 unicast routing protocols on its native IPv6 interface and may do so on its 6to4udp pseudo-interface, but these are independent routing domains with separate policies, even if the same protocol, probably BGP4+, is used in both cases. A relay router also participates in IPv4 unicast routing protocols on its IPv4 interface used to support 6to4, but this is not further discussed here. On its native IPv6 interface, the relay router MUST advertise a route to 2003::/16. It MUST NOT advertise a longer 2003:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain. IPv6 packets received by the relay router whose next hop IPv6 address matches 2003::/16 will be routed to its 6to4 pseudo-interface and treated according to the sending rule of Section 5.1. 5.2.2.1. BGP4+ not used If BGP4+ is not deployed in the 6to4udp exterior routing domain (option 2.1 of Section 5.2), the relay router will be configured to accept and relay all IPv6 traffic only from its client 6to4udp sites. Each 6to4udp router served by the relay router will be configured with a default IPv6 route to the relay router (for example, Site B's default IPv6 route ::/0 would point to the relay router's address under prefix 2003:09fe:fdfc::/48). 5.2.2.2. BGP4+ used If BGP4+ is deployed in the 6to4udp exterior routing domain (option 2.2 of Section 5.2), the relay router advertises IPv6 native routing prefixes on its 6to4 pseudo-interface, peering only with the 6to4udp routers that it serves. (An alternative is that these routes could be advertised along with IPv4 routes using BGP4 over IPv4, rather than by running a separate BGP4+ session.) The specific routes advertised depend on applicable routing policy, but they must be chosen from among those reachable through the relay router's native IPv6 interface. In the simplest case, a default route to the whole IPv6 address space could be advertised. When multiple relay routers are in use, more specific routing prefixes would be advertised according to the desired routing policy. The usage of BGP4+ is completely standard so is not discussed further in this document. 5.2.2.3. Relay router scaling Relay routers introduce the potential for scaling issues. In general a relay router should not attempt to serve more sites than any other transit router, allowing for the encapsulation overhead. 5.2.3 Unwilling to relay It may arise that a site has a router with both 6to4udp pseudo- interfaces and native IPv6 interfaces, but is unwilling to act as a relay router. Such a site MUST NOT advertise any 2003:: routing prefix into the native IPv6 domain and MUST NOT advertise any native IPv6 routing prefixes or a default IPv6 route into the 6to4udp domain. Within the 6to4udp domain it will behave exactly as in the basic 6to4udp scenario of Section 5.1. 5.3 Sending and decapsulation rules The only change to standard IPv6 forwarding is that every 6to4udp router (and only 6to4udp routers) MUST implement the following additional sending and decapsulation rules. In the sending rule, "next hop" refers to the next IPv6 node that the packet will be sent to, which is not necessarily the final destination, but rather the next IPv6 neighbour indicated by normal IPv6 routing mechanisms. If the final destination is a 6to4udp address, it will be considered as the next hop for the purpose of this rule. If the final destination is not a 6to4udp address, and is not local, the next hop indicated by routing will be the 6to4udp address of a relay router. ADDITIONAL SENDING RULE for 6to4 routers if the next hop IPv6 address for an IPv6 packet does match the prefix 2003::/16, and does not match any prefix of the local site then apply any security checks (see Section 8); encapsulate the packet in IPv4 as in Section 3, with IPv4 destination address = the NLA value V4ADDR and UDP destination port = the SLA value V4PORT extracted from the next hop IPv6 address; queue the packet for IPv4 forwarding. A simple decapsulation rule for incoming IPv4 UDP packets with destination port 0x2003 MUST be implemented: ADDITIONAL DECAPSULATION RULE for 6to4udp routers apply any security checks (see Section 8); remove the IPv4 header and UDP header; submit the packet to local IPv6 routing. 5.4 Variant scenario with tunnel to IPv6 space A 6to4udp site which has no IPv6 connections to the "native" IPv6 Internet can acquire effective connectivity to the v6 Internet via a "configured tunnel" (using the terminology in [MECH]) to a cooperating router which does have IPv6 access, but which does not need to be a 6to4udp router. Such tunnels could be autoconfigured using an IPv4 anycast address, but this is outside of the scope of this document. Alternatively a tunnel broker can be used. This scenario would be suitable for a small user-managed site. These mechanisms are not described in detail in this document. 5.11. Routing loop prevention Since 6to4udp has no impact on IPv4 routing, it cannot induce routing loops in IPv4. Since 2003: prefixes behave exactly like standard IPv6 prefixes, they will not create any new mechanisms for routing loops in IPv6 unless misconfigured. One very dangerous misconfiguration would be an announcement of the 2003::/16 prefix into a 6to4udp exterior routing domain, since this would attract all 6to4udp traffic into the site making the announcement. Its 6to4udp router would then resend non- local 6to4udp traffic back out, forming a loop. The 2003::/16 routing prefix may be legitimately advertised into the native IPv6 routing domain by a relay router, and into an IPv6 site's local IPv6 routing domain; hence there is a risk of misconfiguration causing it to be advertised into a 6to4udp exterior routing domain. To summarise, the 2003::/16 prefix MUST NOT be advertised to a 6to4udp exterior routing domain. 6. Multicast and Anycast It is not possible to assume the general availability of wide-area IPv4 multicast, so (unlike [6OVER4]) the 6to4 mechanism must assume only unicast capability in its underlying IPv4 carrier network. An IPv6 multicast routing protocol is needed [MULTI]. The allocated anycast address space [ANYCAST] is compatible with 2002:: prefixes, i.e. anycast addresses formed with such prefixes may be used inside a 6to4 site. 7. ICMP messages ICMP "unreachable" and other messages returned by the IPv4 routing system will be returned to the 6to4udp router that generated a encapsulated 2003:: packet. However, this router will often be unable to return an ICMPv6 message to the originating IPv6 node, due to the lack of sufficient information in the "unreachable" message. This means that the IPv4 network will appear as an undiagnosable link layer for IPv6 operational purposes. Other considerations are as described in Section 4.1.3 of [MECH]. An ICMP port unreachable message that is returned likely indicates that no such IPv6 host exists, and should be treated like the failure of neighbour discovery protocol. 8. IANA considerations The IANA is asked to assign the special TLA value 0x0003. 9. Security considerations Implementors should be aware that, in addition to possible attacks against IPv6, security attacks against IPv4 must also be considered. Use of IP security at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons. For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authentication of IPv4 will add little. Conversely, IPv4 security will not protect IPv6 traffic once it leaves the 6to4 domain. Therefore, implementing IPv6 security is required even if IPv4 security is available. By default, 6to4udp traffic will be accepted and decapsulated from any source from which regular IPv4 traffic is accepted. If this is for any reason felt to be a security risk (for example, if IPv6 spoofing is felt to be more likely than IPv4 spoofing), then additional source address based packet filtering could be applied. A possible plausibility check is whether the encapsulating IPv4 address is consistent with the encapsulated 2003:: address. If this check is applied, exceptions to it must be configured to admit traffic from relay routers (Section 5). 2003:: traffic must also be excepted from checks applied to prevent spoofing of "6 over 4" traffic [6OVER4]. In any case, any 6to4udp traffic whose source or destination address embeds a V4ADDR which is not in the format of a global unicast address MUST be silently discarded by both encapsulators and decapsulators. Specifically, this means that IPv4 addresses defined in [RFC 1918], broadcast, subnet broadcast, multicast and loopback addresses are unacceptable. In addition, there are a number of IPv4 security gateways that provide for stateful release of UDP traffic from the internal network. This protocol can easily be used through them. There is a risk involved here. Acknowledgements The basic idea presented above is probably not original, and it is largely inspired from the 6to4 work of RFC3056. References [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373 [AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374 [API] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553. [BGP4+] Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont, RFC 2545 [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460 [6OVER4] Carpenter, B., and Jung., C. "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529. [ANYCAST] Johnson, D. and Deering, S., Reserved IPv6 Subnet Anycast Addresses, draft-ietf-ipngwg-resv-anycast-01.txt (work in progress). [MULTI] Thaler, D., Support for Multicast over 6to4 Networks, draft- thaler-ngtrans-6to4-multicast-01.txt (work in progress). [SCALE] Hain, T., 6to4-relay discovery and scaling, draft-hain-6to4- scaling-00.txt (work in progress). [SELECT] Draves, R., Default Address Selection for IPv6, draft-ietf- ipngwg-default-addr-select-00.txt (work in progress). [RFC 791] Postel, J., "Internet Protocol", RFC 791 [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., Lear, E., "Address Allocation for Private Internets", RFC 1918 [MECH] Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan & E. Nordmark, draft-ietf-ngtrans-mech-06.txt (work in progress updating RFC 1933). [RSIP] Realm Specific IP: Protocol Specification, M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi, draft-ietf-nat-rsip-protocol-03.txt (work in progress) [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner, RFC 2119 [RFC 2283] Multiprotocol Extensions for BGP-4, T. Bates, R. Chandra, D. Katz, Y. Rekhter, RFC 2283 Authors' Addresses insert me Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.