Another bogon block: 2001:678::/29 (Was: Bogon Filter - Please check for 77/8 78/8 79/8)

Mon Dec 11 15:55:34 UTC 2006

[After the very short IANAL part, an operational part wrt 2001:678::/29]

Robert E. Seastrom wrote:
> 
> no, he's saying that a lawsuit is a useful method of forcing someone
> who is intentionally or negligently distributing incorrect information
> that other people who do not know any better then believe and use in
> their own networks.

If that is the basis that people sue on, then I really wonder all of a
sudden when somebody will sue their government, news agencies and all
those nice magazines where those paparazzi stalkers are working for.

But to keep this nice and operational:

Just as a side example: 2001:678:1::/48 is a "DNS Anycast Block".
ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest doesn't
list this yet, even though it was allocated 2 months ago. There was
though a 2001:678::/35 block previously (which is still in the above
file but not in whois anymore). GRH thus listed this falsely. Should I
thus be liable for publishing information that is wrong, as GRH was
listing the /48 "Subnet of a big allocation", which it in effect was, as
it was, according to the tool, part of the /35.

grh.sixxs.net> show bgp 2001:678:1::/48
BGP routing table entry for 2001:678:1::/48
Paths: (32 available, best #30, table Default-IP-Routing-Table)

And that is out of about 100 peers that GRH has. As such can I ask the
community, people who are maintaining routers, to check their filters
and start accepting these prefixes? Thank you.

As many people rely on the 'delegated-<RIR>-latest' files for producing
their filters, I have contacted RIPE NCC to resolve that issue, most
likely that will then automatically punch the appropriate holes into the
automated tools which rely on it. GRH though has been updated manually
already. When RIPE NCC has fixed it up, I'll follow up to ISP's that
have not fixed up their filters yet, so that that number comes quite a
bit closer to 100. Thanks to Simon Leinen for reporting it btw as I
hadn't noticed it: am I thus liable for 'spreading false info' ?

Greets,
 Jeroen
 (glad to not be in the US :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20061211/378eaeca/attachment.sig>