[ixpmanager] Trouble adding v6 /64

[Rob Lister]

LONAP had to renumber our peering LAN in 2013 from 193.203.5.0/24 to 
5.57.80.0/22, so I am glad that whoever set it up years ago, did not tie it 
to IPv4 address, or that they used the last octet, as obviously "5.57.80.10" 
and "5.57.81.10" would clash, then we'd have to shove ":1:x" in there or 
something. Both of those IPv4 -> IPv6 translations wouldn't have made sense
later on down the line.

We use the "ASN hex" method, though this too has some wrinkles but seems to 
mostly work well.

I suppose the original intent was that IXP participants could easily 
"self-assign" IPv6 addresses on a given exchange without further 
intervention by the IXP, to just switch it on.

e.g. "My ASN is 8330, hex: 208a. Therefore I can have: 2001:7f8:17::208a:*
and assign an IPv6 address to all my interfaces."

In the early days members did just that, and we didn't always get to know 
about it, but had to rely on trying to detect it by looking at IPv6 
neighbour tables etc.

I suspect there may be a few still not in our database, as there wasn't 
a slot for "IPv6 address" in our early databases/"collection of text files 
annoyingly delimited with ':' " :(

I guess the expected huge stampede of support tickets for IPv6 addresses was 
more of a slow trickle taking 15 years. :)

It may also go some way to making keying errors less likely to cause 
duplicate IP problems.

Given the lack of reverse DNS on lots of IPv6 router interfaces, it's 
probably no bad thing that it can be reversed to determine an ASN.

It's also possible to automatically determine what the IPv6 address should 
be from the AS number. Possibly handy, maybe not so much these days it's in 
a database.

In reality, IXP intervention is usually required for things like configuring 
route server sessions and collector router, so we need to know an address, 
which we just assume to start ":1", then ":2" for the next port, and so on, 
though there's nothing to stop a member using ":<ashex>:beef" if they 
want.

Downsides of asn hex encoding? 

I suppose are 32-bit ASNs looking a bit odd: Ours end up looking like:

ASN: 123456
HEX: 1e240
IPv6 1: 2001:7f8:17::1:e240:1

Also if a member changes ASN, they have to reconfigure their IPv6 address, 
but the sessions need to be reconfigured anyway, so it's not really extra 
hassle.


Rob



On Mon, Jan 15, 2018 at 02:31:10PM +0000, Barry O'Donovan wrote:
> Martin J. Levy wrote:
> >     https://tools.ietf.org/html/rfc5963
> >     IPv6 Deployment in Internet Exchange Points (IXPs)
> 
> Really not sure why sections 3 (1) and (2) are there at all. Why are
> people so intent on 'encoding' data in a v6 address :-/


-- 
Rob Lister
rob at lonap.net
+44 20 3137 8330