<div dir="ltr"><div><br></div>wait? what?<div><br></div><div>How is this any different in IPv6 versus IPv4? </div><div><br></div><div>if you don't route BGP over IPv4, why do you believe you need to route it over IPv6? </div><div><br></div><div>If you don't have any named externally exposed services in an IPv4 world, why would you expose them through your IPv6 firewall?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Thu, Nov 6, 2014 at 12:43 PM, Jonathan Thorpe <span dir="ltr"><<a href="mailto:jthorpe@conexim.com.au" target="_blank">jthorpe@conexim.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mike,<br>
<br>
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).<br>
<br>
In IPv6, the premise that sites should advertise address space upstream to achieve this makes it all but impossible because:<br>
* Sites need to now get an ASN, pay for and manage their own public address space.<br>
* Get involved with running and tuning BGP (and perhaps a bigger router to hold a couple of full feeds).<br>
* 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.<br>
<br>
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.<br>
<span><br>
Kind Regards,<br>
Jonathan<br>
<br>
-----Original Message-----<br>
</span><span>From: Mike Jones [mailto:<a href="mailto:mike@mikejones.in" target="_blank">mike@mikejones.in</a>]<br>
Sent: Thursday, 6 November 2014 12:13 PM<br>
To: Jonathan Thorpe<br>
Cc: <a href="mailto:ausnog@lists.ausnog.net" target="_blank">ausnog@lists.ausnog.net</a><br>
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. "<br>
<br>
</span><div><div>On 5 November 2014 21:17, Jonathan Thorpe <<a href="mailto:jthorpe@conexim.com.au" target="_blank">jthorpe@conexim.com.au</a>> wrote:<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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 (<a href="http://tools.ietf.org/html/rfc6296" target="_blank">http://tools.ietf.org/html/rfc6296</a>), but I'm yet to see any working implementations of this on any CPE or routing platform.<br>
><br>
> 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.<br>
><br>
> Interesting times ahead.<br>
><br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
In summary, IPv4 failover requires that you buy routers that support failover then you configure them in a complex failover configuration.<br>
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.<br>
<br>
- Mike Jones<br>
<br>
*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.<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Dr Paul van den Bergen<br><br></div>
</div></div>