[AusNOG] FW: [Ap-ipv6tf] official shutdown date for IPv4. The date he is pushing for is April 4, 2024. "IPv4 can't go on forever, " Latour said. "

Thu Nov 6 14:59:30 EST 2014

Hi Paul,

I agree with what you’re saying regarding avoiding NAT, however let me describe a scenario I’ve often seen that I can’t see a way around without using some kind of translation:

Router has three interfaces:

wan1
wan2
lan1

Routing requirements are as follows:
1. Traffic from (potentially specified hosts) lan1 destined to a specified set of hosts (setA) should by default go via wan1.
2. Traffic from (potentially specified hosts) lan2 destined to a specified set of hosts (setB) should by default go via wan2.
3. If wan1 fails, all traffic goes over wan2 and vice-versa.
4. Ingress traffic must come back on the same interface.

How this is done today with IPv4 and NAT:
1. PBR determines which interface the traffic should go *out* on and routes over that WAN interface based on the source and destination. i.e. you might want VoIP to go over wan1 and everything else over wan2 by default.
2. Source NAT (Masquerading) on the outbound interface changes the source address and ensures return traffic returns on the right interface. Remembering the address space is not portable and we cannot do asynchronous routing (RPF for one will prevent this).

Avoiding NAT on IPv6, the only mechanism that exists (as discussed) is to use radvd/DHCPv6 to provide multiple IPv6 global addresses out of different non-portable prefixes. This works fine if your client can:
1. Receive a router advertisement in a timely manner (James suggests the default for radvd for example is 30 minutes which doesn't work).
2. Detect if sending traffic out using that source address actually works (although this could be negated if point 1 works properly).
3. Need to configure your routing policies on the client. This is impractical on any scale larger than 1 or 2 hosts.

If we look at this a different way and assume that it becomes practical for these entities to have their own /48, you can multi-home, but forget about any kind of traffic engineering since you won't be able to advertise any prefixes larger than your /48 and control over return traffic is likely to be limited.

I look forward to saying goodbye to NAT, but I think we shouldn't be quick to dismiss all forms of translation as there are a number of use-cases (as described above) that I'm yet to see a solution that's as elegant as what can be currently achieved on IPv4.

NPTv6 gives you everything we need to achieve the above, without the nasties like maintaining session state.

Kind Regards,
Jonathan

From: Paul van den Bergen [mailto:paul.vandenbergen at gmail.com] 
Sent: Thursday, 6 November 2014 2:25 PM
To: Jonathan Thorpe
Subject: Re: [AusNOG] FW: [Ap-ipv6tf] official shutdown date for IPv4. The date he is pushing for is April 4, 2024. "IPv4 can't go on forever, " Latour said. "

OK.

but still - the equivalent of NAT/IPv4 in IPv6 is to have a separate network space for the multiple connecting links with routing at either end to the source/sink networks... 

                 /---------- (path 1 network 2)---------------\
(network 1)                                                            (network 3)
                 \---------- (path 2 network 2)---------------/

or am I still not understanding what you are trying to achieve...?

what I'm saying is that there is no scenario I can imagine where having a NAT + private network segment doesn't have an equivalent configuration achievable with global IPv6 addresses....

everything else is just firewall rules...

On Thu, Nov 6, 2014 at 2:14 PM, Jonathan Thorpe <jthorpe at conexim.com.au> wrote:
Hi Paul,

I think you’ve misunderstood the use case.

This isn’t about externally exposed services (servers etc) – it’s about providing redundant Internet connectivity to sites which aren’t big enough to warrant having their own portable address space (along with the infrastructure/expertise/expense to operate it) in a manner that is achievable today under IPv4 with NAT.

Kind Regards,
Jonathan

From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Paul van den Bergen
Sent: Thursday, 6 November 2014 2:06 PM
To: ausnog at lists.ausnog.net

Subject: Re: [AusNOG] FW: [Ap-ipv6tf] official shutdown date for IPv4. The date he is pushing for is April 4, 2024. "IPv4 can't go on forever, " Latour said. "

wait? what?

How is this any different in IPv6 versus IPv4? 

if you don't route BGP over IPv4, why do you believe you need to route it over IPv6? 

If you don't have any named externally exposed services in an IPv4 world, why would you expose them through your IPv6 firewall?

On Thu, Nov 6, 2014 at 12:43 PM, Jonathan Thorpe <jthorpe at conexim.com.au> wrote:
Hi Mike,

In practice, devices that can manage failover for small sites over a couple of business grade DSL Services from diverse providers have a low barrier of entry (achievable for around $100 and easy to set up) and can in some cases be scaled to support device level redundancy (pfSync etc).

In IPv6, the premise that sites should advertise address space upstream to achieve this makes it all but impossible because:
* Sites need to now get an ASN, pay for and manage their own public address space.
* Get involved with running and tuning BGP (and perhaps a bigger router to hold a couple of full feeds).
* It gets hard to avoid asynchronous routing because your diverse providers are likely to be within a couple of hops of one another and you have almost no control over inbound traffic.

As much as I dislike NAT, this is the one use case where it makes it hard for me to completely abandon. NPTv6 seems like a good compromise to me; being stateless, it largely avoids the issue of session exhaustion under DDoS (it's stateless) and still enables PBR with less chance of asynchronous routing.

Kind Regards,
Jonathan

-----Original Message-----
From: Mike Jones [mailto:mike at mikejones.in]
Sent: Thursday, 6 November 2014 12:13 PM
To: Jonathan Thorpe
Cc: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] FW: [Ap-ipv6tf] official shutdown date for IPv4. The date he is pushing for is April 4, 2024. "IPv4 can't go on forever, " Latour said. "
On 5 November 2014 21:17, Jonathan Thorpe <jthorpe at conexim.com.au> wrote:
> NAT is not a firewall or a security feature and shouldn't be treated as such. At best, it helps abstract internal addressing to help against reconnaissance.
>
> On that basis, I'm happy to see NAT go with IPv6, however I've recently come across a few use cases where it does actually help in a non-security sense.
>
> For most CPE, you don't have the luxury of advertising BGP address space and managing failover in that manner. Instead, you have address/prefix assignments from the ISP and you can NAT traffic from the private address space.
>
> This works well on IPv4 with NAT because you don't have to worry about changing address space on the LAN and can go as far as using PBR to distribute different types of traffic across Internet connections.
>
> From what I've seen, there's currently no workable way to do this with IPv6 on a LAN as there's no NAT. While there's no NAT, we do apparently have NPTv6 (http://tools.ietf.org/html/rfc6296), but I'm yet to see any working implementations of this on any CPE or routing platform.
>
> With NPTv6, we get network address translation, but does so statelessly (not touching ports or host portion of the address), so overcoming some of the shortcomings of NAT. With the expectation of end-to-end consistency in IPv6 addressing however, I do fear that things will still break.
>
> Interesting times ahead.
>

In theory* it is quite the opposite... on IPv4 you need ugly hacks to get redundancy, on IPv6 you shouldn't need to do anything special and will get it automatically for free.

For redundant uplinks: IPv4 NAT based failover requires that you terminate both uplinks on the device and have the device chose which address traffic comes from, so you need a special router that supports dual uplinks for this to work properly. IPv6 based failover you simply advertise both prefixes and the client can chose which source address to use (also meaning you can have different applications bind to different interfaces if you want, so better as well as simpler).

For redundant routers: IPv4 Default gateway failover requires some kind of "smarts" in the routers to detect when the other router goes down and take over its IP address. For IPv6 you simply have both routers plugged in at the same time, if one goes down it stops advertising itself and clients stop using it.

In summary, IPv4 failover requires that you buy routers that support failover then you configure them in a complex failover configuration.
IPv6 can give you full redundancy by simply getting a simple router for each uplink and plugging them in at the same time. You can of course terminate multiple uplinks on the same router if you want.

- Mike Jones

*In practice OS vendors made a small 'mistake' in not tying prefixes to routes. With most ISPs doing uRPF you generally need to match the source address to the uplink that packet is sent to which clients don't do by default, so you in fact do need the router to do additional work as well as being connected to all uplinks like IPv4, just without the NAT. Hopefully this is something that will eventually get fixed, and as soon as the update has been pushed to clients we can start to take advantage of the improved IPv6 design to simplify redundancy.
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

-- 
Dr Paul van den Bergen

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

-- 
Dr Paul van den Bergen