[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enhanced SIIT
Why not extend MIP?
One can assume that people would roam between v4 only and v6 only sites
in future.
could MIP not be a technology dealing with this?
G/
-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Iljitsch van Beijnum
Sent: Thursday, October 18, 2007 2:05 PM
To: todd@fries.net
Cc: Brian E Carpenter; IPv6 Operations; Jari Arkko
Subject: Re: Enhanced SIIT
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?