NAT66 : A first implementation

NAT66 : A first implementation

[Terry Moës]

Hi all !

Since the Draft of NPT66 (Stateless Mapping) has gone RFC 
(http://tools.ietf.org/html/rfc6296), it's the good time for me to 
publish my master thesis : an implementation, for Netfilter, of NAT in 
IPv6, with both Stateless and Stateful approaches.

It's published on Sourceforge : https://sourceforge.net/projects/nfnat66/

You will find 5 items in here :
- The PDF of my thesis, which explains some choices, if wanted;
- The slides shown on the presentation of my thesis, which contain some 
extra-information with respect to the report;
- Two extensions for ip6tables (SNAT and DNAT);
- Three kernel files that have been edited for the purpose of the 
implementation;
- The two modules that have been created.

Moreover, my thesis gives a deep explanation of NAT44 implementation, 
and can thus be referenced anywhere needed.

The whole development of NAT66 is inspired from what was done for NAT44.

There is still a lot of work to do, and there is probably some bugs in 
the modules (despite many tests in lab), thus any help is welcome!

A first step would be to patch the next version of the kernel with the 
three modified files, so that any further development is greatly 
facilitated! And since it's a thing I've never done, any advise is not 
unnecessary :)

Don't hesitate if you have any question.

Greetings,
Terry

--
Terry Moës (20061420)
Université de Liège - Faculté des Sciences Appliquées
2ème année Master Ingénieur Civil en Informatique - Délégué
Représentant Etudiant - Conseil de Faculté
FFSA Administrateur - http://www.ffsa.be
T.Moes@student.ulg.ac.be

-- 

N-HiTec - Nova High Technology Engineering and Consulting

Responsable des Infrastructures - Vice-Président

Web :   http://www.nhitec.com
Tél :   04/366.20.01

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Jan Engelhardt]

On Thursday 2011-07-14 17:47, Terry Moës wrote:

> Hi all !
>
> Since the Draft of NPT66 (Stateless Mapping) has gone RFC
> (http://tools.ietf.org/html/rfc6296), it's the good time for me to publish my
> master thesis : an implementation, for Netfilter, of NAT in IPv6, with both
> Stateless and Stateful approaches.
>
> It's published on Sourceforge : https://sourceforge.net/projects/nfnat66/

Hm, how often has this been (re)implemented now... the last one was 
sf.net/projects/map66
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Terry Moës]

If you are willing to compare this implementation, which just add two 
targets to Xtables, with mine, which involves the Connection Tracking, 
and is able to deal with icmp error messages, AND implements stateful, 
n:1 mapping, yes, ok, I've done nothing.

Have you at least taken a look at this work, before saying I've 
implemented nothing but something already implemented ?

On 14/07/11 18:22, Jan Engelhardt wrote:
> On Thursday 2011-07-14 17:47, Terry Moës wrote:
>
>> Hi all !
>>
>> Since the Draft of NPT66 (Stateless Mapping) has gone RFC
>> (http://tools.ietf.org/html/rfc6296), it's the good time for me to publish my
>> master thesis : an implementation, for Netfilter, of NAT in IPv6, with both
>> Stateless and Stateful approaches.
>>
>> It's published on Sourceforge : https://sourceforge.net/projects/nfnat66/
> Hm, how often has this been (re)implemented now... the last one was
> sf.net/projects/map66

--
Terry Moës (20061420)
Université de Liège - Faculté des Sciences Appliquées
2ème année Master Ingénieur Civil en Informatique - Délégué
Représentant Etudiant - Conseil de Faculté
FFSA Administrateur - http://www.ffsa.be
T.Moes@student.ulg.ac.be

-- 

N-HiTec - Nova High Technology Engineering and Consulting

Responsable des Infrastructures - Vice-Président

Web :   http://www.nhitec.com
Tél :   04/366.20.01

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Jan Engelhardt]

On Thursday 2011-07-14 18:27, Terry Moës wrote:

>>>Hi all !
>>>
>>>Since the Draft of NPT66 (Stateless Mapping) has gone RFC 
>>>(http://tools.ietf.org/html/rfc6296), it's the good time for me to 
>>>publish my master thesis : an implementation, for Netfilter, of NAT 
>>>in IPv6, with both Stateless and Stateful approaches.
>>>
>>>It's published on Sourceforge : 
>>>https://sourceforge.net/projects/nfnat66/
>>
>>Hm, how often has this been (re)implemented now... the last one was 
>>sf.net/projects/map66
>
>If you are willing to compare this implementation, which just add two 
>targets to Xtables, with mine, which involves the Connection Tracking, 
>and is able to deal with icmp error messages, AND implements stateful, 
>n:1 mapping

Of course yours is feature-richer. But the topic of IPv6 NAT has had 
come up a number of unrecollectable times, and the response has been the 
same everytime - NAT is still an ugly undesired hack whose recurrence 
wants to be avoided.

As such, anything revolving around that topic is closely eyed and 
dismantled. (The Linux camp generally being one that likes to DTRT and 
cook their ideas through, at least more than some 
purely-commercially-oriented huts.)


As for the thesis paper:

- At times, the document reads like a speech, owing to certain 
linguistic constructs such as enumerations, relatively short sentences 
("election campaingn" style), and a somewhat abundant use of exclamation 
marks.


>This feature [NAT] is very common in IPv4 networks today - it made the 
>delay of the X-Day possible - and will surely have its applications in 
>IPv6 networks.

Possible yes, however, delaying of the x-day was surely not one of its 
design goals. As such, the delay seems more like a side-effect at 
first — and then when it became apparent that address space runs out 
"soon", NAT became a constant abuse.


>The NAT general principle is the modification of the addresses 
>information of IP packets in order to isolate all the network [...] 
>Security. The NAT Device often blocks packets unassociated to any 
>existing flow [...] this “application” is more a side-effect

NAT is not a security device, even if a particular implementation with a 
particular configuration _may_ drop packets. A different implementation 
may even allow them by default — think certain router models with 
clearly labeled "DMZ" ports, and a user plugging stuff in without 
thinking.

Side-effect is too soft. Calling NAT a security device comes like 
premeditated deception of end-users.



>Multi-Homing. One network can be a client of several ISPs in order to 
>ensure redundancy or in order to reduce costs. These different ISPs 
>will assign the client different prefixes. However, it can be desired 
>that the client does not have to modify the topology of his subnet each 
>time he switches from one ISP to another.

When switching the provider, consider:

- If ISP2 blocks packets with source address SRC1, you are busted. NAT 
won't fix your problem:

- reason 1: NAT is applied per CT and does not automatically change 
while a CT exists.

- reason 2: Even if it did, packets of your connection would suddenly 
have SRC2, and the remote side would reject it with TCP RST, because it 
only knows a connection with SRC1.

- If ISP2 does accept packets from SRC1 (last time I checked, HE.net and 
SIXXS.net did that), you don't need NAT either.

These issues are known today already because they also apply to v4-NAT. 
The more so because in the providers' little IPv4 space, in practice 
ISPn almost always block sources claiming not to come from ISP2's space.


>the main reason for using NAT in IPv4 was the ability to connect 
>several hosts of an internal network to an external network, using less 
>public IP Addresses than needed

There is a difference between needed address and available addresses. If 
people did not need so many, they could fit all their hosts in the 
available address space instead - and would not need NAT.


>But, if there were only routing tables, there would be a problem with 
>prefixes: both ISPs would impose their prefixes, and the network inside 
>the company cannot have several prefixes.

There is no reason that hosts inside a network are limited to a single 
address. There:

ip addr add 2001:db8:1::1/64 dev dummy0
ip addr add 2001:db8:2::1/64 dev dummy0

In fact, each IPv6 hosts usually already has more than one address - and 
one of them is the fe80::/ link-scope prefix. So they are generally 
already multi-homed once one has added a unicast address to an 
interface.


>Fast execution NAT in IPv4 is slowed because the NAT device has to 
>recompute the checksums every time a packet goes through; we want to 
>circumvent this limitation.

You need to recompute them anyway when doing L7 substitution.


>An entity that is 128 bits long is never atomic

A 128-bit entity can very well be atomic if the programming language 
implementation decides to make it so. Just because yours does not do it 
currently does not mean it will never be.


>And whatever is the type of the variable defined, the representation in 
>memory will remain the same.

This statement seems incorrect. One type's representation may be a trap 
representation for another type. Again, just because that is not the 
case in contemporary implementations does not mean it is not possible.


>routers cannot fragment a packet on their own anymore, and cannot 
>reassemble fragments either.

While I can agree with this statement, be aware that "routers" running 
nf_conntrack will undoubtedly reassemble in all cases, save perhaps for 
packets delievered to raw sockets due to the order of raw-socket 
delivery and nf_defrag. Subsequently,


>We will thus have to be aware that some packets arriving have NO Layer 
>4 information while NAT is still working.

is not satisfied. nf_conntrack (required by nf_nat) forces reassembly of 
packets exactly because the L4 header is part of the tracking tuple.


>int i; // A loop counter

	“A loop counter!? Nobody would have expected _that_!”


>This negotiation happens in a ASCII format data flow and not in a 
>binary format. Therefore, the change of the connection information in 
>the ASCII format may change the length of the packet after the NAT 
>manipulation.

Note however that binary encodings can also exist as variable-length. So 
binary is not the magic scepter. Think of UTF-8.


So far my active readthrough..
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[David Miller]

From: Jan Engelhardt <jengelh@medozas.de>
Date: Fri, 15 Jul 2011 01:15:47 +0200 (CEST)

> Of course yours is feature-richer. But the topic of IPv6 NAT has had 
> come up a number of unrecollectable times, and the response has been the 
> same everytime - NAT is still an ugly undesired hack whose recurrence 
> wants to be avoided.

You can't avoid it.

People want to hide the details of the topology of their
internal networks, therefore we will have NAT with ipv6
no matter what we think or feel.

Everyone needs to stop being in denial, now.

Re: NAT66 : A first implementation

[Rick Jones]

On 07/14/2011 04:17 PM, David Miller wrote:
> From: Jan Engelhardt<jengelh@medozas.de>
> Date: Fri, 15 Jul 2011 01:15:47 +0200 (CEST)
>
>> Of course yours is feature-richer. But the topic of IPv6 NAT has had
>> come up a number of unrecollectable times, and the response has been the
>> same everytime - NAT is still an ugly undesired hack whose recurrence
>> wants to be avoided.
>
> You can't avoid it.
>
> People want to hide the details of the topology of their
> internal networks, therefore we will have NAT with ipv6
> no matter what we think or feel.
>
> Everyone needs to stop being in denial, now.

So, does that imply there will be systems with only link-scope IP's 
reaching-out to global-scope IPs, getting their link-scope's adjusted by 
an IPv6 NAT?

rick jones

Re: NAT66 : A first implementation

[Rick Jones]

On 07/14/2011 04:37 PM, Rick Jones wrote:
> On 07/14/2011 04:17 PM, David Miller wrote:
>> Everyone needs to stop being in denial, now.
>
> So, does that imply there will be systems with only link-scope IP's
> reaching-out to global-scope IPs, getting their link-scope's adjusted by
> an IPv6 NAT?

The reason I ask is that getaddrinfo() in various places is being 
tweaked to not perform v6 lookups if only link-scope IPs are assigned to 
the system...

rick jones

Re: NAT66 : A first implementation

[Jan Engelhardt]

On Friday 2011-07-15 01:17, David Miller wrote:

>From: Jan Engelhardt <jengelh@medozas.de>
>Date: Fri, 15 Jul 2011 01:15:47 +0200 (CEST)
>
>> Of course yours is feature-richer. But the topic of IPv6 NAT has had 
>> come up a number of unrecollectable times, and the response has been the 
>> same everytime - NAT is still an ugly undesired hack whose recurrence 
>> wants to be avoided.
>
>People want to hide the details of the topology of their
>internal networks,

And IPv6 Privacy w.r.t. random address selection, combined with a 
firewall, won't do that?

Re: NAT66 : A first implementation

[Krzysztof Olędzki]

On 2011-07-15 01:55, Jan Engelhardt wrote:
> On Friday 2011-07-15 01:17, David Miller wrote:
>
>> From: Jan Engelhardt<jengelh@medozas.de>
>> Date: Fri, 15 Jul 2011 01:15:47 +0200 (CEST)
>>
>>> Of course yours is feature-richer. But the topic of IPv6 NAT has had
>>> come up a number of unrecollectable times, and the response has been the
>>> same everytime - NAT is still an ugly undesired hack whose recurrence
>>> wants to be avoided.
>>
>> People want to hide the details of the topology of their
>> internal networks,
>
> And IPv6 Privacy w.r.t. random address selection, combined with a
> firewall, won't do that?

Be rational.

How would you imagine managing and maintaining a typical corporate 
network (1K+ devices) of different devices and operating systems - 
workstations (Windows, Mac, Linux), servers (Windows, Linux, BSD) 
routers, switches (radius), firewalls, APs, etc; without static IP 
addresses? Static = not random.

Also, how would you imagine readressing such network one day, when you 
decide to change your ISP?

Without NAT (and BTW without working and complete L3 security in 
switches) no one will consider IPv6 seriously nor dare to implement it 
in production. Of course NAT does not provide security but it provides a 
real and useful privacy, opposite to annoying randomness.

Best regards,

				Krzysztof Olędzki
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Ed W]

Hi

> How would you imagine managing and maintaining a typical corporate
> network (1K+ devices) of different devices and operating systems -
> workstations (Windows, Mac, Linux), servers (Windows, Linux, BSD)
> routers, switches (radius), firewalls, APs, etc; without static IP
> addresses? Static = not random.

I agree.  Can't see how you would (unless dynamic DNS started to work a
whole lot better than today...)


> Also, how would you imagine readressing such network one day, when you
> decide to change your ISP?

Aha.  This is a statement that you don't believe PI space will become
easier to access when requesting IPV6 space?

There seems to be sufficient space for PI to become the norm to hand
out.  However, the current state of routing appears to struggle with
IPV4 taken to the limit, and so there seems to be understandable
reluctance to actually fix all the issues we have with IPV4 since some
facets of the solution kill current routing hardware..?

Mobile phone numbers are now interchangeable between phone companies in
under 24 hours in the UK.  Lets hope that PI space allocations become
the norm under IPv6..?


> Without NAT (and BTW without working and complete L3 security in
> switches) no one will consider IPv6 seriously nor dare to implement it
> in production. Of course NAT does not provide security but it provides a
> real and useful privacy, opposite to annoying randomness.

It's not clear to me that NAT solves L3 security any better than a
non-nat firewall?  "Security" through NAT is largely through breaking
routing, but a non NAT firewall appears to achieve entirely the same
effect more directly (some would argue much better in fact)


I personally think that IPV6 NAT could be very useful for a number of
niche situations!  Please lets see this get implemented!

On the other hand I hope that widespread adoption doesn't happen...
Instead I hope that PI allocations become straightforward and the norm.
I would also disagree with some of the reasons *why* you want NAT,
although at the limit I would still agree NAT is useful for some
situations (just different situations)

Cheers

Ed W

Re: NAT66 : A first implementation

[Krzysztof Olędzki]

On 2011-07-18 00:23, Ed W wrote:
> Hi
Hi,


>> Also, how would you imagine readressing such network one day, when you
>> decide to change your ISP?
>
> Aha.  This is a statement that you don't believe PI space will become
> easier to access when requesting IPV6 space?

IPv6 PI for everyone? Forget about it, we would shortly hit 1M or even 
10M+ IPv6 prefixes and this way make BGP unreliable.

> There seems to be sufficient space for PI to become the norm to hand
> out.  However, the current state of routing appears to struggle with
> IPV4 taken to the limit, and so there seems to be understandable
> reluctance to actually fix all the issues we have with IPV4 since some
> facets of the solution kill current routing hardware..?
>
> Mobile phone numbers are now interchangeable between phone companies in
> under 24 hours in the UK.  Lets hope that PI space allocations become
> the norm under IPv6..?

You must not compare PSTN with IP this way. How many GSM operators are 
there in UK with own network prefix? 50? 100? Now: compare it to BGP 
AS'es. How long you need to wait to initiate a call. Finally, how many 
calls do you make per second? ;)

BTW: phone numbers are interchangeable not only in UK and not only 
mobile. ;)

>> Without NAT (and BTW without working and complete L3 security in
>> switches) no one will consider IPv6 seriously nor dare to implement it
>> in production. Of course NAT does not provide security but it provides a
>> real and useful privacy, opposite to annoying randomness.
>
> It's not clear to me that NAT solves L3 security any better than a
> non-nat firewall?

Sorry, english is not my native language, maybe I was not clear enough. 
By L3 security in switches I meant:

  - DHCPv6-snooping, like dhcp-snooping in IPv4, which protects your 
network from unauthorized dhcp-servers. Just think of someone enabling 
connection sharing in windows, grrr!

  - ND-protect, like arp-protect in IPv4 - there is no ARP for IPv6

  - "ipv6 source-lockdown", like "ip source-lockdown" [1]) to protect 
from arp/ip spoofings/takeovers.

Such mechanisms are standard for enterprise and nowadays even soho edge 
switches, but only for IPv4.

However, as IPv6 is totally different to IPv6, you also need many 
additional mechanisms. For example, several IPv6 stacks are vulnerable 
to RA DoS attack (google: "vulnerable ra ipv6"), and you would like to 
filter unauthorized routers anyway.

But this little offtopic to Netfilter. ;)

[1] HP Procurve terminology.

Best regards,

				Krzysztof Olędzki
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Ed W]

On 18/07/2011 00:54, Krzysztof Olędzki wrote:
>>> Also, how would you imagine readressing such network one day, when you
>>> decide to change your ISP?
>>
>> Aha.  This is a statement that you don't believe PI space will become
>> easier to access when requesting IPV6 space?
> 
> IPv6 PI for everyone? Forget about it, we would shortly hit 1M or even
> 10M+ IPv6 prefixes and this way make BGP unreliable.

Agree entirely, but I think it's clear that were this an option then a
number of issues would disappear?

On a related note, plenty of people are pointing out that there are
enough IPv6 addresses to give every atom an entire IPV4 space. However,
the implementation of IPv6 appears to currently be to give out whacking
great blocks of space on the grounds that giving out small chunks would
lead to an unroutable situation..? Are we just heading for a repeat of
IPV4 exhaustion at some future point?

My understanding of IPv6 is way too limited at present, but it would
*appear* that IPV6 is really a kind of a 64bit address scheme (or
perhaps more like a 64-70bit), given that many of the standards assume
prefixes starting at /64 and getting shorter from there if you are a
larger user?  My ISP (IDNet) gives every customer a /48 for example...
It seems like DHCPv6 is needed to autoassign shorter prefixes than /64
(so I presume that /64 will be the shortest prefix given to soho users
for the time being?)

Seems absolutely baffling that we created a standard for this gigantic
address space and then we are scared to actually use it because it's
unroutable with today's hardware and so instead we hand it out in globs
large enough to make it only a tiny fraction of the size...

Ahh well

Ed W


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: NAT66 : A first implementation

[Jeff Haran]

> -----Original Message-----
> From: netfilter-devel-owner@vger.kernel.org [mailto:netfilter-devel-
> owner@vger.kernel.org] On Behalf Of David Miller
> Sent: Thursday, July 14, 2011 4:17 PM
> To: jengelh@medozas.de
> Cc: T.Moes@student.ulg.ac.be; netfilter-devel@vger.kernel.org
> Subject: Re: NAT66 : A first implementation
> 
> From: Jan Engelhardt <jengelh@medozas.de>
> Date: Fri, 15 Jul 2011 01:15:47 +0200 (CEST)
> 
> > Of course yours is feature-richer. But the topic of IPv6 NAT has had
> > come up a number of unrecollectable times, and the response has been
> the
> > same everytime - NAT is still an ugly undesired hack whose
recurrence
> > wants to be avoided.
> 
> You can't avoid it.
> 
> People want to hide the details of the topology of their
> internal networks, therefore we will have NAT with ipv6
> no matter what we think or feel.
> 
> Everyone needs to stop being in denial, now.

People will use IPv6 NAT if they perceive its benefits outweigh its
costs.

Its costs will be significant. All that connection state tracking will
translate to more hardware. Managing multiple, possibly overlapping,
private network address spaces will mean more administrative headaches.

The benefit, hiding IPv6 address of hosts and routers in internal
networks, is I suspect less tangible. NAT in of itself doesn't provide
enough security to be relied upon solely, so you need firewalls in any
case. And unlike IPv4, you can't argue that you have to use NAT because
of lack of address space.

I think maybe we will get lucky. The bean counters may well keep the
specter of IPv6 NAT at bay. 8^)

Re: NAT66 : A first implementation

[Adam Roach]

On 7/14/11 19:48, Jul 14, Jeff Haran wrote:

> People will use IPv6 NAT if they perceive its benefits outweigh its
> costs.
>
> Its costs will be significant. All that connection state tracking will
> translate to more hardware. Managing multiple, possibly overlapping,
> private network address spaces will mean more administrative headaches.
>
> The benefit, hiding IPv6 address of hosts and routers in internal
> networks, is I suspect less tangible. NAT in of itself doesn't provide
> enough security to be relied upon solely, so you need firewalls in any
> case. And unlike IPv4, you can't argue that you have to use NAT because
> of lack of address space.
>
> I think maybe we will get lucky. The bean counters may well keep the
> specter of IPv6 NAT at bay. 8^)

I haven't had time to look at the thesis or implementation under 
discussion, so I don't know what it does. However, I do want to point 
out that the properties you describe are not necessarily true of all 
IPv6 NAT approaches. If you look at RFC 6296 
(http://tools.ietf.org/html/rfc6296), you'll see that it does not 
require connection state tracking (or, indeed, any state tracking 
whatsoever). It even does some really clever manipulations that prevent 
it from having to recalculate packet checksums.

The handling of NAT between private address spaces -- even overlapping 
private address spaces -- is similarly clever (see section 2.2), and it 
even handles the multihoming case that Jan was insisting doesn't work 
(see section 2.4).

You are correct that NAT and firewalls are very different things, and 
the technique described in RFC 6296 makes this fact abundantly clear. It 
does so by removing the properties most IPv4 NATs have which people 
mistook for security features. It is a great conceptual untangling, 
which should help dispel this common misconception.

In terms of the tangible benefits... I'll defer to language in the RFC 
itself: "[This technique] provides a useful alternative to the 
complexities and costs imposed by multihoming using provider-independent 
addressing and the routing and network management issues of overlaid ISP 
address space." In medium to large enterprises, this can be a 
*substantial* operational cost reduction. Cost savings, coupled with 
stateless translation (== barely more hardware than you need for simple 
routing) start to tip the equation a bit.

So, really, before we do the whole "NATS BAD!" dogpile again, I'd 
encourage people take an unprejudiced look at the technique described in 
RFC 6296. There may actually be a place for NPTv6 in netfilter after all.

/a

RE: NAT66 : A first implementation

[Jeff Haran]

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Thursday, July 14, 2011 7:29 PM
> To: Jeff Haran
> Cc: David Miller; jengelh@medozas.de; T.Moes@student.ulg.ac.be;
netfilter-
> devel@vger.kernel.org
> Subject: Re: NAT66 : A first implementation
> 
...
> So, really, before we do the whole "NATS BAD!" dogpile again, I'd
> encourage people take an unprejudiced look at the technique described
in
> RFC 6296. There may actually be a place for NPTv6 in netfilter after
all.

I was unaware of the RFC. Thanks for the reference, however I have to
point out the following quote from its introduction:

"For reasons discussed in [RFC2993] and Section 5, the IETF does not
recommend the use of Network Address Translation technology for IPv6."

I'm not saying nobody is going to use IPv6 NAT nor that the Linux world
should somehow make it hard on them to do so. There may be a few cases
where it makes sense.

All I am saying is I think most will come to the conclusion that the
benefits they get from it will not compensate for the hassle of dealing
with it. And lacking popularity, many of the hassles will go
unaddressed, further encouraging users to not use it. With IPv4, NAT
quickly became a necessity because of the lack of address space. If your
application or device broke IPv4 NAT, you had a lot of incentive to
change it so it worked with NAT. I think it is unlikely that the same
incentives will come into play with any form of IPv6 NAT.

Re: NAT66 : A first implementation

[Adam Roach]

On 7/15/11 17:12, Jul 15, Jeff Haran wrote:
>> I was unaware of the RFC. Thanks for the reference, however I have to
>> point out the following quote from its introduction:
>>
>> "For reasons discussed in [RFC2993] and Section 5, the IETF does not
>> recommend the use of Network Address Translation technology for IPv6."

That statement is simple IETF politics. A substantial portion of RFC 
2993 doesn't apply to the RFC 6296 mechanism. For example, of the seven 
problems enumerated in section 7, only two -- 7.2 and 7.5 -- remain 
applicable. And, to be fair, those two issues are very minor compared to 
the other five.

>> I'm not saying nobody is going to use IPv6 NAT nor that the Linux world
>> should somehow make it hard on them to do so. There may be a few cases
>> where it makes sense.
>>

Exactly. Even the most recent IAB statement on IPv6 NATs (RFC 5902) 
concedes: "[I]n smaller managed networks that cannot get 
provider-independent IP address blocks, renumbering remains a serious 
issue.  Regional Internet Registries (RIRs) constantly receive requests 
for PI address blocks; one main reason that they hesitate in assigning 
PI address blocks to all users is the concern about the PI addresses' 
impact on the routing system scalability."

So, yes, IPv6 NAT remains inadvisable for most residential applications 
(which can simply propagate their ISP's assigned prefix down to 
devices), and some very large enterprise deployments (which can get PI 
address blocks). But it does solve a very real problem for small to 
medium (and even large, depending on where you want to draw the line) 
enterprises -- basically, "everyone else."

It seems a little silly to refuse _consideration_ of NAT technologies 
when (1) a preponderance of the problems historically present in IPv4 
NATs have been addressed, and (2) a small but nontrivial portion of 
networks that will be using IPv6 soon will desire this technology for 
operational cost reasons.

What I'm saying is that this age-old policy statement: 
<http://lists.netfilter.org/pipermail/netfilter/2005-March/059463.html> 
needs to be revisited. The facts on the ground have changed. Adhering to 
beliefs in the face of contrary evidence isn't principle -- it's 
religion. And imposing religion on others doesn't help anyone.

/a

Re: NAT66 : A first implementation

[YOSHIFUJI Hideaki]

Hi,

David Miller wrote:
> From: Jan Engelhardt <jengelh@medozas.de>
> Date: Fri, 15 Jul 2011 01:15:47 +0200 (CEST)
> 
> > Of course yours is feature-richer. But the topic of IPv6 NAT has had 
> > come up a number of unrecollectable times, and the response has been the 
> > same everytime - NAT is still an ugly undesired hack whose recurrence 
> > wants to be avoided.
> 
> You can't avoid it.
> 
> People want to hide the details of the topology of their
> internal networks, therefore we will have NAT with ipv6
> no matter what we think or feel.
> 
> Everyone needs to stop being in denial, now.

I have to agree.

In fact, we have started using simple, static IPv6-NAT (implemented
in userspace) in our cloud environment.  I still think that IPv6-NAT
is NOT a "must to have," but I agree that some kind of IPv6-NAT will
give us more options from network and/or cloud operational point of
view.  So, I am okay to have it and let market to decide.

Two things:
- I am still against NAT for link-local addresses.
- "NAT" between IPv6 and IPv4 is, of course, needed, as well.

Regards,

--yoshfuji

Re: NAT66 : A first implementation

[Patrick McHardy]

On 15.07.2011 01:17, David Miller wrote:
> From: Jan Engelhardt <jengelh@medozas.de>
> Date: Fri, 15 Jul 2011 01:15:47 +0200 (CEST)
> 
>> Of course yours is feature-richer. But the topic of IPv6 NAT has had 
>> come up a number of unrecollectable times, and the response has been the 
>> same everytime - NAT is still an ugly undesired hack whose recurrence 
>> wants to be avoided.
> 
> You can't avoid it.
> 
> People want to hide the details of the topology of their
> internal networks, therefore we will have NAT with ipv6
> no matter what we think or feel.

I agree, the multiple existing implementations are proof of that.

> Everyone needs to stop being in denial, now.

Re: NAT66 : A first implementation

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

Hi all,

just a few words out of the strange land that retired netfilter hackers
go to:

1) I am quite at ease not participating in netfilter/iptables anymore
   while the discussion about IPv6 NAT becomes an issue again:  I always
   indicated "over my dead body", and now that I am no longer in charge,
   nobody will have to kill me ;)

2) I agree that there has been a lot of improvement between the
   abomination of what we are doing in IPv4 NAT and what is
   described in RFC6296.

3) For any netfilter integration, I would strongly suggest something
   that does not carry aroudn with it the burden of connection tracking,
   but rather something stateless.  Or at least have the conntrack
   dependency optional.  If there's no need for sophisticated state
   tracking as per the RFC, then don't make it a hard/mandatory
   dependency.

... and now I'll happily retire again to GSM land ...

Regards,
	Harald
-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: NAT66 : A first implementation

[Philip Craig]

On Fri, Jul 15, 2011 at 9:15 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Thursday 2011-07-14 18:27, Terry Moës wrote:
>>Multi-Homing. One network can be a client of several ISPs in order to
>>ensure redundancy or in order to reduce costs. These different ISPs
>>will assign the client different prefixes. However, it can be desired
>>that the client does not have to modify the topology of his subnet each
>>time he switches from one ISP to another.
>
> When switching the provider, consider:
>
> - If ISP2 blocks packets with source address SRC1, you are busted. NAT
> won't fix your problem:
>
> - reason 1: NAT is applied per CT and does not automatically change
> while a CT exists.
>
> - reason 2: Even if it did, packets of your connection would suddenly
> have SRC2, and the remote side would reject it with TCP RST, because it
> only knows a connection with SRC1.

I don't see how either of those reasons apply to the situation. The goal
here is to have multiple ISP links, and use them for redundancy and/or
load balancing at a connection level, not to have the same connection go
over both links.

So neither of those reasons stops you from:
- creating a new connection via ISP2 using SRC2
- using multiple connections from SRC1 and SRC2 simultaneously

IPv4 NAT allows you to do the above without needing multiple addresses
on your internal network, and without needing each client on your
internal network to choose which ISP to use for each connection.
It also ensures that the reply packets come back on the same link.

Maybe IPv6 has solved that problem, but I'm not aware of how.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Jan Engelhardt]

On Friday 2011-07-15 07:48, Philip Craig wrote:

>On Fri, Jul 15, 2011 at 9:15 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>>On Thursday 2011-07-14 18:27, Terry Moës wrote:
>>
>>>Multi-Homing. One network can be a client of several ISPs in order to
>>>ensure redundancy or in order to reduce costs. These different ISPs
>>>will assign the client different prefixes.[...]
>>
>>[...About the problems, but also possibilities, about switching 
>>the link of a connection's packets in the middle of the connection...]
>
>[...] The goal here is to have multiple ISP links, and use them for 
>redundancy/load balancing[...] at a connection level, not to have the 
>same connection go over both links.
>
>So neither of those reasons stops you from:
>- creating a new connection via ISP2 using SRC2
>- using multiple connections from SRC1 and SRC2 simultaneously
>
>IPv4 NAT allows you to do the above without needing multiple addresses 
>on your internal network, and without needing each client on your 
>internal network to choose which ISP to use for each connection.

Without the knowledge of which address will be chosen, a client will 
sooner or later run into ETE problems because it does not know which 
address to write into its data stream. Always assume that this data 
stream is armored (visible, but unmodifiable without breaking a 
signature) or even encrypted (invisible, implies armored).


>It also ensures that the reply packets come back on the same link. 
>Maybe IPv6 has solved that problem, but I'm not aware of how.

Well, I am thinking about whether MIP or a form thereof could be of use. 
(Answer: not directly, because a server cannot realistically have two 
routes to two different fd00::1.)

[ BTW Terry: fec0::/ that you are using in your NAT66_slides.pdf are 
deprecated since 2004. ]

What we want: ETEC, i.e. webserver can potentially backconnect (subject 
to any firewalling rules) to an arbitrary port of 1. the src address of 
the packet and/or 2. the address(es) contained in the armored data 
stream.

Step 1. To satisfy point 1, NAT bindings are supposed to be a 1:1 
binding (i.e. ignoring all L4 components // L4 wildcard). NAT bindings 
may be created on the fly as a packet traverses the NAT device. Whether 
that is stateful or stateless is left to the implementation.

Step 2. A client may send addresses inside the data stream. The client 
shall emit a DST header containing a 2-tuple of addresses used in the 
armored/encrypted communication procedure, e.g.

	<i-address, p-address>
	<fc00::1, fc00::1>
afterw.	<fc00::1, 2001:db8::1>

(I chose DST so that it is not stripped at a router. A HBH header that 
each router reproduces would do the same, though that would probably 
need extra routing software support.)

During NAT traversal, only the p-address is changed. A server can now 
substitute "fc00::1" appearing in the datastream by "2001:db8::1" to be 
able to connect.

Naturally, this needs application support, and given there are already a 
handful of solutions with application support, maybe this is not as 
ideal as one of such preexisting solutions. Anyhow, the upside is that 
this would only require application support at the receiver side, which 
means that a client does not need to discover its own addresses in 
advance (like UPNP/IGD if I read it right). The issue with in-advance 
address discovery would be that it may be outdated again once used. 
Also, the header approach does not need protocol modifications.

Step 3. Since I guess some people will whine again that their 
oh-so-secret internal addresses that mean nothing to the outside world 
are visible, the client can actually utilize fake addresses in both the 
armored data stream, and the DST header.

	<::2, fc00::1>
afterw.	<::2, 2001:db8::1>

Since the application support is already given by step 2, this step is 
practically for free.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Terry Moës]

I won't react to anything that has been replied before me about the 
utility of NAT in general. I obviously agree with those of you that 
think it's worth a try !


On 15/07/11 01:15, Jan Engelhardt wrote:
> As such, anything revolving around that topic is closely eyed and
> dismantled. (The Linux camp generally being one that likes to DTRT and
> cook their ideas through, at least more than some
> purely-commercially-oriented huts.)
>
I don't like NAT either. But, by definition, RFC means Request for 
Comments, and I don't know how to make any constructive comment without 
trying to implement it, and see pros and cons...
> As for the thesis paper:
>
> - At times, the document reads like a speech, owing to certain
> linguistic constructs such as enumerations, relatively short sentences
> ("election campaingn" style), and a somewhat abundant use of exclamation
> marks.
I'm not seeing myself as an English-master, and this is the first real 
big project I had in English, thus yes, I agree it can be difficult to 
read. But I don't think we are on this list to criticize my level in 
English.
>> This feature [NAT] is very common in IPv4 networks today - it made the
>> delay of the X-Day possible - and will surely have its applications in
>> IPv6 networks.
> Possible yes, however, delaying of the x-day was surely not one of its
> design goals. As such, the delay seems more like a side-effect at
> first — and then when it became apparent that address space runs out
> "soon", NAT became a constant abuse.
I don't see where I say "Its goal was" in this sentence. A constant 
abuse, maybe, but an abuse that helped the most people to have an 
Internet access at home. Some are conservative and will say it is not 
such a good thing, but I'm not one of them. Some must have said the same 
thing when the Television, next the phone have become so popular...

Let's not forget also that, the more people are using internet, the more 
servers we need; and the more servers we need, the more IP addresses we 
need; ...; quicker will be be the need of IPv6. And I think, as many 
others, that it is time for IPv6 to come, not only for the number of 
available addresses, but for many other reasons !
>
> Side-effect is too soft. Calling NAT a security device comes like
> premeditated deception of end-users.
I insisted enough on the fact that a NAT Device is NOT a security 
device. And it IS a side-effect; too "soft" is somewhat psychologically 
subjective.
But I didn't think either it was a primary and desired effect, until one 
member of my jury, who is a recognized and well-known security expert, 
told me that NAT has two primary interests in today's Internet : 
Multi-Homing and... Security!

Having said that, I don't think "side-effect" is too soft!
> There is a difference between needed address and available addresses. If
> people did not need so many, they could fit all their hosts in the
> available address space instead - and would not need NAT.
Yes. But these addresses were needed, thus they needed NAT. I don't 
understand your point here.
> In fact, each IPv6 hosts usually already has more than one address - and
> one of them is the fe80::/ link-scope prefix. So they are generally
> already multi-homed once one has added a unicast address to an
> interface.
Yes, and these link-scope addresses are not routable, and if you add a 
unicast address from the prefix of one ISP, another one will reject this 
prefix. Therefore, the utility of NAT66!
>> Fast execution NAT in IPv4 is slowed because the NAT device has to
>> recompute the checksums every time a packet goes through; we want to
>> circumvent this limitation.
> You need to recompute them anyway when doing L7 substitution.
Yes, that's something that remains to be done on the implementation I 
provided. And my knowledge is that there is very more packets of L7 
protocols that do not need a L7 substitution, than those that need!
Please, don't read : "there is few L7 protocols that need substitution" 
; I'm talking about the volume of data transferred !
> A 128-bit entity can very well be atomic if the programming language
> implementation decides to make it so. Just because yours does not do it
> currently does not mean it will never be.
Yes, but the title of my thesis say "in a Linux kernel", and I'm not 
thinking that the kernel is compiled in a way that 128 bits are atomic !
But you're right on one point : I should have enlightened that by saying 
"by the time of this writing, and in the Linux kernel".
>
> This statement seems incorrect. One type's representation may be a trap
> representation for another type. Again, just because that is not the
> case in contemporary implementations does not mean it is not possible.
Same as before.
>> routers cannot fragment a packet on their own anymore, and cannot
>> reassemble fragments either.
> While I can agree with this statement, be aware that "routers" running
> nf_conntrack will undoubtedly reassemble in all cases, save perhaps for
> packets delievered to raw sockets due to the order of raw-socket
> delivery and nf_defrag.
My knowledge so far is that the reassembling routine in the conntrack 
(in IPv6) is authorized only in the INPUT chain (Pierre Rondou, who is 
from same University and has same jury of mine has been confronted to 
this problem).
And if some modules in the kernel need to reassemble, I'm not, and I can 
very well work with packet fragmented.

BTW, if you know a module/a way to reassemble a packet in transit in the 
kernel, I'm curious to know it !
> nf_conntrack (required by nf_nat) forces reassembly of
> packets exactly because the L4 header is part of the tracking tuple.
In IPv6 also ?
>> int i; // A loop counter
> 	“A loop counter!? Nobody would have expected _that_!”
What do you mean ?

If what makes you react is the comment, I will say "a comment not very 
useful is more than nothing, which is approximately the level of comment 
in the kernel, and that really is a pain in the ass when you're trying 
to understand something ; and if I was the reader of this portion of 
code, such a comment would surely not hinder me".

And if it's the fact that there is a loop counter that makes you react, 
because it's a mistake, explain to me why this is a mistake would 
certainly be useful !

>> This negotiation happens in a ASCII format data flow and not in a
>> binary format. Therefore, the change of the connection information in
>> the ASCII format may change the length of the packet after the NAT
>> manipulation.
> Note however that binary encodings can also exist as variable-length. So
> binary is not the magic scepter. Think of UTF-8.
What I meant here, is that the length of the IP address may change in 
ASCII format (2001:db8:1::1 => 2001:db8:1:babe::1) has 5 more characters 
in ASCII format. You can have a binary encoding which is 
variable-length, you will never have the same number of bits in both cases.

--
Terry Moës (20061420)
Université de Liège - Faculté des Sciences Appliquées
2ème année Master Ingénieur Civil en Informatique - Délégué
Représentant Etudiant - Conseil de Faculté
FFSA Administrateur -http://www.ffsa.be
T.Moes@student.ulg.ac.be

-- 

N-HiTec - Nova High Technology Engineering and Consulting

Responsable des Infrastructures - Vice-Président

Web :http://www.nhitec.com
Tél :   04/366.20.01

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAT66 : A first implementation

[Jan Engelhardt]

On Friday 2011-07-15 11:16, Terry Moës wrote:

>>- At times, the document reads like a speech, owing to certain 
>>linguistic constructs such as enumerations, relatively short sentences 
>>("election campaingn" style), and a somewhat abundant use of 
>>exclamation marks.
>
>I'm not seeing myself as an English-master, and this is the first real 
>big project I had in English, thus yes, I agree it can be difficult to 
>read. But I don't think we are on this list to criticize my level in 
>English.

Well, it is independent of English - the same atmosphere one can 
construct with many indoeuropean languages. (“IPv6 n'est pas un 
illusion, [n'est pas] un rêve, [n'est pas] une chimère, [n'est pas] un 
concept obscur. C'est ici!” “IPv6 är inte en illusion, [inte] en dröm, 
[inte] en chimär, [inte] en mörk koncept. Det är här!”)

If you have a French copy of the work, I am happy to read it.

>>>This feature [NAT] is very common in IPv4 networks today - it made 
>>>the delay of the X-Day possible - and will surely have its 
>>>applications in IPv6 networks.
>>
>>Possible yes, however, delaying of the x-day was surely not one of its 
>>design goals. As such, the delay seems more like a side-effect at 
>>first — and then when it became apparent that address space runs out 
>>"soon", NAT became a constant abuse.
>
>I don't see where I say "Its goal was" in this sentence.

You don't explicitly, but the subconscious sound is there. (Reads: "NAT 
made the delay possible".)


>maybe, but an abuse that helped the most people to have an Internet 
>access at home.

NAT is not a prerequisite to Internetworking.


>>In fact, each IPv6 hosts usually already has more than one address - 
>>and one of them is the fe80::/ link-scope prefix. So they are 
>>generally already multi-homed once one has added a unicast address to 
>>an interface.
>
>Yes, and these link-scope addresses are not routable,

Routable or not, your host is essentially multi-homed already for a 
particular group of hosts.


>and if you add a unicast address from the prefix of one ISP, another 
>one will reject this prefix.

As I reported, this is not the case. At first I too thought this was a 
bug that one ISP allows packets from another one's address space, but it 
also seemed like a deliberate goal of IPv6.


>>A 128-bit entity can very well be atomic if the programming language 
>>implementation decides to make it so. Just because yours does not do 
>>it currently does not mean it will never be.
>
>Yes, but the title of my thesis say "in a Linux kernel", and I'm not 
>thinking that the kernel is compiled in a way that 128 bits are atomic 
>! But you're right on one point : I should have enlightened that by 
>saying "by the time of this writing, and in the Linux kernel".

I meant the programming language implementation (e.g. compiler with a 
hardware that offers a 128-bit atomic type), not adding atomic barriers 
like spinlocks around IPv6 manipulations in the source code.

Maybe Dave knows whether "long double", which occupies 128 bits on 
x86_64, is an example of an already-existing atomic type.

(And then there is __m128 too.)


>>>routers cannot fragment a packet on their own anymore, and cannot 
>>>reassemble fragments either.
>>
>>While I can agree with this statement, be aware that "routers" running 
>>nf_conntrack will undoubtedly reassemble in all cases, save perhaps 
>>for packets delievered to raw sockets due to the order of raw-socket 
>>delivery and nf_defrag.
>
>My knowledge so far is that the reassembling routine in the conntrack 
>(in IPv6) is authorized only in the INPUT chain (Pierre Rondou, who is 
>from same University and has same jury of mine has been confronted to 
>this problem).

>>nf_conntrack (required by nf_nat) forces reassembly of packets exactly 
>>because the L4 header is part of the tracking tuple.
>
>In IPv6 also ? And if some modules in the kernel need to reassemble, 
>I'm not, and I can very well work with packet fragmented.

Look at NF_IP{,6}_PRI_CONNTRACK_DEFRAG. It runs even before raw, 
otherwise one could not reliably select packets to be -j CT 
--notrack'ed. Cf. 
http://www.spinics.net/lists/netfilter-devel/msg11656.html


>>> int i; // A loop counter
>> 	“A loop counter!? Nobody would have expected _that_!”
>
>What do you mean ? If what makes you react is the comment, I will say 
>"a comment not very useful is more than nothing,[...] which is 
>approximately the level of comment in the kernel, and that really is a 
>pain in the ass when you're trying to understand something ; and if I 
>was the reader of this portion of code, such a comment would surely not 
>hinder me".

What code does, one can read from the source. Summaries are ok, like the 
ones inside xt_find_target. Comments should more often explain why they 
do something - and I agree there is a shortage of those in networking. 
But // A loop counter would just be noise that does not add 
documentation value. ("i" is concise, short, and if it were not used for 
a loop, temporary or immediately obvious construct, you have a naming 
issue according to LKCS chapter 4.)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html