[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

implications of 6to4 for v6coex

everyone--
I've been reviewing RFC 3056, RFC 3068 and RFC 3964 with an eye toward composing draft guidelines for service providers deploying 6to4 relays for the exclusive use of their subscribers, i.e. *not* public 6to4 relay services. In the process, I've come to think that some additional recommendations from IETF are in order, specifically to deal with IPv6-IPv4 Coexistence (V6COEX) issues. The intent of this message is to start a discussion on the topic.
I believe section 5.2 "Mixed scenario with relay to native IPv6" in RFC 3056 adequately describes the scenario of interest to the V6COEX effort.
In this scenario, the service provider has a mix of offerings, including 1) IPv4 service at globally routed addresses and 2) native or tunneled IPv6 service at globally routed addresses. The V6COEX issue arises when a node in subscriber A, receiving IPv4-only service in its delegated 192.0.2.0/24 subnet, e.g. 192.0.2.1, elects to become a 6to4 site with its corresponding 6to4 prefix 2002:c000:201::/48 in order to communicate with native IPv6 nodes at subscriber B in the 2001:db8:1::/48 prefix.
Here's an ASCII diagram to show how this scenario presents a V6COEX issue: 

Subcriber                       Service Provider                Public
Networks                        Interior                        Internet

 Subscriber A
 (6to4-only)
+--------------------+ 192.88.99.1 +-------------------+ | 2002:c000:201::/48 |=================================>| Public 6to4 | | | | | | 192.0.2.1/32 |<============++ +-------------| Relay | +--------------------+ 192.0.2.1 \\ / +-------------------+ 
                                     \\ /
 Subscriber B                         \/
 (native IPv6)                        /\\
+--------------------+ 2001:db8:1::1 / \\ +-------------------+ | 2001:db8:1::/48 |<-------------+ ++=============| Public 6to4 | | | | | | |--------------------------------->| Relay | +--------------------+ 2002:c000:201::1 +-------------------+ 

             1. The common scenario today, i.e. no 6to4 relay in
                service provider network.  Public relay of last
                resort used.
The double-width lines show 6to4 packet flows tunneled over IPv4 and the single-width lines show all other IPv6 packet flows (native and other tunnels).
All the outbound IPv6 packets from Subscriber A are encapsulated in IPv4 proto 41 and sent to their corresponding IPv4 destination directly if they're for the 2002::/16 prefix, otherwise they are forwarded to some public 6to4 relay at the 192.88.99.1 anycast address. Likewise, the return path from Subscriber B, along with all the other traffic destined to 6to4 addresses, i.e. 2002::/16, are forwarded to some public 6to4 relay at the 2002:c058:6301:: anycast address.
The two 6to4 relay routers may or may not be the same router. They may or may not even be located in the same autonomous system. In any case, neither relay is operated by the service provider.
The V6COEX issue related to this scenario arises from a combination of two very common network operation errors. The first problem is that many public 6to4 relay operators do not comply with the requirement of section 5.2.3 in RFC 3056, which says: 
5.2.3 Unwilling to relay

It may arise that a site has a router with both 6to4 pseudo-
   interfaces and native IPv6 interfaces, but is unwilling to act as a
   relay router.  Such a site MUST NOT advertise any 2002:: routing
prefix into the native IPv6 domain and MUST NOT advertise any native 
   IPv6 routing prefixes or a default IPv6 route into the 6to4 domain.
   Within the 6to4 domain it will behave exactly as in the basic 6to4
   scenario of Section 5.1.
Admittedly, part of the problem is that a similar statement about the IPv4 anycast prefix, i.e. 192.88.99.0/24 is not present in RFC 3068. Moving on, the second problem is that many IPv4 network managers are not following the recommendations of section 7 in RFC 3068, which says: 


7 Security Considerations
The generic security risks of 6to4 tunneling and the appropriate protections are discussed in [RFC3056]. The anycast technique introduces an additional risk, that a rogue router or a rogue AS would introduce a bogus route to the 6to4 anycast prefix, and thus divert the traffic. IPv4 network managers have to guarantee the integrity of their routing to the 6to4 anycast prefix in much the same way that they guarantee the integrity of the generic v4 routing.
As a result of these two common operating errors, the scenario in the diagram above results in communication failure. When public relay operators do not actually provide the service they are advertising, then neither do the Internet service providers who accept their routes to the 6to4 anycast prefix without guaranteeing the integrity of service.
It's a particularly visible issue when the communication failure is between two co-located subscribers.
Why should the traffic even need to flow outside the data center, much less across two continents and a transoceanic link? The answer is that it shouldn't. The IETF should recommend that those providers planning to offer both IPv4 and IPv6 service to subscribers make sure to deploy 6to4 relays for the exclusive use of their subscribers. 

Compare the following ASCII diagram to the previous one:

Subcriber                       Service Provider                Public
Networks                        Interior                        Internet
IPv4 IPv6 +--------------------+ | | | Subscriber A | <=======================================># | | (6to4-only) | +---------------+ | | | |==========>| |<------------|------- ># | 2002:c000:201::/48 | | SP 6to4 Relay | | | | 192.0.2.1/32 |<==+ +--| | <===========># | +--------------------+ \\ / +---------------+ | | \\/ : : | | /\ : : | | +--------------------+ / \\ +---------------+ | | | Subscriber B |<--+ \+==| | <===========># | |(native IPv6) | | SP 6to4 Relay | | | | |<--------->| |<------------|------- ># | 2001:db8:1::/48 | +---------------+ | | | |<----------------------------------------|------- ># +--------------------+ | | 

             2. The proposed scenario, i.e. service provider
                deploys 6to4 relays for exclusive use of its
                own subscribers.  No public relays are needed.
In this diagram, subscriber A communicates directly via native IPv4 with the public Internet to and from any address in its subnet 192.0.2.0/24. Likewise, subscriber B communicates directly via native IPv6 with non-6to4 Internet destinations through the normal forwarding path. Once again, the double-width lines show 6to4 packet flows tunneled over IPv4 and the single-width lines show all other IPv6 packet flows (native and other tunnels).
When subscriber A wishes to communicate with non-6to4 IPv6 sites, their 6to4 router at 192.0.2.1 sends its traffic encapsulated in IPv4 to its nearest SP 6to4 relay, which decapsulates and forwards either to subscriber B or to some exterior IPv6 transit network. Likewise, when subscriber B wishes to communicate with 6to4 IPv6 sites, the service provider's IGP routes all traffic destined for 2002::/16 to the nearest interior 6to4 relay, which encapsulates and forwards either to subscriber A or to some exterior IPv4 transit network. In the case of subscriber A communicating with subscriber B, the paths in each direction never leave the service provider's networks.
Even service providers who offer *only* IPv6 service to their customers and do *not* offer IPv4 service should still deploy 6to4 relays in their own networks so that the return path to 6to4 destinations does not depend on the use of public relays whose reliability and availability they do not and cannot control. This is the essential not of the case that 6to4 presents a V6COEX problem.
I mean to document in detail how service providers can configure and deploy 6to4 relays for the exclusive use of their own subscribers in a forthcoming Internet draft, but there are some practical issues with such deployments that I think would best be addressed by an update to the standards documents.
In particular, I think it would be helpful to ask IANA to allocate a block of IPv4 unicast addresses for use by service providers in assigning interface addresses of their non-public 6to4 relays. These addresses would be like RFC 1918 addresses, in that they are explicitly forbidden from appearing in the IPv4 default-free zone routing tables, and their uniqueness property is only guaranteed to hold within the borders of a single autonomous system (though peering relationships could certainly extend their reach by mutual agreement).
The reasoning behind my idea is that service providers really do not want their 6to4 relays to be available outside their own networks, so assigning public addresses to their IPv4 interfaces as the current standards documents require is unnecessary, fails to conserve IPv4 address space, and places a burden on them to do ingress filtering at their borders to prevent unauthorized use of their relays by exterior sites. However, assigning them RFC 1918 addresses is a less than ideal solution, because those addresses are very likely to be reserved for use by carrier-grade NAT devices in providing Internet service to subscribers. Allocating a new special use block reserved solely for service provider 6to4 relay interfaces seems to me like a good and proper thing to do. These addresses do not need to appear in any of the 6to4 transit packets; they are only used for operations and management functions.
Note well: there is no need to allocate a special-use block of IPv6 addresses for service provider 6to4 relays. The RFC 4193 unique local addresses are more than adequate for this purpose. 

Comments?


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering