Modifications to the inet6num in the RIPE Database
David Kessens david at Qwest.net
Mon Mar 15 18:50:27 CET 1999
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 <joao at ripe.net> > 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<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 ?!? > 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<l<27. I don't think this should be part of the syntax checks or the object description. This is more a local configuration issue. For now, certain limits are set. I think that those limits belong either in the configuration file or the objects can be shielded from use by using allocation 'inet6num:' objects in combination with 'mnt-lower:' (which is the least amount of work). These limits might not always stay the same and are not part of the basic specification. > - - 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. ---
[ lir-wg Archives ]