Re: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria
Collective, This originated from a thread I started on ipv6-ops... As the archives seem to bear out shim6/mhap/multi6 or whatever the new *thing* will be is not ready. We (uk.netegral) have a /32 already (2001:4bf0::) however many of the recipients of sub-allocations will be using the resources in conjunction with their other providers. My, now somewhat aging, e-mail to lir-help asked what happens to LIRs that cannot get/justify/plan for 200 /48s their reply was simple: get it off another LIR. This now leads into a problem with routing policies: if /32s are only to be allowed in the backbone, how doe these sub-lir allocations get announced. My idea is to simply allow internetwork /48 to be announced to the backbone, or aggregates thereof (i.e. to adjacent /48s for the same ASN as a /47 and so on...). I know the first response will be that this will grow the routing table infinitely and I agree, however with 629-ish from my view there isn't much of a table to speak of. Are there any considerations I'm missing, why can't IPv6 prefixes be treated in the same way as IPv4? I'm not advocating announcing every /64 from here to timbuktu but otherwise I can't see anything to allow the "little guys" from actually benefitting therefore deploying IPv6. One of our customers has a /48 allocation and is now refusing to issue to customers as he can't announce this to the second upstream (they refuse to pass it on as it isn't a /32), they have also hit peers that refused the prefix as it hit their "this route is internal" prefix filter. I assume the end goal here is to encourage the uptake of v6 not hinder it... Can this disparity in policies not be addressed using current protocols and technologies simply by increasing the allowable boundary for the backbone? This has a neat side effect of not having to alter the issuing policy for /32s :) .
Can this disparity in policies not be addressed using current protocols and technologies simply by increasing the allowable boundary for the backbone? This has a neat side effect of not having to alter the issuing policy for /32s :) .
If there is going to be a route in the global routing table then it is better for that route to be a /32 rather than to ambiguously allow for longer prefixes. Therefore, RIPE, and all other RIRs, should give organizations a /32 if they intend to announce routes in the global IPv6 routing table. This does not waste IPv6 space since a /32 is a very small fraction of the IPv6 address space. In fact, it is the same as an IPv4 /32 when measured as a percentage of the total IPv4 address space. --Michael Dillon
Michael.Dillon@radianz.com wrote:
If there is going to be a route in the global routing table then it is better for that route to be a /32 rather than to ambiguously allow for longer prefixes. Therefore, RIPE, and all other RIRs, should give organizations a /32 if they intend to announce routes in the global IPv6 routing table.
This does not waste IPv6 space since a /32 is a very small fraction of the IPv6 address space. In fact, it is the same as an IPv4 /32 when measured as a percentage of the total IPv4 address space.
I appreciate that, but how then does an organisation that can only qualify for a /48 from x upstream participate? Many Hosting providers (rather than connectivity providers) are going to end up shafted by that ideal. Or are we simply moving everybody up a subnet, i.e. LIRs now get /24...? Either way we end up with the same argument, just with longer or shorter prefixes. Or are we lobbying for the criteria as a LIR to be relaxed...? Hosting suppliers are seemingly getting the raw end of this deal and seen as IPv6 will be de fact one day and they need redundancy and multi-path, etc. I would think now would be the time to accomodate them. -- Best regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | cgray@netegral.co.uk 0871 277 NTGL (6845)
Or are we lobbying for the criteria as a LIR to be relaxed...?
Hosting suppliers are seemingly getting the raw end of this deal and seen as IPv6 will be de fact one day and they need redundancy and multi-path, etc. I would think now would be the time to accomodate
YES! them. Then they should come to Stockholm in May and state their case at the meeting. If they want to take RIPE to court or make a complaint to the European Competition Commission, they first have to attempt to solve the problem using the channels that exist for changing RIPE policies. It's that simple. --Michael Dillon
Hi, On Thu, Apr 21, 2005 at 11:27:32AM +0100, Cameron Gray (RIPE Address Policy WG) wrote:
Or are we lobbying for the criteria as a LIR to be relaxed...?
Actually there are no big hurdles for becoming a LIR. Prove your existance, fill in paperwork, pay startup fee, done. This alone doesn't give you an IPv6 allocation yet, though - the biggest hurdle there is that you have to claim a plan to supply 200 customers with IPv6. As it is only a *plan*, it's possible to achieve for most LIRs that actually provide addresses to customers. OTOH, there's an ongoing policy change proposal to drop the 200-customer rule. Please read up the specifics of the proposal in the archive, and voice your opinion... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Gert, On Thu, Apr 21, 2005 at 02:41:06PM +0200, Gert Doering wrote:
OTOH, there's an ongoing policy change proposal to drop the 200-customer rule. Please read up the specifics of the proposal in the archive, and voice your opinion...
We have been discussing this proposal now for years. What is it that is needed to get a decision made regarding rejection or approval of this proposal? David Kessens ---
Hi, On Thu, Apr 21, 2005 at 06:16:14PM -0700, David Kessens wrote:
On Thu, Apr 21, 2005 at 02:41:06PM +0200, Gert Doering wrote:
OTOH, there's an ongoing policy change proposal to drop the 200-customer rule. Please read up the specifics of the proposal in the archive, and voice your opinion...
We have been discussing this proposal now for years.
Indeed, but the discussion always died down after a while, and nobody did everything necessary to make it an actual policy change. I think one of the reasons for that was that the RIPE policy process just wasn't formal enough, to say "*this* is the timeline, we make a decision *now*" - which should be easier now, with the new formalized policy process. OTOH...
What is it that is needed to get a decision made regarding rejection or approval of this proposal?
... I am not sure whether I can see any sort of consensus yet. We have very loud voices that oppose the change, other voices want much more than that, and a number of people agree with it. If I do some sort of "averaging", the "average opionion" from this could be "yes, go for it", but basically it comes down to "what's our definition of consensus" now. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On 22-apr-2005, at 9:39, Gert Doering wrote:
What is it that is needed to get a decision made regarding rejection or approval of this proposal?
... I am not sure whether I can see any sort of consensus yet.
I am sure: there isn't any.
We have very loud voices that oppose the change, other voices want much more than that, and a number of people agree with it. If I do some sort of "averaging", the "average opionion" from this could be "yes, go for it", but basically it comes down to "what's our definition of consensus" now.
Well, my definition of "consensus" doesn't include any averaging... I'm thinking: why don't we get a group of people representing the different viewpoints together in Stockholm and try to hash out a compromise? However, this means the "free for all" proponents need to be willing to do some compromising. Dropping the 200 limit and giving everyone who pays the LIR fee a /32 isn't my idea of a compromise. Iljitsch
On 20-apr-2005, at 18:05, Cameron Gray (RIPE Address Policy WG) wrote:
My, now somewhat aging, e-mail to lir-help asked what happens to LIRs that cannot get/justify/plan for 200 /48s their reply was simple: get it off another LIR. This now leads into a problem with routing policies: if /32s are only to be allowed in the backbone, how doe these sub-lir allocations get announced.
Well, there are no rules as to what is and isn't "allowed in the backbone". There is RFC 2772, which provides "6bone backbone routing GUIDELINES" and there are is a remark in the RIR/IANA IPv6 policies that the RIRs will only allocate blocks of /32 and bigger for the benefit of prefix length filtering. (But some root DNS servers have / 48 blocks...) At the end of the day, it's individual ISPs who decide what they allow and don't allow in their routing tables. It's true that if you announce a smaller block than a /32 you'll be filtered in many places. However, this isn't necessarily a problem. For instance, if someone in Asia sends your customer who has a /48 from you and also announces this /48 to another ISP, and the Asian network filters the / 48, the packet will flow towards Europe as per your /32. Then when it gets to Europe, it's pretty likely that the packet will hit an ISP who actually has the /48 in their routing table. After all, what's allowing a few /48s from the people you get drunk with at all those RIPE meetings? If then the link between you and your customer is down the packets still get to the customer. (Obviously if you drop the /32 announcement for whatever reason this is no longer true.) So I would encourage you, your customers and your customer's other ISPs to announce these smaller blocks over regional exchange points. This will give your customers 80% of the advantages of having PI space with only 20% of the downsides. (Note that it would be good if those customers had a bigger block than a /48. Even a /47 would be better, as it's likely that ISPs will leak /48s that shouldn't be announced at some point, which will make others want to filter /48s. But since customers generally don't have bigger blocks than a /48 there is no reason to disallow /47s in anti- leak filters.)
On Sun, Apr 24, 2005 at 11:26:12AM +0200, Iljitsch van Beijnum wrote:
At the end of the day, it's individual ISPs who decide what they allow and don't allow in their routing tables. It's true that if you announce a smaller block than a /32 you'll be filtered in many places. However, this isn't necessarily a problem. For instance, if someone in Asia sends your customer who has a /48 from you and also announces this /48 to another ISP, and the Asian network filters the / 48, the packet will flow towards Europe as per your /32. Then when it gets to Europe, it's pretty likely that the packet will hit an ISP who actually has the /48 in their routing table. After all, what's allowing a few /48s from the people you get drunk with at all those RIPE meetings?
The filtering out there IS a problem. For an example what happens when you try multihoming with </32, see: http://www.sixxs.net/tools/grh/lg/?prefix=2001:1578::/32 It's not that extreme in this case, as some/many people seem to filter "<=/48" instead of ">/32" and /40s do pass, but in general your AS_PATHs for the more-specifics can get VERY long. So borderline is that you have worse to MUCH worse connectivity by announcing the more-specific than via the aggregate, thanks to the filtering done out there. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 24-apr-2005, at 13:34, Daniel Roesen wrote:
The filtering out there IS a problem.
Yes, but it's getting better.
in general your AS_PATHs for the more-specifics can get VERY long. So borderline is that you have worse to MUCH worse connectivity by announcing the more-specific than via the aggregate, thanks to the filtering done out there.
There are still people out there who announce everything to everyone over tunnels. It was much worse in the past but it's important that not only the people who do this are encouraged to stop, but also that the people who are feeding them cut their BGP feeds off if they don't. This is all BGP 101 so there is absolutely no reason for this to persist, people just have to flip the "test/production" switch on their IPv6 stuff in the "production" direction and take away peering privileges from well-meaning but clue-challenged amateurs.
participants (6)
-
Cameron Gray (RIPE Address Policy WG) -
Daniel Roesen -
David Kessens -
Gert Doering -
Iljitsch van Beijnum -
Michael.Dillon＠radianz.com