[lir-wg] IPv6 assignments to RIPE itself
Jeroen Massar jeroen at unfix.org
Tue Jan 14 13:04:42 CET 2003
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 at sixxs.net remarks: Information can be found at http://www.sixxs.net/ changed: info at sixxs.net 20020928 changed: info at sixxs.net 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
[ lir-wg Archives ]