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

["Mudric, Dusan (Dusan)" <[e-mail]>]

Regarding 'M' and 'O' flags (and possibly other flags: A, L, ...), we need first to answer:
- if there is a need to administratively enable/disable DHCPv6 and SLAAC,
- if there is a need for stateless DHCPv6,
- if there is a need for simultaneous SLAAC and DHCPv6 address assignments, and
- if there is a need for ND and DHCPv6 interworking: e.g. the role of ND on-link address prefix for DHCPv6 addresses, MTU and DNS configuration, ...

Dusan Mudric.

-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Enno Rey
Sent: Thursday, May 14, 2015 10:51 AM
To: [e-mail]
Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags

All,

pls allow to make you aware that we did some similar tests as those laid out in draft-ietf-v6ops-dhcpv6-slaac-problem (btw: very nice work!). Details & results can be found in:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ernw.de_download_ERNW-5FWhitepaper-5FIPv6-5FRAs-5FRDNSS-5FDHCPv6-5FConflicting-5FParameters.pdf&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=SFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0ZGazMF2c&s=S0TH39V-uf4_dlD9pSQUQ5DVzIQMNk3Om1XWJmf_DZQ&e= .

We gave a presentation on this today in the IPv6 WG at RIPE70, with some additionals comments:
https://urldefense.proofpoint.com/v2/url?u=https-3A__ripe70.ripe.net_presentations_132-2DERNW-5FRIPE70-5FIPv6-5FBehavior-5FConflicting-5FEnvironments-5Fv0-5F92-5Fshort.pdf&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=SFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0ZGazMF2c&s=AzY7qkWVsXBI5gcqrq5yLCxte8EVuqZnMFRjIvm_keY&e= 

Overall we observed the same unfortunate ambiguities and differing vendor interpretations/strategies.

thanks

Enno


On Thu, May 14, 2015 at 02:41:32PM +0000, Mudric, Dusan (Dusan) wrote:
> 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] (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?
> 
> > - 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] 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.
> 
> > 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-2DA.2&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4OmAPBz0&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=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4OmAPBz0&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_
> > 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-2Ded
> > itor
.> 
> > 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_
> > > mail
> 
> > >
> 
> > 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_ma
> > ilman_listinfo_v6ops&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLea
> > Jxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQ
> > fl4OmAPBz0&s=QafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrEEqqiXs&e=
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_v6ops&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf
> 3iCrhIoUWB8YLZU23029sMQGQ2kY&m=SFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0ZGaz
> MF2c&s=ZPjsWnHR8KdgkzP0GOQBecbMqehiw424gpmxD0ya1p8&e=

--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. [phone] - Fax [phone] - Cell [phone] 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

_______________________________________________
v6ops mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=SFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0ZGazMF2c&s=ZPjsWnHR8KdgkzP0GOQBecbMqehiw424gpmxD0ya1p8&e=