IPv6 allocations, deaggregation, etc.
We have decided to initiate the process of becoming IPv6 capable. We have requested and received a block of addresses which, after reading some of the discussion here, I fear may be too small to suit our needs (a /48). To better understand how to proceed and in an attempt to get it right (or close to right) the first time, I am soliciting opinions and comments from other network operators. It appears from earlier discussions on this list that while many networks will not filter a /48 announcement in their routing tables, others will. We have data centers and offices in three regions of the globe; North America, Europe, and Asia/Pacific. We are also multihomed as well as having some direct peering. I can break my /48 into /56 nets for each facility. My thought process here being that if I have the same transit providers at all sites, I can announce the /48 from my primary location and that would get announced by the transit provider. They would also accept my more specific routes but not announce them outside of their AS. So traffic originating outside of my transit provider would flow toward them following the /48 and they then move the traffic to the final destination based on the more specific and in the case the traffic has no more specific route, hand the traffic to my main location for me to sort out or just black hole it. There are two problems with this approach. 1: We are unreachable from anyone filtering a /48 and 2: I could see a situation where traffic crosses the Pacific, is handed to my transit provider, and then crosses the Pacific again to get to the destination resulting in poor performance. So it now seems to me that maybe a larger block might be the best answer but being an "end user" the policies seem pretty restrictive on getting a /32 though I might qualify for several /48 blocks (at least one in each registry region). So how does one reconcile having a diverse, multihomed organization on several continents while at the same time trying to do the right thing, not requesting more resources than we need, and trying to be friendly to the various networks' operations by advertizing only what we need to? Is it unreasonable to get separate /48 blocks for operations in Europe, North America, and Asia or possibly two for Asia (one in China and one for Asia outside of China)? While that still won't help us with connectivity from networks filtering /48's, it might relieve much of the back and forth transit across oceans to get traffic originating from and destined for the same continent to stay there. I don't have a problem with regional backhaul tying an office /56 to a data center announcing a /48 and using that data center as a communications hub for the region. It also assumes a transit provider I am paying to haul my traffic will take "more specifics" for internal use even if they aren't advertizing them. I am just trying to minimize the stupidity and barriers to scale on my side of the equation.
The assumption that networks will filter /48s is not the whole story. The RIRs giving out /48s do so from a single pool that only contains / 48 assignments. The RIRs give out /32s from a pool containing /32 or shorter prefixes (ie /31, /30, etc. etc). You will find that most networks filtering /48s allow them from the pool with only /48s in it. The root DNS servers are in /48s. If you can justify getting a /32, then I suggest you do so, but if not then don't worry, a /48 will work just fine. The networks that do filter you will pretty soon adapt I expect. Insert routing table explosion religious war here, with snipes from people saying that we need a new routing system, etc. etc. So with that in mind, do your concerns from your original post still make sense? -- Nathan Ward
-----Original Message----- From: Nathan Ward [mailto:nanog@daork.net] Sent: Tuesday, December 22, 2009 6:34 PM To: nanog@nanog.org Subject: Re: IPv6 allocations, deaggregation, etc.
The assumption that networks will filter /48s is not the whole story. ... You will find that most networks filtering /48s allow them from the pool with only /48s in it.
That makes perfect sense.
If you can justify getting a /32, then I suggest you do so, but if not then don't worry, a /48 will work just fine. The networks that do filter you will pretty soon adapt I expect.
I can't in good conscience justify a /32. That is just too much space. I believe I can, however, justify a separate /48 in Europe and APAC with my various offices and data centers in that region coming from the /48 for that region.
Insert routing table explosion religious war here, with snipes from people saying that we need a new routing system, etc. etc.
Eh, it isn't so bad. I could think of some ways things could have been better (e.g. providers use a 32bit ASN as the prefix with a few "magic" destination prefixes for multicast, anycast, futurecast and multihomed end users use a 16-bit regional prefix with a 16-bit ASN as a 32-bit prefix) but we are too far down the road to complain too much about that sort of stuff.
So with that in mind, do your concerns from your original post still make sense?
Thanks, Nathan, and let's say that I am somewhat less apprehensive than I was. George
On 23/12/2009, at 3:52 PM, George Bonser wrote:
If you can justify getting a /32, then I suggest you do so, but if not then don't worry, a /48 will work just fine. The networks that do filter you will pretty soon adapt I expect.
I can't in good conscience justify a /32. That is just too much space. I believe I can, however, justify a separate /48 in Europe and APAC with my various offices and data centers in that region coming from the /48 for that region.
I'm not sure it's about good conscience and worrying about address space wastage anymore. I mean sure, don't go ask for a /8 or something, but follow the RIR guidelines - don't paint yourself in to a corner later by trying to save the world now. If you are assigning addresses to customers, you should have a /32 allocation. If you are an end user of addresses, you should have a /48 portable assignment. In APNIC world anyway, I'm not sure of the terms and policies used in other regions. -- Nathan Ward
I can't in good conscience justify a /32. That is just too much space.
Then you need to go back to IPv6 101.
I believe I can, however, justify a separate /48 in Europe and APAC with my various offices and data centers in that region coming from the /48 for that region.
A /48 is for a single site. If you are operating a network connecting many sites, then you are a network operator and should get a /32 block. Don't try to fit more into a /48 than one single site. If you need to announce /33 or /34 prefixes to make things work, then deal with it. Talk to providers and explain what is going on. IPv6 routing is in its infancy and many people tend to set it up and let it run on autopilot. There is no law saying that you must announce one and only one /32 aggregate everywhere. For real technical solutions to your problem, you are probably better off going to the IPv6-ops list Subscription info is here <http://lists.cluenet.de/mailman/listinfo/ipv6-ops> --Michael Dillon --Michael Dillon
-----Original Message----- From: Michael Dillon [mailto:wavetossed@googlemail.com] Sent: Thursday, December 24, 2009 4:11 PM To: nanog@nanog.org Subject: Re: IPv6 allocations, deaggregation, etc.
I can't in good conscience justify a /32. That is just too much space.
Then you need to go back to IPv6 101.
This is an end user application, not an ISP application. Something between a /32 and a /48 would suffice. The idea was that a /32 is too large (in my opinion) for an organization that isn't planning on having more than 20 sites in the next 5 years. If it were 200, that would be a different story. If having a block smaller than a /32 breaks something, then it needs to break early so it can be addressed before things progress much further. And getting a /32 would appear to violate ARIN's policy: 6.5.8.2. Initial assignment size Organizations that meet the direct assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. An HD-Ratio of .94 must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. If we were to number all sites globally into a /45, we could meet the .94 HD-Ratio but with the potential problems noted in earlier traffic on this thread. I am now leaning toward expanding my request to a /45 if we go with a global block or a /46 if we go with only using ARIN allocations in North American operations.
Don't try to fit more into a /48 than one single site.
Yeah, I think I pretty much "get" that, at this point. I can hang small offices off of a data center, giving them one or more /56 nets each but yeah, trying to split a /48 between data centers is probably counter-productive.
If you need to announce /33 or /34 prefixes to make things work, then deal with it. Talk to providers and explain what is going on. IPv6 routing is in its infancy and many people tend to set it up and let it run on autopilot. There is no law saying that you must announce one and only one /32 aggregate everywhere.
Agreed. Wasn't planning on it but if we did eventually become fully integrated globally, I would probably announce the larger aggregate(s) out of one main location, maybe handing any unassigned traffic to a honey-net or something. At least if a mistake is made somewhere in addressing, that would give me a "backstop" so that we could provide a temporary fix for the problem quickly until it got fixed correctly. If someone misconfigures something and traffic goes out with the wrong subnet SA but still in our block (say someone transposes a couple of subnet digits someplace), at least the reply traffic would come back to someplace I have some control over and could route (or tunnel) the reply traffic back to where it needs to go until the root cause could be fixed. It would be ugly and slow for a while but it wouldn't be completely broken until a maintenance window where we could correct the underlying problem. Things like that offers an opportunity to fix emergencies quickly and schedule more disruptive corrective actions for a later time when people can plan for the outage. It is yet another advantage of having a larger global block over a gaggle of smaller scattered blocks.
For real technical solutions to your problem, you are probably better off going to the IPv6-ops list
Signed up yesterday :)
--Michael Dillon
Thanks, Michael. George
I'm not an expert, but can/should you advertise ARIN IP space on APNIC or RIPE, etc ? You are talking about having recieved ip space from ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of form than anything else though..... On Tuesday, December 22, 2009, Nathan Ward <nanog@daork.net> wrote:
The assumption that networks will filter /48s is not the whole story.
The RIRs giving out /48s do so from a single pool that only contains /48 assignments. The RIRs give out /32s from a pool containing /32 or shorter prefixes (ie /31, /30, etc. etc).
You will find that most networks filtering /48s allow them from the pool with only /48s in it.
The root DNS servers are in /48s.
If you can justify getting a /32, then I suggest you do so, but if not then don't worry, a /48 will work just fine. The networks that do filter you will pretty soon adapt I expect.
Insert routing table explosion religious war here, with snipes from people saying that we need a new routing system, etc. etc.
So with that in mind, do your concerns from your original post still make sense?
-- Nathan Ward
I'm not an expert, but can/should you advertise ARIN IP space on APNIC or RIPE, etc ? You are talking about having recieved ip space from ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of form than anything else though.....
This happens all the time with IPv4 space and AS #'s today, why would it be any different with v6?
On 23/12/2009, at 4:04 PM, Shane Ronan wrote:
I'm not an expert, but can/should you advertise ARIN IP space on APNIC or RIPE, etc ? You are talking about having recieved ip space from ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of form than anything else though.....
This happens all the time with IPv4 space and AS #'s today, why would it be any different with v6?
It's not. -- Nathan Ward
-----Original Message----- From: eric clark
I'm not an expert, but can/should you advertise ARIN IP space on APNIC or RIPE, etc ? You are talking about having recieved ip space from ARIN, tied to an ARIN AS.... I suppose it's probably more a matter of form than anything else though.....
That is what prompted me to say that I could probably justify a /48 in each region out of that region's registry. We have legitimate business operations in those regions so having an AS and IP block for those regions should not only be justifiable but also would tend to make things "cleaner".
George Bonser wrote:
We have decided to initiate the process of becoming IPv6 capable. We have requested and received a block of addresses which, after reading some of the discussion here, I fear may be too small to suit our needs (a /48). To better understand how to proceed and in an attempt to get it right (or close to right) the first time, I am soliciting opinions and comments from other network operators.
Given you topology your direct assignment request should properly reflect the number of sites you expect to need to need to serve. At a /48 per site it starts to look rational.
It appears from earlier discussions on this list that while many networks will not filter a /48 announcement in their routing tables, others will. We have data centers and offices in three regions of the globe; North America, Europe, and Asia/Pacific. We are also multihomed as well as having some direct peering. I can break my /48 into /56 nets for each facility. My thought process here being that if I have the same transit providers at all sites, I can announce the /48 from my primary location and that would get announced by the transit provider. They would also accept my more specific routes but not announce them outside of their AS. So traffic originating outside of my transit provider would flow toward them following the /48 and they then move the traffic to the final destination based on the more specific and in the case the traffic has no more specific route, hand the traffic to my main location for me to sort out or just black hole it. There are two problems with this approach. 1: We are unreachable from anyone filtering a /48 and 2: I could see a situation where traffic crosses the Pacific, is handed to my transit provider, and then crosses the Pacific again to get to the destination resulting in poor performance.
So it now seems to me that maybe a larger block might be the best answer but being an "end user" the policies seem pretty restrictive on getting a /32 though I might qualify for several /48 blocks (at least one in each registry region). So how does one reconcile having a diverse, multihomed organization on several continents while at the same time trying to do the right thing, not requesting more resources than we need, and trying to be friendly to the various networks' operations by advertizing only what we need to? Is it unreasonable to get separate /48 blocks for operations in Europe, North America, and Asia or possibly two for Asia (one in China and one for Asia outside of China)? While that still won't help us with connectivity from networks filtering /48's, it might relieve much of the back and forth transit across oceans to get traffic originating from and destined for the same continent to stay there. I don't have a problem with regional backhaul tying an office /56 to a data center announcing a /48 and using that data center as a communications hub for the region. It also assumes a transit provider I am paying to haul my traffic will take "more specifics" for internal use even if they aren't advertizing them.
I am just trying to minimize the stupidity and barriers to scale on my side of the equation.
participants (6)
-
eric clark -
George Bonser -
Joel Jaeggli -
Michael Dillon -
Nathan Ward -
Shane Ronan