From stephenb at uk.uu.net Mon Mar 1 09:14:42 1999 From: stephenb at uk.uu.net (Stephen Burley) Date: Mon, 01 Mar 1999 08:14:42 -0000 (GMT) Subject: Poul-Henning's statistics (was: lowering maximum assignment In-Reply-To: <199902261856.TAA21769@aegir.EU.net> Message-ID: Agreed. "LIR-ALLOCATED" would be good especially with IPV6 on the way. > Personally I think that LIRs *should* be allowed to give objects a status of > "ALLOCATED" in some circumstances. > > Imagine, if you can, your typical supernational registry which gets multiple > address blocks allocated by the NCC for redistribution amongst the LIR's 20 > or or more associated organisations. Here a lower level "ALLOCATED" inetnum > could be used to keep track of this redistribution (if only the NCC's > auditing tools didn't automatically assume that these - carefully labelled - > allocations were duplicate assignments. > > Another possible use for LIR "ALLOCATED" inetnum objects would be to keep > track of where a range of addresses was being used for assignments to VSE > customers connected at a particular point of presence. > > ... just my thoughts from several years of running a large supernational > registry and currently being in the middle of a lengthy registry audit by > the RIPE NCC... ;-) > > James > > ----- ___ - James Aldridge, Senior Network Engineer, > ---- / / / ___ ____ _/_ -- EUnet Communications Services BV > --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL > -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 > - ----- 24hr emergency number: +31 20 421 0865 ---------------------------------- Stephen Burley Senior Hostmaster for UUNET Date: 01-Mar-99 Time: 08:12:32 http://www.uk.uu.net ---------------------------------- An MCI WorldCom Company From Andreas.Wittkemper at de.uu.net Mon Mar 1 12:47:06 1999 From: Andreas.Wittkemper at de.uu.net (Andreas.Wittkemper at de.uu.net) Date: Mon, 01 Mar 1999 12:47:06 +0100 Subject: Adding nic handles to contact objects without one In-Reply-To: Your message of "Fri, 26 Feb 1999 17:09:02 +0100." <199902261609.RAA03687@x41.ripe.net> Message-ID: <199903011147.MAA03298@valinor.de.uu.net> Hello, Joao Luis Silva Damas writes: > "Eamonn" writes: > * > * Hi Joao, > * > * I'd like to know what exactly are the advantages (and to whom) to > * adding a nic-hdl to person objects which don't already have one ? > * > > I think there are benefits for everyone. The database becomes more coherent, > ambiguity between different people with the same name disappears (especially > if as you say below, references by name are then substituted by references to > NIC Handles). > > * In some cases a person (without a nic-hdl) has their name referenced > * in other Db objects. This was before nic-hdls were mandatory. So if > * you add a nic-hdl to such a person's person object what can be done to > * those objects which reference his/her name ? > > That, I think, is a discussion for these lists. Either the user does it or the > RIPE NCC can do it if users wish to. Of course this can only be done for > references by name corresponding to names that are unique in the database, > otherwise we wouldn't know who to assign the object to and we shouldn't. It would be a great pleasure for us, if the RIPE NCC could do this task. We have some very old assigments which lack the nic-hdls. So if we only had to sort out the ambigious person objects it would be very helpful. But... > * > * There is no way of distinguishing the names referenced in the contact > * attributes of these objects since a similar name can refer to > * different people. > * > > Indeed. it should be remarked that the person object has been assigned a nic-handle by the RIPE-NCC so that a human can easier recognize the old object and can update the referenced objects. For example: remarks: nic-handle added by the RIPE-NCC consistency project (19990301) > > * Then you have the problem where these people created a new person > * object for themselves when nic-hdls became mandatory and left their > * old person object for dead. How will you overcome these old person > * objects ? > * > > Yes, that happened in the past. The software can cope with that now so we > shouldn't see cases like those any more. > The cleanup I think is best done within the consistency project which is right > now regaining speed (more on that soon...) Regards, Andreas Wittkemper NIC & DNS Team UUNET Deutschland GmbH Tel. +49 231 972 00 Emil-Figge-Stra_e 80 Fax. +49 231 972 1177 44227 Dortmund, Germany Andreas.Wittkemper at de.uu.net URL: http://www.uunet.de From joao at ripe.net Tue Mar 2 17:35:26 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 02 Mar 1999 17:35:26 +0100 Subject: Adding nic handles to contact objects without one In-Reply-To: Your message of Fri, 02 Mar 2001 14:08:06 +0100. <200103021308.OAA01910@eunet.ch> References: <200103021308.OAA01910@eunet.ch> Message-ID: <199903021635.RAA10071@x41.ripe.net> Hello, "Bernard Steiner" writes: * * This is a non-advantage because * Actually it is from a database point of view because you increase coherency between the objects and their definition. It also facilitates further work on the DB to eliminate ambiguity. * > RIPE NCC can do it if users wish to. Of course this can only be done for * > references by name corresponding to names that are unique in the database, * * > otherwise we wouldn't know who to assign the object to and we shouldn't. * * the existing ambiguity will *not* disappear. * Yes. That's what I said in my previous mail. Ambiguity will not disappear just by doing this. The users with that kind of objects would have to fix them. The RIPE NCC will aid the users through the database consistency project. This is a first step that doesn't solve all the problems but makes it easier for the future and adds a bit more coherency to the Database. So, I think we agree and I hope you can support the addition of the NIC handles to the objects that don't have one yet. * > * Then you have the problem where these people created a new person * > * object for themselves when nic-hdls became mandatory and left their * > * old person object for dead. How will you overcome these old person * > * objects ? * * Let me also point out that there appear to exist (inetnum) objects that * reference non-existing person objects. If a new person object is created * such that the name happens to match, that person will then inherit the * reference. This can't happen anymore. Now the DB code will not allow a deletion of a person/role object that is still being referenced by other objects. The ones that are already there will have to be fixed, again by the user with our help if it is requested. The consistency project will soon start publishing reports on the occurrence of various types of inconsistencies in the database together with instructions on how to fix them. * This may or may not be intentional (e.g. replacing a person objec * t * with a role object where the new role object has the same handle as the old * person object :-) * On the other hand, just because someone who used to have something to do * with an inetnum in (say) Norway and another Person with the same name but * from (say) Switzerland appears in the database, if the .no guy's person reco * rd * got deleted, then the .ch guy has nothing to do with the .no inetnums. * Even as of now, I cannot delete old person objects in cases where names are * referenced and objects with the same name are still in the database :-( * * What I am getting at is that if you add handles to all person objects and * then update the references from person names to handles, the effect is not * necessarily correct. You cannot make a non-consistent database consistent by * automatic measures. * Again I agree. That's what I stated in the previous mail. No amount of code can subsitute a reasonable person so the real cleanup will need some user intervention. * Just my ECU 0.02 Most welcome [although the ECU is now gone :-) ] Regards, Joao Damas RIPE NCC * Greetings * Bernard From iris-nic at rediris.es Wed Mar 3 12:16:22 1999 From: iris-nic at rediris.es (IRIS-NIC) Date: Wed, 3 Mar 1999 12:16:22 +0100 Subject: lowering maximum assignment window In-Reply-To: Paula Caslav "lowering maximum assignment window" (Feb 23, 6:33pm) References: <199902231613.RAA05824@x30.ripe.net> Message-ID: <990303121623.ZM1592@chico.rediris.es> 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 at rediris.es | +---------------------------------------------------------------+ From joao at ripe.net Thu Mar 4 10:20:17 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 04 Mar 1999 10:20:17 +0100 Subject: Modifications to the inet6num in the RIPE Database Message-ID: <199903040920.KAA14186@x41.ripe.net> 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 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 Date: Thu, 04 Mar 1999 10:20:17 +0100 To: lir-wg at ripe.net, db-wg at 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 Message-ID: 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 NLA is only allowed if the prefix length is 16 References: Message-ID: <199903150456.FAA16062@office.ripe.net> Hi Simon, thanks for your comments. You are absolutely right. Actually I would even add to your comments by saying that inet6num objects should be rejected if the prefix is in the reserved field except if the TLA is the one reserved for sub-TLAs (0x0001). In that case the status field should have the sub-TLA value if the prefix is 16 writes: * 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 NLA is only allowed if the prefix length is 16 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 From david at Qwest.net Mon Mar 15 18:50:27 1999 From: david at Qwest.net (David Kessens) Date: Mon, 15 Mar 1999 10:50:27 -0700 Subject: Modifications to the inet6num in the RIPE Database In-Reply-To: <199903121121.MAA05139@x41.ripe.net>; from Joao Luis Silva Damas on Fri, Mar 12, 1999 at 12:21:52PM +0100 References: <199903121121.MAA05139@x41.ripe.net> Message-ID: <19990315105027.B1048@qwest.net> Joao, On Fri, Mar 12, 1999 at 12:21:52PM +0100, Joao Luis Silva Damas wrote: > > A week has passed and no comments against the proposed modifications to the > IPv6 object have been put forward. I am a bit late too, and do have a few comments, though not very significant. > ------- Begin Original Message > From: Joao Luis Silva Damas > Date: Thu, 04 Mar 1999 10:20:17 +0100 > To: lir-wg at ripe.net, db-wg at 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 NLA is only allowed if the prefix length is 16 SLA is only allowed if the prefix length is 48 Joao writes: > Actually I would even add to your comments by saying that inet6num > objects > +should be rejected if the prefix is in the reserved field except if > the TLA is > +the one reserved for sub-TLAs (0x0001). > In that case the status field should have the sub-TLA value if the > prefix is +16 - - addition of "mnt-lower" capabilities, as in the IPv4 object. In the only kind of production 'inet6num:' registry in the world, the 6bone, this is already implemented and used for over a year time. So I don't have trouble with adding something that already exists ;-). There is something missing in your definition though, when adding 'mnt-lower:' attributes, you always need to define the hierarchy order that you want to use. Is it indeed the same order as in the 'inetnum:' object ?!? I would rather like to choose not to allow anybody to put in top level objects as is the case with 'inetnum:' objects. David K. --- From woeber at cc.univie.ac.at Tue Mar 16 14:41:50 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 16 Mar 1999 14:41:50 MET Subject: Modifications to the inet6num in the RIPE Database Message-ID: <009D5343.96C27D7C.15@cc.univie.ac.at> Hi David, Joao, et.al. My question is going to prove complete ignorance when it comes to IPv6 address formats. So please bear with me :-) => 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 NLA is only allowed if the prefix length is 16 SLA is only allowed if the prefix length is 48 References: <009D5343.96C27D7C.15@cc.univie.ac.at> Message-ID: <199903161401.PAA26470@office.ripe.net> Hi Wilfried, I am not yet too comfortable with writing IPv6 addresses myself. There is a standard which also has a couple of notes on how to avoid confusion that can arise from the :: thingy meaning all zeros up to the next part. However, I always have trouble with this and have to look it up so I will not try to explain it here (I am currently not at the office, so no book). We have adapted the syntax checks to take into account the different way of writing IPv6 addresses since the inet6num was introduced. May be Engin can elaborate on the cases, particularly when there can be ambiguity. None of the introduced changes constrain the standard but rather adapt to it. Regards, Joao "Wilfried Woeber, UniVie/ACOnet" writes: * Hi David, Joao, et.al. * * * * My question is going to prove complete ignorance when it * comes to IPv6 address formats. So please bear with me :-) * * * * => 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 NLA is only allowed if the prefix length is 16 SLA is only allowed if the prefix length is 48 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 . 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 From woeber at cc.univie.ac.at Tue Mar 16 18:21:30 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 16 Mar 1999 18:21:30 MET Subject: Modifications to the inet6num in the RIPE Database Message-ID: <009D5362.46E0DF3C.25@cc.univie.ac.at> 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 at 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 -------------------------------------------------------------------------- From Guy.Davies at uk.uu.net Tue Mar 16 15:25:54 1999 From: Guy.Davies at uk.uu.net (Guy Davies) Date: Tue, 16 Mar 1999 14:25:54 +0000 Subject: Modifications to the inet6num in the RIPE Database References: <009D5343.96C27D7C.15@cc.univie.ac.at> Message-ID: <36EE69F2.9DC83D3D@uk.uu.net> Hi Wilfried, The syntax of IPv6 addresses confused the hell out of me for ages. It works like this. The address is written as 8 blocks of two bytes represented as 4 hex digits (with me so far?) Each block is separated by a single colon. Now for the special cases... Any leading zeroes in a single block of 4 hex digits can be omitted (hence, :00fe: would be reduced to just :fe:. Taken to the extreme case in a single block of four digits, if all four hex digits are zero, then it reduces to simply ::. Take that one step further, if some sequential blocks of 4 hex digits are all zeroes, you can reduce _all_ those blocks to '::' so :0000:0000: also reduces to :: 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 3ffe:1100:0:c04::1/64 3ffe:1100:0:c1c:60:3e59:4d90:8/64 Hope this helps. Regards, Guy "Wilfried Woeber, UniVie/ACOnet" wrote: > > Hi David, Joao, et.al. > > > > My question is going to prove complete ignorance when it > comes to IPv6 address formats. So please bear with me :-) > > > > => 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 => NLA is only allowed if the prefix length is 16 => SLA is only allowed if the prefix length is 48 = > =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 at 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 > -------------------------------------------------------------------------- -- Guy Davies UUNET, An MCI WorldCom Company European Network Specialist 332 Science Park, Cambridge, CB4 4BZ, UK e: Guy.Davies at uk.uu.net t: +44 (1223) 250457 f: +44 (1223) 250412 PGP Key fingerprint = 8C 16 26 7A 86 90 E7 FB 23 8F E2 85 F1 81 F7 F8 From engin at ripe.net Tue Mar 16 16:13:26 1999 From: engin at ripe.net (Engin Gunduz) Date: Tue, 16 Mar 1999 16:13:26 +0100 Subject: Modifications to the inet6num in the RIPE Database References: <009D5343.96C27D7C.15@cc.univie.ac.at> <199903161401.PAA26470@office.ripe.net> Message-ID: <36EE7516.500F9F30@ripe.net> Hi, 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. But I don't know what 6bone registry does. The semantic checks do not have an influence on the formatting, nor the proposals about it. They can be implemented without touching the formatting. Best regards, Engin Gunduz RIPE NCC Joao Luis Silva Damas wrote: > > Hi Wilfried, > I am not yet too comfortable with writing IPv6 addresses myself. > There is a standard which also has a couple of notes on how to avoid confusion that can arise from the :: thingy meaning all zeros up to the next part. > However, I always have trouble with this and have to look it up so I will not try to explain it here (I am currently not at the office, so no book). We have adapted the syntax checks to take into account the different way of writing IPv6 addresses since the inet6num was introduced. > May be Engin can elaborate on the cases, particularly when there can be ambiguity. > None of the introduced changes constrain the standard but rather adapt to it. > > Regards, > Joao > > "Wilfried Woeber, UniVie/ACOnet" writes: > * Hi David, Joao, et.al. > * > * > * > * My question is going to prove complete ignorance when it > * comes to IPv6 address formats. So please bear with me :-) > * > * > * > * => 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 * => NLA is only allowed if the prefix length is 16 * => SLA is only allowed if the prefix length is 48 * = > * =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 at 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 > * -------------------------------------------------------------------------- > * From phk at critter.freebsd.dk Tue Mar 16 18:48:15 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 16 Mar 1999 18:48:15 +0100 Subject: Modifications to the inet6num in the RIPE Database In-Reply-To: Your message of "Tue, 16 Mar 1999 18:21:30 +0700." <009D5362.46E0DF3C.25@cc.univie.ac.at> Message-ID: <29817.921606495@critter.freebsd.dk> In message <009D5362.46E0DF3C.25 at cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO net" writes: > 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? There is certainly something to be said for making it easy for programs to parse the registry. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From keith at stamford.linx.org Wed Mar 17 10:10:18 1999 From: keith at stamford.linx.org (Keith Mitchell) Date: Wed, 17 Mar 1999 09:10:18 +0000 Subject: Report on NCC progress toward ICANN Address Supporting Organisation (IMPORTANT) Message-ID: <990317091019.ZM10686@stamford.linx.org> 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 From guyd at uk.uu.net Tue Mar 16 21:24:38 1999 From: guyd at uk.uu.net (Guy Davies) Date: Tue, 16 Mar 1999 20:24:38 +0000 (BST) Subject: Modifications to the inet6num in the RIPE Database In-Reply-To: <009D5362.46E0DF3C.25@cc.univie.ac.at> Message-ID: > 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? I have to admit that in recording address allocations in UUNET UK's networks, I write the addresses out in full. I tabular format, it makes for much easier identification of errors and anomalies. In the RPSL format, it's a little more difficult to point to benefits for humans but, as PHK pointed out, it's easier for machines to parse. However, given that at least a few dozen hardware and software vendors have come up with a reliable way to parse the abbreviated form, it can't be that difficult. Regards, Guy From david at Qwest.net Tue Mar 16 21:25:15 1999 From: david at Qwest.net (David Kessens) Date: Tue, 16 Mar 1999 13:25:15 -0700 Subject: Modifications to the inet6num in the RIPE Database In-Reply-To: <29817.921606495@critter.freebsd.dk>; from Poul-Henning Kamp on Tue, Mar 16, 1999 at 06:48:15PM +0100 References: <009D5362.46E0DF3C.25@cc.univie.ac.at> <29817.921606495@critter.freebsd.dk> Message-ID: <19990316132515.A14717@qwest.net> On Tue, Mar 16, 1999 at 06:48:15PM +0100, Poul-Henning Kamp wrote: > In message <009D5362.46E0DF3C.25 at cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO > net" writes: > > > 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? > > There is certainly something to be said for making it easy for programs > to parse the registry. The current registry abbreviates. While this means a little more work for machines, people seem to have more trouble parsing long lines and are more difficult to fix in this regard than a simple parser in a program. I don't think that adding zeroes makes it easier to read and editing an existing object doesn't get very easy either: inet6num: 3FFE:1100:0:C00::/56 becomes: inet6num: 3FFE:1100:0000:0C00:0000:0000:0000:0000/56 David K. --- From engin at ripe.net Wed Mar 17 10:40:31 1999 From: engin at ripe.net (Engin Gunduz) Date: Wed, 17 Mar 1999 10:40:31 +0100 Subject: Modifications to the inet6num in the RIPE Database References: <29817.921606495@critter.freebsd.dk> Message-ID: <36EF788F.42877E5C@ripe.net> Hi, Personally, I would like to see 2030:0:5::/48 instead of 2030:0:5:0:0:0:0:0/48 as the result of the query in the whois database, since shorthand notation is, IMHO, more "readable" by human eye. However, maybe we can introduce yet another option to the whois server and client to show the query result on inet6num objects without shorthand notation? Well, restricting the usage of shorthand notation could ease the implementation of the whois server. But, IMHO, in the user side, it is better to allow it. Best regards, Engin Gunduz RIPE NCC Poul-Henning Kamp wrote: > > In message <009D5362.46E0DF3C.25 at cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO > net" writes: > > > 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? > > There is certainly something to be said for making it easy for programs > to parse the registry. > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk at FreeBSD.ORG "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! From phk at critter.freebsd.dk Wed Mar 17 10:47:38 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 17 Mar 1999 10:47:38 +0100 Subject: Modifications to the inet6num in the RIPE Database In-Reply-To: Your message of "Wed, 17 Mar 1999 10:40:31 +0100." <36EF788F.42877E5C@ripe.net> Message-ID: <40015.921664058@critter.freebsd.dk> Uhm, I think people got my comment wrong: I don't particular care if we use :: shorthand or not, I just want it to be sufficient systematic that programs can parse it reliably. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!