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

Re: Enhanced SIIT

On 18-okt-2007, at 14:27, Todd T. Fries wrote:


The question I think is the wrong question.  I've read enough of the
discussion on this topic to realize the people discussing it here presume that stateless communication between IPv4 and IPv6 is some holy grail that 
must be achieved at all costs.
It's not so much the statelessness that's important, but the ability for people to go ahead with IPv6 and reduce their IPv4 footprint *now* rather than more or less be forced to wait until everyone else is dual stack. The problem with dual stack is that it provides no compelling benefits: you get all the complexity that's in IPv4, all the complexity that's in IPv6, and any complexity arising from their interaction to boot.
However, any stateless transition mechanism is going to be as harmful as IPv4 mapped IPv6 addressing given that you add an entire complex case to 
firewalls and any security issues you wish to address.
Unfortunately, firewalls are used in such an abundant variety of harmful ways, that there is no reasonable way to accommodate their use in most IETF work. People shouldn't depend on firewalls as crutches that let them keep doing things that they shouldn't be doing. 


To answer your other statement, I cannot see how you call the IPv6 api
something to transition to and once transitioned to, you cannot use
the IPv4 API.
I'm not saying you can't, I'm saying it doesn't make sense to use different code paths for IPv4 and IPv6. 


There are some new standard functions, getaddrinfo() for example, that
support both protocols.  If you write your code properly, you need not
care which protocol you are talking to.
Right. That's exactly what I'm saying. But the OpenBSD people didn't want that, and made sure their kernel would only allow the IPv6 API to generate IPv6 packets. Fortunately, this is something that's no longer a system-wide setting these days (well, unless you use Windows XP, where v4 and v6 are separate protocols that shall never meet in an API) but something that applications can control. 

[...]
So there is infrastructure in place that is transitioning to IPv6 as we speak.
On the other hand, none of the big content sites uses IPv6, very few end-user ISPs offer IPv6 and none of the common CPEs support IPv6. The same thing was true several years ago, but we are now making way more progress using up the remaining IPv4 space than adding IPv6 in these three areas.
The biggest holdup in the IPv6 transition in my humble opinion is the lack of having IPv6 root dns servers in the advertised/example root.cache/root.hints 
file.
Huh? Not to say that I'm happy with the glacial progress in that area, but how exactly would that help? Yes, with IPv6 root servers it's possible for a system that runs IPv6-only to reach another IPv6 system without touching any IPv4 infrastructure if all the DNS servers in the delegation chain also support IPv6, but the problem is that you can't run IPv6-only anyway because then you don't have access to the top 100 web sites, any of the large IM networks, etc.