How to do sites when you have a distributed organization with no own network (Was: v6 subnet size for DSL & leased line customers)

Thu Jan 3 09:49:38 UTC 2008

Simon Lyall wrote:
> On Wed, 2 Jan 2008, Deepak Jain wrote:
>> Is there anything inherently harmful with suggesting that filtering at
>> RIR boundaries should be expected, but those that accept somewhat more
>> lenient boundaries are nice guys??? When the nice guys run out of
>> resources, they can filter at RIR boundaries and say they are doing so
>> as a security upgrade :_).
> 
> So how would this work for large companies?
> 
> In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should
> only get at most a /48 from each RIR.
> 
> How should they handle region offices, Especially mutihomed ones?

First thing you will have to define here is 'multihomed'. Do you mean
that they have 1 prefix and multiple upstreams, or do you mean that they
have multiple upstreams and multiple prefixes?

This is actually a problem for every organization that does have
multiple distributed offices/sites but doesn't have the
capability/core-business of setting up connectivity between all of them
and moving the bits for all of them.

Nevertheless the current 'solution' to this problem (1 org, distributed
sites, no own network between those sites) will be:

option 1)
 - Every site gets a /48 from their local ISP
 - Internet connectivity happens using the ISP prefix

 - Communications between sites happen using the ISP prefix
 - Site Firewalling happens on the ISP prefix (multiple
   entries needed, lets hope they don't change or that
   an auto-update system is in place)

option 2)
 - Every site gets a /48 from their local ISP
 - $org gets a prefix from RIR
 - Every site gets a /48 from the $org prefix

 - Every site setup a VPN to every other site where needed
 - Internet connectivity happens using the ISP prefix
 - Communications between sites happen using the org prefix
 - Firewalling happens on the $org prefix

Option 2 has one small problem though: source address selection.
Fortunately if one can deploy RFC3484 properly this should not be a big
problem. Also mostly a source address is chosen based on it being
'closest' to the destination prefix*.

Greets,
 Jeroen

* = which is why when 2003::/16 started to get deployed, 6to4
(2002::/16) was being preferred over 2001::/16 source addresses ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080103/ca504268/attachment.sig>