On killing IPv6 transition mechanisms

[Benedikt Stockebrand]

Hi Brian, Tore and list,

Brian E Carpenter <brian.e.carpenter at gmail.com> writes:

> On 2010-03-19 10:46, Tore Anderson wrote:
>
> [RFC 3484 Destination address selection and 6to4]
>
>> It is not a Windows-specific arrangement, it's implemented in
>> getaddrinfo() at least in GNU libc, probably most other modern variants
>> as well.  This is because rule 4 of the destination address selection
>> (chapter 6) comes into play, which says to prefer matching labels.

ok, I missed that one.  There are plenty of other reasons not to use
6to4 in production setups anyway, so this never had any particular
relevance to me.

>> However, if both the client and the server were to have 6to4-addresses,
>> a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, 
>> [...]
>
> I believe this was intentional, since the philosophy was 'prefer IPv6
> connectivity if it exists'. I also agree that reversing this in
> the policy table would be very reasonable; 3484 only provides a
> *default* policy table.

The root problem here isn't so much RFC 3484 but the fact that people
use 6to4 in ways beyond its capabilities.

In the past I often found 6to4 the most convenient way to quickly set
up IPv6 connectivity, make the turtle dance and show people that
things actually work.  I also recommend ISP techs in trainings to set
up their traffic accounting to collect data on all 6in4 (not limited
to 6to4) use so they can show their management how much IPv6 traffic
their customers already generate.  Maybe it provides them with the
convincing argument to move towards IPv6.

But ISPs selling 6to4 as a "solution" to their customers are about as
bad as CPE routers enabling it by default.  6to4 is anything but a
production grade solution, not only with the issues created by
public/anycast relays but also due to the inherently asymmetric
routing.

>> [...] 6to4 connections will be preferred over NAT-ed IPv4 connections
>> from RFC 1918 prefix.  
>
> Again, intentional, for the same reason.

And it saves you from STUN etc, too:-)

You know better than me about the original intention of the 6to4
specs, but I'd say if 6to4 is a design meant to be used only after a
deliberate decision rather than being enabled by default, this
reasoning is perfectly justified.

In hindsight, if there's something missing in RFC 3068 then it's an
unmistakable statement that 6to4 shouldn't be enabled by default.

>> I see quite a bit of breakage (lost clients that's using Mac OS X)
>> towards my dualstack testing host due to this.  

So much about the difference between actual and perceived cause of a
problem...

> The assumption of RFC 3056 was that the placement of 6to4 relays
> would be a managed process, for savvy early-adopter sites. The
> addition of the anycast relay model in RFC 3068 broke that
> assumption and brought about unmanaged deployment.

This is a bit unfair---3068 is rather explicit about the
responsibilities of a public relay operator and the problems that may
occur if a public relay fails.  Public relays are apparently serving a
very valuable purpose right now because they help generate the IPv6
traffic we need to put more pressure on ISPs, software developers and
just about anybody else.

> Nathan Ward has suggested a way to fix this (and the equivalent
> problem with Vista/Teredo) but it does need sites or ISPs to install
> a box to catch the anycasts.

Honestly, with most sites and ISPs either still ignoring IPv6 or more
or less frantically struggling to get a more permanent solution set up
I personally wouldn't expect them to put much effort into such a
temporary solution.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.