[141936] in North American Network Operators' Group
Re: Question about migrating to IPv6 with multiple upstreams.
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Jun 14 13:57:42 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <BANLkTimBXoHzBZLUXVMwUsmtoSgo+z6nXg@mail.gmail.com>
Date: Tue, 14 Jun 2011 10:50:15 -0700
To: William Herrin <bill@herrin.us>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
