Subject: [BEHAVE] Translating proto 41 tunnels in CGNAT?

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 14 Jan 2013 14:14:46 +0100

Hi all,

One of the issues with carrier grade NAT is that it breaks IPv6-in-IPv4 tunneling mechanisms that use protocol 41 encapsulation, because here the IPv6 header follows the IPv4 header without a UDP header or anything else containing something resembling port numbers in between.

However, it doesn't seem too difficult to make protocol 41 NATing work: simply use the embedded IPv6 destination address for demultiplexing. With this in place, existing IPv6-enabled home gateways could talk to existing tunnel brokers (tunnelbroker.net, sixxs.net) even though there's a carrier grade NAT in the middle.

Thoughts?

Iljitsch

---

From: Wes Felter <[email-masked]>
Date: Mon, 14 Jan 2013 10:54:22 -0600

> One of the issues with carrier grade NAT is that it breaks IPv6-in-IPv4 tunneling mechanisms that use protocol 41 encapsulation, because here the IPv6 header follows the IPv4 header without a UDP h…

If CGN is in place, then native IPv6 should also be there and there's 
little need for those tunnels. IMO tunnel brokers are a placebo that's 
slowing down adoption of real IPv6.

-- 
Wes Felter
IBM Research - Austin

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Jan 2013 17:12:54 +0000

On 14/01/2013 16:54, Wes Felter wrote:
>> One of the issues with carrier grade NAT is that it breaks
>> IPv6-in-IPv4 tunneling mechanisms that use protocol 41 encapsulation,
>> because here the IPv6 header follows the IPv4 header without a UDP
>> header or anything else containing something resembling port numbers
>> in between.
> 
> If CGN is in place, then native IPv6 should also be there 

We can agree that it *should* be there, but only if the ISP
has decided to put it there, and many haven't, unfortunately.

> and there's

One thing they are not is a placebo (something that works by a
psychological effect). For users stuck behind a reluctant ISP,
they are by contrast the only solution, which is why I use
SixXs.

otoh I don't think that adding this feature to a CGN is the best
use of an ISP's time. See RFC 6264.

   Brian

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Jan 2013 18:22:25 +0100

Le 2013-01-14 14:14, Iljitsch van Beijnum a écrit :
> However, it doesn't seem too difficult to make protocol 41 NATing
> work: simply use the embedded IPv6 destination address for
> demultiplexing. With this in place, existing IPv6-enabled home
> gateways could talk to existing tunnel brokers (tunnelbroker.net,
> sixxs.net) even though there's a carrier grade NAT in the middle.

BCP: don't use proto 41 behind a NAT.

Use an IPv6 tunnelling protocol that supports NAT.
E.g.: TSP [RFC5572], which is used at freenet6.net.

Simon

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 Jan 2013 09:23:07 -0800

> E.g.: TSP [RFC5572], which is used at freenet6.net.

And there is also this http://tools.ietf.org/html/rfc6732

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 14 Jan 2013 21:51:21 +0100

> And there is also this http://tools.ietf.org/html/rfc6732

Wait, what? You are suggesting that ISPs not only do CGNAT for IPv4, but also for IPv6?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 14 Jan 2013 21:56:17 +0100

> use of an ISP's time. See RFC 6264.

Not sure if ISPs write their own CGN code...

The big selling point of protocol 41 through CGN is that it works with unmodified home gateways and unmodified tunnel brokers. I've had IPv6-capable home gateways since 2004 or 2005, but I'm not sure if any of them would be able to handle native IPv6 the way it's rolled out today (I hope to find out one of these days!), and they certainly don't support 6rd or AYIYA or anything like that.

Protocol 41 is the lingua franca of IPv6-in-IPv4 tunneling. I think it's helpful to support it when and where possible.

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Jan 2013 02:13:48 -0500

> BCP: don't use proto 41 behind a NAT.

BCP: don't use NAT.  At all.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Jan 2013 14:25:31 +0100

> E.g.: TSP [RFC5572], which is used at freenet6.net.

I find it annoying that pretty much all comments miss the point that NATting protocol 41 allows EXISTING implementations to keep working.

I gather that there aren't even two different interoperating implementations of TSP. There are dozens, if not hundreds, of millions of devices out there that can do protocol 41 out of the box.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 25 Jan 2013 08:45:23 -0500

> I gather that there aren't even two different interoperating implementations of TSP. There are dozens, if not hundreds, of millions of devices out there that can do protocol 41 out of the box.

maybe, but:
a) not that many have their vendor firmware configurable to do that.
b) even if they do, that is far from the normal end-user can do.
c) only real use case is the geek who is running openwrt/dd/... or knows enough to configure a proto 41 tunnel.

So at the end, the c) use case is able to use TSP, which requires no modification to the CGNs.

Moreover, long reach tunnels do not provide a best experience. With happy eyeballs being deployed, the v6 side will always loose. Short range tunnels are good, especially when the tunnel concentrator is in your upstream provider network. Then it makes more sense: deployments of these have been done using 6to4pmt, 6rd, TSP or else.  In this context, since it is a service provided by the ISP, then it can locate the tunnel concentrator in the non-cgn part of the network.

I fail to see a good use case for your proposal, except for some real geek corner cases.

Marc.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 26 Jan 2013 01:09:07 +1100

In message <[email-masked]>, Iljitsch van Beijn
um writes:
> I find it annoying that pretty much all comments miss the point that NATting 
> protocol 41 allows EXISTING implementations to keep working.

I'm curious.  Say you have two tunnels both going to the same router.
How does the NAT learn which IPv6 prefixes are associated with which
internal addresses.  Remember these tunnels are often up for months
at a time with both external and internally initiated traffic?

Today I re-establish my HE tunnel whenever the DHCP lease updates
the IPv4 address.  There is a /128 and a /64 associated with that
tunnel.  I have both externally and internally initiated traffic.
The tunnel re-establishment is done over https.  I can use "auto"
for my local IPv4 address and the tunnel broker will look at the
IPv4 address of the https session to fill in my IPv4 address.

So for this to work the NAT would need to detect the https session
and the force protocol 41 traffic to use the same IPv4 address.  If
there was another internal machine talking to the same tunnel broker
it would also need to learn the prefixes associated with each tunnel.
Now I suppose the NAT could have a list of tunnel broker addresses
and ensure that no internal machines used the same external address
when talking to a particular tunnel broker but it would be fragile
to the extreme.

This is just one use of protocol 41.

The simplest thing is to look to see who is using protocol 41 and
just not put them behind a CGN or wire down the internal/external
address mappings for these customers similar to a DMZ host.  Other
clients can still share the address but all protocol 41 traffic
goes to internal client with the fixed mapping.

> I gather that there aren't even two different interoperating implementations 
> of TSP. There are dozens, if not hundreds, of millions of devices out there t
> hat can do protocol 41 out of the box.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 26 Jan 2013 01:21:29 +1100

In message <[email-masked]>, Marc Blanchet wr
ites:
> 
> Le 2013-01-25 =E0 08:25, Iljitsch van Beijnum a =E9crit :
> 
> > On 14 jan 2013, at 18:22, Simon Perreault <[email-masked]> w=
> rote:
> > =
> 
> > =
> > =
> > I find it annoying that pretty much all comments miss the point that NATt=
> ing protocol 41 allows EXISTING implementations to keep working.
> > =
> 
> > I gather that there aren't even two different interoperating implementati=
> ons of TSP. There are dozens, if not hundreds, of millions of devices out t=
> here that can do protocol 41 out of the box.
> 
> maybe, but:
> c) only real use case is the geek who is running openwrt/dd/... or knows en=
> ough to configure a proto 41 tunnel.
> 
> So at the end, the c) use case is able to use TSP, which requires no modifi=
> cation to the CGNs.
> 
> Moreover, long reach tunnels do not provide a best experience. With happy e=
> yeballs being deployed, the v6 side will always loose.

This statement is demonstatably false.  I have a long range tunnel
(Sydney/Palo Alto).  63% of my external traffic is IPv6 and goes
over it even *with* happy eyeballs in play.  There is not significant
difference between IPv4 and IPv6 when talking to the US, Europe or
any IPv4 destination that I would normally route to via the US for
me.  My IPv4 path to the US also goes via Palo Alto.

This is not to say tunnel end point selection is not important or
I wouldn't prefer a more local one.

> Short range tunnels =
> are good, especially when the tunnel concentrator is in your upstream provi=
> der network. Then it makes more sense: deployments of these have been done =
> using 6to4pmt, 6rd, TSP or else.  In this context, since it is a service pr=
> ovided by the ISP, then it can locate the tunnel concentrator in the non-cg=
> n part of the network.
> 
> I fail to see a good use case for your proposal, except for some real geek =
> corner cases.
> 
> Marc.
>

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 25 Jan 2013 10:10:33 -0500

Le 2013-01-25 à 09:21, Mark Andrews a écrit :

> This statement is demonstatably false.

well… I would rephrase my statement as: depending on your trafic pattern and the v4/v6 topology differences between the two tunnels endpoints.

Marc.

>  I have a long range tunnel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Jan 2013 17:47:44 +0100

> at a time with both external and internally initiated traffic?

By looking at the IPv6 source addresses in the inner IPv6 header and creating state based on those. Then when packets arrive from the outside, get the destination IPv6 address from the inner IPv6 header, and determine the IPv4 address to translate to from the NAT table.

Ideally, this would be a dynamic longest match first, so a single address can set up a mapping for an entire /48 or /56 until a different host uses an address in a different /64 but in the same /48 or /56.

Doing this all the way up to /128 is more robust against spoofing attacks, but less robust against NAT state exhaustion attacks.

> and the force protocol 41 traffic to use the same IPv4 address.

No, that doesn't work. The issue with protocol 41 is that it has no port numbers, so without looking inside the inner IPv6 header, there's nothing to demultiplex packets towards different users behind the same NAT.

A different solution would be an extra encapsulation that is used between the tunnel broker and the CGN.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 26 Jan 2013 10:58:54 +1100

In message <[email-masked]>, Iljitsch van Beijn
um writes:
> By looking at the IPv6 source addresses in the inner IPv6 header and creating
> state based on those. Then when packets arrive from the outside, get the des
> tination IPv6 address from the inner IPv6 header, and determine the IPv4 addr
> ess to translate to from the NAT table.
> 
> Ideally, this would be a dynamic longest match first, so a single address can
> set up a mapping for an entire /48 or /56 until a different host uses an add
> ress in a different /64 but in the same /48 or /56.

Which will result in packets being sent to the wrong internal machine.
 
> Doing this all the way up to /128 is more robust against spoofing attacks, bu
> t less robust against NAT state exhaustion attacks.
> 
> No, that doesn't work. The issue with protocol 41 is that it has no port numb
> ers, so without looking inside the inner IPv6 header, there's nothing to demu
> ltiplex packets towards different users behind the same NAT.

And I'm showing you how protocol 41 tunnels are established today.
You are the one claiming that this will work with existing setups.
Today the https source address and the protocol 41 source address
are constrained to be the same address 99.99% of the time as the
customer has a single IPv4 address. This relationship is used by
the tunnel establishment process.

With CGN there is no such required relationship.  Additionally the
relationship can change without the endpoints being aware of the
change.

Tunnels are not transient connections.  They are long term connections
and cause all the sorts of issues that long running TCP sessions
have with NATs.

-- 
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 29 Jan 2013 11:55:03 +0100

> Which will result in packets being sent to the wrong internal machine.

Unreliable datagram service. All part of the game.

Misdelivery of a few random packets that aren't part of two-way communication can happen, yes.

> And I'm showing you how protocol 41 tunnels are established today.

I've never done it that way, but if you say so.

That doesn't change the fact that there are no port numbers in protocol 41 so HTTPS activity can't create the actual CGNAT mappings.

> You are the one claiming that this will work with existing setups.

Yes.

> the tunnel establishment process.

Right. Except with CGNAT the IPv4 address that is "used by the tunnel establishment process" is the CGNAT's external IPv4 address. So as before, the tunnel broker knows where to send its protocol 41 encapsulated packets.

The question is what happens once the packets arrive at the CGNAT. If the CGNAT takes a look at the IPv6 addresses embedded in the inner IPv6 header, then the CGNAT can NAT the packets, and of course all the limitations of NAT apply, except that the inner IPv6 addresses are (presumably) globally unique, unlike port numbers.