On Wed, Feb 22, 2017 at 11:51 PM, David Farmer <farmer@xxxxxxx> wrote:
There is no universal (Internet wide) requirement, to make the Internet work, that all interfaces have /64 as their as their prefix.
Where "make the Internet work" means what, exactly? I assume you don't mean "experiences no loss in functionality" - all it takes is one implementation that breaks when configured with a non-/64 prefix to make the statement false.
That might seem like a specious distinction, but if you think about it more broadly, then I think you'll agree that "work" is not black and white, and also covers degraded functionality. In which case it's absolutely true that moving away from /64 everywhere is going to cause some amount of loss of functionality. The question is how much, and whether that's acceptable.
Their is a local requirement that all interfaces on the same link have the same prefix.
Actually, there isn't. The requirement for working communication is that all hosts are configured with a prefix length that covers all hosts on the link (or, more narrowly, all hosts they want to talk to). It IS a requirement in IPv4 because of the broadcast address, but it's not in IPv6. Again, this might seem like nitpicking, but if you think about it some more, I think you might realize that some of what is being written on this thread is based on unstated assumptions that are not necessarily correct, and in many cases based only on IPv4 practices where they were actually necessary for reasons that are no longer applicable in IPv6.
Is the operational effort to utilize other prefix lengths (/126 through /65) justified, including the issues discussed in RFC7421? Most of the time, probably NO, but some times, YES it is. Here is the crux of this issue, some of you think it is never justified.
I think this is where the disconnect lies. As a host OS developer and app developer, my work is not impacted by what you, Job, or Chris, individually do in your networks. My work is impacted by the minimum common denominator, because that is what constrains the code I need to write.
If we don't have a fixed subnet size, that minimum common denominator quickly ends up being /128-to-the-host. I don't want to end up at /128 because it makes my code more complex and brittle and my users' experience much more battery intensive and less reliable. (Again, see RFC 7934.)
If we do have a fixed subnet size, and the only loss is that that backbone operators cannot use RFC 4291bis to complain if host vendors refuse to implement configuring /117 prefixes on their links, then I truly believe that that is a better outcome for the Internet as a whole. As you point out, /117 already "works", anyway - at least in your definition of "works".
When I was still involved in writing its addressing plans, the backbone I am familiar with ran on a mix of /127, link-local point to point, and /64-to-the-rack with some operational measures to defend against ND cache exhaustion attacks. I never found the lack of /117 prefix lengths to be a limitation.