Summary of the PI Task Force's recent discussions
Dear Colleagues, Below is a summary of the recent discussions on the PI TF mailing list. The policy for portable address space is on the draft agenda for the Address Policy WG's session at RIPE 46 on 3 September. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager A summary of the PI TF's initial discussions was agreed and posted to the <lir-wg@ripe.net> mailing list on 6 May 2003. It can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/2003/msg00265.html Gert Döring presented on the discussion at the RIPE 45 LIR WG session. His slides can be found at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-pi-tf. pdf At RIPE 45 there was an agreement that the Task Force should continue its work. There was also an agreement that the PI policy is tied to the qualifying criteria for an initial IPv4 allocation. Discussion focused around a straw-man proposal to make four related policy changes. The proposed changes are outlines below along with a summary of comments received on them. 1. Reduce the minimum allocation size from /20 to /21 - There was some support for this point. There were requests for /21 allocations to come from a new and separately identified address blocks. 2. Remove the requirement to show an immediate need for 25% of the allocated address space (a /23 in this case) - There was no objection to this point. It was pointed out that with a lower barrier to entry the overhead of checking each requester is ready to use 512 IP addresses straight away would be unlikely to be equal to the value of the work. 3. No longer assign PI (Portable) address space to End Users - There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments. 4. End Users requiring a portable address block could become an LIR and receive a /21 allocation. - There was some support for this point. The costs of operating an LIR were raised as an issue. It was also noted that everyone may become an LIR. There is no barrier to membership of the RIPE NCC. There was a suggestion for a one-time service fee. There were also some additional comments: It was noted that if the policy allows for address allocations based on other criteria than prior demonstrated need some providers may filter those allocations. It was also noted that the RIPE NCC cannot provide any guarantee as to whether address space will or will not be routed of filtered by network operators. Some statistics were requested and provided for the first half of 2003: ASN assignments: 599 Allocation: 377 PI Assignments: 408 Number of /20s allocated per month for the same period: 200301 7 200302 20 200303 14 200304 16 200305 35 200306 24 Finally, it was noted that there is a requirement for globally unique addresses that will not be routed on the Internet.
On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda <leo@ripe.net> wrote a message of 91 lines which said:
3. No longer assign PI (Portable) address space to End Users
- There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments.
And what about ccTLD name servers?
Hi, On Mon, Aug 11, 2003 at 10:29:53AM +0200, Stephane Bortzmeyer wrote:
3. No longer assign PI (Portable) address space to End Users
- There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments.
And what about ccTLD name servers?
What's special about ccTLD name servers? "Special" in the sense of "needs an IP address that cannot ever change because it cannot be looked up by DNS"? There's nothing more special about ns.nic.de than about www.google.com - if the service moves, the address in the DNS changes, and people won't even notice. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, Aug 11, 2003 at 11:16:20AM +0200, Gert Doering <gert@Space.Net> wrote a message of 28 lines which said:
"Special" in the sense of "needs an IP address that cannot ever change because it cannot be looked up by DNS"?
Right.
There's nothing more special about ns.nic.de than about www.google.com - if the service moves, the address in the DNS changes, and people won't even notice.
Hmmm, Gert, sorry if I seem rude, but did you heard of glue records? If not, "whois -h whois.iana.org de" and you'll understand the difference with Google (the last change we requested from IANA, adding a new name server, ns3.domain-registry.nl, for ".re" is now three weeks old and still not performed... DENIC has similar experience.).
Hi, On Mon, Aug 11, 2003 at 11:20:16AM +0200, Stephane Bortzmeyer wrote:
There's nothing more special about ns.nic.de than about www.google.com - if the service moves, the address in the DNS changes, and people won't even notice.
Hmmm, Gert, sorry if I seem rude, but did you heard of glue records?
Of course.
If not, "whois -h whois.iana.org de" and you'll understand the difference with Google (the last change we requested from IANA, adding a new name server, ns3.domain-registry.nl, for ".re" is now three weeks old and still not performed... DENIC has similar experience.).
That's an operational problem, not a technical one. If IANA/ICANN isn't working, give them a good beating, but please don't break policy to cover for human deficiencies. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, Aug 11, 2003 at 11:36:54AM +0200, Gert Doering <gert@Space.Net> wrote a message of 29 lines which said:
That's an operational problem, not a technical one.
Policy is only about operational problems (filtering by operators, for instance, otherwise we would just use a /29 - more than enough for the nameserver and its close friends - and announce it with BGP).
If IANA/ICANN isn't working, give them a good beating, but please don't break policy to cover for human deficiencies.
It is completely unrealistic. Do you really expect the European ccTLD to be able to change Uncle Sam's policies and practices in the next few years? <troll>Change the policy to disallow any new IPv4 allocation and assignment. After all, IPv6 works, technically speaking, so it is "just an operational problem" now, do not create convoluted policies because of IPv4 addresses scarcity.</troll>
Hi, On Mon, Aug 11, 2003 at 11:43:07AM +0200, Stephane Bortzmeyer wrote:
If IANA/ICANN isn't working, give them a good beating, but please don't break policy to cover for human deficiencies.
It is completely unrealistic. Do you really expect the European ccTLD to be able to change Uncle Sam's policies and practices in the next few years?
As far as I understand, the threat from APNIC and RIPE to just ditch ICANN and get on without it seems to have had quite some effect. If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
<troll>Change the policy to disallow any new IPv4 allocation and assignment. After all, IPv6 works, technically speaking, so it is "just an operational problem" now, do not create convoluted policies because of IPv4 addresses scarcity.</troll>
Fine with me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, 11 Aug 2003, Gert Doering wrote:
Hi,
On Mon, Aug 11, 2003 at 11:43:07AM +0200, Stephane Bortzmeyer wrote:
If IANA/ICANN isn't working, give them a good beating, but please don't break policy to cover for human deficiencies.
It is completely unrealistic. Do you really expect the European ccTLD to be able to change Uncle Sam's policies and practices in the next few years?
As far as I understand, the threat from APNIC and RIPE to just ditch ICANN and get on without it seems to have had quite some effect.
If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
Has anyone tried serious reasoning with them about these delays??? ./Carlos "Upgrade the Internet! -- Now!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup FCCN - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 "Internet is just routes (125953/461), naming (millions) and... people!"
On Mon, Aug 11, 2003 at 11:00:02AM +0100, Carlos Friacas <cfriacas@fccn.pt> wrote a message of 29 lines which said:
If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
Has anyone tried serious reasoning with them about these delays???
Good Lord, on which planet were you, the last five years? All the ccTLD managers, as well as many governments, a lof of concerned individuals and so on, have tried to move IANA faster. If it does not, it is not a technical issue (unlike ".com" or even ".fr", the root is a very small zone, easily maintainable manually), it is a political one. IANA blackmails the ccTLD managers: if they do not sign the "sponsorship agreement" (not one in Europe did), even very trivial changes are delayed for ever.
|
On Mon, Aug 11, 2003 at 11:00:02AM +0100, Carlos Friacas <cfriacas@fccn.pt> wrote a message of 29 lines which said:
If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
Has anyone tried serious reasoning with them about these delays???
I have raised the question to the ASO address council and ICANN coordination list. I'll get back to the WG with the response and we can discuss a constructive approach to solve this. Hans Petter Holen RIPE Address Policy chair / ICANN ASO Address Council co-chair.
Good Lord, on which planet were you, the last five years? All the ccTLD managers, as well as many governments, a lof of concerned individuals and so on, have tried to move IANA faster. If it does not, it is not a technical issue (unlike ".com" or even ".fr", the root is a very small zone, easily maintainable manually), it is a political one.
IANA blackmails the ccTLD managers: if they do not sign the "sponsorship agreement" (not one in Europe did), even very trivial changes are delayed for ever.
On Mon, Aug 11, 2003 at 11:00:02AM +0100, Carlos Friacas <cfriacas@fccn.pt> wrote a message of 29 lines which said:
If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
Has anyone tried serious reasoning with them about these delays???
I have raised the question to the ASO address council and ICANN coordination list.
I'll get back to the WG with the response and we can discuss a constructive approach to solve this.
I have been in touch with ICANN staff regarding this, and from what I understand there are no open requests with IANA from the two previously mentioned ccTLDs. I got yet another example by private email, but it was from 2 years back. There is however an open request to add IPv6 addres recors to the root-zone. On this matter ICANN have asked for technical advice from the root server advisory group and are currently awaiting this advice before proceeding. If you have problems with the response time from IANA in such matters please first contact IANA staff with the ticketing number in question. Eventaly the CcNSO will be the forum to address such issues, until then feel free to contact me to use whatever connections I have with ICANN to solve operational problems. I hope this helps, Best Regards, Hans Petter Holen
As far as I understand, the threat from APNIC and RIPE to just ditch ICANN and get on without it seems to have had quite some effect.
If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
and why should they trust ripe and apnic more than icann? all act from positions of power while claiming service. randy
On Mon, Aug 11, 2003 at 07:18:31AM -0700, Randy Bush <randy@psg.com> wrote a message of 11 lines which said:
all act from positions of power while claiming service.
This is perfectly true. However, in practice, some are more inefficient/ obtrusive/ obnoxious, than others.
Randy, the RIPE NCC, imperfect as it may be, pre-dates ICANN by many years and has always been a bottom-up organisation driven by the ISPs. It is a response to the need of the ISPs to organise some technical aspects of the Internet infrastructure as a group, while going about their otherwise competitive business(es). The RIPE NCC is a neutral organisation providing professional services. The formal structure reflects this fully: a membership association directed by its members, the ISPs. Of curse the members have a task in this: to control and steer the association. RIPE itself has always been an open forum where even those wo are not members of the RIPE *NCC* can have great influence on what the RIPE *NCC* does. As such the RIPE NCC has *much* more legitimacy than ICANN, an organisation instigated by a policy need of one particular government. You know the history at least as well as I do. Other governments mostly jumped on the bandwaggon for varied reasons. ICANN still largely has to earn its legitimacy. This is a difficult task and I do not envy those undertaking it. But, through hard work of -among others- the RIPE NCC, ICANN's possibilities to interfere with ISP related matters without legitimacy, are extremely limited. I take offense if people put ICANN and the RIPE NCC in the same corner, especially people who know better. They are two totally different things. Randy, I would hope that you can stop sneering and help work towards improving the RIPE NCC, like you once did. Sincerely Daniel (first and longest serving of the RIPE NCC staff) On 11.08 07:18, Randy Bush wrote:
As far as I understand, the threat from APNIC and RIPE to just ditch ICANN and get on without it seems to have had quite some effect.
If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
and why should they trust ripe and apnic more than icann? all act from positions of power while claiming service.
randy
daniel, and both of us predate ripe, icann, and so forth. and many folk here contributed to the formation of all of these administrative monsters. big whoopie-doo. i would gladly be 30 years younger and a newbie. as a user of ripe, apnic, icann, ... i am telling you that it is hard for me to tell the difference these days in arrogance, application of power, bureaucratic delay, political maneuvering, stonewalling, blah blah blah. and when you push back as opposed to seriously discussing my concerns, as has been the case for a few years now, all i can think is QED. like other representative systems such as legislatures, the RIRs have moved from being associations of their users to becoming self-perpetuating governmental bureaucracies, who are not actually users themselves, but speak for us, tell us what we think and should do, and how we are being uncooperative and sneering. but at least the RIRs are not invading foreign countries and murdering people, as my local governmental bureaucracy seems wont to do. and don't give me "why don't you help?" i have for decades. you recently stopped listening. randy
I have not stopped listening to concrete ideas about improving the RIPE NCC. I am still here at the RIPE NCC working and listening. Of course the bureaucratic developments you sneer at *do* happen to some degree. This is inevitable and both you and I know it. The ability of individuals like you and me to influence things immediately and directly is reduced. Of course I personally I do not agree with all things the RIRs do and more often I do not agree with *how* things are done. What seems to divide us is that I still work to improve the 'least of all evils' structure and you sneer at it providing no alternative. I would hope that more people will chose the former instead of the latter. I also hope that people still see the relative mertis and the differences in legitimacy that exist between the various organisations. Sneering at the RIPE NCC without suggesting either alternatives or improvements does not help. Daniel
Randy Bush wrote:
like other representative systems such as legislatures, the RIRs have moved from being associations of their users to becoming self-perpetuating governmental bureaucracies, who are not actually users themselves, but speak for us, tell us what we think and should do, and how we are being uncooperative and sneering. but at least the RIRs are not invading foreign countries and murdering people, as my local governmental bureaucracy seems wont to do.
I could not agree more. No, really. There is no way for anyone with 'opposing' views to make them heard in any relevant forum. Mailing lists are not classed as official, and unless you speak "bureauocratese" (as I have said before), you cannot be heard in any official forum. I expect the overstaffed gravy train that is RIPE to continue supporting it's implicit "jobs for friends and for life" policies to continue and for us "members" to be expected to pay without any real voice. Please don't bother telling me about "taking part" and "attending meetings", I did that in the past, now I cannot be bothered wasting the airfare. Peter
Peter,
like other representative systems such as legislatures, the RIRs have moved from being associations of their users to becoming self-perpetuating governmental bureaucracies, who are not actually users themselves, but speak for us, tell us what we think and should do, and how we are being uncooperative and sneering. but at least the RIRs are not invading foreign countries and murdering people, as my local governmental bureaucracy seems wont to do.
I could not agree more. No, really. There is no way for anyone with 'opposing' views to make them heard in any relevant forum. Mailing lists are not classed as official,
why not? There is now an entire WG set-up to discuss the performance and activities of the NCC. Feel free to join.
and unless you speak "bureauocratese" (as I have said before), you cannot be heard in any official forum.
Uhm, would you care to elaborate?
I expect the overstaffed gravy train that is RIPE to continue supporting it's implicit "jobs for friends and for life" policies to continue and for us "members" to be expected to pay without any real voice.
This is not really a very professional nor constructive remark. I am sure you could move over to the ncc-services-wg mailinglist and explain your toughts on developing the NCC.
Please don't bother telling me about "taking part" and "attending meetings", I did that in the past, now I cannot be bothered wasting the airfare.
Then send text. - kurtis -
Randy, You and Daniel outrank me with some years, but I still feel a need to comment on this:
like other representative systems such as legislatures, the RIRs have moved from being associations of their users to becoming self-perpetuating governmental bureaucracies, who are not actually users themselves, but speak for us, tell us what we think and should do, and how we are being uncooperative and sneering. but at least the RIRs are not invading foreign countries and murdering people, as my local governmental bureaucracy seems wont to do.
Personally I think I have seen quite a few positive imporvements from the RIPE NCC over the last year. -hph
Hi, On Mon, Aug 11, 2003 at 07:18:31AM -0700, Randy Bush wrote:
As far as I understand, the threat from APNIC and RIPE to just ditch ICANN and get on without it seems to have had quite some effect.
If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect.
and why should they trust ripe and apnic more than icann? all act from positions of power while claiming service.
I was just argueing that "the internet will work fine without ICANN, so maybe they should actually start being productive for the money they burn". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
and why should they trust ripe and apnic more than icann? all act from positions of power while claiming service. I was just argueing that "the internet will work fine without ICANN, so maybe they should actually start being productive for the money they burn".
s/icann/icann, the rirs, .../ all this is a social experiment to see how many bureaucrats, amateur politicians (though the professionals are entering the fray), bureaucrats, lawyers, and just plain slimeballs it takes to replace one part-time computer scientist (whose 60th birthday would have been last wednesday). randy
.
s/icann/icann, the rirs, .../
all this is a social experiment to see how many bureaucrats, amateur politicians (though the professionals are entering the fray), bureaucrats, lawyers, and just plain slimeballs it takes to replace one part-time computer scientist (whose 60th birthday would have been last wednesday).
randy
To: Randy Bush <randy@psg.com> Subject: Re: [address-policy-wg] Summary of the PI Task Force's recent discussions
s/icann/icann, the rirs, .../
all this is a social experiment to see how many bureaucrats, amateur politicians (though the professionals are entering the fray), bureaucrats, lawyers, and just plain slimeballs it takes to replace one part-time computer scientist (whose 60th birthday would have been last wednesday).
randy
To some extent i have to agree with you Randy, but i also think we where taken advantage of by the suits. Once our computer scientist had passed on the community panicked, the last thing we wanted was a government agency running the show and the bureaucrats knew this. The bureaucrats held out their hands and we grabbed hold out of the fire into the fire some might say. But the bottom line is we can not change it now and to some extent it has stabilized, what we have to keep doing is not let them run the show and make sure it still works for us from the bottom up. Its easy to be bitter but lets channel that energy into making it better not complaining. The NCC lost their way for a bit and with some strong recommendations from the community pulled them selves back on track (not maybe all the way but at least what we have now is better than before the recommendations). Remember we ultimately hold the purse strings ;) BTW its good to be back. Stephen Burley Not working for a corporate corrupt giant anymore. Internet Communications Consultant Africonnect PS sorry if you got this mail twice.
all this is a social experiment to see how many bureaucrats, amateur politicians (though the professionals are entering the fray), bureaucrats, lawyers, and just plain slimeballs it takes to replace one part-time computer scientist (whose 60th birthday would have been last wednesday).
randy
well said! Hank Nussbacher
On Mon, Aug 11, 2003 at 08:28:21AM -0700, Randy Bush <randy@psg.com> wrote a message of 14 lines which said:
it takes to replace one part-time computer scientist
Do not paint the past in too bright colors. Besides the obvious (there was much less users of the Internet at this time, and a more closed community, which is easier to manage), Jon Postel made a lot of wrong decisions, too (such as denying ".tf" - French Southern Territories - to a French organization, then granting it without due process to a British one, in direct violation of his own RFC 1591 "For top-level domains that are country codes at least the administrative contact must reside in the country involved.").
It is completely unrealistic. Do you really expect the European ccTLD to be able to change Uncle Sam's policies and practices in the next few years?
Sligthly concerned that we should spend our time on "fixing" ICANNs operational pratices on ccTLD delegation trough IP addressing policy. -hph
It is completely unrealistic. Do you really expect the European ccTLD to be able to change Uncle Sam's policies and practices in the next few years?
Yes, I do. There are various ways to make this happen. They specificaly do not include * beating * calling eachother names (its ICANN not "Uncle Sam" * discussing ICANN ccTLD operational matters in the RIPE address policy WG. -hph
On Mon, Aug 11, 2003 at 08:52:45PM -0100, Hans Petter Holen <hpholen@tiscali.no> wrote a message of 13 lines which said:
* beating
I didn't.
* calling eachother names (its ICANN not "Uncle Sam"
Yes, it is the same thing. Read www.icann.org and specially the parts about the various contracts with DoC (US Department of Commerce) which approves, in writing, every change in the root zone file.
* discussing ICANN ccTLD operational matters in the RIPE address policy WG.
I didn't want to discuss ICANN matters. On the contrary, I wanted to emphasize that ICANN practices are a fixed feature, like gravity, and therefore we should design policies that take this feature into account (if policies are meant to solve real-world problems, that is, and not just to be "elegant").
On Mon, 11 Aug 2003, Gert Doering wrote:
That's an operational problem, not a technical one. If IANA/ICANN isn't working, give them a good beating, but please don't break policy to cover for human deficiencies.
Well, the policies should created for humans that deal with machines, not for machines that have to deal with humans. Renumbering Google means a change of an A (or CNAME) record. And people can still use Altavista or Lycos, so no big deal. Renumbering a ccTLD DNS is painful - even a secondary one. Not to mention what happens to the primary, if the operator providing connectivity to the registry bankrupts. Remember the ns.EU.net case? And what about public exchange points? Regards, Beri ---------------------------------------------------------- Berislav Todorovic, Designer KPN Telecom B.V. - OER IP Design and Engineering Phone: +31 70 343 1950 * Email: beri@eurorings.net ----------------------------------------------------------
Hi, On Mon, Aug 11, 2003 at 11:59:34AM +0200, Berislav Todorovic wrote:
Renumbering Google means a change of an A (or CNAME) record. And people can still use Altavista or Lycos, so no big deal.
If one DNS server for a ccTLD goes down, there are lots of secondaries that queries can go to. A normal end user won't even notice. If the primary goes down and needs to change IPs, that's primarily a non-user-visible change in the configuration of the secondary name servers.
Renumbering a ccTLD DNS is painful - even a secondary one. Not to mention what happens to the primary, if the operator providing connectivity to the registry bankrupts. Remember the ns.EU.net case?
Distribute your secondary name servers well, and a single nameserver going down won't do that much hurt. Of course procedures should be into place to change the glue records quickly (in the range of "hours", instead of "months").
And what about public exchange points?
In which way are ccTLDs related to public exchange points? Or are you referring to the discussed "abandon PI" policy change? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, 11 Aug 2003, Gert Doering wrote:
And what about public exchange points?
In which way are ccTLDs related to public exchange points? Or are you referring to the discussed "abandon PI" policy change?
In no way ... that was a separate question related to the PI policy change. I should have put a "P.S." in front. Sorry for confusion. ;-) ---------------------------------------------------------- Berislav Todorovic, Designer KPN Telecom B.V. - OER IP Design and Engineering Phone: +31 70 343 1950 * Email: beri@eurorings.net ----------------------------------------------------------
hi, On Mon, Aug 11, 2003 at 12:20:27PM +0200, Berislav Todorovic wrote:
And what about public exchange points?
In which way are ccTLDs related to public exchange points? Or are you referring to the discussed "abandon PI" policy change?
In no way ... that was a separate question related to the PI policy change. I should have put a "P.S." in front. Sorry for confusion. ;-)
Okay :-) - I have no clear answer on the exchange point question. Many of them are LIR already anyway (so they use PA). The approach with a one-time service fee to get "PI-like" space might work out for them. But yes, this needs discussion. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
(I am late in this discussion due to vacation and a crashed laptop)
And what about public exchange points?
In which way are ccTLDs related to public exchange points? Or are you referring to the discussed "abandon PI" policy change?
In no way ... that was a separate question related to the PI policy change. I should have put a "P.S." in front. Sorry for confusion. ;-)
Okay :-) - I have no clear answer on the exchange point question. Many of them are LIR already anyway (so they use PA).
This is not true. LIR - yes; PA - no. They do not met the requirements. That is part of the problem.
The approach with a one-time service fee to get "PI-like" space might work out for them.
Yes, that was the idea. - kurtis -
On Mon, 11 Aug 2003 11:36:54 +0200, Gert Doering wrote:
That's an operational problem, not a technical one.
If IANA/ICANN isn't working, give them a good beating, but please don't break policy to cover for human deficiencies. Well, the policy is for the humans and not the humans for the policy.
We are all *service* providers and thus we should deliver the *service* the customer which the customer demands. If there is a reasonable demand for PI (whether v4 or currently unsolved v6), we should try to do our best to serve this demand. Just my 2 cent for your "I don't like independend address space" position, which I don't believe is the position of the majority of the ISP's. 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 Monday, August 11, 2003 11:16:20 +0200 Gert Doering <gert@space.net> wrote:
What's special about ccTLD name servers?
Nothing -- your analysis is correct. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
On Mon, Aug 11, 2003 at 11:31:32AM +0200, Måns Nilsson <mansaxel@sunet.se> wrote a message of 32 lines which said:
What's special about ccTLD name servers?
Nothing -- your analysis is correct.
No, it is not. IANA does not store the IP address of www.google.com in the DNS zone file of the root.
--On Monday, August 11, 2003 11:35:17 +0200 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
What's special about ccTLD name servers?
Nothing -- your analysis is correct.
No, it is not. IANA does not store the IP address of www.google.com in the DNS zone file of the root.
Which is easily editable, and has the ability to propagate to all root servers in a fast and timely manner, using a well-known and defined interaction system. The root server operators will probably be happy to ensure us that this is the fact. There is no magic here -- just ordinary DNS. The ONLY magic addresses in the DNS are the root server IP addresses, because they need to be in the hint file; the rest is nothing special. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
I have one question, trying to understand the main goal of the exercise: * Is the aim of the a new PI policy to adjust the policy to the requests and needs of the industry or is it a way of getting a "special allocation" policy by another name? Joao On Monday, August 11, 2003, at 10:29 AM, Stephane Bortzmeyer wrote:
On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda <leo@ripe.net> wrote a message of 91 lines which said:
3. No longer assign PI (Portable) address space to End Users
- There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments.
And what about ccTLD name servers?
Hi, On Mon, Aug 11, 2003 at 11:48:28AM +0200, Joao Luis Silva Damas wrote:
I have one question, trying to understand the main goal of the exercise:
* Is the aim of the a new PI policy to adjust the policy to the requests and needs of the industry or is it a way of getting a "special allocation" policy by another name?
My aim is to adjust the policy (actually both PA and PI policy) to match observed need. People are requesting *multiple* PI blocks because they can't get a PA allocation, and that seems to be just wrong to me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert, On Monday, August 11, 2003, at 11:50 AM, Gert Doering wrote:
Hi,
On Mon, Aug 11, 2003 at 11:48:28AM +0200, Joao Luis Silva Damas wrote:
I have one question, trying to understand the main goal of the exercise:
* Is the aim of the a new PI policy to adjust the policy to the requests and needs of the industry or is it a way of getting a "special allocation" policy by another name?
My aim is to adjust the policy (actually both PA and PI policy) to match observed need.
That is good.
People are requesting *multiple* PI blocks because they can't get a PA allocation, and that seems to be just wrong to me.
Just to spell it out clearly: - Is it people who do not meet the minimum allocation size for PA? I guess these ones would ask for a single PI assignment? - Is it people who find it to be so much hassle to get an allocation that they end up requesting multiple PI blocks with the same amount of addresses? - People who have multiple sites and if they get a normal PA block will need to split it and end up with a bunch of non-routable sites? Other? Just trying to understand. One last thing. There is something that makes it unusually attractive to have PI space: it usually comes from "old" blocks (192/8, 193-195/8) where you don't have to bother with anyone filtering you if you have at least a /24 (damn easy to justify). Joao
Hi, On Mon, Aug 11, 2003 at 12:24:14PM +0200, Joao Damas wrote:
People are requesting *multiple* PI blocks because they can't get a PA allocation, and that seems to be just wrong to me.
Just to spell it out clearly:
- Is it people who do not meet the minimum allocation size for PA? I guess these ones would ask for a single PI assignment?
The ones I've heard about is "people that are startup ISPs, and still too small for PA". So they get a PI (because that's all they can get), and when that's full, they get another PI, and so on, until they can demonstrate "utilization of a /21" - and then they go for PA. They are effectively using PI as a "easier to get PA substitute" - which is wrong, but points at a serious problem in the policy.
- Is it people who find it to be so much hassle to get an allocation that they end up requesting multiple PI blocks with the same amount of addresses?
After a while, they move from your first category to this one...
- People who have multiple sites and if they get a normal PA block will need to split it and end up with a bunch of non-routable sites?
As far as I know, not this. [..]
One last thing. There is something that makes it unusually attractive to have PI space: it usually comes from "old" blocks (192/8, 193-195/8) where you don't have to bother with anyone filtering you if you have at least a /24 (damn easy to justify).
But this only works if you actually *get* a /24. So people that run two servers have to lie to the NCC to get a /24 (instead of a /29 or a /28), which is also a hint at a broken policy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
The ones I've heard about is "people that are startup ISPs, and still too small for PA". So they get a PI (because that's all they can get), and when that's full, they get another PI, and so on, until they can demonstrate "utilization of a /21" - and then they go for PA.
They are effectively using PI as a "easier to get PA substitute" - which is wrong, but points at a serious problem in the policy.
If an end user needs between /24 and /21 and do not expect much growth within the next few years but would like to be able to easily change provider without renumbering then I believe PI space is a good solution. I do not see the reason for using PI space if you're an ISP intending to become LIR, this means you will need to renumber when you get your PA allocation no matter if you use PA or PI, so why not just get a PA assignment from your provider until you can justify the /21? Marcus Ruchti says that the majority of the ISPs will not announce PA space from another AS, does this include more specific announcements? If the community does not allow this, whats the point of this: 1. Why is PI space required rather than PA space? - If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route(with the PA block holder adding a more specific route too). (part of the questions which must be answered after applying for PI space). We set up a few customers requesting PI space, some of the bigger ones also set up BGP and gets their own AS, if they cannot justify (nor wishes) a PA allocation, they need to be able to get PI space. A very peculiar thing regarding policy, a customer of ours applied for a PA block but could not justify a /20 (a year ago), BUT, when we applied on their behalf for PA space (ours) we were allowed to assign them a /20....! I was then told that as they had now been assigned a /20 they would be allowed to become LIR...! Hopefully this was a misunderstanding, if not, I think this part of the policy might need a few changes.. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote:
Marcus Ruchti says that the majority of the ISPs will not announce PA space from another AS, does this include more specific announcements? If the community does not allow this, whats the point of this:
You will need both parties. The first ISP to add a route-object, and the second to be willing to announce. -- Sabri Berisha "I route, therefore you are" user-specific rbl checking? http://sourceforge.net/projects/rblcheckd
Yes, I know, but I don't see any technical problems in doing this, and if the alternative is that the customer chooses another provider, then I would think that a lot of ISPs would accept. I think this is a better way than assigning a PI net which will only be used until the customer can justify the /21, I know there is some administrative tasks in doing it this way, but if the customer is willingly to pay an administrative fee I don't see the problem. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
-----Original Message----- From: Sabri Berisha [mailto:sabri@cluecentral.net] Sent: 11. august 2003 13:55 To: Christian Rasmussen Cc: Gert Doering; Joao Damas; Address Policy WG Subject: Re: [address-policy-wg] Summary of the PI Task Force's recent discussions
On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote:
Marcus Ruchti says that the majority of the ISPs will not announce PA space from another AS, does this include more specific announcements? If the community does not allow this, whats the point of this:
You will need both parties. The first ISP to add a route-object, and the second to be willing to announce.
-- Sabri Berisha "I route, therefore you are"
user-specific rbl checking? http://sourceforge.net/projects/rblcheckd
Hi, On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote:
I do not see the reason for using PI space if you're an ISP intending to become LIR, this means you will need to renumber when you get your PA allocation no matter if you use PA or PI, so why not just get a PA assignment from your provider until you can justify the /21?
That's what I thought people would do. But they don't. They want to be "independent", and so they go for PI, instead for a suballocation from one of their upstreams. (And they don't renumber, of course, but just keep the PI)
Marcus Ruchti says that the majority of the ISPs will not announce PA space from another AS, does this include more specific announcements?
I just disagree with that statement. PA-based multihoming is a valid approach to solve certain classes of problems. If some ISPs refuse to support this (because it creates more work for their NOC or whatever reason...), the market place has alternatives... [..]
A very peculiar thing regarding policy, a customer of ours applied for a PA block but could not justify a /20 (a year ago), BUT, when we applied on their behalf for PA space (ours) we were allowed to assign them a /20....! I was then told that as they had now been assigned a /20 they would be allowed to become LIR...! Hopefully this was a misunderstanding, if not, I think this part of the policy might need a few changes..
Changing this is part of Leo's proposal :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert, On Monday, August 11, 2003, at 02:05 PM, Gert Doering wrote:
Hi,
On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote:
I do not see the reason for using PI space if you're an ISP intending to become LIR, this means you will need to renumber when you get your PA allocation no matter if you use PA or PI, so why not just get a PA assignment from your provider until you can justify the /21?
That's what I thought people would do. But they don't. They want to be "independent", and so they go for PI, instead for a suballocation from one of their upstreams.
From an end user (enterprise) point of view, what is wrong with trying to minimise the pain of changing ISPs (renumbering)? On the other hand, it seems a waste of time and resources for all involved to give out blocks of size less than the minimum observed to be routed on the Internet. I know the registries can not guarantee routing of anything on the network but that does not mean the registries can not follow 'best common practice' as seen on the net, and I think everyone agrees that any prefix longer than a /24 doesn't make it past your border routers.
(And they don't renumber, of course, but just keep the PI)
Well, yes, would anyone return it if it worked for them? Joao
Hi, On Mon, Aug 11, 2003 at 02:38:47PM +0200, Joao Damas wrote:
On Monday, August 11, 2003, at 02:05 PM, Gert Doering wrote:
On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote:
I do not see the reason for using PI space if you're an ISP intending to become LIR, this means you will need to renumber when you get your PA allocation no matter if you use PA or PI, so why not just get a PA assignment from your provider until you can justify the /21?
That's what I thought people would do. But they don't. They want to be "independent", and so they go for PI, instead for a suballocation from one of their upstreams.
From an end user (enterprise) point of view, what is wrong with trying to minimise the pain of changing ISPs (renumbering)?
I wasn't judging, I was explaining why the mechanisms in the current policy don't work on real-world people - and as such, the policy is flawed in that respect. (Yes, I see a difference between "startup LIR having problems in getting an initial allocation -> fix policy" and "ccTLDs have problems in getting ICANN to change glue records -> fix ICANN").
On the other hand, it seems a waste of time and resources for all involved to give out blocks of size less than the minimum observed to be routed on the Internet. I know the registries can not guarantee routing of anything on the network but that does not mean the registries can not follow 'best common practice' as seen on the net, and I think everyone agrees that any prefix longer than a /24 doesn't make it past your border routers.
People actually do want PI space for other things (like "internal VPN connections that must be numbered unique but need not be routed"). But that's a different issue.
(And they don't renumber, of course, but just keep the PI) Well, yes, would anyone return it if it worked for them?
No, and that's part of the problem. If it can be avoided in the first place to have people announce multiple prefixes, then we should aim for that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Monday, August 11, 2003, at 05:03 PM, Gert Doering wrote:
People actually do want PI space for other things (like "internal VPN connections that must be numbered unique but need not be routed").
That is what I am trying to see. The more exceptions and the more fine tuning a policy has, usually the worse it is when it gets applied.
(And they don't renumber, of course, but just keep the PI) Well, yes, would anyone return it if it worked for them?
No, and that's part of the problem. If it can be avoided in the first place to have people announce multiple prefixes, then we should aim for that.
I agree. In general, policies that encourage people to distort reality or look for workarounds are not good policies. In those cases you have to go and fix the offending policy and try not to teak the workarounds. So, can we enumerate 4 or 5 items that cover a wide range of cases where people asked for PI and see if the origin of the problem is with the PI policy or elsewhere? Leo's earlier mail included a reference to a change in the minimum allocation size from a /20 to a /21 (8x /24). Is this likely to have an impact such that the pressure to use PI is going to be less? Joao
On Mon, 11 Aug 2003, Joao Damas wrote:
Leo's earlier mail included a reference to a change in the minimum allocation size from a /20 to a /21 (8x /24). Is this likely to have an impact such that the pressure to use PI is going to be less?
I think the minimum allocation size reduction is a good idea as it reduces the need for PI and waste in PA. PI should still be available for those who ask for it. There are indeed projects that would not be likely to need a /21 but might need independent space. It's a waste making them to take a /21. I can to some degree understand this desire for large PI blocks (/21 and above) but there should be place for the /24, /23 and /22 PI blocks. Sebastien. --- NetConnex Broadband Ltd. tel. +44 870 745 4830 fax. +44 870 745 4831 Court Farm Lodge, 1 Eastway, Epsom, Surrey, KT19 8SG. United Kingdom.
On Mon, Aug 11, 2003 at 02:05:59PM +0200, Gert Doering wrote:
That's what I thought people would do. But they don't. They want to be "independent", and so they go for PI, instead for a suballocation from one of their upstreams.
(And they don't renumber, of course, but just keep the PI)
Correct.
Marcus Ruchti says that the majority of the ISPs will not announce PA space from another AS, does this include more specific announcements?
I just disagree with that statement. PA-based multihoming is a valid approach to solve certain classes of problems. If some ISPs refuse to support this (because it creates more work for their NOC or whatever reason...), the market place has alternatives...
It's the end customer who refuses to use PA address space of one of his upstreams as when he terminates contract with him, he'll need to renumber. This is a commercial factor. Renumbering costs customers real money. As such, PA space ties the end customer somewhat into the PA-providing uplink. The second reason why I find this approach not too viable is that it would create a lot of inconsistant origin BGP announcements. I do understand that this is needed for anycast applications, but this should be limited to a number of "well-known" anycast services. On the other hand, this (and ONLY THIS) point is moot as soon as the end customer gets an ASN of his own and announces the PA more-specific himself. But this leaves still the commercial consideration discussed above. According to my experience, end customers multihome for two reasons: - technical resilience - commercial independence Multi-homing with PA subnets solves only the first problem space. Nowadays, customers are more and more (and more) looking to solve the second problem space as well (and for good reasons). We ISPs are here to solve customer problems - even if it means that we give up some means of customer retention, so we should aim to tackle the second problem space as well. I will respond to the four proposed policy changes in a seperate mail. Best regards, Daniel
3. No longer assign PI (Portable) address space to End Users
- There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments. And what about ccTLD name servers?
you can look them up in the dns. randy
And what about ccTLD name servers? you can look them up in the dns. Do you read all the thread before replying? That erroneous argument has already been beaten to death.
no. you just don't happen to like it. some decades ago, we moved from hosts.txt to a dynamic system to resolve names. part of its design was that it was rooted in a few well-known addresses, the ip addresses of the root servers. the protocol is such that you don't even need to have a completely correct list of those. now you want to fix the addresses of many names we worked hard to make dynamic. no thanks. randy
On Mon, Aug 11, 2003 at 07:37:14AM -0700, Randy Bush <randy@psg.com> wrote a message of 17 lines which said:
now you want to fix the addresses of many names we worked hard to make dynamic.
I'm fairly certain that many people here will like to read your proposal explaining how to suppress glue records in the root zone file. Send a copy to IANA, too.
--On Monday, August 11, 2003 16:18:14 +0200 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, Aug 11, 2003 at 07:13:22AM -0700, Randy Bush <randy@psg.com> wrote a message of 10 lines which said:
And what about ccTLD name servers?
you can look them up in the dns.
Do you read all the thread before replying? That erroneous argument has already been beaten to death.
dig fr ns +short | while read ns ; do dig $ns A +short dig $ns AAAA +short done 193.176.144.6 204.152.184.64 2001:4f8:0:2::13 128.105.2.10 193.51.208.13 128.112.129.15 128.112.128.1 192.93.0.1 192.93.0.4 192.134.0.49 2001:660:3006:1::1:1 I feel your pain -- I have once waited more than a month for an IANA ccTLD change, but do not let that pain mess up the allocation discussion -- they are separate issues. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote:
Below is a summary of the recent discussions on the PI TF mailing list.
As the pi-tf mailing list seems to have been closed (at least I'm unable to subscribe - pi-tf-request@ripe.net bounces as unknown), I guess further discussion should take place here (which makes some sense).
1. Reduce the minimum allocation size from /20 to /21
Agreed.
2. Remove the requirement to show an immediate need for 25% of the allocated address space (a /23 in this case)
Agreed.
3. No longer assign PI (Portable) address space to End Users
Strongly disagreed. Upstream-independent address space is _needed_. This cannot be ignored.
4. End Users requiring a portable address block could become an LIR and receive a /21 allocation.
An end-user can't be a LIR by definition. :-) Let's take a look at four entity categories: A) Commercial ISPs, assigning subnets to customers B) Enterprises (from very small companies to multinational heavyweights) C) non-commercial organisations (NCOs) being absolute end-users D) non-commercial organisations (NCOs) assigning subnets to org members Cat A is quite clear. They should become regular LIRs, receive an initial allocation under provisions of #1 and #2 above. RIPE NCC efforts are covered by LIR membership fees. Cat B should be able to get an IP block according to documented need plus some reserve (perhaps at least a /22 by default) without ability to sub-assign subnets. RIPE NCC efforts are primarily one-time and thus the requestor should pay a one-time fee for the request processing, plus a periodic, moderate maintenance fee to cover administrative and operational costs for their data in the RIPE systems like the RIPE DB. Usually, those kind of entities are nowadays typical PI requestors (getting IP space for free via a LIR), or Enterprise LIRs (paying significant yearly fees, but not requiring any cost-intensive RIPE NCC service like hostmaster support as no registry function is performed). Cat C+D are most interesting. The aim for those should be to keep cost as low as possible. Cat C would be typical PI requestors today, with no fees to be paid at all. IMHO, we should keep this cost neutrality for those kind of NCOs. Cat D is where the fun starts. Currently, Cat D NCOs would usually request larger PI blocks, and "silently" (without documentation in the RIPE DB due to the nature of PI assignments) sub-assign subnets to NCO members. As an example, imagine a "computer club" having built a city-wide "club WAN" by some creative means, being BGP multihomed to some ISPs, connecting club members with static IP subnets to this "club backbone". Naturally, the club would like to document those assignments in RIPE to provide sensible contact information for IP ranges, but isn't allowed due to the "end user" style of PI assignments (mnt-lower to RIPE NCC). NCOs like clubs usually can't afford to become LIRs, but would like to document such sub-assignments. I would suggest to treat them like Cat C, but: - Allocate a netblock of justified size, at least /21, like ISP LIRs - Allow assignments within this allocation for documentation reasons (NOT usage level _justification_) in RIPE DB. - require them to request their stuff via an established LIR like with Cat C and usualy PI requests today. - no fees Overall, in short: A) normal LIR status, with normal LIR payments to RIPE NCC B) end-user status, one-time fee plus moderate periodic maintenance fee C) non-commercial (totally) end-user status, no fees, request via a LIR D) non-commercial organisation able to document usage of IP blocks within their IP range, no fees, request via a LIR So, Cat A+D would receive PA allocations, and Cat B+C would receive PI assignments. Reading all that again, I might overcomplicate things. But then again, I don't simpler models being equally "fair". :-/
Finally, it was noted that there is a requirement for globally unique addresses that will not be routed on the Internet.
This would fall under Cat B (if commercial) or Cat C (non-commercial). Please take above as a proposal for discussion. I'm highly interested in comments. Best regards, Daniel
Hay, On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote:
On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote:
Below is a summary of the recent discussions on the PI TF mailing list.
As the pi-tf mailing list seems to have been closed (at least I'm unable to subscribe - pi-tf-request@ripe.net bounces as unknown), I guess further discussion should take place here (which makes some sense).
Closed, yes.
1. Reduce the minimum allocation size from /20 to /21
Agreed.
There shouldn't be much problems with that.
2. Remove the requirement to show an immediate need for 25% of the allocated address space (a /23 in this case)
Agreed.
That was a bad one anyways, for the reasons mentioned already. Such requirements only lead to faked requests and more work. We even had a customer who insisted on us faking some PA assignments for him so he can show a /22 for immediate use; of course he never wanted to use them in first place since he didn't want to renumber his customers twice. After we denied that, the customer left, but obviously found another LIR who had no problems with such things, at least he is LIR now for a while.
3. No longer assign PI (Portable) address space to End Users
Strongly disagreed. Upstream-independent address space is _needed_. This cannot be ignored.
Oh my... the big PI vs. routing table size ect. discussion. I _really_ don't want to get into this. But in general, PI is needed - people, deal with it. (This goes for IPv6, too by the way... some day you all will notice).
4. End Users requiring a portable address block could become an LIR and receive a /21 allocation.
An end-user can't be a LIR by definition. :-)
Hrnjaaa... Enterprise-LIRs are End-Users (more or less).
Let's take a look at four entity categories:
A) Commercial ISPs, assigning subnets to customers B) Enterprises (from very small companies to multinational heavyweights) C) non-commercial organisations (NCOs) being absolute end-users D) non-commercial organisations (NCOs) assigning subnets to org members
Cat A is quite clear. They should become regular LIRs, receive an initial allocation under provisions of #1 and #2 above. RIPE NCC efforts are covered by LIR membership fees.
ACK. as always.
Cat B should be able to get an IP block according to documented need plus some reserve (perhaps at least a /22 by default) without ability to sub-assign subnets. RIPE NCC efforts are primarily one-time and thus the requestor should pay a one-time fee for the request processing, plus a periodic, moderate maintenance fee to cover administrative and operational costs for their data in the RIPE systems like the RIPE DB. Usually, those kind of entities are nowadays typical PI requestors (getting IP space for free via a LIR), or Enterprise LIRs (paying significant yearly fees, but not requiring any cost-intensive RIPE NCC service like hostmaster support as no registry function is performed).
basically, ACK. I'm just no fan of being denied to enter useful information in the database, if i want to. See below, in D)... Why shouldn't it be allowed for big companies to use LIR-PARTITIONED or hopefully soon sub-allocations ect? ...on the other hand, what company does keep their RIPE database objects up-to-date anyways? *bighsigh* There's Enterprise-LIR status, i don't know how many "big" companies get LIR and how many just request a PI-block though. The problem is, you talk about NCOs not being able to document their "sub-assignments" with PI space, but you deny even large companies to do so with your suggestion here. At least those big ones can get Enterprise-LIR up to now and then have the ability (and responsibility) to manage and document their address space within their company, documenting different contact persons, abuse addresses ect. per subsidiary and so on.
Cat C+D are most interesting. The aim for those should be to keep cost as low as possible. Cat C would be typical PI requestors today, with no fees to be paid at all. IMHO, we should keep this cost neutrality for those kind of NCOs.
Full-ACK. Since i'm personally involved in two (and a half) of this kind of non-commercial organisations, i can only confirm this. I'm not pleased with arguments like "you are small, you are not commercial, you have no customers - why do you need to be in the global routing table? just get a descent IP uplink if you want stable connectivity and a big ISP certainly doesn't go bankrupt either so no need to renumber sometime soon!"-talk one _always_ gets about this situation. I'm absolutely against an Internet in the future, where only big companies with much money and thousands of IP addresses are allowed to be completely independant and have full backup connectivity. (i.e., having their prefix(es) showing up in the DFZ). NOT to assign anymore PI-space and denying a cheap way to get PA Allocation blocks of routeable size for no/low fees would be a first step towards that. NOT having some kind of PI-space in the IPv6 world is, too (though, a bit different there, but that's another discussion).
Cat D is where the fun starts.
Currently, Cat D NCOs would usually request larger PI blocks, and "silently" (without documentation in the RIPE DB due to the nature of PI assignments) sub-assign subnets to NCO members. As an example, imagine a "computer club" having built a city-wide "club WAN" by some creative means, being BGP multihomed to some ISPs, connecting club members with static IP subnets to this "club backbone". Naturally, the club would like to document those assignments in RIPE to provide sensible contact information for IP ranges, but isn't allowed due to the "end user" style of PI assignments (mnt-lower to RIPE NCC).
Thank you for describing what i constantly do because i'm forced to. The housing subnets for club-members are refered as one big "housing subnet" in the RIPE reuqest(s), but of course everyone gets a small subnet and a VLAN ... but i can't document it, because there's no sub-assigning or PI-Allocations (bad, bad...) Same goes for IPSEC-Tunnels ect. Though, the problem here seems to be that not enough of those situations with NCOs exist?! (if i'm wrong, show up people! :) ) ==> Probably this shouldn't be narrowed down to NCOs, but also include "very small ISPs", who want to provide adequate services but only have very few customers, and rather want to invest their money into infrastructure than in RIPE membership fees. Whatever, a local WLAN provider with some Hotspots and few point2point links for some offices of customers with permanent links ect. Another point may be that many are not-so-unhappy about not having the responsibility to deal with assignment and record- keeping activities. I'm not sure but i guess at least some NCOs/small ISPs are quite happy with PI space for that reason, too. (which is bad i mean if PI-space is abused for such reasons)
NCOs like clubs usually can't afford to become LIRs, but would like to document such sub-assignments. I would suggest to treat them like Cat C, but:
- Allocate a netblock of justified size, at least /21, like ISP LIRs - Allow assignments within this allocation for documentation reasons (NOT usage level _justification_) in RIPE DB. - require them to request their stuff via an established LIR like with Cat C and usualy PI requests today. - no fees
sounds like a nice compromise. Another one would be an official introduction of PI-Allocations. For example for me, in all cases i don't need a /21, a /23 is enough, most likely forever. "ALLOCATED PI" status exists, why not use it? Of course that's no solution for the future, if i read it right, available PI-blocks are fading away fast. And with your suggestion, new requests might result in PA-allocation-blocks of routable-size, no PI anymore. But probably as additional feature for already existing situations like that with existing PI-Assignments? -> migrate to PI-Allocations on request? ...just an opinion since we already have many relatively small PI blocks out there now which are probably used like described here to a certain degree.
Overall, in short:
A) normal LIR status, with normal LIR payments to RIPE NCC B) end-user status, one-time fee plus moderate periodic maintenance fee C) non-commercial (totally) end-user status, no fees, request via a LIR D) non-commercial organisation able to document usage of IP blocks within their IP range, no fees, request via a LIR
So, Cat A+D would receive PA allocations, and Cat B+C would receive PI assignments.
Reading all that again, I might overcomplicate things. But then again, I don't simpler models being equally "fair". :-/
I put it a bit more general - Independant address space must be available for everone who has a good reason and knows what he/she is doing (that explicitiy does not mean "anyone" as in "anyone" :) ) - There should be possibilities to get address space and have the ability to assign address space without paying horrible RIPE membership fees and the need to fulfill minimum requirements if one is very small and/or a NCO Up to now, you can get PI-space from seperate PI-blocks, any size, but only assignments, no allocations, so documentation is impossible, this is bad for the reasons mentioned above. This was an intended situation, but i think it turned out badly. (More and more PI requests, no documentation of actual assignments within PI assignments...), so it should be changed. And obviously PI-blocks are soon gone. - Small(!) one time or per-year fees are OK, of course with reduced RIPE services, or none at all (-> handling via a LIR); NO FEES are recommended for special cases like NCOs or veeery small ISPs Or to make it easier, probably some reduced-price LIR status for those ("Status: Very Small < Small < Medium < Large" :) ) It's most likely safe to assume that those "small" organisations who really want to get into all the RIPE stuff probably have more self-interest in the things and mean less hassle than one or another "bigger" commercial LIR, so they don't really mean "more work" for the RIPE NCC. But that rather leads into the recent "RIPE-tasks and cost" discussion we had earlier this month. => in short - Daniel's proposal is quite nice so far Though, I wouldn't refuse some kind of "enry-level LIR status" either. Sounds easier for me. Nothing new to implement (not much at least) and no need for seperate PI blocks anymore..
Finally, it was noted that there is a requirement for globally unique addresses that will not be routed on the Internet.
This would fall under Cat B (if commercial) or Cat C (non-commercial).
I don't really see a difference about non-routed addresses either. If IPv4 space finally runs out, probably some more developers and ISPs start deploying IPv6 faster, that's only positive. Doesn't nescessarily mean to _waste_ IPv4 addresses, but i don't see a point in more and more conservation policies. (no more PI assignments... probably more restrictive policy for non-routed addresses ect.)
Please take above as a proposal for discussion. I'm highly interested in comments.
done. Sorry for possible confusion, this is a pre-morning-coffee-reply. I rather wonder why noone else replied yet? Does that mean "granted" and we can implement that by next week? :) -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================
participants (9)
-
Berislav Todorovic -
Carlos Friacas -
Christian Rasmussen -
Daniel Karrenberg -
Daniel Roesen -
Gert Doering -
Hank Nussbacher -
Hans Petter Holen -
Joao Damas -
Joao Luis Silva Damas -
Kurt Erik Lindqvist -
leo vegoda -
Måns Nilsson -
Oliver Bartels -
Peter Galbavy -
Randy Bush -
Sabri Berisha -
Sascha Lenz -
Sebastien Lahtinen -
Stephane Bortzmeyer -
Stephen Burley