RE: IPv6 allocations, deaggregation, etc.
Apologies in advance for the top post. My initial idea was to use a /48, divide it up into /56 nets for each facility with /64 subnets within each facility. We would announce a /48 to our transit providers that I would expect them to announce in turn to their peers and we would also announce the more specific /56 nets to the transit providers that I would expect them not to announce to their peers. My current vlan requirements per facility would support such an addressing plan. In order to make that work, we would need the same transit providers in each region as our locations are not meshed internally. We don’t have dedicated connectivity from the US to the UK or China, for example. Currently that is not a problem as far as connectivity is concerned 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 Africa 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 provider 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 provider … who then must haul it back to Europe to the /56 corresponding to the destination because the original traffic source doesn’t 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 concerned that a /48 wasn’t even enough to get me connected to some nets that were apparently filtering smaller than a /48 but my mind is somewhat eased in that respect and I believe that a /48 announced from space where /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 fairly autonomous and aren’t directly connected by dedicated links. It now seems that we (and the rest of the Internet) might be better served if we get a RIPE AS and net block for our Europe operations, and APNIC 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 regional 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 “right” as possible to prevent us having 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 time. 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 local 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 IPv4/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 previous thinking and biggest thinking point is enterprise level address allocation policy, impacts to device loopbacks, voice vlans, operational simplification requirements for management and security layers etc. The feel overall has been towards needing to have a /32, a /56 per site (campus to small branch) and internally within the site /64 per VLAN. A /48 becomes too small, a /32 very much borderline. Is this a similar scenario for you? How are you justifying a /48 vs a /32?
On 12/23/2009 12:31 AM, George Bonser wrote:
Apologies in advance for the top post.
Likewise. These are general comments, though, so I don't feel too badly... :-) It sounds like you're on the right track. You discovered the 2009-5 Multiple Discrete Networks draft policy, which should allow you a separate /48 for each discrete network. That is somewhat orthogonal to the question of whether you should get separate resources from each RIR whose region you operate a network in. If the networks on different continents are discrete, I think the answer there is yes. I'll also point out another resource for discussing topics like this, particularly if it appears that a change in policy would be needed to accommodate your needs: ARIN's Public Policy Mailing List (PPML), 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, and feedback on the ones being discussed. At the moment, there are some very interesting discussions ongoing about how to rewrite ARIN IPv6 address policy to simplify it while making provider independent addressing more widely available and making it easier to filter traffic engineering deaggregates without accidentally filtering multihomed networks. And on the IPv4 side, there are two policy proposals on the 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 browse the PPML archives, look over the full list of active draft 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 facility with /64 subnets within each facility. We would announce a /48 to our transit providers that I would expect them to announce in turn to their peers and we would also announce the more specific /56 nets to the transit providers that I would expect them not to announce to their peers. My current vlan requirements per facility would support such an addressing plan. In order to make that work, we would need the same transit providers in each region as our locations are not meshed internally. We don’t have dedicated connectivity from the US to the UK or China, for example. Currently that is not a problem as far as connectivity is concerned 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 Africa 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 provider 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 provider … who then must haul it back to Europe to the /56 corresponding to the destination because the original traffic source doesn’t 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 concerned that a /48 wasn’t even enough to get me connected to some nets that were apparently filtering smaller than a /48 but my mind is somewhat eased in that respect and I believe that a /48 announced from space where /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 fairly autonomous and aren’t directly connected by dedicated links. It now seems that we (and the rest of the Internet) might be better served if we get a RIPE AS and net block for our Europe operations, and APNIC 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 regional 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 “right” as possible to prevent us having 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 time. 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 local 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 IPv4/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 previous thinking and biggest thinking point is enterprise level address allocation policy, impacts to device loopbacks, voice vlans, operational simplification requirements for management and security layers etc. The feel overall has been towards needing to have a /32, a /56 per site (campus to small branch) and internally within the site /64 per VLAN. A /48 becomes too small, a /32 very much borderline. Is this a similar scenario for you? How are you justifying a /48 vs a /32?
-----Original Message----- From: Scott Leibrand
It sounds like you're on the right track. You discovered the 2009-5 Multiple Discrete Networks draft policy, which should allow you a separate /48 for each discrete network. That is somewhat orthogonal to the question of whether you should get separate resources from each RIR whose region you operate a network in. If the networks on different continents are discrete, I think the answer there is yes.
The extent to which they are discrete is really more of a function of the partners those networks serve when it comes to the data centers. While most of our partners are regional, that is more by happenstance than by design and I see it changing over time as more of them operate outside of their "home" region. I also want to ensure a design that allows us to serve anyone from anywhere which further "fuzzes" how discrete each potentially is. And this is actually the part where I am having the most trouble sorting the best practice. There are some advantages to doing it either way. I could get a /45 to handle everything. Having a /45 would allow me to aggregate /48s where practical while obtaining individual /48 networks would not guarantee they would be in any sort of contiguous space and not likely allow me to aggregate them even where physically possible to do so. One possible problem of using a US block globally is that someone might see a source address from me and assume it is originating in the US if they are using some sort of geolocation in order to direct service. That might cause me to be directed to a sub-optimal service portal depending on who I am communicating with. Getting blocks from the regions served seems to be the way that will cause less of a problem overall at the cost of ability to aggregate the blocks should the entire network become fully physically integrated at some point in the future.
I'll also point out another resource for discussing topics like this, particularly if it appears that a change in policy would be needed to accommodate your needs: ARIN's Public Policy Mailing List (PPML), https://www.arin.net/participate/mailing_lists/index.html
Thanks for the pointer, Scott, I will have a look. George
participants (2)
-
George Bonser -
Scott Leibrand