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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf