Noel Chiappa wrote:
> From: Keith Moore <moore(_at_)network-heretics(_dot_)com>
> You don't need to add it to all (or most) IPv6 implementations.
It's not hair-splitting if it significantly reduces the barrier to adoption.
> The goal ... is not to magically make all boxes and apps suddenly be
> able to communicate with both IPv4-only and IPv6-only hosts as if there
> were no difference between the two.
So you're willing to live with the converse of that? I.e. a situation where
communication between the two groups is spotty and unpredictable?
I'm willing to live with a world where a v6-only app that needs to
communicate with a v4 peer, or a v4-only app that needs to communicate
with a v6 peer, has a well-defined way of doing so - even though it
might require extra effort (in the form of extra API calls and/or
binding to a library that does them implicitly) and infrastructure (in
the form of a willing v4-v6 NAT). (Particularly if this extra effort
doesn't burden communication between v6-only peers.)
> Enterprise network management will continue to evolve and they'll see
> the benefits of using v6.
A familiar prediction...
Again, it's a big topic. I don't want to gloss over the problems -
they're considerable. But neither do I assume that enterprise network
operators in general are not capable of leveraging advantages of IPv6.
>> Either this functionality is added to .. IPv6 .., or the IPv6/v4
>> NAT boxes .. will display the same crippling problems as v4/v4 NAT...
> No, because (a) you're not trying to impose this on all hosts or apps,
> ... and (c) you engineer these boxes from day one in such a way as to
> avoid the crippling problems we've experience in v4 NAT.
I see no refutation of my basic observation, here.
I see no support for your assertion that this needs to be a core part of
Ietf mailing list