<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="font-family: monospace; ">Hello,</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">Running rpsltool[1] against the RIPE database, it broke on a rather odd object in the RIPE database:</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><blockquote type="cite" style="font-family: monospace; ">inet6num: 2a02:4c8::1/64<br></blockquote><blockquote type="cite" style="font-family: monospace; ">netname: ITDNET<br></blockquote><blockquote type="cite" style="font-family: monospace; ">descr: ITD Network, AD<br></blockquote><blockquote type="cite" style="font-family: monospace; ">country: BG<br></blockquote><blockquote type="cite" style="font-family: monospace; ">........<br></blockquote><blockquote type="cite" style="font-family: monospace; ">route6: 2a02:4c8::1/64<br></blockquote><blockquote type="cite" style="font-family: monospace; ">descr: ITD Network AD<br></blockquote><blockquote type="cite" style="font-family: monospace; ">origin: AS9070<br></blockquote><blockquote type="cite" style="font-family: monospace; ">.........<br></blockquote><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">That doesn't seem right - the correct prefix would be 2a02:4c8::/64.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">I've asked the RIPE NCC about this, and they explained that internally, the database silently discards the host bits. So for the database, this is 2a02:4c8::/64. This is also visible in whois queries: searching for 2a02:4c8::1/64 yields no results, you have to search for 2a02:4c8::/64.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">Upon asking, the RIPE NCC responded that this is technically valid according to the relevant RFCs. But, they acknowledged that this behaviour can be confusing, and say they intend to disallow it at a later time.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">Down to my specific question: has anyone made the appropriate modifications to rpsltool to handle these kind of objects, and also silently discard the host bits in the address? I imagine we can't be the first people running into this.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br>[1] <a href="http://www.linux.it/~md/software/">http://www.linux.it/~md/software/</a></span><div><span class="Apple-style-span" style="font-family: monospace; "><br></span><div><span class="Apple-style-span" style="font-family: monospace; ">cheers,</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">Erik Romijn</span></div></div></body></html>