Cleansing 6bone (Was: [6bone] pTLA request by CTN1 - review closes 16 December 2003)

[Jeroen Massar]

-----BEGIN PGP SIGNED MESSAGE-----

[Real problems, private ASN's etc, at the about 50% of the mail]

Nicolas DEFFAYET wrote:

> > ND> Open your eyes, not all pTLA request respect fully RFC2772.
> > ND> There is a problem with this request, because some people want troll
> > ND> about it.
> > 
> > If pTLA requests don't conform to RFC2772 they should not 
> > be allocated a pTLA.
> 
> Please read the archive before !
> When you have pTLA allocated with unassigned ASN, only one contact
> person,... Are this pTLA conform to RFC2772 ? Why they have been
> allocated ?

I totally agree with you Nico, 6bone should be reclaiming space
that is not actively maintained any more.

We will start by pointing out one of the newer prefixes, yours:

$ whois -h whois.6bone.net 3FFE:4013::/32

netname:      FR-NDSOFTWARE-20021110
descr:        NDSoftware IP Network
country:      FR
admin-c:      NN175-RIPE
tech-c:       NN175-RIPE
rev-srv:      ns1.ndsoftware.net
rev-srv:      ns2.ndsoftware.net
rev-srv:      ns3.ndsoftware.net
notify:       noc@ndsoftware.net
mnt-by:       MNT-NDSOFTWARE
changed:      nicolas.deffayet@ndsoftware.net 20021110
changed:      nicolas.deffayet@ndsoftware.net 20031206
source:       6BONE

Let me see, 1 contact person, not even a 6bone handle,
but that is allowed and it's probably cooler to register
6bone objects in the wrong registry.

Could your staff (or you yourself) fix this as per
RFC2772, which you just commented about? Aka you might
want to add 2 more contacts, who are not you.

Don't complain about other TLA's when you cannot even
fix maintain own or that of your company.

Ofcourse you are completely correct, this should be
fixed as soon as possible.

Fortunatly for the owners of these prefixes there hasn't
been a real witch hunt for these problems and I suspect
there never will be. 6bone is testspace and problems are
allowed to happen. Ofcourse they should be fixed asap and
the only way of doing that is contacting the relevant.

I would like to point people out to <shameless selfplug>:
http://www.sixxs.net/tools/grh/

Current problems, which really should not be there:

2001:d10::/32          AS64600 is reserved
2001:d30::/32          Multiple Origin ASN's (2500,4717) 
2002:c2b1:d06e::/48    More specific 6to4 prefix (194.177.208.110/32) from AS5408 
2002:c8a2::/33         More specific 6to4 prefix (200.162.0.0/17) from AS15180 
2002:c8c6:4000::/34    More specific 6to4 prefix (200.198.64.0/18) from AS15180 
2002:c8ca:7000::/36    More specific 6to4 prefix (200.202.112.0/20) from AS15180 
3ffe:1300::/24         Mismatching origin ASN, should be 762 (now: 10318) 
3ffe:2200::/24         Ghost Route (18/12)
3ffe:3500::/24         AS64600 and AS64702 are reserved
3ffe:8030::/28         Ghost Route (20/12) 

6bone does affect RIPE space as you can see from the above list.

btw AS10318, if *anybody* has a contact there, please ask them to
respond to the list or privatly. Any peers still peering with them
please consider to depeer as they have been unreachable for over
a year now.

<SNIP>

> A lot of pTLA allocated have never make end-user assignement...

There is no requirement for making end-user assignments.
6bone is a *test* bed, not a production environment.
Though one of the methods for testing could be to test making
end-user assignments and giving them access to the 6bone so
that they can test how IPv6 works, thus making you test out
whether your routing infrastructure works. That is the main
goal for the 6bone: testing. Ofcourse it is needless to say
that prefixes don't even have to be announced for this reason.

Checking: http://www.sixxs.net/tools/grh/tla/6bone/
8<---------------------------------------------------------
The database currently holds 144 IPv6 TLA's.
Of which 16 (11.11%) are returned to the pool, 16 (11.11%)
IPv6 TLA's didn't have a routing entry.
Thus 112 (77.78%) networks are currently announced.
- --------------------------------------------------------->8

Unfortunatly we don't have data from way back when most of
these where allocated, but this does show that some are
not reachable.

> Why a pTLA request for make end-user assignement must be 
> denied because the requester can use the upstream address space ?

Indeed, quite strange that you need another pTLA then:

$ whois -M 3ffe:4013::/32  |grep inet6num

inet6num:     3FFE:4013:2207::/48
inet6num:     3FFE:4013:2105::/48
inet6num:     3FFE:4013:2300::/40
inet6num:     3FFE:4013:1000::/36
inet6num:     3FFE:4013:2104::/48

3 /48's a /40 for 'personal' use and a /36 for some other 'project'.
You could btw with ease delegate some more space to CTN1, they
have the same upstream and then they can test their commercial
million euro webhosting. If you try to make your point then
you really should have gotten your own act together first.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/

iQA/AwUBP+Db7CmqKFIzPnwjEQI9EgCgva+RyN0Ha1KmEmq9APzMq8ei8aYAnjBQ
sU6ObEhLDJlL3UDvDQxlS5Fx
=/QjC
-----END PGP SIGNATURE-----