IPv6 Policy Clarification - Initial allocation criteria "d)"
Dear Colleagues, We have received many comments that the text of the current IPv6 Allocation and Assignment Policy document can be difficult to read and understand. Some of these difficulties were presented at RIPE 48 by Leo Vegoda: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-polic... During the following discussions, the RIPE NCC was asked to co-ordinate work on clarifying the text. Please note that we do not intend to propose any policy changes. In order to assist with rewriting the IPv6 Policy document, we would like to have some input from the community on the issues needing clarification. We will send each issue for discussion in a separate mail. This is the first of these mails. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "d)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years." 1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention? 2. There are a number of interpretations of requirement "d)": - NUMBER OF ASSIGNMENTS -- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48. -- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s. Which interpretation was intended regarding the number of assignments? - RECIPIENT OF ASSIGNMENTS -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations. -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted. -- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation. -- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure". Which interpretation was intended regarding the recipient of assignments? We look forward to receiving the community's input on this. Best Regards, Laura Cobley Registration Services RIPE NCC
Inline... my views. On Mon, 14 Jun 2004, Laura Cobley wrote:
Dear Colleagues,
We have received many comments that the text of the current IPv6 Allocation and Assignment Policy document can be difficult to read and understand. Some of these difficulties were presented at RIPE 48 by Leo Vegoda:
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-polic...
During the following discussions, the RIPE NCC was asked to co-ordinate work on clarifying the text. Please note that we do not intend to propose any policy changes.
In order to assist with rewriting the IPv6 Policy document, we would like to have some input from the community on the issues needing clarification. We will send each issue for discussion in a separate mail.
This is the first of these mails.
Below is an excerpt from the IPv6 Address Allocation and Assignment Policy:
5.1.1. Initial allocation criteria "d)"
"To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years."
1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention?
If focus on *only*, "Yes". Otherwise i would say "No".
2. There are a number of interpretations of requirement "d)":
- NUMBER OF ASSIGNMENTS
-- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48.
-- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s.
I would go with this one. Focus on address space being "handed out", not on the # of different customers.
Which interpretation was intended regarding the number of assignments?
- RECIPIENT OF ASSIGNMENTS
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations.
This should be valid.
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted.
Own assignments should count. At a latter point in time projects/other might shift administrative control...
-- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation.
Should be valid. Some LIRs in fact manage a lot of projects, lot of networks, etc...
-- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure".
Too much conservative -- also a good way to stop/slow down IPv6. :-(
Which interpretation was intended regarding the recipient of assignments?
We look forward to receiving the community's input on this.
Best Regards,
Laura Cobley Registration Services RIPE NCC
Regards, ./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (135072/470), naming (millions) and... people!"
My opinions.. On Mon, 14 Jun 2004, Laura Cobley wrote:
Below is an excerpt from the IPv6 Address Allocation and Assignment Policy:
5.1.1. Initial allocation criteria "d)"
"To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years."
1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention?
The recommended policy is to make /48 assignments, so encouragement in this policy does not hurt. So, I'd maybe interpret this as "if you plan to make so many /64 assignments that 200 /48's wouldn't be enough, you may get an allocation". Means that guide LIRs towards Doing the Right Thing wrt. assignments are not a bad idea.
2. There are a number of interpretations of requirement "d)":
- NUMBER OF ASSIGNMENTS
-- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48.
-- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s.
Which interpretation was intended regarding the number of assignments?
IMHO, the former. The latter would be a loophole, and there shouldn't be a need for making many allocations larger than /48 in any case (and if they are made, there will have to be permission from RIPE NCC in any case, as of today)
- RECIPIENT OF ASSIGNMENTS
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations.
No, your own allocations are not counted.
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted.
This was what was meant, I think.
-- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation.
-- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure".
These two are just variants of the above assuming that "NUMBER OF ASSIGNMENTS" (above) does not need to be at least 200. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention?
The recommended policy is to make /48 assignments, so encouragement in this policy does not hurt. So, I'd maybe interpret this as "if you plan to make so many /64 assignments that 200 /48's wouldn't be enough, you may get an allocation".
Means that guide LIRs towards Doing the Right Thing wrt. assignments are not a bad idea.
I don't think you really believe this, either of you. First, I don't think anyone believes that mobile operators, who plan to make 50 million /64 assignments and no /48 assignments, do not qualify for IPv6 allocations from RIPE. Second, I don't think that anyone believes that it is the "right thing" for a mobile operator to assign 50 million /48 blocks, one to each customer handset. I think the community's intention was to happily offer IPv6 addresses to mobile operator LIRs who are moving beyond their small GPRS deployments and beginning to build true 3G ubiquitous wireless networks. But, often policies need to be edited and re-edited in order to clearly express the intention.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-14, at 11.34, Pekka Savola wrote:
- RECIPIENT OF ASSIGNMENTS
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations.
No, your own allocations are not counted.
Why not? If I have a large infrastructure, or is in the start-up phase or going through a network merger etc. I might have a lot of internal infrastructure but not many customer allocations. I fail to see why we would not include own allocations as those will be coming out of your block anyway. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+JtqarNKXTPFCVEQLPNwCdGUPO5YA3T6ZVY6OgdB9WpniemSgAoI1M nH85IqerKGd7H23Ge+ZMGBY2 =Hhkp -----END PGP SIGNATURE-----
On Wed, 16 Jun 2004, Kurt Erik Lindqvist wrote:
On 2004-06-14, at 11.34, Pekka Savola wrote:
- RECIPIENT OF ASSIGNMENTS
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations.
No, your own allocations are not counted.
Why not? If I have a large infrastructure, or is in the start-up phase or going through a network merger etc. I might have a lot of internal infrastructure but not many customer allocations. I fail to see why we would not include own allocations as those will be coming out of your block anyway.
Because the original text required that the assignments are made to the *other* organizations. By all logic, only the assignments to the others should count. In any case, your own infrastructure shouldn't take more than a /48 or something like that, so it wouldn't be useful to count it either: 199 or 200 makes no difference -- this would become bad if you could just assign e.g. /38 to your own infrastructure and state you've already assigned worth of 200 /48's. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Because the original text required that the assignments are made to the *other* organizations. By all logic, only the assignments to the others should count.
In any case, your own infrastructure shouldn't take more than a /48 or something like that, so it wouldn't be useful to count it either: 199 or 200 makes no difference -- this would become bad if you could just assign e.g. /38 to your own infrastructure and state you've already assigned worth of 200 /48's.
See the email from Amar. Also, if you have several operating companies you might want to have separate assignments for each of them. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNFPdqarNKXTPFCVEQKQFQCfb5RaQrTHk8tX+eBRTa7sRuRwJ/wAnipW 4D9dXvdbynovbsdHahJjB3ye =Wihj -----END PGP SIGNATURE-----
On Thu, 17 Jun 2004, Kurt Erik Lindqvist wrote:
Because the original text required that the assignments are made to the *other* organizations. By all logic, only the assignments to the others should count.
In any case, your own infrastructure shouldn't take more than a /48 or something like that, so it wouldn't be useful to count it either: 199 or 200 makes no difference -- this would become bad if you could just assign e.g. /38 to your own infrastructure and state you've already assigned worth of 200 /48's.
See the email from Amar. Also, if you have several operating companies you might want to have separate assignments for each of them.
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Thursday 17 June 2004 10:20, Pekka Savola wrote:
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic. Jon
Hello, we face the same problem. We are a small internet access provider in France. We provide internet in residential areas, and our customers currently use less than one IPv4 address per home. We do not want to assign a /48 to all our customers only to meet RIPE's criteria. We prefer using only a /32 for each of our broadband access server, and /48 only for customers asking for it (ie : customers who have a router, several subnets, ...). Bertrand Maujean Jon Lawrence a écrit :
On Thursday 17 June 2004 10:20, Pekka Savola wrote:
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic.
Jon
-- Bertrand Maujean, responsable Informatique & Telecoms SEM Cable de l'Est - www.semnet.tm.fr 254 rue de la gare, 54710 Ludres - 03 83 25 97 82
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule -
perhaps somee one would like to explain the logic.
There is no logic to the rule. You have come right to the crux of the problem. The rules make it unnecessarily difficult to get IPv6 addresses which makes it hard for LIRs to get the addresses needed to run trials. If an LIR has already justified an IPv4 address block from RIPE then they should qualify for a block of IPv6 addresses. It doesn't matter how many IPv4 addresses they have or what plans they have for IPv6. Only one thing matters: the organization has proven that they have a real IP network and can justify receiving a RIPE IPv4 allocation. This means that they are a real IP network operator. And since all IP network operators will tranisition to IPv6 at some time in the future, they should need no other justification for an IPv6 allocation. The same rule should apply in all the other 4 RIR regions. The pseudo-logic behind this rule is that IPv4 addresses are scarce therefore we have to be careful how many we allocate and who we give them to. Since IPv6 is like IPv4 we also need complex rules to limit who gets addresses. The flaw is that IPv6 is not *LIKE* IPv4. It is a simpler and more flexible version of the Internet Protocol that has a vastly larger address space. The block of IPv6 unicast addresses currently earmarked for the RIRs is only a small part of the total address space. If we waste all of this by making dumb decisions then we still have plenty of other address space to use later on when we are wiser and have more IPv6 experience. This means that the risk of doing the wrong thing is vastly smaller than it was with IPv4. We should plan to err on the side of simplicity and flexibilty, i.e. give everyone an IPv6 allocation if they already have an IP network. There is very little downside to doing this. --Michael Dillon
On Thu, Jun 17, 2004 at 01:21:39PM +0100, Michael.Dillon@radianz.com wrote:
IPv4 addresses they have or what plans they have for IPv6. Only one thing matters: the organization has proven that they have a real IP network and can justify receiving a RIPE IPv4 allocation. This means that they are a real IP network operator. And since all IP network operators will tranisition to IPv6 at some time in the future, they should need no other justification for an IPv6 allocation.
Here here. This process should be much more streamlined than the person doing the IPv6 initiall allocation request saying "we have n networks, covering m addresses, we plan to dual stack everything in the future so we need x IPv6 space". There should be a simple rule saying for x IPv4 space you get y IPv6 space, if you need more you'd need to justify it.
The same rule should apply in all the other 4 RIR regions.
The pseudo-logic behind this rule is that IPv4 addresses are scarce therefore we have to be careful how many we allocate and who we give them to. Since IPv6 is like IPv4 we also need complex rules to limit who gets addresses. The flaw is that IPv6 is not *LIKE* IPv4. It is a simpler and more flexible
Even if it was *LIKE* IPv4, using the same criteria would make sense. As it's not, using IPv4 has a criteria means you're already using a stricter criteria than needed.
This means that the risk of doing the wrong thing is vastly smaller than it was with IPv4. We should plan to err on the side of simplicity and flexibilty, i.e. give everyone an IPv6 allocation if they already have an IP network. There is very little downside to doing this.
As oposed to making needlessly hard to get an assigment on the edges of the Internet, where the commercial demand starts. cheers -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Hi, On Thu, Jun 17, 2004 at 01:46:06PM +0100, Carlos Morgado wrote:
As oposed to making needlessly hard to get an assigment on the edges of the Internet, where the commercial demand starts.
We have about 355 IPv6 allocations to LIRs in the RIPE region. Most of them are to medium sized or small ISPs that want to "get IPv6 started". To me, this looks as if it's quite possible to get an IPv6 allocation under the current policy. But still: if you want to have it changed, please write a specific proposal for the change (*this* thread is mainly meant to clarify the wording of the existing policy, without actually changing it - but that doesn't mean it can't be done), and send it to the apwg mailing list. Consider the pros and cons of the change, and maybe the reasons behind the things being what they are now (should all be in the mailing list archives). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Thu, Jun 17, 2004 at 01:21:39PM +0100, Michael.Dillon@radianz.com wrote:
You have come right to the crux of the problem. The rules make it unnecessarily difficult to get IPv6 addresses which makes it hard for LIRs to get the addresses needed to run trials.
For trials, you don't need your own allocation. If you're serious about deployment, you can get an allocation. [..]
This means that the risk of doing the wrong thing is vastly smaller than it was with IPv4. We should plan to err on the side of simplicity and flexibilty, i.e. give everyone an IPv6 allocation if they already have an IP network. There is very little downside to doing this.
The members of all the RIR communities (*you*) have clearly voiced that they did not want this. *I* did propose, some years in the past, to just give a /32 to every LIR that asks for it... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Replying to two messages in one go.. On Thu, 17 Jun 2004, Jon Lawrence wrote:
On Thursday 17 June 2004 10:20, Pekka Savola wrote:
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic.
Now, this is another argument *altogether*, not a reason to start counting internal assignments. If we want to discuss whether rewording the 200 customers rule needs tuning, let's discuss that. I think the spirit (and the implementation) of the policy is that if you have 200 customers which *might* want IPv6 (but you haven't seen actual interest from 200 customers), and you'd be willing to give it to them if they asked, you'd qualify under the "200" rule in any case. Nobody will be withdrawing your allocation just because all your customers didn't yet realize that IPv6 is a good thing. Bertrand Maujean <bertrand.maujean@semnet.tm.fr>:
we face the same problem. We are a small internet access provider in France. We provide internet in residential areas, and our customers currently use less than one IPv4 address per home.
Because they use NAT with IPv4. They won't with IPv6, so they require sufficient number of addresses -- at least a /64, and in case they'd want to subnet, a /48. The simplest would be just giving /48 to everyone.
We do not want to assign a /48 to all our customers only to meet RIPE's criteria.
Do you mean that you don't want to give the users a /48, but rather something smaller, like /64? That's a bad idea IMHO.
We prefer using only a /32 for each of our broadband access server, and /48 only for customers asking for it (ie : customers who have a router, several subnets, ...).
/32 for each broadband access router? How many /32's do you intend to get??! :) Was this a typo? Why not just give /48 to everyone whether they want it or not? Or at least reserve /48 to everyone, but only assign a /64 or the like if they don't support prefix delegation or other mechanisms? That way you'd fulfill the allocation criteria as well, and make the users happier. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Thursday 17 June 2004 13:23, Pekka Savola wrote:
On Thu, 17 Jun 2004, Jon Lawrence wrote:
On Thursday 17 June 2004 10:20, Pekka Savola wrote:
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic.
Now, this is another argument *altogether*, not a reason to start counting internal assignments. If we want to discuss whether rewording the 200 customers rule needs tuning, let's discuss that.
Agreed - I was just wondering if anyone remembered why the 200 rule came into being in the first place. The documentation clearly states 200 end user sites. So I'd interpret that as meaning that internal assignments didn't count.
I think the spirit (and the implementation) of the policy is that if you have 200 customers which *might* want IPv6 (but you haven't seen actual interest from 200 customers), and you'd be willing to give it to them if they asked, you'd qualify under the "200" rule in any case. Nobody will be withdrawing your allocation just because all your customers didn't yet realize that IPv6 is a good thing.
Must say I'd never thought of it quite like that. I suppose you could see it as 'I planned to issue 200 /48's but my customers couldn't or wouldn't use IPv6'. Jon
On Thu, Jun 17, 2004 at 02:33:07PM +0100, Jon Lawrence wrote:
Must say I'd never thought of it quite like that. I suppose you could see it as 'I planned to issue 200 /48's but my customers couldn't or wouldn't use IPv6'.
I planned to issue 200 /48's, but all I got was this lousy T-shirt. Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. 802.11 deployment in Dublin: http://www.enigma.ie/wardrive/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-17, at 15.33, Jon Lawrence wrote:
Now, this is another argument *altogether*, not a reason to start counting internal assignments. If we want to discuss whether rewording the 200 customers rule needs tuning, let's discuss that.
Agreed - I was just wondering if anyone remembered why the 200 rule came into being in the first place. The documentation clearly states 200 end user sites. So I'd interpret that as meaning that internal assignments didn't count.
Which I am arguing is silly. We want IPv6 deployment to take off, right? So let's set the threshold for getting blocks fairly low. There is already a price on IPv6 blocks, the LIR fee. The 200 sites/end-users/customers/whatever does not make much sense. We are all even using fairly divergent specs for what the requirement is. And I don't remember it from the top of my head. However, I would argue that 200 assignments (internal, external, whatever you want) is enough. It's a measurement we have fairly good grip on by now. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNM9nqarNKXTPFCVEQJ0vACeMyf8pn3MCKOHZT0076rL1vzrh88An0LB rgIYdV5omq+OFA3Qs7/vB9Xw =ABb2 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic.
Now, this is another argument *altogether*, not a reason to start counting internal assignments. If we want to discuss whether rewording the 200 customers rule needs tuning, let's discuss that.
I disagree. If we are to count assignments, we are to count internal ones as well. IF you then feel that 200 is to low, let's discuss.
I think the spirit (and the implementation) of the policy is that if you have 200 customers which *might* want IPv6 (but you haven't seen actual interest from 200 customers), and you'd be willing to give it to them if they asked, you'd qualify under the "200" rule in any case. Nobody will be withdrawing your allocation just because all your customers didn't yet realize that IPv6 is a good thing.
Actually, this "might" argument only came after it was apparent that the reason that noone was asking for IPv6 allocations was that they realized they would never have 200 customers within two years. At least that is what I remember. I think we can stay with the 200 limit, BUT - Count internal blocks - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNM8sqarNKXTPFCVEQLb6wCeMJEzabA9xxFzI3jvkXCwW1jz5Z4AoKBn AceQTK4bDkpvEUg5sadZedWB =B9CA -----END PGP SIGNATURE-----
On Fri, 18 Jun 2004, Kurt Erik Lindqvist wrote:
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic.
Now, this is another argument *altogether*, not a reason to start counting internal assignments. If we want to discuss whether rewording the 200 customers rule needs tuning, let's discuss that.
I disagree. If we are to count assignments, we are to count internal ones as well. IF you then feel that 200 is to low, let's discuss.
No. The policy is: "d) have a plan for making at least 200 /48 assignments to other organisations within two years." Are an ISP's own PoPs or other parts of infrastructure "other organisations"? Nope. Never. Not by any English dictionary :). The purpose at this point is to clarify the policy, not to change it. You're confusing the issue by saying what you believe an optimal policy *SHOULD* be. I have an opinion about that as well, but that's out of scope of this debate, i.e., what the policy is and what it was intended to be (and 'other organisations' makes it crystal clear IMHO that you were not intended to count the internal assignments). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Saturday 19 June 2004 12:31, Pekka Savola wrote:
The purpose at this point is to clarify the policy, not to change it.
Good point. So let's clarify this as "other organisations, not including internal assignments" and kick off a debate on changing the policy. A strict interpretation of the policy might help to get dome discussion going since, clearly, few memebers of the community are happy with it. Cheers, Sascha -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha@eirconnect.ie Ireland | http://www.eirconnect.ie
Hi, On Sat, Jun 19, 2004 at 01:07:26PM +0100, Sascha Luck wrote:
A strict interpretation of the policy might help to get dome discussion going since, clearly, few memebers of the community are happy with it.
I tend to disagree with that statement. Over 360 allocations have been made, so I'd say (again) that the policy seems to be working fairly well for a number of people. People have voiced complaints about unclear wording in the policy, and this needs to be fixed. Some people have complained about the "200 customers" rule, and this certainly needs discussion. *One* person is taking major offence at not being allowed to play with the big boys. This is to be expected if the community decides to draw a line at "who gets an allocation, who doesn't". Democratic procedures aren't necessarily *nice* to everybody. I count that as "one member is very unhappy, and a few others have sore spots", which is something different from "clearly, few members are happy"... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi Gert, On Monday 21 June 2004 17:20, Gert Doering wrote:
I tend to disagree with that statement. Over 360 allocations have been made, so I'd say (again) that the policy seems to be working fairly well for a number of people.
Well these 360 people have not (yet?) piped up and said "We're happy, leave it as it is".
*One* person is taking major offence at not being allowed to play with the big boys.
Condescension will get us nowhere. Ok, we're a small ISP in a small market. Since we aim at the business/leased line market only, we may not have 200 customers, let alone 200 IPv6 allocations, within 2 years (I hope to be wrong, of course). Give me *one* good reason why we shouldn't be allowed to offer IPv6 connectivity? Give me a reason why we should lose *one*, otherwise happy, customer because of an arbitrary "line in the sand"?
This is to be expected if the community decides to draw a line at "who gets an allocation, who doesn't". Democratic procedures aren't necessarily *nice* to everybody.
When was this policy democratically decided? IIRC it was handed down from IANA/ICANN (I may be wrong on this) Besides, there is no benefit to this rule as far as I can see. IPv6 space is not a scarce resource. IPv4 is, yet is is easy enough to get.
I count that as "one member is very unhappy, and a few others have sore spots", which is something different from "clearly, few members are happy"...
If this is to be discussed, everyone who is happy with the existing rule is, of course, free to say so. Silence does not, necessarily, imply assent. Best regards, Sascha Luck Eirconnect
Hi, On Mon, Jun 21, 2004 at 06:20:14PM +0100, Sascha Luck wrote:
On Monday 21 June 2004 17:20, Gert Doering wrote:
I tend to disagree with that statement. Over 360 allocations have been made, so I'd say (again) that the policy seems to be working fairly well for a number of people. Well these 360 people have not (yet?) piped up and said "We're happy, leave it as it is".
They don't need to - the policy has fulfilled their purpose for them.
*One* person is taking major offence at not being allowed to play with the big boys.
Condescension will get us nowhere. Ok, we're a small ISP in a small market. Since we aim at the business/leased line market only, we may not have 200 customers, let alone 200 IPv6 allocations, within 2 years (I hope to be wrong, of course). Give me *one* good reason why we shouldn't be allowed to offer IPv6 connectivity? Give me a reason why we should lose *one*, otherwise happy, customer because of an arbitrary "line in the sand"?
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed). If you are in good hope to reach more than 200 customers, you fulfill the criteria (as has been mentioned before).
This is to be expected if the community decides to draw a line at "who gets an allocation, who doesn't". Democratic procedures aren't necessarily *nice* to everybody.
When was this policy democratically decided? IIRC it was handed down from IANA/ICANN (I may be wrong on this)
You are wrong on this :-) - the policy was discussed again and again at various RIPE meetings in the past 5 years. We had an interim policy, which was bad, but better than none. Then we had this policy, which is still not perfect, but enabled us to make progress.
Besides, there is no benefit to this rule as far as I can see. IPv6 space is not a scarce resource. IPv4 is, yet is is easy enough to get.
I wasn't in favour of the 200-customer rule (which is in the archives :) ). Quite a number of people from various regions insisted on it, at that time, for fear of a "landrush" or "routing table explosion" (routing table slots *are* a scarce resource indeed, but changing this policy to "every LIR in existance today gets one" won't hurt *that* much).
I count that as "one member is very unhappy, and a few others have sore spots", which is something different from "clearly, few members are happy"...
If this is to be discussed, everyone who is happy with the existing rule is, of course, free to say so. Silence does not, necessarily, imply assent.
The way people work, usually only those who are unhappy take the burden to figure out *where* to voice their unhappiness... But anyway, I agree that this side-track discussion isn't overly productive. In fact, I have not heard anyone stand up and say "WE MUST KEEP THE 200 CUSTOMER RULE!" - most people voiced some sort of "well, it's there, it doesn't do much harm, we can live with it", but nobody has actively stood up in favour of it. Has anyone? So shall we abandon it? In favour of *what* to replace it? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, Jun 21, 2004 at 07:31:41PM +0200, Gert Doering wrote:
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
Which one ? And, if he decides to drop that particular upstream he gets to renumber and ask all his clients to renumber ? Are you joking ? -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
On Monday 21 June 2004 18:31, Gert Doering wrote:
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
I could get native IPv6 connectivity from 3 upstreams today (OK, only from 2 for commercial purposes). TTBOMK, no multihoming facility exists without your own /32 allocation (considering aggregation, probably just as well).
If you are in good hope to reach more than 200 customers, you fulfill the criteria (as has been mentioned before).
Of course, I'm in good hope of reaching that goal. If that's good enough, fine but how do I document this hope? Will the NCC take my word for it? ;)
You are wrong on this :-) - the policy was discussed again and again at various RIPE meetings in the past 5 years. We had an interim policy, which was bad, but better than none. Then we had this policy, which is still not perfect, but enabled us to make progress.
Fair enough. I've only attended sporadically in the last few years, so this may well have slipped past me. Mea culpa.
Quite a number of people from various regions insisted on it, at that time, for fear of a "landrush" or "routing table explosion" (routing table slots *are* a scarce resource indeed, but changing this policy to "every LIR in existance today gets one" won't hurt *that* much).
Well the landslide hasn't happened as far as I can see :) Even though I'd love to see it happen. The routing table does need to be considered, but it still is IMO a technical problem. Although it seems there is a shift in v4 policies away from aggregation in favour of conservation (no more reservations for contiguous address space, etc)
The way people work, usually only those who are unhappy take the burden to figure out *where* to voice their unhappiness...
Hmm, reminds me of the recent European elections ;)
So shall we abandon it? In favour of *what* to replace it?
My proposal would be similar to the ARIN (I think) one: Any LIR in good standing is entitled to a /32 with justification for any follow-up allocation. Best regards, Sascha Luck Eirconnect
Today RIPE is trusting you for the 200 customers commitment, but I don't think this is the point. Why not compare with the IPv4 allocations ? Is there any minimum number of customers in x years ? LACNIC, I believe, is also just granting the /32 if you commit to route it in some years (not sure how many), independently of how many customers you bring up. Regards, Jordi ----- Original Message ----- From: "Sascha Luck" <ripe-lst@eirconnect.net> To: <address-policy-wg@ripe.net> Sent: Monday, June 21, 2004 8:04 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
On Monday 21 June 2004 18:31, Gert Doering wrote:
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
I could get native IPv6 connectivity from 3 upstreams today (OK, only from 2 for commercial purposes). TTBOMK, no multihoming facility exists without your own /32 allocation (considering aggregation, probably just as well).
If you are in good hope to reach more than 200 customers, you fulfill the criteria (as has been mentioned before).
Of course, I'm in good hope of reaching that goal. If that's good enough, fine but how do I document this hope? Will the NCC take my word for it? ;)
You are wrong on this :-) - the policy was discussed again and again at various RIPE meetings in the past 5 years. We had an interim policy, which was bad, but better than none. Then we had this policy, which is still not perfect, but enabled us to make progress.
Fair enough. I've only attended sporadically in the last few years, so this may well have slipped past me. Mea culpa.
Quite a number of people from various regions insisted on it, at that time, for fear of a "landrush" or "routing table explosion" (routing table slots *are* a scarce resource indeed, but changing this policy to "every LIR in existance today gets one" won't hurt *that* much).
Well the landslide hasn't happened as far as I can see :) Even though I'd love to see it happen. The routing table does need to be considered, but it still is IMO a technical problem. Although it seems there is a shift in v4 policies away from aggregation in favour of conservation (no more reservations for contiguous address space, etc)
The way people work, usually only those who are unhappy take the burden to figure out *where* to voice their unhappiness...
Hmm, reminds me of the recent European elections ;)
So shall we abandon it? In favour of *what* to replace it?
My proposal would be similar to the ARIN (I think) one: Any LIR in good standing is entitled to a /32 with justification for any follow-up allocation.
Best regards, Sascha Luck Eirconnect
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi, On Mon, Jun 21, 2004 at 08:09:14PM +0200, JORDI PALET MARTINEZ wrote:
Why not compare with the IPv4 allocations ?
Why *do*? What relevance has IPv4 to IPv6 policy? (But actually, the current size of an ISPs network *is* taken into account when considering larger-than-/32 allocations) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi Gert, Because in my opinion, we should not make today any distinction in what the ISP is committing to (in terms of number of customers) to deploy IPv6, same way we don't have this rational with IPv4. Is just IP !, and moreover, we should facilitate the move to IPv6. Furthermore, if an IPv4 LIR/ISP (not end user) is requesting IPv6, not ANY more questions should be asked. If he doesn't route it within a "normal" time frame (5 years, whatever years, or what the market trend self-defines), then RIPE can always claim back the prefix, exactly the same as for IPv4. Right ? As I commented already in one of my previous emails, I will just give a /32 to every LIR/ISP (not end user) unless: 1) He explicitly states "I'm not going to use it" or 2) He request something bigger and properly justify it. I agree that if a bigger than /32 prefix is requested, then we should make sure if this make sense. Regards, Jordi ----- Original Message ----- From: "Gert Doering" <gert@space.net> To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> Cc: <address-policy-wg@ripe.net> Sent: Monday, June 21, 2004 9:04 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Hi,
On Mon, Jun 21, 2004 at 08:09:14PM +0200, JORDI PALET MARTINEZ wrote:
Why not compare with the IPv4 allocations ?
Why *do*? What relevance has IPv4 to IPv6 policy?
(But actually, the current size of an ISPs network *is* taken into account when considering larger-than-/32 allocations)
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
JORDI PALET MARTINEZ wrote: Hi Jordi,
As I commented already in one of my previous emails, I will just give a /32 to every LIR/ISP (not end user) unless: 1) He explicitly states "I'm not going to use it" or 2) He request something bigger and properly justify it.
I totally agree. Why not make a rule like 'only one sTLA per LIR' and 'has to be announced by the LIR itself or its upstream ISP(s)' and give a /32 out to every LIR? - ISPs (as long as they are LIRs, that should be the most of them) could deploy IPv6 without having to lie about their plans for 200 customers. They would not be bound to an upstream more than they are in current IPv4 world. The "has to announce by itself" would stop some kiddies wet dreams of asking their (not IPv6 capable for years) LIR to get a /32 for them to play with. - Companies with LIR status could deploy IPv6 as well. By being LIR and paying LIR fees they sort of help the community out there (more LIRs - more income - perhaps lower RIPE fees for everyone). - Companies without LIR status either have to become LIR (see above) or have to use their upstream's address space with all known consequences. As soon as there is a scalable/usable approach of multi6 there might be some thinking in the companies about whether one could save the LIR fees and go with multi6. Bernhard
Hi All At 03:09 PM 6/21/2004, JORDI PALET MARTINEZ wrote:
Today RIPE is trusting you for the 200 customers commitment, but I don't think this is the point.
Why not compare with the IPv4 allocations ? Is there any minimum number of customers in x years ?
LACNIC, I believe, is also just granting the /32 if you commit to route it in some years (not sure how many), independently of how many customers you bring up.
It is one year and offer some kind of IPv6 services before 24 months after the allocation is made. Full list of initial allocation is as follow To qualify for an initial allocation of IPv6 address space, an organization must: a) Be a LIR or an ISP; b) Not be an end site (end user); c) Document a detailed plan for the services and IPv6 connectivity to be offered to other organizations (clients) d) Announce a single block in the Internet inter-domain routing system, aggregating the total IPv6 address allocation received, within a period not longer than 12 months. e) Offer IPv6 services to clients physically located within the region covered by LACNIC within a period not longer than 24 months. Regards German Valdez LACNIC
Regards, Jordi
----- Original Message ----- From: "Sascha Luck" <ripe-lst@eirconnect.net> To: <address-policy-wg@ripe.net> Sent: Monday, June 21, 2004 8:04 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
On Monday 21 June 2004 18:31, Gert Doering wrote:
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
I could get native IPv6 connectivity from 3 upstreams today (OK, only from 2 for commercial purposes). TTBOMK, no multihoming facility exists without your own /32 allocation (considering aggregation, probably just as well).
If you are in good hope to reach more than 200 customers, you fulfill the criteria (as has been mentioned before).
Of course, I'm in good hope of reaching that goal. If that's good enough, fine but how do I document this hope? Will the NCC take my word for it? ;)
You are wrong on this :-) - the policy was discussed again and again at various RIPE meetings in the past 5 years. We had an interim policy, which was bad, but better than none. Then we had this policy, which is still not perfect, but enabled us to make progress.
Fair enough. I've only attended sporadically in the last few years, so this may well have slipped past me. Mea culpa.
Quite a number of people from various regions insisted on it, at that time, for fear of a "landrush" or "routing table explosion" (routing table slots *are* a scarce resource indeed, but changing this policy to "every LIR in existance today gets one" won't hurt *that* much).
Well the landslide hasn't happened as far as I can see :) Even though I'd love to see it happen. The routing table does need to be considered, but it still is IMO a technical problem. Although it seems there is a shift in v4 policies away from aggregation in favour of conservation (no more reservations for contiguous address space, etc)
The way people work, usually only those who are unhappy take the burden to figure out *where* to voice their unhappiness...
Hmm, reminds me of the recent European elections ;)
So shall we abandon it? In favour of *what* to replace it?
My proposal would be similar to the ARIN (I think) one: Any LIR in good standing is entitled to a /32 with justification for any follow-up allocation.
Best regards, Sascha Luck Eirconnect
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
--- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004
German Valdez LACNIC Potosí 1517 Montevideo 11500 - Uruguay Tel: +598 2 606 2822 Fax: +598 2 601 5509 www.lacnic.net --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004
Hi, On Mon, Jun 21, 2004 at 07:04:28PM +0100, Sascha Luck wrote:
On Monday 21 June 2004 18:31, Gert Doering wrote:
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
I could get native IPv6 connectivity from 3 upstreams today (OK, only from 2 for commercial purposes). TTBOMK, no multihoming facility exists without your own /32 allocation (considering aggregation, probably just as well).
As of today, multihoming with a more-specific from one of your upstreams will work - using the classic BGP multihoming approach. I don't know what the multi6 WG will come up with in the end, but can't really imagine that there is something else which will work for an ISP.
If you are in good hope to reach more than 200 customers, you fulfill the criteria (as has been mentioned before).
Of course, I'm in good hope of reaching that goal. If that's good enough, fine but how do I document this hope? Will the NCC take my word for it? ;)
They have to :-) - in the last 5 years, hardly anybody could be *sure* to have 200 IPv6 customers after two years - but unless you are sure that you won't reach that goal (due to your customer structure, whatever) the underlying goal is "optimism and get IPv6 rolled out". [..]
Quite a number of people from various regions insisted on it, at that time, for fear of a "landrush" or "routing table explosion" (routing table slots *are* a scarce resource indeed, but changing this policy to "every LIR in existance today gets one" won't hurt *that* much).
Well the landslide hasn't happened as far as I can see :) Even though I'd love to see it happen.
Things are moving, and I think the current pace isn't too bad. Too fast will not necessarily help...
The routing table does need to be considered, but it still is IMO a technical problem. Although it seems there is a shift in v4 policies away from aggregation in favour of conservation (no more reservations for contiguous address space, etc)
Let's not discuss IPv4 policy in this thread (but I agree). [..]
So shall we abandon it? In favour of *what* to replace it?
My proposal would be similar to the ARIN (I think) one: Any LIR in good standing is entitled to a /32 with justification for any follow-up allocation.
Well, initially all regions had the "200 customers" rule (which made the whole process difficult, because the goal was a *global* policy). I need to check whether this has changed recently in one of the other regions. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Monday 21 June 2004 19:37, Gert Doering wrote:
Well, initially all regions had the "200 customers" rule (which made the whole process difficult, because the goal was a *global* policy).
I need to check whether this has changed recently in one of the other regions.
AFAIK, ARIN still have the 200 customer policy, the "good standing" is what they are proposing to change it to (it came up in discussion at RIPE-48) rgds, Sascha Luck
Hi, On Mon, Jun 21, 2004 at 08:00:57PM +0100, Sascha Luck wrote:
I need to check whether this has changed recently in one of the other regions.
AFAIK, ARIN still have the 200 customer policy, the "good standing" is what they are proposing to change it to (it came up in discussion at RIPE-48)
OK. How exactly do you define "good standing"? This needs to be something that a RIR hostmaster can base a decision on...? Personally, I like Oliver Bartels' proposal. :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Monday 21 June 2004 20:06, Gert Doering wrote: Hi Gert,
OK. How exactly do you define "good standing"? This needs to be something that a RIR hostmaster can base a decision on...?
In UK/Ireland a "member in good standing" is defined as someone who "have all their fees paid and have no disciplinary action pending" ;) I *think* what ARIN meant was an established LIR
Personally, I like Oliver Bartels' proposal. :-)
Yes, I would sign that, too. rgds, Sascha Luck -- DDO Eirconnect
In UK/Ireland a "member in good standing" is defined as someone who "have all their fees paid and have no disciplinary action pending" ;) I *think* what ARIN meant was an established LIR
In the ARIN region we have LIRs who received their allocation from SRI-NIC or the Internic in the distant past. These LIRs pay no fees to ARIN and may not even maintain their contact data. The reason I suggested that we only issue IPv6 to LIRs in good standing was to give these LIRs a reason to join ARIN. It's not just about the money. It's about getting everyone in the industry to work together to maintain fair adressing policies. --Michael Dillon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 20.37, Gert Doering wrote:
If you are in good hope to reach more than 200 customers, you fulfill the criteria (as has been mentioned before).
Of course, I'm in good hope of reaching that goal. If that's good enough, fine but how do I document this hope? Will the NCC take my word for it? ;)
They have to :-) - in the last 5 years, hardly anybody could be *sure* to have 200 IPv6 customers after two years - but unless you are sure that you won't reach that goal (due to your customer structure, whatever) the underlying goal is "optimism and get IPv6 rolled out".
Actually, what is a customer? Someone who pays for service? Or are we talking allocations made to non-infrastructure-or-owned-entities ? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNfIK6arNKXTPFCVEQKgLwCdERdqetnMSwZbv0fr0xXNrnHnYPIAoOQq imOnTuWrKexenj7R76bfm9H9 =zxqL -----END PGP SIGNATURE-----
Hi, On Mon, 21 Jun 2004 19:31:41 +0200, Gert Doering wrote:
In fact, I have not heard anyone stand up and say "WE MUST KEEP THE 200 CUSTOMER RULE!" - most people voiced some sort of "well, it's there, it doesn't do much harm, we can live with it", but nobody has actively stood up in favour of it. Has anyone?
So shall we abandon it? In favour of *what* to replace it? My suggestion: "To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site; c) plan to provide IPv6 connectivity to non-affiliated organisations to which it will assign parts of this address space according to the RIPE policy; and d) plan to provide IPv6 connectivity to a significant part of their non-affiliated customer base by advertising such connectivity through its single aggregated address allocation"
There is no well defined check for c) and d) (which is the same as the 200 customers limit, *of course* we all *plan* to provide connectivity to millions of very well paying IPv6 customers and would like to gain the income, however the reality in the market tells us something different). However it gives the NCC some chance to ask questions about allocations to "we need this rare resource" non-ISP organisations. However "ceterum censeo": The multihoming-without-renumbering problem must be solved *for such organisations* or IPv6 *won't* gain a significant market share. This is because e.g. Banks are not ISP's and clearly won't qualify for an allocation in most cases, *however* they won't give up their ISP independence gained by their LIR or PI status. And e.g. home banking might be some important argument for most customers ... Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gert,
*One* person is taking major offence at not being allowed to play with the big boys.
Condescension will get us nowhere. Ok, we're a small ISP in a small market. Since we aim at the business/leased line market only, we may not have 200 customers, let alone 200 IPv6 allocations, within 2 years (I hope to be wrong, of course). Give me *one* good reason why we shouldn't be allowed to offer IPv6 connectivity? Give me a reason why we should lose *one*, otherwise happy, customer because of an arbitrary "line in the sand"?
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber.
So shall we abandon it?
Yes.
In favour of *what* to replace it?
RIR membership. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNfHOqarNKXTPFCVEQKtOQCg1zOZF0IUfjui3Vdgzf2A/f4HWZIAn1gC 8JG8Zg7yMx6efCwdGb8OpZoy =PTYp -----END PGP SIGNATURE-----
Hi, On Tue, Jun 22, 2004 at 07:44:23AM +0200, Kurt Erik Lindqvist wrote:
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber.
As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy. Admittedly, if changing the upstream, his customers would need to be renumbered (but this is not too different from IPv4 today with "very small ISPs that do not want to become LIR" - they use upstream space for a couple of years, and eventually become LIR and have to renumber). I can see that people don't like it, I'm just mentioning that it *could* be done. We will need to do something like that for the class "is ISP but is not LIR", even if we abandon the 200-users rule.
So shall we abandon it? Yes.
In favour of *what* to replace it? RIR membership.
I'm still waiting for someone to yell "WE MUST KEEP THIS RULE!!!"... :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Jun 22, 2004 at 08:45:29AM +0200, Gert Doering wrote:
Hi,
On Tue, Jun 22, 2004 at 07:44:23AM +0200, Kurt Erik Lindqvist wrote:
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber.
As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy.
Can you personaly garantee the upstream suplying the space won't aggregate his prefix ? If you can't this just turned a nice IPv6 space rental setup. -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Hi, On Tue, Jun 22, 2004 at 11:08:09AM +0100, Carlos Morgado wrote:
This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber. As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy.
Can you personaly garantee the upstream suplying the space won't aggregate his prefix ?
And if he does, so what? He will loose traffic, as the *other* ISP will make the more specific visible world-wide, and thus no paid-for packets will arrive at the aggregating upstream. Using a more-specific block out of PA space is a well-established technique in IPv4 today. It's not "beautiful", but it works better than other variants.
If you can't this just turned a nice IPv6 space rental setup.
Huh? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Jun 22, 2004 at 12:29:06PM +0200, Gert Doering wrote:
If you can't this just turned a nice IPv6 space rental setup.
Huh?
We'll see upstreams that don't actually sell good connectivity but just rent space disguised as bad cheap connectivity. -- Carlos Morgado <chbm@cprm.net> - Internet Engineering GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Hi, On Tue, Jun 22, 2004 at 11:58:15AM +0100, Carlos Morgado wrote:
On Tue, Jun 22, 2004 at 12:29:06PM +0200, Gert Doering wrote:
If you can't this just turned a nice IPv6 space rental setup. Huh? We'll see upstreams that don't actually sell good connectivity but just rent space disguised as bad cheap connectivity.
So what can we do about it? Just dropping the 200-customers rules won't change the fact that some people will always want address space with the community saying "*you* can't get an allocation from your RIR". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 12.29, Gert Doering wrote:
On Tue, Jun 22, 2004 at 11:08:09AM +0100, Carlos Morgado wrote:
This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber. As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy.
Can you personaly garantee the upstream suplying the space won't aggregate his prefix ?
And if he does, so what? He will loose traffic, as the *other* ISP will make the more specific visible world-wide, and thus no paid-for packets will arrive at the aggregating upstream.
Using a more-specific block out of PA space is a well-established technique in IPv4 today. It's not "beautiful", but it works better than other variants.
Well, in todays IPv4 world people are also taking PA blocks and advertise them as individual /24s, just to implement policy. I am not sure that is so much better than just giving the LIRs a /32. Those who are to small to become LIRs? Though luck. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgcxKarNKXTPFCVEQKErwCdEMKuZqc8p28+Balrh6FLurHR6boAn2SQ MYTctDKhAqzgdRCIcn4XhOyX =y9Kr -----END PGP SIGNATURE-----
Hi Gert, all, On Tuesday 22 June 2004 07:45, Gert Doering wrote:
As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy.
It's certainly a work-around if all else fails. I'm not sure it should be *encouraged* though, since announcing more-specific routes flies in the face of aggregation. Besides, don't most people filter on allocation boundaries? rgds, Sascha Luck -- DDO Eirconnect
Hi, On Tue, Jun 22, 2004 at 12:23:50PM +0100, Sascha Luck wrote:
On Tuesday 22 June 2004 07:45, Gert Doering wrote:
As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy.
It's certainly a work-around if all else fails. I'm not sure it should be *encouraged* though, since announcing more-specific routes flies in the face of aggregation.
Having more-specifics for multihomed (and only those!) customers doesn't mean the rest of the block must be deaggregated. The impact on the routing table is, at worst, the same as in "you get your own prefix and announce that world-wide". At best, the customer might eventually cease to be multihomed, and the more-specific goes away.
Besides don't most people filter on allocation boundaries?
Most people don't filter at all. Of those that do, some filter on allocations, and some permit up to /48s. Which doesn't break anything in that model - the aggregate is there, so packets travel in the right direction. "Near to the network in question", chances are high that more-specifics *are* visible, and thus the packets can reach their destination. Nobody can *guarantee* anything anyway. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Jun 22, 2004 at 08:45:29AM +0200, Gert Doering wrote:
This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber. As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy.
Maybe I have lost you somewhere now: You only get an assignement when you are a big one (>200 customers). That is to keep the routing table smaller. Because that does not work for small ISPs (see above) they announce a route for a smaller network (that was assigned to him from his upstream provider). So we have one /32 route less, one /40 route more or something like that. Doesn't seem to save much space in the routing table?
Admittedly, if changing the upstream, his customers would need to be renumbered (but this is not too different from IPv4 today with "very small ISPs that do not want to become LIR" - they use upstream space for a couple of years, and eventually become LIR and have to renumber).
It is an absolute pain in the ass. And it will be in the future. Yes, the mechanisms to make it easy are in place, but they are not implemented. Renumbering is NOT EASY. It costs a hell lot of money, each time it has to be done.
I can see that people don't like it, I'm just mentioning that it *could* be done. We will need to do something like that for the class "is ISP but is not LIR", even if we abandon the 200-users rule.
I would change that to "is mutlihomed but is not LIR". Even without being an ISP you can easily run into the same problems. And I do not want to be in charge at Siemens, GM, Nortel, Cisco or so for renumbering projects. With using globally unique addresses in the organization (and being able to do that is one of the advantages of IPv6 - using site local and NAT does not make sense, I can stay at v4 then) makes it even worse. Now renumbering of official Adresses "only" means changing everything about external communication. Nils
Hi, On Tue, Jun 22, 2004 at 08:16:40AM -0400, Nils Ketelsen wrote:
On Tue, Jun 22, 2004 at 08:45:29AM +0200, Gert Doering wrote:
This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber. As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy.
Maybe I have lost you somewhere now: You only get an assignement when you are a big one (>200 customers).
Yes.
That is to keep the routing table smaller.
"Because the community wanted to have it this way".
Because that does not work for small ISPs (see above) they announce a route for a smaller network (that was assigned to him from his upstream provider).
So we have one /32 route less, one /40 route more or something like that. Doesn't seem to save much space in the routing table?
Not that much. One could apply more-specific filters to routes coming from other regions, so it *would* save something. Or the customer might eventually decide to cease to multihome, and the more-specific gets folded back into the aggregate - and this *does* happen, two of our customers did this in the past couple of years, and we're not one of the "really big" ISPs. [..]
Admittedly, if changing the upstream, his customers would need to be renumbered (but this is not too different from IPv4 today with "very small ISPs that do not want to become LIR" - they use upstream space for a couple of years, and eventually become LIR and have to renumber).
It is an absolute pain in the ass. And it will be in the future. Yes, the mechanisms to make it easy are in place, but they are not implemented. Renumbering is NOT EASY. It costs a hell lot of money, each time it has to be done.
Announcing your routes to the whole world also costs "a hell of a lot of money". Not your money, of course, but everyone elses. So pain needs to be balanced.
I can see that people don't like it, I'm just mentioning that it *could* be done. We will need to do something like that for the class "is ISP but is not LIR", even if we abandon the 200-users rule.
I would change that to "is mutlihomed but is not LIR". Even without being an ISP you can easily run into the same problems. And I do not want to be in charge at Siemens, GM, Nortel, Cisco or so for renumbering projects.
So what is your propsal for a new policy, then? "Everybody who is special gets their own allocation?" Which makes it very simple, as long as you can define "special". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote:
I can see that people don't like it, I'm just mentioning that it *could* be done. We will need to do something like that for the class "is ISP but is not LIR", even if we abandon the 200-users rule. I would change that to "is mutlihomed but is not LIR". Even without being an ISP you can easily run into the same problems. And I do not want to be in charge at Siemens, GM, Nortel, Cisco or so for renumbering projects.
So what is your propsal for a new policy, then?
"Everybody who is special gets their own allocation?"
I personally would like to see "Everybody who wants it gets an allocation", but I see the technical limitations. But I agree with Oliver in so far, as I can not see IPv6 deployment in major organisations without giving them advantages over IPv4. This is an economical limitation. So now the question is: Should the policy try to fix the technical problem and then we wait for economics to change, or should the policy try to fix the economical problem and we wait for technology to change? Given the pace of change in these two field, I think it is more likely that technicians come up with a solution being able to handle billions of routes, then economy doing something that costs money to lose a benefit. Currently working on the next budget I again (like the last two years) think about budgeting for the move v4 to v6 (or more precisely for its start, as this will never be done within one year). And though my technically intereted heart would love to do it, the brain kicks in: There is absolutely no reason, it costs money, it does not give you any advantage. I think the policy, concentrating on technical issues, actually makes IPv6 less attractive. Nils -- C: Ich möchte nicht länger "Junge" genannt werden. Ich finde den Ausdruck demütigend und sexistisch. H: Wie möchtest Du dann genannt werden? [aus "Calvin and Hobbes" C: "Genetisch bevorzugter Jugendlicher". by Watterson]
On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote:
Not that much. One could apply more-specific filters to routes coming from other regions, so it *would* save something. Or the customer might
What's this "regions" you speak about ? We're a fairly small (in the global scheme of things) transit provider and we're connected to 4 continents. Are you thinking about toy ISPs with one transit and a connection to the local IX ? -- Carlos Morgado <chbm@cprm.net> - Internet Engineering GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Hi, On Tue, Jun 22, 2004 at 03:05:08PM +0100, Carlos Morgado wrote:
On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote:
Not that much. One could apply more-specific filters to routes coming from other regions, so it *would* save something. Or the customer might
What's this "regions" you speak about ? We're a fairly small (in the global scheme of things) transit provider and we're connected to 4 continents. Are you thinking about toy ISPs with one transit and a connection to the local IX ?
I was speaking of RIR regions (which is the only thing that a router can filter on, provided ICANN will eventually start allocating decent chunks). Of course ISPs that are connected to all the regions will need to carry all more-specifics. Tough, cost of making business. There are different ISPs out there - those that are obviously large enough to not be called "toy ISPs", but still only active in one or two regions - so why should an ISP that's only active in the US carry more specifics from APNIC or Europe? Or vice versa? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Jun 22, 2004 at 09:06:12PM +0200, Gert Doering wrote:
Hi,
On Tue, Jun 22, 2004 at 03:05:08PM +0100, Carlos Morgado wrote:
On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote:
Not that much. One could apply more-specific filters to routes coming from other regions, so it *would* save something. Or the customer might
What's this "regions" you speak about ? We're a fairly small (in the global scheme of things) transit provider and we're connected to 4 continents. Are you thinking about toy ISPs with one transit and a connection to the local IX ?
I was speaking of RIR regions (which is the only thing that a router can filter on, provided ICANN will eventually start allocating decent chunks).
Exactly. All this discussion becomes somewhat moot if the trend of /23s goes on much longer. Not to mention you lose hope of being able to recognize where an address is supposed to be without db lookups, but that's out of this scope.
There are different ISPs out there - those that are obviously large enough to not be called "toy ISPs", but still only active in one or two regions - so why should an ISP that's only active in the US carry more specifics from APNIC or Europe? Or vice versa?
Fair enough.
From a routing perspective, if you have 2 transit providers and ask them to announce default + clients/direct peerings you get a somewhat similar situation to IPv6 RIR prefixes + local specifics. Or am I missing something ?
-- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Kurt Erik Lindqvist;
If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed).
This doesn't fly. He can't set his own routing policy and he can't multihome.
Kurt, as I made presentation in front of you and Brian Carpenter at multi6 WG meeting of IETF58 in Minneapolis on Nov. 2003, it is possible for a small ISP delegated address blocks from multiple larger ISPs and can still have its own policy. Since then, you made no counter argument against my presentation that it is your fallacy to say things against the presentation. For those of you who are not familiar with my (expired) draft used at the meeting, it is available at: http://www.watersprings.org/pub/id/draft-ohta-multihomed-isps-00.txt The interim conclusion of the draft is: Thus, it is not essential that ISPs have their own TLAs.
If he changes the single upstream his customers needs to renumber.
If one changes homing, one needs to renumber, of course. But, it has nothing to do with multihoming or hierarchical ISPs. Just as we shouldn't discourage customers change ISPs, we shouldn't discourage ISPs change upper level ISPs.
So shall we abandon it?
Yes.
No.
In favour of *what* to replace it?
RIR membership.
No. It is proven not to scale. Does it mean that it is beneficial for you if RIRs have more power even though it sacrifices ISPs and users of the Internet by requiring routers with a lot more routing table entries than necessary? Masataka Ohta
Hi, On Tue, Jun 22, 2004 at 08:30:34PM +0900, Masataka Ohta wrote:
In favour of *what* to replace it? RIR membership. No. It is proven not to scale.
"Proven"? When, where, by whom, based on what data? There are less than 10.000 LIRs in existance today, all RIRs combined. So that would be a maximum of 10.000 routing table entries (if we can manage to keep it at "1 prefix per LIR").
Does it mean that it is beneficial for you if RIRs have more power even though it sacrifices ISPs and users of the Internet by requiring routers with a lot more routing table entries than necessary?
10.000 routing table entries is something far below the near 140.000 we have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 routes, it *does* scale up to fairly insane numbers. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, 22 Jun 2004 13:49:12 +0200, Gert Doering wrote:
"Proven"? When, where, by whom, based on what data?
There are less than 10.000 LIRs in existance today, all RIRs combined.
So that would be a maximum of 10.000 routing table entries (if we can manage to keep it at "1 prefix per LIR"). Full Ack.
A table of this size is handled with a one cycle memory access in modern routing hardware. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Oliver Bartels:
So that would be a maximum of 10.000 routing table entries (if we can manage to keep it at "1 prefix per LIR").
Full Ack.
A table of this size is handled with a one cycle memory access in modern routing hardware.
By definition of "one cycle memory access", any table of any size can be handled with a one cycle memory access in any routing hardware. However, memory access cycle can be a lot larger than a CPU clock cycle. On typical modern chips, tens of registers can be accessed within a CPU cycle. On chip primary cache with thousands of entries needs about twice or three times more than that. Off chip cache needs about ten, twenty or, maybe, hundred more to access. Masataka Ohta
Masataka Ohta wrote:
Oliver Bartels:
So that would be a maximum of 10.000 routing table entries (if we can manage to keep it at "1 prefix per LIR").
Full Ack.
A table of this size is handled with a one cycle memory access in modern routing hardware.
By definition of "one cycle memory access", any table of any size can be handled with a one cycle memory access in any routing hardware.
However, memory access cycle can be a lot larger than a CPU clock cycle.
On typical modern chips, tens of registers can be accessed within a CPU cycle. On chip primary cache with thousands of entries needs about twice or three times more than that. Off chip cache needs about ten, twenty or, maybe, hundred more to access.
If I get this correctly you seem to argue that because todays hardware is "slow" and/or "inefficient" for large routing tables IPv6 multi- homing should not be allowed? This way at looking things in fundamentally broken. The need for speed has started many developments we enjoy today. I am sure engineers will find good and efficient ways to deal with large routing tables at high speeds. Just look at the last ten years. In 1994 a T3 was like "wow!". Today n-times 10Gig is "wow!". Go ahead and technology will follow. -- Andre
On Tue, 22 Jun 2004 21:26:30 +0900, Masataka Ohta wrote:
However, memory access cycle can be a lot larger than a CPU clock cycle. With 10000 prefixed put in in a TCAM and get a result per pipeline cycle. This means 100M packet lookups per second, which is sufficient for >10G. TCAM does the complete prefix lookup in one cycle. It's limit by price is the table size (typically 64K to 256K). If it is combined with regular RAM (per cluster table), someone can select millions of prefixes *pipelined* within few accesses in a fully pipelined architecture in the >=10G and >=100Mpps range.
On typical modern chips, tens of registers can be accessed within a CPU cycle. On chip primary cache with thousands of entries needs about twice or three times more than that. Off chip cache needs about ten, twenty or, maybe, hundred more to access. Modern Routers no longer use traditional CPU/cache architectures. Either fast static RAM together with trie structures (e.g. patricia tree/radix tree) or TCAM is used together with highly pipelined processors.
Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Oliver Bartels;
However, memory access cycle can be a lot larger than a CPU clock cycle.
With 10000 prefixed put in in a TCAM and get a result per pipeline cycle. This means 100M packet lookups per second, which is sufficient for >10G. TCAM does the complete prefix lookup in one cycle.
I know. Do you know that the current Internet backbone is operating with parallel 10Gs?
It's limit by price is the table size (typically 64K to 256K).
So, large memory costs. Do you also know that access speed of memory (including but not limited to TCAM) degrades proportional to log or sqrt of the number of entries?
If it is combined with regular RAM (per cluster table), someone can select millions of prefixes *pipelined* within few accesses in a fully pipelined architecture in the >=10G and >=100Mpps range.
I know. And, it costs a lot.
On typical modern chips, tens of registers can be accessed within a CPU cycle. On chip primary cache with thousands of entries needs about twice or three times more than that. Off chip cache needs about ten, twenty or, maybe, hundred more to access.
Modern Routers no longer use traditional CPU/cache architectures. Either fast static RAM together with trie structures (e.g. patricia tree/radix tree) or TCAM is used together with highly pipelined processors.
Both modern routers and modern CPUs are highly pipelined, which means there is some performance loss if TCAM or primary cache miss occurs. Secondary or third level cache of modern CPUS often have millions of entries and constructed with static RAM. Masataka Ohta
On Tue, 22 Jun 2004 22:41:20 +0900, Masataka Ohta wrote:
Do you know that the current Internet backbone is operating with parallel 10Gs? Someone may stretch the term "backbone". There is no single one. Some use OC-3 and some use OC-192, some plan to use 40G (and caclculate wavelength counts against bandwidth occupied by a single wavelength).
So, large memory costs. Not really.
Todays price, single pcs., IDT/-100 at Arrow for 64K*72 TCAM: $155 from stock. If someone operates a major backbone, this is no real cost factor compared to leased lines and wavelengths ... Even if you multiply this with five for sales droid financing ... Fast synchronous static memory is even *much* less, e.g. few $'s per Multi-Mbit chip.
Do you also know that access speed of memory (including but not limited to TCAM) degrades proportional to log or sqrt of the number of entries? Again, it depends ...
Both modern routers and modern CPUs are highly pipelined, which means there is some performance loss if TCAM or primary cache miss occurs. A *cached* router is a good-weather-only product which would die e.g. if a DDoS or SQL Slammer is on the road.
Secondary or third level cache of modern CPUS often have millions of entries and constructed with static RAM. Which again tells us that 10K is not a real limit for modern routers, as well as 100K is not. Noone would buy a *new* backbone router which isn't capable to handle a n*100K table even if there is "rain and snow" inside
Thus modern backbone routers *do not use route caches*. the network ... Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Oliver Bartels;
Do you know that the current Internet backbone is operating with parallel 10Gs?
Someone may stretch the term "backbone". There is no single one.
There is 10G backbone with paralle routes operated at least one ISP in Japan.
So, large memory costs.
Not really.
Todays price, single pcs., IDT/-100 at Arrow for 64K*72 TCAM: $155 from stock.
Instllation of chips, especially those operating at highest possible speed, costs a lot more than that. If it is not on chip, you lose, a lot.
If someone operates a major backbone, this is no real cost factor compared to leased lines and wavelengths ...
If country backbone is as slow as 10G, maybe. However... In Japan, today, several Kms of dark fiber costs tens of USD/month.
Even if you multiply this with five for sales droid financing ...
Internet grows faster than any sales droid can understand.
Fast synchronous static memory is even *much* less, e.g. few $'s per Multi-Mbit chip.
As it is off the chip, you automarically lose.
Do you also know that access speed of memory (including but not limited to TCAM) degrades proportional to log or sqrt of the number of entries?
Again, it depends ...
It depends? I'm saying how it depends. It, of course, is not a problem, if and only if the routing table size has hard limit.
Both modern routers and modern CPUs are highly pipelined, which means there is some performance loss if TCAM or primary cache miss occurs.
A *cached* router is a good-weather-only product which would die e.g. if a DDoS or SQL Slammer is on the road.
That's why the global routing table must be small.
Thus modern backbone routers *do not use route caches*.
I know. Who suggested route cache? I didn't.
Secondary or third level cache of modern CPUS often have millions of entries and constructed with static RAM.
Which again tells us that 10K is not a real limit for modern routers, as well as 100K is not.
It merely means that it costs, especially when you do off chip interleaving with a lot of wiring.
Noone would buy a *new* backbone router which isn't capable to handle a n*100K table even if there is "rain and snow" inside the network ...
That was a valid argument for IPv4. Masataka Ohta
Gert Doering wrote:
In favour of *what* to replace it?
RIR membership.
No. It is proven not to scale.
"Proven"? When, where, by whom, based on what data?
There are less than 10.000 LIRs in existance today, all RIRs combined.
According to my upper bound, it's already unnecessarily too large.
10.000 routing table entries is something far below the near 140.000 we have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 routes, it *does* scale up to fairly insane numbers.
Of course, you can have as many routing table entries as you want, as long as backbone routers, speed of which degrade as their routing table bloat, have large enough routing table. However, routing table does cost. High speed memory for backbone routers costs a lot. The cost must be paid by ISPs and, then, by users. If the size of global routing table is limited by a hard upper bound, it simplifies the design of routers a lot (you can put a backbone router (or many of them) with a global routing table in a chip), reduces cost of routers a lot and increases speed of routers a lot. Note that, for scalable (thus, end to end) site multihoming properly work, all the sites are required to circulate global routing table within the sites. Masataka Ohta
Hi, On Tue, Jun 22, 2004 at 09:18:05PM +0900, Masataka Ohta wrote:
Gert Doering wrote:
In favour of *what* to replace it?
RIR membership.
No. It is proven not to scale.
"Proven"? When, where, by whom, based on what data? There are less than 10.000 LIRs in existance today, all RIRs combined. According to my upper bound, it's already unnecessarily too large.
So the *proof* mentioned above consists of "your personal feelings what the upper limit on the routing table size should be"? While I honour your feelings (I also think that the routing table shouldn't grow out of bounds), this is no "proof" that it's not going to scale. Also it brings back the problem of "who is worthy enough to receive one of 8192 TLAs", which was abandoned some 5 years ago, because there is no entity that can make this decision.
10.000 routing table entries is something far below the near 140.000 we have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 routes, it *does* scale up to fairly insane numbers.
Of course, you can have as many routing table entries as you want, as long as backbone routers, speed of which degrade as their routing table bloat, have large enough routing table.
Of course. But I tend to believe if people tell me "10k routes are no problem today". Oliver is building routers, with fast memory, and good routing table lookup algorithms. Today, high end routers can handle 140k routes. [..]
If the size of global routing table is limited by a hard upper bound, it simplifies the design of routers a lot (you can put a backbone router (or many of them) with a global routing table in a chip), reduces cost of routers a lot and increases speed of routers a lot.
This is not going to work. *Inside* your AS, you will always have some more routes, and depending on the quality of your IGP aggregation, you might easily end up with more than 10k *internal* routes. So no matter what upper bound you put on the external routes, you cannot assume that nobody will ever need more routing table entries. Out of interest: what number do you suggest for the hard upper bound?
Note that, for scalable (thus, end to end) site multihoming properly work, all the sites are required to circulate global routing table within the sites.
Actually, no. Not even in IPv4 today (which is part of the problem, that you can inject your prefix from a Cisco 2500 router, while everyone else needs to buy $costly hardware to *carry* your prefix). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering;
According to my upper bound, it's already unnecessarily too large.
So the *proof* mentioned above consists of "your personal feelings what the upper limit on the routing table size should be"?
No. I gave the upper bound considering the current number of unit of global policies ((UN approved) countries and (self qualified) tier1 providers) and concluded 1000 is large enough.
While I honour your feelings (I also think that the routing table shouldn't grow out of bounds), this is no "proof" that it's not going to scale.
As you agree that there should be bounds, any policy not incorporating the bounds does not scale. QED.
Also it brings back the problem of "who is worthy enough to receive one of 8192 TLAs", which was abandoned some 5 years ago, because there is no entity that can make this decision.
But, we have entities to define address allocation rules. So, it is merely an issue to have an agreeable rule. For example, assign 3 TLAs to NICs operating ccTLDs. NICs of countries are assigned one more for each population of 10 million. Then, have 500 for initial auction with lease period of a year with 10 more supplied monthly for 5 years. There will be about 2,000 TLAs, yet.
Of course. But I tend to believe if people tell me "10k routes are no problem today". Oliver is building routers, with fast memory, and good routing table lookup algorithms.
Be careful. I'm not offending Oliver. But, it should be noted that, in general, router vendors, especially large ones, want to keep their product as expensive as possible. And, now, though I may offend Oliver, router engineers do their work in a way they have been doing. So, it is possible to have a router with 10k routes today and tomorrow. But, it will costs almost as much as today even in tomorrow. However, it is a lot less expensive if global routing can be performed only by looking 13 bits of the address. There is no associative memory necessary. It's just a memory of 8K entry with no associativity. I think it is still reasonable to have an associative memory of, say, 1K entry, for local routing.
Today, high end routers can handle 140k routes.
How much does it costs? How much do low end routers with 1G ethernet interfaces costs?
If the size of global routing table is limited by a hard upper bound, it simplifies the design of routers a lot (you can put a backbone router (or many of them) with a global routing table in a chip), reduces cost of routers a lot and increases speed of routers a lot.
This is not going to work. *Inside* your AS, you will always have some more routes,
Sure. It does work. See above.
and depending on the quality of your IGP aggregation, you might easily end up with more than 10k *internal* routes.
It's a poor operation, which costs.
So no matter what upper bound you put on the external routes, you cannot assume that nobody will ever need more routing table entries.
Those requiring a lot IGP entries should pay the cost by themselves.
Out of interest: what number do you suggest for the hard upper bound?
8K for the global routing table, though I think, with reasons, 1K is large enough.
Note that, for scalable (thus, end to end) site multihoming properly work, all the sites are required to circulate global routing table within the sites.
Actually, no. Not even in IPv4 today (which is part of the problem, that you can inject your prefix from a Cisco 2500 router, while everyone else needs to buy $costly hardware to *carry* your prefix).
Yes and no. IPv4 today is hopeless, because of legacy randomized allocation of class Cs, which is why multi6 is not multi4. The charter of multi6 says: but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following is explicitly not written as co-chair of the IETF multi6 WG.
Kurt, as I made presentation in front of you and Brian Carpenter at multi6 WG meeting of IETF58 in Minneapolis
I think I have seen close to 40 presentations that all would solve the multihoming problem one way or the other, or at least parts of it.
on Nov. 2003, it is possible for a small ISP delegated address blocks from multiple larger ISPs and can still have its own policy.
It's possible for a small ISP to get several blocks from their upstream, route them inside their network and assign each of their customers with an address out of each of those blocks. Does it scale? Nope. Can it handle failures in the upstream? No. Etc.
Since then, you made no counter argument against my presentation that it is your fallacy to say things against the presentation.
There are several of the proposals in multi6 that have never received comments, nor support of any kind.
For those of you who are not familiar with my (expired) draft used at the meeting, it is available at:
http://www.watersprings.org/pub/id/draft-ohta-multihomed-isps-00.txt
The interim conclusion of the draft is:
Thus, it is not essential that ISPs have their own TLAs.
Your document does not address the criterias for being classified in a particular category. It does not address what would happen if an ISP grow, get's split/divided. It does not address what the financial models for transit would be. It does not address the non-balance of local vs global traffic coverage. It does not take into account the current peering economics of the Internet. So it's really hard to say anything regarding it.
If he changes the single upstream his customers needs to renumber.
If one changes homing, one needs to renumber, of course.
Which is a limiting factor that I think you will that customers will find unacceptable.
But, it has nothing to do with multihoming or hierarchical ISPs.
Just as we shouldn't discourage customers change ISPs, we shouldn't discourage ISPs change upper level ISPs.
Having to renumber when chaining ISPs is not to discourage _change_ of ISP. It's to discourage signing up with that ISP in the first place.
In favour of *what* to replace it?
RIR membership.
No. It is proven not to scale.
In what way?
Does it mean that it is beneficial for you if RIRs have more power even though it sacrifices ISPs and users of the Internet by requiring routers with a lot more routing table entries than necessary?
I am not following this. In what way would the RIRs get more "power"? The policies of the RIRs is set by the RIR community. We are having a lot more routing entries today than we need to, and people seems to think it is a good idea. Actually it is today used to implement policies that follow requirements set by users to their ISPs. Users that pay to get that policy. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgi/aarNKXTPFCVEQIAcQCfYowvBqwQ8MRQusq68q1OBTkKdwkAoPTb zVVRNw/ZJa4p6sGXKMM20RRC =DMSt -----END PGP SIGNATURE-----
Kurt Erik Lindqvist;
Kurt, as I made presentation in front of you and Brian Carpenter at multi6 WG meeting of IETF58 in Minneapolis
I think I have seen close to 40 presentations that all would solve the multihoming problem one way or the other, or at least parts of it.
40? Below is the agenda of the last Minneapolis meeting. Agenda bashing, Chairs (5 min) DT2 Update, David&Marcelo (5 min) DT1 Update, Tony&Iljitsch (5 min) MAST, Dave Crocker (15 min) draft-arifumi-tcp-mh-00, Arifumi Matsumoto (10 min) draft-ohta-multihomed-isps-00, Masataka Ohta (15 min) draft-ohira-assign-select-e2e-multihome-02, Kenji Ohira (10 min) LIN6 update, Masahiro Ishiyama (5 min) draft-nordmark-multi6-threats-00, Erik Nordmark (5 min) draft-nordmark-multi6-noid-01 and draft-nordmark-multi6-sim-01, Erik Nordmark (10 min) Update from chairs and where we go next Open microphone There were a lot less than 40 presentations and the number of proposals was even less.
on Nov. 2003, it is possible for a small ISP delegated address blocks from multiple larger ISPs and can still have its own policy.
It's possible for a small ISP to get several blocks from their upstream, route them inside their network and assign each of their customers with an address out of each of those blocks. Does it scale? Nope. Can it handle failures in the upstream? No. Etc.
First of all, the small ISPs have multiple upstream ISPs. It is explicitly stated in my draft, which is 3 pages long: It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites. NLI is an acronym of "Next Level ISP".
Since then, you made no counter argument against my presentation that it is your fallacy to say things against the presentation.
There are several of the proposals in multi6 that have never received comments, nor support of any kind.
That's fine, as long as you are indifferent to the issue. However, as you actively made statement against my draft, you are guilty.
Your document does not address the criterias for being classified in a particular category.
My document does address the criteria for being classified in TLI. Classification as NLI is up to TLIs.
It does not address what would happen if an ISP grow, get's split/divided.
No, of course. What if, an ISP having a global routing table entry grow, get's split/divided? The issue is orthogonal to my draft.
It does not address what the financial models for transit would be.
No, of course. It is a policy issue orthogonal to my draft.
It does not address the non-balance of local vs global traffic coverage.
No, of course. For TLI, only the global traffic is important.
It does not take into account the current peering economics of the Internet.
No, of course. It is a policy issue orthogonal to my draft.
So it's really hard to say anything regarding it.
which means you have been indifferent to multi6 issues.
If he changes the single upstream his customers needs to renumber.
If one changes homing, one needs to renumber, of course.
Which is a limiting factor that I think you will that customers will find unacceptable.
Huh? What can the customer do, then? Note that it is not acceptable for the customer to switch to other ISP only to change its address.
Having to renumber when chaining ISPs is not to discourage _change_ of ISP. It's to discourage signing up with that ISP in the first place.
What if an ISP bankrupts (like UUNET) and stop operating? Are you saying to discourage signing up with any ISP which may possibly stop operating in the future? Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
There were a lot less than 40 presentations and the number of proposals was even less.
Since the first meeting in Vienna there have been a lot more presentations. I didn't say anything about Minneapolis. Whatever.
on Nov. 2003, it is possible for a small ISP delegated address blocks from multiple larger ISPs and can still have its own policy.
It's possible for a small ISP to get several blocks from their upstream, route them inside their network and assign each of their customers with an address out of each of those blocks. Does it scale? Nope. Can it handle failures in the upstream? No. Etc.
First of all, the small ISPs have multiple upstream ISPs.
Yes?
It is explicitly stated in my draft, which is 3 pages long:
It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites.
NLI is an acronym of "Next Level ISP".
Yes? And if the end host selects an address that belongs to a TLI that has a internal network failure and the traffic is blaockholed in that providers network, how does the end node find out? TCP timeout?
There are several of the proposals in multi6 that have never received comments, nor support of any kind.
That's fine, as long as you are indifferent to the issue.
I am not. But it's the multi6 WG that will have to end up selecting what to move forward.
However, as you actively made statement against my draft, you are guilty.
"Guilty"!? Whatever.
Your document does not address the criterias for being classified in a particular category.
My document does address the criteria for being classified in TLI.
Classification as NLI is up to TLIs.
So each TLI can have their own policy for their down-stream NLIs? Who decides who are the TLIs?
It does not address what would happen if an ISP grow, get's split/divided.
No, of course.
What if, an ISP having a global routing table entry grow, get's split/divided?
Actually, this is an issue today. Not a complex one, but there is policies in place for it. And if a TLI no longer is a TLI, that will have implications on down-streams.
It does not address what the financial models for transit would be.
No, of course.
It is a policy issue orthogonal to my draft.
Your draft does makes assumptions on how the policy would like. It actually makes assumptions that are very different from the model of today so I think it would be reasonable to explain the thinking. Otherwise I don't think to many ISPs will be interested.
It does not address the non-balance of local vs global traffic coverage.
No, of course.
For TLI, only the global traffic is important.
What about TLIs that do have large customer bases in local networks? What about very dominant local players that today can force large ISPs to peer simply because of the dominance in particular markets?
It does not take into account the current peering economics of the Internet.
No, of course.
It is a policy issue orthogonal to my draft.
Again, if you propose something that ignores the polices as they are implemented in todays Internet, I would expect at least some elaboration on how you see todays ISPs adopt this scheme.
Having to renumber when chaining ISPs is not to discourage _change_ of ISP. It's to discourage signing up with that ISP in the first place.
What if an ISP bankrupts (like UUNET) and stop operating?
It creates a nightmare for it's customers. Been there, done that, and have plenty of T-shirts to prove it. I think you miss the point. customers do not want to renumber if their _ISP change upstream_. That have a financial impact on them without them having control of the decision. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgwp6arNKXTPFCVEQIHOgCgzo+9bGXkc8O5A1wwLbC5C5f68/wAoLom neT+RDZlLHxQTDdRyTF+Uq7y =0ZWg -----END PGP SIGNATURE-----
Kurt Erik Lindqvist;
It's possible for a small ISP to get several blocks from their upstream, route them inside their network and assign each of their customers with an address out of each of those blocks. Does it scale? Nope. Can it handle failures in the upstream? No. Etc.
First of all, the small ISPs have multiple upstream ISPs.
Yes?
It does scale. It can handle failures in the upstream.
It is explicitly stated in my draft, which is 3 pages long:
It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites.
NLI is an acronym of "Next Level ISP".
Yes? And if the end host selects an address that belongs to a TLI that has a internal network failure and the traffic is blaockholed in that providers network, how does the end node find out? TCP timeout?
Read the draft of end to end multihoming. It is an issue of transport/application layer. Application running over TCP can use default TCP timeout or modify it. Application may use UDP with its own timeout.
There are several of the proposals in multi6 that have never received comments, nor support of any kind.
That's fine, as long as you are indifferent to the issue.
I am not.
You have been.
But it's the multi6 WG that will have to end up selecting what to move forward.
It's your problem that you failed to properly control the WG.
"Guilty"!? Whatever.
See the subject.
So each TLI can have their own policy for their down-stream NLIs? Who decides who are the TLIs?
If you need an example policy, read the draft.
It does not address what would happen if an ISP grow, get's split/divided.
No, of course.
What if, an ISP having a global routing table entry grow, get's split/divided?
Actually, this is an issue today. Not a complex one, but there is policies in place for it. And if a TLI no longer is a TLI, that will have implications on down-streams.
Sure. So, even if you directly subscribe to an TLI, you may have to renumber. Fair enough.
Your draft does makes assumptions on how the policy would like.
My draft does not make any assumption on how the policy would like. You failed to give specific example for counter argument.
It does not address the non-balance of local vs global traffic coverage.
What about TLIs that do have large customer bases in local networks? What about very dominant local players that today can force large ISPs to peer simply because of the dominance in particular markets?
Dominant local players may be treated as NLI or it can be an independent TLI. I know Yahoo, for example, has certain influence on its ISPs.
It is a policy issue orthogonal to my draft.
Again, if you propose something that ignores the polices as they are implemented in todays Internet, I would expect at least some elaboration on how you see todays ISPs adopt this scheme.
I do recognize the policies and says them orthogonal.
What if an ISP bankrupts (like UUNET) and stop operating?
It creates a nightmare for it's customers. Been there, done that, and have plenty of T-shirts to prove it. I think you miss the point. customers do not want to renumber if their _ISP change upstream_. That have a financial impact on them without them having control of the decision.
You miss the point. I'm saying all the ISPs have chance to change its prefix. Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
It is explicitly stated in my draft, which is 3 pages long:
It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites.
NLI is an acronym of "Next Level ISP".
Yes? And if the end host selects an address that belongs to a TLI that has a internal network failure and the traffic is blaockholed in that providers network, how does the end node find out? TCP timeout?
Read the draft of end to end multihoming.
Ok, so you are actually proposing that we a) Change the allocation policies according to draft-ohta-multihomed-isps-00.txt and b) Adopt the mechanisms in draft-ohta-e2e-multihoming-06.txt ?
It is an issue of transport/application layer.
So we need to modify the application layer according to the e2e draft?
Application may use UDP with its own timeout.
So all UDP applications need to modified (or not used at multihomed sites)?
But it's the multi6 WG that will have to end up selecting what to move forward.
It's your problem that you failed to properly control the WG.
This is a discussion that doesn't belong here, but it's not the role of the WG chairs to control the WG. It's the chairs job to conclude what solutions there are support for and which ones there are not. This is the reason for the classification of solutions sent to the multi6 WG and the statement that many of them simply do not have any support.
So each TLI can have their own policy for their down-stream NLIs? Who decides who are the TLIs?
If you need an example policy, read the draft.
Make a bidding round for the TLI roles? So you want an open market for default-free address space?
It does not address the non-balance of local vs global traffic coverage.
What about TLIs that do have large customer bases in local networks? What about very dominant local players that today can force large ISPs to peer simply because of the dominance in particular markets?
Dominant local players may be treated as NLI or it can be an independent TLI.
I know Yahoo, for example, has certain influence on its ISPs.
So Yahoo would qualify as a TLI? If they won a TLI assignment in the bidding round? While for example NTT might not?
It is a policy issue orthogonal to my draft.
Again, if you propose something that ignores the polices as they are implemented in todays Internet, I would expect at least some elaboration on how you see todays ISPs adopt this scheme.
I do recognize the policies and says them orthogonal.
Well, the bidding for address space has a large chance to off-set the financial models of the Internet today.
It creates a nightmare for it's customers. Been there, done that, and have plenty of T-shirts to prove it. I think you miss the point. customers do not want to renumber if their _ISP change upstream_. That have a financial impact on them without them having control of the decision.
You miss the point. I'm saying all the ISPs have chance to change its prefix.
Why would customers go to NLIs in the first place? I for one would only by service from TLIs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg+vqarNKXTPFCVEQKuBgCfThWCvXgCnbYfsyFvRFxUlBsbnMUAn3hs LKmspmiIwsGGSWDu80HV4m56 =lPg6 -----END PGP SIGNATURE-----
Kurt Erik Lindqvist;
It is explicitly stated in my draft, which is 3 pages long:
It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites.
NLI is an acronym of "Next Level ISP".
Yes? And if the end host selects an address that belongs to a TLI that has a internal network failure and the traffic is blaockholed in that providers network, how does the end node find out? TCP timeout?
Read the draft of end to end multihoming.
Ok, so you are actually proposing that we
I'm actually proposing that you read the draft, if you are interested in multi6 issues. Then, if you have any question, ask, hopefully with proper quoting of the draft. Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 16.51, Masataka Ohta wrote:
Ok, so you are actually proposing that we
I'm actually proposing that you read the draft, if you are interested in multi6 issues.
For the record for the RIPE address policy WG, I will take this discussion over to multi6 only. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNhZG6arNKXTPFCVEQLyCQCeMpcC0HeHQ5kwbyosKArIwO8zoosAn1PM VjC50f6zfRPocE5XrfPG9Zc1 =bva4 -----END PGP SIGNATURE-----
Hi, On Tue, Jun 22, 2004 at 06:06:48PM +0200, Kurt Erik Lindqvist wrote:
On 2004-06-22, at 16.51, Masataka Ohta wrote:
Ok, so you are actually proposing that we I'm actually proposing that you read the draft, if you are interested in multi6 issues. For the record for the RIPE address policy WG, I will take this discussion over to multi6 only.
I would appreciate if you could send us an "executive summary", so that people over here that are not so well-versed in the different multi6 proposals can try to judge the benefits and costs of this proposal. Something that right now confuses *me* is: If I understand this correctly, the 'default-free zone' is meant to be kept below 1000 routes, so routers can be fast. But what about the internal structure of all these networks? At least the "internal core" boxes need to know all routes for the "NLI"s (or the NLIs' customers), which might well be many 1000s... thanks, Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering; Hi,
Something that right now confuses *me* is: If I understand this correctly, the 'default-free zone' is meant to be kept below 1000 routes, so routers can be fast.
The hard limit is, IMO, 8192.
But what about the internal structure of all these networks? At least the "internal core" boxes need to know all routes for the "NLI"s (or the NLIs' customers), which might well be many 1000s...
You are right. There is nothing mentioned in the draft, but I suggested 1000 today, which I still think enough for TLI internal, but should not be enough for NLI. Do you have any suggestion? Note that routers in NLIs may have less performance than those in TLIs. Masataka Ohta
Hi, On Wed, Jun 23, 2004 at 04:29:37AM +0900, Masataka Ohta wrote:
Note that routers in NLIs may have less performance than those in TLIs.
Why? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering;
Note that routers in NLIs may have less performance than those in TLIs.
Why?
Because with minimum peering global traffic concentrates on peerings between TLIs and because minimum links make the traffice concentrate on backbone links of TLIs. With extra links, extra peerings and associated policies, it is possible to reduce the concentration or even have an NLI link carry more traffic than links of TLIs. Masataka Ohta
Something that right now confuses *me* is: If I understand this correctly, the 'default-free zone' is meant to be kept below 1000 routes, so routers can be fast.
The hard limit is, IMO, 8192.
Past history has told us that at least some technologists have failed miserably in predicting whether fast routers can be built which handle largish routing tables. If I recall correctly, an argument similar to the above one was one of the arguments the ATM proponents used in their day: you need a short header to do fast lookups, and "fast IP routers cannot be built". History since then has at least told me that this was not entirely accurate. Therefore, I tend to view the above justification and limits with a healthy dose of scepticism. Regards, - Håvard
Havard Eidnes wrote: Thank you for good examples.
Something that right now confuses *me* is: If I understand this correctly, the 'default-free zone' is meant to be kept below 1000 routes, so routers can be fast.
The hard limit is, IMO, 8192.
Past history has told us that at least some technologists have failed miserably in predicting whether fast routers can be built which handle largish routing tables.
And, I happened to be a technologist who know how to build a fast (Pbps or more) router even before no one have the needs. So, the only problem on fast routers is their prices. Limiting the number of global routing table entries helps a lot. With no loops in the forwarding path of routers, the limiting factor is latency of routing table look up. While parallelism is a solution, it does not reduce the routing table size. So, to reduce the prices of routers, it is better to reduce the routing table size. Their are poeple who use science to prove that it is impossible to make flying machines. Their are people who use science to make flying machines more efficient and less expensive.
If I recall correctly, an argument similar to the above one was one of the arguments the ATM proponents used in their day: you need a short header to do fast lookups, and "fast IP routers cannot be built". History since then has at least told me that this was not entirely accurate.
At that days, my theory explained why ATM is about 10 times slower than IP. The theory is simply that, given 28 bit address with hierarchy (VPI/VCI or more), it is almost as complex as processing 32 bit IP. So, it takes about 10 times more amount of work to process 48B chunks than 500B-in-average chunks. Of course, there are other factors obscuring the essential difference.
Therefore, I tend to view the above justification and limits with a healthy dose of scepticism.
So, you can still insist that my theory is incorrect and ATM is 8192 or more times faster than IP, while I can keep saying ATM is about 10 times slower than IP with reasons. I can also say 8192 is large enough for the number of global routing table entries with reasons. You can alsy say IPv6 is no good because 128 bit address is not long enough. But, it's your limitation, not mine. Masataka Ohta PS Note that there are people who analize that large routing table increases the time for BGP convergence.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ok, so you are actually proposing that we I'm actually proposing that you read the draft, if you are interested in multi6 issues. For the record for the RIPE address policy WG, I will take this discussion over to multi6 only.
I would appreciate if you could send us an "executive summary", so that people over here that are not so well-versed in the different multi6 proposals can try to judge the benefits and costs of this proposal.
Which proposal? Ohta-sans? I will rather give you a short update on the status of multi6 in general.
Something that right now confuses *me* is: If I understand this correctly, the 'default-free zone' is meant to be kept below 1000 routes, so routers can be fast. But what about the internal structure of all these networks? At least the "internal core" boxes need to know all routes for the "NLI"s (or the NLIs' customers), which might well be many 1000s...
This is just one out of many proposals (+30) that was brought to the multi6 WG. During the interim meeting in Santa Monica last week a number of actions where triggered 1) The WG have been asked if they want to adopt draft-lear-multi6-things-to-think-about-03.txt as per the charter item "practical questions" 2) The WG have been asked if they want to adopt draft-nordmark-multi6-threats-02.txt as per the charter item "security threats" 3) A classification of many/most of the proposals brought to the multi6 WG was posted to the mailinglist as well as discussed during the interim meeting. The classification was based on draft-huston-multi6-architectures-01.txt. During the discussions at the interim meeting, the classification was revised and discussed. It was concluded that most of the classes either a) Lack support b) Proposals have been withdrawn by their author c) Are interesting as components for other solutions Based on this it was proposed to concentrate on solutions that are either "fat-ip" or wedgelayers at layer "3.5". This classification and the reasoning was posted to the multi6 WG mailinglist, and should be discussed there if anyone have opinions on it. Now, there is also the issue that the minutes from the interim meeting unfortunately have not been posted yet, as a full day minutes takes some time to merge. In the mean time there is a Jabber log at http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNktaqarNKXTPFCVEQI6LwCg5HxX2NAjrpbMN57Cs3dZrxae2SAAniiJ Yh5nFQ2QMfuXnFxr9L8j5guw =RHFL -----END PGP SIGNATURE-----
Kurt Erik Lindqvist; With your fallacy denied, why do you replay the well known fallacy of NAT that NAT is transparent to the upper layers? It is of course for those having some expertise on the Internet architecture that entities performing address rewriting between layer 4 of a peer is no transparent.
Based on this it was proposed to concentrate on solutions that are either "fat-ip" or wedgelayers at layer "3.5".
So, it is simply wrong. An easy counter example is an application protocol carrying raw address such as IPv4 FTP. Another easy counter example is applications over UDP. Layer 3.5 means an interim layer to perform address rewriting with which multihoming is supported without upper layer changes. Such approach does work to let all the existing upper layer accept incoming packets, regardless of their locators. However, with the unmodified upper layer, it is impossible for the interim or lower layers when to try alternate address of its peer. That is, such approach does not work to let any of the existing upper layer generate outgoing packets with proper destination locators. Thus, there is no such thing as the magical layer 3.5. That NAT and the layer 3.5 interoperate with TCP means nothing. Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-23, at 13.03, Masataka Ohta wrote:
Based on this it was proposed to concentrate on solutions that are either "fat-ip" or wedgelayers at layer "3.5".
So, it is simply wrong.
I am simply referring the conclusions of the interim meeting on the request of the WG co-chair. Values of this being right or wrong, or other comments on various proposals to the multi6 problem belong in the multi6 WG. Not here (which I am sure the WG chairs will agree with). - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNllQaarNKXTPFCVEQIiTwCdGGiZVRjT5YA/LoyJU/H/+1KGVRYAoMWv OfxW6NYkpRMc66u8JunqmgL/ =1/8r -----END PGP SIGNATURE-----
Hi, On Wed, Jun 23, 2004 at 08:03:38PM +0900, Masataka Ohta wrote:
With your fallacy denied, why do you replay the well known fallacy of NAT that NAT is transparent to the upper layers?
Please STOP cc: ing the address-policy working group on e-mails that are purely about protocol design decisions and problems. Your opinions about the address policy are known by now, and these e-mails do not contribute further to the discussion at hand. Gert Doering, speaking as APWG Co-Chair. -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering;
With your fallacy denied, why do you replay the well known fallacy of NAT that NAT is transparent to the upper layers?
Please STOP cc: ing the address-policy working group on e-mails that are purely about protocol design decisions and problems.
It is not protocol design decision but is information that Kurt want multi6 not solve the multihoming problem. I stated it with a well known reason that intermediate entities such as layer 3.5 and NAT which perform address rewriting can not be transparent.
Your opinions about the address policy are known by now, and these e-mails do not contribute further to the discussion at hand.
The point of my post is that 8192 is large enough as the global routing table size, which is mostly orthogonal to multi6 issues (except that failure of multi6 bloat the routing table size indefinitely large). One important factor not explained yet very well is that BGP converges slowly as the number of ASes increases, which is another reason to limit the global routing table size. Masataka Ohta
----- Original Message ----- From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> Sent: Thursday, June 24, 2004 7:17 AM
Gert Doering;
With your fallacy denied, why do you replay the well known fallacy of NAT that NAT is transparent to the upper layers?
Please STOP cc: ing the address-policy working group on e-mails that are purely about protocol design decisions and problems.
It is not protocol design decision but is information that Kurt want multi6 not solve the multihoming problem.
I stated it with a well known reason that intermediate entities such as layer 3.5 and NAT which perform address rewriting can not be transparent.
Your opinions about the address policy are known by now, and these e-mails do not contribute further to the discussion at hand.
The point of my post is that 8192 is large enough as the global routing table size, which is mostly orthogonal to multi6 issues (except that failure of multi6 bloat the routing table size indefinitely large).
One important factor not explained yet very well is that BGP converges slowly as the number of ASes increases, which is another reason to limit the global routing table size.
You can try but you can't stop the evolution(tm). A number like that or any other number will be just as "fatal" like the 640kb problem was in the 80's in the long run. The problem with the current IPv6 specification as I see it is purely technical and should be dealt with by the vendors making the IP routers. There is more than one way to implement routing algorithms, and several of them could equally give the best performance. Of course it would help if the RIR's tried not to hand out more than 1 prefix per LIR. If a LIR is multihomed they should be allocated a prefix. If not then people will stick to IPv4 until we really run out of ip's and keep sticking to it. Then we would have major problems deprecating IPv4. PI allocations doesn't exist anymore with IPv6 so that problem is solved..? Joergen Hovland
Joergen Hovland; First of all, if you insist writing your name beyond ASCII, that's fine if it is common local practice within your country. However, you should accept the fact that your international mail is often treated as SPAM.
One important factor not explained yet very well is that BGP converges slowly as the number of ASes increases, which is another reason to limit the global routing table size.
You can try but you can't stop the evolution(tm).
I don't.
A number like that or any other number will be just as "fatal" like the 640kb
Who said 8192 of the global routing table size fatal? It, of course, is doable, as exemplified by the current reality with
100K.
problem was in the 80's in the long run. The problem with the current IPv6 specification as I see it is purely technical and should be dealt with by the vendors making the IP routers. There is more than one way to implement routing algorithms, and several of them could equally give the best performance. Of course it would help if the RIR's tried not to hand out more than 1 prefix per LIR.
Wrong. It does impose unnecessary restriction on mergers of LIRs.
If a LIR is multihomed they should be allocated a prefix.
If the LIR covers large enough (a lot lot larger than 200), yes of course.
If not then people will stick to IPv4 until we really run out of ip's and keep sticking to it.
Sure. It is exactly why I suggest giving v4 blocks to ISPs, only when the ISPs publicly announce that they will fully support v6 shortly , which was presented several years ago at Amsterdam RIPE meeting. At that time, many expected, without technical reasons, that IPv6 will prevail.
Then we would have major problems deprecating IPv4. PI allocations doesn't exist anymore with IPv6 so that problem is solved..?
The only technical way to deprecate v4 is to exhaust the v4 address space. It should be noted that NAT delayed the exhaustion and delayed v6 deployment. It should also be noted that it was good because v6 is still faulty not to be deployed widely. Masataka Ohta
----- Original Message ----- From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> Sent: Thursday, June 24, 2004 2:56 PM Subject: Re: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
Joergen Hovland;
First of all, if you insist writing your name beyond ASCII, that's fine if it is common local practice within your country. However, you should accept the fact that your international mail is often treated as SPAM.
ありがとう。 今固定される (test)
One important factor not explained yet very well is that BGP converges slowly as the number of ASes increases, which is another reason to limit the global routing table size.
Who said 8192 of the global routing table size fatal?
There are N amount of LIR's and other companies in the need of prefixes. Any limit below N is not going to work. Since N is a dynamic variable it can not be permanently set.
It, of course, is doable, as exemplified by the current reality with
100K.
problem was in the 80's in the long run. The problem with the current IPv6 specification as I see it is purely technical and
be dealt with by the vendors making the IP routers. There is more than one way to implement routing algorithms, and several of
should them
could equally give the best performance. Of course it would help if the RIR's tried not to hand out more than 1 prefix per LIR.
Wrong. It does impose unnecessary restriction on mergers of LIRs.
I said only to try, not to demand. Unnecessary fragmentation should always be avoided.
If a LIR is multihomed they should be allocated a prefix.
If the LIR covers large enough (a lot lot larger than 200), yes of course.
I meant if the LIR was multihomed, period. You can't deny v4 LIR's a v6 prefix if you want v6 to be deployed in this century. Isn't the only reason why v6 policies are so strict compared to v4 today due to the socalled multi-homing problem? Are we afraid of that we won't be able to develop better hardware/software that can support even larger routingtables tomorrow ?
Then we would have major problems deprecating IPv4. PI allocations doesn't exist anymore with IPv6 so that problem is solved..?
The only technical way to deprecate v4 is to exhaust the v4 address space.
You are probably correct. But if the same restrictive v6 policies exist when v4 is exhausted people might start to pay good money (like a blackmarket) for v4 multihomed capable prefixes since they can't get multihomed capable v6 prefixes. Then v4 and v6 will together live for ever. Joergen Hovland
Kurt Erik Lindqvist;
Application may use UDP with its own timeout.
So all UDP applications need to modified (or not used at multihomed sites)?
If there is a family of UDP applications sharing the same idea on "connection", there can be a set of connection management library functions shared by the applications. Then, it may be that only the library may be modified.
This is a discussion that doesn't belong here, but it's not the role of the WG chairs to control the WG.
Then, it was your mistake that you controlled the WG to forbid presentations of proposals.
Make a bidding round for the TLI roles? So you want an open market for default-free address space?
Read the draft for an example. It does not say "open".
So Yahoo would qualify as a TLI? If they won a TLI assignment in the bidding round? While for example NTT might not?
Read the draft.
I do recognize the policies and says them orthogonal.
Well, the bidding for address space has a large chance to off-set the financial models of the Internet today.
As explained in my presentation, it does not.
Why would customers go to NLIs in the first place? I for one would only by service from TLIs.
It is you who are ignoring the reality. Why do customers today buy service from tier2 providers? Masataka Ohta
Since Kurtis took off his co-chair hat for this thread, I will put mine on. This is not a fruitful discussion, and it certainly should not be cross-posted. As Kurtis said, there have been no indications of support for Masataka's draft in multi6, so subject to the minutes of the recent meeting being sent to the list and agreed, it is off the table. Since multi6 has not firmly identified a solutions direction, and no work on a specific solution is chartered in the IETF yet, it's premature to discuss possible impact of multi6 on RIR policy. Brian multi6 WG co-chair Masataka Ohta wrote:
Kurt Erik Lindqvist;
Application may use UDP with its own timeout.
So all UDP applications need to modified (or not used at multihomed sites)?
If there is a family of UDP applications sharing the same idea on "connection", there can be a set of connection management library functions shared by the applications. Then, it may be that only the library may be modified.
This is a discussion that doesn't belong here, but it's not the role of the WG chairs to control the WG.
Then, it was your mistake that you controlled the WG to forbid presentations of proposals.
Make a bidding round for the TLI roles? So you want an open market for default-free address space?
Read the draft for an example. It does not say "open".
So Yahoo would qualify as a TLI? If they won a TLI assignment in the bidding round? While for example NTT might not?
Read the draft.
I do recognize the policies and says them orthogonal.
Well, the bidding for address space has a large chance to off-set the financial models of the Internet today.
As explained in my presentation, it does not.
Why would customers go to NLIs in the first place? I for one would only by service from TLIs.
It is you who are ignoring the reality.
Why do customers today buy service from tier2 providers?
Masataka Ohta
Brian E Carpenter;
As Kurtis said, there have been no indications of support for Masataka's draft in multi6,
As you give no chance to discuss it at the meeting, it is not a valid decision.
so subject to the minutes of the recent meeting being sent to the list and agreed, it is off the table.
Thank you for yet another demonstration of poor chairing. WG can't decide something at the meeting. Masataka Ohta
Ohta-san, Which part of your previous message provides me guidance on how your solution will solve scaling problems? Eliot
Eliot Lear; Hi,
Which part of your previous message provides me guidance on how your solution will solve scaling problems?
Scaling problems of which? If we have hard limit on the global routing table size, there is no scaling problem on the global routing table size. The question is whether we can put the limit or not. Considering that the global routing table entries are for global policy control, we don't need so much entries much more than those having real global policy, that is, (self qualified) tier1. Masataka Ohta
Besides, there is no benefit to this rule as far as I can see. IPv6 space is not a scarce resource. IPv4 is, yet is is easy enough to get.
It should not be any more difficult to get an IPv6 allocation than it is to get an IPv4 allocation. Therefore, any ISP/LIR who already has an IPv4 allocation should be able to get their first IPv6 /32 simply by asking for it. In fact, you could argue that the RIRs should just allocate an IPv6 block to every ISP/LIR right now and send them out in the next email. --Michael Dillon
On Saturday 19 June 2004 12:31, Pekka Savola wrote:
Are an ISP's own PoPs or other parts of infrastructure "other organisations"?
Nope. Never. Not by any English dictionary :).
Yes, it can be. You're all assuming that an LIR has to be an ISP. That's not always the case. The only infrastructure our LIR owns are the routers. We provide connectivity to several ISP's - including our own. Our ISP is simply another customer of the LIR. My personal opinion is that the '200' rule should be scrapped - this is obviously a topic for a different debate. but, in answer to the original question: "To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years." There is in my understanding no stipulation that these assignments must all be made to external organisations. Therefore an assignment to your own infrastructure counts - not that 1 assignment out of 200 makes a great deal of difference. Just my 2 peneth worth. Regards, Jon Lawrence
Hi, On Sun, Jun 20, 2004 at 09:02:15AM +0100, Jon Lawrence wrote:
not that 1 assignment out of 200 makes a great deal of difference.
I think this is a very important statement. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-19, at 13.31, Pekka Savola wrote:
Are an ISP's own PoPs or other parts of infrastructure "other organisations"?
Nope. Never. Not by any English dictionary :).
I haven't claimed it to be.
The purpose at this point is to clarify the policy, not to change it.
Is it?
You're confusing the issue by saying what you believe an optimal policy *SHOULD* be.
Yes, and?
I have an opinion about that as well, but that's out of scope of this debate, i.e., what the policy is and what it was intended to be (and 'other organisations' makes it crystal clear IMHO that you were not intended to count the internal assignments).
Well, it would be good if we understood the current policy, or at least that all had the same view of it. But if it is that unclear, we should perhaps revisit it. Which is what I am arguing for. And when we do - I think this is something that we need to get in there. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNaDWKarNKXTPFCVEQLpMACfUW9B709p3aVgYNGHMCT2CwHN0J8An07k ++ZM5s4v1fUYDn0jzbwZagWR =gF4H -----END PGP SIGNATURE-----
Hi, On Thu, Jun 17, 2004 at 11:50:29AM +0100, Jon Lawrence wrote:
And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic.
To clarify this, speaking officially as AP WG co-chair. - to gain IPv6 experience and to run trials, you should be able to get a /48 or bigger from your friendly IPv6 neighbour / tunnel peer / upstream. - if you have serious *plans* (<< note the emphasis) for deploying IPv6 services, and you have more than 200 IPv4 customers (!), *or* there is a remote chance that you will have 200 IPv6 customers in two years, you qualify for an IPv6 allocation. This is one of the most misunderstood parts of the policy. It's sole purpose is to weed out those that want IPv6 only for their own network, not to stifle IPv6 deployment for those LIRs that really want to get the ball rolling. Nobody can claim to be 100 per cent *sure* to have 200 IPv6 customers in two years (or even a /20 worth :-) ) - and that's the reason why the number of your IPv4 customers is also taken into account when judging the application. Or, to phrase it differently. As of today, *no single* IPv6 allocation request has been denied by the RIPE NCC. Sometimes they ask questions, or want a somewhat creative network plan. Some people get scared away by this - but so far, all serious requests have been approved. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
I really fail to see the reason behind the 200 other organisation rule - perhaps someone would like to explain the logic.
I think the logic is that the RIRs are trying to portion out routing space so that we don't get a global routing table explosion in IPv6 in the same way we have (had) in IPv4. To acheive this, they need to make sure that the small ISPs don't get their own allocation, but instead go to their upstream provider for an IPv6 address space delegation. I can't really see another reason for this particular aspect of the policy. No, I don't think I agree with this policy, but I think I see what the RIRs are trying to conserve. I also have to agree with Pekka; "200 assignments to other organizations" can only be interpreted one way. Not that 199 or 200 would make all that much of a difference, so that's a minor point. Regards, - Håvard
On 21 Jun, 2004, at 17:00, Havard Eidnes wrote:
I really fail to see the reason behind the 200 other organisation rule - perhaps someone would like to explain the logic.
I think the logic is that the RIRs are trying to portion out routing space so that we don't get a global routing table explosion in IPv6 in the same way we have (had) in IPv4. To acheive this, they need to make sure that the small ISPs don't get their own allocation,
If this is true, it is really disturbing given that the RIPE NCC was rather proactive some years ago when the whole TLA/NLA/SLA structure was conceived with the main objective of allowing only up to 8192 players in the global routing table. Eventually everyone got to see the point of view championed by DFK that it would be undue regulation of the industry. Now, like then, the arguments in favour of imposing this limitation where all to do with the current technical difficulties with coping with a huge routing table. Also disturbing is that, while there are groups working on proposing new solutions to the multihoming problem, the policy seems to reflect a conviction that they will fail and therefore there need to be constraints imposed at a table size of a few hundred entries. I would like to suggest that if the multihoming proposals fail, then the policy becomes irrelevant because so does IPv6. Therefore the policy ought to be as relaxed as possible to not preclude any possible growth at this stage.
but instead go to their upstream provider for an IPv6 address space delegation. I can't really see another reason for this particular aspect of the policy.
Joao
Hi, On Tue, Jun 22, 2004 at 09:54:59AM +0200, Joao Damas wrote:
On 21 Jun, 2004, at 17:00, Havard Eidnes wrote:
I really fail to see the reason behind the 200 other organisation rule - perhaps someone would like to explain the logic.
I think the logic is that the RIRs are trying to portion out routing space so that we don't get a global routing table explosion in IPv6 in the same way we have (had) in IPv4. To acheive this, they need to make sure that the small ISPs don't get their own allocation,
If this is true, it is really disturbing given that the RIPE NCC was [..]
The "200 user" criteria came from the ARIN and APNIC communities, not from the RIRs. [..]
Also disturbing is that, while there are groups working on proposing new solutions to the multihoming problem, the policy seems to reflect a conviction that they will fail and therefore there need to be constraints imposed at a table size of a few hundred entries.
I can't see the connection. The whole point of the multi6 group is to find multihoming solutions that do *not* need a global routing table slot. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On 22 Jun, 2004, at 9:59, Gert Doering wrote:
[..]
Also disturbing is that, while there are groups working on proposing new solutions to the multihoming problem, the policy seems to reflect a conviction that they will fail and therefore there need to be constraints imposed at a table size of a few hundred entries.
I can't see the connection. The whole point of the multi6 group is to find multihoming solutions that do *not* need a global routing table slot.
What the solution is does not matter as long as it is workable. The point I raised has nothing to do with how multi6 intends to achieve it's goals, rather with the fact that the current attitude towards policy making for IPv6 seems to have the underlying assumption that there is a need to drastically reduce the number of organisations that can get allocations to reduce the number of entries in the routing table. This happens at the same time that there is a group working on solutions so it shows little faith in the outcome of the work. I am arguing for a change in mentality that, while keeping memory of the good lessons learned in IPv4 (eg. allocation size related to network size, via variable sized prefixes) does not keep newcomers from deploying IPv6 (eg. a LIR -> an allocation or variations) Joao
Joao Damas;
The point I raised has nothing to do with how multi6 intends to achieve it's goals, rather with the fact that the current attitude towards policy making for IPv6 seems to have the underlying assumption that there is a need to drastically reduce the number of organisations that can get allocations to reduce the number of entries in the routing table. This happens at the same time that there is a group working on solutions so it shows little faith in the outcome of the work.
In multi6 WG, there certainly is a proposal to reduce the number of TLAs.
I am arguing for a change in mentality that, while keeping memory of the good lessons learned in IPv4 (eg. allocation size related to network size, via variable sized prefixes) does not keep newcomers from deploying IPv6 (eg. a LIR -> an allocation or variations)
Then, accept the fact that we can't have so much TLAs. A simple way to do so is to allow TLAs only to national IRs. There are other ways, too. Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 13.42, Masataka Ohta wrote:
A simple way to do so is to allow TLAs only to national IRs.
What is a "national IR"? National Internet Registry? What about corporations that fall outside the nation boundary? Who controls the national IRs? What are the rules they operate by? What do we gain with this over RIRs? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgdh6arNKXTPFCVEQJrVwCg5+d4ijks9Nx57KwrOinD+pRGWvwAoNEs h9Ypi+U12+ZIoFfb6a/6ZUjU =dEIB -----END PGP SIGNATURE-----
Kurt Erik Lindqvist;
A simple way to do so is to allow TLAs only to national IRs.
Can you beahve fair to quote properly. I wrote:
A simple way to do so is to allow TLAs only to national IRs.
There are other ways, too.
What is a "national IR"? National Internet Registry? What about corporations that fall outside the nation boundary? Who controls the national IRs? What are the rules they operate by? What do we gain with this over RIRs?
For example, in my draft you actively ignored, I wrote: For example, some TLA may be supplied from RIRs with bidding. Some TLA may be allocated to each country (proportional to the population of the country) and delivered with the countrie's policy. As you have chances to ask questions, you are supposed to understand the meanings of the examples of the draft. Or, you can say that you have never been interested in mult6 issues. Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A simple way to do so is to allow TLAs only to national IRs.
There are other ways, too.
What is a "national IR"? National Internet Registry? What about corporations that fall outside the nation boundary? Who controls the national IRs? What are the rules they operate by? What do we gain with this over RIRs?
For example, in my draft you actively ignored, I wrote:
For example, some TLA may be supplied from RIRs with bidding.
Some TLA may be allocated to each country (proportional to the population of the country) and delivered with the countrie's policy.
I was asking trying to clarify what you meant by "national IR" and under what policies these would operate. Which is a fairly substantive question.
As you have chances to ask questions,
Which is exactly what I am doing. But I think the chairs will ask us to take this elsewhere soon, as this is pretty far off topic. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgj96arNKXTPFCVEQLORQCg1SG5EaX1Xh3R3LExIANRud1/7uwAoPKv CJ8Ei3j6Ujf7FFouwuBJiq3H =jE/f -----END PGP SIGNATURE-----
Kurt Erik Lindqvist;
For example, in my draft you actively ignored, I wrote:
For example, some TLA may be supplied from RIRs with bidding.
Some TLA may be allocated to each country (proportional to the population of the country) and delivered with the countrie's policy.
I was asking trying to clarify what you meant by "national IR" and under what policies these would operate. Which is a fairly substantive question.
And, as I properly quoted, the answer was given in my draft you actively ignored. proportional to the population of the country OK?
But I think the chairs will ask us to take this elsewhere soon, as this is pretty far off topic.
As my suggestion is just "for example" that there are a lot to discuss which is within the scope of "address-policy-wg". Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 14.32, Masataka Ohta wrote:
proportional to the population of the country
OK?
Well, I was unclear. I was referring to the policy of the national IR? Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgsgaarNKXTPFCVEQKAxACg/u+0brzfNy/70ZYfRTI+0itUJkoAoJXp 6uMfeFYh3794+OqhVGshZBc5 =mkIy -----END PGP SIGNATURE-----
Kurt Erik Lindqvist;
proportional to the population of the country
OK?
Well, I was unclear. I was referring to the policy of the national IR? Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority?
Do you know how nations get ccTLDs? Hint: We have UN. Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 15.29, Masataka Ohta wrote:
proportional to the population of the country
OK?
Well, I was unclear. I was referring to the policy of the national IR? Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority?
Do you know how nations get ccTLDs?
Well, this is an interesting question loaded with more politics that I really would like to get into.
Hint: We have UN.
Hint: How does the island of Taiwan get a block? This discussion will drift into WSIS/ITU/UN/ICANN/IETF etc. Let's drop it here. I know what your view is then. Good enough. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg6XKarNKXTPFCVEQIrtQCfVvAFQzdG2EYvmQgDsIkoo+AgaNUAn3GN bVdP/hq5sdW/TdgG6jZEg1Sj =K/7S -----END PGP SIGNATURE-----
Hi, On Tue, Jun 22, 2004 at 10:29:34PM +0900, Masataka Ohta wrote:
Well, I was unclear. I was referring to the policy of the national IR? Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority?
Do you know how nations get ccTLDs?
Hint: We have UN.
To bring in the governments into an address policy discussion should qualify for application of Godwin's law. "The thread has ended here". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 16.10, Gert Doering wrote:
"The thread has ended here".
Understood. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg+7qarNKXTPFCVEQKofwCg7YM4YqeDXkZIG4jqSoYnKv8DtMgAoJut BMsrbLN4fcA1dZikS9+wm+Zo =sBKy -----END PGP SIGNATURE-----
Gert Doering wrote:
Well, I was unclear. I was referring to the policy of the national IR? Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority?
Do you know how nations get ccTLDs?
Hint: We have UN.
To bring in the governments into an address policy discussion should qualify for application of Godwin's law. "The thread has ended here".
So, we don't have ccTLDs. OK. Masataka Ohta
Well, I was unclear. I was referring to the policy of the national IR? Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority?
Do you know how nations get ccTLDs?
Hint: We have UN.
To bring in the governments into an address policy discussion should qualify for application of Godwin's law. "The thread has ended here".
So, we don't have ccTLDs. OK.
This is terribly confused. In fact, nations get ccTLDs by accepting incoming international mail, i.e. letters and parcels. Any area of the world that has a postal system which receives incoming mail, also has a two-letter code assigned by the Universal Postal Union. They aren't terribly concerned about political divisions when making the code allocations. The important thing is that the area must have a separate postal system and since Taiwan has a postal system separate from the People's Republic of China, it also gets a UPU code. Same thing for Hong Kong. And mainland France also had a code until recently (MF) to distinguish it from the French overseas departments and territories which all have their own individual codes. IANA and ICANN simply refer to the UPU list to decide whether or not to give out a ccTLD. They prefer to give the ccTLD to an administrator who has the support of the majority of Internet users in the ccTLD area and there is a dispute procedure to sort out arguments. If necessary, governments can win those disputes but it usually is not necessary for governments to get involved at all because the independent ccTLD organizations in most countries try to do a good enough job that nobody complains about them. Strangely enough, this is not that different from the RIR system. --Michael Dillon
Michael.Dillon@radianz.com wrote:
Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority?
Do you know how nations get ccTLDs?
Hint: We have UN.
IANA and ICANN simply refer to the UPU list to decide whether or not to give out a ccTLD. They prefer to give the ccTLD to an administrator who has the support of the majority of Internet users in the ccTLD area and there is a dispute procedure to sort out arguments. If necessary, governments can win those disputes but it usually is not necessary for governments to get involved at all because the independent ccTLD organizations in most countries try to do a good enough job that nobody complains about them.
So, just as there are national NICs there can be national IRs. National IRs may nor may not be a part of a government. Masataka Ohta PS It's not UPU but ISO-3166, which is maintained by UN (security council). http://www.icann.org/icp/icp-1.htm : whose codes are assigned from a table known as ISO-3166-1, which is : maintained by an agency of the United Nations.
Hi, On Tue, Jun 22, 2004 at 02:20:03PM +0200, Kurt Erik Lindqvist wrote:
But I think the chairs will ask us to take this elsewhere soon, as this is pretty far off topic.
Oh, well, it gives interesting insights. Also I finally got my statement for "WE NEED TO KEEP THE 200 USERS RULE!", and I'm now trying to sum up the discussion into a summary statement... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 11.17, Joao Damas wrote:
I can't see the connection. The whole point of the multi6 group is to find multihoming solutions that do *not* need a global routing table slot.
What the solution is does not matter as long as it is workable.
The point I raised has nothing to do with how multi6 intends to achieve it's goals, rather with the fact that the current attitude towards policy making for IPv6 seems to have the underlying assumption that there is a need to drastically reduce the number of organisations that can get allocations to reduce the number of entries in the routing table. This happens at the same time that there is a group working on solutions so it shows little faith in the outcome of the work.
Well, there is also a time scale factor. If multi6 concluded today, someone still needs to do the protocol work, which is at least two years. Add to that implementation. 10 years might be optimistic. Then again we haven't gotten 500 routes in the past 10 years. And even if all LIRs got a prefix that would still only be some 20k prefixes at best. But you are right, that there is a roll-out plan missing. At some point we need to decide who's job it is to come up with the implementation strategy and a policy for what to do in the mean time. I would like to say that multi6 has moved far enough that it's time to start discussing this. But I think I will save that for after the San Diego IETF meeting. I think also the multi6 WG chairs needs to talk with the ADs of how to proceed with this issue... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgbt6arNKXTPFCVEQLCewCeMsJ6fQuijsW2UW++/PHBXxs74VkAoOXf DZby4qMAQ3rYOlDUo0Irxteq =UDUs -----END PGP SIGNATURE-----
Kurt Erik Lindqvist wrote:
Well, there is also a time scale factor. If multi6 concluded today, someone still needs to do the protocol work, which is at least two years. Add to that implementation. 10 years might be optimistic.
Just for your (other than Kurt) information, there is running code of a multi6 proposal which does not bloat global routing table size, which has been running even before the multi6 WG was formed. The only problem for the deployment of the proposal is that IPv6 is not deployed. Masataka Ohta
On Tue, 22 Jun 2004 21:01:59 +0900, Masataka Ohta wrote:
Just for your (other than Kurt) information, there is running code of a multi6 proposal which does not bloat global routing table size, which has been running even before the multi6 WG was formed. With todays >10GB backbones, we need running *hardware*.
The only problem for the deployment of the proposal is that IPv6 is not deployed. This is *the* cat-tail-problem we are talking about: IPv6 *won't* be deployed if it can't provide at a minimum all commonly used features of IPv4 and does something better. Multihoming with unique and world wide valid IP adresses *is* a feature commonly used by *large* customers who pay significant amounts of the ISP infrastructure.
At the end of the day the technical guys have to justify the invests into new infrastructure to the commercial guys. They will simply ask: "What does IPv6 gain to our company" "Oh well, instead of having first class PA/PI adresses, we will have second class multi6 accessibility and our true address range will be at the mercy of our Upstream/ISP" If you want to see what happens with investments of artificial "comission" protocols, have a look at UMTS ;-/ Ceterum censeo: Either the routing bottleneck is removed, or we won't see a successfull IPv6 in the next fifty years. And sadly as it is: To make some address range globaly routable as *numeric packet address* and not as super-DNS or second class host-hast-to-start-search addreses the routers which do the job need some information about the goal of the packet, of either static or dynamic type. And as the ISP market has no regional hierachy like a postal service, it must be world wide. IMHO the only chance of a commercially successfull deployment is some sort of make-it-better-than-BGP which can handle large amounts of prefix data. As we can't expect such a change in the near future, in my personal view the policy needs a modification which: a) advances and pushes forward IPv6 deployment, instead of the >=200 limit which is rather contraproductive. b) *currently* keeps the cover on the multihoming pot until the problem is *really* solved by technology. Sorry that I have no better news, but mathematics and physical law's won't be changed by discussions, as well as economical laws won't. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Oliver Bartels;
Just for your (other than Kurt) information, there is running code of a multi6 proposal which does not bloat global routing table size, which has been running even before the multi6 WG was formed.
With todays >10GB backbones, we need running *hardware*.
Sure. The proposal needs no change on routers, which is why the code is running, of course, over commercial v6 routers.
The only problem for the deployment of the proposal is that IPv6 is not deployed.
This is *the* cat-tail-problem we are talking about: IPv6 *won't* be deployed if it can't provide at a minimum all commonly used features of IPv4 and does something better.
Currently, the only merit of v6 over v4 is that v6 address space is larger. Trying to add other merit, v6 became unncessarily complex and, thus, worse than v4. The only exception is the possiblity to limit the number of global routing table entries. See below.
Multihoming with unique and world wide valid IP adresses *is* a feature commonly used by *large* customers who pay significant amounts of the ISP infrastructure.
That is a problem of v6, not of the proposal above.
At the end of the day the technical guys have to justify the invests into new infrastructure to the commercial guys. They will simply ask: "What does IPv6 gain to our company" "Oh well, instead of having first class PA/PI adresses, we will have second class multi6 accessibility and our true address range will be at the mercy of our Upstream/ISP"
The proper answer should be: Because IPv6 requires only 8192 global routing table entries, 10G backbone router costs 100 times less than that of IPv4
IMHO the only chance of a commercially successfull deployment is some sort of make-it-better-than-BGP which can handle large amounts of prefix data.
Huh? Do you mean we shouldn't have policy to allow a lot of prefixes?
As we can't expect such a change in the near future, in my personal view the policy needs a modification which: a) advances and pushes forward IPv6 deployment, instead of the >=200 limit which is rather contraproductive.
The only limitation globally necessary is on the number of TLAs. Other limitations are local issues.
b) *currently* keeps the cover on the multihoming pot until the problem is *really* solved by technology.
The problem is proven to be solved. Masataka Ohta
On Tue, 22 Jun 2004 23:24:26 +0900, Masataka Ohta wrote:
The proper answer should be:
Because IPv6 requires only 8192 global routing table entries, 10G backbone router costs 100 times less than that of IPv4 You are joking.
If you buy a $100000 car and drive 1000 milles per year, you won't drop your total cost of ownership by a factor of 10 if you just get the gasoline 10 times cheaper ... I agree with Gert: => application of Godwin's law. "The thread has ended here". Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Oliver Bartels;
You are joking.
I'm afraid you are seriously saying that speed of the Internet stays same forever.
If you buy a $100000 car and drive 1000 milles per year, you won't drop your total cost of ownership by a factor of 10 if you just get the gasoline 10 times cheaper ...
10 years ago, T3 was considered to be fast. Masataka Ohta
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 09.59, Gert Doering wrote:
I can't see the connection. The whole point of the multi6 group is to find multihoming solutions that do *not* need a global routing table slot.
Well, they will need a global routing table slot, but preferably not more than one :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgadaarNKXTPFCVEQKDlQCg45zioLuVEJ23LaLFbEuWh/2WeRQAoKQF 7W5N2tArVmQpzd9GIemhUZU7 =q+GO -----END PGP SIGNATURE-----
Quoting Pekka Savola <pekkas@netcore.fi>:
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
If so - please state this clearly in the policy so noone will make their own "interpretation" of how this should be done. -- amar ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi, On Thu, Jun 17, 2004 at 12:20:49PM +0300, Pekka Savola wrote:
I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations!
*I* always thought the primary goal was to get IPv6 deployed... (and the "200" number is in there to get some sort of rough filter to get only those IPv6 "adaptors" that really want to do some sort of IPv6 distribution to third parties) Gert Doering (speaking mainly as IPv6 user, not as co-chair) -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
*I* always thought the primary goal was to get IPv6 deployed...
i would think that the primary goal was to move the customers' packets. if they want us to move ipv6, them it's moving ipv6. we are concerned that it is deployABLE, because customers may want it. but our job is not to get ipv6 deployed. randy
Hi, now this is getting philosophical, and might better belong to the ipv6-wg mailing list... but still. On Thu, Jun 17, 2004 at 01:05:45PM -0700, Randy Bush wrote:
*I* always thought the primary goal was to get IPv6 deployed...
i would think that the primary goal was to move the customers' packets. if they want us to move ipv6, them it's moving ipv6. we are concerned that it is deployABLE, because customers may want it.
but our job is not to get ipv6 deployed.
Actually it *is* part of my job description here :-) If the move to IPv6 is ever going to happen, we should better have a large part of "the network" prepared for it - and that includes rolling out v6 address space to ISPs, deploying it in our networks, and learning from lots of mistakes, so that eventually we can move customer's IPv6 packets in good faith that they might arrive at their indended goals. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-17, at 22.05, Randy Bush wrote:
*I* always thought the primary goal was to get IPv6 deployed...
i would think that the primary goal was to move the customers' packets. if they want us to move ipv6, them it's moving ipv6. we are concerned that it is deployABLE, because customers may want it.
but our job is not to get ipv6 deployed.
Good point. If it where, people might realize that we forgot a bunch of stuff in IPv6. Such as multihoming...:-) But, I *think* that Gerts point was that our job is to make it as easy as possible to prepare for when (if) customers want IPv6. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNM+1qarNKXTPFCVEQLuoQCfYPlzoEQdi67Luz5CzCjoE948RKwAoIGH EglO6L5tXz6ei1XKAGle2SGO =HnZO -----END PGP SIGNATURE-----
--On fredag 18 juni 2004 21.13 +0200 Kurt Erik Lindqvist <kurtis@kurtis.pp.se> wrote:
But, I *think* that Gerts point was that our job is to make it as easy as possible to prepare for when (if) customers want IPv6.
And our customers want it (since we're NREN, few others care right now..) but we've got our /32 so all is nice and hunky dory and they are satisifed. As soon as we can get these shiny v4 routers behave, that is. OTOH, I'd hate to see the same mistakes (that seemed reasonable at the time) that were made in the v4 sunrise period be repeated in v6, like: * too small assignments for customers forcing NAT in use, * dependency on temporary hacks that suddenly must be made permanent to keep the world rolling, [0] * The tendency of RIRen to act as if their main task was conserving address space when their job is to make sure that all reasonable requests get served. The way around this, imho, is to make large enough initial assignments, and to be liberal with them. I think that the 200 customer rule is silly, invites to lies, and in general, is counterproductive. Better would be to hand out one /32 (because I think it is a nice size) to any LIR asking for one, and then perhaps be tough on the second one. So: 1. Define that the 200 customers rule is "something", either including internal assignments or not. 2. Kill it. For it is bad. 3. Focus on multihoming. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE [0] I bet a beer that we'll see luser outcry june 7th 2005 because the nice 3FFE addresses don't work like they used to, coupled with a range of quick hacks to get it back running again. Imagine: Tunneling 3FFE:: over 2001:: over v4 to get around the deprecation.. MTU 384 bytes, on a lucky day ;-)
On Sat, 19 Jun 2004, Måns Nilsson wrote:
But, I *think* that Gerts point was that our job is to make it as easy as possible to prepare for when (if) customers want IPv6.
And our customers want it (since we're NREN, few others care right now..) but we've got our /32 so all is nice and hunky dory and they are satisifed. As soon as we can get these shiny v4 routers behave, that is.
OTOH, I'd hate to see the same mistakes (that seemed reasonable at the time) that were made in the v4 sunrise period be repeated in v6, like: [...]
Remember, the current policy was designed to meet two goals: 1) giving easy access to an IPv6 prefix allocation for real ISPs, and 2) not giving a prefix to enterprises or "toy" (or other small) ISPs. The mechanisms how this has been policed to a degree have been the "200 /48's" and "_to other organizations_" rules. If we still agree that we don't want to give /32's to enterprises, toy ISPs without any real number of customers (hey! my consulting company has two connectivity customers as well, should I get a /32 prefix?), or such, we have to keep in some checks. On the other hand, I think everyone agrees that real ISPs, with a large numbers of customers, should get a v6 allocation without any hassle. The current policy has allowed that, even though it's wording (".. in two years") might have been a bit scary. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Mon, Jun 21, 2004 at 12:41:05PM +0300, Pekka Savola wrote:
If we still agree that we don't want to give /32's to enterprises, toy ISPs without any real number of customers (hey! my consulting company has two connectivity customers as well, should I get a /32 prefix?), or such, we have to keep in some checks.
Have we figured out how to make multihoming work without giving multihomed networks their own prefix like in v4 ? -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 11.58, Carlos Morgado wrote:
On Mon, Jun 21, 2004 at 12:41:05PM +0300, Pekka Savola wrote:
If we still agree that we don't want to give /32's to enterprises, toy ISPs without any real number of customers (hey! my consulting company has two connectivity customers as well, should I get a /32 prefix?), or such, we have to keep in some checks.
Have we figured out how to make multihoming work without giving multihomed networks their own prefix like in v4 ?
Depends on your definition of "figured out". At the multi6 WG interim meeting last week we got down to 6 proposal from 32. And I think those 6 will come down to two fairly shortly. Then all we need to do is develop and implement it... I suggest joining the multi6 mailinglist. Instructions at http://www.ietf.org/html.charters/multi6-charter.html - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNa0LKarNKXTPFCVEQJFMgCfUoFi2ji1/2P+IxgUH2gkx+rRbYYAn1ph iwNvR0h/6q9c5bD1ZMnTb5ao =TuZe -----END PGP SIGNATURE-----
On Monday 21 June 2004 10:41, Pekka Savola wrote:
1) giving easy access to an IPv6 prefix allocation for real ISPs, and 2) not giving a prefix to enterprises or "toy" (or other small) ISPs.
I take offence at being called a "toy ISP". Apart from the moral issue here, this stance is probably illegal under EU law as it is blatantly anti-competitive. regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha@eirconnect.net Ireland | http://www.eirconnect.net
On Mon, Jun 21, 2004 at 11:00:36AM +0100, Sascha Luck wrote:
[this stance] is blatantly anti-competitive.
The whole IPv6 world is currently anti-competitive. Power is shifted to the bigger players more than in the v4 world. Independence from suppliers is not granted to smaller shops anymore. A technical scaling problem is used as an excuse to the conveniently raise the bar (currently [amongst other constraints] using some arbitrary quantity [number of customers] to qualify - hrhr). Even if a technical solution comes out of the multi6 WG, I have some serious doubts that the "internet core" will implement/support it, as it is against their essential commercial interests. And I totally agree with Oliver Bartels and others who proclaim that IPv6 won't take off until the enterprise multihoming issue is solved. Looks like the cat is biting it's tail... Regards, Daniel (slightly disillusioned)
On Tue, 22 Jun 2004, Daniel Roesen wrote:
Even if a technical solution comes out of the multi6 WG, I have some serious doubts that the "internet core" will implement/support it, as it is against their essential commercial interests. And I totally agree with Oliver Bartels and others who proclaim that IPv6 won't take off until the enterprise multihoming issue is solved. Looks like the cat is biting it's tail...
Which is why the solution will likely be such that it's transparent to the "internet core". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Monday 21 June 2004 10:41, Pekka Savola wrote:
1) giving easy access to an IPv6 prefix allocation for real ISPs, and 2) not giving a prefix to enterprises or "toy" (or other small) ISPs.
I take offence at being called a "toy ISP". Apart from the moral issue here, this stance is probably illegal under EU law as it is blatantly anti-competitive. regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha@eirconnect.net Ireland | http://www.eirconnect.net
OTOH, I'd hate to see the same mistakes (that seemed reasonable at the time) that were made in the v4 sunrise period be repeated in v6, like:
* too small assignments for customers forcing NAT in use,
v4 sunrise had too BIG, not too small, assignments. hence all the underpopulated As abd Bs. it took a major war, cidrd, to fix that. and yes your point holds; we're doing it again. those who forget history are condemned to repeat it. randy
Hi, On Mon, Jun 21, 2004 at 10:47:33AM -0400, Randy Bush wrote:
and yes your point holds; we're doing it again.
those who forget history are condemned to repeat it.
I dimly remember that it was *you* that argued very much in favour of "give /48s to every end site, don't start handing out different sizes", some few meetings ago. So what's wrong with it, all of a sudden? Could you please be a bit more specific about what you think is fundamentally wrong about the current IPv6 policy, so that we might go and fix it? "A networks are too big" doesn't really hold - if anything, /32s are too small. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
I dimly remember that it was *you* that argued very much in favour of "give /48s to every end site
not exactly. i argued against it within the ivtf; thinking it was a bit short. and i was also against assigning /48s to dialu-ups. but when i presented the ivtf position, i presented the ivtf position, not my personal opinion.
"A networks are too big" doesn't really hold - if anything, /32s are too small.
might it not depend on the size of the network? that is a lesson we learned in cidr back in the early '90s. how many times do we need to learn it? randy
Hi, On Mon, Jun 21, 2004 at 01:30:37PM -0400, Randy Bush wrote:
"A networks are too big" doesn't really hold - if anything, /32s are too small.
might it not depend on the size of the network? that is a lesson we learned in cidr back in the early '90s. how many times do we need to learn it?
Isn't that what we have? "You get a /32, unless you can explain why a bigger block is reasonable for your network, and in that case, you get more". So it *does* depend on the size of the network, but at the same time tries to reduce bureaucracy in the actual allocation process. (Personally, I'm a bit unhappy because I think the "32" number is erring towards the "conservation" side, and this might lead to having multiple allocations for ISPs that start small but grow quickly. But the way RIPE is currently reserving /29s for those ISPs, the case *should* be infrequent) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
--On måndag 21 juni 2004 10.47 -0400 Randy Bush <randy@psg.com> wrote:
OTOH, I'd hate to see the same mistakes (that seemed reasonable at the time) that were made in the v4 sunrise period be repeated in v6, like:
* too small assignments for customers forcing NAT in use,
v4 sunrise had too BIG, not too small, assignments. hence all the underpopulated As abd Bs. it took a major war, cidrd, to fix that.
I would argue, perhaps foolishly, that an assignment that is 1/4294967296 of the theoretical space available is sensible if done to any organisation large enough that it today, with the present routing infrastructure, is an autonomous system, and further, that this is much more sensible than the sunrise practice of handing out 1/65536 of the available space to just about anyone. (which *was* stupid, I agree, even though my present employer benefited greatly from this.) The practice is similar, yes, but the world surrounding it has changed.
and yes your point holds; we're doing it again. those who forget history are condemned to repeat it.
Yes, but if pain is to be avoided in some place, one must decide where to move it instead. As long as multi6 is working we need an interim solution. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
Quoting Kurt Erik Lindqvist <kurtis@kurtis.pp.se>:
Why not? If I have a large infrastructure, or is in the start-up phase or going through a network merger etc. I might have a lot of internal infrastructure but not many customer allocations. I fail to see why we would not include own allocations as those will be coming out of your block anyway.
The policy states that You can assign a /48 per POP - lets say a "broadband POP". If that should include the users asignments or not is not defined. -- amar ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-16, at 12.02, amar@telia.net wrote:
Why not? If I have a large infrastructure, or is in the start-up phase or going through a network merger etc. I might have a lot of internal infrastructure but not many customer allocations. I fail to see why we would not include own allocations as those will be coming out of your block anyway.
The policy states that You can assign a /48 per POP - lets say a "broadband POP". If that should include the users asignments or not is not defined.
Right. And I am arguing that those /48s should be included in the 200 limit. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNFPIaarNKXTPFCVEQI/lgCg2AMfFbKbRljx9vJGfBdzf7/zNsQAn2rq B0DIIaq+XYHNPoc9ATyFXN4K =FFGL -----END PGP SIGNATURE-----
Dear Laura, On Mon, 14 Jun 2004 10:36:40 +0200, Laura Cobley wrote: [...] Below are my views: >Below is an excerpt from the IPv6 Address Allocation and Assignment >Policy: First some gerneral comment: IPv6 is *currently* primarily an experimental feature and - from business man's view: a cost factor -. If IPv6 should ever get some significant growth, please *make it as easy as possible* to implement it. Please *avoid unnecessary buerocracy*. > 1. According to this criterion, LIRs who are operators planning to only > make /64 assignments appear not to qualify. Was this the community's > intention? It is very unlikely that some LIR would *only* make /64 assignments (DSL ?), but: This criterion would be just another item to prevent IPv6 to become a significant factor in the Internet. Thus try to avoid it. > Which interpretation was intended regarding the number of > assignments? In my view it was the fear that small blocks would increase the IPv6 global routing table size. But again, please keep in mind: - The LIR min. alloc. was changed from /20 to /21 and the requirement of a min. usage was dropped to permit large organizations with redundant upstreams to become (paying ;-) RIPE NCC members instead of using PI. These organisations want to be independend from single ISP's. If you would now force them back to single ISP upstream with a min. number of assignments, you would either gain "plans" which are not worth the paper they are written on, or, they just won't use IPv6. - With today's router technology and decreased RAM pricing and increased bandwith between BGP speakers, the larger table should not be a big issue in the IPv6 area. The real implementation of IPv6 (not just small experimental traffic) will sooner or later require new routers with e.g. improved hardware forwarding. - Operating a LIR requires some continuous investment. The RIPE NCC membership costs are some barrier to prevent a polution of the IPv6 global routing table with no-traffic prefixes. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On Mon 14 Jun 2004 10:38, Oliver Bartels wrote:
If IPv6 should ever get some significant growth, please *make it as easy as possible* to implement it. Please *avoid unnecessary buerocracy*.
There was a proposal, at RIPE-48, to abolish the 200 customer requirement altogether. (Don't remember by whom). The reasoning being that it raises the bar to IPv6 adoption unneccessarily. For the record, I support this argument.
It is very unlikely that some LIR would *only* make /64 assignments (DSL ?), but:
Mobile telcos?
In my view it was the fear that small blocks would increase the IPv6 global routing table size.
This is a technical problem and thus a technical solution should be looked for. Why should hardware vendors determine IP allocation policy? Best regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha@eirconnect.net Ireland | http://www.eirconnect.net
On Mon 14 Jun 2004 10:38, Oliver Bartels wrote:
If IPv6 should ever get some significant growth, please *make it as easy as possible* to implement it. Please *avoid unnecessary buerocracy*.
There was a proposal, at RIPE-48, to abolish the 200 customer requirement altogether. (Don't remember by whom). The reasoning being that it raises the bar to IPv6 adoption unneccessarily. For the record, I support this argument.
It is very unlikely that some LIR would *only* make /64 assignments (DSL ?), but:
Mobile telcos?
In my view it was the fear that small blocks would increase the IPv6 global routing table size.
This is a technical problem and thus a technical solution should be looked for. Why should hardware vendors determine IP allocation policy? Best regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha@eirconnect.net Ireland | http://www.eirconnect.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Below is an excerpt from the IPv6 Address Allocation and Assignment Policy:
5.1.1. Initial allocation criteria "d)"
"To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years."
1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention?
I personally think this is silly. Then again I have a hard time understanding why you would not give out a /48 to each customer or "site".
2. There are a number of interpretations of requirement "d)":
- NUMBER OF ASSIGNMENTS
-- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48.
-- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s.
Which interpretation was intended regarding the number of assignments?
Why not just "200 assignments"? And oh, while we are at it, why 200 assignments?
- RECIPIENT OF ASSIGNMENTS
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations.
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted.
-- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation.
-- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure".
Which interpretation was intended regarding the recipient of assignments?
Actually non from the RIPE community if I remember. But we discussed this before. IF we want to stay with the 200 limit, I would say 200 assignments. Period. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+JAaarNKXTPFCVEQIVHQCfaApDWVknpVsKo/qUQB6DtDdJvu8AoLuQ ix5Dx9pTA5w2gU62swoVUiNN =PRPl -----END PGP SIGNATURE-----
Hi all, See my inputs below in-line. Besides this, I think we are realizing that a change in the policy is needed. My understanding is that the current policy was developed in much different circumstances, including the main one, that at that time was not "so clear" IPv6 will be deployed, at least not in a short time, and this is clearly happening now and fast. Actually, one of the motivations for http://www.ripe.net/ipv6/ipv6-support-20040512.html was "Encouraging the participation of all those who are interested in the IPv6 policy development process". I guess there are more and more communities with IPv6 deployment experience, and unfortunately they are not all participating in the policy process. On the other way around also, not all the LIRs/ISPs have IPv6 experience, and may be this is one of the hurdles for the deployment take up, they could actually believe is much more difficult that the reality. Actually I know for ISPs that just don't consider even asking RIPE about an allocation, because their reading of the policy is like "you are really going to deploy IPv6 and ensure to have 200 customers soon". My feeling is that we need to facilitate the IPv6 deployment. Some of my thoughts: 1) Do we really want to keep the "intend" to provide 200 /48 (or an equivalent distribution) in two years ? May be we can extend this period to 5 years ? 2) Is 200 /48 appropriate ? I know about ISPs with LESS customers than that. May be is time to think in that today the point must be to just have interest in using IPv6 some time, even when no concrete users are asking for it. If the ISP want to make some experiments, is ridiculous to me asking them to go for an experimental allocation, then once they finish the experiment, to move for the real allocation. The experimental allocations must be for "experimental" things, not just for "not sure if I'm going to deploy IPv6, let me try". 3) The policy should not be different than in the case of IPv6 regarding own structure, others, or any mix of both. I think just using IPv6 should provide the right for an allocation. 4) I will go even further: Why not provide IPv6 allocations by default to all the IPv4 ISPs, unless they clearly state they aren't going to use it ? 5) And even much further, should be mandatory for the ISPs, in a time frame of for example 5 years, to provide IPv6 services IF they want to keep their IPv4 allocations ? Regards, Jordi ----- Original Message ----- From: "Laura Cobley" <laura@ripe.net> To: <address-policy-wg@ripe.net> Sent: Monday, June 14, 2004 10:36 AM Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Dear Colleagues,
We have received many comments that the text of the current IPv6 Allocation and Assignment Policy document can be difficult to read and understand. Some of these difficulties were presented at RIPE 48 by Leo Vegoda:
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-polic...
During the following discussions, the RIPE NCC was asked to co-ordinate work on clarifying the text. Please note that we do not intend to propose any policy changes.
In order to assist with rewriting the IPv6 Policy document, we would like to have some input from the community on the issues needing clarification. We will send each issue for discussion in a separate mail.
This is the first of these mails.
Below is an excerpt from the IPv6 Address Allocation and Assignment Policy:
5.1.1. Initial allocation criteria "d)"
"To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years."
1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention?
2. There are a number of interpretations of requirement "d)":
- NUMBER OF ASSIGNMENTS
-- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48.
-- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s.
Which interpretation was intended regarding the number of assignments?
I think the intend was 200 /48 or anything more or less equivalent.
- RECIPIENT OF ASSIGNMENTS
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations.
-- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted.
-- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation.
-- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure".
Which interpretation was intended regarding the recipient of assignments?
I don't think it was clearly foreseen if the 200 assignments exclude "own" assignments.
We look forward to receiving the community's input on this.
Best Regards,
Laura Cobley Registration Services RIPE NCC
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi, On Sun, Jun 20, 2004 at 01:05:09PM +0200, JORDI PALET MARTINEZ wrote:
5) And even much further, should be mandatory for the ISPs, in a time frame of for example 5 years, to provide IPv6 services IF they want to keep their IPv4 allocations ?
No. It's not the address policy's job to force market developments (it's worse enough already with the effects our policy has, but we should not do that on purpose). Our job is to make sure that numbers that must be globally unique are distributed in a fair and balanced way. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Laura, On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote:
During the following discussions, the RIPE NCC was asked to co-ordinate work on clarifying the text. Please note that we do not intend to propose any policy changes.
During the meeting, I asked you not to waste your time on this. Since the policy is already changing in the other regions, our time would be better spend to move forwards, instead of stalling the policy development process by spending time on 'clarifications'. I would like to ask the working group whether we can ask the RIPE NCC to summarize the different changes made to the policy in the other regions, so that we can have a discussion on which changes are appropriate. Thanks, David Kessens ---
Hi, On Mon, Jun 21, 2004 at 04:14:48PM -0700, David Kessens wrote:
I would like to ask the working group whether we can ask the RIPE NCC to summarize the different changes made to the policy in the other regions, so that we can have a discussion on which changes are appropriate.
Sounds like a useful plan.
From what I hear, things are moving in the same direction anyway ("drop 200-users rule, clarify some of the other issues"), and this may help to make better informed decisions.
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, SUMMARY of the IPv6 working group thread "Re: IPv6 Policy Clarification - Initial allocation criteria "d)" The discussion started with a request for clarification from the RIPE NCC hostmasters about the "200 /48 assignments to other organization" rule. At first, people discussed various interpretations of this: - whether or not "infrastructure /48s" count towards the 200 number (no clear statement what really was intended, as it didn't originally come from the RIPE region, and people have very different opinions on what it should be) - whether or not ISPs assigning only /64s (3GPP networks) qualify (most people seem to agree that those qualify, but per the letter, they don't. Some comments are confused why someone would assign /64s at all, but that's what the 3GPP standard recommends) In the course of the discussion, one major point emerged: - please *change* the policy and remove the "200 assignments" clause (and leave the remaining criteria mostly unchanged, that is, the applicant still has to be a LIR). there have been many voices supporting this change, and only one voice vehemently argueing against it. Masaka Ohta urges us to rework the whole system to make sure that at maximum 1000 routes appear in the global table. To base the WGs decision on more facts, the RIPE NCC has been asked to provide an overview about the current IPv6 policy (proposals) in the other regions. Filiz from the NCC has done this yesterday (thanks). There have been a couple of sidetrack discussions without specific results: - whether the "one size fits all" (/32) model for sizing the LIR allocations is a good way to tackle things, or whether it's repeating the "class A allocation" error. - whether or not using "more specific PA space" from one upstream ISP is a valid way to do BGP multihoming, at least for some networks - whether or not the price of a >10Gbit router is significantly changed if the number of routes it must carry is hard capped to 1000 (or 8192). (Oliver Bartels has sent me some more supporting documents. His claim is that a TCAM memory based hardware forwarding engine can handle at least 65k IPv6 prefixes at >10Gbit/s with a $150 US$ TCAM per line card. Going to a $350 US$ TCAM per line card enables >130k prefixes. Comparing that to the cost of 10Gbit/s. optics, SDH framing chips, and hardware development effort, that's a only a minor part of the total costs. For lower bandwidth, todays algorithms don't even need TCAM, SRAM is enough. Details upon request) - a very vehement discussion concerning a specific IETF multi6 proposal which may or may not have been judged fairly by the multi6 working group. Kurtis Lindqvist moved *that* subthread to the IETF list, and volunteered to give updates about multi6 progress to the APWG list. - at least two persons voiced very clearly that they are convinced IPv6 deployment will not go ahead unless companies that have their own IPv4 address space today will be able to reach that amount of independence and flexibility with IPv6 as well. Read: get "IPv6 PI" address space (or qualify for a LIR allocation, which is effectively the same). This latter part worries me. Judging from the discussion, and "counting voices", I propose to proceed as follows: - study the "other regions policy" report from the RIPE NCC - try to come up with new rules for the allocation criteria, dropping the 200-assignments part, and integrate whatever is necessary to balance the remainder. - circulate that proposal, present it at RIPE49, and if there is consensus, integrate it into the official RIPE policy. I don't think that we will be able to find consensus for "let's start handing out PI address space". But if one of the proponents wants to try to propose a policy that will permit "special networks" to receive a portable allocation without widely opening the flood gates (there *is* consensus that "everybody can get their own block and carry it around" is *not* what will scale), please go ahead and do so. Please do it in a new thread, though. Gert Doering -- APWG Co-Chair -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Thu, 24 Jun 2004, Gert Doering wrote:
- try to come up with new rules for the allocation criteria, dropping the 200-assignments part, and integrate whatever is necessary to balance the remainder.
Wasn't pretty much all of this (except one comment) based on the misconception that you'd actually have to have 200 IPv6 customers, not that you would have *potential* IPv6 customers (i.e: v4 customers, and you willing to give them service)? So I don't think there was such a strong need for removeing the rule, just if we clarified it sufficiently so that people would not (again!) interpret it too strongly. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hi Pekka, Sorry, but I can't agree with this. I provided the example of small ISPs, that have less than 200 customers for IPv4. So are we limiting those small ISPs (that may have a complete own infrastructure, even international peerings/links, etc.) and their customers from using IPv6 ? Some of this small ISPs survive because they provide service to a reduced set of companies, but BIG companies ... So the size of the ISP doesn't mean necessarily that the addressing space they may need is not big ! Just look to other RIRs ... Regards, Jordi ----- Original Message ----- From: "Pekka Savola" <pekkas@netcore.fi> To: "Gert Doering" <gert@space.net> Cc: "Laura Cobley" <laura@ripe.net>; <address-policy-wg@ripe.net> Sent: Friday, June 25, 2004 7:36 AM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
On Thu, 24 Jun 2004, Gert Doering wrote:
- try to come up with new rules for the allocation criteria, dropping the 200-assignments part, and integrate whatever is necessary to balance the remainder.
Wasn't pretty much all of this (except one comment) based on the misconception that you'd actually have to have 200 IPv6 customers, not that you would have *potential* IPv6 customers (i.e: v4 customers, and you willing to give them service)?
So I don't think there was such a strong need for removeing the rule, just if we clarified it sufficiently so that people would not (again!) interpret it too strongly.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi, On Fri, Jun 25, 2004 at 08:32:31AM +0200, JORDI PALET MARTINEZ wrote:
Some of this small ISPs survive because they provide service to a reduced set of companies, but BIG companies ... So the size of the ISP doesn't mean necessarily that the addressing space they may need is not big !
Customer size is a non-argument for v6. 5 BIG COMPANIES will receive the same 5 /48s as 5 small dsl customers. (Now if you offer dial-up services for all employees of 5 BIG COMPANIES, you'll reach 200 end site assignments very quickly - so, again, no problem with the 200-user rule here). But I think the whole point of the discussion is that the rule is pretty pointless. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Friday 25 June 2004 08:59, Gert Doering wrote:
But I think the whole point of the discussion is that the rule is pretty pointless.
I agree. Saying that we *plan* to make IPv6 available to 200 end sites within 2 years is pretty easy. The fact that we currently have no where near 200 end sites could be viewed as irrelevant as far as planniing is concerned. This in my view makes a joke of the rule. Even a brand new LIR with only half a dozen end sites at present could easily present a case for *planning* to have 200 over the next 2 years. It was suggested that if you don't/can't reach the 200 rule then you should take address space from your upstream. How many datacenters are going to be willing to do that. We'd like to be able to start offering IPv6 services for our datacenter, there's no way we're going to take a single upstream. A datacenter needs to be multihomed with different providers (at least in my opinion). I suppose I could assign a /48 to each customer in the datacenter (to reach the magic 200) but most customers have only *one* server, so that would be a big waste of space. Instead I'd simply assign a single /48 to the datacenter and that would be aggregated by us on our multiple links, but by doing this we'd never reach 200 end sites. I personally think we should get rid of the 200 rule completely. Saying something along the lines of: An LIR should provide IPv6 services (to end user sites) and advertise an aggregated route within 12 months of receiving the allocation. Regards, Jon
On Fri, 25 Jun 2004, Jon Lawrence wrote:
On Friday 25 June 2004 08:59, Gert Doering wrote:
But I think the whole point of the discussion is that the rule is pretty pointless.
I agree. Saying that we *plan* to make IPv6 available to 200 end sites within 2 years is pretty easy. The fact that we currently have no where near 200 end sites could be viewed as irrelevant as far as planniing is concerned. This in my view makes a joke of the rule. Even a brand new LIR with only half a dozen end sites at present could easily present a case for *planning* to have 200 over the next 2 years.
It was suggested that if you don't/can't reach the 200 rule then you should take address space from your upstream. How many datacenters are going to be willing to do that. We'd like to be able to start offering IPv6 services for our datacenter, there's no way we're going to take a single upstream. A datacenter needs to be multihomed with different providers (at least in my opinion). I suppose I could assign a /48 to each customer in the datacenter (to reach the magic 200) but most customers have only *one* server, so that would be a big waste of space. Instead I'd simply assign a single /48 to the datacenter and that would be aggregated by us on our multiple links, but by doing this we'd never reach 200 end sites.
I personally think we should get rid of the 200 rule completely. Saying something along the lines of: An LIR should provide IPv6 services (to end user sites) and advertise an aggregated route within 12 months of receiving the allocation.
Regards, Jon
1. repeating myself... "200 rule"... IMHO to dropped as soon as possible. 2. please drop the "conservation" thinggy... ~"big waste of space" one server means one LAN = /64, just like a p2p connection is also a LAN = /64. someone might disagree on this... ;-) if you have more than one LAN, that means a /48. if you have a customer with 2 servers, if they are on the same LAN, just put a /64 on top of the table. if he wants them separated (2 vlans), give him a /48 and simply route his 2 /64s. ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!"
Hi, On Fri, Jun 25, 2004 at 11:55:57AM +0100, Jon Lawrence wrote:
opinion). I suppose I could assign a /48 to each customer in the datacenter (to reach the magic 200) but most customers have only *one* server, so that would be a big waste of space.
Actually, "waste of space" is a non-argument for IPv6-to-customer assignments - you have 65k /48s (at least), which should make for a fairly big datacenter. The policy says "every customer gets a /48", except in very specific circumstances. (By the way: we don't assign /48s to our *datacenter* customers either - every datacenter customer VLAN gets a /64, no matter if "one single machine" or "hundreds". As soon as the customer has "more infrastructure" behind his VLAN, or a separate internet access product, he'll get the /48, of course). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Sat, 2004-06-26 at 00:12, Gert Doering wrote:
Hi,
On Fri, Jun 25, 2004 at 11:55:57AM +0100, Jon Lawrence wrote:
opinion). I suppose I could assign a /48 to each customer in the datacenter (to reach the magic 200) but most customers have only *one* server, so that would be a big waste of space.
Actually, "waste of space" is a non-argument for IPv6-to-customer assignments - you have 65k /48s (at least), which should make for a fairly big datacenter.
The policy says "every customer gets a /48", except in very specific circumstances.
(By the way: we don't assign /48s to our *datacenter* customers either - every datacenter customer VLAN gets a /64, no matter if "one single machine" or "hundreds". As soon as the customer has "more infrastructure" behind his VLAN, or a separate internet access product, he'll get the /48, of course).
I usually like to think of it like: - a 'link', thus a network which is not routed gets a /64. - a routed network gets a /48. The first includes p2p _links_, tunnel _links_ etc. But also an IX with one shared medium counts as a link, even if there are 100.000 devices on that same link. When there is a router in the riddle, then give them a /48. Which is just like you mentioned with 'more infrastructure'. Greets. Jeroen
So I don't think there was such a strong need for removeing the rule, just if we clarified it sufficiently so that people would not (again!) interpret it too strongly. You might think so, but I have the impression that the community
On Fri, 25 Jun 2004 08:36:52 +0300 (EEST), Pekka Savola wrote: thinks different. The point is : We want to push IPv6 forward. Here is the choice: - We insist on a strict 200 customers rule: IPv6 *will* die. Period. Because larger companies tend to use special business ISP's with often have less than 200 customers, *but* the service of these customers probably is important to the internet users. And to show the complete nonsense of the /48 rule: This will either even exclude companies like AOL or T-Online from IPv6 if they do not intend to assign /48's to their *residential* customers, or will force them to do so, which sooner or later again means: New prefix, full table, game over. - We "would not (again!) interpret it too strongly": Then this rule is worth nothing. A rule which should be interpreted in this way enforces that every applicant sends a "plan" like: "Of course *we want* to get zillions of IPv6 customers and became the one and only monopoly provider and thus 200 users is peanuts for us". A rule which should be interpreted this way is not worth the paper or disk space it is written on, even thru this is the current handling of the rule. We should prevent to waste the capacity of the RIPE NCC and limited time of their hostmasters to read such useless "plans" and then better completely remove the rule. And at the end this means: As it is ignored in practice, LIR will become the synonym for PI, which is *not* what was intended. - We look at the intention of the rule and modify the wording in a useful way to keep cover on the PI pot until a technical solution to the global table explosion problem is provided in some way, but to provide full level IPv6 to all customer servicing true ISP's (where ISP means: companies that sell connectivity to other non-affiliated customers) wanting to push IPv6 forward. I am a friend of "open words": I can not hide my impression that there are massive commercial interests of some large players to implement a market-prohibitive rule because their management *thinks* they will gain additional business customers from it. Some "technical" arguments are then used to support this interest. However, please here my words: Those managers *won't get* additional customers, however they *will* damage IPv6. For sure. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Hi, On Fri, Jun 25, 2004 at 09:23:26AM +0200, Oliver Bartels wrote:
And to show the complete nonsense of the /48 rule: This will either even exclude companies like AOL or T-Online from IPv6 if they do not intend to assign /48's to their *residential* customers, or will force them to do so, which sooner or later again means: New prefix, full table, game over.
This argument doesn't hold. Look at Telia - they got a /20. That's enough address space for at least 5 million /48s. Nothing precludes AOL or T-Online from applying for a /18, or even more, based on their customer numbers. (Also, if "every ISP that is able to fill a /20" will insert a 2nd or 3rd prefix into the global table, it definitely won't kill any router) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Fri, Jun 25, 2004 at 08:36:52AM +0300, Pekka Savola wrote:
On Thu, 24 Jun 2004, Gert Doering wrote:
- try to come up with new rules for the allocation criteria, dropping the 200-assignments part, and integrate whatever is necessary to balance the remainder.
Wasn't pretty much all of this (except one comment) based on the misconception that you'd actually have to have 200 IPv6 customers, not that you would have *potential* IPv6 customers (i.e: v4 customers, and you willing to give them service)?
Actually, since the current policy is in effect, this was the main sore spot about it. People being scared away due to misinterpretation, people complaining about the "restrictive policy", and so on. Nobody (from the RIPE region) ever spoke in favour of it, as far as I can remember...
So I don't think there was such a strong need for removeing the rule, just if we clarified it sufficiently so that people would not (again!) interpret it too strongly.
We would definitely need to clarify it "very much so". Even then, I'm not sure what good it does - a "normal" LIR that's serious about it will be able to come up with 200 prospective customers (if only by creative definitions of "end site"). The really problematic cases, like "big transport provider, most customers bring their own address space anyway, so few (if any) direct assignments" would still remain (NORDUnet comes to mind). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert, On Fri, Jun 25, 2004 at 09:57:19AM +0200, Gert Doering wrote:
Nobody (from the RIPE region) ever spoke in favour of it, as far as I can remember...
Actually ... It was a compromise between the different regions. As such, it worked just fine since we managed to get a policy in place that worked better than the one before. Times change though and it seems that nobody cares at all anymore about the fact that we are dealing here with global resource that has global impact and that should have a global policy. There is no point to keep adhering to global policy that is not in use anymore in any of the other regions. It is very sad, but it's the truth.
So I don't think there was such a strong need for removeing the rule, just if we clarified it sufficiently so that people would not (again!) interpret it too strongly.
We would definitely need to clarify it "very much so".
This is not about clarifying. The policy is very clear: 'you need a plan to have 200 customers'. I cannot help it that people have trouble reading that. Getting rid of the requirement for 'a plan' or for '200 customers' is a 'policy change' not a 'clarification'. And policy changes should be discussed out in the open and not be sneaked in as if they are just a minor 'clarification'. David Kessens ---
On Friday 25 June 2004 22:12, David Kessens wrote:
The policy is very clear: 'you need a plan to have 200 customers'.
That's the whole point. The policy says *plan* to make 200 /48 assignments to other organisations within two years. What's the point in that ? anyone can *plan* to make 200 assignments. It seems to be a rule for the sake of having a rule - I'm sure there must have been good reasons for bringing it in, perhaps I just don't get it. e.g. An LIR gets an allocation by showing a plan to assign 200 /48's. But after 2 years they've only assigned 50. They would have obeyed the policy even though they failed to achieve the 200 assignments. This says to me that the 200 assignment rule is completely pointless.
Times change though and it seems that nobody cares at all anymore about the fact that we are dealing here with global resource that has global impact and that should have a global policy.
Yes, it is a global resource and I agree that it should be used in accordance with some global policy. But that global policy has got to make sense, and I just can't see the sense in the 200 assignments rule. Jon
Jon, On Fri, Jun 25, 2004 at 10:53:00PM +0100, Jon Lawrence wrote:
On Friday 25 June 2004 22:12, David Kessens wrote:
The policy is very clear: 'you need a plan to have 200 customers'.
That's the whole point. The policy says *plan* to make 200 /48 assignments to other organisations within two years. What's the point in that ? anyone can *plan* to make 200 assignments.
The point was to have a slight barrier to make sure that only people that had a serious intent to deploy ipv6 networks would apply for addresses. As such, it actually worked and it was not too big of a hurdle for people who wish to deploy ipv6 either, although admittedly, it should be noted that at least some people seem to have trouble understanding the difference between a 'plan' and actually having 200 customers. This was at the time a compromise between the different regions and the most liberal rule that was acceptable for all regions. The alternative was to keep the old policy and I am pretty sure that you would like that one even less. From that point of view, it made a lot of sense for the RIPE region to accept this rule because it was better then what we had before. Let's not waste any more time on the '200 customer' rule. The reasons for it's existence are not there anymore. I was just trying to give a bit of background information why this rule existe and what it was designed for. Now that the other regions seem to depart from this policy and apply policies that are more liberal but also divergent from each other, it seems that there is unfortunately no reason any longer to aim for a global policy. The regional registries seem to be unwilling to support a process where we started to develop such policies on a global level through a bottom-up process. We tried for the ipv6 policies with a global maillist and it failed. This is a serious problem inherent with the regional setup that just doesn't make a lot of sense for resources that need global management. One day this is going to cause interesting problems. The system as it is setup today is working as a never ending escalation of liberalizing the rules without any regard for the reality that all those prefixes are going to end up in one global routing table. David Kessens ---
Hi David, I'm very interested to heard about what "interesting problems" do you think the lack of a global policy will create. May be having those problems openly discussed could provide the required propeller in order to ensure a global coordination again. Regards, Jordi ----- Original Message ----- From: "David Kessens" <david.kessens@nokia.com> To: "Jon Lawrence" <jon@lawrence.org.uk> Cc: <address-policy-wg@ripe.net> Sent: Saturday, June 26, 2004 12:27 AM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Jon,
On Fri, Jun 25, 2004 at 10:53:00PM +0100, Jon Lawrence wrote:
On Friday 25 June 2004 22:12, David Kessens wrote:
The policy is very clear: 'you need a plan to have 200 customers'.
That's the whole point. The policy says *plan* to make 200 /48 assignments to other organisations within two years. What's the point in that ? anyone can *plan* to make 200 assignments.
The point was to have a slight barrier to make sure that only people that had a serious intent to deploy ipv6 networks would apply for addresses. As such, it actually worked and it was not too big of a hurdle for people who wish to deploy ipv6 either, although admittedly, it should be noted that at least some people seem to have trouble understanding the difference between a 'plan' and actually having 200 customers.
This was at the time a compromise between the different regions and the most liberal rule that was acceptable for all regions. The alternative was to keep the old policy and I am pretty sure that you would like that one even less. From that point of view, it made a lot of sense for the RIPE region to accept this rule because it was better then what we had before.
Let's not waste any more time on the '200 customer' rule. The reasons for it's existence are not there anymore. I was just trying to give a bit of background information why this rule existe and what it was designed for.
Now that the other regions seem to depart from this policy and apply policies that are more liberal but also divergent from each other, it seems that there is unfortunately no reason any longer to aim for a global policy. The regional registries seem to be unwilling to support a process where we started to develop such policies on a global level through a bottom-up process. We tried for the ipv6 policies with a global maillist and it failed. This is a serious problem inherent with the regional setup that just doesn't make a lot of sense for resources that need global management. One day this is going to cause interesting problems. The system as it is setup today is working as a never ending escalation of liberalizing the rules without any regard for the reality that all those prefixes are going to end up in one global routing table.
David Kessens ---
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Jordi, On Sat, Jun 26, 2004 at 12:40:39AM +0200, JORDI PALET MARTINEZ wrote:
I'm very interested to heard about what "interesting problems" do you think the lack of a global policy will create.
May be having those problems openly discussed could provide the required propeller in order to ensure a global coordination again.
IP (both versions) address space is a global resource. It would be unfair for people operating in different regions if they would get addresses based on different rulesets, or worse are unable to get addresses in one region while they would be eligible in another. In addition, multinational companies are able to do address shopping in different regions (where it is easiest/cheapest), while local companies have to deal with the local monopoly that has more difficult rules than another region or has temporary service issues. [On a side note: The boundaries of the regions are completely artificial and irrelevant in a network that knows no borders. Why is it that we have to get our resources from areas on the globe that are rather expensive in an age when many companies are starting to move service industry jobs to places where it is more cost effective ?] In addition, a climate has been created where we are doing 'competive liberalization' of our rules, if one region changes the rules, others feel they have to follow, even though very often no research has been done on what actually the need for the policy change was, the consequences for the global routing table and whether other alternative solutions were possible that are cheaper in execution or more fair. And this is only a subset of all the issues, use your imagination and you will come up with your own set. David Kessens ---
Hi David, Fully agree with your comments. Why we don't try to open the eyes on those points in the different RIRs policy WGs ? Actually I'm even starting to doubt about the effectiveness of having different RIRs. It will not be simple to have a single entity, with different local offices, with localized training plans, etc., but single global policy ? I know this is "politically" difficult and even can be perceived as incorrect by some members but ... seems to me much more practical. One suggestion I made several times is that instead of having 3 regional meetings per year, we should have less regional meetings and 1 Global RIRs (all the members) meeting. This meeting can move each year to a different region and I'm sure will be very good to actually help to build a global policy. Regards, Jordi ----- Original Message ----- From: "David Kessens" <david.kessens@nokia.com> To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> Cc: <address-policy-wg@ripe.net> Sent: Friday, July 02, 2004 3:30 AM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Jordi,
On Sat, Jun 26, 2004 at 12:40:39AM +0200, JORDI PALET MARTINEZ wrote:
I'm very interested to heard about what "interesting problems" do you think the lack of a global policy will create.
May be having those problems openly discussed could provide the required propeller in order to ensure a global coordination again.
IP (both versions) address space is a global resource. It would be unfair for people operating in different regions if they would get addresses based on different rulesets, or worse are unable to get addresses in one region while they would be eligible in another. In addition, multinational companies are able to do address shopping in different regions (where it is easiest/cheapest), while local companies have to deal with the local monopoly that has more difficult rules than another region or has temporary service issues.
[On a side note: The boundaries of the regions are completely artificial and irrelevant in a network that knows no borders. Why is it that we have to get our resources from areas on the globe that are rather expensive in an age when many companies are starting to move service industry jobs to places where it is more cost effective ?]
In addition, a climate has been created where we are doing 'competive liberalization' of our rules, if one region changes the rules, others feel they have to follow, even though very often no research has been done on what actually the need for the policy change was, the consequences for the global routing table and whether other alternative solutions were possible that are cheaper in execution or more fair.
And this is only a subset of all the issues, use your imagination and you will come up with your own set.
David Kessens ---
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Actually I'm even starting to doubt about the effectiveness of having different RIRs. It will not be simple to have a single entity, with different local offices, with localized training plans, etc., but single global policy ?
Sounds like the Communist Party of the Soviet Union. It was definitely simpler but it simply did not work in the long run. The real world is too fluid; simple static theoretical approaches usually do not work. In the stormy seas of policy and politics, we need a calming influence to keep things under control and the current RIR system does this. A single global policy might lead us to something like this: http://www.offbeattours.co.nz/photo/18.htm But I think this: http://www.axonhost.com/active/crazywind/sailing/Log7-13.htm is good enough.
One suggestion I made several times is that instead of having 3 regional meetings per year, we should have less regional meetings and 1 Global RIRs (all the members) meeting. This meeting can move each year to a different region and I'm sure will be very good to actually help to build a global policy.
The RIR regions are already quite large geographically. That's why a lot of people don't participate in the regional meetings unless it comes very close to them. That's also why RIPE NCC has had special meetings in Russia and Dubai and Kenya. If we started to have global meetings even fewer people would attend them. And most of the people who would attend a global meeting already go to ARIN, RIPE, APNIC meetings. We need to avoid applying engineering solutions and techniques to problems of policy and politics. --Michael Dillon
If we have less but more productive meetings, more people will participate. Moreover, most of the time is even cheaper traveling abroad than for example within Europe ... And in any case, the people really interested, will do it anyway. More concretely, the people (not just a few) that actually attend the several RIRs meetings, will save some resources. Regards, Jordi ---- Original Message ---- From: <Michael.Dillon@radianz.com> To: <address-policy-wg@ripe.net> Sent: Friday, July 02, 2004 1:08 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Actually I'm even starting to doubt about the effectiveness of having different RIRs. It will not be simple to have a single entity, with different local offices, with localized training plans, etc., but single global policy ?
Sounds like the Communist Party of the Soviet Union. It was definitely simpler but it simply did not work in the long run. The real world is too fluid; simple static theoretical approaches usually do not work.
In the stormy seas of policy and politics, we need a calming influence to keep things under control and the current RIR system does this. A single global policy might lead us to something like this:
http://www.offbeattours.co.nz/photo/18.htm
But I think this:
http://www.axonhost.com/active/crazywind/sailing/Log7-13.htm
is good enough.
One suggestion I made several times is that instead of having 3 regional meetings per year, we should have less regional meetings and 1 Global RIRs (all the members) meeting. This meeting can move each year to a different region and I'm sure will be very good to actually help to build a global policy.
The RIR regions are already quite large geographically. That's why a lot of people don't participate in the regional meetings unless it comes very close to them. That's also why RIPE NCC has had special meetings in Russia and Dubai and Kenya. If we started to have global meetings even fewer people would attend them. And most of the people who would attend a global meeting already go to ARIN, RIPE, APNIC meetings.
We need to avoid applying engineering solutions and techniques to problems of policy and politics.
--Michael Dillon
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi, On Sat, Jul 03, 2004 at 01:32:16AM +0200, JORDI PALET MARTINEZ wrote:
And in any case, the people really interested, will do it anyway. More concretely, the people (not just a few) that actually attend the several RIRs meetings, will save some resources.
I certainly don't have budget (neither time nor financial) to travel to non-european places for "policy meetings". I would *love* to go to nice places in the US, or the far east, but somebody has to pay for it... OTOH, I like the existing system - it does the job pretty well. There are some regional differences, which isn't very surprising, as the member structure of the different regions is also very much different. But even if applied to a global resource some (minor) local differences make sense - if the underlying people and enterprises are different, the rules must adapt (most obvious example: the NIR structure in the AP region). Also, looking at the difficulties *today* of making a sensible policy, I can't see it getting any easier if even more people of wildly varying cultural background need to agree on something. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi Gert, I understand your point, but actually traveling to US or even AP sometimes is even cheaper than traveling to Europe, at least from Madrid ;-) Regards, Jordi ---- Original Message ---- From: "Gert Doering" <gert@space.net> To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> Cc: <address-policy-wg@ripe.net> Sent: Monday, July 05, 2004 2:25 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Hi,
On Sat, Jul 03, 2004 at 01:32:16AM +0200, JORDI PALET MARTINEZ wrote:
And in any case, the people really interested, will do it anyway. More concretely, the people (not just a few) that actually attend the several RIRs meetings, will save some resources.
I certainly don't have budget (neither time nor financial) to travel to non-european places for "policy meetings". I would *love* to go to nice places in the US, or the far east, but somebody has to pay for it...
OTOH, I like the existing system - it does the job pretty well. There are some regional differences, which isn't very surprising, as the member structure of the different regions is also very much different. But even if applied to a global resource some (minor) local differences make sense - if the underlying people and enterprises are different, the rules must adapt (most obvious example: the NIR structure in the AP region).
Also, looking at the difficulties *today* of making a sensible policy, I can't see it getting any easier if even more people of wildly varying cultural background need to agree on something.
Gert Doering -- NetMaster
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi David, I mostly agree with you, but... David Kessens wrote:
IP (both versions) address space is a global resource. It would be unfair for people operating in different regions if they would get addresses based on different rulesets, or worse are unable to get addresses in one region while they would be eligible in another. In addition, multinational companies are able to do address shopping in different regions (where it is easiest/cheapest), while local companies have to deal with the local monopoly that has more difficult rules than another region or has temporary service issues.
I very much agree with you on that. This should not happen, BUT I believe we cannot assume the same rules apply in all regions in this world.
[On a side note: The boundaries of the regions are completely artificial and irrelevant in a network that knows no borders. Why is it that we have to get our resources from areas on the globe that are rather expensive in an age when many companies are starting to move service industry jobs to places where it is more cost effective ?]
The network ist a technical transport layer, but if the network assists to bypass rules and laws - which definitively differ massively country by country - the network as a global thing will have ha hard time - no matter how many addresses it will be able to carry! We have to consider regional issues into the networking architecture, that user and content tracking must be integrateable as well as other features such as roaming and multihoming. Of course I do like freedom and free speech, but the same as customs on borders have their right of existance, taxes are essential and crime is a problem. If we don't integrate "APIs" for legal entities into the design, more and more blocks will be erected to filter traffic or scan contents in a very uneffective way, which also kills the BIG_Address-Advantage all at once. Is the phone system currently good or bad? It scaled pretty well with the country-code numbering plan and a more or less open end-device addressing scheme. OK, routing is complicated nowadays as well, but this system surely proofs, that localized concepts can be successful too. And multihoming phones is news to me anyway. If the cell breaks down, my cell-phone is dead. I do believe IP-whatever-Version will become no (even higher) success, if the design does not focus more on the application that on the network end-to-end connectivity "advantage". Actually 90% of all companies that demand multihoming, just need a redundancy for their application to stay up and not ONE addressblock that is connected by multiple providers. The whole problem starts when tying applications too close to the network. Regards, Kurt -- + Kurt Kayser - Geschäftsführer Netzwerke - teamix GmbH + * Südwestpark 35, 90449 Nürnberg, Germany (Old Europe) * # Tel: +49 911 30 999 0, Mobil: +49 160 5810284 #
Jon Lawrence <jon@lawrence.org.uk> writes:
On Friday 25 June 2004 22:12, David Kessens wrote:
The policy is very clear: 'you need a plan to have 200 customers'.
That's the whole point. The policy says *plan* to make 200 /48 assignments to other organisations within two years. What's the point in that ? anyone can *plan* to make 200 assignments.
It seems that folk have lost site of the motivation for this rule. What we were trying to achieve (and believe we still MUST strive to achive) is a balance between making it straightforward for a serious ISP to get an IPv6 block, but also prevent what is essentially an end site from getting an allocation direct from an RIR. The latter is not scalable long-term and must be prevented in general. The general goal is that any ISP that is seriously looking at deploying IPv6 and/or offering it to their customers should be able to get an allocation. But how do you "measure" the seriousness of this in straightforward, unambiguous ways? And how do you prevent what is essentially an end site from being able to get an allocation because (say) they happen to be a member of RIPE, ARIN, etc.? E.g., if all it takes to get an allocation is be a member, I suspect that some end sites will join _just_ to get an IPv6 address. It is these sorts of things that make it difficult to say "just give a block to anyone that asks," or otherwise remove all barriers to getting an allocation. The intention behind the wording:
d) have a plan for making at least 200 /48 assignments to other organizations within two years.
includes some key things. "other organizations" was intended to ensure that we don't get end sites saying "hey, I've got a global (internal) network, with 200 branch offices (each with a /48). I should qualify for an allocation". And "200" was chosen (somewhat arbitrarily) again to make it clear this wasn't just for a handful of end sites. In order to get good aggregation long term, we need to have ISPs aggregating _many_ end sites, i.e., in the thousands and more. This won't happen anytime soon, but once IPv6 becomes widely deployed, this is the sort aggregation we need. Thus, 200 was picked as a number large enough to indicate that over the long term aggregation of a significant number of end sites is needed. Finally, the 2 years figure was also somewhat arbitrary. I view the goal here as being something like: when IPv6 starts to get seriously deployed, and many end sites are being assigned /48s, at that point it would be appropriate to put some teeth into the "200 customers" figure. But since we aren't there, and don't really have any idea how long it will be before that kind of deployment takes place, we can't really put in a fixed number (and really believe it). Hence, the words "plan" and "two years". The idea here is that this indicates a serious committment to actually getting IPv6 enabled internally and made available to customers. But of course, if there is no customer demand, then the dates need to be pushed out per above. I believe all the RIRs have stated that they have no intention to go after LIRs after 2 years if they haven't actually gotten 200 customers. I suspect that they would start going after LIRs only after discussion within the community indicated that the state of deployment had advanced enough that it was now appropriate to go after deadbeats - LIRs that have allocations, but never really lived up to their obligations to really offer IPv6 service to its customers.
It seems to be a rule for the sake of having a rule - I'm sure there must have been good reasons for bringing it in, perhaps I just don't get it. e.g. An LIR gets an allocation by showing a plan to assign 200 /48's. But after 2 years they've only assigned 50. They would have obeyed the policy even though they failed to achieve the 200 assignments. This says to me that the 200 assignment rule is completely pointless.
Hopefully that explains the motivation behind the current wording. I agree that the current wording has been controversial and could be better. But what I would like to see is that any proposal for change keep the original goals in mind, rather than just say "stupid requirment, get rid of it completely - and don't replace it with anything else". We need to ensure for the long-term that the right balance is maintained between ease of allocation and prudent management of a (limited) public resource. And to be clear, I say "limited" no in the sense of numbers of addresses, but in the number of prefixes that can be effectively managed in the DFZ. Folks don't want just addresses, they also want connectivity to all other end sites. Thomas
On Thu, Jul 01, 2004 at 11:49:27AM -0400, Thomas Narten wrote:
Jon Lawrence <jon@lawrence.org.uk> writes: It seems that folk have lost site of the motivation for this rule. What we were trying to achieve (and believe we still MUST strive to achive) is a balance between making it straightforward for a serious ISP to get an IPv6 block, but also prevent what is essentially an end site from getting an allocation direct from an RIR. The latter is not scalable long-term and must be prevented in general.
I know a lot of endsites, that (essentially) have (a) a lot more need for address space than many ISPs and (b) the realistic chance to deploy IPv6 in a large network, because they can actually force the use of IPv6 in their network. I think this fight for "Allocations of Address space only to ISPs" is one of the best reasons not to do IPv6. Actually the only reason for this rule that I can think of is, that it is made by ISPs who as it seems either believe they have the biggest networks or believe they could tie up customers with that. I think both assumptions are plain wrong. Currently it means no big organisation I can think of is willing to do IPv6. Now they are free to move from provider to provider, then they are not. Businesswise it would be stupid to give up this freedom.
The general goal is that any ISP that is seriously looking at deploying IPv6 and/or offering it to their customers should be able to get an allocation. But how do you "measure" the seriousness of this in
So an ISP with 200 Customers (each havong one server in his datacenter) gets IP-Space allocated, a multinational company having a few thousand servers and a few hundredthousand workstations all connected through their own network, doesn't. Okay, these are extremes, but extremes show it the best: This does not make sense. Maybe the rule should not say "planning to connect 200 organizations" but rather "will connect x devices within the next 2 years". X has to be negotiated. Or, instead of devices, networks. But these are much more useful numbers. As well for some ISPs (which only 5-20 customers, but these are big) as for other organizations, which in the end connect more end-users then most ISPs.
"other organizations" was intended to ensure that we don't get end sites saying "hey, I've got a global (internal) network, with 200 branch offices (each with a /48). I should qualify for an allocation".
I think these should qulify as much as an ISP connecting 200 Dialup-users. Nils -- *SAMMELT OBSTKERNE!*
Hi Nils, El 02/07/2004, a las 2:03, Nils Ketelsen escribió:
On Thu, Jul 01, 2004 at 11:49:27AM -0400, Thomas Narten wrote:
Jon Lawrence <jon@lawrence.org.uk> writes: It seems that folk have lost site of the motivation for this rule. What we were trying to achieve (and believe we still MUST strive to achive) is a balance between making it straightforward for a serious ISP to get an IPv6 block, but also prevent what is essentially an end site from getting an allocation direct from an RIR. The latter is not scalable long-term and must be prevented in general.
I know a lot of endsites, that (essentially) have (a) a lot more need for address space than many ISPs and (b) the realistic chance to deploy IPv6 in a large network, because they can actually force the use of IPv6 in their network.
imho the difficulty here is how do you define a "large" network, i mean when a network is large enough to obtain its own allocation. to which i guess one option is what you mention below.... [...]
Maybe the rule should not say "planning to connect 200 organizations" but rather "will connect x devices within the next 2 years". X has to be negotiated. Or, instead of devices, networks. But these are much more useful numbers. As well for some ISPs (which only 5-20 customers, but these are big) as for other organizations, which in the end connect more end-users then most ISPs.
how much is x? regards, marcelo
"other organizations" was intended to ensure that we don't get end sites saying "hey, I've got a global (internal) network, with 200 branch offices (each with a /48). I should qualify for an allocation".
I think these should qulify as much as an ISP connecting 200 Dialup-users.
Nils -- *SAMMELT OBSTKERNE!*
Maybe the rule should not say "planning to connect 200 organizations" but rather "will connect x devices within the next 2 years". X has to be negotiated. Or, instead of devices, networks. But these are much more useful numbers. As well for some ISPs (which only 5-20 customers, but these are big) as for other organizations, which in the end connect more end-users then most ISPs.
In addition to a plan to connect x devices, the applicant should also be able to demonstrate that they currently have at least y devices connected to their network. This existing network does not have to be an IPv4 network, i.e. it could be GSM or some other technology. The point is that the applicant is a real network operator today with a real network and they are migrating to IPv6 technology in some way. Maybe the number y should be the same as (or similar to) the minimum size of a PI allocation. And maybe x should be the same. --Michael Dillon
I know a lot of endsites, that (essentially) have (a) a lot more need for address space than many ISPs and (b) the realistic chance to deploy IPv6 in a large network, because they can actually force the use of IPv6 in their network.
Note: end sites can get _lots_ of address space from their ISP. The issue is not about getting address space, it's whether address space is obtained direct from an RIR (with the presumption that it will be PI) or from the ISP. We simply do not know how to scale routing within the network if we give every end site its own direct allocation. Given that we don't know how to do it, it's _really_ hard to come up with fair/scalable policies that give only _some_ (e.g., the "biggest", however you define that) end sites a direct allocation, but not others.
I think this fight for "Allocations of Address space only to ISPs" is one of the best reasons not to do IPv6. Actually the only reason for this rule that I can think of is, that it is made by ISPs who as it seems either believe they have the biggest networks or believe they could tie up customers with that. I think both assumptions are plain wrong.
No. The reason for this rule is fundamentally a technical one. We do not know how to give every end site a direct allocation and keep the routing system afloat. This is a _real_ technical issue, and is not just something the ISPs have dreamed up to capture customers. (Well, some ISPs may welcome this as a side-effect, but it is not the real motivation for the policy). Thomas
On Fri, Jul 02, 2004 at 10:46:48AM -0400, Thomas Narten wrote:
I know a lot of endsites, that (essentially) have (a) a lot more need for address space than many ISPs and (b) the realistic chance to deploy IPv6 in a large network, because they can actually force the use of IPv6 in their network.
Note: end sites can get _lots_ of address space from their ISP. The issue is not about getting address space, it's whether address space is obtained direct from an RIR (with the presumption that it will be PI) or from the ISP.
What is an ISP then? Is an organization, providing a network to a few thousand (internal) suborganizations an ISP? If yes: Most companies will qualify as an ISP then, giving you the same problems you also have when allowing everyone getting address space. If no: All the universities, the governments, the RIPE itself, the IANA etc do no longer qualify for receiving allocations.
We simply do not know how to scale routing within the network if we give every end site its own direct allocation. Given that we don't
As I already mentioned earlier in this thread: You can either make IPv6 attractive to the business and hope for better technology or you make it easy for the technology and wait for people changing how they do business. I think technology will improve a long time before business people will invest money to get rid of benefits. I think this whole policy is too much tech-driven. But if the goal of the policy is to get IPv6 rolling, you can not only concentrate on a nice and shiny network from the engineering point of view. You also need to make it attractive to the potential customer. Internet on IPv4 was easy to bring to the customer, because it gave him a benefit without taking something away from him. It increased his possibilities. Now you are trying to bring a technology to the customer, that will limit his possibilities through the policies for handing out the ressource needed for the tech. Why should anyone be interested in that?
No. The reason for this rule is fundamentally a technical one. We do not know how to give every end site a direct allocation and keep the routing system afloat. This is a _real_ technical issue, and is not just something the ISPs have dreamed up to capture customers. (Well, some ISPs may welcome this as a side-effect, but it is not the real motivation for the policy).
Still the question is open: What is the logic in allowing a 200 customer (one server per customer) ISP an allocation and at the same time deny it to companies with thousands of servers and hundreds of thousands of workstations? What makes the company calling itself ISP more worthy for an allocation than ACME corp? Sorry, it only makes sense when you are an ISP. Otherwise I can not detect any logic in that. But you want the endsites to use IPv6. If only the providers use it you will end up with a very boring network. Nils -- May Brute Force be with you
Hi, On Fri, Jun 25, 2004 at 02:12:14PM -0700, David Kessens wrote:
On Fri, Jun 25, 2004 at 09:57:19AM +0200, Gert Doering wrote:
Nobody (from the RIPE region) ever spoke in favour of it, as far as I can remember...
Actually ... It was a compromise between the different regions.
Yes, I remember :-) - I just said "nobody from *us* direly wanted to see it there". Obviously someone from the other regions must have.
As such, it worked just fine since we managed to get a policy in place that worked better than the one before. Times change though and it seems that nobody cares at all anymore about the fact that we are dealing here with global resource that has global impact and that should have a global policy.
The differences in IPv4 policy are much more fundamental, and things are still running quite well. So minor differences in the v6 policy shouldn't do great harm. OTOH, a globally unique policy is nearly impossible to change (in any sort of reasonable timeframe) given the current RIR/LIR structures - as we can see here. These issues ("can we give an allocation to a 3GPP network? to a big transit provider with few direct customers?") are open issues since years now, and there doesn't seem to be any coordinated effort to change the global policy, or to integrate LACNICs local changes (if there *is* a global effort going on, it's hiding well, and I apologize for noticing it). [..]
So I don't think there was such a strong need for removeing the rule, just if we clarified it sufficiently so that people would not (again!) interpret it too strongly.
We would definitely need to clarify it "very much so".
This is not about clarifying. The policy is very clear: 'you need a plan to have 200 customers'.
"...in two years time". So what happens if you assume that it's unlikely that you'll reach that number (which would be "normal" for any network these days, unfortunately)? Do known-unrealistic plans count as well? Also it's not that clear that it have to be *customers* (what about LIRs that have only few direct re-selling ISP customers, but zillions of end sites connected to *them*?) or just "/48 assignments". What's a "site", by the way?
I cannot help it that people have trouble reading that. Getting rid of the requirement for 'a plan' or for '200 customers' is a 'policy change' not a 'clarification'. And policy changes should be discussed out in the open and not be sneaked in as if they are just a minor 'clarification'.
Hmmm, you must have missed something in my summary e-mail :-) - let me repeat that part: --------- snip ---------- Judging from the discussion, and "counting voices", I propose to proceed as follows: - study the "other regions policy" report from the RIPE NCC - try to come up with new rules for the allocation criteria, dropping the 200-assignments part, and integrate whatever is necessary to balance the remainder. - circulate that proposal, present it at RIPE49, and if there is consensus, integrate it into the official RIPE policy. --------- snip ---------- I won't consider that "sneaking it in". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (36)
-
amar＠telia.net -
Andre Oppermann -
Bernhard Schmidt -
Bertrand Maujean -
Brian E Carpenter -
Carlos Friacas -
Carlos Morgado -
Daniel Roesen -
David Kessens -
Eliot Lear -
German Valdez -
Gert Doering -
Havard Eidnes -
Havard Eidnes -
Jeroen Massar -
Joao Damas -
Jon Lawrence -
JORDI PALET MARTINEZ -
Jørgen Hovland -
Kurt Erik Lindqvist -
Kurt Kayser -
Laura Cobley -
marcelo bagnulo braun -
Masataka Ohta -
Michael.Dillon＠radianz.com -
Måns Nilsson -
Niall Richard Murphy -
Nils Ketelsen -
Nils Ketelsen -
Oliver Bartels -
Pekka Savola -
Randy Bush -
Sascha Luck -
Sascha Luck -
Sascha Luck -
Thomas Narten