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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf