On Mon, Mar 27, 2006 at 05:11:18PM -0500, Keith Moore wrote:
> >>>Your long term view is irrelevant if you are unable to meet short term
> >>>challenges.
> >>very true. but at the same time, it's not enough to meet short term
> >>challenges without providing a path to something that is sustainable in
> >>the long term.
> >>
> >
> > This is reasonable, but there is no realistic path to ipv6 that the
> >known world can reasonably be expected to follow.
>
> That's because people keep thinking that there needs to be a path from
> IPv4 to IPv6 that makes sense for all applications. No such path
> exists, because applications vary widely both in how they use the
> network and in how much existing infrastructure they have. No single
> path makes sense for all of them.
>
That's probably true, but it doesn't help if you are trying to
justify a move to ipv6 beyond some very limited and specific scope. Unless
all of a given organization's business applications which use ipv4 seamlessly
work in ipv6, a v4 -> v6 upgrade won't happen without a strong business
case.
For smaller organizations NAT _is_ relatively seamless beyond
doing a bit of trickery at the network edge, despite the shortcomings.
<good comments snipped for brevity>
> > Saying that it is a deficient mechanism may be true, but it
> >won't slow or change deployment. We can say that using workaround solutions
> >such as static natting ports, etc. are akin to putting lipstick on a
> >chicken,
> >but the ipv6 vs. NAT battle is over in the marketplace.
>
> the battle isn't over as long as vendors want to keep selling products.
> the shortcomings of NATs are now widely acknowledged. there is a
> market opportunity for a better solution.
>
I agree, but that opportunity may be to enhance NAT rather than
throw it away (you state something similar in your conclusion).
> > There may be specific applications where ipv6 is deployed and working
> >well (or so I hear). But NAT is ubiquitous. It's sort of like discussing
> >Lisp vs. c/c++.
>
> no it's not, because any program that can be written in LISP can be
> written in C/C++, or vice versa. OTOH, it is not in general possible to
> write a program that works in a non-NATted network and move that program
> to a NATted network unless you build additional infrastructure "in the
> core" of the NATted network that supports tunneling through the NATs and
> layers a new addressing scheme on top of the overlay network.
This is true, no question. It is definitely an added burden. But
it's a burden which must be dealt with because it's not going away
any time soon. The ubiquity of NATs is common knowledge to application
developers.
>
> now if what you're saying is that we need a standard NAT extension
> protocol that does that, I might agree. though IMHO the easiest way to
> do that is to make the NAT boxes speak IPv6.
>
Yes, I am saying we need this or something similar. It seems like
the current solution I've seen implemented is something like static port
mapping with private ip space behind the NAT for most applications. There's
still the limited known ports issue (discussed earlier) among several others
which are as yet either unsolved or unimplemented on the global scale.
There is probably still room for improvement here if it can be done
seamlessly or you can show a real business benefit to changing, such as ease of
multihoming or multiplexing of outside address space. Otherwise people will
just stick with what works adequately well.
Water flows downhill. Programmers are lazy. :-)
Austin
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
