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

[Philip Homburg <[e-mail]>]

[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.

> If the prefix is static, I wonder why you'd use DHCPv6. That said,
> a static prefix would be, I guess, a prefix with an infinite
> lifetime. So, if anything, one might consider this value as a
> special case -- i..e, if the DHCPv6 valid-lifetime is infinity
> (0xffffffff), set the RA lifetime to infinity.

The DHCPv6 lifetime is actually very short for reasons I described before.

> 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?

> Riiight.  So the network admin has built a network using "consumer
> grade" or ISP supplied CPE, using default configuration.  

What does this mean? Do we have 'real' routers that allowed to use
longer lifetimes in RAs, because they are expensive and there are
'consumer grade' routers that are not?

Is that how we want to make standards?

> 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.