The discussion today in Behave shows there is very strong peer-pressure
group-think with no serious analysis of the long term implications about
what is being discussed. I requested we pop this up a level to talk about
'make things better' by focusing on ---who--- we are making it better for.
The closest we came to that was Townsley's discussion about spec'ing
something in the short term for the people that are building 46/64 nats to
make their job easier.
There is a ---very--- large issue here related to the application developers
and end users need to deal with topology warts. In IPv4, nat became
necessary due to the limited address range, so establishing some rules
through Behave made sense to minimize the kinds of impacts that applications
would have to deal with. So far there has not been any valid need documented
for why a 66nat should exist. Just the lame, 'they will be built anyway'
group-think of the mob.
If there is a valid need, yes Behave should make sure we minimize the kinds
of impacts that applications have to deal with. Lacking a valid need,
standardizing 66nat only ensures that applications will have to deal with
these unnecessary topology warts ---forever---. This is ---NOT--- making
things 'better' for applications developers, and end users. Making it easier
for a few product vendors to throw in 66nat while they are doing 46/64 is
not in the long term best interest of the Internet, and therefore the IETF
should not be doing this work. The charter of Behave should be amended to
remove this entire discussion until someone demonstrates that we actually
need a 66nat because there is no way to solve a real problem without it.
Rewind the clock, and note that as chair of ngtrans I tried very hard to
categorize the nat-pt effort as experimental, but the IESG and IETF chair of
the time overruled that in the face of group-think pressure to have a
standards track document. Fast forward to RFC 4966 where that decision was
reversed in the face of deployment evidence showing an experiment gone awry.
I ask myself what is different about the 66nat discussion, and the only
thing I can come up with is that the applications development community is
not aware and voicing their objections to this discussion, and that there
will be no way to recall this nonsense through a simple change of status
once they do, because the products will have long since been widely deployed
through default configurations (unlike nat-pt).
Tony
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf