Christian, I want to say thank you for the comments! In fact I
wondered whether people noticed this draft as there had been no
comment till this msg showed up.
On Mar 18, 2009, at 9:44 AM, Christian Vogt wrote:
Lixia, David, and all -
I think it is very useful that IAB is taking position on the issue of
NAT in IPv6. And it is great that you, Lixia and David, have
documented
this position. Below I have one comment on the document. I admit that
the comment is a bit hypothetical, but I do believe it is worthwhile
to
be considered in the discussion around IPv6 NAT.
On page 9, you state, based on a citation from RFC 4924: "We believe
that providing end-to-end transparency [...] is key to the success of
the Internet." I think this statement needs elaboration.
Let me first quote the RFC4924 text here so people can see the context
of this discussion:
As [RFC4924] states:
A network that does not filter or transform the data that it
carries may be said to be "transparent" or "oblivious" to the
content of packets. Networks that provide oblivious transport
enable the deployment of new services without requiring changes
to
the core. It is this flexibility that is perhaps both the
Internet's most essential characteristic as well as one of the
most important contributors to its success.
To me this essentially stated that "network, please let users data go
end-to-end and stay intact"
End-to-end
transparency is not a reason for the success of the Internet.
Instead,
it is a requirement that follows from the overloading of
identification
and location semantics onto IP addresses: It is exactly those
applications that pursue this overloading, in form of address
referrals,
which have difficulties with the lack of end-to-end transparency.
I believe that people in general agree that applications should not
use IP address for referrals.
As RFC1958 "Architectural Principles of the Internet" (June 1996)
stated:
4.1 Avoid any design that requires addresses to be hard coded or
stored on non-volatile storage (except of course where this is an
essential requirement as in a name server or configuration server).
In general, user applications should use names rather than
addresses.
Maybe it's too late so my brain got foggy, however between these two
issues,
(1) keeping user packets intact as they transit through the
network, and
(2) applications using address for referral
I do not see that (2) is a consequence of (1), as you seem to believe.
Since the comments below seem trying to justify for IPv6 NAT, I would
also like to point out the following text in draft-iab-ipv6-nat-00:
If we accept the view that some, but not all, parties want IPv6 NAT,
then the real debate should not be on what benefits IPv6 NAT may
bring. As every coin has two sides, it is undeniable that network
address translation can bring certain benefits to its users.
However
the real challenge we should address is how to design IPv6 NAT in
such a way that it can hide its impact within some localized scope.
If IPv6 NAT design can achieve this goal, then the Internet as a
whole can strive for (re-installing) the end-to-end reachability
model.
The draft did not take any position on 1:1 NAT; it simply stresses the
importance to strive for (re-installing) Internet's end-to-end
reachability model, if/when one designs IPv6 NAT.
And I believe you too agree with this.
Lixia (no hat on)
Of course, this is not to mean that NAT, as used in IPv4 today,
would be
a harmless technology if we had a clean identifier-locator separation.
But this is because IPv4 NAT does more potentially harmful things
apart
from removing end-to-end transparency. The reason for the
harmfulness of
IPv4 NAT is not the address rewriting by itself; it is that IPv4 NATs
multiplex multiple internal addresses onto a single external address.
This "address overloading" is causing problems that wouldn't go away
even if we had a clean identifier-locator separation -- problems in
terms of reduced host reachability, reduced network robustness, and a
limitation to connection types with en-route-modifiable port numbers.
The reason why address overloading causes these problems is that it
(a) makes addresses ambiguous and, for the purpose of disambiguation,
(b) adds per-connection state to the network.
Now, assuming we had a large enough number of addresses for a one-to-
one
mapping between the internal and external addresses of a NAT, the NAT
could do simple address rewriting without address overloading, hence
avoiding aforementioned problems. If we further assume that we had a
clean identifier-locator separation, then why would it matter that
simple address rewriting causes a loss of end-to-end transparency?
Why
would it matter if a locator changes en route for a packet if both the
old and the new locator map unambiguously to the same identifier?
I don't think it would matter -- again, provided we had enough
addresses
and an identifier-locator separation. Luckily, in IPv6 we have the
former;
unfortunately, though, neither in IPv4 nor in IPv6 we have the latter.
- Christian
PS: FWIW, draft-vogt-address-translation-harmfulness [1] is related to
your document. It is a harmfulness analysis of possible NAT
designs, which looks at potential problems of the NAT designs, and
evaluates the cost and completeness of solutions to those problems.
This includes an evaluation of impacts that NAT deployment may have
on the rest of the Internet -- a question which, as you say, has so
far not been sufficiently attended to.
[1]
http://users.piuha.net/chvogt/pub/2009/draft-vogt-address-translation-harmfulness-02.txt
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf