Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Le 24 févr. 2017 à 04:27, Lorenzo Colitti <lorenzo@xxxxxxxxxx> a écrit :

On Fri, Feb 24, 2017 at 7:43 AM, Pierre Pfister <pierre.pfister@xxxxxxxx> 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]