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

> Le 23 févr. 2017 à 21:42, Mark Smith <markzzzsmith@gmail.com> a écrit :
> 
> On 24 February 2017 at 06:00, Nick Hilliard <nick@foobar.org> 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.

And during those 11 years. Nobody implemented this rule specific to ::/3.

> 
> It can't be changed without invalidating all of the other RFCs that
> have utilised 64 bit identifiers.

Those "other RFCs" have nothing to do with being part of ::/3 or not.
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".

- 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops