Subject: Re: [BEHAVE] IPv6 NAT: implementer perspectives

From: Dave Thaler <[email-masked]>
Date: Tue, 2 Dec 2008 17:53:08 -0800

Catching up on email after the holiday here in the US...

Ran Atkinson wrote:
> In practice, I think most IPv6 host implementations at least
> have implemented support for "IPv6 Privacy Addresses".
>
> I do not clearly understand what the default setting might be
> for that feature (i.e. enabled or not) in various implementations.

I can answer for one implementation:

Privacy Addresses are supported on all versions of Windows that support
IPv6.  They're on by default on all client versions (XP, Vista,
Windows 7) and off by default on all server versions (2003, 2008,
Windows 7 Server).

Note that privacy addresses as specified in RFC 3041 do not completely
prevent host counting.  This is because the defaults in 3041 are to
use what I'll call an "address of the day" for outgoing connections.
But there's still just one "address of the day" used for new outgoing
connections.  So if you count the number of source addresses of SYN's
during a given day, that's a pretty good approximation of the number
of active hosts.

>> In an attempt to unravel or terminology in this case and around the
>> topology hiding/node correlation discussion, I've started a taxonomy
>> and terminology document that I'll post soon.  Hopefully we can all
>> agree on the terms, which should let us have a better discussion of
>> the trade-offs of different approaches.
>
> That seems likely to help focus discussion.
>
> I'd urge that the document distinguish "topology hiding" from
> "able to count the hosts behind the NAT", as the former does not
> imply the latter AND the latter seems challenging to truly achieve
> (e.g. see URL from an earlier note today).

+1

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 05 Dec 2008 18:34:32 -0500

Hi Margaret/Ran/All,

Margaret Wasserman wrote:
> I was on the fence, but your post has convinced me that attempting a 
> checksum neutral translation (while a neat trick, in some sense) is not 
> all that useful.  There are actually two more useful things we could 
> spend our time doing:
> 
> (1) Agreeing on a format for any future IPv6 extension headers so that 
> they can be skipped without knowing what they are.  I think this work is 
> already underway in 6man, and we should support it.

This work is kind of stalled in 6man for the lack of support to take it 
forward. I would appreciate it if you take a look at

http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-06

and send in your comments and/or support to the 6man mailing list.

Cheers
Suresh

---

From: Peter Dambier <[email-masked]>
Date: Sat, 06 Dec 2008 01:20:38 +0100

I hope it is ok to include NAT66.

Thank you Suresh for pointing us to

I would very much like to have an extension header for NAT66.

That would allow symmetric NAT66 to automatically undo what
a NAT66 has done.

Outside the NATted area addresses would be orignal and everything
would work as expected.

Inside the NATted area applications would be warned by the
unknown extension header and older applications would break
preventing harm.

The extension header for NAT66 might include the original address
pair and the original checksum.

Downside

MTU reduced for packets sent through the NATted area.

Upside

Original header restored. No address or port bits lost.

Kind regards
Peter

Suresh Krishnan wrote:
>> checksum neutral translation (while a neat trick, in some sense) is
>> not all that useful.  There are actually two more useful things we
>> could spend our time doing:
>>
>> they can be skipped without knowing what they are.  I think this work
>> is already underway in 6man, and we should support it.
> 

- --
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 20:15:55 -0500

> That would allow symmetric NAT66 to automatically undo what

If you're going to incur per-packet overhead for the sake of reversing
the address translation, why not just tunnel?

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 20:43:36 -0500

Peter Dambier wrote:
> Hello Keith,
> 
> the NAT66 I might get from my ISP is almost native IPv6.
> 
> The tunnel I might get from a tunnel broker means a loss
> of speed and yet another dependence on somebody else.

why would your ISP impose a NAT on v6 traffic anyway?

Keith

---

From: Peter Dambier <[email-masked]>
Date: Sat, 06 Dec 2008 02:42:24 +0100

Hello Keith,

Of course an IPv6 port of TOR would be a good idea.
Maybe I should talk to the TOR people.
But I am afraid that is not the tunnel you meant.

Connecting customers via aDSL and PPPoE my ISP does already
put me through a tunnel and he does already take some bytes
away.

I dont want a NAT in the first place but I prefer a NAT66
that can be undone by a symmetric NAT66 to an opaque one.

Kind regards
Peter

- --
Peter and Karin Dambier

---

From: Peter Dambier <[email-masked]>
Date: Sat, 06 Dec 2008 03:20:31 +0100

> why would your ISP impose a NAT on v6 traffic anyway?

Right now they dont sell IPv6 to their customers at all.

They (dtag.de) keep telling me infrastructure is not
ready yet. Customer equipment is not ready yet and after
all there is no NAT66 yet and no firewall.

Without NAT66 they cannot route because IPv6 addresse dont
aggregate and all those many tunnels keep address tables
exploding.

On the other hand if we can build a little something that
can replace your existing NAT44 router and allows you to
6to4 through your dynamic IPv4 address but keeping your
ULA or PI intact, that little something might be called
NAT66 and two of them might be called symmetric NAT66.

If there is a draft to follow, the linux IPv6 guys and
and the BSD guys will implement it. It will finally
find its way into those little boxes that do connect
you to the IPv4 internet today.

Kind regards
Peter

- --
Peter and Karin Dambier

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Dec 2008 13:48:16 +1100

In message <[email-masked]>, Peter Dambier writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Keith Moore wrote:
> > Peter Dambier wrote:
> >> Hello Keith,
> >>
> ready yet.

	Read: we stuffed around for years despite being told IPv6
	is coming and failed to request IPv6 support from our vendors
	in time to be ready when our customers requested it.

> Customer equipment is not ready yet and after

	Read: we havn't done our home work and we are going to b@3$t
	you by stating there is no CPE equipement or firewalls.  In
	addition to that we are going to add some more b@#$t about
	NAT being required.
 
> aggregate and all those many tunnels keep address tables

	Which the other ISP's who supply IPv6 to their customers
	can just do without requiring NAT66.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFJOeFtoQA0qetcyygRApXrAJ9pOIAWP52kuUoVZhh+UVtmYZE4ggCfYyk7
> cfAbWsZKHNPuD4S6WoGoOk0=
> =Ep69
> -----END PGP SIGNATURE-----
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 21:49:40 -0500

> you to the IPv4 internet today.

that is the most bizarre thing I've ever read on an IETF list in 18 years.

Keith

---

From: "Eric Klein" <[email-masked]>
Date: Sat, 6 Dec 2008 09:15:11 +0200

>        in time to be ready when our customers requested it.

Actually I think this should read "we didn't bother to upgrade our routers
yet, and now can not afford to as we don't know if we will have jobs at the
end of the year.

>        addition to that we are going to add some more b@#$t about

Seems that they never heard of Windows XP and prove the point of this
mailing list that people assume that what worked in v4 (i.e. NAT) should be
done the same in v6. Also I am not sure about the firewalls, I know that
Checkpoint was working on this 2 years ago but don't know what progress they
made.

>        can just do without requiring NAT66.

This was actually the only argument that is close to legitimate, as the
routing tables will get larger - maybe if they used some of the user fees to
upgrade the hardware (more memory?) they would be able to handle this, as
there are many routers out there for the past few years that can handle this
problem.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Sat, 06 Dec 2008 09:54:06 +0100

Hi Suresh.

The ability to skip unknown extension headers is IMO extremely important.
Lack of it can almost be seen as a bug in the original IPv6 design.

Please forward this message to the 6man mailing list.

Cheers,
RD

Please forward this

Suresh Krishnan  -  le (m/j/a) 12/6/08 12:34 AM:
>> (1) Agreeing on a format for any future IPv6 extension headers so 
>> that they can be skipped without knowing what they are.  I think this 
>> work is already underway in 6man, and we should support it.
>
> This work is kind of stalled in 6man for the lack of support to take 
> it forward. I would appreciate it if you take a look at
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 7 Dec 2008 17:41:15 -0500

Hi Peter,

There are serious security issues with the idea of having a host on  
the receiving end "automatically undo" something that will give the  
impression that a packet was actually received from a different  
address.  For example, an external source address could be used to  
pass ingress filtering rules at a border router, and then the address  
could be switched "back" to an address that appears to have originated  
locally.  This could be used as the basis for an attack.  The "TRIP"  
proposal I circulated had the same problem...  There are potential  
solutions to this problem, such as having the addresses  
cryptographically generated, but they would have to be spelled out in  
detail for any proposal along these lines to be secure.

Also, how is the receiving host supposed to send traffic back to the  
source?  Which address would it use?

I don't think I understand how your proposal would work, unless both  
the internal and external addresses are globally routed addresses.  If  
that is the case, what benefit is gained from having two sets of  
addresses?  Even if you did globally route both sets of addresses, I  
am still having some conclusion about what addresses will be seen by  
the transport layer (and apps) on both ends.

Could you perhaps write an Internet-Draft describing your proposal, so  
that we can discuss it in detail?  It should include an explanation of  
how a client gets the IP address(es) for a remote host, how it  
initiates a connection, how the remote host responds, what addresses  
the transport layers will see on both ends, how the local host's  
transport layer associates the response with the connection it  
initiated, etc.

Also, could you explain which of the benefits of IPv4 NAT are  
preserved in your solution?

Thanks,
Margaret

On Dec 5, 2008, at 8:42 PM, Peter Dambier wrote:

> iD8DBQFJOdh+oQA0qetcyygRAuqwAJ4jh5HvZSckODCPyitXF7Qpfg9pcgCfZAep
> frNw0I4d0ZVzvL1gJh6sIrw=
> =hW7V

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 7 Dec 2008 17:47:30 -0500

Hi Peter,

> aggregate and all those many tunnels keep address tables

This doesn't make any sense to me.  Why don't IPv6 addresses  
aggregate?  AFAIK, they aggregate the same way that IPv4 addresses do.

There are known issues with certain technologies (like using inter-ISP  
tunnels for site multihoming) and route aggregation, but it is my  
understanding that those problems exist in both IPv4 and IPv6.  Is you  
ISP describing an IPv6-specific problem?
> NAT66 and two of them might be called symmetric NAT66.

It is my understanding that the term "symmetric NAT" is already in use  
to describe something different from what you are describing, so you  
might consider a different term to avoid ambiguity.

It is _exactly_ the point of NAT66 that a customer can use his ULA or  
PI address internally and his ISP-provided, aggregated address  
externally.  I am not sure, though how the rest of your solution  
relates.  Without a global mapping service of some type, it would not  
be useful for my ULA or non-globally-routed PI addresses to get to  
your site, because you couldn't send a packet back to those addresses.
> you to the IPv4 internet today.

Sadly (or perhaps fortunately :-)), it doesn't always follow that the  
open source guys implement whatever we write.  Hopefully we can have  
some influence in this case, however.

Margaret

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 8 Dec 2008 09:53:41 +0200

> Lack of it can almost be seen as a bug in the original IPv6 design.

But the real question is, why would we need a sixth extension header type?
Any new extension should fit within either Destination or Hop-by-hop header. 
And they can both be skipped, by design.

Besides, it's simply too late. Millions of devices have been shipped with a 
(dormant) IPv6 stack, and they're not going to be upgraded anytime soon. How 
useful is a new header if it's not backward compatible?

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

---

From: Peter Dambier <[email-masked]>
Date: Mon, 08 Dec 2008 10:47:22 +0100

Hello Rémi,

I am just working on something like reversible NAT66 that depends on two
NAT66 devices and their ability to remember original addresses and checksums.

That header would normally be seen only by these devices so not much harm
would be done. IPv6 ist still alive. That header could slowly migrate into
the source code and it would be there when somebody else needs it.

I shall have a look into the hop-by-hop header nevertheless.

Kind regards
Peter

- --
Peter and Karin Dambier

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 8 Dec 2008 07:51:42 -0500

Hi Peter,

On Dec 8, 2008, at 4:47 AM, Peter Dambier wrote:

> would be done.

The problem is that there is no header that will only be seen by  
certain devices.  If you use a new header type (rather than a hop-by- 
hop or end-to-end option), all hosts that receive a packet containing  
that header (whether they care about it or not) will need to recognize  
the header so that they can skip it and get to the transport layer  
header.

If you use a hop-by-hop option, every router will parse the header,  
but there is enough information available to skip the header, and you  
can indicate that it should be ignored by routers that do not  
recognize it.

However, I think that all of this discussion is about details, and I  
think that there are more fundamental problems with what you have  
proposed.

Margaret

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 08 Dec 2008 19:07:17 -0500

Hi Remi,

> And they can both be skipped, by design.

On an intermediate node, it is easier to find information in an 
extension header rather than in a hop-by-hop option.

> useful is a new header if it's not backward compatible?

The earlier versions of this document specified a backward compatible 
format, but this required redefining the fragment header. So that did 
not fly

Thanks
Suresh

---

From: Peter Dambier <[email-masked]>
Date: Tue, 09 Dec 2008 10:45:07 +0100

Thank you Margaret,

it needs another week of thinking.

Hop-by-hop should do. There is no more need for a new heder.

The rest involves so much tunnel digging that I should
consult the tunnel-diggers first. Fred has shown me where
to look. Thank you Fred.

Kind regards
Peter

Margaret Wasserman wrote:
> The problem is that there is no header that will only be seen by certain
> devices.  If you use a new header type (rather than a hop-by-hop or
> end-to-end option), all hosts that receive a packet containing that
> header (whether they care about it or not) will need to recognize the
> header so that they can skip it and get to the transport layer header.
> 
> If you use a hop-by-hop option, every router will parse the header, but
> there is enough information available to skip the header, and you can
> indicate that it should be ignored by routers that do not recognize it.
> 
> think that there are more fundamental problems with what you have proposed.
> 
> Margaret
> 
> 

- --
Peter and Karin Dambier