Hi Job,
On 21/02/2017 13:19, Job Snijders wrote:
On Thu, Feb 16, 2017 at 09:40:01AM +0100, otroan(_at_)employees(_dot_)org
wrote:
There are many reasons for the 64 bit boundary.
- Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66
Irrelevant.
Not really. They are both running code. You may not want them in
*your* network but that isn't the point. Some people want them.
And there is a lot of other running code too, not just SLAAC which is
mandatory to implement in every IPv6 host. So this actually trumps all
the other arguments: it's 64 bits because it's 64 bits.
...
Also, I think we here touching upon the very heart of the issue: some
would like to force every link on this planet to have a routable /64
(for perhaps ideological reasons),
No. For running code and interoperability reasons. We could have settled
on 48 bits, but we didn't. But, because of interoperability, we had to
pick something.
and some don't (for perhaps
operational reasons).
In practice, there isn't much choice except for point to point links.
All the same, we definitely needed RFC7608 (=BCP198).
I'm from the school of thought where unenforceable rules have no place
in society. There already is precedent to abandon a classful addressing
paradigm in favor of classless inter-domain routing. This implies that a
the fixed 64 bit boundary is unattainable, as such, getting classless
IPv6 is merely a matter of expending sufficient energy.
No. IPv6 routing is classless and always has been. RFC7608 simply re-states
it. But automatic address assignment, which is an equally important property
of IPv6, needs a default setting for portable code, and it is /64. That isn't
a matter of opinion. It's a (possibly inconvenient) truth.
...
If this is the case, why proceed 4291bis while its content is contested?
What we're discussing is the exact text to describe the inconvenient
truth. I'm not aware of any generally available running code that will
be changed in even one instruction by the final text - that is indeed
a requirement for advancement to Internet Standard.
Brian