Subject: Comment on draft-iab-ipv6-nat-00

From: Christian Vogt <[email-masked]>
Date: Wed, 18 Mar 2009 09:44:20 -0700

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.  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.

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 Mar 2009 13:24:29 -0400

Excerpts from Christian Vogt on Wed, Mar 18, 2009 09:44:20AM -0700:
> transparency is not a reason for the success of the Internet.  

I invoke Feynman and the "philosophy of ignorance".  The reason you
want e2e transparency is because you do not know what it might enable,
and we want that.  We _want_ to have uncertainty about what the future
of the Internet is.  We do not know what advantages or restrictions
our decisions will bring in the future.  The richness of the Internet
experience has come about because we have given end users the
capability to develop new ways of using it, and somehow managed to
have got out of the way, so far.

Feynman said (among other things -- search for it):

  Our responsibility is to do what we can, learn what we can, improve
  the solutions, and pass them on.  It is our responsibility to leave
  the people of the future a free hand.  In the impetuous youth of
  humanity, we can make grave errors that will stunt our growth for a
  long time.  This we will do if we say we have the answers now, so
  young and ignorant as we are.  If we suppress all discussion, all
  criticism, proclaiming “This is the answer, my friends; man is
  saved!” we will doom humanity for a long time to the chains of
  authority, confined to the limits of our present imagination.  It
  has been done so many times before.

Scott

---

From: Christian Vogt <[email-masked]>
Date: Wed, 18 Mar 2009 17:07:41 -0700

Scott -

Feynman is absolutely right, and certainly a network should enable
future, unknown applications.  But your conclusion that end-to-end
locator transparency is a requirement to build such a network does not
convince me.

This said, there is no question that end-to-end locator transparency is
a critical property in the Internet we have.  (And this was, after all,
was the point that Lixia and Dave were making.)  My point was that
end-to-end locator transparency is not the /reason/ for the Internet's
success, because you could build networks that function perfectly fine
without it.  E.g., a network with identifier-locator separation.

- Christian

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Mar 2009 20:58:22 -0400

> without it.  E.g., a network with identifier-locator separation.

That's an interesting theory.  I've yet to be convinced it's more than
wishful thinking.

I'll believe in ID-locator separation in the Internet when

a) there is a fast, reliable, secure and scalable system for either
routing on ID, or mapping from ID to locator, that is closely coupled to
both the routing system and the system of assigning addresses to
endpoints, so that they do not get out of sync with one another.

b) host stacks demultiplex incoming traffic via ID rather than locator

IMO, those are necessary, but perhaps not sufficient, conditions for it
to work.

Keith

---

From: Robin Whittle <[email-masked]>
Date: Thu, 19 Mar 2009 12:06:48 +1100

I support Scott Brim's position, I understanding as:

  End-to-end transparency (the packet received is identical to
  that sent, including its source and destination addresses, but
  not including hop limit etc.) is a major component of the
  Internet's flexible and open-ended nature.

  We would need extraordinarily strong arguments to eliminate
  this from IPv6 - or to remove other such basis which may
  facilitate the development of applications we cannot yet
  imagine.

> locator transparency is a requirement to build such a network does not

I am not sure what "end-to-end locator transparency" means.

"End-to-end transparency" is defined here:

  http://tools.ietf.org/html/rfc4924#section-1

in terms of "data" in the packet, but my definition involves
the source and destination addresses, since these are typically
important for how each host interprets the packet.

I fully support:

   http://tools.ietf.org/html/draft-iab-ipv6-nat-00#section-4.1

   We believe that providing end-to-end transparency, as defined above,
   is key to the success of the Internet.  While some fields of traffic
   (e.g., Hop Limit) are defined to be mutable, transparency requires
   that fields not defined as such arrive un-transformed.  Currently,
   the source and destination addresses are defined as immutable fields,
   and are used as such by many protocols and applications.

My definition of end-to-end transparency is not affected by
some function between the hosts which tunnels the packet to
some intermediate device at "locator" address as part of
efficiently forwarding it to the destination host.

Any system such as NAT which changes the source or destination
addresses of packets between hosts adds complexity and
restrictions to what would otherwise be a clean, open, network.

This was forced upon us with IPv4.  If such changes to packets
as seen by hosts is proposed as part of a scalable routing
solution for IPv6, I think there would need to be robust
arguments why any other scalable routing approach which
preserved end-to-end transparency was impractical or for some
very strong reason undesirable.

The Richard Feynman quote is from "What Do You Care What Other
People Think?: Further Adventures of a Curious Character (1988)".

    http://en.wikiquote.org/wiki/Richard_Feynman

  - Robin

---

From: Christian Vogt <[email-masked]>
Date: Wed, 18 Mar 2009 18:17:15 -0700

On Mar 18, 2009, Keith Moore wrote:

> wishful thinking. [...]

Me too. ;-)

Oh, and the question whether and when to introduce identifier-locator
separation is an orthogonal one.  We are talking about it, e.g., in RRG.
Here, I was just making an observation.

- Christian

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 18 Mar 2009 22:50:04 -0700

On Mar 18, 2009, at 5:07 PM, Christian Vogt wrote:

> was the point that Lixia and Dave were making.)

Hi Christian,

I will get back to your original comments in the next msg, but I feel  
the need to first correct potentially a very big error in the above:  
would you please kindly point to the exact text in draft-iab-ipv6- 
nat-00 that either stated or implied "end-to-end *locator*  
transparency", as you attributed to the draft?

I do not recall the draft mentioned the word "locator" at all.

Lixia

>  My point was that

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 18 Mar 2009 23:43:55 -0700

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:

> 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
> Instead,

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)

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Mar 2009 08:17:39 -0400

Lixia Zhang wrote:
> I believe that people in general agree that applications should not use
> IP address for referrals.

I don't know which people you're referring to there, but that's
absolutely not the case for application developers.  In the current
internet, use of IP addresses for referrals is essential.  And in fact
every application that uses DNS does exactly that.

It's all well and good to imagine a world where there would be a clear
ID-LOC separation.  But we've never created such a world, and we don't
currently have an ID-LOC mapping layer that is good enough to use by all
applications.  DNS falls short in many ways.  And as long as there is
not a universal mapping layer that is aware of things like NATs and
mobility, and for that matter as long as there are devices that impose
arbitrary limitations on traffic flow (e.g. connections have to be
initiated from "inside"), there will be a need for applications to deal
explicitly with IP addresses.  Sure it's ugly but it's the best that
applications can do.

> As RFC1958 "Architectural Principles of the Internet" (June 1996) stated:
> 
>    In general, user applications should use names rather than addresses.

Yes, that's in there.  The last sentence was a stretch even in 1996, and
it's simply incorrect as applied to the current Internet.  (Note that
NATs were not so widely deployed in 1996 as they are now.)

Saying that applications should use names rather than addresses,
especially in the context of a NATted Internet, is tantamount to saying
(a) that we have perfect faith in DNS to reliably map names to addresses
at all times, in all realms, and that DNS RRs will never leak across
realm boundaries, and (b) that we have perfect faith that any address
pair chosen by the host stack for communication will continue to
function for the entire lifetime of the association.  Both of those
assumptions would clearly be naive today.

>   (1) keeping user packets intact as they transit through the network, and

Part of what we mean by "transparency" is that applications should not
have to care about how the network routes packets or the way it is
connected.  In the original Internet there was a clear separation of
function - the applications generated messages to send to each other
than the network made a "best effort" to route those messages to their
intended destinations.  That's no longer true today.  And as long as
there are NATs in the network (or for that matter other devices that
violate the "best effort" model), some applications will be forced to
care about such things.  Part of the way they learn about such things
today is by looking at endpoint addresses, and part of the way they deal
with such things today is by using addresses for referral.

Keith

---

From: Pete Resnick <[email-masked]>
Date: Thu, 19 Mar 2009 11:04:45 -0700

On 3/19/09 at 8:17 AM -0400, Keith Moore wrote:

>internet, use of IP addresses for referrals is essential.

That IP addresses are currently essential for referral is not 
mutually exclusive with the idea that applications should not use IP 
addresses for referrals. IP addresses fail for referrals in a vast 
number of cases including 1918 addresses, firewalled networks, 
certain asymmetric routing cases, etc. Given the current state of the 
network, you can neither recommend nor completely forbid the use of 
IP addresses for referrals in applications. (And nowhere in what 
Lixia said was the statement that applications MUST NOT use IP 
addresses for referrals.)

>And in fact every application that uses DNS does exactly that.

I think that's a rather narrow view of where DNS falls in the architecture.

>It's all well and good to imagine a world where there would be a 
>clear ID-LOC separation.  But we've never created such a world, and 
>we don't currently have an ID-LOC mapping layer that is good enough 
>to use by all applications.

Yup. In part, that's what LISP is about. But I actually think it's 
incorrect to talk about having "an ID-LOC mapping layer good enough 
to use by all applications". If we're talking about the ideal world, 
applications should almost never need to use the mapping layer; they 
should be able to simply use the ID (without touching the LOC) and 
let the routing system deal with finding a LOC for the ID. That an 
application would have to actually deal with the mapping is an 
artifact of the current state of affairs where neither the LOC (IP 
address) or ID (DNS) is good enough to allow the application to do 
what it needs to do.

>DNS falls short in many ways.  And as long as there is not a 
>universal mapping layer that is aware of things like NATs and 
>mobility, and for that matter as long as there are devices that 
>impose arbitrary limitations on traffic flow (e.g. connections have 
>to be initiated from "inside"), there will be a need for 
>applications to deal explicitly with IP addresses.  Sure it's ugly 
>but it's the best that applications can do.

I'm guessing we're in violent agreement, but NATs and mobility and 
"traffic flow limiters" actually make it impossible (viewing it from 
the other end) to use IP addresses: Giving a reference to myself 
using my own IP address when I am behind a NAT is useless; using a 
name, if one is available, is the only way to go. (And I still agree 
with your above paragraph.)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Mar 2009 15:26:38 -0400

Pete Resnick wrote:
> That IP addresses are currently essential for referral is not mutually
> exclusive with the idea that applications should not use IP addresses
> for referrals.

Let me put it a different way:

Many of us look forward to a day when some other token, identifier,
structure than an IP address will suffice for referrals from and to
anywhere in the network, and this will work so universally and reliably
that there will be no need whatsoever to use IP addresses in referrals.

However that's an incredibly difficult problem to solve, especially as
long as the network contains a large number of NATs in arbitrary
locations.  At the rate we are going now, I'll be very surprised to see
that problem solved before I die.

> I think that's a rather narrow view of where DNS falls in the architecture.

A and AAAA records are address referrals.

>> currently have an ID-LOC mapping layer that is good enough to use by
>> all applications.
> 
> Yup. In part, that's what LISP is about.

Except that LISP doesn't actually define the mechanism to do the mapping
(i.e. maintain the bindings and allow them to be queried), and that's
the hard part of the problem.  At least, it's the hard part of the
problem if you believe that ID-LOC separation can solve the problem of
referrals in the presence of NATs (and maybe some of the other problems
caused by NATs).  If you're just trying to solve the routing scalability
problem the mapping is somewhat easier to accomplish, but then you need
yet another mapping layer to deal with NATs...back to square one.

> But I actually think it's incorrect to talk about having "an ID-LOC
> mapping layer good enough to use by all applications". If we're
> talking about the ideal world, applications should almost never need
> to use the mapping layer; they should be able to simply use the ID
> (without touching the LOC) and let the routing system deal with
> finding a LOC for the ID. That an application would have to actually
> deal with the mapping is an artifact of the current state of affairs
> where neither the LOC (IP address) or ID (DNS) is good enough to
> allow the application to do what it needs to do.

Oh it's perfectly fine with me if the mapping isn't dealt with
explicitly by applications - provided of course, that it works so well
that applications never have a need to deal with it explicitly.  There's
the rub.

>> DNS falls short in many ways.  And as long as there is not a universal
>> mapping layer that is aware of things like NATs and mobility, and for
>> that matter as long as there are devices that impose arbitrary
>> limitations on traffic flow (e.g. connections have to be initiated
>> from "inside"), there will be a need for applications to deal
> "traffic flow limiters" actually make it impossible (viewing it from the
> other end) to use IP addresses: Giving a reference to myself using my
> own IP address when I am behind a NAT is useless; using a name, if one
> is available, is the only way to go.

Actually, the internal IP address is not useless at all, as (a) it's
still often the best identifer for use with other hosts in the same
realm and (b) it is useful to compare with the external IP address (as
obtained by STUN or UPnP or by talking to a peer) to determine if one is
behind a NAT.  Nor is the DNS name the "only way to go" as a DNS query
by a peer might or might not yield a useful result, and two-faced DNS
doesn't work very well, and there are the usual reliability problems
with DNS (especially when making queries through NATs that have buggy
DNS proxies).

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Mar 2009 09:48:28 +1300

I recently had this exchange with Dan Wing on the BEHAVE list:

>> > ... it seems to me
>> > that we might consider defining a generic 'referral object', containing
>> > more information than just an address, that could be passed among
>> > application entities. It could contain TLVs that would provide the
>> > semantics of the referred address as well as the raw address bits.
>> > 
>> > Does this seem worth exploring?
> 
> Yes, this could form the basis for very useful guidance to application
> designers.  ICE does something like this already, but abstracting its
> functions up several levels, as you propose, would be useful.
> 
> Something like:  "here is my IPv4 address, it goes through a 
> translator so avoid using it if you can utilize my IPv6 address" 
> and so on.

   Brian

On 2009-03-20 07:04, Pete Resnick wrote:
> for referrals. IP addresses fail for referrals in a vast number of cases
> including 1918 addresses, firewalled networks, certain asymmetric
> routing cases, etc. Given the current state of the network, you can
> neither recommend nor completely forbid the use of IP addresses for
> referrals in applications. (And nowhere in what Lixia said was the
> statement that applications MUST NOT use IP addresses for referrals.)
> 
> incorrect to talk about having "an ID-LOC mapping layer good enough to
> use by all applications". If we're talking about the ideal world,
> should be able to simply use the ID (without touching the LOC) and let
> the routing system deal with finding a LOC for the ID. That an
> application would have to actually deal with the mapping is an artifact
> of the current state of affairs where neither the LOC (IP address) or ID
> (DNS) is good enough to allow the application to do what it needs to do.
> 
> is available, is the only way to go. (And I still agree with your above
> paragraph.)
> 
> pr

---

From: Christian Vogt <[email-masked]>
Date: Thu, 19 Mar 2009 14:21:34 -0700

Lixia -

> I do not see that (2) is a consequence of (1), as you seem to believe.

I was actually making a different statement.  I was saying that
end-to-end (locator/address) transparency is important in the existing
Internet because IP addresses are overloaded as identifiers by some
applications.  If there wasn't this kind of overloading, then the lack
of end-to-end (locator/address) transparency would be less of an issue.

Another clarification:  I am surprised that you say I would justify IPv6
NAT.  As I said in my posts, NAT does introduce issues simply because
the existing overloading of IP addresses as locators and identifiers
works best if IP addresses are carried unchanged by the network.
Whether these issues are worth the benefits of NATs is something that
requires a separate discussion.

Makes sense?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 19 Mar 2009 14:34:05 -0700

> nat-00
> that either stated or implied "end-to-end *locator* transparency", as
> you attributed to the draft?

Hi Lixia -

I used the term "locator transparency" to distinguish this from other
types of transparency, such as data transparency or, in a world with
identifier-locator separation, identifier transparency.  I found this
useful given that I was talking about identifier-locator separation.

Consequently, "locator transparency" in my posts has the meaning of "IP
address transparency", i.e., the type of transparency that NATs break.
Since your document is about NAT, I am assuming that this is also the
type of transparency that you are referring to in your document.

- Christian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 Mar 2009 17:18:54 +0100

On 19 mrt 2009, at 7:43, Lixia Zhang wrote:

> 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  

Which I find strange. The ability to have 1:1 mappings, which are  
orders of magnitude less harmful than 1:N mappings that we get in  
IPv4, make a huge difference towards NAT in IPv6.

I have no problem with the conclusion that IPv6 NAT shouldn't happen,  
but I'm not very happy with the draft in its current state. See below.  
Also, let everyone realize that "IPv6 NAT shouldn't happen" is a much  
stronger position than "we don't standardize IPv6 NAT". Under the no  
IPv6 NAT regime, the IESG MUST make sure that no mechanisms are  
published by the IETF that allow for nothing else than IPv6 NAT  
traversal. Anything less than that is a de facto "we won't stop IPv6  
NAT but we just don't want to bother standardizing it."

Are we ready to adopt the policy that forbids IPv6 NAT traversal  
mechanisms?

The arguments for NAT are mostly bogus or fall within the "polkadot"  
realm: if the paint shop starts selling paint that's pink with  
fluorescent green polkadots, some person will paint their house with  
that paint, no matter how ugly the results will be.

The renumbering and multihoming arguments are especially troublesome:  
the hard part in multihoming isn't giving a host interface a new  
address, but making sure that everything that points to that address,  
from the DNS to firewall rules, is updated.

NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT  
breaks multihoming because after a rehoming event, the addresses are  
translated differently.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Mar 2009 10:40:46 +1300

Iljitsch,

On 2009-03-21 05:18, Iljitsch van Beijnum wrote:
...
> breaks multihoming because after a rehoming event, the addresses are

It's correct that NAT changeovers break existing sessions. But your blanket
statement isn't true. NAT-based multihoming has the major benefit that
the number of extra BGP4 routes caused by a multihomed site is exactly
zero. That feature may have low value today, but will have very high value
if we collectively succeed in exceeding BGP4's scaling limits.

Also, NAT-based multihoming has value for large international corporate
networks with dozens or hundreds of interconnection points to
the public network. It basically solves their address management
problem when dealing with multiple ISPs in multiple locations. That's
running code today.

Sad but true.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Mar 2009 22:44:35 -0700

>  Internet's flexible and open-ended nature.

I'm actually of a slightly different opinion. I think it is important  
that one application instance be able to select another application  
instance, or a set of them, and send packets to all of those  
applications, one of them, or a specific one as it requires. That  
doesn't mean that the process knows anything about what is happening  
below the application layer; in fact, that would be about naming those  
application instances, and the fact that it can name and exchange  
sessions with sets of applications that it is authorized access to  
implies nothing further than that.

I also think it is important that one transport endpoint be able to  
select another transport endpoint, or a set of them, and send packets  
to all of those transport endpoints, one of them, or a specific one as  
it requires. That doesn't mean that the transport endpoint knows  
anything about what is happening below the transport layer beyond a  
string of bits that it uses to identify the far end; in fact, that  
would be about addressing those transport endpoints, and the fact that  
it can address and exchange datagrams with sets of transport endpoints  
that it is authorized access to implies nothing further than that.

The fact that a system, and by extension the applications and  
transports on it, can identify other systems by name or address is the  
critical bit, not that every system in the network uses the same name  
or address. If that were not true, multi-named systems and multihomed  
systems would be a problem, as would multicast and anycast.

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Mar 2009 09:37:05 -0700

> Are we ready to adopt the policy that forbids IPv6 NAT traversal  

Preemptive to the BOF on the topic? You might recall the IAB making a  
preemptive decision in 1992, just prior to the Cambridge meeting. CLNS  
was going to be the next generation IP as I recall.

---

From: Rémi Després <[email-masked]>
Date: Sat, 21 Mar 2009 10:11:21 -0700

Brian E Carpenter  -  le (m/j/a) 3/20/09 2:40 PM:

Full agreement.

And it's possible to do even better than NATs for multihoming in IPv6.

(That's a feature of SAM.)

I don't understand the configuration of this case.

Any reference to clarify it (or an explanation)?

RD

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 21 Mar 2009 15:52:23 -0400

No business case for IPv6, survey finds But Internet Society members report
rising customer demand, deployment plans

http://www.networkworld.com/news/2009/032009-ipv6-business-case.html?nladnam
e=032009dailynewspmal&code=nldailynewspm187866

Business incentives are completely lacking today for upgrading to IPv6, the
next generation Internet protocol, according to a survey of network
operators conducted by the Internet Society (ISOC).

In a new report, ISOC says that ISPs, enterprises and network equipment
vendors report that there are ``no concrete business drivers for IPv6.''
Developers and Identity Services : Tackling Identity Data with Identity Hub:
Download now

However, survey respondents said customer demand for IPv6 is on the rise and
that they are planning or deploying IPv6 because they feel it is the next
major development in the evolution of the Internet.

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of Brian E Carpenter
>  Sent: Thursday, March 19, 2009 4:48 PM
>  To: Pete Resnick
>  Cc: Christian Vogt; Lixia Zhang; Keith Moore; IETF Discussion Mailing
>  List
>  Subject: Re: Comment on draft-iab-ipv6-nat-00
>  
>  mutually
>  clear
>  let
>  artifact
>  universal
>  the
>  _______________________________________________
>  Ietf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Mar 2009 12:07:37 +1300

...

> Any reference to clarify it (or an explanation)?

Suppose you're operating a large international network with (to take
a random example) IPv4 1/8 as its PI prefix.

You can't just advertise 1/8 in BGP4, because in fact it is split
up into many longer prefixes for various kinds of use and various
geographies. So how do you connect your internal users to the Internet?
(We're talking about desktop users, not about servers in a DMZ.)

You have (I'm making this up) 100 different interconnects to the
public Internet around the world, across a variety of ISPs. If you
advertise longer prefixes out of 1/8 through those ISPs, life gets
highly complex if you want multihoming. Certainly you won't be able
to advertise *all* those prefixes through *all* those ISPs, so you'll need
a complex worldwide management system just for your BGP4 advertisements,
to decide which prefixes are advertised where, and what the desired backup
paths are. It can be done, but the OPEX is high.

So instead, you run NAT at every ISP connection. Your internal users get
NATted to an ISP prefix at whichever exit point their traffic happens
to reach, which automatically causes their return traffic to come through
the same ISP. That exit point is locally chosen by the local routing setup.
You don't need any worldwide coordination of the BGP4 advertisements,
because there aren't any expect the ISP's normal ones. Also, traffic
flows inside your network are localised, since traffic goes out and
returns through a (reasonably) local gateway.

When one of these NATs goes down, active connections will be lost,
but IGP routing will switch users automatically to a different NAT
when they retry.

I'm sure there are people who can give a more accurate explanation
than that.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Sat, 21 Mar 2009 16:52:39 -0700

Thanks, Brian, for the detailed explanation.

IMHO, this case is _very_ interesting.

It identifies one more NAT44 service that must be available in IPv6
with a defined solution for it.

AFAIK, it was not identified in RFC4864, and I didn't have it either in
draft-despres-sam-02.

Regards,

RD

Brian E Carpenter  -  le (m/j/a) 3/21/09 4:07 PM:

...

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 22 Mar 2009 09:04:34 +0900

> a random example) IPv4 1/8 as its PI prefix.

Are you assuming that an organization operating such a large network
does not operate any externally accesible servers?

I would rather assume that there are a lot of such servers distributed
worldwide and the servers are, of course, multihomed.

So, the servers have PI addresses.

As there is no reason to assign extra address block that the PI
addresses will be from 1/8.

Considering that trafic to the servers should be localized, local
PI address block with prefixes longer than 8 should be advertised
to local ISPs, BGP4 advertisement of which must be coordinated
worldwide.

> life gets highly complex if you want multihoming.

That's life.

> I'm sure there are people who can give a more accurate explanation

That there are poeple who are doing unreasonable things does not
rationalize their behaviour.

						Masataka Ohta

---

From: Geoff Huston <[email-masked]>
Date: Sun, 22 Mar 2009 15:34:04 +1100

On 21/03/2009, at 3:18 AM, Iljitsch van Beijnum wrote:

> On 19 mrt 2009, at 7:43, Lixia Zhan"
>

no.

This industry needs standards, and relies on standards.

For many years the Internet Engineering Task Force has viewed  
standardization of NATs and their behaviour as being an action that  
would encourage further deployment of a technology that was apparently  
considered undesireable. The result has been that NATs have been  
deployed for reasons entirely unconnected with the IETF and  
standardization. However,  because the original specification of NAT  
behaviour was at such a general level, each NAT implementor has been  
forced into making local decisions as to how the NAT should behave  
under specific circumstances. We now enjoy a network with widespread  
deployment of an active device that does not have consistent  
implementations and, in the worst cases, exhibits non-deterministic  
behaviours. This has made the task of deployment of certain  
applications on the Internet, including voice-based applications,  
incredibly difficult.

Whether NATs are good or bad, they’d be less of a collective headache  
today if they shared a common standard core behaviour. NATs for IPv6  
may be felt to be unnecessary today, and it can be argued they  
represent no real value to an IPv6 site. But a collection of IPv6 NAT  
implementations with no common core behaviour would be a far worse of  
problem for applications and their users. Standardization of  
technology at least eliminates some of the worst aspects of  
application-level guesswork out of technology deployment.

regards

Geoff

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 07:10:58 -0700

> but IGP routing will switch users automatically to a different NAT

If you allow your hosts to use multiple connection points into the
Internet, and external routing changes so that the packets they send go
out different connection points, their apparent source address can
change.  One of the requirements for effective use of NAT and
multihoming is that your hosts' peers need to handle this (via
Multipath, HIP, MIP, SCTP or whatever).  That is, you can't allow your
hosts to use multiple connection points until everyone _else_ they talk
to has been upgraded.  How will you know when that is?

Scott

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 07:13:47 -0700

> from the DNS to firewall rules, is updated.

But "address independence" eliminates 90% of what needs to be updated
(internal policy etc.)

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 07:21:53 -0700

> of end-to-end (locator/address) transparency would be less of an issue.

OK, now I understand.  You're not talking about end-to-end transparency
in general but end-to-end address transparency.  I think I agree
completely.  We are certainly working toward not caring what addresses
are used.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Mar 2009 03:30:28 +1300

On 2009-03-23 03:10, Scott Brim wrote:
> change.  

True. I should have said 'when one of these NATs go down, or routing changes
such that a user's exit point changes, active connections will be lost.'

> One of the requirements for effective use of NAT and

You won't. Active connections will fail in the scenario I described.
That is inconsistent with the goals defined in RFC3582, but it is
current reality in some places, and applications and/or users have to
deal with it.

(I never said I liked NAT, did I?)

     Brian

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 07:33:26 -0700

> (I never said I liked NAT, did I?)

In your opinion, what sucks less?

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 22 Mar 2009 10:09:29 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott Brim
> Sent: Sunday, March 22, 2009 7:11 AM
> To: Brian E Carpenter
> Cc: Iljitsch van Beijnum; IAB; IETF Discussion Mailing List; 
> Lixia Zhang

A host knows if it is using HIP, MIP, or SCTP to communicate with
another host.  FYI, there is also a new idea for Mobile DTLS which
provides similar address mobility, draft-barrett-mobile-dtls-00.txt.

-d

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 10:28:29 -0700

>> functions up several levels, as you propose, would be useful.

Referrals are hard to figure out.  I think the tradeoffs are worth
serious study.

First party referrals like this are interesting but not so hard as third
party referrals (Tom tells Dick how to reach Harry).  They assume that
Tom knows Dick's and Harry's shared scope.  Can we assume we have some
kind of globally unique identifiers that are globally unique?  So far
that has been extremely hard to pull off.  I have a suspicion that for
referrals you want to go all the way back to domain names and URIs.

Also, the referral problem is multilayer (you want to be able to refer
to processes in addition to machines) but only at the layer that needs
that information.  The question, which is something like the e2e
argument, is whether to bother providing details in network-layer
referrals if they will be trumped by higher-layer needs.

But in any case we should do a major investigation of referrals in the
light of location/identification separation and the fracturing of the
Internet into various scopes.

Scott

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 10:53:02 -0700

Dan Wing allegedly wrote on 03 22 2009 10:09 AM:
>>> When one of these NATs goes down, active connections will be
>>> lost, but IGP routing will switch users automatically to a
>>> different NAT when they retry.
>> 
>> Internet, and external routing changes so that the packets they
>> send go out different connection points, their apparent source
>> address can change.  One of the requirements for effective use of
>> NAT and multihoming is that your hosts' peers need to handle this
>> (via Multipath, HIP, MIP, SCTP or whatever).  That is, you can't
>> allow your hosts to use multiple connection points until everyone
>> _else_ they talk to has been upgraded.  How will you know when that
>> is?
> 
> another host.  

I was asking how the site knows when its hosts peers have been upgraded,
so that it can allow their traffic to be routed out multiple interfaces.

> FYI, there is also a new idea for Mobile DTLS which

Yes but that should be a different thread.

Scott

---

From: Melinda Shore <[email-masked]>
Date: Sun, 22 Mar 2009 14:00:39 -0400

> so that it can allow their traffic to be routed out multiple interfaces.

Yeah, exactly, although the canonical Unix-y way to
do this would be to try it and see what you get back.
If it doesn't work, catch the error and fall back to
whatever it is you've planned to fall back to.
There are obvious problems with this in a network
environment (latency, resource consumption) but it's
already how the IETF has chosen to deal with NAT
traversal (ICE) so I expect there's a reasonable
question about whether or not connectivity tests can
(or should) be extended to transport, etc..

Melinda

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 22 Mar 2009 11:05:19 -0700

> (or should) be extended to transport, etc..

Yeah because resource reservation and and capability negotiation are
definitely thing we want to have to do on an IP network before
initiating a connection.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 22 Mar 2009 11:27:50 -0700

> From: Scott Brim [mailto:[email-masked]] 
> Sent: Sunday, March 22, 2009 10:53 AM
> To: Dan Wing
> Cc: 'Brian E Carpenter'; 'Iljitsch van Beijnum'; 'IAB'; 'IETF 
> Discussion Mailing List'; 'Lixia Zhang'

Thinking out loud, I posit that IPv6 route headers might be useful to 
steer traffic to a specific NAT66, until the host indicates (to the 
network) that it doesn't need such steering.  There are undoubtedly
other techniques.

-d

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 11:38:39 -0700

Keith Moore allegedly wrote on 03 19 2009 5:17 AM:
> applications.  

I don't think this question needs to arise.  There is no need, or
reason, that a single identifier would be used for all purposes.
Identifiers that are used to find out where to send packets for {initial
discovery (mapping), contact, and establishment of a session} do not
have to be the same as identifiers that applications use for session
maintenance.  Higher layer identifiers can be transient and only need to
be unique within their very limited scope of use.  The requirements on
their use are very different from requirements for identifiers used for
initial discovery and contact.  There is no reason why they need to have
anything to do with locators.  Only the identifiers that are used for
initial discovery need to be mapped -- for example domain names and URIs.

> DNS falls short in many ways.  And as long as there is

I don't see this.  You need something (e.g. a domain name or URI) to map
to _some_ addresses which you can use to launch your initial packets
toward your destination.  They don't have to be the same addresses that
the destination thinks it has, as long as the packets get there and
there is a mechanism to establish security associations and multiple
path use.

> function for the entire lifetime of the association.  

No no no.  The address pair just has to last long enough to establish an
association.  If we're lucky we'll figure out how to do it even while IP
addresses are changing.

Scott

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Mar 2009 11:39:43 -0700

> is available, is the only way to go. (And I still agree with your above

Yes.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Mar 2009 12:26:54 -0700

> zero.

No. What you're talking about is multiaddress multihoming.

Then you add NAT to hide the changes to addresses from the hosts. But  
IPv6 hosts can work with multiple addresses anyway (well, there's the  
ingress filtering issue) so NAT is largely orthogonal to the  
multihoming.

Also, shim6 gives you actual multihoming where sessions survive rather  
than the watered down thing where you only get to reestablish new  
sessions.

> problem when dealing with multiple ISPs in multiple locations. That's

People run whatever they can get away with. Doesn't mean it's a good  
idea.

However, I do agree that it's useful to have stable internal  
addressing when external connectivity is subject to change. That is a  
legitimate advantage of NAT (66) which we haven't managed to make work  
without NAT. We could though, by making sure that ULAs are used for  
local connectivity regardless of the external connectivity.

> geographies.

Then what is the point of having a single prefix?

> So how do you connect your internal users to the Internet?

Same way as everyone else, return the /8.

> paths are. It can be done, but the OPEX is high.

Cost for the community is also high because a single organization puts  
a whole bunch of prefixes in the routing table.

> So instead, you run NAT at every ISP connection.

Ok, I said they didn't need the /8 before, but now you've completely  
lost me. What is the point of having that prefix now??

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 22 Mar 2009 12:39:24 -0700

> Behalf Of Joel Jaeggli
> Sent: Sunday, March 22, 2009 11:05 AM
> To: Melinda Shore
> Cc: 'IAB'; 'IETF Discussion Mailing List'

ICE does not perform resource reservation and ICE does not
perform capability negotiation.

-d

---

From: Melinda Shore <[email-masked]>
Date: Sun, 22 Mar 2009 15:43:43 -0400

> perform capability negotiation.

You might not call it that but it does, in fact,
snag resources.  On the capability negotiation
front I figure that's just a matter of time.
(Somebody needs to come up with a cool acronym
expansion for METASTASIS).

That said, I'm not crazy about capability negotiation.
Try something and send meaningful error messages if
it doesn't work.  Avoid race conditions and try to
keep state machines cleaner.

Melinda

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 22 Mar 2009 12:59:24 -0700

> From: Melinda Shore [mailto:[email-masked]] 
> Sent: Sunday, March 22, 2009 12:44 PM
> To: Dan Wing
> Cc: 'Joel Jaeggli'; 'IAB'; 'IETF Discussion Mailing List'
> snag resources. 

ICE sends UDP packets and TCP packets.  I agree they might
create state in a NAT, and state in a NAT is a resource.  But
with that argument my web browser is also doing 'resource
reservation'.

> On the capability negotiation

Sure.  But every exensible protocol can do 'capability
negotiation'.  TCP does it: winscale, timestamps, and SACK
are all capabilities that are negotiated during connection
establishment.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Mar 2009 09:19:07 +1300

> No. What you're talking about is multiaddress multihoming.

That's true too, but it isn't the same scenario. If it's NAT-based,
the site can use a nice home-made ULA prefix and never has to
think about it again. Multi-prefix based multihoming doesn't
have that convenience factor for the site's IT manager.
See draft-carpenter-renum-needs-work for some of the
consequences.

> ingress filtering issue) so NAT is largely orthogonal to the multihoming.

In fact, there's the exit router selection issue as a result of the ingress
filtering issue. Certainly a site with many exits gets that problem
in any case, but I suggest that it's less acute in the NAT model
because in the end, any exit point will do.

> than the watered down thing where you only get to reestablish new sessions.

Correct. That's why we're standardising shim6. The question isn't there;
it's about what gets deployed.

> People run whatever they can get away with. Doesn't mean it's a good idea.
> 
> However, I do agree that it's useful to have stable internal addressing
> when external connectivity is subject to change. That is a legitimate
> advantage of NAT (66) which we haven't managed to make work without NAT.
> We could though, by making sure that ULAs are used for local
> connectivity regardless of the external connectivity.

Yes. So how can we persuade IT managers to adopt that as standard
practice?

> Then what is the point of having a single prefix?

Mainly historical, or to say it another way, a large corporate
network acquires its own routing swamp over many years. Suppose
you sell a department of the company off to another company, for
example, but the cost of renumbering is considered too high?
(I am not making any of this up, although 1/8 is an example.)

> Same way as everyone else, return the /8.

Not if you want to do traffic engineering, so that traffic for
the Hong Kong office doesn't enter the Internet in New York.

> Cost for the community is also high because a single organization puts a
> whole bunch of prefixes in the routing table.

Yes

> lost me. What is the point of having that prefix now??

None, by now; it's become a private swamp.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Sun, 22 Mar 2009 18:06:28 -0700

Scott Brim wrote:
> Tom knows Dick's and Harry's shared scope. 

...or that Dick can, given the information in the referral structure
obtained from Tom, figure out an effective way to reach Harry given
their shared scope.

> Can we assume we have some kind of globally unique identifiers that are globally unique?  So far
> that has been extremely hard to pull off. 

Yes and no.  We've managed to cope with the IPv4 address shortage in the
short term and get away with not requiring every host to have a global
address.  But this is only because there is still a large set of
globally unique addresses.

> I have a suspicion that for referrals you want to go all the way back to domain names and URIs.

Ah, if only that would work well...  it's a house of cards.

> Internet into various scopes.

It might be a bit late for that.

Keith