Re: IPv6 allocations, deaggregation, etc.
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:mkorou...@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.txthttp://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?
RE: IPv6 allocations, deaggregation, etc.
-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
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. 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
RE: IPv6 allocations, deaggregation, etc.
-Original Message- From: Michael Dillon [mailto:wavetos...@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
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:mkorou...@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?
Re: IPv6 allocations, deaggregation, etc.
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
RE: IPv6 allocations, deaggregation, etc.
-Original Message- From: Nathan Ward [mailto:na...@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
Re: IPv6 allocations, deaggregation, etc.
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
Re: IPv6 allocations, deaggregation, etc.
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?
Re: IPv6 allocations, deaggregation, etc.
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
Re: IPv6 allocations, deaggregation, etc.
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.
Re: IPv6 Allocations
Esposito, Victor wrote, on 2009-10-19 16:01: Since there is a lot of conversation about IPv6 flying about, does anyone have a document or link to a good high level allocation structure for v6? See RFC 3531 and here: http://www.ipv6book.ca/allocation.html Simon -- DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: IPv6 Allocations
On 20/10/2009, at 9:01 AM, Esposito, Victor wrote: Since there is a lot of conversation about IPv6 flying about, does anyone have a document or link to a good high level allocation structure for v6? It seems there are 100 different ways to sub allocate the /32, and I am trying to find a simple but scalable method... . This discussion has been done a bunch of times. Here is my scheme, which has been adopted (sometimes with small modifications) by quite a few providers I have spoken with. http://mailman.nanog.org/pipermail/nanog/2009-August/012681.html Read the whole thread because there was a bit of confusion. -- Nathan Ward
Re: IPv6 Allocations
The tool is aware of the prefix length you insert. So instead of /32, put /64 or /48 etc. On Oct 19, 2009, at 6:22 PM, Matthew Petach wrote: On Mon, Oct 19, 2009 at 1:23 PM, Simon Perreault simon.perrea...@viagenie.ca wrote: Esposito, Victor wrote, on 2009-10-19 16:01: Since there is a lot of conversation about IPv6 flying about, does anyone have a document or link to a good high level allocation structure for v6? See RFC 3531 and here: http://www.ipv6book.ca/allocation.html Simon I'm sure I'm just dumb, but no matter what numbers I put into that tool, it only spits out a series of /32s on the HTML output. That doesn't seem terribly useful, as most of us aren't going to be allocating multiple /32s, we'll be splitting up a single /32 into smaller bits. Matt
Re: Practical numbers for IPv6 allocations
David Conrad wrote: On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed. Only APNIC is doing bisection style assignments today: 20091001|apnic|AU|ipv6|2402:c00::|32|allocated 20091001|apnic|SG|ipv6|2402:400::|32|allocated 20091005|apnic|JP|ipv6|2402:1400::|32|allocated 20091006|apnic|NZ|ipv6|2402:1c00::|32|allocated 20090930|arin|US|ipv6|2607:fd70::|32|allocated 20090930|arin|CA|ipv6|2607:fd78::|32|allocated 20091001|arin|US|ipv6|2607:fd80::|32|allocated 20091006|arin|US|ipv6|2607:fd88::|32|allocated 20091005|ripencc|RU|ipv6|2a00:1440::|32|allocated 20091005|ripencc|SI|ipv6|2a00:1448::|32|allocated 20091005|ripencc|IE|ipv6|2a00:1450::|32|allocated 20091005|ripencc|BE|ipv6|2a00:1458::|32|allocated 20090709|lacnic|PY|ipv6|2800:3a0::|32|allocated 20090714|lacnic|CL|ipv6|2800:3b0::|32|allocated 20090807|lacnic|GY|ipv6|2800:3c0::|32|allocated 20090903|lacnic|AR|ipv6|2800:3d0::|32|allocated 20090708|afrinic|GH|ipv6|2001:43c0::|32|allocated 20090729|afrinic|EG|ipv6|2001:43c8::|32|allocated 20090813|afrinic|KE|ipv6|2001:43d0::|32|allocated 20090909|afrinic|ZA|ipv6|2001:43d8::|32|allocated - Kevin
Re: Practical numbers for IPv6 allocations
FWIW - I don't believe the two arguments are in opposition/conflict ... But totally agree with your end result of /56s and /48s, with add'l bits held in reserve ... /TJ On Mon, Oct 5, 2009 at 11:39 PM, Doug Barton do...@dougbarton.us wrote: [ I normally don't say this, but please reply to the list only, thanks. ] I've been a member of the let's not assume the IPv6 space is infinite school from day 1, even though I feel like I have a pretty solid grasp of the math. Others have alluded to some of the reasons why I have concerns about this, but they mostly revolve around the concepts that the address space is not actually flat (i.e., it's going to be carved up and handed out to RIRs, LIRs, companies, individuals, etc.) and that both the people making the requests and the people doing the allocations have a WIDE (pardon the pun) variety of motivations, not all of which are centered around the greater good. I'm also concerned that the two main pillars of what I semi-jokingly refer to as the profligate school of IPv6 allocation actually conflict with one another (even if they both had valid major premises, which I don't think they do). On the one hand people say, The address space is so huge, we should allocate and assign with a 50-100 year time horizon and on the other they say, The address space is so huge, even if we screw up 2000::/3 we have 7 more bites at the apple. I DO believe that the space is large enough to make allocation policies with a long time horizon, but relying on trying again if we screw up the first time has a lot of costs that are currently undefined, and should not be assumed to be trivial. It also ignores the fact that if we reduce the pool of /3s because we do something stupid with the first one we allocate from it reduces our opportunities to do cool things with the other 7 that we haven't even thought of yet. In regards to the first of the profligate arguments, the idea that we can do anything now that will actually have even a 25 year horizon is naively optimistic at best. It ignores the day-to-day realities of corporate mergers and acquisitions, residential customers changing residences and/or ISPs, the need for PI space, etc. IPv6 is not a set it and forget it tool any more than IPv4 is because a lot of the same realities apply to it. You also have to keep in mind that even if we could come up with a theoretically perfect address allocation scheme at minimum the existing space is going to be carved up 5 ways for each of the RIRs to implement. (When I was at IANA I actually proposed dividing it along the 8 /6 boundaries, which is sort of what has happened subsequently if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to LACNIC and 2c00::/12 to AfriNIC.) Since it's not germane to NANOG I will avoid rehashing the why RA and 64-bit host IDs were bad ideas from the start argument. :) In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. As a practical matter we're stuck with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a long view into consideration. The last time I looked into this there were several ISPs in Japan who were assigning /60s to their residential users with good success. OTOH, a /56 contains 256 /64s, which is way WAY more than enough for a residential user. The idea that a residential user needs a full /48 (65,536 /64s) is absurd. OTOH, assigning a /48 to even a fairly large commercial customer is perfectly reasonable. This would give them 256 /56 networks (which would in turn have 256 /64 networks) which should be plenty to handle the problems of multiple campuses with multiple subnets, etc. So let's assume that we'll take /56 as the standard unit of assignment to residential customers, and /48 as the standard unit of assignment to commercial customers. A /32 has 65,536 /48s in it. If your business was focused mainly on commercial customers that's not a very big pool. OTOH if your business was focused primarily on residential customers you'd have 16,777,216 /56s to work with. That's enough for even a very large regional ISP. One could also easily imagine a model where out of a /32 you carve out one /34 for /56 assignments (4,194,304) and use the other 3/4ths of the space for /48s (49,152). A really large (national or even global) ISP would obviously need more space if they were going to intelligently divide up addresses on a regional basis. A /28 would have 16 /32s which should be enough for even a very large ISP, but let's really make sure that we cover the bases and go /24 (256 /32s). Even if you assume splitting that address space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s, and 8,388,608
RE: Practical numbers for IPv6 allocations
Doug Barton wrote: [ I normally don't say this, but please reply to the list only, thanks. ] I've been a member of the let's not assume the IPv6 space is infinite school from day 1, even though I feel like I have a pretty solid grasp of the math. Others have alluded to some of the reasons why I have concerns about this, but they mostly revolve around the concepts that the address space is not actually flat (i.e., it's going to be carved up and handed out to RIRs, LIRs, companies, individuals, etc.) and that both the people making the requests and the people doing the allocations have a WIDE (pardon the pun) variety of motivations, not all of which are centered around the greater good. I'm also concerned that the two main pillars of what I semi-jokingly refer to as the profligate school of IPv6 allocation actually conflict with one another (even if they both had valid major premises, which I don't think they do). On the one hand people say, The address space is so huge, we should allocate and assign with a 50-100 year time horizon and on the other they say, The address space is so huge, even if we screw up 2000::/3 we have 7 more bites at the apple. I DO believe that the space is large enough to make allocation policies with a long time horizon, but relying on trying again if we screw up the first time has a lot of costs that are currently undefined, and should not be assumed to be trivial. I agree with the point about undefined costs, but the biggest one that is easy to see is that 100-300 years from now when someone thinks about moving on to the second /3, this entire discussion will have been lost and there will be an embedded-for-generations expectation that the model is cast in stone for all of the /3's. It also ignores the fact that if we reduce the pool of /3s because we do something stupid with the first one we allocate from it reduces our opportunities to do cool things with the other 7 that we haven't even thought of yet. www.tndh.net/~tony/ietf/draft-hain-ipv6-geo-addr-00.txt shows a different way to allocate space, using only 1/16 the total space to achieve a /48 globally on a 6m grid. Other ideas will emerge, so you are correct that we can't assume we have 8 shots at this, but if the first pass is really bad the second will be so draconian in restrictions that you will never get to the third. In regards to the first of the profligate arguments, the idea that we can do anything now that will actually have even a 25 year horizon is naively optimistic at best. It ignores the day-to-day realities of corporate mergers and acquisitions, residential customers changing residences and/or ISPs, the need for PI space, etc. IPv6 is not a set it and forget it tool any more than IPv4 is because a lot of the same realities apply to it. Well mostly. It is not set forget, but a lot of the day-to-day in IPv4 is wrapped up in managing subnet sizes to 'avoid waste'. In an IPv6 environment the only concern is the total number of subnets needed to meet routing/access policy, avoiding the nonsense of continually shifting the subnet size to align with the number of endpoints over time. You also have to keep in mind that even if we could come up with a theoretically perfect address allocation scheme at minimum the existing space is going to be carved up 5 ways for each of the RIRs to implement. (When I was at IANA I actually proposed dividing it along the 8 /6 boundaries, which is sort of what has happened subsequently if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to LACNIC and 2c00::/12 to AfriNIC.) Since it's not germane to NANOG I will avoid rehashing the why RA and 64-bit host IDs were bad ideas from the start argument. :) People need to get over it... the original design was 64 bits for both hosts and routing exceeding the design goal by 10^3, then routing wanted more so it was given the whole 64 bits. The fact that 64 more bits was added is not routing's concern, but the IPv4-conservation mindset can't seem to let it go despite having 10^6 more space to work with than the target. It could have been 32 bits (resulting in a 96 bit address), but given that 64 bit processors were expected to be widespread, it makes no sense to use less than that. In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. I assume you meant 4-bit. ;) ^^^ As a practical matter we're stuck with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a long view into consideration. Stop looking backward. To achieve the home network of the last millennium a small number of subnets was appropriate. Constraining the world to that through allocation is a self-fulfilling way to
Re: Practical numbers for IPv6 allocations
Tony Hain wrote: Doug Barton wrote: In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. I assume you meant 4-bit. ;) Grrr, I hate when I do that. I spent quite a bit of time on this post, and the one time I remembered that I needed to go back and double-check what I wrote there I wasn't at the keyboard. Thanks for keeping me honest. There was one other thing you wrote that I wanted to clarify, you indicated that I was arguing for ISPs to only get one shot at an IPv6 allocation. Since my post was already really long I chose to leave out the bit about how (TMK, which could be outdated) the RIRs are reserving a bit or two for their allocations to ISPs so going back and expanding should be an easy thing to do. On a personal note, I hope that we DO need to expand IPv6 allocations to ISPs as this thing finally gets deployed. I'm not responding to the rest of your post because you and I have already had those discussions in person on more than one occasion and I know I'm not going to change your mind. I do think it's extremely gracious of you to say that my post was well reasoned though. :) Thanks to the others who had nice things to say as well. Regards, Doug
Re: Practical numbers for IPv6 allocations
On 7/10/2009, at 6:10 AM, Doug Barton wrote: Tony Hain wrote: Doug Barton wrote: In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. I assume you meant 4-bit. ;) Grrr, I hate when I do that. I spent quite a bit of time on this post, and the one time I remembered that I needed to go back and double-check what I wrote there I wasn't at the keyboard. Thanks for keeping me honest. There was one other thing you wrote that I wanted to clarify, you indicated that I was arguing for ISPs to only get one shot at an IPv6 allocation. Since my post was already really long I chose to leave out the bit about how (TMK, which could be outdated) the RIRs are reserving a bit or two for their allocations to ISPs so going back and expanding should be an easy thing to do. On a personal note, I hope that we DO need to expand IPv6 allocations to ISPs as this thing finally gets deployed. My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. -- Nathan Ward
Re: Practical numbers for IPv6 allocations
On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed. Regards, -drc
Re: Practical numbers for IPv6 allocations
On Oct 6, 2009, at 6:17 PM, David Conrad wrote: On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed. Sigh. Seem to have troubles posting coherent English to the Nanog list recently. The they in the above sentence references the RIRs except for APNIC (last I heard). Regards, -drc
Practical numbers for IPv6 allocations
[ I normally don't say this, but please reply to the list only, thanks. ] I've been a member of the let's not assume the IPv6 space is infinite school from day 1, even though I feel like I have a pretty solid grasp of the math. Others have alluded to some of the reasons why I have concerns about this, but they mostly revolve around the concepts that the address space is not actually flat (i.e., it's going to be carved up and handed out to RIRs, LIRs, companies, individuals, etc.) and that both the people making the requests and the people doing the allocations have a WIDE (pardon the pun) variety of motivations, not all of which are centered around the greater good. I'm also concerned that the two main pillars of what I semi-jokingly refer to as the profligate school of IPv6 allocation actually conflict with one another (even if they both had valid major premises, which I don't think they do). On the one hand people say, The address space is so huge, we should allocate and assign with a 50-100 year time horizon and on the other they say, The address space is so huge, even if we screw up 2000::/3 we have 7 more bites at the apple. I DO believe that the space is large enough to make allocation policies with a long time horizon, but relying on trying again if we screw up the first time has a lot of costs that are currently undefined, and should not be assumed to be trivial. It also ignores the fact that if we reduce the pool of /3s because we do something stupid with the first one we allocate from it reduces our opportunities to do cool things with the other 7 that we haven't even thought of yet. In regards to the first of the profligate arguments, the idea that we can do anything now that will actually have even a 25 year horizon is naively optimistic at best. It ignores the day-to-day realities of corporate mergers and acquisitions, residential customers changing residences and/or ISPs, the need for PI space, etc. IPv6 is not a set it and forget it tool any more than IPv4 is because a lot of the same realities apply to it. You also have to keep in mind that even if we could come up with a theoretically perfect address allocation scheme at minimum the existing space is going to be carved up 5 ways for each of the RIRs to implement. (When I was at IANA I actually proposed dividing it along the 8 /6 boundaries, which is sort of what has happened subsequently if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to LACNIC and 2c00::/12 to AfriNIC.) Since it's not germane to NANOG I will avoid rehashing the why RA and 64-bit host IDs were bad ideas from the start argument. :) In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. As a practical matter we're stuck with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a long view into consideration. The last time I looked into this there were several ISPs in Japan who were assigning /60s to their residential users with good success. OTOH, a /56 contains 256 /64s, which is way WAY more than enough for a residential user. The idea that a residential user needs a full /48 (65,536 /64s) is absurd. OTOH, assigning a /48 to even a fairly large commercial customer is perfectly reasonable. This would give them 256 /56 networks (which would in turn have 256 /64 networks) which should be plenty to handle the problems of multiple campuses with multiple subnets, etc. So let's assume that we'll take /56 as the standard unit of assignment to residential customers, and /48 as the standard unit of assignment to commercial customers. A /32 has 65,536 /48s in it. If your business was focused mainly on commercial customers that's not a very big pool. OTOH if your business was focused primarily on residential customers you'd have 16,777,216 /56s to work with. That's enough for even a very large regional ISP. One could also easily imagine a model where out of a /32 you carve out one /34 for /56 assignments (4,194,304) and use the other 3/4ths of the space for /48s (49,152). A really large (national or even global) ISP would obviously need more space if they were going to intelligently divide up addresses on a regional basis. A /28 would have 16 /32s which should be enough for even a very large ISP, but let's really make sure that we cover the bases and go /24 (256 /32s). Even if you assume splitting that address space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s, and 8,388,608 /48s. There are roughly 2,097,152 /24s in 2000::/3 (I say roughly because I'm ignoring space that's already been carved out, like 6to4, etc.), or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that yes, we really do have a lot of space to work with. I also think it means that even with a lot of space there
Re: Practical numbers for IPv6 allocations
On Mon, Oct 5, 2009 at 11:39 PM, Doug Barton do...@dougbarton.us wrote: As a practical matter we're stuck with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a long view into consideration. The last time I looked into this there were several ISPs in Japan who were assigning /60s to their residential users with good success. OTOH, a /56 contains 256 /64s, which is way WAY more than enough for a residential user. The idea that a residential user needs a full /48 (65,536 /64s) is absurd. OTOH, assigning a /48 to even a fairly large commercial customer is perfectly reasonable. This would give them 256 /56 networks (which would in turn have 256 /64 networks) which should be plenty to handle the problems of multiple campuses with multiple subnets, etc. Keep in mind that not all 'fairly large enterprises' are willing to sit at a single ISP, they may have diverse offices on diverse network provider connections. They may want the easy of saying: 'All my address blocks are in 1.2.0.0/16' and not understand (or like) that they now have to deal with wierd routing and addressing problems because they can't get a /32 and break it up into /48's all over creation (different ISP's/links/etc) or deal with the split of address space they'd get from ISP /48 PA assignments. the enterprise world has changed quite a bit from IPNG's early days... Someone who runs a large Enterprise with global office locations and who's actually deploying ipv6 internally/externally ought to give a presentation at NANOG and/or IETF. I don't disagree with the math I snipped, I do appreciate you laying it out, and I don't think that there are a super large number of folks in the scenario I layed out above. I've seen quite a few at previous employers though... -Chris
