Now that we have the new IPv6 policy in place, and we have try and start using it, I have a small problem. We have been allocated a IPv6 block for the Supernational-LIR. However, the actual LIR consits of several ASes, each present at it's own IX and with it's own routing policy. To me, a Supernational-LIR consists of several sub-LIRs. My problem is that RIPE will only allocate on /35 block to us, saying that is the allocation for our LIR. This means that we will end up having to break that block into smaller announcements, one per each sub-LIR. Could someone elaborate on the thinking behind this policy. To me it would routingwise make more sense to allocate a block per sub-LIR. Best regards, - kurtis -
On Wed, 29 May 2002, Kurt Erik Lindqvist KPNQwest wrote:
Now that we have the new IPv6 policy in place, and we have try and start using it, I have a small problem. We have been allocated a IPv6 block for the Supernational-LIR. However, the actual LIR consits of several ASes, each present at it's own IX and with it's own routing policy.
To me, a Supernational-LIR consists of several sub-LIRs. My problem is that RIPE will only allocate on /35 block to us, saying that is the allocation for our LIR. This means that we will end up having to break that block into smaller announcements, one per each sub-LIR.
Could someone elaborate on the thinking behind this policy. To me it would routingwise make more sense to allocate a block per sub-LIR.
To me, it would make sense to allocate a /3x to each and every one who has an AS#, and requests ipv6-space, then we would NOT have any problem like the above or with 'multihoming' either. It is not like the adresses would be used-up with this scenario..
Best regards,
- kurtis -
-- Regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------
Hi, On Wed, May 29, 2002 at 10:14:34AM +0200, Fredrik Widell wrote:
To me, it would make sense to allocate a /3x to each and every one who has an AS#, and requests ipv6-space, then we would NOT have any problem like the above or with 'multihoming' either. It is not like the adresses would be used-up with this scenario..
Won't really solve anything - it will just move the question to "who is entitled to get an AS number?" and "do we really want to see 32 bit AS numbers?". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
me, it would make sense to allocate a /3x to each and every one who has > an AS#, and requests ipv6-space, then we would NOT have any problem like the > above or with 'multihoming' either. It is not like the adresses would be used-up > with this scenario..
Won't really solve anything - it will just move the question to "who is entitled to get an AS number?" and "do we really want to see 32 bit AS numbers?".
We could always go for 128-bits! <running and ducking> :) Seriously, what about the orginal problem? Is there any logical reason as to why not the Supernational-LIRs would not be allocated a block per sub-LIR? Best regards, - kurtis -
Hi, On Wed, May 29, 2002 at 10:54:42AM +0200, Kurt Erik Lindqvist KPNQwest wrote:
me, it would make sense to allocate a /3x to each and every one who has > an AS#, and requests ipv6-space, then we would NOT have any problem like the > above or with 'multihoming' either. It is not like the adresses would be used-up > with this scenario..
Won't really solve anything - it will just move the question to "who is entitled to get an AS number?" and "do we really want to see 32 bit AS numbers?". We could always go for 128-bits! <running and ducking> :)
The problem with that isn't so much the lenght of the number (that's just "linear memory waste"), the problem that I see is that the number of ASes actually in use reflect the complexity of the overall topology - and *that* goes into BGP convergence times much stronger than linearily.
Seriously, what about the orginal problem? Is there any logical reason as to why not the Supernational-LIRs would not be allocated a block per sub-LIR?
I can speak only for myself here, of course. The way I see the current (new) policy, and the idea behind it, is to use *hierarchical aggregation*, which means "you get one big block and feed your sub-LIRs out of this". If you have a big block, say a /28, and each of your sub-LIRs gets a /32 out of it, and those that really need it announce the /32 to the world, the net impact on BGP is mostly the same, but for documentation purposes, it's still clear that "yes, this is all the same LIR". Not all of the /32s might even necessarily be visible globally, upstream could go through the /28. The new policy (effective next monday) will permit this - if you come up with good reasons and some thought about addressing plans and hierarchy, getting something "large enough" should not be a unsolveable problem. At least that was the intention - the address space is large enough so that haggling over "we need a /28" - "no you can only get a /31 plus a /32" should not occur (unless the "need" for a /28 really isn't justificable). Does this make sense to anybody? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, 29 May 2002, Gert Doering wrote:
The new policy (effective next monday) will permit this - if you come up
You mean, effective 1 Jul 2002. - Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hi, On Wed, May 29, 2002 at 12:46:41PM +0300, Pekka Savola wrote:
On Wed, 29 May 2002, Gert Doering wrote:
The new policy (effective next monday) will permit this - if you come up You mean, effective 1 Jul 2002.
July? Ooops. I thought that was "June". Hrm. So we'll have to wait a bit longer :-/ Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
The problem with that isn't so much the lenght of the number (that's just "linear memory waste"), the problem that I see is that the number of ASes actually in use reflect the complexity of the overall topology - and *that* goes into BGP convergence times much stronger than linearily.
Agreed. It was merly a joke. Personally I think that most customers asking for multihoming is actually asking for something completly different. But we have been down that discussion before...
Not all of the /32s might even necessarily be visible globally, upstream could go through the /28.
Well, in our case they would. Problem is that we do not have a /28. My point was to some extent that we should define this better. It's is a single LIR, but the question is what the allocation should be for routing purposes.
The new policy (effective next monday) will permit this - if you come up with good reasons and some thought about addressing plans and hierarchy, getting something "large enough" should not be a unsolveable problem. At least that was the intention - the address space is large enough so that haggling over "we need a /28" - "no you can only get a /31 plus a /32" should not occur (unless the "need" for a /28 really isn't justificable).
I agree, but RIPE NCC have said we will only get the /35. Best regards, - kurtis -
Hi, On Thu, May 30, 2002 at 10:05:09AM +0200, Kurt Erik Lindqvist KPNQwest wrote: [..]
Not all of the /32s might even necessarily be visible globally, upstream could go through the /28.
Well, in our case they would. Problem is that we do not have a /28. My point was to some extent that we should define this better. It's is a single LIR, but the question is what the allocation should be for routing purposes. [..] I agree, but RIPE NCC have said we will only get the /35.
Try again after the new policy is in place. The old policy had no provisions for anything reasonable, but under the new policy, it should be possible to get a /28. Or maybe even a /20. Or whatever make sense according to a "aggregation is very important, conservation should not be neglected but is not the main issue". Be prepared, though, to invest quite some thoughts into network structure, plans for hierarchical address space distribution, and so on - the NCC will need this to judge whether the request is reasonable, or outragious. (Of course I'd like a /20 too :-) - but there is no way I will get one, as I can't demonstrate any reasonable need for it, and this is perfectly ok with me). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
In message <20020529104819.I13918@Space.Net>, Gert Doering writes:
Won't really solve anything - it will just move the question to "who is entitled to get an AS number?" and "do we really want to see 32 bit AS numbers?".
Considering that we are running out of 16 bit numbers, and considering that no other viable multihoming option has been found yet in either of IPv4 and IPv6, I think 32bit AS numbers are a foregone conclusion... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Poul-Henning Kamp wrote:
In message <20020529104819.I13918@Space.Net>, Gert Doering writes:
Won't really solve anything - it will just move the question to "who is entitled to get an AS number?" and "do we really want to see 32 bit AS numbers?".
Considering that we are running out of 16 bit numbers, and considering that no other viable multihoming option has been found yet in either of IPv4 and IPv6, I think 32bit AS numbers are a foregone conclusion...
How about BGPDNS? See http://www.bgpdns.org. It could stop quit a number of those multihomed /24s. -- Andre AO6-RIPE
Poul-Henning Kamp wrote:
In message <20020529104819.I13918@Space.Net>, Gert Doering writes:
Won't really solve anything - it will just move the question to "who is entitled to get an AS number?" and "do we really want to see 32 bit AS numbers?".
Considering that we are running out of 16 bit numbers, and considering that no other viable multihoming option has been found yet in either of IPv4 and IPv6, I think 32bit AS numbers are a foregone conclusion...
How about BGPDNS? See http://www.bgpdns.org. It could stop quit a number of those multihomed /24s. -- Andre AO6-RIPE
On Wed, 29 May 2002, Fredrik Widell wrote:
On Wed, 29 May 2002, Kurt Erik Lindqvist KPNQwest wrote: To me, it would make sense to allocate a /3x to each and every one who has an AS#, and requests ipv6-space, then we would NOT have any problem like the above or with 'multihoming' either. It is not like the adresses would be used-up with this scenario..
Providers state that aggregation/hierarchy is needed because of faster convergence time and less wasted resources (among other valid reasons). Customers appear to believe that providers are less reliable than the other business critical services they may depend on (read the SLA offered to clients and the financial penalties applied for outages, draw a conclusion)
From an engineering perspective the providers are correct in their conclusion. From a commercial perspective the customers seem justified in theirs.
It does seem as if the desire to multihome (as a (perceived|actual)) form of risk management will continue to be an issue for the M/L Enterprise which needs to be addressed by the SP community. Rightly or wrongly. A-
Best regards,
- kurtis -
To me, it would make sense to allocate a /3x to each and every one who has an AS#, and requests ipv6-space, then we would NOT have any problem like the above or with 'multihoming' either. It is not like the adresses would be used-up with this scenario..
I agree. With the current to-be-implemented routing policy, having an AS# is however not sufficient grounds for getting your own "portable" IPv6 address space. At least not the way I read it. While it is true that the addresses would not be used up anytime soon with this alternative address allocation scheme, I have understood the fear to be that the routing table space would be consumed too quickly in this scenario. Apparently, in some regions getting the LIR status, multiple service provider connections, and your own AS# is considered to be "too easy" or "too cheap", so the practice would proliferate, and routing table explosion would be the result. However, as far as I know, none of the "alternative" ways to do multihoming in the IPv6 world provide a service with similar characteristics to the one we currently have in IPv4. In a way, this is a reflection of the fact that routing in IPv6 is just "more of the same" compared to IPv4, and that the routing and particularly multihoming issues from IPv4 have not been solved in IPv6. The current IPv6 address allocation policy nevertheless appears to try to implement routing aggregation through the RIR IPv6 allocation policy, in that only the "big guys" can get an allocation from their RIR. A side effect of this is that it will take away smaller ISPs ability to set their own routing policy, because they would need to go to their upstream(s) to get IPv6 addresses, and it seems likely that strict filtering of routing announcements on LIR allocation boundaries will be implemented. Regards, - Håvard
Hi, On Wed, May 29, 2002 at 06:03:37PM +0200, Havard Eidnes wrote:
The current IPv6 address allocation policy nevertheless appears to try to implement routing aggregation through the RIR IPv6 allocation policy, in that only the "big guys" can get an allocation from their RIR.
Misunderstood. The new policy means that every LIR (that is serious about connecting customers) can get IPv6 space. Yes, (smallish) end customers can not.
A side effect of this is that it will take away smaller ISPs ability to set their own routing policy, because they would need to go to their upstream(s) to get IPv6 addresses, and it seems likely that strict filtering of routing announcements on LIR allocation boundaries will be implemented.
Setting their own "regional" routing policy and doing peering should work fine in such a framework. The question to be asked is "is it so important to be visible world-wide and to impact every single core BGP router world-wide" if the entity in question can't be bothered to become an LIR and document the *plan* to connect 200 customers? Yes, becoming an LIR costs money, but announcing space to the world does so as well - and there ain't no free lunch (and should not be). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (8)
-
Alan Sawyer -
Andre Oppermann -
Fredrik Widell -
Gert Doering -
Havard Eidnes -
Kurt Erik Lindqvist KPNQwest -
Pekka Savola -
Poul-Henning Kamp