On Wed, Feb 22, 2017 at 11:51 PM, David Farmer <farmer(_at_)umn(_dot_)edu>
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.