Le 24/02/2017 à 07:58, Pierre Pfister a écrit :
Le 24 févr. 2017 à 04:27, Lorenzo Colitti <lorenzo(_at_)google(_dot_)com
<mailto:lorenzo(_at_)google(_dot_)com>> a écrit :
On Fri, Feb 24, 2017 at 7:43 AM, Pierre Pfister
<pierre(_dot_)pfister(_at_)darou(_dot_)fr
<mailto:pierre(_dot_)pfister(_at_)darou(_dot_)fr>> wrote:
> The thing is this is not new text, it has been in RFC4291 for 11
> years. c.f., 2.5.1.
And during those 11 years. Nobody implemented this rule specific
to ::/3.
I can implement it today in some of our code if you like :-).
Good luck getting that upstreamed ! ;-)
But it seems unlikely to make a difference, since the rule only
applies to unicast addresses in ::/3, and no such addresses have been
released to the RIRs. That in turn is unlikely to change until we run
out of 2000::/3, and even then we'll likely move on to allocating
addresses out of 4000::/3 instead of from ::/3.
So what you are saying is that all currently assigned unicast addresses
are out of the ::/3 prefix.
Meaning that, according to proposed standard, I should not be able to
configure on-link prefixes of length different than 64 with currently
assigned unicast addresses.
At least Linux, Windows, Apple, Cisco, and probably all mature IPv6
stacks, would let you configure prefixes of length different than 64.
A question to Windows is the following: what prefixlen does it set when
the end user manually assigns an address on an interface without
specifiying a prefixlen?
Is that 64? If yes then it's wrong.
Alex
- Pierre