> From: Margaret Wasserman <mrw@xxxxxxxxxxxxxx>
I know I said I was going to stay out of this, but your note provoked some
generic architectural thoughts which I thought some might find interesting.
> NPTv6 has a great advantage over ... tunnel-based ID/LOC
> solutions in that the packet format of NPTv6 packets remains fully
> backward compatible with IPv6, allowing for full incremental deployment
> (one site can deploy it, without losing connectivity to anyone) through
> seamless backward-compatibility with existing IPv6 implementations.
I think the way you put this is potentially confusing, although you do have
an important basic point correct. NAT-based solutions do, as you point out,
only need a box deployed at _one_ end, so any site can get the full benefits,
acting entirely on its own.
However, I wouldn't describe it as "the packet format of NPTv6 packets
remains fully backward compatible with IPv6 ... through seamless
backward-compatibility with existing IPv6 implementations". Having pondered
your message for a bit, I now see what you're getting at (the box at the
'other end' doesn't need a 'de-frobber' box to ingest the packets, but can
consume them on its own), but it wasn't immediately obvious on first reading
it. The phrasing makes it (erroneously) sound like somehow tunnel-based
solutions use a non-IP format, which is of course not so (perhaps I find this
more confusing than other people since I have advocated having tunnel boxes
wrap packets in non-IP formats, going forward, as a way to deploy 'new
stuff').
Also, designs like ILNP and HIP, which do not involve tunnels, inhabit a
similar space to tunnel-based designs, in that unless both ends are upgraded
- or there is a proxy at the un-upgraded end - you don't get any benefits. So
it's really not the tunnel which is the key point here, it's the 'all at one
end' which is key.
However, the basic point does raise an interesting question: does the
'feature' that there's only a box at one end have a 'bug' that there's only a
box at one end? Are there things such design cannot accomplish, because of
that? (To put it another way, does the fact that the packet has only a single
name in it present a limitation? Put that way, it would seem natural that it
should...) I can quickly think of some examples, e.g. mobility with open
connections, but I'd need to ponder this a while to assess how the costs and
benefits of the two cases balance out.
> The major problems with IPv4 NA(P)T are caused by port mapping/address
> sharing and state-based (vs. algorithmic) translation, both of which
> were eliminated in NPTv6.
There's also the issue of having critical state in the network which is not
designed to be maintained in an 'architected' way, e.g. the ability to
provide redundant copies in several boxes.
(Had NAT been actually designed by the IETF, as opposed to sticking its head
in the sand and going 'neener neener neener', perhaps this could have been
dealt with, but it wasn't - thereby leading box providers to design boxes
that didn't need to interact with other boxes - meaning they _couldn't_
interact with other boxes, even when it would have been useful to be able
to do so. e.g. to replicate state for robustness.)
Some system (as opposed to purely point-point) tunnel designs, for all their
issues, do at least have this capacity...
> NAT-based ID/LOC solutions (such as NPTv6) have several advantages over
> tunnel-based ID/LOC solutions ... particularly in the areas of
> incremental deployment and backwards compatibility.
Lord knows that tunnel system designs have their issues (e.g. the high
inter-'switch' fan-out), but I think it's important to realize that they also
has advantages (alluded to above). And some of their disadvantages (the need
to have a mapping system, which brings both configuration and operational
costs) have their own advantages (now there's a mapping layer there which has
global visibility).
Where the balance lies between the two (with the advantages and disadvantages
of each), only time will truly tell.
Noel