Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

[Fernando Gont <[e-mail]>]

On 25/5/20 11:52, Philip Homburg wrote:
> [note, I'm replying here to multiple messages]
> 
>> Why wouldnt the operator in such a case simply configure the RA
>> side as static?
> 
> Yes, but it introduces extra complexity. In particular, the CPE has to
> continue to request a prefix using DHCPv6. Then a naive implementation may
> end up with two entries for the same prefix in a single RA. Finally, the
> implementor may realize that filtering out the prefix from DHCPv6 may
> actually cause the CPE to violate a MUST NOT, so a strict interpretation of
> the CPE may cause the CPE to remove the user supplied prefix.

Again: this document specifies a recommended behavior when the CE Router 
handles the whole thing automatically. You don't even need permission to 
have a manual knob that allows you to do something else.




>> That is indeed a good point. Maybe we should copy the terminology
>> section from RFC7084, which describes the usage of these terms in
>> this document? Namely:
>>
>> ---- cut here ---- X.Y.  Requirements Language
>>      Take careful note: Unlike other IETF documents, the key words
>>      "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
>>      "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>      document are not used as described in RFC 2119 [RFC2119].  This
>>      document uses these keywords not strictly for the purpose of
>>      interoperability, but rather for the purpose of establishing
>>      industry-common baseline functionality.  As such, the document
>>      points to several other specifications (preferable in RFC or
>>      stable form) to provide additional guidance to implementers
>>      regarding any protocol implementation required to produce a
>>      successful CE router that interoperates successfully with a
>>      particular subset of currently deploying and planned common
>>      IPv6 access networks.
> 
> I'm not sure what that means. Does it mean that an implementation is
> free to violate a MUST NOT, because it doesn't really mean MUST NOT?

It means this is not a protocol spec. In fact, you might well decide to 
not implement this spec and still be compliant with all the protocol specs.



>> So the answer to that corner case is simply "properly build your
>> network". Personally I think trying to cater for all use cases, so
>> as to allow a corporate level network to be built without any router
>> config (or, it seems, admin skills), is a road to a massively
>> over-complicated spec that makes it harder rather than easier to
>> build "non-trivial" networks.
> 
> The only thing I'm asking for is an exception to the MUST NOT that allows
> the admin of the CPE to override the lifetimes. That is not a remote
> corner case, that's the kind of stuff every serious router allows the admin
> to do.

As noted, you're allowed to, already. In fact, I had suggested this text 
(for the "Introduction" section) in another email, which hopefully makes 
this very explicit:

"This document specifies recommendations for the default behavior of CE 
Routers, and does not preclude the availability of configuration knobs 
that might allow an operator or user to manually-configure the CE Router 
to deviate from these recommendations"

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1