From: Jeroen Massar (no email)
Date: Thu Jan 03 2008 - 04:49:38 EST
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 ;)
|
|
|