David Conrad wrote: > .... > IPv6 _is_ IPv4 with more bits and it is being deployed that way. No it is not, and you need to stop claiming that because it confuses people into limiting their thinking to the legacy IPv4 deployment model. > One > can argue that it shouldn't be that way and that there should be a > paradigm shift in the enterprises, ISPs, and grandmothers of the > world, but commercial reality makes such a shift very, very hard. Transition requires that the technology meet people where they are, which is why you note that IPv6 is being deployed like IPv4. Then once they get over the basic education hump they can think about the different capabilities to move beyond the historical limitations. There are way too many arguments (even on this list of relatively smart people) where the fundamental difference of simultaneous use of multiple addresses is the key to thinking differently between the versions. Until people get their heads out of the IPv4 darkness they will keep insisting on making IPv6 deployments look the same. > > > And getting it solved > > means having a solution that actually works, has all > > the little details (like what the security is etc) worked > > out, fits with the incentives that the various players > > have, and so on. > > Do you believe IPv4 (or ANY other successful large scale technology), > when it was designed, had all the little details worked out? If anyone doubts this point, note that the IETF still creates more IPv4 specific RFCs than IPv6 ones. Until the IESG/IAB get serious about stopping all work on the dead-end IPv4 protocol, people will continue to argue that IPv6 is not ready for deployment. > > As I have said elsewhere, I've come to believe that one of the > fundamental failures of the IETF is that it permits or even > encourages protocol design to be directed by corner cases. In this > particular case, it isn't even clear to me there is agreement on what > the problem we're trying to solve actually is. There are operational practices that originate from lack-of-memory/lack-of-reliable-resolution that end up embedding IP addresses in places that make it very costly to change them later. The work was done on the endpoint side to simplify renumbering, because touching the larger number of them was clearly a problem, but it was not done in the firewall/management system area. > > > And we have a place for that work to happen in the IRTF. > > Actually, I suspect if the work were to happen in the IRTF, it would > be doomed. The IRTF is, after all, focused on research. I can > imagine the people in the IRTF contributing towards a solution but > that isn't where a solution will come from. Given real world > constraints, a solution will come from engineers (protocol, network, > hardware, and/or software), singly or working together, coming up > with an approach that meets real world requirements (not what > researchers believe are real world requirements). It almost > certainly won't be architecturally pure and it probably won't be > pretty, but it will probably meet commercial and operational needs. If there is research to do towards this, it will be in the arena of social engineering. Once it is clear how to stop operators from deciding the most expedient thing to do is embed the current IP address into some configuration, then engineering can build the tool to enforce that. It is very difficult to get people to realize that the accumulation of short term cost savings will turn on them as a sizable cost when changes become necessary. Tony _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf