-----Original Message----- From: Matthew Reath [mailto:matt@mattreath.com] Sent: June-11-11 11:22 PM To: Randy Carpenter Cc: nanog@nanog.org Subject: Re: Question about migrating to IPv6 with multiple upstreams.

Standard IP routing, the default gateway of the network can decide based on a route entry whether to send it to the cable modem or send it to the firewall.

If the source block is not routed via both connections it won't work without NAT. I had this same problem trying to use my ISP's native v6 over PPPoE and maintain a tunnel as backup since it was still pretty flaky as they were testing it at the time ... no way a residential ISP is going to route 3rd party blocks for all their customers, and no chance the tunnel provider was going to route the block my ISP assigned me either ... with no NAT66 in Tomato/ddWRT/etc it was 100% impossible to have multiple connections ...

I guess I'm a little confused on the setup. You have a firewall with a connection to a local LAN, another connection to customer network(s), and a third connection to the Internet via cable modem?

You have NAT setup to NAT your Local LAN out to the Internet and to the customer network? A customer network device would use the outside IP on the customer network connection to communicate with devices in the Local LAN?

I think it makes more sense to me now.

Provider1 Provider2 | | | | cable modem router (PI space, BGP) | | | |--- Servers | | -------Firewall----- | Clients The clients are on rfc1918 space, or on a small chunk of a block of PI space. For normal web traffic, they get NATed as the outside cable modem IP address on the firewall. For traffic that is to specific places (customer sites), it is routed to the router. For the rfc1918 clients, they are NATed as the PI IP address on the firewall. For the clients that have fully routable PI addresses, they are simply routed normally. Has worked quite well for a long time. -Randy

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@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

----- Original Message -----

The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your upstream providers.

This is precisely what we are doing on the main network. We just want to keep the general browsing traffic separated.

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.

I am hoping that this will eventually become a moot point for this particular installation, but as it is, the cable modem is $50/month for 15 Mb/s, and adding 15 Mb/s to the main network would cost around $3,000/month. It is really hard to justify. If we could BGP via the cable modem, that would be great, but they won't allow it :) -Randy

On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong <owen@delong.com> wrote:

The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your upstream providers.

My "(cheap) cable modem for general browsing" provider wouldn't even delegate RDNS; they'd only put PTRs in *their* servers. Swap BGP routes with them? Swell dream. This has become a common strategy: the cheap, fast, commodity service for the most-of-the-time that it's working and the most-of-the-stuff that it works for combined with the expensive and slow but reliable and full featured service for the mission critical apps. One of these isn't going to come with BGP and a PI prefix, and the technologies we deploy are going to have to deal with that. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com  bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

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@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@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/

I try to avoid the Obfuscation argument when I can. I've seen people try to be smart by telling Law Enforcement that they don't keep logs and can't point to which host was a problem behind a NAT box, only to see Law Enforcement take all the PCs instead of the one in question. So it's always made me nervous. As for the security value; I think it's more a privacy value than anything. But you can accomplish almost the same thing by having those hosts use a web proxy; which you likely want to be doing anyway so you can scan content for threats. I personally have no desire for it; but if someone wants to implement it I won't stop them. On Tue, Jun 14, 2011 at 1:28 PM, William Herrin <bill@herrin.us> wrote:

On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy <rps@maine.edu> wrote:

...

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.

Hi Ray,

There's a nuance here you've missed.

There are two main reasons for ULA inside the network:

1. Address stability (simplifies network management) 2. Source obfuscation (improves the depth of the security plan)

Option 1: Obfuscation desired.

ULA inside. NAT/PAT at both borders. You don't use prefix translation here because prefix translation does little obfuscation: it has a 1:1 relationship with each individual host and still reveals the internal routing structure.

Option 2: Stability, no obfuscation desired.

ULA inside, prefix translation at both borders.

Option 3: Neither stability nor obfuscation required.

GUA from one of the providers inside. Prefix translation to the other provider for the connections desired out that border. Giving the hosts real GUA addresses maximizes application compatibility.

Regards, Bill Herrin

-- William D. Herrin ................ herrin@dirtside.com  bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Jun 14, 2011, at 10:28 AM, William Herrin wrote:

On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy <rps@maine.edu> wrote:

...

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.

Hi Ray,

There's a nuance here you've missed.

There are two main reasons for ULA inside the network:

1. Address stability (simplifies network management) 2. Source obfuscation (improves the depth of the security plan)

Option 1: Obfuscation desired.

ULA inside. NAT/PAT at both borders. You don't use prefix translation here because prefix translation does little obfuscation: it has a 1:1 relationship with each individual host and still reveals the internal routing structure.

Option 2: Stability, no obfuscation desired.

ULA inside, prefix translation at both borders.

Option 3: Neither stability nor obfuscation required.

GUA from one of the providers inside. Prefix translation to the other provider for the connections desired out that border. Giving the hosts real GUA addresses maximizes application compatibility.

If you're going to go with option 3, why not just put both GUA on the hosts and set up proper rules for source address selection to control the outbound preferences? Owen

Why do people insist on creating solutions where each host has exactly one IPv6 address, instead of letting each host have *three* (in this case) - a ULA and two provider-prefixed addresses?

How does the upstream router control which address/path the client host use to route? -Randy

On Jun 14, 2011, at 10:52 AM, Ray Soucy wrote:

It's a security and operational issue.

The perception is that it's easier to monitor, manage, and filter one address per host instead of 3. For most in the enterprise world it's a non-starter to have that setup; even if that perception is a false one.

Yes... The key word there is perception. The question is whether it makes more sense to put effort into correcting mis-perceptions or to put the effort into providing workarounds which provide a sub-par networking experience to the end user. IMNSHO, it is better to put effort into education. I'm surprised to find someone from a .EDU on the opposite side of that thought. One would normally expect them to favor the idea of education over hackery.

Not sure I have the energy to re-hash the tired old NAT debate though. ;-)

That sound you hear is me breathing a sigh of relief. I will continue to do it as long as it remains necessary, but, I'm tired of it too. Owen

On Tue, Jun 14, 2011 at 1:38 PM, <Valdis.Kletnieks@vt.edu> wrote:

...

On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said:

...

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.

Why do people insist on creating solutions where each host has exactly one IPv6 address, instead of letting each host have *three* (in this case) - a ULA and two provider-prefixed addresses?

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Jun 14, 2011, at 2:57 PM, Scott Helms wrote:

...

Yes... The key word there is perception. The question is whether it makes more sense to put effort into correcting mis-perceptions or to put the effort into providing workarounds which provide a sub-par networking experience to the end user.

IMNSHO, it is better to put effort into education. I'm surprised to find someone from a .EDU on the opposite side of that thought. One would normally expect them to favor the idea of education over hackery.

There are few things harder on the planet than changing perception and one of the few is changing human behavior. NAT is normal for many/most enterprises and the thought of trying to explain sub-par networking to most business leaders makes my teeth hurt.

It only took us about 15 years to change behavior to NAT by default, so, I'm betting that if we do the right thing and put in the effort, in 15 years, we can have a nice NAT-free network. Personally, I think it's worth it. I have very little trouble explaining sub-par networking to most of them. Usually it goes something like this... Remember when your IT department came to you with projections of enormous savings on telephone costs in 2003 and your company did their first foray into VOIP? Yeah, that's a good example of sub-par networking. Owen

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@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@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/

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@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@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@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/

On Jun 14, 2011, at 2:42 PM, Seth Mos wrote:

Op 14 jun 2011, om 19:04 heeft Ray Soucy het volgende geschreven:

...

My guess is within the next year we'll see something pop up that does this.

Ehm, It's already here, you searched google right?

I finished it 4 months ago. And a number of commercial platforms already support it. Although Owen doesn't like it much.

I really wish there was a more bomb proof "lite" version of the BGP protocol. - One that has proper authentication not based on a single MD5. - One that does not allow the client side to define the networks. - That will only support default routes, it's easier if it can not carry the world.

Bullet 1: You're in luck... In IPv6, you can run BGP/IPSEC. Works today. Bullet 2: Not sure how you'd do that, but, since the "client side" can't control what the upstream side accepts, I'm not sure why that matters. Bullet 3: You have the option of doing that in BGP today, but, I don't know of any versions of BGP that are so limited other than by memory constraints.

I think a evolved version of ebgp multihop is workable, but you'd still need some lightweight form of hooking back into the BGP table.

Not sure what you mean by this. Pretty simple, really... ISP advertises default and accepts <CUST> prefixes with a simple prefix filter. <CUST> accepts default and advertises own prefixes. Done. Works today. Can mostly be fire-and-forget, even.

Ideally, ISPs could deploy a number of these route "guides" that would inject the proper route into the real BGP table, but by then it is filtered and the ISP has proper control over what ends up in it. Some ISPs could mark this up as a luxury version.

Why not just do it as part of the customer interface configuration on the edge router? Why add the complication of an extra box somewhere else to manage?

Perhaps a form of PI bound to country (Exchange) would be a workable solution. So request a piece of "country PI" that is delegated explicitly to the roaming guide(s).

Country PI is fail for a number of reasons. Owen