Subject: [BEHAVE] Why IETF should standardize IPv6 NAT

From: Christian Vogt <[email-masked]>
Date: Sun, 2 Nov 2008 17:18:26 +0200

Hi Margaret and all,

I have read Margaret's IPv6 NAT proposal, draft-mrw-behave-nat66-00, and
I fully support this being standardized in the IETF.  Here is why:

There is good reason to believe that address translation will be used in
IPv6, because it enables the operation of a network (1) in a
provider-independent manner, and (2) without going through the process
of acquiring global IPv6 addresses.  Since the use of NAT at one end of
a communication has implications to both ends of the communication, IETF
should ensure that IPv6 NATs are minimally disruptive and behave
predictably.  The only way to achieve this is through standardization.

Moreover, IPv6 NAT can be designed to be architecturally more acceptable
than IPv4 NAT, because the issues of IPv4 NAT can partly be avoided in
IPv6 NAT.  The issues of IPv4 NAT can be summarized thus:

(1) Unidirectional reachability -- Hosts behind an IPv4 NAT cannot be
     contacted from hosts on the other side of the IPv4 NAT because they
     use non-unique addresses.

(2) Reduced robustness -- IPv4 NATs are single point of failures.  They
     build up dynamic state that communications depend on, and hence
     limit a network’s ability to reroute traffic in case of path
     failures.

(3) Broken address referrals -- Applications that refer to hosts by IP
     address expect that a host's IP address is the same across the
     entire Internet.  IPv4 NATs break this expectation because they  
make
     a host's IP address a function of the location of the peer.

These issues are often subsumed as "breaking the end-to-end principle".
But I think it is worthwhile separating the issues because they have
different causes, and some of those can be avoided for IPv6 NAT.

The cause for issues (1) and (2) is that IPv4 NATs use address
multiplexing, i.e., they map multiple host addresses onto a single
translated address.  This implies unidirectional reachability because a
recipient host behind an IPv4 NAT cannot be identified based on only a
translated address.  And it implies reduced robustness because the state
of an IPv4 NAT, which is required to demultiplex a translated address
back onto the correct host address, makes it difficult to fail over an
active communication from one IPv4 NAT to another.  The cause for issue
(3) is the lack of transparency to applications.

The potential advantage of IPv6 NAT over IPv4 NAT is that the former can
avoid issues (1) and (2):  It does not require address multiplexing
because the sufficient availability of global IPv6 addresses enables
one-to-one address translation.  This leaves issue (3) for IPv6 NAT --
an issue that IMO should be tackled by a new API between applications
and the TCP/IP stack that hides IP addresses from applications.

This is why I believe IETF should standardize IPv6 NAT.  And I think
draft-mrw-behave-nat66-00 is a really good starting point.

- Christian

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Christian Vogt <[email-masked]>
Date: Sun, 2 Nov 2008 17:38:12 +0200

One more thing:  Earlier in the Routing research group, I had proposed
the same IPv6 address prefix mapping technique as described in
draft-mrw-behave-nat66-00 as a potential solution to the routing
scalability problem.  Even the trick for avoiding checksum changes is
the same.  Here is the latest paper:

http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf

In a nutshell, the paper describes a technique, Six/One Router, that
enables provider-independent addressing in edge networks without
negative impacts on global routing scalability.  It achieves this with
one-to-one translation between provider-independent IP addresses (for
use in edge networks) and provider-allocated IP addresses (for efficient
routing across the Internet core).  The translation is transparent to
end hosts if Six/One Router is deployed on both sides of a communication
because the translation is then reversed prior to packet delivery.  If
deployed only unilaterally, Six/One Router reduces to non-transparent
address translation.  And then it works exactly as described in
draft-mrw-behave-nat66-00.  Check sections 2.1 and 2.4.4 in the paper.

- Christian

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 2 Nov 2008 11:10:25 -0500

Thanks for the reference, Christian.  I certainly don't take sole  
credit for the idea of a transport-agnostic, checksum-neutral mapping  
mechanism, and it is possible that the discussion I've seen of these  
ideas was inspired by your paper.  I was not previously aware of your  
work, but I will add a citation to this paper in the next version of  
the NAT66 draft.

Margaret

---

From: Christian Vogt <[email-masked]>
Date: Sun, 2 Nov 2008 18:48:42 +0200

Margaret Wasserman wrote:

> credit
> for the idea of a transport-agnostic, checksum-neutral mapping
> the
> NAT66 draft.

Thanks, Margaret.  But note that, what I wanted to point out with my
email is the potential synergies between the work in Behave and the work
in RRG.  There are good arguments that very similar techniques, or even
the same technique, could be suitable for both Behave and RRG -- perhaps
with extensions to meet the more ambitious objectives of RRG.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 02 Nov 2008 18:13:44 +0100

Hi,

I can certainly see what Christian is pointing out.
I mean, if you want to achieve provider independence, a NAT66 is a good 
way yo start, since it provides you the benefits and only requires the 
interested site to deploy it to get the benefits, providing a powerful 
deployment model.
However, we don't need to stop there.
We can create a NAT-to-NAT protocol, that can be used to restore the 
addresses contained in the packet, restoring e2e transparency while 
changing the IP addresses used to route the packet between the two NAT 
boxes.
In other words, if properly designed, the NAT66 could be a first step of 
an architecuture that allows restoring the e2e transparency if both ends 
deploy these enhanced NAT boxes.

Regards, marcelo

Christian Vogt escribió:
>> Thanks for the reference, Christian.  I certainly don't take sole credit
>> work, but I will add a citation to this paper in the next version of the
>> NAT66 draft.
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 2 Nov 2008 12:14:12 -0500

> with extensions to meet the more ambitious objectives of RRG.

I agree with you.  It is likely that a stateless, transport-neutral  
IPv6 NAT could be used as the basis of a two-tiered (or multi-tiered)  
local/global routing architecture that would correspond to some of the  
ideas discussed in the RRG.

Margaret

---

From: Christian Vogt <[email-masked]>
Date: Sun, 2 Nov 2008 21:41:00 +0200

marcelo bagnulo braun wrote:

> I can certainly see what Christian is pointing out. [...]  If properly
> designed, the NAT66 could be a first step of an architecuture that
> allows restoring the e2e transparency if both ends deploy these  
> enhanced
> NAT boxes.

Precisely.

If there is sufficient interest, I could re-deliver an older 15-min
presentation about Six/One Router at the Behave session.  This would be
about exactly what Marcelo said:  How to specify a translation box (call
it a "NAT66" or a "Six/One router"), which anyone can deploy locally and
independently of others.  And should there be such boxes on both sides
of a communication, the boxes will figure this out and start restoring
end-to-end transparency.

- Christian

---

From: Rémi Després <[email-masked]>
Date: Sun, 02 Nov 2008 22:55:51 +0100

> ideas discussed in the RRG.
The  draft-despres-sam 02, which I plan to post late on Monday, is along 
this line.

Most of the document deals with address mappings and encapsulations for 
local domain traversals,  a subject for  Softwires. But it has also a 
section on privacy protection in IPv6, which is  clearly relevant to 
this discussion thread. It is quoted below (the sentence with v6E can be 
ignored so far, and v6G means global IPv6).

Regards,

RD

<<<
3.6.  On demand privacy protection

   IPv6 end-to-end (i.e. without NAT traversal) is the only way to
   restore both global reachability, at stable address and ports without
   port restrictions, and the end to end packet preservation which is
   needed for transport protocols that apply a stronger checksum
   algorithm than the 16-bit one's complement of UDP and TCP (e.g.
   SCTP).

   On the other hand, NATs are known to provide some privacy protection
   because individual hosts behind NATs cannot be identified from the
   outside and because, behind NATs, private routing topologies are
   hidden.  There are consequently some advocates for the deployment of
   IPv6 to IPv6 NAT to be endorsed by IETF (NAT66s).  Without strong
   caveats, and restrictions on what these NAT66s would do, this could
   break confidence in IPV6 end-to-end capabilities, and encourage a
   longer use of IPv4, with its NATs and NAT cascades.

   It is therefore proposed to limit address and port translations to
   outgoing connections of internal hosts that use privacy addresses.
   Thus, users that consciously request privacy are informed that they
   implicitly accept some service limitations, which other users don't
   want to accept, and that the same users may not wish to accept at
   different times (then using other local addresses).

   In v6G addresses, a privacy demand is already coded as bit 6 of the
   9th octet set to 0.  In v6E addresses, the proposed coding for
   privacy demands is in the v6E tag (Section 3.2.4), with bit 0 set to
   1.

   When a SAM has to forward an IPv6 global packet to an external domain
   with an IPv6 source expressing a privacy demand, it scrambles, in an
   arbitrary way provided it is reversible, bits of the internal host
   address that follow the global prefix P, and bits 2-15 of the
   internal port if it is a dynamic port (thus performing a locally
   known 1:1 mapping).  The reverse mapping is performed in packets
   destined to internal hosts that have privacy requirement in their
   address.

   The freedom to choose any reversible scrambling algorithm should make
   it difficult to discover it from the outside.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 3 Nov 2008 09:28:54 +0200

>      use non-unique addresses.

Even with 1:1 address mapping, a.k.a. pure NAT instead of NAPT, you won't get 
unidirectional reachability, unless:
1/ the NATted host knows its external address,
2/ the external address "works" even in the absence of any traffic.

This is possible for fully stateless NAT. But Margaret's document does not 
mandate stateless NAT, in my understanding. Another nice thing about 
stateless translation is that it's very easy to pass all BEHAVE requirements 
with it. An example stateless NAT is the Linux traffic classifier (not to be 
confused with the more commonly use Linux Netfilter, which is statefull).

>      limit a network’s ability to reroute traffic in case of path

This seems unlikely to go away with NAT66. You can implement failover with 
NAT44 as with NAT66. I fail to see how NAT66 is better here.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 03 Nov 2008 09:38:49 +0100

> NAT44 as with NAT66. I fail to see how NAT66 is better here.

well, not necesarilly... if the algorithm used to map the internal to 
the external is fully stateless as you say, we have two cases imho. The 
one where the "public" side of both nats are able of using the same 
prefix, in which case you achieve reliability wihtout any inter-nat 
protocol or
 in the case they can't do that, in which case it doesn't work in any case.

So, i think it is possible that the nat66 case can be more robust, at 
least in some cases

regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Mon, 3 Nov 2008 11:30:08 +0200

Rémi -

> 2/ the external address "works" even in the absence of any traffic.

You mean "you won't get bidirectional reachability", right?

But I disagree, actually.  If you have 1-to-1 translation, and  
provided that the application does not use address referrals, you have  
bidirectional reachability even if hosts don't know their external  
address.

> This seems unlikely to go away with NAT66. [...]

Let me clarify; perhaps we have a misunderstanding:  The robustness  
issue is absent if (and only if) the translator is stateless.  Traffic  
can then seamlessly fail over or load-balance between translators  
because there is no dependency on state within any particular  
translator.  You need to put translators on multiple paths, of course  
-- e.g., on all network border links.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 03 Nov 2008 10:40:56 +0100

Christian Vogt escribió:
> issue is absent if (and only if) the translator is stateless.
I think you need to clarify more than that
in nats, i think the meaning of stateless is associated to the case 
where there is no state per flow.
However, here is is not enough with that imho.
I mean, if you have two nat66 and they are connected to different isps, 
and enve though they don't have state per flow, this doesn't provide the 
robustness features that we are looking for, since the PA prefix will be 
different.

regards, marcelo

>   Traffic can then seamlessly fail over or load-balance between 
> translators because there is no dependency on state within any 
> particular translator.  You need to put translators on multiple paths, 
> of course -- e.g., on all network border links.
>
> - Christian
>
>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 3 Nov 2008 11:45:34 +0200

> bidirectional reachability even if hosts don't know their external

Eh no. If you need to send a packet outside for the external address to be 
assigned, then you don't have bidirectional reachability, i.e. you cannot run 
a passive TCP/SCTP/DCCP socket). That's how NAT usually works.

Inbound reachability can only work if there is a well-defined surjection from 
the external address space to the internal address space. This pretty much 
implies:
1/ stateless translation, or
2/ manually provisioned address mappings, or
3/ a mapping preallocation mechanism (needs changes to the hosts).

---

From: Christian Vogt <[email-masked]>
Date: Mon, 3 Nov 2008 12:13:45 +0200

marcelo bagnulo braun wrote:

> I mean, if you have two nat66 and they are connected to different  
> isps, and enve though they don't have state per flow, this doesn't  
> provide the robustness features that we are looking for, since the  
> PA prefix will be different.

But that's not an issue introduced by the NAT, right?  It's an issue  
of multi-homing with provider-allocated addresses in general.

- Chris

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 03 Nov 2008 11:17:27 +0100

Christian Vogt escribió:
>> provide the robustness features that we are looking for, since the PA 
>> prefix will be different.
>
right, but i guess you want to address it, right?

---

From: Christian Vogt <[email-masked]>
Date: Mon, 3 Nov 2008 13:22:03 +0200

>> But that's not an issue introduced by the NAT, right?  It's an  
>> issue of
>> multi-homing with provider-allocated addresses in general.
>

Certainly.  I just would like to emphasize that it is not the stateless
NAT that is causing the multi-homing problem. The problem exists anyway.

Unfortunately, the multi-homing problem is hard.  I don't think it is
possible to provide seamless failover and load balancing between
provider-allocated prefixes without support at both ends of a
communication.  The reason is that only with support on both ends will
we be able to hide the provider-allocated addresses from both peers.

But perhaps we could live without such seamless failover and load
balancing.  Perhaps application-level re-connects would be sufficient as
a failover mechanism.  Then, if connectivity via one provider fails, it
would be up to the application to try again using a different
provider.  I think this would be a reasonable approach given that
applications anyway need to be capable of handling multiple source
addresses in efficient manner.

To enable application-level re-connects, edge networks would use
multiple internal, provider-independent sub-prefixes, one per provider,
and each internal sub-prefix would map onto exactly one external,
provider-allocated prefix.  Hosts consequently would have one internal
IP address per provider.  Source-address-dependent routing within an
edge network would ensure that egress traffic from a particular internal
sub-prefix is delivered to the NAT that translates onto the
corresponding external prefix.

- Christian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Nov 2008 12:56:30 +0100

On 3 nov 2008, at 8:28, Rémi Denis-Courmont wrote:

> This is possible for fully stateless NAT.

> NAT44 as with NAT66. I fail to see how NAT66 is better here.

See your own sentence above: "this is possible for fully stateless  
NAT": you just send the packets to the other NAT which applies the  
same translation.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Lars Eggert <[email-masked]>
Date: Mon, 3 Nov 2008 17:52:17 +0200

On 2008-11-2, at 19:13, ext marcelo bagnulo braun wrote:
> changing the IP addresses used to route the packet between the two  
> NAT boxes.

FWIW, DoCoMo Japan had a proposal a few years back that did exactly  
that for NAT44 called IP^2 ("IP square").

Lars

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 3 Nov 2008 10:56:11 -0500

> NAT44 as with NAT66. I fail to see how NAT66 is better here.

I don't agree.  I think it is possible to build a network using NAT66  
that is no less robust than an IPv6 network that doesn't use NAT.

If you use a completely stateless NAT66 mapping (such as the two-way,  
algorithmic mapping described in my NAT66 document), NAT66 devices can  
translate arbitrary inbound or outbound packets, without the need to  
have seen earlier packets in the same connection.  This allows  
adaptive (and even asymmetrical) routing to work properly, because  
traffic from a single connection does not need to run through a single  
NAT66 device.  So, you can have multiple redundant routers (all  
running NAT66 with the same internal/external prefixes configured),  
and your connection will not fate-share with any one NAT device.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 3 Nov 2008 11:00:28 -0500

> a passive TCP/SCTP/DCCP socket). That's how NAT usually works.

This is how NAT44 usually works, but it is not how the default (two- 
way, algorithmic)
mapping for NAT66 works.  With the default mapping, connections can be  
initiated in
both the inbound and outbound direction, because there is a 1:1  
correspondence
between inbound and outbound addresses, and an algorithm can be used  
in either
direction to translate one address to the other.

> 1/ stateless translation, or

This is the case with the two-way, algorithmic address mapping defined  
in the NAT66
document.

Margaret

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 03 Nov 2008 17:43:30 +0100

> that for NAT44 called IP^2 ("IP square").
very interesting!
a pointer?
Look in google for it and find a company that builds chip sets....

any idea how the solve the security issues?

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Mon, 3 Nov 2008 21:39:22 +0200

>> NAT

Note that the NAT-to-NAT protocol would also work for translation
between IP versions.

In particular the variant IPv4-to-IPv6-to-IPv4 could be interesting:  It
would enable legacy IPv4 networks with provider-independent address
space to communicate with each other across an IPv6-only Internet core
that routes efficiently based on provider-allocated addresses.

- Christian

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 3 Nov 2008 12:00:05 -0800

(apology for jumping into the middle; yet to read the earlier msg on  
this thread)

> that routes efficiently based on provider-allocated addresses.

hmm...
NAT has a unique edge in that it can be done by one party only,  
without anyone else knowing it.

If one has to do something at both ends, then wouldn't encapsulation  
an easier/better way out?
i.e. I can paraphrase the above using encapsulaiton:

    IPv4-to-IPv6-to-IPv4 can be done thru encap.   It would enable
    legacy IPv4 networks with provider-independent address
    space to communicate with each other across an IPv6-only
    Internet core that routes efficiently based on provider-allocated
    addresses.

Lixia

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 03 Nov 2008 21:21:22 +0100

>    Internet core that routes efficiently based on provider-allocated

the point that we are making is that NAT provides a smooth dpeloyment model
If you support only one edge, you use nat as usual
If both end support it, then you reverse the operation at the receiving end
Encapsulation doesn't have that feature i guess, since you need both 
ends for this work

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Nov 2008 21:27:05 +0100

> If both end support it, then you reverse the operation at the  

But how useful is it for me to know that the host I'm talking to  
thinks it's 192.168.0.2 and not the 223.223.223.223 that I see in the  
source address fields in the packets it sends me?

The only time we care is when the host we're talking to moves to a new  
externally visible address. Then we need to know it's still the same  
host when we get packets with a different source address. But we  
already have shim6 and mobility that can give us that.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 03 Nov 2008 21:29:07 +0100

> source address fields in the packets it sends me?

very useful
cause if the primary path fails, you change paths and the receiver sees 
that same address

regards, marcelo

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 3 Nov 2008 15:45:15 -0500

On Nov 3, 2008, at 3:29 PM, marcelo bagnulo braun wrote:
>> thinks it's 192.168.0.2 and not the 223.223.223.223 that I see in  
>> the source address fields in the packets it sends me?
>
> very useful
> cause if the primary path fails, you change paths and the receiver  
> sees that same address

The problem with all of these mechanisms is how the reverse mapping  
information is obtained or communicated across the Internet in a  
scalable way.  External signalling?  Signalling inside the translated  
packets?  Some sort of global mapping infrastructure?  To add a  
painful twist, to be really useful, it has to be possible to exchange  
this information (securely!) between entities that have no 1:1 social  
or contractual relationship.

If you can solve that problem, then there are a lot of ways to make  
what you are describing work.  If you can't solve that problem, then a  
big chuck of your solution is missing.

Margaret

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 03 Nov 2008 22:06:02 +0100

> or contractual relationship.
exactly
imho, one the most complex part of the problem as you point out is security
> big chuck of your solution is missing.

We do have solutions for IPv6 that would do the trick imho
Not sure how much we want to jump into solution space (of this part i 
mean, the nat part is good)

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Nov 2008 15:50:56 +1300

On 2008-11-04 00:22, Christian Vogt wrote:
...
> addresses in efficient manner.

Needless to say, that was discussed to death in the MULTI6 WG, and
the consensus (in RFC3852) was to include seamless transport failover
and load balancing in the goals. I had my doubts at the time, for the
reason you give, and many applications, not to mention SCTP, handle
failover as you describe.

    Brian

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 3 Nov 2008 23:08:43 -0800

On Nov 3, 2008, at 12:21 PM, marcelo bagnulo braun wrote:

>>>> FWIW, DoCoMo Japan had a proposal a few years back that did  
>>>> exactly that
>>>> for NAT44 called IP^2 ("IP square").
>>>
>> If one has to do something at both ends, then wouldn't  
>> encapsulation an easier/better way out?

Hi Marcelo, note that my msg was specifically on the point made in  
Christian's msg: 2-end NATing could help with routing scalability  
problem.  I just wanted to point out that, if one has to make changes  
at both ends, encapsulation seems an even better thing than 2-end  
NATing.

I also agree with Margaret that the hard problem is how to obtain the  
reverse mapping info.

Lixia

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Nov 2008 09:37:21 +0100

On 4 nov 2008, at 8:08, Lixia Zhang wrote:

> note that my msg was specifically on the point made in Christian's  
> msg: 2-end NATing could help with routing scalability problem.

Maybe we should discuss this on the RRG list...?

> I just wanted to point out that, if one has to make changes at both  
> ends, encapsulation seems an even better thing than 2-end NATing.

Not necessarily. The problem with encapsulation is that it makes  
packets larger, which is less efficient to start with, and worse,  
opens up MTU issues.

But the main reason to use translation rather than encapsulation would  
be that you could apply the translation on one end, and if the other  
end doesn't support translation, you still have a valid packet, with  
the only issue with the currently proposed NAT66 being that referrals  
won't work without extra effort from applications.

With encapsulation, you need a decapsulator. In the current internet,  
we can't assume the presence of decapsulators. But I guess if LISP or  
something gets deployed widely this will be different.

> I also agree with Margaret that the hard problem is how to obtain  
> the reverse mapping info.

We have some proposals for this, which seem like they can grow up to  
be something useful, although they all seem to have issues currently.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Christian Vogt <[email-masked]>
Date: Tue, 4 Nov 2008 12:07:18 +0200

Hi Lixia -

> ends, encapsulation seems an even better thing than 2-end NATing.

Why?

I agree with the advantages of translation that Iljitsch and Marcelo
have pointed out.  And in addition, I don't see any disadvantage
compared to tunneling.

Let me also forestall one common fallacy:  It may seem that, to
re-establish an original packet, it is simpler to decapsulate than to
reverse-translate because reverse translation requires a lookup in a
mapping table.  However, a mapping table lookup also has a security
function because it verifies the mapping between two addresses.  So a
mapping table lookup, or an alternative security function, would also
need to be provided by tunneling techniques.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 4 Nov 2008 12:43:01 +0200

On Nov 3, 2008, Margaret Wasserman wrote:

> painful
> twist, to be really useful, it has to be possible to exchange this
> information (securely!) between entities that have no 1:1 social or
> contractual relationship.
>
> what
> you are describing work.  If you can't solve that problem, then a big
> chuck of your solution is missing.

Absolutely.  Several solutions have been proposed in RRG to distribute
mapping information, ranging from reactive pull to proactive push
mapping systems.  Clearly, the need for such a mapping system is the
cost for transparency.

The next question is whether transparency is worth this cost.  The main
reason I proposed Six/One Router is that it gives you a benefit even
without paying this cost, namely, if you run the protocol in unilateral
mode, i.e., in "NAT66 mode".

- Christian

---

From: Rémi Després <[email-masked]>
Date: Tue, 04 Nov 2008 11:59:31 +0100

> corresponding external prefix.
Christian,

I believe you should be interested in the just posted draft 
http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt.

It deals with the multihoming problem.
IMU,  it introduces a solution for seamless failover, provided Shim6 or 
SCTP is used.

It also introduces an on demand address and port scrambling, for 
privacy, applicable to hosts that use their ISP specific global addresses .

Time has been insufficient to work on convergence of this proposal and 
Margaret's NAT66 proposal.

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 04 Nov 2008 14:04:05 +0100

> something gets deployed widely this will be different.
http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt is a 
proposal in this direction.
Regards,
RD

---

From: Lars Eggert <[email-masked]>
Date: Tue, 4 Nov 2008 15:33:43 +0200

James Kempf may have some pointers.

On 2008-11-3, at 18:43, ext marcelo bagnulo braun wrote:

>>> We can create a NAT-to-NAT protocol, that can be used to restore  
>>> the addresses contained in the packet, restoring e2e transparency  
>>> while changing the IP addresses used to route the packet between  
>>> the two NAT boxes.
>>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 4 Nov 2008 15:35:02 +0200

On 2008-11-3, at 22:00, ext Lixia Zhang wrote:
> without anyone else knowing it. If one has to do something at both  
> ends, then wouldn't encapsulation an easier/better way out?

The one good thing about NAT vs. encaps is that it doesn't have MTU  
issues.

Lars

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 4 Nov 2008 08:41:25 -0800

> Maybe we should discuss this on the RRG list...?

quoting a toddler, "he started here!":)

> packets larger, which is less efficient to start with, and worse,  

1/ lets put things in perspective: translating a v4 packet to v6
    already increases its size.
2/ I heard MPLS encap. had MTU problem too?  and people managed to  
cope with it
3/ tunneling/encap. are used by a number of things.
    One needs to figure out a way to deal with MTU

> But the main reason to use translation rather than encapsulation  
> would be that you could apply the translation on one end,

I thought that was in the first sentence of my first reply:-)

> and if the other end doesn't support translation, you still have a  
> valid packet, with the only issue with the currently proposed NAT66  
> being that referrals won't work without extra effort from  
> applications.
>
> With encapsulation, you need a decapsulator. In the current  
> internet, we can't assume the presence of decapsulators. But I guess  
> if LISP or something gets deployed widely this will be different.
>

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 4 Nov 2008 08:49:14 -0800

> have pointed out.  And in addition, I don't see any disadvantage

I assume you meant encapsulation.

why it is better: personally I believe it is best not to touch the  
packets if everything else being equal.

that could avoid a host of potential issues.  We all learned  
modularity in school. We want to decouple a box mid of a network from  
what hosts might do with its packet header (or even inside)

> need to be provided by tunneling techniques.

this is my first time hearing this "common fallacy":-)
I had thought it was the other way around

Lixia

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Nov 2008 18:00:12 +0100

> modularity in school. We want to decouple a box mid of a network  
> from what hosts might do with its packet header (or even inside)

Unfortunately things aren't this simple. With stateless translation  
there is a single function that gives you the output from the input,  
while with encapsulation you must derive the outer header from fields  
in the inner header, which is more work. (But if there is multihoming,  
we need state for the translation as well.)

About MTU issues with NAT64: there are some, but the common case is  
TCP where a maximum segment size option is exchanged that makes the  
IPv4 side send packets that fit after translating the header into IPv6.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Christian Vogt <[email-masked]>
Date: Tue, 4 Nov 2008 22:04:38 +0200

Lixia -

> modularity
> in school. We want to decouple a box mid of a network from what hosts
> might do with its packet header (or even inside)

I think what you are after is a robustness issue:  You want to minimize
the impact on the overall system in case a system component fails.
Modularity is certainly an important tool to achieve this.  And in many
cases, encapsulation can provide modularity.

But not in this case.  The reason is that, opposite to translation,
encapsulation cannot easily fall back to an asymmetric mode, i.e., a
mode where packet changes at the sending side are not reversed at the
receiving side.  Consequently, in the event of a mapping system failure,
encapsulation will fail altogether, while translation continues to work.

> this is my first time hearing this "common fallacy":-) I had thought  
> it
> was the other way around

Not sure if you agree with me or not. ;-)  Can you clarify?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 4 Nov 2008 22:59:01 +0200

Hi Lixia -

> cope
>   with it

Packet size increments actually are an MTU issue not so much in general,
but rather more specifically when they happen outside the administrative
domain of the sending host.  This will never happen with translation,
but it may happen with encapsulation.

Packet size increments are less problematic if known to the sender's
domain because the sender's domain can then take action to make the
sending hosts use an appropriately smaller packet size.  Packet sizes
will therefore still be within limits despite the increments.  However,
if the administrative domain of the sending host does not know about the
packet increase, then it won't take such action and packets may be too
large after incrementing.

The reason why this problem can only arise with encapsulation is because
encapsulation depends on proxies to process packets on behalf of legacy
networks.  Such proxies will increase the size of packets without the
sending side knowing about it.  In contrast, translation does not
require proxies because it can fall back to an asymmetric mode where
packet changes at the sending side are not reversed at the receiving
side.  So with translation, packet size increments never happen outside
of the sender's domain.

- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Nov 2008 10:05:34 +1300

> need to be provided by tunneling techniques.

You can argue that shim6 is an existence proof for such solutions -
it is in fact a two-ended NAT that verifies the address mapping.
But because it uses some in-band signalling, it also has a (minor)
MTU issue. A variant that avoids in-band signalling would avoid
that problem too. A proxy-shim6 solution is pretty much equal to
two-ended NAT.
http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt

    Brian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 4 Nov 2008 23:27:31 +0200

Brian -

> it is in fact a two-ended NAT that verifies the address mapping.

Exactly.

> MTU issue.

Referring to my previous email, this MTU issue is indeed minor because
the host can ensure by itself that the size of the final, incremented
packet does not exceed the permitted maximum.

- Christian

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Nov 2008 17:38:07 -0800

> IPv4 side send packets that fit after translating the header into  

Well, with a little help from some friends. The tunnel from my home  
office to Cisco uses an option

     interface Tunnel13
        ip tcp adjust-mss 1360

that tells it that I have authorized it to reach up into passing SYN  
and SYN-ACK packets and adjust the MSS down. I think you're suggesting  
that an IPv4/IPv6 translator would do the same, and it probably needs  
to. But I'm not sure I'm ready to write that in an RFC... I would  
probably just hope (in an RFC) that Path MTU fixed it.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave