Hello,
Please advice what is the best practice to use IPv6 address block
across distributed locations.
Recently we obtained our PI /48 from RIPE. The idea was to assign
partial slices from this block to different locations (we have
currently 3 offices in Europe and 2 in USA). All locations are
interconnected with static VPNs. Each location is supposed to
establish BGP session with local ISP. Partial prefix /56 + aggregate
/48 (with long AS PATH) are to be announced by each office.
The problem we ran across is that ISP in US does not wish to accept
prefixes longer then /48 from us.
Need your advice: is this normal to distribute /48 by /56 parts across
locations or should we obtain separate /48 for each of them? Or maybe
we need /32 that can be split into multiple /48? Anyway we are not ISP
so /48 looks quite reasonable and sufficient for all our needs.
Thank you.
Dmitry Cherkasov
Don't expect anyone to accept less than /48, so in your setup you need a /48 per site.
Couldn't you also advertise the /48 from all the sites, if you're
willing to sort things out over the inter-site VPNs?--Richard
You go to multiple RIRs and get multiple prefixes.
Heck, you apparently can even get multiple disjunct prefixes from the
same RIR.
There went the whole idea of aggregation....
Greets,
Jeroen
(Note though that some entities who actually got disjunct prefixes are
quite large and will be putting quite a number of hosts behind those
prefixes, thus the usage/prefix ratio is quite high and likely worthy of
a routing slot)
Not sure about RIPE, but under ARIN, you would qualify for a /44 (or larger if you have more than 12 sites), out of which you could announce the /48s independently and as an aggregate, as you wish to do.
-Randy
Ideally, you should put a /48 at each location.
Owen
Think of a /48 the same way you'd use a /24 of IPv4 space in a multi-homed design. /48 is the smallest v6 block that you can reasonably expect to be globally reachable. Many providers will not accept anything smaller, unless it's from one of their own blocks, in which case it will likely get aggregated into their larger prefix.
jms
Speaking from my experience with getting v6 space from ARIN earlier this year, as long as your documentation is in pretty good order, a /48 per site is pretty easy to get.
I don't know if the experience is different with other RIRs.
jms
Ideally, you should put a /48 at each location.
Owen
Hello,
Please advice what is the best practice to use IPv6 address block
across distributed locations.
Recently we obtained our PI /48 from RIPE. The idea was to assign
partial slices from this block to different locations (we have
currently 3 offices in Europe and 2 in USA). All locations are
interconnected with static VPNs. Each location is supposed to
establish BGP session with local ISP. Partial prefix /56 + aggregate
/48 (with long AS PATH) are to be announced by each office.
The problem we ran across is that ISP in US does not wish to accept
prefixes longer then /48 from us.
Need your advice: is this normal to distribute /48 by /56 parts across
locations or should we obtain separate /48 for each of them? Or maybe
we need /32 that can be split into multiple /48? Anyway we are not ISP
so /48 looks quite reasonable and sufficient for all our needs.
It's not because it can't be de-aggregated further in general. if you
have 5 discreet site you really need at /45. if you can tthe
announcements of the regions to something less specific than a /48 e.g.
a /46 then by all means do so.
Hello,
Please advice what is the best practice to use IPv6 address block
across distributed locations.
You go to multiple RIRs and get multiple prefixes.
Heck, you apparently can even get multiple disjunct prefixes from the
same RIR.
There went the whole idea of aggregation....
or you could just get an aggregateable block of the appropiate size from
one RIR and deaggregate it as necessary which should be the normal
course of action...
One important question: if data for one of your locations were to be sent
from somewhere that is closer (as the packets fly) to another, would you
prefer that it be sent over your VPN or over the open Internet? The latter
may be cheaper for you, since you don't have to pay for that bandwidth; the
former may be more secure if your VPN is encrypted.
To send stuff only over the open Internet in this situation, use a separate
/48 for each location. To send stuff only over your VPN, put everything in
a single /44 or so and advertise only it. Advertising the /44 and having
each location advertising its own /48 within that /44 will usually cause the
traffic to go over the open Internet, with your VPN as backup in case of
reachability problems if some ISPs won't carry the longer /48s because of their
own policies.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
If we're talking about a site-to-site IPsec VPN "over the internet", then that's a very bad idea. Even if "the internet" in this case is entirely within the same provider's network. (and it doesn't sound like it is.)
--Ricky
Thanks to everybody who responded.
To summarize it all, these are the guides for non-ISP company to use
PI IPv6 addresses:
case 1: single POP, no plans to have more
- get single /48 from your RIR, announce it to one or multiple ISPs
that POP is connected to
case 1a: multiple separate POPs (no VPN interconnections)
- the same as for case 1 but for each POP independently; each POP has
individual AS, btw
case 2: extranet like multiple POPs interconnected with VPNs
- get greater then /48 block (like /44) so each POP gets its /48 part
- each POP announces its corresponding /48 prefix to their local ISPs
- decide if you wish that traffic from Internet to some POP passes
through some other of your POPs (security or other considerations); if
this is desirable you may announce the whole aggregate (like /44)
additionally to /48 from all or some of the POPs; optionally you may
wish to announce /44 with community 'no-export'
As for /48 IPv6 blocks being like /24 for IPv4.
It really seems that /48 may be the most popular PI block and this may
lead to overcrowding of DFZ. Probably, this is logical consequence of
getting bigger address space. We needed more IP addresses and we get
them. Anyway getting greater then /48 just because you do not want to
pollute DFZ is not justified.
Thank you.
Dmitry Cherkasov
You really don't need to tag the larger block with no-export. In fact,
if the POPs are suitably interconnected on the back end, you really
don't need to advertise the /48s all, and just advertise the /44. Depending on your upstreams, you might be able to tag your advertisements with certain BGP communities (will vary from provider to provider) to give you some degree of conrol over traffic distribution.
Getting back to the original point, unless someone does something odd with their BGP views, the /48s will be preferred because they're smaller (more specific), and the /44 would only be used if a corresponding /48 prefix doesn't exist in their BGP view.
jms
As for /48 IPv6 blocks being like /24 for IPv4.
It really seems that /48 may be the most popular PI block and this may
lead to overcrowding of DFZ. Probably, this is logical consequence of
getting bigger address space. We needed more IP addresses and we get
them. Anyway getting greater then /48 just because you do not want to
pollute DFZ is not justified.
I agree with you except this last statement.
If you have a need for more than a /48 and you can announce the aggregate
and not the more specifics, it is perfectly valid to get more than a /48 and
you should do so in a way that allows you to announce only the aggregate
so as to avoid polluting the DFZ.
DFZ pollution is not about prefix size, it is about the number of prefixes.
In all cases, one should attempt to implement the minimum number of prefixes
necessary to effect your desired (or needed) routing policy.
Prefix size, OTOH, should relate to the number of end-sites served where
each end-site gets a /48.
Owen
In fact, if you have one or more providers which, in common, serve
multiple POPs, it may be desirable to tag the more specifics (/48s)
as no-export and leave the /44s exportable.
In this way, you can avoid unnecessary DFZ pollution.
Owen
My take on the issue is that your providers are wise in not wanting to
accept prefixes longer than /48s.
You should get multiple prefixes, from the same or different RIRs. If
there are policies in place which do not allow you to do so, I think
it's a good time to discuss them.
regards
Carlos
Same from LACNIC. This would have justify a /44 or separate /48s for each site.
/as