[120571] in North American Network Operators' Group
Re: IPv6 allocations, deaggregation, etc.
daemon@ATHENA.MIT.EDU (Scott Leibrand)
Thu Dec 24 15:38:16 2009
Date: Thu, 24 Dec 2009 12:37:13 -0800
From: Scott Leibrand <scottleibrand@gmail.com>
To: nanog@nanog.org
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7107@RWC-EX1.corp.seven.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 12/23/2009 12:31 AM, George Bonser wrote:
> Apologies in advance for the top post.
> =20
Likewise. These are general comments, though, so I don't feel too=20
badly... :-)
It sounds like you're on the right track. You discovered the 2009-5=20
Multiple Discrete Networks draft policy, which should allow you a=20
separate /48 for each discrete network. That is somewhat orthogonal to=20
the question of whether you should get separate resources from each RIR=20
whose region you operate a network in. If the networks on different=20
continents are discrete, I think the answer there is yes.
I'll also point out another resource for discussing topics like this,=20
particularly if it appears that a change in policy would be needed to=20
accommodate your needs: ARIN's Public Policy Mailing List (PPML),=20
https://www.arin.net/participate/mailing_lists/index.html. That's where =
2009-5 came from, and I know there are still some needs unmet by current =
ARIN IPv6 address policy, so we're always looking for more good ideas,=20
and feedback on the ones being discussed. At the moment, there are some =
very interesting discussions ongoing about how to rewrite ARIN IPv6=20
address policy to simplify it while making provider independent=20
addressing more widely available and making it easier to filter traffic=20
engineering deaggregates without accidentally filtering multihomed=20
networks. And on the IPv4 side, there are two policy proposals on the=20
docket to lower ARIN's minimum allocation size to /23 or /24.
I encourage anyone on this list who's interested in these topics to=20
browse the PPML archives, look over the full list of active draft=20
policies and policy proposals at https://www.arin.net/policy/proposals/, =
and subscribe to PPML. We need all the input we can get.
Thanks,
Scott Leibrand
elected volunteer member of the ARIN Advisory Council, but speaking only =
for myself
>
>
> My initial idea was to use a /48, divide it up into /56 nets for each f=
acility with /64 subnets within each facility. We would announce a /48 t=
o our transit providers that I would expect them to announce in turn to t=
heir peers and we would also announce the more specific /56 nets to the t=
ransit providers that I would expect them not to announce to their peers.=
My current vlan requirements per facility would support such an address=
ing plan. In order to make that work, we would need the same transit pro=
viders in each region as our locations are not meshed internally. We don=
=E2=80=99t have dedicated connectivity from the US to the UK or China, fo=
r example. Currently that is not a problem as far as connectivity is con=
cerned as my US providers appear in Europe and my China provider appears =
in the US. BUT when I consider the possibilities of South America and Afr=
ica and finding a transit provider that has a robust presence everywhere,=
my choices are very limited. I need to be multihomed and I need to be p=
rovider agnostic in my addressing.
>
>
>
> Using that scheme above does create some potential performance issues. =
While my transit provider collects the traffic from a remote location and=
routes it to the more specific location in my network, If a provider in =
Europe, for example, sees only the /48 announced from the US, maybe they =
haul the traffic across an ocean to a point where they peer with my provi=
der =E2=80=A6 who then must haul it back to Europe to the /56 correspondi=
ng to the destination because the original traffic source doesn=E2=80=99t=
see my /56 unless they are using the same transit provider I am.
>
>
>
> Then based on earlier discussion on the list a while back, I was concer=
ned that a /48 wasn=E2=80=99t even enough to get me connected to some net=
s that were apparently filtering smaller than a /48 but my mind is somewh=
at eased in that respect and I believe that a /48 announced from space wh=
ere /48s are issued will be accepted by most people.
>
>
>
> Then I was informed of ARIN 2009-5 which seems aimed at our situation; =
data centers widely separated by large geographical distances that are fa=
irly autonomous and aren=E2=80=99t directly connected by dedicated links.=
It now seems that we (and the rest of the Internet) might be better ser=
ved if we get a RIPE AS and net block for our Europe operations, and APNI=
C AS and net block for our APAC operations and get a regional /48 that I =
can split into /56 nets for the various satellite facilities within that =
region as those satellite offices CAN be directly connected to the region=
al data center which would act as the regional communications hub.
>
>
>
> There are probably 16 different ways to slice this but I would like to =
get it as close to =E2=80=9Cright=E2=80=9D as possible to prevent us havi=
ng to renumber later while at the same time not taking more space than we=
need. A /48 per region seems like the right way to go at the present ti=
me. So we would have a /48 for the US, a /48 for Asia (and possibly one =
/48 dedicated to China) and a /48 for Europe. Satellite facilities would=
collect a /56 (or two or three) out of that regional block for their loc=
al use. Then I am free from being nailed to the same providers globally =
and have less chance of traffic crossing an ocean twice.
>
>
>
> The probability of needing 200 /48s in the next several years is pretty=
slim and do not warrant our getting a /32 when currently three or four =
/48 nets will fill the requirements.
>
>
>
> Thanks again for the input, Mick.
>
>
>
> George
>
>
>
>
>
> From: Mick O'Rourke [mailto:mkorourke@gmail.com]
> Sent: Tuesday, December 22, 2009 10:43 PM
> To: Joel Jaeggli
> Cc: George Bonser; nanog@nanog.org
> Subject: Re: IPv6 allocations, deaggregation, etc.
>
>
>
> Is the idea behind the /48 being looked at (keeping in mind a mixed IPv=
4/IPv6 environment& http://www.ietf.org/rfc/rfc5375.txt<http://www.ietf.=
org/rfc/rfc5375.txt%20> page 8) to have a /64 per smaller branch or VLAN=
, larger campus /56, and advertise out the /48 for the region?; My previo=
us thinking and biggest thinking point is enterprise level address alloca=
tion policy, impacts to device loopbacks, voice vlans, operational simpli=
fication requirements for management and security layers etc. The feel ov=
erall has been towards needing to have a /32, a /56 per site (campus to s=
mall branch) and internally within the site /64 per VLAN. A /48 becomes t=
oo small, a /32 very much borderline. Is this a similar scenario for you?=
How are you justifying a /48 vs a /32?
>
> =20
