Le 24 févr. 2017 à 04:27, Lorenzo Colitti <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.
- Pierre