Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags

Hi Dusan and all,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mudric, Dusan
> (Dusan)
> Sent: Thursday, May 14, 2015 4:46 AM
> To: Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H; v6ops@ietf.org
> Cc: Lin, Ping (Ping); Steven B.
> Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags
> 
> draft-ietf-v6ops-dhcpv6-slaac-problem:
> - Does not mention use of stateless DHCPv6
> - Does not mention that is not clear if stateless DHCPv6 client should start if
> SLAAC is used and M=0 and O changes from 0 to 1. Or, stateful DHCPv6 can
> start but IPv6 address can be ignored or ORO option does not require the
> address.
[Bing] (Speak as a co-author) We indeed didn't test the case as you said above, but we tested a similar case: at initial stage, when A=0,M=0, and O=1, some platform would start stateless DHCPv6 while some not.
Details please refer to the Appendix A.2 (https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-04#appendix-A.2).

> - Does not mention if the host is SLAAC and stateful DHCPv6 configured
> simultaneously (bullet two does not say stateful), DHCPv6 address should
> start with PI prefix
[Bing] Sorry I didn't catch your point. Why is the "PI prefix" related to SLAAC/DHCPv6 configured simultaneously?
Btw, which "bullet two" did you refer to?

> - Does not mention that 'M' and 'O' flags, should be used as a mechanism to
> disable only stateful IPv6 address if SLAAC is enabled. 
[Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6 address configuration should be disabled?
We did observed some behaviors like this in some platform: when a host has configured SLAAC, and then M changes from 0 to 1, some hosts just ignore the M flag (see the second bullet of Appendix A.3).

However, personally I'm not sure this should be a right behavior. SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios. https://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes-03#section-3.1 has a brief discussion on this. But this draft-ietf-v6ops-dhcpv6-slaac-problem does not intend to discuss what the right behavior should be.

> What is the value of
> disabling other DHCPv6 configuration? End point instruments need DHCPv6
> for other configuration information and that shall not be disabled via a
> router (Unless there is a plan to provide all that configuration via a router?).
> If there is agreement on this statement, only one flag is needed, 'M' flag.
[Bing] I can't really answer this question. My guess is that , when the hosts can get both address and other configuration information through stateful DHCPv6 configuration, then the stateless DHCPv6 configuration is redundant if it is always on.

> This flag would control if end point instruments would have only SLAAC or
> only DHCPv6 address (example: M=1 would mean only DHCPv6 address is
> configured and if A=1 would mean that DHCPv6 address would have to start
> with the PI prefix). I don't see a need for both SLAAC and DHCPv6 addresses.
[Bing] As said above, I think co-existing might make sense in some scenarios.

Best regards,
Bing

> Dusan
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Tuesday, May 12, 2015 4:05 PM
> To: Mudric, Dusan (Dusan); Lorenzo Colitti; STARK, BARBARA H
> Cc: Lin, Ping (Ping); Steven B.; ipv6@ietf.org; Bernie Volz (volz)
> Subject: Re: Question re. stateless DHCPv6 and 'M' & 'O' flags
> 
> Hi Dusan,
> 
> The M/O flags are not obsolete. They are defined in RFC 4861.
> 
> You might want to read
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_
> draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem&d=AwIFaQ&c=BFpWQ
> w8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2k
> Y&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--QcC30&s=VvC2nQToB
> 51qdh8J7Jlpw-Y3NE3g_JSuooay2fEVu0s&e=
> (noting that it is still a draft, discussed in the v6ops WG) and you might move
> this discussion to the v6ops list, too.
> 
> Regards
>    Brian Carpenter
> 
> 
> On 13/05/2015 06:53, Mudric, Dusan (Dusan) wrote:
> > Hi Everyone,
> >
> > I would appreciate your help answering the questions regarding the
> stateless DHCPv6 and ‘M’ & ‘O’ flags:
> >
> > Background:
> > ===========
> > Following RFC 2462, “O” flag in Router Advertisements is used to start
> stateless DHCPv6 client. When using ‘O’ flag, the end point shall support:
> >
> > ·         RFC
> 3736<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.rfc-2Deditor.
> org_in-2Dnotes_rfc3736.txt&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=
> UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64
> eDKTcooJX8vvQdTCdwGe7w--QcC30&s=mZkhBdhXoIRGEsK6Z3mfWS4RyvKB
> -IiKhorpXBfnwEY&e= > , that defines stateless DHCPv6 client
> >
> > ·         RFC 4242, that defines when the end point should refresh the
> configuration information.
> >
> > Questions:
> > =========
> > If RFC 4862 removed ‘M’ & ‘O’ flags and obsoleted RFC 2462 (that
> defines ‘M’ & ‘O’ flags), why are the flags not deprecated? What is the
> value of referring to the obsoleted standard, in order to support flags in the
> solution that is not mature?
> >
> > rfc4862#appendix-C
> >    o  Removed the text regarding the M and O flags, considering the
> >       maturity of implementations and operational experiences.
> >       ManagedFlag and OtherConfigFlag were removed accordingly.
> (Note
> >       that this change does not mean the use of these flags is
> >       deprecated.)
> >
> > In the thread “Re: Question re. RECONFIG in DHCPv6”, Bernie stated:
> > “The RFC 3736 document is really not something I would recommend
> following - see full RFC 3315 and implement those features you need (such
> as only Information-Request and Reply). 3736 was written to demonstrate
> that stateless dhcpv6 was rather simple to implement.”
> >
> > Based on the fact that ‘M’ & ‘O’ flags are removed from the RFC 4862
> and the statement above, can we say the stateless DHCPv6 is not mandatory
> and, consequently, ‘O’ flag is not required?
> >
> > If stateless DHCPv6 is not used, stateful DHCPv6 is required. Then, ‘M’
> flag is not needed.
> >
> > Regards,
> > Dusan Mudric.
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> >
> man_listinfo_ipv6&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbL
> eaJxhf3
> >
> iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdT
> CdwGe7w--Qc
> > C30&s=4hQwBk4MvPSWFh7Lbyj9pLYa4obbbDO_17EYLcFKh3U&e=
> > --------------------------------------------------------------------
> >
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops