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 ;)