IPv6 NAT

By Jonathan Corbet
July 20, 2011

One of the nice things that the IPv6 protocol was supposed to do for us was to eliminate the need for network address translation (NAT). The address space is large enough that many of the motivations for the use of NAT (lack of addresses, having to renumber networks when changing providers) are no longer present. NAT is often seen as a hack which breaks the architecture of the Internet, so there has been no shortage of people who would be happy to see it go; the IPv6 switch has often looked like the opportunity to make it happen.

So it is not surprising that, when Terry Moës posted an IPv6 NAT implementation for Linux, the first response was less than favorable. Anybody wanting to see the end of NAT is unlikely to welcome an implementation which can only serve to perpetuate its use after the IPv6 transition. The sad fact, though, is that NAT appears to be here to stay. David Miller expressed it in a typically direct manner:

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.

Like it or not, we will be dealing with NAT indefinitely. For those who are curious about how it might work in Linux, Terry's implementation can be found on SourceForge along with a paper describing the design of the code. Both stateless (RFC 6296) and stateful NAT are supported.

Index entries for this article
Kernel	Networking/IPv6

to post comments

IPv6 NAT

Posted Jul 21, 2011 9:13 UTC (Thu) by copsewood (subscriber, #199) [Link] (8 responses)

Smaller IPV6 networks, like the one I'm setting up on my LAN, are going to have to renumber if moving between providers. If not, the router tables will fragment into too many little pieces. If you have an AS number you can change the routing between your address space and the rest of the world, but you need a large network to do that.

IPv6 NAT

Posted Jul 21, 2011 10:04 UTC (Thu) by akumria (guest, #7773) [Link] (3 responses)

And why is renumbering bad?

AIUI you have a router which will either be performing DHCPv6 or SLAAC (stateless address auto-configuration).

In either case, this router will be issuing the prefix (first /64) to other devices.

If you change providers, you have to modify things on the router.

With NAT66, what changes?

- no need to modify DHCPv6 (or SLAAC)
- but you still need to change things on the router

i.e. you still need to change things on the router.

I'm struggling to see why NAT66 helps in your renumbering case.

IPv6 NAT

Posted Jul 21, 2011 11:27 UTC (Thu) by copsewood (subscriber, #199) [Link]

I think it's too early in the cycle to say exactly how smaller IPV6 networks will be configured, as these now are more likely to be for technology exploration geeks and early adopters as opposed to for production use. So IPV6 configurations are likely to be unstable and will change as we learn more. The cost of address renumbering is also pretty low on my list of current IPV6 migration concerns. At the moment IPV6 feels a bit like when in order to get IPV4 connections I had to install userspace PPP or SLIP tunnels over X25 over POTS. My subsequent larger permanently routed IPV4 LAN installs had static IP address allocation per host, as have my early IPV6 ones due to the fact I'm setting static IPV6 routes within my small experimental LAN for which the IPV4 only router carries IPV6 tunneled, prior to very much thought having to be given to IPV6 firewalling.

The primary motivation for IPV4 DHCP also wasn't to conserve IPV4 addresses but to simplify management, so a single host image could be rolled out and didn't need so much hand configuration. Prior to managing the LAN using DHCP/NAT we had the problem of needing to keep a very tight register of address allocations and when that eventually broke down we had occasional instances of duplicate IPV4 addresses fighting each other on the same network.

I'm also not a fan of NAT unless what you really want is a gateway to prevent the outside looking into interior private LAN operations. I am a fan of the kind of stateful default firewall NAT provides - this kind of firewall will still be needed on IPV6 consumer grade routers once these are widely available and sensibly priced, regardless of whether address translation is used or not, to require someone to state to the router that they want to provide a world-visible service before they do so by default, before IPV6 is rolled out as a standard "plug it in and it goes" default option to great numbers of the security ignorant.

IPv6 NAT

Posted Jul 21, 2011 21:14 UTC (Thu) by mstefani (guest, #31644) [Link] (1 responses)

How often have you renumbered networks?
It is a *pain*. Even on the network side which is the easiest part it is a lot of work (globally update your route filters, your firewalls, intrusion detection, monitoring). Even if you use dhcp there will be the odd device or "power user" that has a static address. Or worse there will be that "critical" in house application (of which the IT department doesn't know that it even exists) that has IP addresses hard coded all over the place. And that's only the technical part. The worst thing is that you move from a simple, well understood and local change that you can do in your standard maintenance window to a high impact widespread change. Think project management, business cases and justifications, coordination meetings, ROI discussions, etc. etc.

Oh, and your sales rep with the old provider very well knows those costs of changing IP addresses and will factor that in in his updated quote. And you'll grudgingly have to accept that the $500 that he charges you more per month provides you with the "better value".

So no, changing the IPs with the provider is the worst solution for an enterprise. You want to go either PIR or ULA. But of course for a hotel or coffee place that offers Internet access to their guests changing IP addresses with the providers is a viable solution.

IPv6 NAT

Posted Jul 23, 2011 13:29 UTC (Sat) by dsommers (subscriber, #55274) [Link]

Fair enough, renumbering networks can really be a pain. Agreed! Been there, done that - several times. But is that the fault of the network numbering? Or the management routines related to the network numbering?

I do consider NAT44 a nasty hack, but is pragmatic enough to see that David S. Miller is right. NAT won't go away. But sometimes I wonder why many prefers hacks to solve their issues, rather than to target the root issue. Make the tools you need/use tackle network renumbering better, instead of adding yet another layer of complexity in your core network. Tools will only have effect and do the job when you do the change. NAT66 can impact the network efficiency over a long time.

Regarding 'power users' or 'that "critical" in house application of which IT doesn't know about" ... for me this is just lame excuses why not to aim for a better solution. Yes, these things happens. But that those services or persons outside the IT dep. can be able to keep the IT dep. hostage like this, is just absurd in my eyes.

However, renumbering IPv6 addresses cannot be that easily compared to renumbering IPv4 nets. With IPv4, your netmask might be reduced, or you might have a /27 net which is moved and so on. So with IPv4 addresses you might need to change your addressing scheme, sometimes that's a very big change - *this* is painful. But with IPv6 only the prefix should change, where you most likely will have /48, /56 or /64 subnets. Which means you can keep the same IPv6 addressing scheme, you just need to change the prefix you have been assigned. In other word, this is be *less* painful.

And if I've understood NAT66 correctly, it is not really comparable to NAT44, as *port* NATing is not part of NAT66. NAT66 will just modify the IPv6 prefix. But I've not looked deep into the changes nfnat66 does. If it stays compliant to the RFC6296, I struggle to see the real effect of this "infrastructure hiding" which is claimed as the reason why to use NAT.

IPv6 NAT

Posted Jul 21, 2011 17:36 UTC (Thu) by Lennie (subscriber, #49641) [Link] (3 responses)

Why not use http://en.wikipedia.org/wiki/Unique_local_address ?

You have 3 addresses on your hosts:
- link-local
- global address
- ULA

You can have several ULA-ranges in your organisations and you setup any firewalls and internal DNS and so on to only use the ULA.

I know some people think ULA is a bad idea, but I think using NAT is a lot worse.

IPv6 NAT

Posted Jul 21, 2011 19:58 UTC (Thu) by mstefani (guest, #31644) [Link] (2 responses)

Because it is an operational mess in practice.
ULAs are not a special IPv6 address type like the site local addresses once where. They are global addresses by the standard. So you have 2 global addresses on the hosts and the applications/hosts will "randomly" pick one as source address. There doesn't seem to be any consistency between OSes or even OS versions on which address is chosen and applications can mess with that too. Stateful firewalls tend to not like that and protocols that are NAT unfriendly will have a tendency to break too.

What we hear from network vendors is that their customer that tried your proposal have reverted to use only global addresses pretty quickly and not bother with ULA. Even if they don't route their global address to the internet and provide only NATed or proxied Internet access over IPv6.

No, ULA is a nice idea but doesn't seem to work in practice.
NAT sounds like a bad idea but it tends to work in practice and can simplify some network designs tremendously (multihoming, making sure that the traffic returns through the same stateful firewall, stop gap measure for internet access while you beat your provider and upstream provider for weeks and months to not filter out your prefix, etc). After all NAT is *not* bad, NAT is just a tool. A tool that can be misused but also a tool that can save your ass sometimes.

IPv6 NAT

Posted Jul 21, 2011 22:28 UTC (Thu) by Lennie (subscriber, #49641) [Link]

That is the best argument of why ULA doesn't work I've ever seen.

I do think there are ways to solve that, SLAAC and DHCPv6 have a lot of options, I wouldn't be surprised if most operating systems don't honor half of them though.

The solution could be to have the router(s) send 2 different RA-packets, one with the global routablable address and default route, the other with the ULA and more specific routes for other parts of the network.

That way the host-machine thinks there are 2 routers and thus it knows what source-address to use when talking to the router and hosts on the other parts of the network.

In other news, some people say proxy servers are the solution not NAT.

IPv6 NAT

Posted Aug 30, 2011 23:20 UTC (Tue) by baldur (guest, #77305) [Link]

"So you have 2 global addresses on the hosts and the applications/hosts will "randomly" pick one as source address."

No, the host should follow the rules set out in RFC 3484: http://www.ietf.org/rfc/rfc3484.txt

More specifically the host will use the source address with the longest common prefix of the destination address. This rule guarantees that the ULA address will be used to communicate with other ULAs. And the GUA for other GUAs.

IPv6 NAT

Posted Jul 21, 2011 10:27 UTC (Thu) by pkern (subscriber, #32883) [Link]

Port forwarding would be really, really helpful to have in the toolset. And it can be done right. The ignorance of that is sad. (And yeah, I know that everybody says NAT and means IP masquerading or NAPT really.)

IPv6 NAT

Posted Jul 21, 2011 16:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (33 responses)

Unfortunately, there's no way around at least prefix translation NAT. Because there are still no good other ways to do multihoming.

The only method we have is BGP-based multihoming, but it doesn't scale well with the number of participants and anyway requires experienced administrators to setup and maintain.

Compare this to IPv4 NAT - you just plug two WAN links into a router and it works. Transparently and immediately. No need to pay $3000 just for that privilege.

So until something like LISP is deployed widely, we have no chance but to live with NATs. Even in the IPv6 world.

IPv6 NAT

Posted Jul 21, 2011 17:18 UTC (Thu) by hmh (subscriber, #3838) [Link] (29 responses)

"The only method we have is BGP-based multihoming, but it doesn't scale well with the number of participants and anyway requires experienced administrators to setup and maintain."

Experienced administrators to setup an maintain is certainly true. I'd just change that to network administrators. But it doesn't scale well? I am utterly puzzled about that one.

IPv6 NAT

Posted Jul 21, 2011 17:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (28 responses)

BGP doesn't scale well because each route announcement has to be propagated to ALL of the BGP-capable routers in the world.

Right now there are about 350000 entries in the IPv4 default-free table and it already strains a lot of routing hardware. Imagine what would happen if every home user decided to give BGP a try.

IPv6 NAT

Posted Jul 21, 2011 18:06 UTC (Thu) by raven667 (subscriber, #5198) [Link] (2 responses)

I don't see the number of organizations announcing routes changing just because of IPv6. I would actually see the number of existing IPv4 routes as an upper bound because consolidation seems likely. Providers can have large contiguous blocks that they can internally subdivide but should be able to announce in aggregate.

IPv6 NAT

Posted Jul 21, 2011 18:48 UTC (Thu) by hmh (subscriber, #3838) [Link]

BGP multihoming requires PI space, which does increase the routing table size _always_.

That's not the problem. The problem is that you pretty much have to de-aggregate your announcements to do traffic engineering, and that inflates the table a LOT more. And very large ISPs won't aggregate it back later: http://www.cidr-report.org/as2.0/#Gains

The number of updates per second is just a matter of not using wimpy router CPUs to deal with large BGP feeds in the first place, and not doing full table feeds where it is not needed so that wimpy routers just have to deal with less than 5k routes and a few updates per minute.

Route table size is different, supporting very large route tables on high-speed routers is not that easy. However, I am still waiting to see a hardware router which does for its distributed TCAMs what your typical high-end CPU does for its L1/L2 cache. If anyone knows of a vendor that does this, please share.

IPv6 NAT

Posted Jul 21, 2011 20:26 UTC (Thu) by mstefani (guest, #31644) [Link]

There will be consolidations especially in the provider space but a lot of small and medium businesses that are multihomed with NAT to their providers IPv4 addresses might go PIR. That is the big unknown: how many will go that route or stay with NAT/proxy based Internet access.

I don't see consolidation in route entries for global enterprises. Those will have multiple regional connection points to the Internet and will *need* independent routing for those.

IPv6 NAT

Posted Jul 21, 2011 23:08 UTC (Thu) by anselm (subscriber, #2796) [Link] (24 responses)

Right now there are about 350000 entries in the IPv4 default-free table

IPv6 seems to get by with 6900 entries or so at the moment. The nice thing about IPv6 is that there are no provider-independent addresses, which are the main reason why the IPv4 default-free tables are so big.

IPv6 NAT

Posted Jul 22, 2011 0:03 UTC (Fri) by dlang (guest, #313) [Link]

I see two ways to look at this.

1. almost nobody is using IPv6 yet, so the size of the tables reflect that

2. with IPv6, everybody's address will be provider-independent (or if they aren't, there will be even more of a push for NAT66 so that people can continue to map between their internal addresses that are configured on the servers, and what the outside world sees them as, just in case they ever want to switch providers)

I personally think both are true.

IPv6 NAT

Posted Jul 22, 2011 7:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (21 responses)

That's because only about 10% of autonomous systems announce IPv6 prefixes. The table will be guaranteed to grow.

And if we want to have NAT-less world it'll have to grow BIG.

IPv6 NAT

Posted Jul 22, 2011 8:32 UTC (Fri) by anselm (subscriber, #2796) [Link] (20 responses)

I'm not convinced. The IPv4 routing tables are as big as they are because (a) various assumptions governing address allocation were flawed and couldn't really be corrected retroactively, and (b) people are generally not eager to renumber their whole network when they change providers just to simplify the default-free routing tables, hence »provider-independent addresses« for larger installations.

With IPv6, renumbering is much less of a hassle than with IPv4, and there are many more addresses available in the first place, so there's a good chance that the routing tables will not grow that much. They will probably grow some, but not by several orders of magnitude.

(Note: I don't claim to be an IPv6 guru, but I have this from a few people who do IPv6 for a living, and it makes sense to me.)

IPv6 NAT

Posted Jul 22, 2011 9:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (19 responses)

>With IPv6, renumbering is much less of a hassle than with IPv4, and there are many more addresses available in the first place, so there's a good chance that the routing tables will not grow that much. They will probably grow some, but not by several orders of magnitude.

First, even renumbering won't help you to use two independent uplinks. You either need PI or NAT for it. No other choices. And right now NAT wins by a huge margin.

As for renumbering, have you ever done it with IPv6? It's actually WORSE than with IPv4.

<rant mode on>
The situation with IPv6 rhymes with "muster duck", to quote someone on NANOG.

For example, I have a device (say, a network printer) on my network. It gets its address from SLAAC. So far so good, the only question is: how do I discover it?

Manually adding it by typing 128-bit long address is out of the question. And won't work with renumbering, anyway.

Ok, let's try DHCPv6. Oh, another "muster duck" - it can't be used separately without SLAAC. And anyway, this way I'll have to identify my devices by MAC addresses which is definitely suboptimal. Also, DHCP server becomes a single point of failure and a maintenance nightmare.

Ok, what if we want device to self-register in my local DNS? Can't be done. TSIG is broken for that purpose and IETF only _now_ starts to think about suitable standards for it.

With NAT everything is easy - just statically assign IPv4 address and you're done. And it'll work even if you have multiple uplinks. End of story.
</rant mode off>

IPv6 NAT

Posted Jul 22, 2011 14:13 UTC (Fri) by foom (subscriber, #14868) [Link] (2 responses)

Well, the way machines get names on both my home IPv4 home network and my work IPv4 network is that the DHCP server creates an entry in DNS for the hostname that the endpoint reports in its DHCP request.

When the lease expires, the name is removed from DNS. The device doesn't need to self-register with DNS, since the DHCP server handles it. And the DHCP server doesn't need to have MAC address mapping for the endpoints, since it just gets the names from the DHCP request.

Works great....and would work for IPv6 too, if I had set that up.

IPv6 NAT

Posted Jul 22, 2011 20:10 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Yeah.

Want to bet that it'd take less than a week in organization of medium size for a host with duplicate name to appear?

Also, that's a nice attack vector for hackers. Just infect your CEOs iPad and make it impersonate a VerySecureFinancialServer.yourorganization.com - DHCP is not authenticated so all hacker would need to do is change iPad's hostname.

IPv6 NAT

Posted Jul 24, 2011 18:00 UTC (Sun) by foom (subscriber, #14868) [Link]

> Want to bet that it'd take less than a week in organization of medium size for a host with duplicate name to appear?

Well, we use the automatic unauthenticated assignment for desktops so it mostly doesn't matter (and btw, there's ~400 of them). If a duplicate name is requested, it's simply ignored if the first DHCP lease is still active. Of course if the first user's lease expires (or is relinquished), you could steal their hostname, indeed. Shrug.

> Also, that's a nice attack vector for hackers. Just infect your CEOs iPad and make it impersonate a VerySecureFinancialServer.yourorganization.com - DHCP is not authenticated so all hacker would need to do is change iPad's hostname.

Well, yes, guess what. Neither MAC addresses nor IP addresses are authenticated either. If you want to secure such things, you'll need to have a separate trusted network segment (or use 802.1x), and then you can lock down "secure" hostnames to that network segment.

You can also use Windows Active Directory, with which it is trivial to do dynamic hostname assignment authenticated to the host's kerberos key.

IPv6 NAT

Posted Jul 22, 2011 15:48 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

Service discovery is still a problem in IPv4 which is why protocols such as mDNS exist but there is also standard ways of discovering neighbors in IPv6 such as pinging the all hosts multicast address ff02::1. Manually putting addresses in DNS is certainly not out of the question either, just because you have a slightly longer address string.

Sure there are operational changes with IPv6 and there will be rough edges that need to be refined that will become more apparent as it is used more. Think about the difference between a modern IPv4 implementation such as in Linux vs. IPv4 of 10 or 20 years ago. The protocols are compatible but the implementation and management are very different. Implementations can be modified to support quick prefix changes without changing any of the local subnetting or addressing in a compatible way, if that is the way the market goes.

IPv6 NAT

Posted Jul 22, 2011 20:29 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>Service discovery is still a problem in IPv4 which is why protocols such as mDNS exist but there is also standard ways of discovering neighbors in IPv6 such as pinging the all hosts multicast address ff02::1.

That's so incredibly unreliable and convoluted, that it actually might be used.

>Manually putting addresses in DNS is certainly not out of the question either, just because you have a slightly longer address string.
It is out of the question. Addresses are not 'slightly' longer, they are ten _times_ longer in practice.

In IPv4 world one just needs to remember _one_ _octet_ in practice. Because three other octets are usually fixed in a typical NAT-ed network. In IPv6 world one needs to remember at least 8 octets.

And no, assigning the second half of the IPv6 manually won't work. I have not yet seen a device that can accept a prefix advertisement AND allow to assign the postfix manually. And you'll need it to make renumbering even a remotely possible alternative.

>Sure there are operational changes with IPv6 and there will be rough edges that need to be refined that will become more apparent as it is used more. Think about the difference between a modern IPv4 implementation such as in Linux vs. IPv4 of 10 or 20 years ago.

Not true. IPv4 networks 10 years were administered almost exactly like today. Even 15 years ago situation was not that much different (well, we used HTTP proxies instead of NATs, relied more on manual assignment than on DHCP but that's basically all).

IPv6 is right now NOT READY for the real world. The basic protocol is fine, but everything else starting from DHCPv6 and SLAAC is utterly and horribly broken.

/me wants to hit IETF members with a lead pipe. Repeatedly.

IPv6 NAT

Posted Jul 23, 2011 16:12 UTC (Sat) by baldur (guest, #77305) [Link] (13 responses)

Your printer already has an address that never changes: The link local address.

But lets consider what it is you want. You want a private address range, for example fdbe:3b30:fb0b::/48. You can make up your own range easily here: http://bitace.com/ipv6calc/

Then you propose to use NAT to convert that range to your real public address range. But why would you do that? It is so much simpler to assign both a private AND a public IP to every device. If you are multihomed you simply assign two public IPs to everyone. In case you are wondering: How long does it take for everyone to switch to the backup if the primary fails: 30 seconds (the NUD timeout).

If you follow all the rules a private range can be quite long and hard to remember as in my example. But then, if you don't care and it appears you don't, why not just use fd00::/64 as your range? Then your printer could be fd00::5. How is that any harder to remember than 172.16.0.5? The IPv6 address is in fact shorter...

How to make the printer be fd00::5? The same way as with IPv4. Either manual config or through DHCP(v6).

IPv6 NAT

Posted Jul 23, 2011 16:23 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

Link-local addresses are useless. They JustDoNotWork(tm).

First, not all services accept link-locals. Second, they are not routed.

>Then you propose to use NAT to convert that range to your real public address range. But why would you do that?
Because alternatives suck.

>It is so much simpler to assign both a private AND a public IP to every device. If you are multihomed you simply assign two public IPs to everyone. In case you are wondering: How long does it take for everyone to switch to the backup if the primary fails: 30 seconds (the NUD timeout).

Yeah, yeah. Now try this _in_ _practice_. Printers and other networked devices usually don't support it. And even desktop computers have problems with choosing correct addresses.

AND you're not solving the problem with renumbering, you're actually making it even worse (which IP address should be registered in DNS if we have three uplinks?).

Oh, and I actually help to support a production IPv6 network of about 1000 devices. Try this, and you'll rapidly realize that IPv6 is just not yet ready for the real world.

IPv6 NAT

Posted Jul 23, 2011 18:33 UTC (Sat) by baldur (guest, #77305) [Link] (11 responses)

Any device that supports IPv6 also supports multiple addresses. In fact the minimum number of addresses possible is two: The link local and the public IP. A Windows computer will have a minimum of three: Link local, the permanent public and the temporary privacy address.

Fact is that if you put two or more routers on a network and let them announce different prefixes, I have never seen a device that will not pick them up correctly. I have never seen a desktop OS that did not choose the correct address, do you have any documentation for that claim?

What address would you put in DNS if you were using NAT with multiple uplinks? Whatever your answer to that question I will say the same for the solution without NAT.

I am not sure why you want client computers to be in the DNS in the first place. But anyway, one possible answer is to put all the public IP addresses in the DNS. Some programs, like a web browser, knows to try the alternative IP if the first fails. Another answer is to put the private fd00:: addresses in DNS. This will work for anyone using VPN or similar to your network (ie. anyone that has a reason to communicating with your client machines using a DNS name).

If we are talking about servers the best option is PI. As would it be in a solution that includes NAT. But there is actually an alternative: You can use mobile IPv6. This has no overhead when your primary link is up.

In fact you can use mobile IPv6 or NEMO for the whole network if need to. Or you can use LISP.

IPv6 NAT

Posted Jul 23, 2011 19:07 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

I know that there is always a link-local address. It doesn't matter.

For example, on HP networked printers allow to manually assign only one address. And Windows does not allow to select address precedence using GUI, so it's extremely easy to get one congested link and one lightly loaded - and no way to fix it. Even setting an interface metric (which still doesn't solve problems in reality) requires to use DHCPv6 and SLAAC.

Even something as simple as ULA does not work well.

>What address would you put in DNS if you were using NAT with multiple uplinks?
The local address. It works fine for intra-organization purposes. In fact, it works GREAT when it's coupled with Microsoft AD.

>If we are talking about servers the best option is PI.
Which is expensive and doesn't scale.

>As would it be in a solution that includes NAT. But there is actually an alternative: You can use mobile IPv6.
No I cannot. Mobile IPv6 is not even supported in Linux properly, never mind all those embedded networked devices. Oh, Windows Vista/7 also don't support it.

IPv6 NAT

Posted Jul 23, 2011 19:39 UTC (Sat) by baldur (guest, #77305) [Link] (9 responses)

Your HP printer only needs one manually configured address: The ULA. This is the same with or without NAT.

Address preference is set by the router (RA option).

ULA address in the DNS works the same with or without NAT.

Mobile IPv6 would require extra software on the clients yes. But not on these embedded devices, printers, etc, that are not supposed to be public available anyway. There is Linux support btw: http://www.umip.org/

You are overlooking the more powerful alternatives:

NEMO: http://www1.cse.wustl.edu/~jain/cse574-06/ftp/network_mob...

LISP: http://en.wikipedia.org/wiki/Locator/Identifier_Separatio...

LISP was used by Facebook during IPv6 day.

IPv6 NAT

Posted Jul 24, 2011 17:35 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

I'm not overlooking anything. I need something right _now_.

And right now I have only two solutions: NAT or PIR. And the second one is expensive and complex.

Forget IPv6 NAT; use LISP instead

Posted Jul 24, 2011 20:58 UTC (Sun) by baldur (guest, #77305) [Link] (7 responses)

If you need something now go download yourself a copy here: http://www.openlisp.org/

Or if you are using Cisco go here: http://lisp4.cisco.com/index.html

The Linux implementation (which seems less mature): https://github.com/aless/

The available NAT66 solutions do not seem to be any more mature than LISP. Since LISP is so far superior I can not imagine the world taking on NAT66 at a greater scale. I would therefore expect little or no application support for NAT66 and a world of hurt for those that follow that ill path. There for sure are zero applications today that handles NAT on IPv6 (using STUN to figure out the real IP address and all that jazz).

Forget IPv6 NAT; use LISP instead

Posted Jul 25, 2011 8:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Ok.

I have IPv6 address assignment from my ISP. I want to use LISP. What should I do?

..crickets..

Forget IPv6 NAT; use LISP instead

Posted Jul 25, 2011 9:39 UTC (Mon) by baldur (guest, #77305) [Link] (5 responses)

Install one of the 6 different implementations. Decide if you want to be part of the beta network or just setup your own proxies. If you want the beta network follow the guidelines here: http://www.lisp4.net/beta-network/get-involved/

Otherwise you can ignore the network and install your own PxTR(s) on collocated servers.

Forget IPv6 NAT; use LISP instead

Posted Jul 25, 2011 13:10 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

So, right now LISP is useless as-is. And the only way to use it is to have a proxy somewhere with a stable IP address.

Well, I can do this with IPSec tunnels or PPtP/GRE. And more easily, in fact.

Forget IPv6 NAT; use LISP instead

Posted Jul 25, 2011 19:34 UTC (Mon) by baldur (guest, #77305) [Link] (3 responses)

LISP is very useful and was used by some very large sites (Facebook) during IPv6 day. If they can so can you.

But you are right - a tunnel is yet another way to solve the multihome issue. So now we got:

1) IPv6 with multiple prefixes
2) IPv6 with multiple prefixes and ULA
3) LISP: http://www.lisp4.net/
4) BGP multihome
5) NEMO and MIPv6: http://software.nautilus6.org/implementations.php
6) Custom tunnel
7) NAT66 (pre alpha version published on 15 Jul 2011: http://sourceforge.net/projects/nfnat66/).

We are currently doing 1) on a significantly larger network than the one you administer and it "just works". But I definitely think the future is 3). It might currently take some involvement to setup but that will change quickly.

The use cases and complaints that you have put forward are all solved by LISP and in a much better way than NAT66.

Forget IPv6 NAT; use LISP instead

Posted Jul 26, 2011 16:26 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

LISP has the same problem as IPv6 - to be useful it needs to be widely deployed. And it doesn't look like it'll happen soon.

MIPv6 and NEMO are effectively dead. They require cooperation of both parties to avoid triangular routing, and that's not going to happen because Windows has dropped MIPv6 support and has never had NEMO support.

I honestly think that NAT66 will be used quite widely. And it's actually not that bad, because it's possible to use it just in prefix-translation mode with 1-to-1 mapping.

Forget IPv6 NAT; use LISP instead

Posted Jul 26, 2011 16:53 UTC (Tue) by baldur (guest, #77305) [Link] (1 responses)

You can be the first person in the world to implement LISP and it will be useful. It is not just a tunnel equallent.

Say you have ISP A and ISP B as uplinks. In addition pay for, rent or collocate a server at both ISPs where you install the LISP proxy software. Granted this extra expense but you got:

1) The ISPs are taking care of BGP.
2) Automatic load balancing both up and downstream.
3) Automatic failover.
4) If you got PI address space you can easily switch ISPs.
5) If one server goes down your are still good although this depends on the ISP stopping advertising your PI space.

LISP currently as an enormous amount of steam so I feel quite confident that the beta network will eventually convert to production state. At that point it will be just as easy to setup as NAT66 but without any of the drawbacks. All you would need is to login to the web interface of your standard router and check the LISP option. Then tell it four pieces of information: Your allocated EID, the address of the map service, your username and password.

Of course NAT66 will happen but I don't see multihoming or renumbering-protection as good use cases. These will be better handled by LISP. I don't see most applications getting good NAT66 handling the same way they have NAT44 handling today.

We are probably not going to get any more learnings or consensus out of this thread. I just wanted to point there are in fact more options than BGP and NAT66.

Forget IPv6 NAT; use LISP instead

Posted Jul 26, 2011 17:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, it's much easier just to register in ARIN/RIPE and get PI assignment. It'll cost about $3000, which is far cheaper than two colocated servers/routers with BGP and LISP support. And I'll get all those benefits and without need to setup LISP.

We've actually considered a similar variant (colocate a server and use it to terminate GRE tunnels).

So while there may be other ways (I'll concede that multiple IPv6 addresses might work for somebody), your choice is still is very much between spending $$$$ and having in many ways inferior solution.

As for LISP, it merits its own article on LWN. And right now it's FAR from being really complete (which is OK, people are still working on it).

PI Addresses

Posted Jul 22, 2011 11:06 UTC (Fri) by mstefani (guest, #31644) [Link]

No provider independent addresses for IPv6? Providers loved the idea of locking their customers in as they know the real costs of re-IPing your network. But that severely hampered the uptake of IPv6 in the enterprise space.

Grudgingly they had to accept the concept of PI addresses 2 - 2.5 years ago. We got our provider independent /46 more than a year ago.

So no IPv6 doesn't fixes the issues of the real Internet in any way, form or shape. It may make the problem even worse, but that depends of course if IPv6 will "take over". Luckily we have now NAT66 standardized and I have a feeling that a lot of people will go for that as it is the simplest and least ugly of the multihoming solutions. That will buy us time until something like LISP (Locator/Identifier Separation Protocol) catches on.

IPv6 NAT

Posted Jul 21, 2011 18:11 UTC (Thu) by raven667 (subscriber, #5198) [Link] (2 responses)

That kind of device can only work for outbound connections, inbound traffic would still require dynamic DNS changes. In IPv6 it's pretty easy to change the network prefix and have that change announced via router advertisement, without changing any of the local subnets or local addressing, wouldn't doing that make more sense as an outbound-only failover mechanism? Coupled with quick DNS changes for inbound connections seems like it could solve the problem simply.

IPv6 NAT

Posted Jul 22, 2011 7:10 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Sure, but home users don't usually run servers. And even companies often use rendezvous services like LogMeIn or DropBox instead of dealing with DNS and portmapping.

IPv6 NAT

Posted Jul 23, 2011 19:19 UTC (Sat) by mastro (guest, #72665) [Link]

Home users very often run servers. They're part of their file-sharing "clients" (including BitTorrent), voice and video call programs, modern web browsers (that now or soon will support ConnectionPeer, <device>, WebSockets and whatnot), browser plugins and in general any P2P program.

For home users getting rid of NAT will be a huge step forward and open many new possibilities even for application that are usually considered unaffected by NAT, like browsers and websites.

IPv6 NAT

Posted Jul 22, 2011 9:42 UTC (Fri) by pabs (subscriber, #43278) [Link]

It should have been called NAT666.