BCP for multisite multihoming

[Max Tulyev]

Hi!

Sorry for so late answer on so interesting theme for me :(

But. There was a nice discussion, but I didn't see anything really
simple and working in practice was offered can became BCP for such
project. So, I'll try to do some sort of howto.

At first, all four sites should have own ASNs and own IP space of course.

There is three different RIR regions, so actions will be a bit different.

RIPE region (London): Go to one of RIPE LIR (me? :) ), get /24 or more
PI space, get ASN. It will cost you less than $1000 one-time fee. If you
really need IPv6 - you should get not less than /32. I have a BIG
troubles with less size more specific prefixes routing, it means <=/32
more specific is unusable for business. IPv6 will cost you much more,
most probably starting up a new LIR, EUR2000 + almost same EUR2000 per year.

ARIN region (NY): Payments:
http://www.arin.net/billing/fee_schedule.html. You also need IPv4 PI /20
(minimum assignment), ASN, and ARIN have IPv6 PI! =) So feel free to ask
it (/44 is minimum, but will it be routed good - I don't know).

APNIC region (Japan and Korea): As I can see, there is PI for both IPv6
and IPv4 (http://www.apnic.net/docs/policy/add-manage-policy.html#11.1
and http://www.apnic.net/docs/policy/ipv6-address-policy.html#5.8). Same
rule: IPv4 not less than /24, IPv6 not less than /32. Contact NIR/LIRs
for details.

That's all ;)

Please, correct me where I'm wrong.

Kevin Day wrote:
> 
> I ask this partly rhetorically(I think I already know the answer) and
> partly to see which alternative everyone else would use in this situation.
> 
> Assume the following:
> 
> 1) A company has four branch offices(POPs) around the world, New York,
> London, Tokyo and Sydney.
> 2) This company requires IP addresses for internal use, customer use, etc.
> 3) Each POP must be multihomed, with connections to two or more transit
> providers.
> 4) Multihoming must support load balancing in both directions.
> 5) Each POP has a unique set of transit providers, there isn't one
> transit provider that has service at all locations.
> 6) Transit providers come and go, PA space isn't acceptable.
> 7) There is no connectivity between each POP at all, everything between
> nodes goes over the internet.
> 
> In IPv4 land, this company can obtain an /18, and announce a /20 from
> each POP.  Problem solved, all requirements are met.
> 
> 
> In IPv6, which of these methods is the "right" one?
> 
> 
> 1) Obtain a single /32, and announce it at all POPs.
> 
> Not feasible - each POP would have to have enough capacity to route
> traffic for all the others. If their Sydney office is very small,
> they're going to spend a fortune just bouncing packets back out to the
> rest of the world for any traffic that hits there over tunnels or
> dedicated lines that would otherwise be unnecessary. Inbound routing is
> going to be sub-optimal. This would also be very expensive. This isn't
> necessary at all in IPv4, it's hard to justify why IPv6 would require
> end sites to handle this level of traffic routing.
> 
> 
> 2) Obtain a single /32, and announce /34s (or /36, or /40 or whatever,
> if they want to leave room for expansion) from each POP.
> 
> Probably not possible - A lot of people are filtering on the RIR's
> allocation size. If this company is assigned a /32, there's an
> expectation (correct or not) that it's the only thing going to be
> announced.
> 
> 
> 3) Obtain a single /32, announce the /32 from each POP and announce more
> specifics (/34s or whatever) to each upstream at each POP only for that
> specific POP.
> 
> Probably not possible - If your providers are also filtering on RIR
> allocation size, they aren't going to hear your more specifics from POPs
> that they don't service. Traffic is for all POPs are going to get pulled
> to a provider that may only service one provider,
> 
> 
> 4) Obtain multiple /32s, announce one from each POP.
> 
> Probably not possible - The bar is pretty high to receive a second /32,
> most companies will never reach the utilization percentage to receive a
> second, let alone one per POP.
> 
> 
> Additional bonus semi-rhetorical questions:
> 
> * What should a company do when it requires multiple unique routing
> entries in v6 because of physical disparate networks?
> 
> * Does your solution require just as many entries in the global routing
> table as if the company deaggregated their allocation? If so, why not
> allow deaggregation where strictly needed?
> 
> * If these four offices were multiple companies instead of owned by the
> same, they'd have no problem obtaining space and announcing their own
> space at each POP. It would also equal the same number of routes in the
> table as if the one company had just deaggregated. Things are being
> complicated because they're owned by the same legal entity. One legal
> entity doesn't necessarily equal one unique network though.
> Multinational/multisite corporations are probably not going to be
> thrilled with this revelation - is this being considered acceptable damage?
> 
> 
> -- Kevin
> (not trying to troll here, just trying to see what the consensus is)
> 
> 
> 


-- 
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO)