Question about migrating to IPv6 with multiple upstreams.

Owen DeLong owen at delong.com
Tue Jun 14 21:55:58 UTC 2011


On Jun 14, 2011, at 11:00 AM, Ray Soucy wrote:

> I think that's a market problem rather than a routing problem.  In the
> long term, If we had separation of L2 and L3 service providers there
> would be very, very few who need L3 redundancy; and that amount would
> be fine using BGP.
> 
ROFLMAO... You're joking, right? Oh, you're serious... OK... I encourage
my competitors to try that.

> Metro Ethernet services are making it a bit easier to accomplish this;
> but every ISP wants you to use them for everything so it's still a
> challenge.
> 

I would still want L3 redundancy and I can't imagine any of my clients
choosing to go with diverse L2 paths to the same L3 provider as a
valid complete solution for redundancy.

> I would really like to see L2 optical services being treated as a
> public utility; and you just purchase your L3 from any provider you
> want.  Prices would go down because we wouldn't be wasting money on
> building identical fiber paths, and bandwidth would go up.  Have a
> problem with your current ISP? The switch to a different one can be
> done with a phone call; you don't even need to have a technician sent
> out.
> 

Agreed, but, that doesn't change the fact that L3 redundancy is still
a requirement for a growing (not shrinking) number of organizations.
That's not a market issue, that _IS_ a routing issue.

The good news on that front, however, is that if we get from o(10+) prefixes
per organization to o(2) prefixes per organization, we get a dramatically
smaller routing table with iPv6 fully deployed and can accommodate a
pretty hefty number of additional organizations in IPv6.

> Maine recently started the ground work for that by making a new class
> of Public Utility for Dark Fiber, but it doesn't allow them to light
> it up.
> 
It's been done in Sweden and is being done in AU as well. I've been
advocating an independent monopoly LMI non-profit available to all
higher tier service providers on an equal basis for years. Glad to see
it's starting to finally catch on in a couple of places.

Owen

> On Tue, Jun 14, 2011 at 1:48 PM, Owen DeLong <owen at delong.com> wrote:
>> Actually, a vastly inferior solution, but, it does have the attraction of
>> being able to continue to ignore the need for scalable routing for several
>> more years.
>> 
>> In reality, we need to solve the scalable routing problem at some point
>> and having everyone jump into the IPv6 BGP world for multihoming
>> would be sustainable long enough for that problem to get solved if
>> resources were focused on it.
>> 
>> Owen
>> 
>> On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote:
>> 
>>> Today you're probably correct.  If you want to have more than one
>>> provider reliably you pretty much need to be doing BGP; or have some
>>> sort of primary-backup setup to fail over from one to the other; or
>>> give each host a global address from each provider (really not
>>> desirable in the majority of networks).
>>> 
>>> I think in the long term telling everyone to jump into the BGP table
>>> is not sustainable; and not operationally consistent with the majority
>>> of SMB networks.
>>> 
>>> A better solution; and the one I think that will be adopted in the
>>> long term as soon as vendors come into the fold, is to swap out
>>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>>> policy routing to handle load balancing and failover the way most
>>> "dual WAN" multifunction firewalls do today.
>>> 
>>> Example:
>>> 
>>> Each provider provides a 48-bit prefix;
>>> 
>>> Internally you use a ULA prefix; and setup prefix translation so that
>>> the prefix gets swapped appropriately for each uplink interface.  This
>>> provides the benefits of "NAT" used today; without the drawback of
>>> having to do funky port rewriting and restricting incoming traffic to
>>> mapped assignments or UPnP.
>>> 
>>> The firewall keeps track of if a connection is up or down and keeps
>>> policy routing up to date;
>>> 
>>> You can choose to set it up to either load balance per-flow or as a
>>> primary and backup interface.
>>> 
>>> You can handle DNS by using RFC 2136 updates for a sub-domain with a
>>> short TTL on a hosted server to keep names up to date in the event of
>>> a link drop.
>>> 
>>> This doesn't require cooperation from the provider; it doesn't require
>>> knowledge of routing protocols; and it is easy to understand for
>>> people used to the "NAT" environment.
>>> 
>>> Last time I checked, Linux still needs some work to handle ECMP
>>> routing for IPv6, but once that is in place; combined with patches for
>>> Network Prefix Translation (NPT), it should be trivial to implement.
>>> 
>>> My guess is within the next year we'll see something pop up that does this.
>>> 
>>> Ray
>>> 
>>> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong <owen at delong.com> wrote:
>>>> The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your
>>>> upstream providers.
>>>> 
>>>> Prefix translation comes with all the same disabilities that are present when you do this in IPv4.
>>>> 
>>>> In IPv4, everyone's software expects you to have a broken network (NAT) and there is lots of extra
>>>> code in all of the applications to work around this.
>>>> 
>>>> In iPv6, it is not unlikely that this code will eventually get removed and you will then have a high
>>>> level of application problems in your "prefix-translated" environment.
>>>> 
>>>> Owen
>>>> 
>>>> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote:
>>>> 
>>>>> Prefix translation looks to be exactly what we need to do here. Thanks for all of the replies.
>>>>> 
>>>>> 
>>>>> -Randy
>>>>> 
>>>>> On Jun 12, 2011, at 2:42, Seth Mos <seth.mos at dds.nl> wrote:
>>>>> 
>>>>>> 
>>>>>> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven:
>>>>>> 
>>>>>>> 
>>>>>>> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines.
>>>>>> 
>>>>>> So basically policy routing?
>>>>>> 
>>>>>>> The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections.
>>>>>> 
>>>>>> Yep that sounds like policy routing.
>>>>>> 
>>>>>>> With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished?
>>>>>> 
>>>>>> Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks.
>>>>>> 
>>>>>> Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1.
>>>>>> 
>>>>>> In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56.
>>>>>> 
>>>>>> In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces.
>>>>>> 
>>>>>> The policy routing rules on your firewall can make all the routing decissions for you.
>>>>>> 
>>>>>> If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page.
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Seth
>>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Ray Soucy
>>> 
>>> Epic Communications Specialist
>>> 
>>> Phone: +1 (207) 561-3526
>>> 
>>> Networkmaine, a Unit of the University of Maine System
>>> http://www.networkmaine.net/
>> 
>> 
> 
> 
> 
> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/





More information about the NANOG mailing list