RE: [lir-wg] IPv6 assignments to RIPE itself
- Date: Tue, 14 Jan 2003 13:04:42 +0100
- Organization: Unfix
Wilfried Woeber, UniVie/ACOnet wrote:
> >| > whois 2001:610:240:0:193::193
> >| inet6num: 2001:0610:0240::/42
> >| netname: RIPE-NCC-IPv6
> >| descr: RIPE NCC
> >| status: ALLOCATED-BY-LIR
>
> I think there are 2 questions here that should be discussed,
> under the premises that SURFnet has set aside a /42 for
> the NCC from SURFnet's sTLA:
>
> a) what is the "correct" status: field for a block bigger than /48
> I think in most cases (like /47, /46 for a big site) it should
> simply be ASSIGNED, even if it is as big as a /42.
>
> b) in a more general sense, to what level are we (LIR) and our
> sites/customers (/64, /48 or bigger) expected to document
internal
> address management?
>
> For the moment, the only thing that looks funny _for me_ is
> the status:
> "ALLOCATED-BY-LIR". I read that as an indication that the
> NCC would make
> _assignments_ from that block, e.g. /64s and /48s - which I think
> _should_ be registered by the NCC or by SURFnet.
IMHO the assignments for the /48's should be documented in
a local (r)whois database. With at least a referal from the central
whois. Anything bigger than one /48 should be documented in the
central (whois.ripe.net) database. This should 'lighten' the load
on the central whois as there are 2^(128-32-48=48) (a lot) of
/48's to be registered in to the database.
As for the reason why I think those /48's should be registered:
When a spammer/abuser/* is using 1 IP out of the /48 it would be
better to contact the onsite administrator then the upstream ISP.
And especially as a /48 could hold a major corporation or a big
university this is something that IMHO should be very useful.
Ofcourse one shouldn't be forced to use the defacto whois
software but could integrate it into their backend systems,
thus actually allowing a view into their network. Ofcourse
this isn't always what is wanted due to various political
reasons etc., which is why I said that it _should_ be documented ;)
Example: SixXS (www.sixxs.net) has the IPng tunnelbroker which delegates
/60's from 3ffe:8114:2000::/48. We used to register every /60 in the
6bone
database. But updating this every time an allocation is made and with
the
number of allocations isn't quite handy especially as the parameters
enclosed
in the inet6num could change a lot (eg endpoint changes).
Thus we created our very own whois server (whois.sixxs.net) from
which the data can be accessed, directly and up-to-date. eg:
8<----------------------------------------------
$ whois -h whois.sixxs.net 3ffe:8114:2000:240::/60
% This is the SixXS Whois server.
% SixXS - http://www.sixxs.net.
% The objects are in RPSL format.
% Objects not beginning with SIXXS-
% or ending in -SIXXS are
% cached responses from remote sources.
inet6num: 3ffe:8114:2000:240::/60
netname: SIXXS-NLAMS02-NET-JRM1-6BONE-34
descr: This route goes to an endpoint of JRM1-6BONE.
descr: This route is routed to 3ffe:8114:1000::27 /
195.64.92.136.
descr: IPng import
country: NL
admin-c: PBVP1-6BONE
admin-c: JRM1-6BONE
tech-c: PBVP1-6BONE
tech-c: JRM1-6BONE
rev-srv: purgatory.unfix.org.
remarks: Prefixtype: Route
remarks: This object is generated from the SixXS database
remarks: Abuse reports should go to abuse@localhost
remarks: Information can be found at http://www.sixxs.net/
changed: info@localhost 20020928
changed: info@localhost 20030105
mnt-by: SIXXS-MNT
source: SIXXS
<SNIP other objects referred here>
---------------------------------------------->8
This allows troubleshooters to see where this prefix leads but
it doesn't burden the main (in this case 6bone) database with
new creations/updates/deletions.
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.
Ofcourse all this is just my idea on this small sidesubject.
Greets,
Jeroen
