On 24 Feb. 2017 09:43, "Pierre Pfister" <pierre.pfister@xxxxxxxx> wrote:
And during those 11 years. Nobody implemented this rule specific to ::/3.
> Le 23 févr. 2017 à 21:42, Mark Smith <markzzzsmith@xxxxxxxxx> a écrit :
>
> On 24 February 2017 at 06:00, Nick Hilliard <nick@xxxxxxxxxx> wrote:
>> as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit
>> the implementation of any interface netmask != /64:
>>
>>> However, the Interface ID of
>>> all unicast addresses, except those that start with the binary value
>>> 000, is required to be 64 bits long.
>>
>
> The thing is this is not new text, it has been in RFC4291 for 11
> years. c.f., 2.5.1.
Those "other RFCs" have nothing to do with being part of ::/3 or not.
>
> It can't be changed without invalidating all of the other RFCs that
> have utilised 64 bit identifiers.
They require an interface identifier of 64 bits long.
The fact that a protocol does not work in some conditions does not invalidate the protocol.
e.g. the fact that SLAAC over Ethernet doesn't work when IID is not 64 doesn't mean
the IID could not be 64 bits long. It just means that under those conditions, SLAAC would not work.
And those conditions are perfectly well defined in those "other RFCs".
A non-SLAAC example.
"Unicast-Prefix-based IPv6 Multicast Addresses"
That example and many others are described in
"Analysis of the 64-bit Boundary in IPv6 Addressing"
https://tools.ietf.org/rfc/rfc7421Surely everybody here saying change it or abandon it have read that RFC so they fully understand the consequences of what they're suggesting, right? I'm pretty sure it has been referenced in at least one version of the text I've seen in the discussion.
- Pierre
>
>> This has substantial operational consequences in the ipv6 world because
>> if it's implemented as stated, it will cause production ipv6 networks to
>> break.
>
> Going by the millions of IPv6 deployments now, it has been implemented
> as stated.
>
>>
>> The ipv6 operational community may have opinions on the wisdom of
>> mandating new behaviour which would cause their networks to fall over,
>
> There is and should be no new behaviour in RFC4291bis, it is a tidy up
> to advance it along the standard track.
>
>
>> so it would probably be a good idea to notify v6ops@ietf about the
>> existence of this draft so that the folks over there get a look-in
>> before a consensus call is made. As far as I can tell, this notification
>> never happened.
>>
>> Nick
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/v6ops