Sky blocks Newzbin, important legal and technical questions need answering

[Ian Batten]

On 16 Dec 2011, at 20:36, James Firth wrote:
> 
> Hence the rightmost 64 bits - the "interface identifier" are reserved for
> the MAC address or equivalent, and IPv6 addresses are designed to be
> allocated in blocks of /64.  That's why no end "customer" should ever get
> less than a /64.
> 
> Now I hear you cry, since MAC addresses are in theory unique, there's no
> need to give every customer a /64... But there is, really.  MAC fiddlers,
> etc.
> 
> An obvious privacy nightmare standards have emerged such as RFC 3041; which
> I think, Ian, might describe similar behaviour to that mentioned in your
> earlier post.


Just to clarify, 3041 that you refer to is obsoleted by 4941 which I referred to.  They're very similar. 

The use-case only really applies for mobile devices.  The concern it addresses is the case where a device (say, a laptop) is mobile between networks.   Today, it'll get allocated a fresh IP number by the local DHCP server, which even if it's not NAT-ed at the border anyway won't be in any way correlated between networks.  Therefore, of itself, the allocated address does not provide a means of linking two network addresses as pointing to the same device.

That's not true with IPv6 stateless auto-configuration.  The algorithm there is to form the bottom 64 bits by taking the MAC address, splitting it it two, padding the two halves apart with FF:FE and inverting bit 7.    You then probe for someone else using the same address and do some magic if you hit a clash.  That makes the bottom 64 bits (usually) constant for a given device, and hence trackable from prefix to prefix.  So 4941 allows you to instead form an address at random, probe to see if it's in use, and assuming it's free use that.

But for fixed devices, that's pretty pointless.   It's not a surprise that, say, a.root-servers.net. is at 2001:503:ba3e::2:30, nor is there any reason why the operators of a.root-servers.net would mind me knowing that over the long term.  And there's no reason why 2001:503:ba3e::2:31 should be off-limits: clearly, ::2:31 hasn't been formed by splitting a mac address, inserting ff:fe and inverting bit seven, nor has it (one would guess) been formed with 64 random bits.  It's been formed by hand, just like 2001:7fd::1 (another of the roots).   And that argument extends to any fixed address of a fixed machine, especially one that needs its PTR records to work correctly.

So if I'm a small co-lo running IPv6, RFC 6177 says my registry should be willing to give me more than a /64 but (potentially) less than a /48.  If I've got a /56, say, I'm going to be nervous about giving my customers /64s, because I've only got 256 of them.  In any event, the last thing a co-lo customer is going to want to happen is the IPv6 address of their machine change because it's had a motherboard swap, or because it's been moved from VMware host to VMware host, or whatever.  They're going to want a fixed IPv6 address, just like they have a fixed IPv4.  I'm going to be pretty annoyed if the IPv6 address of the authoritative nameserver for my domain changes, because it's in the glue records; it's not enough that the top 64 bits are constant, the bottom 64 need to be constant as well.  Given that's going to apply to most people in co-los, why wouldn't the co-lo operator allocate multiple addresses in the same /64 to different customers?  They're not going to be using stateless autoconfiguration, after all.

ian