inet6num referral (Was: [lir-wg] IPv6 assignments to RIPE itself)
- Date: Wed, 15 Jan 2003 01:40:11 +0100
- Organization: Unfix
Wilfried Woeber, UniVie/ACOnet [
] wrote:
> Hi Jeroen!
>
> >Only problem here is that in the non rwhois databases there is no
> >defacto 'referal' method. At least as far as I know of except for
> >a 'remarks:' field. If somebody can hint me where to find it I would
> >be pleased.
>
> Interesting line of thought!
>
> In fact there _is_ a referral mechanism - for domain lookups, but
not
> for address lookups. Depending on what the result of this discussion
> is, we could investigate the merits of a referral mechanism for
> inet6nums, too.
[Maybe this should go into db-wg?]
The domain name referral mechanism works using the 'refer' tag.
This could be used for inet6nums too, albeit as it isn't defined
for inet6num's the whois db won't accept it. Most clients probably
won't care much. Marco d'Itri's whois client also handles
The refer tag is documented in amongst others
http://www.ripe.net/ripe/docs/databaseref-manual.html
An (minimal) example of inet6num in this style could look like.
8<------------------------
inet6num: fec0:8114:1000::/40
netname: EXAMPLE-DLG-ONE
descr: Example /48 delegation space to endusers.
refer: RIPE whois.example.net 43
country: NL
remarks: More specific information can be found by quering
whois.example.net
mnt-by: MNT-EXAMPLE
changed: jeroen@localhost 20030115
source: EXAMPLE
------------------------>8
Lines 4 and 6 depict the referral, line 6 is simply there to allow
humans to
know of ther referral too, though it could be left out as line 4 is
obvious enough.
Line 6 can ofcourse easily be autogenerated in the server side.
The "refer" should actually be "longer refer" in that only the
subdelegations
of the inet6num are referred and not the inet6num documented itself.
This way
the documentation is always available in RIPE (which should be up 99%)
and
the more detailed versions should go in the referred server.
One thing is that the domain 'refer' attribute does the refer on the
RIPE server.
Thus the object is fetched from the referred server bij whois.ripe.net
which
actually could/will cause some extra load on the whois.ripe.net machine.
Marco pointed out to me that the 6bone database (whois.6bone.net) has a
special
piece of code that when a person/maintainer object etc is not found in
the local
database it outputs a:
% referto: whois -h whois.ripe.net -p 43 -s RIPE -T person,role
NO17-RIPE
Eg as found in
http://www.viagenie.qc.ca/cgi-bin/whois.pl?SURFNET
The whois-client then connects to the specified server and request
the data from there. It would probably be better if these referals
are done client side for the inet6num case too.
Problem with this is that it isn't an attribute and thus there is
no way to control it when filling in your inet6num, unless there comes
a exception etc... in which case a correctly specified refer attribute
would be better.
> Nevertheless I'd strongly suggest to keep the (minimal) required
> documentation of resources in the central database, instead of going
> down the route of rwhois (or the like).
IMHO the </48 should be completely documented in the RIPE db, but
suballocations of that should be documented in a local (referred) whois.
The records to which the referal points could sub-document their
delegation
again in another whois if wanted. eg:
fec0:8114:1000::/40 -> whois.ripe.net, with a "longer refer" to
whois.example.net
fec0:8114:1000::/48 -> whois.example.net (The regional ISP)
fec0:8114:1000::/56 -> whois.example.org (The enduser organisation)
Which makes it quite flexible, but ofcourse people shouldn't refer to
much
otherwise this will become DNS.
Greets,
Jeroen
