Building network automation solutions

9 module online course

Start now!

Category: NAT

Video: Scale-Out NAT

Network Address Translation (NAT) is one of those stateful services that’s almost impossible to scale out, because you have to distribute the state of the service (NAT mappings) across all potential ingress and egress points.

Midokura implemented distributed stateful services architecture in their Midonet product, but faced severe scalability challenges, which they claim to have solved with more intelligent state distribution.

read more see 5 comments

464XLAT Explained

IETF recently published RFC 6877 (464XLAT) describing a dual-translation mechanism that allows an IPv6 host (or CPE) in an IPv6-only access network to pretend it still has IPv4 connectivity. Why would one need a kludge ingenious solution like this? In a word: Skype.

For more details, watch the video explaining the need for 464XLAT and two typical use cases: Android handset and a CPE device (example: SOHO router with 3G uplink).

see 4 comments

IPv6 Multihoming Without NAT: the Problem

Every time I write about IPv6 multihoming issues and the need for NPT66, I get a comment or two saying:

But I thought this is already part of IPv6 stack – can’t you have two or more IPv6 addresses on the same interface?

The commentators are right, you can have multiple IPv6 addresses on the same interface; the problem is: which one do you choose for outgoing sessions.

The source address selection rules are specified in RFC 3484 (Greg translated that RFC into an easy-to-consume format a while ago), but they are not very helpful as they cannot be influenced by the CPE router. Let’s look at the details.

read more see 14 comments

We Just Might Need NAT66/NPT66

My friend Tom Hollingsworth has written another NAT66-is-evil blog post. While I agree with him in principle, and most everyone agrees NAT as we know it from IPv4 world is plain stupid in IPv6 world (NAPT more so than NAT), we just might need NPT66 (Network Prefix Translation; RFC 6296) to support small-site multihoming ... and yet again, it seems that many leading IPv6 experts grudgingly agree with me.

read more see 24 comments

Brocade ServerIron ADX – NAT64 done right

With the latest software release (12.3.01) the ServerIron ADX, Brocade’s load balancer product, supports the real NAT64 (not 6-to-4 load balancing). Even more, it supports all of the features I would like to see in a NAT64 box plus a few more:

True NAT64 support, mapping the whole IPv4 address space into an IPv6 prefix that can be reached by IPv6 clients. One would truly hope the implementation is conformant with RFC 6146, but the RFC is not mentioned in the documentation and I had no means of checking the actual behavior. DNS64 is not included, but that’s not a major omission as BIND 9.8.0 supports it.

read more add comment

NAT-PT is dead! Long live NAT-64!

I’m getting questions like this one all the time: “Where are we with NAT-PT? It was implemented in IOS quite a few years ago but it has never made it into ASA code.

Bad news first: NAT-PT is dead. Repeat after me: NAT-PT is dead. Got it? OK.

More bad news: NAT-PT in Cisco IOS was seriously broken after they pulled fast switching code out of IOS. Whatever is left in Cisco IOS might be good enough for a proof-of-concept or early deployment trials, but not for a production-grade solution.

read more see 8 comments

Small Site Multihoming in IPv6: Mission Impossible?

Summary: I can’t figure out how to make small-site multihoming (without BGP or PI address space) work reliably and decently fast (failover in seconds, not hours) with IPv6. I’m probably not alone.

Problem: There are cases where a small site needs (or wants) to have Internet connectivity from two ISPs without going through the hassle of getting a BGP AS number and provider-independent address space, and running BGP with both upstream ISPs.

read more see 10 comments

NAT444, DS-Lite, A+P and NAT64 explained

One of the biggest hurdles Internet Service Providers will face in the near future is access to legacy IPv4 content once we run out of globally routable IPv4 addresses. Although it’s easy to offer your content over IPv6 (assuming you have a properly designed network using load balancers from a company that understands the need for IPv6 in Data Center), a lot of the “long tail” content will remain reachable only over IPv4.

A while ago I’ve published a presentation I’d delivered at the Slovenian IPv6 summit; a few days ago has published my article describing various transition solutions in more details. In the first part, “IPv4 address exhaustion: Making the IPv6 transition work”, I’m describing the grim facts we’re facing and the NAT-PT fiasco. In the second part, “Comparing IPv6 to IPv4 address translation solutions”, you’ll find brief descriptions of LSN (also known as CGN – Carrier-Grade NAT), NAT444, DS-Lite, A+P and NAT64.

And don’t forget: if you’re looking for in-depth IPv6 information, consider registering for the Building IPv6 Service Provider Core webinar; we can also organize an Enterprise IPv6 Deployment workshop for you.

see 2 comments