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

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 13 May 2015 20:45:51 +0000

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.
- 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
- Does not mention that 'M' and 'O' flags, should be used as a mechanism to disable only stateful IPv6 address if SLAAC is enabled. 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. 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.

Dusan

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, May 12, 2015 4:05 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti; STARK, BARBARA H
Cc: Lin, Ping (Ping); Steven B.; [email-masked]; 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=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--QcC30&s=VvC2nQToB51qdh8J7Jlpw-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=APhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--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
> [email-masked]
> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3
> iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--Qc
> C30&s=4hQwBk4MvPSWFh7Lbyj9pLYa4obbbDO_17EYLcFKh3U&e=
> --------------------------------------------------------------------
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 14 May 2015 03:09:32 +0000

Hi Dusan and all,

> From: v6ops [mailto:[email-masked]] On Behalf Of Mudric, Dusan
> (Dusan)
> Sent: Thursday, May 14, 2015 4:46 AM
> To: Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H; [email-masked]
> Cc: Lin, Ping (Ping); Steven B.
> Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags
> 
> - 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

> 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=
> > 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
> >
> > 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
> > “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?
> >
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 14 May 2015 14:41:32 +0000

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?

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

[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 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:[email-masked]] 
Sent: Wednesday, May 13, 2015 11:10 PM
To: Mudric, Dusan (Dusan); Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H; [email-masked]
Cc: Lin, Ping (Ping); Steven B.
Subject: RE: Question re. stateless DHCPv6 and 'M' & 'O' flags

Hi Dusan and all,

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

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.

Best regards,

Bing

> (noting that it is still a draft, discussed in the v6ops WG) and you might move

> this discussion to the v6ops list, too.

> > I would appreciate your help answering the questions regarding the

> stateless DHCPv6 and ‘M’ & ‘O’ flags:

> > ·         RFC 4242, that defines when the end point should refresh the

> configuration information.

> >       ManagedFlag and OtherConfigFlag were removed accordingly.

> (Note

> > If stateless DHCPv6 is not used, stateful DHCPv6 is required. Then, ‘M’

> flag is not needed.

> man_listinfo_ipv6&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbL

> eaJxhf3

> iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdT

> CdwGe7w--Qc

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4OmAPBz0&s=QafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrEEqqiXs&e=

---

From: Enno Rey <[email-masked]>
Date: Thu, 14 May 2015 16:51:01 +0200

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://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf.

We gave a presentation on this today in the IPv6 WG at RIPE70, with some additionals comments:
https://ripe70.ripe.net/presentations/132-ERNW_RIPE70_IPv6_Behavior_Conflicting_Environments_v0_92_short.pdf

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:
> > 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
> 
> > > ??         RFC 4242, that defines when the end point should refresh the
> 
> > > 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
> 
> > > In the thread ???Re: Question re. RECONFIG in DHCPv6???, Bernie stated:
> 
> > > ???The RFC 3736 document is really not something I would recommend
> 
> > that stateless dhcpv6 was rather simple to implement.???
> 
> > >
> 
> > > Based on the fact that ???M??? & ???O??? flags are removed from the RFC 4862
> 
> > 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.
> 
> > >
> 
> > >
> 
> > >
> 

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

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

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 14 May 2015 16:29:26 +0000

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:[email-masked]] On Behalf Of Enno Rey
Sent: Thursday, May 14, 2015 10:51 AM
To: [email-masked]
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= 

thanks

Enno

On Thu, May 14, 2015 at 02:41:32PM +0000, Mudric, Dusan (Dusan) wrote:
> > - 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
> > - Does not mention that 'M' and 'O' flags, should be used as a 
> > mechanism to disable only stateful IPv6 address if SLAAC is enabled.
> > 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?).
> > 3736<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.rfc-2Ded
> > itor
.> 
> > 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=
> 
> 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. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

_______________________________________________
v6ops mailing list
[email-masked]
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=

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 15 May 2015 06:21:03 +0000

Hi Dusan,

> From: Mudric, Dusan (Dusan) [mailto:[email-masked]]
> Sent: Thursday, May 14, 2015 10:42 PM
> To: Liubing (Leo); Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H;
> [email-masked]
> 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:
[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.

> > simultaneously (bullet two does not say stateful), DHCPv6 address
> > should start with PI prefix
> [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] 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

> [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.
> 
> [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= ).
> 
> 
> 
> > mechanism to
> [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.
> 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
> 
> > DHCPv6
> [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.
> 
> 
> 
> > > il
> man_listinfo_v6ops&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9c
> bLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4m
> xdfBg7Uh-KZQfl4OmAPBz0&s=QafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrE
> EqqiXs&e=

---

From: Tomoyuki Sahara <[email-masked]>
Date: Fri, 15 May 2015 16:49:32 +0900

Hi,

> On May 15, 2015, at 15:21, Liubing (Leo) <[email-masked]> wrote:
> 

I got a different result from my experiment.

My Windows 8.1 host (updated today, running on VirtualBox on MacOS)
does not try to acquire address from DHCPv6 Solicitation but sends
DHCPv6 Information Request to aquire other information where RA flags
are A=0, M=0, O=1.  It behaves same as other operating systems.

I changed router's configuration to send RA with M=1 and the host
started to send DHCPv6 Solicitation, as I expected.

Then, I changed router's configuration back to M=0.  I expected that
Windows 8.1 host would send DHCPv6 Information Request but it continued
to send DHCPv6 Soliciation actually.

Then, I unplugged the Ethenret cable and plugged it back.  The host
started to send DHCPv6 Information Request again.

Thanks,
Tomoyuki

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 15 May 2015 09:01:10 +0000

Hi Enno and all,

> Sent: Thursday, May 14, 2015 10:51 PM
> To: [email-masked]
> 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:
[Bing] Thanks much for sharing the information. 
I'm very happy to see you've done RDNSS&DHCPv6-DNS_Option test and also the more complex scenarios with two routers on the same link. Those tests are really a nice step forward beyond the current v6ops draft.

Another very useful information from your report is the security considerations. Please allow me to quote some of them:
- "An attacker, without having to install a rogue router, can install a rogue DHCPv6 server and provide IPv6 addresses to
Windows 8.1 systems. This can allow her to interact with these systems in a different scope, which, for instance, is not
monitored by an IDPS system."
- " If you want to perform MiTM using a rogue DNS while legitimate RAs with the O flag set are sent to enforce the use of a
DHCPv6 server, you can spoof RAs with the same settings with the legitimate prefix (in order to remain undetectable) but advertising YOUR (attacker's) DNS using RDNSS. In this case, Fedora 21, Centos 7 and Ubuntu 14.04 will use the rogue
RDNSS (advertised by the RAs) as a first option."
- " Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack using a rogue DNS information either, since the
one obtained by the RAs of the first router has a higher priority."
- " The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited for DoS purposes. A rogue IPv6 router not only
provides its own information to the clients, but it also removes the previous obtained (legitimate) information."
- " The Fedora and Centos behaviour can also be exploited for MiTM purposes by advertising rogue RDNSS by RAs which
include RDNSS information."

I think these are essential cautions for the administrators to refer.

> nflicting_Environments_v0_92_short.pdf
[Bing] Very interesting and thoughtful presentation. Recommend all to have a read.

Best regards,
Bing

> > [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?
> >
> > > configured
> > > should
> > 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).
> >
> >
> >
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49
> 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>