[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. "

Mark Andrews marka at isc.org
Thu Nov 6 15:32:00 EST 2014


In message <98518DB27649AF4EAFB2E355F71E6050020C79BE84 at ISRV-EXCH-1.conexim.loca
l>, Jonathan Thorpe writes:
> Hi Paul,
> 
> I agree with what youre saying regarding avoiding NAT, however let me 
> describe a scenario Ive often seen that I cant 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).

There is nothing preventing the router sending out revised
advertisements the moment loss of connectivity is detected.  Similarly
when it is restored.  Just because the normal state is to send these
every 30 minutes doesn't mean that they are not sent sooner.  Remember
they are also sent in response to a router solicitation whenever a
new node connects to the network.

> 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 youve misunderstood the use case.
> 
> This isnt about externally exposed services (servers etc)  its about 
> providing redundant Internet connectivity to sites which arent 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
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the AusNOG mailing list