March 1999 - lir-wg - mailman.ripe.net

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 17 Mar '99

17 Mar '99

Guy, Engin, thanks a lot for the explanation! Guy said: >Finally, you can only have one of these constructs per address. This is >common sense really since, if you have 3ffe::aaaa::bbbb, you cannot tell >how many zeroes are replaced with the first pair of colons and how many >by the second. There is no convention (AFAIK) for which block would be >written out in full. Personally, since I am lazy, I choose to write out >the fewer number of zeroes (remembering that I only need one zero per >block of 4 hex digits). > >So, some examples of IPv6 addresses are... > >3ffe:1100:0:c00::/52 >= Note the :0: because there is a :: later in the address Engin added: >The algorithm we use translates "5:0:0:78:0:0:0:0" >into "5:0:0:78::" but not "5::78:0:0:0:0". Of course, >both are legal, but we choose to double-colonize the >last group of zeros, and all prefixes are normalized >according to this and then put into the registry. which already gives us two compatible but different ways to deal with that, and >But I don't know what 6bone registry does. interesting, indeed. Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry? Is there a danger for braking something by _not_ allowing the "::" construct in the registry at all, or - in particular - not _in the middle_ of a prefix? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

5 5

Report on NCC progress toward ICANN Address Supporting Organisation (IMPORTANT)
by Keith Mitchell 17 Mar '99

17 Mar '99

This is a summary of activities undertaken by RIPE NCC on the formation of an Address Supporting Organisation to affiliate to ICANN since the 32nd RIPE meeting in Amsterdam. At that meeting, we heard from Esther Dyson, interim chairman of ICANN, on the need for an ASO to develop policy in the area of Internet addresses. She, in turn, got to meet us and to see the open forum that is RIPE in action, discussing and forming Internet policy in Europe. She expressed the view that RIPE made sense and the hope that RIPE would become involved in ICANN and in the formation of the ASO. In plenary, RIPE 32 clearly said that it wanted to maintain a bottom-up structure in Internet governance, with working and representative regional structures forming the basis of bodies such as the ASO. Least of all did they want a situation whereby ISPs would be obliged to argue their views on address policy in both European and global forums. Mandated by these clear expressions of policy, RIPE NCC undertook to engage in fresh discussions with the other RIRs, APNIC and ARIN. The NCC arranged a teleconference involving exec and board members of all three RIRs. This established a good deal of common round, including the importance of transparent and open process, and of representative structures. The RIRs and their communities were the most directly concerned with address policy and as such should have a key role in the ASO. The views of other groups were also important, and three possible sectors were identified here: government (representing the general public interest), engineering (with an overview of what was technically feasible), and industry (in the widest sense of the Internet). It was agreed to continue this discussion at the APNIC meeting in Singapore at the end of February, again with exec and board members of the three RIRs. There, the process was further opened, with EuroISPA and CIX being invited to attend. These two bodies had made a joint ASO proposal to ICANN, although they had neither advised nor consulted any of the RIRs about this. While anyone is of course at liberty to make a proposal to ICANN, RIPE NCC believes that this should be done in conformance with the open and transparent ethos of ICANN. Indeed, we believe that the RIPE NCC association can speak for you in matters of address policy; we have an obligation to do so on your behalf in external forums, provided we continue to listen to your views and to give effect to them in a clear and impartial manner. At the same time, we recognise that RIPE NCC does not represent ISPs in all aspects of their business, and that there are areas of concern which might best be addressed by trade associations such as EuroISPA. However, when it comes to address policy, you, through RIPE, are the people who have formed the working policies in Europe in the past decade, and RIPE NCC is your association which has helped to implement those policies, openly and impartially, on our behalf, and to represent those policies to other RIRs and to IANA. At the meeting in Singapore, the consensus was that time should be taken to produce a set of solid ASO principles and a charter, rather then being driven by looming deadlines. We are determined to pursue a course of action which will do justice to the collective opinion of members of the RIPE NCC association, and to the work which you have done in shaping and self-regulating the Internet in Europe. We welcome your views on these matters and look forward to representing them in the formation of the ASO. We encourage RIPE participants and RIPE NCC members to follow and participate in the formation process of the ICANN ASO - more information can be found at: http://www.ripe.net/info/ncc/regional.html and http://www.icann.org Keith Mitchell Chairman, on behalf of the RIPE NCC Executive Board

1 0

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 16 Mar '99

16 Mar '99

Hi David, Joao, et.al. <disclaimer> My question is going to prove complete ignorance when it comes to IPv6 address formats. So please bear with me :-) </disclaimer> => The two suggested changes are: => => - - addition of a "status" attribute with the following possible values: => TLA, NLA and SLA. => Syntax checks will be done so that: => TLA is only allowed if the prefix length is 3<x<=16 => NLA is only allowed if the prefix length is 16<x<=48 => SLA is only allowed if the prefix length is 48<x<=64 = =This is fine although, I am not entirely convinced that we really need =it. It's a bit redundant information. By definition something is a =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you =already know what it is. Can't you just generate this field =automatically ?!? For the IPv4 case we do have a well-established format for external representation of addresses and prefixes, i.e. full dotted quad with /prefix-length. In the 6bone registry there's IPv6 prefixes with a "structured" external representation, like "3FFE::/16" or "5FBC:1000::/32". So my questioon is: is there an agreed algorithm to insert punctuation at the "appropriate" positions, and does the proposal/criticism for the semantic checks do have an influence on this formatting? Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

4 3

IETF Attendees: Open Meeting on the Formation of the ICANN ASO
by Daniel Karrenberg 16 Mar '99

16 Mar '99

For those attending the IETF and interested in the future of Internet Address Space administration, here is notice of a pertinent meeting. This is one of a series of open meetings to solicit broad input on the formation of the "Address Upoorting Organisation" of ICANN. This meeting will not decide anything. It is just a vehicle to keep interested parties informed of what is happening and solicit discussion on the topic. The pertinent mailing list is <aso-discuss(a)ripe.net>. For more info, see: http://www.ripe.net/info/ncc/regional.html "Open Meeting on the Formation of the ICANN ASO" tomorrow Wednesdae 17 March, 1800-1900 (6pm-7pm) Minneapolis Hilton & Towers, Rochester Room (3rd floor) Agenda 1) Presentation of Current State of Process (NN) 2) Discussion Daniel

1 0

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 15 Mar '99

15 Mar '99

Dear all, A week has passed and no comments against the proposed modifications to the IPv6 object have been put forward. Therefore we take it that everyone is happy with it and will procede with the implementation. We expect this to be available in about two weeks. The original message is repeated below for your reference. Regards, Joao Damas DB Group RIPE NCC ------- Begin Original Message From: Joao Luis Silva Damas <joao(a)ripe.net> Date: Thu, 04 Mar 1999 10:20:17 +0100 To: lir-wg(a)ripe.net, db-wg(a)ripe.net Subject: Modifications to the inet6num in the RIPE Database Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC ------- End Original Message

2 1

ANN: Autohm source release
by Maldwyn Morris 15 Mar '99

15 Mar '99

Hi, I am pleased to announce the public release of the source code of autohm, the syntax-checking part of Web141, which is the RIPE NCC's European IP Address Space Request web form. Autohm is a fairly complex perl program designed to be run by web141.pl.cgi or standalone. Some customisation is required by the user, but nothing too complicated. This installation process is documented in docs/readme.pub. You mainly need to ensure that the directory and executable paths are correct and that the permissions are set correctly. You can get the ( gzip-ed and tar-ed ) file at: ftp://ftp.ripe.net/tools/autohm.1.24.tar.gz You can see our local copy running at: http://www.ripe.net/cgi-bin/web141/web141.pl.cgi We have had some helpful suggestions regarding web141, which we hope to implement during the next few days. Please let us know your comments and suggestions - we have already had some helpful suggestions regarding web141, which we hope to implement during the next few days. Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0

Re: Modifications to the inet6num in the RIPE Database
by Simon Leinen 15 Mar '99

15 Mar '99

Joao, sorry for the late comment, but I have a small issue with the following: > Syntax checks will be done so that: > TLA is only allowed if the prefix length is 3<x<=16 > NLA is only allowed if the prefix length is 16<x<=48 I think the separation between TLA and NLA space is not that clear. There are eight reserved bits between the TLA field and the NLA field (see section 2.5.7 of RFC 2373 and section 3.1 of RFC 2374). By introducing the checks as you proposed, you seem to have decided that those should be part of the NLA field. I don't think this is warranted. Section 3.2 of RFC 2374 makes it clear that some of the reserved bits might also be used to extend the TLA field in the future. You should permit either both TLAs and NLAs, or neither of them for prefix lengths between 16 and 24. I suggest rejecting such prefixes for the moment, and keep in mind that the reserved bits may be added to the TLA and/or NLA over time. If I missed some change in the intended structure of IPv6 unicast addresses, please apologize. Regards, -- Simon Leinen simon(a)switch.ch SWITCH http://www.switch.ch/ Who is General Failure & why's he reading my disk?

2 1

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 04 Mar '99

04 Mar '99

Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC

1 0

Re: lowering maximum assignment window
by IRIS-NIC 03 Mar '99

03 Mar '99

Hello all, first of all, sorry for th delay in answering the messages. I'm totally agree with this proposal, but I have two doubts: - the first: the assignment window is applicable to the whole organization addressing or only to the requests? I mean, if an organization has ten C classes, then they apply for ten ones more, have I got to take into account the total of them, twenty C classes, to see if they are reaching to the maximum assignment window? Or have I got to take into account only the ten C classes they apply for in the request? - the second: When will this proposal be made effective? And Paula, could you tell me which is the maximum assignment window for es.rediris? In the other hand, I'd like to comment you something that, maybe, would be related to this issue. I'd like to know if there is any document that say if there is any policy to apply in case of bad use of the assigned addresses. Have you ever had an experience in which you have to unassigned addresses to an organization? Is there any type of revisions we could do to assure the correct use of the assigned addresses? Maybe this organization doesn't use the total addressing any more or they applied in the past for a quantity of addresses that they don't use now because they have reorganized their networks. Which are your thoughts about this? Thank you and regards, Maribel Cosin. > > Hi all, > > Below is my original message with a proposal to lower the maximum > assignment window to a /21 instead of a /19. > > There was much discussion about this on the lir-wg mailing list. Here > is our final proposal that tries to take all the comments into > consideration: > > All registries that currently have a /20 or /19 assignment window will > be at a rotating interval (doing them all at once would put too much of > a load on an already large wait queue) set to a /23 assignment window > temporarily. They will then need to start sending a few requests to > show that they understand the assignment policies and procedures. If > these requests are fine, we will raise their assignment window to a > size that matches the requests we have seen from them (therefore not > necessarily to a /19). Hopefully this will get these registries on an > equal footing with other LIRs. The reason we need to review the > assignment window for all of these registries is that they started out > with a /19 assignment window in the beginning of the RIPE NCC. Whereas > younger registries started out with a 0 assignment window and have > since then proven that they can handle assignents of a certain size and > have therefore had their assignment window raised. For all of the > younger registries we already have a procedure in place of doing random > audits and we will continue doing this. > > By the way, one of the results of this discussion was that Poul-Henning > Kamp wrote a script that checks for inconsistencies between addresses > that are in use but are not registrered in the RIPE database. These > statistics can be found at: http://stat.cybercity.dk/ripe/ > > Please check this page for your own registry ID to see whether your > registry has any inconsistencies to fix. Of course the RIPE NCC will > also be contacting the Registries with the largest list of > inconsistenceis as well, but we don't have the resources to > systematically contact every registry on the list. > -- +---------------------------------------------------------------+ | RedIRIS NIC | | Centro de Comunicaciones CSIC RedIRIS | | Serrano 142 Tel: + 34 915855150 | | 28006 Madrid Fax: + 34 915855146 | | SPAIN Email: iris-nic(a)rediris.es | +---------------------------------------------------------------+

1 0

Adding nic handles to contact objects without one
by Joao Luis Silva Damas 02 Mar '99

02 Mar '99

Dear all, during the last RIPE meeting, in Amsterdam, the database working group discussed a proposal to automatically add NIC Handles to all person and role objects in the RIPE Database that don't yet have one (new objects can't be created without nic handles anymore). This proposal was supported by the working group and it was agreed that it should be circulated to the mailing lists to give people not attending a chance to provide input. This does not affect how other objects reference these person or role objects. This is only intended to bring old objects into conformance with the current object definitions and does not mean that data provided by the user will be modified. Only the nic handle attribute will be given a value when the object lacks one. No other attributes will be touched. Objects which already have nic handles will not be touched. The nic handle is a tag conveying no information about the user or role described in the object. It is an identifier for the object. This addition would make data more uniform and could be a benefit for everyone. For more information on nic handles, please read RIPE 157 and RIPE 189 available at http://www.ripe.net/docs Best regards, Joao Damas Database Group RIPE NCC

4 5