keeping Aggregatable registry

[davidk@ISI.EDU]

Bob,

Bob Fink writes:
> 
> Your question on format is a good one.  David Kessens might suggest one as
> he has said he can help provide the service using his 6bone registry.

There are a couple of ways to do this:

- The DNS reverse zone might be a good place to put this data
- The 6bone registry can be used

  The 6bone registries already has most (if not all) of the support
  needed. There are two possibilities for doing this:
  
  We use the ipv6-site object which contains the 'prefix:' attribute
  which can be used to document the used prefixes. Currently everybody
  can just choose there own prefixes, but I can build in support that one
  needs approval first of the address space manager (SLA level n-1) to
  *create* such a prefix: attribute. It would be needed that the SLA
  manager at level n would also need an 'ipv6-site:' object.
  
  However, a cleaner solution is separating the notion of objects that
  describe which addresses *may* be used by somebody and keep the site
  objects for describing which address space is actually being routed and
  how. This is in fact how it is currently being done for IPv4 address
  space. IPv4 registries have information who can use what (InterNIC,
  RIPE, APNIC) and routing registries (RA, MCI, RIPE, CANET, ANS) have
  information on what is actually using what, where and how. This
  solution would reflect reality better, but might be viewed too
  complicated.
  
  The current software already has support for both type of objects, the
  'ipv6-site:' objects are the routing registry type of objects and the
  'inet6num:' objects for describing allocations/assignments of address
  space. I haven't made the 'inet6num:' public yet since we never had a
  need for it. Below follows a formal description:
  
  inet6num:    [mandatory]  [single]    IPv6 prefix    
  netname:     [mandatory]  [single]    name of the TLA/SLA
  descr:       [mandatory]  [multiple]  description of TLA/SLA
  country:     [mandatory]  [multiple]  space separated list of ISO 
                                        country codes
  admin-c:     [mandatory]  [multiple]  NIC handle for administrative contact
  tech-c:      [mandatory]  [multiple]  NIC handle for technical contact
  rev-srv:     [optional]   [multiple]  nameserver for reverse domain,
                                        could be used by Bill or others
                                        to build the reverse zone!
  remarks:     [optional]   [multiple]  same as in ipv6-site objects
  notify:      [optional]   [multiple]  E-mail address
                                        gets notification message when 
                                        somebody changes the object
  mnt-by:      [optional]   [multiple]  pointer to maintainer object
                                        which describes who can update
                                        the object, everybody can do updates
                                        if you don't use this, however you
                                        can use the 'notify:' attribute to 
                                        make sure you know about the fact.
  mnt-lower:   [optional]   [multiple]  pointer to maintainer object                                        
                                        which describes who is allowed
                                        to *create* objects for SLAs
                                        part of the 'inet6num:' object
  changed:     [mandatory]  [multiple]  same as in ipv6-site objects
  source:      [mandatory]  [single]    equal to 6BONE
  
  We could start with creating the following objects:
  
  inet6num:    0::/0
  netname:     The Mother of All Address Space
  ...
  mnt-by:      IANA
  mnt-lower:   IANA
  
  inet6num:    3FFE:0::/16
  netname:     TestAddressSpace
  ...
  mnt-by:      BobFink-MNT
  mnt-lower:   BobFink-MNT
  
  inet6num:    3FFE:0::/24
  netname:     INNER-TLA0
  ...
  mnt-by:      INNER-TLA0-MNT
  mnt-lower:   INNER-TLA0-MNT
  
  inet6num:    3FFE:0::/32
  netname:     CustomerINNER-TLA0-SLA0
  ...
  mnt-by:      CustomerINNER-TLA0-SLA0-MNT
  mnt-lower:   CustomerINNER-TLA0-SLA0-MNT
    
  and so on ...
  
> Myself, I'm doing the dumb and simple 'keep a text list' approach, see:
> 
> 	http://www.6bone.net/6bone_pTLA_list.html
>
> My guess is that not everyone will want to use either the 6bone registry
> (in a RIPE-style format) or a simple text list, so maybe having both is a
> good idea.

It always make sense to keep such a short simple and authoritative list
to check who is right in case of conflicts that might but should not
happen.

Please let me know what your view is, as the best thing to do,

David K.
---