I understand the problems but I think there are clear cut cases where /48's make sense- a large scale anycast DNS provider would seem to be a good candidate for a /48 and I would hope it would get routed. Then again that might be the only sensible reason...
Don't give people an excuse to deagg their /32 RIPE may only give out /32's but ARIN gives out /48's so there wouldn't be any deaggregation in that case.
That's not what I said. If /48 are accepted by * then people with a /32 or whatever will deagg to /48. How much and why they deagg will vary but *hand waving argument* it'll be a lot more pressure on routing table size than people doing PI You get one shot at fixed prefix size filters, miss and you'll pay forever. Which is more scarce, /32's or routing table entries. brandon
Don't give people an excuse to deagg their /32 RIPE may only give out /32's but ARIN gives out /48's so there wouldn't be any deaggregation in that case.
That's not what I said. If /48 are accepted by * then people with a /32 or whatever will deagg to /48. I understand now that you were referring strictly to filter limits- I misinterpreted you original post. My apologies.
Obviously you don't need to accept /48's from anywhere- you can restrict it to the PI pool- then /32's don't deaggregate but networks approved by ARIN or RIPE or whomever still work.
You get one shot at fixed prefix size filters, miss and you'll pay forever. Which is more scarce, /32's or routing table entries. If we start giving out /32's to work around filters I'm not sure that solves any problems :) And if no one is going to honor a /48 then why bother to give them out?
-Don
On Tue, May 29, 2007 at 06:14:51PM +0100, Brandon Butterworth wrote:
You get one shot at fixed prefix size filters, miss and you'll pay forever. Which is more scarce, /32's or routing table entries.
your first lema is false. and RTE are more scarce.
brandon
let me ask you two questions: ... how many /32's are there? ... how many of them will you allow in your routing table? and a bonus question: ... what are your criteria for rejecting a given /32? --bill
bmanning@karoshi.com wrote:
On Tue, May 29, 2007 at 06:14:51PM +0100, Brandon Butterworth wrote:
You get one shot at fixed prefix size filters, miss and you'll pay forever. Which is more scarce, /32's or routing table entries.
your first lema is false. and RTE are more scarce.
brandon
let me ask you two questions: ... how many /32's are there?
The same number as there are /32s in ipv4, also the same number as there are AS numbers which has a certain nice congruency to it...
... how many of them will you allow in your routing table?
Hopefully not all of them by tomorrow.
and a bonus question: ... what are your criteria for rejecting a given /32?
--bill
Thus spake "Brandon Butterworth" <brandon@rd.bbc.co.uk>
Don't give people an excuse to deagg their /32
RIPE may only give out /32's but ARIN gives out /48's so there wouldn't be any deaggregation in that case.
That's not what I said. If /48 are accepted by * then people with a /32 or whatever will deagg to /48.
The general rule, for both v4 and v6, is that people should filter on whatever the minimum allocation/assignment size for each RIR block. It's also been suggested that you accept a few more bits for routes with a short AS_PATH length to help with TE, but that's optional. Someone recently posted a link (either on PPML or here -- I can't find it now) that showed ARIN's minima for the various v4 and v6 blocks. The v4 ones were all over the map, but there are relatively few v6 blocks and all of them are /32 except for one that's /48. The upside is that in the block you're expected to accept /48s, nobody will have a /32. The downside is that anyone who gets a larger-than-minimum sized allocation/assignment can deaggregate down to that level. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
The upside is that in the block you're expected to accept /48s, nobody will have a /32. The downside is that anyone who gets a larger-than-minimum sized allocation/assignment can deaggregate down to that level. I don't think ARIN is planning on giving out more less a /48 but more than a /32- at least that was the impression I got. End sites get a /48- ISP's get a /32 or larger- and that's it (I could certainly be wrong). As such, deaggragation in the /48 block should not be an issue because no one will have more than a /48 in the first place.
-Don
On May 31, 2007, at 8:03 AM, Donald Stahl wrote:
The upside is that in the block you're expected to accept /48s, nobody will have a /32. The downside is that anyone who gets a larger-than-minimum sized allocation/assignment can deaggregate down to that level. I don't think ARIN is planning on giving out more less a /48 but more than a /32- at least that was the impression I got. End sites get a /48- ISP's get a /32 or larger- and that's it (I could certainly be wrong). As such, deaggragation in the /48 block should not be an issue because no one will have more than a /48 in the first place.
-Don
Yes, you can get a prefix between /32 and /48 if you can justify it. That is certainly in line with the policy which resulted from proposal 2005-1. Owen
I don't think ARIN is planning on giving out more less a /48 but more than a /32- at least that was the impression I got. End sites get a /48- ISP's get a /32 or larger- and that's it (I could certainly be wrong). As such, deaggragation in the /48 block should not be an issue because no one will have more than a /48 in the first place.
Yes, you can get a prefix between /32 and /48 if you can justify it. That is certainly in line with the policy which resulted from proposal 2005-1. You are of course correct- I misread "The minimum assignment size is /48" in terms of prefix length (ie minimum of /48- could be /56, etc.) which is not what was meant. The very next sentence should have clarified that for me but I probably skipped over it. mea culpa.
I'm looking forward to seeing a realistic justification from an end user for more than a /48 :) As an aside- what is the address block for PI end user assignments from ARIN? (I can't seem to find it and 2005-1 only mentions a "distinctly identified prefix" without any mention of what that would be). The Microallocation blocks are: Internal Infrastructure: 2001:0506::/31 Exchange Points: 2001:0504::/31 Critical Infrastructure: 2001:0500::/30 (all of which are /48's so far). But I see no mention of end-user assignments (unless they fall into one of the above categories- though I don't see how). -Don
Thus spake "Donald Stahl" <don@calis.blacksun.org>
The upside is that in the block you're expected to accept /48s, nobody will have a /32. The downside is that anyone who gets a larger-than-minimum sized allocation/assignment can deaggregate down to that level.
I don't think ARIN is planning on giving out more less a /48 but more than a /32- at least that was the impression I got. End sites get a /48- ISP's get a /32 or larger- and that's it (I could certainly be wrong). As such, deaggragation in the /48 block should not be an issue because no one will have more than a /48 in the first place.
Current policy allows for greater-than-/48 PI assignments if the org can justify it. However, since we haven't told staff (via policy) what that justification should look like, they are currently approving all requests and several orgs have taken advantage of that. So, it's entirely possible someone could get a /40 and deaggregate that into 256 routes if they wanted to. Given the entire v6 routing table is around 700 routes today, it's obviously not a problem yet :) S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
Current policy allows for greater-than-/48 PI assignments if the org can justify it. However, since we haven't told staff (via policy) what that justification should look like, they are currently approving all requests and several orgs have taken advantage of that. I can't imagine what an end-user could come up with to justify more than a /48 but what do I know. And if ARIN's primary goal is to prevent de-aggregation then shouldn't there be another fixed allocation size (/40) and block to prevent this?
So, it's entirely possible someone could get a /40 and deaggregate that into 256 routes if they wanted to. Given the entire v6 routing table is around 700 routes today, it's obviously not a problem yet :) Obviously that's short sighted :) As for the deaggregation- anyone deaggregating a /40 into 256 routes should have there AS permanently bloackholed :)
-Don
Thus spake "Donald Stahl" <don@calis.blacksun.org>
Current policy allows for greater-than-/48 PI assignments if the org can justify it. However, since we haven't told staff (via policy) what that justification should look like, they are currently approving all requests and several orgs have taken advantage of that.
I can't imagine what an end-user could come up with to justify more than a /48 but what do I know.
First of all, there's disagreement about the definition of "site", and some folks hold the opinion that means physical location. Thus, if you have 100 sites, those folks would claim you have justified 100 /48s (or one /41). Other folks, like me, disagree with that, but there are orgs out there that have tens of thousands of locations with a need for multiple subnets per location, and that could justify more than a /48 as well via pure subnet counts.
And if ARIN's primary goal is to prevent de-aggregation then shouldn't there be another fixed allocation size (/40) and block to prevent this?
ARIN's goal in v6 is to try to issue blocks so that aggregation is _possible_, by reserving a larger block to allow growth, but ARIN can't prevent intentional (or accidental) deaggregation, and there's too many folks who want to deaggregate for TE purposes to pass a policy officially condemning it.
So, it's entirely possible someone could get a /40 and deaggregate that into 256 routes if they wanted to. Given the entire v6 routing table is around 700 routes today, it's obviously not a problem yet :)
Obviously that's short sighted :) As for the deaggregation- anyone deaggregating a /40 into 256 routes should have there AS permanently bloackholed :)
I'd agree in principle, but all it takes is a brief look at the CIDR report and you'll see that nobody does anything in response to far more flagrant examples in v4. If everyone aggregated properly, we could drop over a third of the current v4 table. This makes me extremely suspicious of ISPs that continually whine about routing table bloat whenever loosening policies for small orgs is discussed. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
First of all, there's disagreement about the definition of "site", and some folks hold the opinion that means physical location. Thus, if you have 100 sites, those folks would claim you have justified 100 /48s (or one /41). Other folks, like me, disagree with that, but there are orgs out there that have tens of thousands of locations with a need for multiple subnets per location, and that could justify more than a /48 as well via pure subnet counts. Companies with tens of thousands of sites, each needing multiple subnets is not the norm for end user allocations. And again- would the administrative overhead of a new /40 netblock really outweigh the benefits to our routing tables? I'm asking not stating...
ARIN's goal in v6 is to try to issue blocks so that aggregation is _possible_, by reserving a larger block to allow growth, but ARIN can't prevent intentional (or accidental) deaggregation, But ARIN has the power to give the community the tools it needs to force aggregation (if the community decides they want)- even if it isn't ARIN's own policy.
and there's too many folks who want to deaggregate for TE purposes to pass a policy officially condemning it. I understand limited deaggregation for TE purposes- but that doesn't mean you have to let people go nuts. 1 or two bits is one thing- 8 (or more) is another animal all together.
I'd agree in principle, but all it takes is a brief look at the CIDR report and you'll see that nobody does anything in response to far more flagrant examples in v4. So because v4 is screwed up we should let v6 get just as bad?
The time to fix these sorts of issues is now- before it's really live, rather than later. -Don
Stephen Sprunk wrote:
Thus spake "Donald Stahl" <don@calis.blacksun.org>
Current policy allows for greater-than-/48 PI assignments if the org can justify it. However, since we haven't told staff (via policy) what that justification should look like, they are currently approving all requests and several orgs have taken advantage of that.
I can't imagine what an end-user could come up with to justify more than a /48 but what do I know.
First of all, there's disagreement about the definition of "site",
The general definition of a site that I find appropriate is and works pretty well as a rule of thumb: "A site is defined by it having a single administrative domain". As such, if you have for example an NREN, most likely every University will have their own Networking Department, with their own administrators of that network. As such, every university is a site. When the University is very large, it will have multiple administrative portions, eg generally Computer Science will have their own folks managing the network. When you have a large company, the company is also split over several administrative sites, in some cases you might have a single administrative group covering several sites though, this allows you to provide them with a single /48 as they are one group they will know how to properly divide that address space up. It comes sort of close to an AS actually, except that an AS tends to cover a lot of sites.
some folks hold the opinion that means physical location. Thus, if you have 100 sites, those folks would claim you have justified 100 /48s (or one /41). Other folks, like me, disagree with that, but there are orgs out there that have tens of thousands of locations with a need for multiple subnets per location, and that could justify more than a /48 as well via pure subnet counts.
If you have 40k sites, then a /32 is a perfect fit for you. There are not too many organizations that come close to that though, making /32's excellent for most organizations, except the very small ones. These can request a /48, or something upto a /40 for that purpose. Greets, Jeroen
On Thu, 31 May 2007 18:40:42 BST, Jeroen Massar said:
When you have a large company, the company is also split over several administrative sites, in some cases you might have a single administrative group covering several sites though, this allows you to provide them with a single /48 as they are one group they will know how to properly divide that address space up.
Works great, until you realize that for traffic engineering purposes, you really want to announce your Los Angeles site at an exchange near there, and your London site to be announced near there, and you end up wondering whether deaggregating the /48, or getting a second/third /48 would be wiser.. ;)
Valdis.Kletnieks@vt.edu wrote:
On Thu, 31 May 2007 18:40:42 BST, Jeroen Massar said:
When you have a large company, the company is also split over several administrative sites, in some cases you might have a single administrative group covering several sites though, this allows you to provide them with a single /48 as they are one group they will know how to properly divide that address space up.
Works great, until you realize that for traffic engineering purposes, you really want to announce your Los Angeles site at an exchange near there, and your London site to be announced near there, and you end up wondering whether deaggregating the /48, or getting a second/third /48 would be wiser.. ;)
Yes, that is indeed one of the many problems that come associated with getting a huge /32. You are supposed to announce that at in one aggregated chunk... At the moment you end up announcing chunks of the /48 to the local area and backhauling traffic from one site to another. The option for getting a separate /48 per site is then very tempting I guess. Unless you have a 10k or so of those sites... Firewall-wise having one big chunk is of course very interesting as you only need 1 ACL. Then again, do you trust everybody in your company? :) I guess that a different way of authentication, eg using authenticated packets (IPSEC AH) will become more and more common. One part missing there is a "Token" which can be added though, eg you have a local Authority which says "I allow X to send packet from Y to Z", take that token and attach it to packets. Firewalls trust the Authority and thus allow those packets through. Accidentally this is similar to something that came up in the DTN meeting last week. This is something that needs to be solved with a magic new routing mechanism though, like a lot of other things. Greets, Jeroen
When you have a large company, the company is also split over several administrative sites, in some cases you might have a single administrative group covering several sites though, this allows you to provide them with a single /48 as they are one group they will know how to properly divide that address space up.
Works great, until you realize that for traffic engineering purposes, you really want to announce your Los Angeles site at an exchange near there, and your London site to be announced near there, and you end up wondering whether deaggregating the /48, or getting a second/third /48 would be wiser.. ;)
I believe that a separate /48 per site is better regardless of whether or not the company has contracted with a single ISP for all sites, or not. As far as I am concerned if there is a separate access circuit, then it is a site and it deserves its own /48 assignment/allocation. --Michael Dillon
On 1-jun-2007, at 10:09, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I believe that a separate /48 per site is better regardless of whether or not the company has contracted with a single ISP for all sites, or not. As far as I am concerned if there is a separate access circuit, then it is a site and it deserves its own /48 assignment/allocation.
So aggregation is no longer a goal?
I believe that a separate /48 per site is better regardless of whether or not the company has contracted with a single ISP for all sites, or not. As far as I am concerned if there is a separate access circuit, then it is a site and it deserves its own /48 assignment/allocation.
So aggregation is no longer a goal?
Aggregation is not harmed by the /48 per site decision. If an ISP wants to aggregate their IPv6 traffic, they will announce one block for their entire global network. Then, internally, they will assign /48s in LA from a western USA internal allocation and /48s in Hamburg from a northwestern Europe internal allocation. If those two sites happen to belong to the same customer, then they could assign the customer a /48 to cover both sites and carry longer prefixes internal so that LA traffic stays in or near LA, and Hamburg traffic stays in or near Germany. Of course, if both sites are different companies, or if both sites belong to the same company but they contract with different ISPs in each country, then the sites will get a /48 assignment without question. --Michael Dillon
Thus spake <michael.dillon@bt.com>
If an ISP wants to aggregate their IPv6 traffic, they will announce one block for their entire global network. Then, internally, they will assign /48s in LA from a western USA internal allocation and /48s in Hamburg from a northwestern Europe internal allocation.
Bad example, since (a) blocks from different RIRs aren't going to aggregate and (b) RIPE doesn't assign /48s anyway. If we were talking about a company with sites on the east and left coasts of the US, then IMHO they should get a single /48 if they have internal connectivity (single site) and two /48s if not (two sites). However, I wouldn't argue (much) with ARIN issuing a /47 even in the former case on the logic that such constitutes two "sites", particularly if they had separate management; it's when we get to the level of hundreds or thousands of locations (with internal connectivity) that I have a problem with calling each location a "site". Below that, it doesn't do much harm. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On Fri, 1 Jun 2007, Iljitsch van Beijnum wrote:
On 1-jun-2007, at 10:09, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I believe that a separate /48 per site is better regardless of whether or not the company has contracted with a single ISP for all sites, or not. As far as I am concerned if there is a separate access circuit, then it is a site and it deserves its own /48 assignment/allocation.
So aggregation is no longer a goal?
why do you say that? he COULD mean that they should get their ip assignment from their provider, which would/should aggregate for him... right?
On 1-jun-2007, at 14:58, Chris L. Morrow wrote:
I believe that a separate /48 per site is better regardless of whether or not the company has contracted with a single ISP for all sites, or not. As far as I am concerned if there is a separate access circuit, then it is a site and it deserves its own /48 assignment/allocation.
So aggregation is no longer a goal?
why do you say that? he COULD mean that they should get their ip assignment from their provider, which would/should aggregate for him... right?
I thought we were talking about PI... Obviously with PA the only issue would be burning through an ISP's space very fast, but with IPv6 that's not a huge deal.
Thus spake "Jeroen Massar" <jeroen@unfix.org>
Stephen Sprunk wrote:
First of all, there's disagreement about the definition of "site",
The general definition of a site that I find appropriate is and works pretty well as a rule of thumb:
"A site is defined by it having a single administrative domain".
That's a good rule of thumb; I'm curious how close it is to what ARIN staff uses when evaluating requests, though. Or if staff let the requestor define "site" themselves since policy doesn't.
As such, if you have for example an NREN, most likely every University will have their own Networking Department, with their own administrators of that network. As such, every university is a site.
That's reasonable, if for no other reason than the number of universities is manageable and there's no doubt they're independently managed -- follow the money. However, I'd argue that NREN is an LIR and the universities are their customers.
When the University is very large, it will have multiple administrative portions, eg generally Computer Science will have their own folks managing the network.
That can be handled by subdividing the /48 that goes to the U.
When you have a large company, the company is also split over several administrative sites, in some cases you might have a single administrative group covering several sites though, this allows you to provide them with a single /48 as they are one group they will know how to properly divide that address space up.
In my experience, there tends to be one corporate IT group that handles stuff like connectivity to other orgs, and several subordinate IT groups that manage their part of the network. That can be handled with chopping up their /48. In the case of the rare (typically multinational) org where the groups run independent networks that talk BGP to each other and/or have their own uplinks, it'd be fair for ARIN to consider each group a separate site or even org if requested. Ditto if a single org had multiple separate networks but only one IT group (e.g. hosters).
It comes sort of close to an AS actually, except that an AS tends to cover a lot of sites.
An end-user AS tends to cover a lot of locations. By definition, it describes an area with a single coherent routing policy and administrator. An ISP AS may cover a lot of sites because leaf sites are part of their upstream's AS as far as routing is concerned.
If you have 40k sites, then a /32 is a perfect fit for you. There are not too many organizations that come close to that though, making /32's excellent for most organizations, except the very small ones. These can request a /48, or something upto a /40 for that purpose.
Let's take our canonical example of McDonald's. Does each store (let's assume they're all company-owned, not franchisees, for a moment) really count as a "site"? It's definitely a location, but if there's a single IT group that manages all 100k or so of them, I'd argue they're all one "site", certainly one org, and not an LIR. Give each store a /60 (to make rDNS easy and allow for growth), and McD's as a whole would get a /40 or so (to allow for internal aggregation). However, as I noted, some folks would consider McD's an LIR and want to give them a /30 or shorter. I think that's wrong, but policy doesn't clearly say either way. Looking at WHOIS doesn't help much, since many obvious end-user orgs like Cisco got LIR allocations back when there was no end-user PIv6 policy; who knows what they'd be told today if they applied with the same rationale. (Though presumably they wouldn't try since assignments are far cheaper to renew) S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On 31-mei-2007, at 15:45, Stephen Sprunk wrote:
The general rule, for both v4 and v6, is that people should filter on whatever the minimum allocation/assignment size for each RIR block.
Did someone take the trouble to tell RIPE that? 193/8 /29 194/7 /29 That allows for 6291456 prefixes when fully deaggregated.
Someone recently posted a link (either on PPML or here -- I can't find it now) that showed ARIN's minima for the various v4 and v6 blocks.
[ALLOCSIZE-APNIC] APNIC, "Allocation sizes within APNIC IPv4 address ranges", http://www.apnic.net/db/min-alloc.html [ALLOCSIZE-LACNIC] LACNIC, "LACNIC - Registration Services", http://lacnic.net/en/registro/index.html [ALLOCSIZE-RIPE] L. Vegoda, "RIPE-380 Address Space Managed by the RIPE NCC", June 2006, https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html [ARIN-MICRO] ARIN, "ARIN Micro-allocations", http://www.arin.net/reference/micro_allocations.html
Thus spake "Stephen Sprunk" <stephen@sprunk.org>
Someone recently posted a link (either on PPML or here -- I can't find it now) that showed ARIN's minima for the various v4 and v6 blocks. The v4 ones were all over the map, but there are relatively few v6 blocks and all of them are /32 except for one that's /48.
This is the page I was thinking of: http://www.arin.net/reference/ip_blocks.html The v6 list doesn't show explicit minima like the v4 list, but it's /32 for non-micro allocations (the block for which, unfortunately, isn't noted on this page) and /48 for direct assignments under current policy. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
participants (12)
-
bmanning＠karoshi.com -
Brandon Butterworth -
Chris L. Morrow -
Donald Stahl -
Iljitsch van Beijnum -
Jeff Kell -
Jeroen Massar -
Joel Jaeggli -
michael.dillon＠bt.com -
Owen DeLong -
Stephen Sprunk -
Valdis.Kletnieks＠vt.edu