cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3291
Views
5
Helpful
6
Replies

How does a more specific prefix of 6to4 pollute routes of native IPv6?

Quang Do Xuan
Level 1
Level 1

"The specification states that such relay routers must only advertise 2002::/16 and not subdivisions of it to prevent IPv4 routes polluting the routing tables of IPv6 routers."

Please anyone explain to methe reason. Kindly give me any citation if possible.

Regards

1 Accepted Solution

Accepted Solutions

The 6to4 specification in RFC3056 prohibits advertising anything other than 2002:/16 on the v6 side in section 5.3  paragraph 3 to avoid embedding the entire v4 routing table into the v6  routing below the 2002://16 prefix as a subset.  Every v4 subnet has a  corresponding 6to4 prefix /48 v6 prefix, which means if even if you  limit v4 adversitements to, say /24's, you would be committing to up to  16M /40's to cover all the 6to4 addresses in your v6 routing table if  you allowed things smaller than /16.  Every backbone router on the  internet would fall over and die.  The "pollution of the IPv6 routing  table" wording is straight out of the RFC, which apparently assumes the  readers to have enough familiarity with BGP+ to grasp this implication without further elaboration:

  http://tools.ietf.org/html/rfc3056

This isn't a problem for 6rd because the 6rd allocations to ISP's follow the usual v6 geographic hierachies and get routed to the ISP's border as something more like a /20 or /32.  In general, v6 currently has about a 7:1 advantage over v4 in terms of route aggregation; compare the table sizes at http://www.cidr-report.org/as2.0/ and http://www.cidr-report.org/v6/as2.0/

In general 6to4 relays are neither widely available nor reliable; see e.g.

   http://www.potaroo.net/ispcol/2010-12/6to4fail.html

On  wireless networks windows laptops with Internet Connection Sharing   turned on and public IPv4 addresses are prone to trying to become 6to4   relays, which usually ends badly for their wifi neighbors; a scenario  mostly seen at research universities in north america.  Other  problems  are NAT devices and firewalls blocking protocol 41 encapsulated   traffic, leading to lengthy timeouts; 6to4 relays whose BGP reach  exceeds their ACL grasp, forming  blackholes (warned of in the RFC);   and the general problems with 3rd party congestion and long  distance  latency, particularly if your nearest 6to4 relay is on the far  side of  some trans-oceanic cable.

Accordingly, at the IETF there is a proposal to move 6to4 to "historic" status, one form of deprecation:

   http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05

Connection  failure rates for Teredo are measurably even worse than for 6to4; APNIC  has measured success rates below 65%.  Meanwhile, over the last 4  years, traffic at v6-enabled content providers has shifted almost  entirely to native IPv6, e.g. at google the native v6 traffic is over 1% and rising, with automatic tunneling gone:

  http://www.google.com/ipv6/statistics.html

RIPE's measurements at exchange points in Europe are similar.

6rd  is a very different proposition operationally: the ISP is using native  IPv6 routing, the end clients are seeing native IPv6 prefixes and RA's,  and the protocol 41 tunnel is entirely and only between the CPE demarc  such as a cable modem and the ISP's in-house relay.  6rd is a great ploy  for ISP's to handle near tearm IPv6 provisioning while working through  their backlog of v4-only POP conversions to dual-stack.  6to4 and Teredo  are basically dead as transition mechanisms.  

A more  interesting issue is that recent cellphone data networks are v6-only,  particularly LTE4 networks in the US, meaning legacy v4 traffic has to  traverse a carrier NAT64 gateway.   Content providers who aren't  dual-stacked are going to start seeing a lot complaints about their  lousy network performance everytime their users tablets or cellphone  move off WIFI, when the underlying issue is actually the carrier NAT  gateway.  The cellphone companies won't care, since all of the top  destinations such as google, yahoo, facebook, youtube etc. are already  dual stacked and get good native v6 performance.  

There  are not yet a lot of v6-only resources, which is fortunate for the  legacy v4 internet, since NAT46, such as NAT-PT, founders on the  impossibility of reliably scaling DNS46  translation state, among other  problems.   The first time a v6-only resource becomes popular, we will  see a suddent strong shift in consumer sentiment toward v6  I predict  this will be based on some end of year holiday electronic toy with an  on-line component out of the pacific rim, and sometime in the next 3  years.  Both Cisco and AT&T have predicted that backbone routing of  v4 will cease by 2020, though backend datacenter v4 and tunneled v4 over  v6 may continue till 2036 or so.

View solution in original post

6 Replies 6

Michael Vincent
Level 1
Level 1

The 6to4 2002::/16 special prefix is used for dynamic 6to4 tunnels.  A full 6to4 address is created by using the 6to4 prefix (2002::/16) and the existing IPv4 interface address.

So for example, my Windows host has a public IPv4 address of 198.133.219.25 (it doesn't really - that's what cisco.com resolves to for me, but this is only an example).  My 6to4 address would be 2002:198.133.219.25::, or written more appropriately as:  2002:c685:db19:: (that's 198 = c6, 133 = 85 ...).

So now I start using IPv6 over my 6to4 tunnel to the 6to4 anycast relay (192.88.99.1).  Suppose my 198.133.219.25 is a class C subnet (/24) and all my colleages on that network - we'll say 200 of them to be conservative - also start using 6to4 with their public IPv4 address on that subnet.

If 6to4 relay routers advertised more specifics, say to /48, they would now be advertising:

2002:c685:db19:: /48

2002:c685:db1a:: /48

2002:c685:db1b:: /48

2002:c685:db1c:: /48

2002:c685:db1d:: /48

...

All 200 - in effect host routes - for each one of my colleagues using 6to4.  IPv6 routers' routing tables "polluted" with "IPv4" routes (the more specific 6to4 prefixes).

I may also lose the advantage of the anycast relay routers as my IPv6 prefix would be "tied" to the 6to4 relay router advertising my more specific route.

Hope that helps.

Thank Micheal,

Why don't they advertise a /40 prefix for your whole class C network, like the way they are using 6RD?

I didn't develop 6to4 or 6rd so I can't say for sure "why" either one is the say they are, but 6rd addresses some of the shortcomings of 6to4 by not using a special prefix, allowing each 6rd operator to use their own prefix for better return-route control and removes the reliance on IPv4 anycast relays.

The way I see it, 6rd is an improvement to 6to4 but also serves a slightly different purpose.  Frankly, I've never used 6to4 as it was intended for host to router tunneling because all my hosts have private IPv4 space - so 6to4 won't work.  I've used 6to4 for dynamic tunnels over IPv4-only MPLS networks for example, but that routing stays local to the client so no worry about polluting global routing tables.

I'm thinking about the assumption that IPv6 is strictly hierrachically designed based on geographical location, for the purpose of better routes summary. Then if a more specific prefix were advetised by relay routers, routes summay would be very messy or even looped. I did try a more specific prefix 6to4 in my school lab and made it workable (the firmware constrain forces me to stick with 6to4). So it's possible a scalable problem with the huge internet where BGP and complicated routes control operate. Anyway it's just my ordinary final year project and I shouldn't run that far. Thanks much, Micheal.

The 6to4 specification in RFC3056 prohibits advertising anything other than 2002:/16 on the v6 side in section 5.3  paragraph 3 to avoid embedding the entire v4 routing table into the v6  routing below the 2002://16 prefix as a subset.  Every v4 subnet has a  corresponding 6to4 prefix /48 v6 prefix, which means if even if you  limit v4 adversitements to, say /24's, you would be committing to up to  16M /40's to cover all the 6to4 addresses in your v6 routing table if  you allowed things smaller than /16.  Every backbone router on the  internet would fall over and die.  The "pollution of the IPv6 routing  table" wording is straight out of the RFC, which apparently assumes the  readers to have enough familiarity with BGP+ to grasp this implication without further elaboration:

  http://tools.ietf.org/html/rfc3056

This isn't a problem for 6rd because the 6rd allocations to ISP's follow the usual v6 geographic hierachies and get routed to the ISP's border as something more like a /20 or /32.  In general, v6 currently has about a 7:1 advantage over v4 in terms of route aggregation; compare the table sizes at http://www.cidr-report.org/as2.0/ and http://www.cidr-report.org/v6/as2.0/

In general 6to4 relays are neither widely available nor reliable; see e.g.

   http://www.potaroo.net/ispcol/2010-12/6to4fail.html

On  wireless networks windows laptops with Internet Connection Sharing   turned on and public IPv4 addresses are prone to trying to become 6to4   relays, which usually ends badly for their wifi neighbors; a scenario  mostly seen at research universities in north america.  Other  problems  are NAT devices and firewalls blocking protocol 41 encapsulated   traffic, leading to lengthy timeouts; 6to4 relays whose BGP reach  exceeds their ACL grasp, forming  blackholes (warned of in the RFC);   and the general problems with 3rd party congestion and long  distance  latency, particularly if your nearest 6to4 relay is on the far  side of  some trans-oceanic cable.

Accordingly, at the IETF there is a proposal to move 6to4 to "historic" status, one form of deprecation:

   http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05

Connection  failure rates for Teredo are measurably even worse than for 6to4; APNIC  has measured success rates below 65%.  Meanwhile, over the last 4  years, traffic at v6-enabled content providers has shifted almost  entirely to native IPv6, e.g. at google the native v6 traffic is over 1% and rising, with automatic tunneling gone:

  http://www.google.com/ipv6/statistics.html

RIPE's measurements at exchange points in Europe are similar.

6rd  is a very different proposition operationally: the ISP is using native  IPv6 routing, the end clients are seeing native IPv6 prefixes and RA's,  and the protocol 41 tunnel is entirely and only between the CPE demarc  such as a cable modem and the ISP's in-house relay.  6rd is a great ploy  for ISP's to handle near tearm IPv6 provisioning while working through  their backlog of v4-only POP conversions to dual-stack.  6to4 and Teredo  are basically dead as transition mechanisms.  

A more  interesting issue is that recent cellphone data networks are v6-only,  particularly LTE4 networks in the US, meaning legacy v4 traffic has to  traverse a carrier NAT64 gateway.   Content providers who aren't  dual-stacked are going to start seeing a lot complaints about their  lousy network performance everytime their users tablets or cellphone  move off WIFI, when the underlying issue is actually the carrier NAT  gateway.  The cellphone companies won't care, since all of the top  destinations such as google, yahoo, facebook, youtube etc. are already  dual stacked and get good native v6 performance.  

There  are not yet a lot of v6-only resources, which is fortunate for the  legacy v4 internet, since NAT46, such as NAT-PT, founders on the  impossibility of reliably scaling DNS46  translation state, among other  problems.   The first time a v6-only resource becomes popular, we will  see a suddent strong shift in consumer sentiment toward v6  I predict  this will be based on some end of year holiday electronic toy with an  on-line component out of the pacific rim, and sometime in the next 3  years.  Both Cisco and AT&T have predicted that backbone routing of  v4 will cease by 2020, though backend datacenter v4 and tunneled v4 over  v6 may continue till 2036 or so.

Very convincing Sir!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: