[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enhanced SIIT
Penned by Iljitsch van Beijnum on 20071018 14:04.52, we have:
| On 18-okt-2007, at 13:49, Todd T. Fries wrote:
|
| >'not too big a deal to modify a v4 host'
|
| The absolute size of the deal isn't in question, it's the relative
| size when comparing moving to IPv6 wholesale (not happening at a
| reasonable pace) vs a mechanism that lets unmodified IPv6 hosts talk
| to unmodified IPv4 hosts (NAT-PT, is now dead) vs a mechanism that
| lets unmodified IPv6 hosts talk to modified IPv4 hosts vs a mechanism
| that lets modified IPv6 hosts talk to unmodified IPv4 hosts.
|
| Since all hosts that can be reasonably considered upgradable have
| both IPv4 AND IPv6 code on board the difference in scope between
| modifying one vs the other is small. Obviously changing deployments
| is rather different between IPv4 and IPv6.
|
| >If you're a v4 host wanting to talk to v6 land, visit:
|
| > http://freedaemonconsulting.com.ipv4.sixxs.org/
|
| There's more to life than HTTP. (I happen to be in a place that is
| blanketed by a wifi network that only supports port HTTP/port 80.
| This is almost useless.)
|
| >Proxies are indeed a valid transition mechanism, they are in place and
| >working, today.
|
| Ok, we can agree on that part then.
|
| >What you propose adds more bandaids to IPv4 and further muddies and
| >confuses
| >the waters.
|
| I'm sure it will be much easier to go back to a clean architecture
| for IPv4 right after we stop running it. :-)
|
| >Do you not realize why IPv4 mapped addresses were a bad idea?
|
| That's an unanswerable question, because knowing something (realizing
| it) implies the knowledge is true. I DO know that some people think
| that, and I vehemently disagree. Using separate APIs to talk IPv4 and
| IPv6 is an incredibly bad idea. Now that the IPv6 API is widely
| supported, applications should just use that one, whether the
| resulting packets are IPv4 or IPv6.
|
| But how does this relate to the question at hand, exactly?
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.
I'm stepping back a few paces and adding some water to your collective
faces and saying ... um, lets think about this for a second.
The question you are trying to answer is "How can we provide IPv6 to IPv4
stateless conversations so as to make things easier to transition?"
I agree with half of that statement, that making things easier to transition
is a useful thing.
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.
If you get your wish and provide that any IPv6 host can talk to any IPv4
host with special extensions, suddenly you drop the collective pants on any
IPv4 host's firewall, just the same as the issues presented with IPv4 mapped
IPv6 addresses. I think this is very much relevant here for this question
and this discussion.
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.
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. If you have an application that
keeps track of the IP address in some manner, then you'll need to add the
support for IPv6 but this hardly mandates removing the IPv4 address handling.
In either case, dual stack machines have the capability to talk to either
IPv6 or IPv4 depending on which addresses are available for the services
they wish to communicate with.
So, I might humbly submit that to make transition easy, one would need
to convince people there is a reason to rollout IPv6 support.
I have an understanding that at least in the US, major carriers (Sprint,
Level3, UUNet, AT&T, Verizon, etc..) are in various stages of implementing
IPv6 backbone services in order to meet the June 2008 deadline for the
US Government to be fully capable with IPv6. They have incentive to keep
their carrier agreements with the government and adding IPv6 allows them
to do this.
So there is infrastructure in place that is transitioning to IPv6 as we speak.
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. Some brain cell in the back of my head reminds me that the transition
as stated ages ago suggested 'routers and dns servers first, hosts second'.
Why can we not get the dns part right, years after the transition has started?
Automagic solutions that require updates that have no experimental experience
and no reference to any security implications seems to me to be a last ditch
effort at doing the worst possible thing at this time.
What is so wrong with talking dual stack for a time, and upgrading like mad
during that time to enable as many people to have either native or tunneled
IPv6 access?
Hmm, that'd require work, not talk. I get it.
Thanks,
--
Todd Fries .. todd@fries.net
_____________________________________________
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| "..in support of free software solutions." \ 250797 (FWD)
| \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt