[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
implications of 6to4 for v6coex
- To: IPv6 Operations <v6ops@ops.ietf.org>
- Subject: implications of 6to4 for v6coex
- From: james woodyatt <jhw@apple.com>
- Date: Fri, 5 Sep 2008 19:32:10 -0700
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