Re: Deployment Cases

On 2008-01-04 05:30, Hallam-Baker, Phillip wrote:
> Yes, as you point out the generic answer to the problem is NAT-PT which was recently squashed after a cabal got together.

That's a bizarre statement. Which of the technical arguments
in RFC 4966 are you referring to as being products of a cabal?
Did you raise your objections to those arguments during the
IETF Last Call on draft-ietf-v6ops-natpt-to-historic
(issued 2007-03-08)?

> My point here is that the thinking on the transition in the IETF to date has all been of the form 'well everyone is going to have to become like us, only they can't possibly expect to so its a bit of a problem but not our problem'.

Have you been contributing to ngtrans and v6ops over the last
ten years to correct this wrong way of thinking?

>  
> I received a lot of criticism when I first proposed that the IETF embrace NAT as a transition tool rather than deprecate it. The idea that we should actively encourage the NAT-ing of IPv4 was considered as unacceptable as Brian and others now find my proposals for changing the way that the IETF operates and the considerations it takes into account. 

That comparison is a category mistake. And given that NAT-PT was defined
as a co-existence technique in February 2000 (RFC 2766), I'm not sure
I see your point exactly.

> I don't see much dispute on that point today. Pretty much everyone seems to now accept that we are going to run out of IPv4 addresses before IPv6 deployment is complete and that some form of address sharing is therefore inevitable. What we have failled to do so far is to act on that.

Well, the original plan was that IPv6 would deploy before sharing
of IPv4 addresses started. That didn't happen and of course it's
unfortunate. It's true that those of us who were aghast at the
negative consequences of address sharing did nothing to make it work
better, and wrote about the negative consequences. I make no apology
for my part in that.

Given today's reality, some of the aghast are thinking actively about
how to define a method that isn't broken in the ways described by
RFC 4966.

    Brian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf