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

["Liubing (Leo)" <[e-mail]>]

Hi Dusan,

> -----Original Message-----
> From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
> Sent: Thursday, May 14, 2015 10:42 PM
> To: Liubing (Leo); Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H;
> [e-mail]
> Cc: Lin, Ping (Ping); Steven B.
> Subject: RE: Question re. stateless DHCPv6 and 'M' & 'O' flags
> 
> Hi Bing,
> 
> The draft-ietf-v6ops-dhcpv6-slaac-problem nicely captures ambiguities and
> different interpretations around 'M', 'O' and 'A' flags. It also opens a floor
> for further discussion around:
> - the need for stateless DHCPv6,
> - simultaneous SLAAC and DHCPv6 address assignments, and
> - ND and DHCPv6 interworking: e.g. the role of ND on-link address prefix for
> DHCPv6 addresses.
> 
> Only when the needs are systematically captured, it will be possible to define
> the flags.
[Bing] I also think these further topics make sense. We might need a broader discussion across v6ops/6am/dhc and maybe another couple of drafts to discuss these topics.


> [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.
> [Dusan] Did the hosts run stateless DHCPv6, or stateful DHCPv6 without the
> address option in ORO, or stateful DHCPv6 and ignored the address in
> REPLY?
[Bing] Let me quote the result in the draft:
o  A=0, M=0, O=1

      *  Windows 8.1 acquired addresses and other information from
         DHCPv6. (P.S. Window 8.1 always tries to acquire address and other information through stateful DHCPv6, regardless of whatever the flags are)

      *  Windows 7, OSX 10.9 and IOS 8.0 acquired other information from
         DHCPv6. (P.S. stateless DHCPv6)

      *  Ubuntu 14.04 acquired no configuration information.

> > - 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?
> [Dusan] It is important that DHCPv6 address starts with on-link prefix.
> Otherwise the end point will be unreachable. When SLAAC/DHCPv6 are
> configured to run simultaneously, if M=1 is interpreted to mean run stateful
> DHCPv6 and obtain IPv6 address via DHCPv6 client, PI option should have L
> bit set to allow the end point to verify the acquired DHCPv6 address in
> on-link. This behavior should be standardized.
[Bing] Ah, you meant PIO (Prefix Information Option). I mistakenly saw it as "Provider Independent" prefix.


> [Bing] Btw, which "bullet two" did you refer to?
> [Dusan] Section 3 - 2).
> 
> > - 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?
> [Dusan] Yes, only the address part should be disabled. But other
> configuration information should be still available via DHCPv6.
> 
> [Bing] However, personally I'm not sure this should be a right behavior.
> SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios.
> [Dusan] draft-liu-v6ops-running-multiple-prefixes-03#section-3.1 only talks
> about the prefix delivering mechanism to routers using DHCPv6. It does not
> recommend the co-existing SLAAC/DHCPv6 behavior for hosts. If there is a
> need for multiple IPv6 addresses per interface, as mentioned in the draft,
> SLAAC already allows the use of multiple prefixes and DHCPv6 already allows
> the assignment of multiple IPv6 addresses. There is really no need for adding
> further complexity by mixing the two: SLAAC IPv6 addresses and DHCPv6
> IPv6 addresses.
[Bing] I agree that SLAAC could achieve the goal to configure multiple addresses. But it might not necessarily mean the DHCPv6 address config should be disabled in this case.
One thing I can imagine is that it might not only regarding to multiple addresses, but also multiple provisioning domains. Say, if one provisioning domain is using SLAAC and the other uses DHCPv6, the co-existing would allow the flexibility for that case.

Best regards,
Bing

> > 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.
> [Dusan] Stateless DHCPv6 is redundant by its nature. Stateful DHCPv6 can
> send SOLICIT and REQUEST messages with ORO option that does not require
> the address (e.g. without OPTION_IA_NA option code). If there is no
> stateless DHCPv6 client to control, there is no need for 'O' flag. The
> remaining 'M' flag can be used to control if ORO option has OPTION_IA_NA
> option code.
> 
> Regards,
> Dusan Mudric.
> 
> -----Original Message-----
> From: Liubing (Leo) [mailto:[e-mail]]
> Sent: Wednesday, May 13, 2015 11:10 PM
> To: Mudric, Dusan (Dusan); Brian E Carpenter; Lorenzo Colitti; STARK,
> BARBARA H; [e-mail]
> Cc: Lin, Ping (Ping); Steven B.
> Subject: RE: Question re. stateless DHCPv6 and 'M' & 'O' flags
> 
> Hi Dusan and all,
> 
> 
> 
> > -----Original Message-----
> 
> > From: v6ops [mailto:[e-mail]] On Behalf Of Mudric, Dusan
> 
> > (Dusan)
> 
> > Sent: Thursday, May 14, 2015 4:46 AM
> 
> > To: Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H;
> > [e-mail]
> 
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html
> _draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem-2D04-23appendix-2D
> A.2&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo
> UWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl
> 4OmAPBz0&s=RYBX4oXn9Jb6D1f2S20unVfInYB3XQCyqBuchFII1-w&e= ).
> 
> 
> 
> > - 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_
> draft-2Dliu-2Dv6ops-2Drunning-2Dmultiple-2Dprefixes-2D03-23section-2D3.
> 1&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoU
> WB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4
> OmAPBz0&s=s5I7IrkUrSvi6Ev5mUhvri9GoL2pLI1Z2cWYDTEQOmM&e=  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:[e-mail]]
> 
> > Sent: Tuesday, May 12, 2015 4:05 PM
> 
> > To: Mudric, Dusan (Dusan); Lorenzo Colitti; STARK, BARBARA H
> 
> > Cc: Lin, Ping (Ping); Steven B.; [e-mail]; 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_ht
> > ml_
> 
> >
> 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
> 
> > > [e-mail]
> 
> > > Administrative Requests:
> 
> > >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> > > il
> 
> > >
> 
> >
> man_listinfo_ipv6&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbL
> 
> > eaJxhf3
> 
> > >
> 
> >
> iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdT
> 
> > CdwGe7w--Qc
> 
> > > C30&s=4hQwBk4MvPSWFh7Lbyj9pLYa4obbbDO_17EYLcFKh3U&e=
> 
> > > --------------------------------------------------------------------
> 
> > >
> 
> >
> 
> > _______________________________________________
> 
> > v6ops mailing list
> 
> > [e-mail]
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> >
> man_listinfo_v6ops&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9c
> bLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4m
> xdfBg7Uh-KZQfl4OmAPBz0&s=QafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrE
> EqqiXs&e=