Subject: [v6ops] DHCPv6 option for MAX_SOL_RT

From: Ralph Droms <[email-masked]>
Date: Wed, 16 Nov 2011 09:28:21 +0800

...is here: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 22:40:50 -0600

Ralph,

Thanks much for the URL to the doc.  One question related to this text from the document snipped below between squared braces.

[If the DHCPv6 server declines to assign any addresses to a client in

an IA_NA or IA_TA option,]

The WAN interface on an IPv6 CE router is using an unnumbered WAN model and thus the WAN DHCPv6 client request may only include an IA_PD option.  Thus, don’t we have to include the IA_PD option to the text above?  If yes, then some other text immediately below in the document also changes to include the IA_PD.

Regards,

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Wednesday, November 16, 2011 9:28 AM
To: [email-masked]
Subject: [v6ops] DHCPv6 option for MAX_SOL_RT

...is here: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 <http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 16 Nov 2011 12:48:12 +0800

Yeah, the text should probably refer to IA_PD as well.  Forwarding to dhc WG as well for comment before I make a change.

- Ralph

On Nov 16, 2011, at 12:40 PM 11/16/11, Hemant Singh (shemant) wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 23:02:37 -0600

Great, thanks,

Hemant

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 12:48 PM
To: Hemant Singh (shemant)
Cc: Ralph Droms; IPv6 Operations; [email-masked] WG
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Yeah, the text should probably refer to IA_PD as well.  Forwarding to
dhc WG as well for comment before I make a change.

- Ralph

On Nov 16, 2011, at 12:40 PM 11/16/11, Hemant Singh (shemant) wrote:

> Ralph,
>  
> Thanks much for the URL to the doc.  One question related to this text
from the document snipped below between squared braces.
> The WAN interface on an IPv6 CE router is using an unnumbered WAN
model and thus the WAN DHCPv6 client request may only include an IA_PD
option.  Thus, don't we have to include the IA_PD option to the text
above?  If yes, then some other text immediately below in the document
also changes to include the IA_PD.
> ...is here:
http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Nov 2011 00:07:06 +0800

> http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00

I don't think we should mess with the default SOL_MAX_RT. In some cases
(e.g., if a host or CE router is disconnected from the network without link
going down), it will cause the host to get stuck asking for DHCPv6 only
once every two hours. This will cause it have to wait, on average, a full
hour before obtaining IPv6 parameters again. This is much slower than IPv4
and thus is a performance parity issue.

Given that this draft defines the option to set SOL_MAX_RT from the DHCPv6
server, why do we need to change the default at all?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Nov 2011 18:19:02 -0600

Lorenzo,

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Thursday, November 17, 2011 12:07 AM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

> In some cases (e.g., if a host or CE router is disconnected from the
network without link going down), it will >cause the host to get stuck
asking for DHCPv6 only once every >two hours. 

How does a node get disconnected from the network without the node's
link going down?  Please give an example?

Hemant

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 17 Nov 2011 08:31:18 +0800

On 11/17/11 08:19 , Hemant Singh (shemant) wrote:
> Lorenzo,
> 
>  
> 
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Lorenzo Colitti
> *Sent:* Thursday, November 17, 2011 12:07 AM
> *To:* Ralph Droms
> *Cc:* [email-masked]
> *Subject:* Re: [v6ops] DHCPv6 option for MAX_SOL_RT
> 
>  
> 
>  
> 
> How does a node get disconnected from the network without the node’s

l2 vs l1 segmentation...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 00:38:43 +0000

> l2 vs l1 segmentation...

Wouldn't there be evidence of this because you'd see different RAs?

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 17 Nov 2011 08:41:30 +0800

> Wouldn't there be evidence of this because you'd see different RAs?

or none at all.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 00:59:53 +0000

> or none at all.

Indeed.   Point being that we can probably figure out a way to make sure that this doesn't happen.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Nov 2011 19:27:47 -0600

-----Original Message-----
From: Joel jaeggli [mailto:[email-masked]] 
Sent: Thursday, November 17, 2011 8:31 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Ralph Droms; [email-masked]
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

>l2 vs l1 segmentation...

Now I remember also one case that I mentioned in the cpe router design
team.  There is a network hub between the broadband modem and the CPE
router.  Even if the modem's Ethernet port signal link down state, the
hub does not transmit such messages.  

Hemant

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 17 Nov 2011 06:27:14 +0000

I think I could live with not changing the default value.

We will also need to ensure IA_PD is added to the draft.

In separate threads the notion of a per IA option is also being discussed.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

On 11/17/11 12:07 AM, "Lorenzo Colitti" <[email-masked]> wrote:

>(e.g., if a host or CE router is disconnected from the network without
>link going down), it will cause the host to get stuck asking for DHCPv6
>only once every two hours. This will cause it have to wait, on average, a
>full hour before obtaining IPv6 parameters again. This is much slower
>than IPv4 and thus is a performance parity issue.
>
>Given that this draft defines the option to set SOL_MAX_RT from the
>DHCPv6 server, why do we need to change the default at all?
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Nov 2011 15:25:13 +0800

> Wouldn't there be evidence of this because you'd see different RAs?

If you're a CE router, it doesn't matter what RAs you see. CE routers
explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or
not,

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 07:50:50 +0000

On Nov 17, 2011, at 3:25 PM, "Lorenzo Colitti" <[email-masked]> wrote:
> If you're a CE router, it doesn't matter what RAs you see. CE routers explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or not,

So if you're a CE router that's plugged into an ethernet that's got your upstream on it, and your upstream goes away, but your switch doesn't tell you because it doesn't know you need to know, then we have a problem.   Is that a possible scenario for CE routers?   It seems to me that typically a CE router is going to see a carrier transition of some kind when moving to a different provider network.

BTW, I actually am not entirely convinced that Ralph's proposal is a good idea—it's a quick hack to work around a one-time operational problem that we will be stuck with forever.   However, I'd like us to focus on real reasons for liking it or disliking it.   I think the "carrier transition won't be noticed" issue is easily addressed and not a very likely scenario anyway.   I would prefer to focus on real problems.

---

From: james woodyatt <[email-masked]>
Date: Thu, 17 Nov 2011 14:55:08 -0800

> If you're a CE router, it doesn't matter what RAs you see. CE routers explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or not,

This is news to me.  The way I read RFC 6204 and I-D.ietf-v6ops-6204bis, CPE routers are not required to ignore the M and O bits in IPv6 router advertisements.  As far as I can see, CPE router implementations that wait to receive a router advertisement on the WAN with O=1 before starting the DHCPv6 client still conforms to the recommendations and complies with the forthcoming IPv6Ready CPE Router Interoperability test specification.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Nov 2011 18:29:13 -0600

James,

RFC 3633 specifies acquiring an IA_PD between a requesting and a
delegating router.  Thus such a protocol between two routers could care
less if the delegating router issued an RA to the requesting router or
if an RA issued, why care about the M and the O bits.  The CE router WAN
interface does support an unnumbered model in which the WAN interface
has only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to
acquire an IA_PD.

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Thursday, November 17, 2011 5:55 PM
To: Lorenzo Colitti
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

If you're a CE router, it doesn't matter what RAs you see. CE routers
explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD
or not,

This is news to me.  The way I read RFC 6204 and I-D.ietf-v6ops-6204bis,
CPE routers are not required to ignore the M and O bits in IPv6 router
advertisements.  As far as I can see, CPE router implementations that
wait to receive a router advertisement on the WAN with O=1 before
starting the DHCPv6 client still conforms to the recommendations and
complies with the forthcoming IPv6Ready CPE Router Interoperability test
specification.

--

---

From: james woodyatt <[email-masked]>
Date: Thu, 17 Nov 2011 18:39:10 -0800

On Nov 17, 2011, at 16:29 , Hemant Singh (shemant) wrote:

> RFC 3633 specifies acquiring an IA_PD between a requesting and a delegating router.  Thus such a protocol between two routers could care less if the delegating router issued an RA to the requesting router or if an RA issued, why care about the M and the O bits.  The CE router WAN interface does support an unnumbered model in which the WAN interface has only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to acquire an IA_PD.

None of that implies that CPE routers are required or even expected, by IETF, to ignore the M and O bits in router advertisements received at their WAN interfaces.  I still don't see any language anywhere in an IETF document that says CPE routers are not permitted to wait until they receive a router advertisement with O=1 before initiating the DHCPv6 client on their WAN interface to request any options, including the IA_PD option.

(For the record, I am still opposed to the adoption of any such language.)

--
j h woodyatt <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2011 05:07:09 +0000

> None of that implies that CPE routers are required or even expected, by IETF, to ignore the M and O bits in router advertisements received at their WAN interfaces.  I still don't see any language a…

Since we don't know what the M and O bits do, I think it's a bit questionable to use them in this way.   I mean, I can hack my router so that your CPE device will not fail to configure itself, but that probably won't be possible anymore once my IPv6 upstream is coming from my actual ISP.

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Nov 2011 07:42:22 +0100

> (For the record, I am still opposed to the adoption of any such language.)

6204 says that you are free to wait for the RA. and look at the M and the O bits. from the M/O bits the CPE can determine if it should ask for only IA_PD or both IA_PD and IA_NA. a 6204 router MUST always do DHCP.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Nov 2011 07:43:36 +0100

Ted,

> So if you're a CE router that's plugged into an ethernet that's got your upstream on it, and your upstream goes away, but your switch doesn't tell you because it doesn't know you need to know, then…

not getting a L2 event is common. there are multiple proposals to deal with that from Ethernet OAM, short DHCP lease timers to BFD echo. not sure any of that applies much to this discussion.

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Fri, 18 Nov 2011 10:04:53 -0800

On Nov 17, 2011, at 22:42 , Ole Troan wrote:
> 
> a 6204 router MUST always do DHCP.

Not strictly true.  Any RFC 6204 conforming CPE router that never receives router advertisements with O=1 on its WAN interface is under no obligation to start its DHCPv6 client.

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Nov 2011 19:08:37 +0100

James,

> Not strictly true.  Any RFC 6204 conforming CPE router that never receives router advertisements with O=1 on its WAN interface is under no obligation to start its DHCPv6 client. 

strictly true.
   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
           delegation, regardless of the M and O flags in a received
           Router Advertisement message.

cheers,
Ole

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 18 Nov 2011 18:24:58 +0000

On 11/17/11 3:50 PM, "Ted Lemon" <[email-masked]> wrote:

>So if you're a CE router that's plugged into an ethernet that's got your
>upstream on it, and your upstream goes away, but your switch doesn't tell
>you because it doesn't know you need to know, then we have a problem.
>Is that a possible scenario for CE routers?   It seems to me that
>typically a CE router is going to see a carrier transition of some kind
>when moving to a different provider network.
[jjmb] this is something that could and does happen in real deployments.

>
>BTW, I actually am not entirely convinced that Ralph's proposal is a good
>idea‹it's a quick hack to work around a one-time operational problem that
>we will be stuck with forever.   However, I'd like us to focus on real
>reasons for liking it or disliking it.   I think the "carrier transition
>won't be noticed" issue is easily addressed and not a very likely
>scenario anyway.   I would prefer to focus on real problems.
[jjmb] I do not agree, many of the assumptions being made assume steady
state, full deployment.  Incremental enablement must be considered, no one
is going to flash enable IPv6.

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 18 Nov 2011 18:28:10 +0000

>From an operators point of view who is deploying IPv6 I expect the M=O=1
to have meaning.

Default routes seem important, as such router advertisements are relevant.

On 11/18/11 8:29 AM, "Hemant Singh (shemant)" <[email-masked]> wrote:

>less if the delegating router issued an RA to the requesting router or if
>an RA issued, why care about the M and the O bits.  The CE router WAN
>interface does support an unnumbered model in which the WAN interface has
>only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to acquire
>an IA_PD.
> 
>Hemant
> 
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>james woodyatt

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 18 Nov 2011 18:32:37 +0000

Some implementations and deployments were planned before the semantics
behind the M/O bits were altered, so I would argue that they have value
and meaning.

The point here is we should not be prohibiting behavior.

John

On 11/18/11 1:07 PM, "Ted Lemon" <[email-masked]> wrote:

>> None of that implies that CPE routers are required or even expected, by
>>IETF, to ignore the M and O bits in router advertisements received at
>>their WAN interfaces.  I still don't see any language anywhere in an
>>IETF document that says CPE routers are not permitted to wait until they
>>receive a router advertisement with O=1 before initiating the DHCPv6
>>client on their WAN interface to request any options, including the
>>IA_PD option.
>
>Since we don't know what the M and O bits do, I think it's a bit
>questionable to use them in this way.   I mean, I can hack my router so
>that your CPE device will not fail to configure itself, but that probably
>won't be possible anymore once my IPv6 upstream is coming from my actual
>ISP.

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 18 Nov 2011 18:34:25 +0000

FWIW - short lease timer is a common practice in broadband networks,
however, this is operationally challenging at times if not automated.  It
would be ideal if this were properly addressed and discussed.

On 11/18/11 2:43 PM, "Ole Troan" <[email-masked]> wrote:

>> So if you're a CE router that's plugged into an ethernet that's got
>>your upstream on it, and your upstream goes away, but your switch
>>doesn't tell you because it doesn't know you need to know, then we have
>>a problem.   Is that a possible scenario for CE routers?   It seems to
>>me that typically a CE router is going to see a carrier transition of
>>some kind when moving to a different provider network.
>
>not getting a L2 event is common. there are multiple proposals to deal
>with that from Ethernet OAM, short DHCP lease timers to BFD echo. not
>sure any of that applies much to this discussion.
>
>> BTW, I actually am not entirely convinced that Ralph's proposal is a
>>good idea‹it's a quick hack to work around a one-time operational
>>problem that we will be stuck with forever.   However, I'd like us to
>>focus on real reasons for liking it or disliking it.   I think the
>>"carrier transition won't be noticed" issue is easily addressed and not
>>a very likely scenario anyway.   I would prefer to focus on real
>>problems.
>
>cheers,
>Ole
>
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 18 Nov 2011 18:29:25 +0000

I agree with James and we should not prohibit the behavior.

On 11/18/11 10:39 AM, "james woodyatt" <[email-masked]> wrote:

>their WAN interfaces.  I still don't see any language anywhere in an IETF
>document that says CPE routers are not permitted to wait until they
>client on their WAN interface to request any options, including the IA_PD
>option.
>

---

From: james woodyatt <[email-masked]>
Date: Fri, 18 Nov 2011 10:41:38 -0800

>           Router Advertisement message.

You're right.  I got ahead of myself.  However, any RFC 6204 conforming CPE router that never receives router advertisements on its WAN interface is under no obligation to start its DHCPv6 client.

It makes no sense to me that RFC 6204 expressly tells CPE router vendors they MUST start the DHCPv6 client even when O=0 in all router advertisements previously received on the WAN interface.  What's the purpose of that? Why on Earth would an operator need for CPE routers to start their DHCPv6 clients when the router advertisements they're sending have O=0?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 18 Nov 2011 13:43:46 -0500

The rest of us (well, me and the MSO guys and I think Hemant and Wes)
agreed to change the language of WPD-4. That's why the current 6204bis
draft has:
   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
           delegation, regardless of the M and O flags in a received
           Router Advertisement message.

I still think this is a reasonable change.
It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
regardless of M/O. It just doesn't mandate it. Now it only mandates it
if M or O=1. The current language leaves it up to the vendor (or other
specs) as to what to do when M=O=0, or no received RA. Devices compliant
under the old requirement are still compliant under the new requirement.

I'm comfortable with the current 6204bis language. I think it allows the
MSOs the ability to decrease the number of CE routers that are doing
all-the-time DHCPv6, while allowing me the freedom to have my CE routers
behave per the previous requirements. It doesn't make previously
compliant devices suddenly non-compliant. It also doesn't bring to zero
the quantity of CE routers that are causing the storm. But hopefully it
decreases the number sufficiently to allow for the desired controlled
introduction architecture to function without being brought to its knees
by CE routers who want their IA_PD and want it now.

Please, can't we agree on this compromise? Pretty please?
Barbara

> Of Ole Troan
> Sent: Friday, November 18, 2011 1:09 PM
> To: james woodyatt
> Cc: IPv6 Operations
> > Not strictly true.  Any RFC 6204 conforming CPE router that never
> receives router advertisements with O=1 on its WAN interface is under
> no obligation to start its DHCPv6 client.
> 
> strictly true.

---

From: james woodyatt <[email-masked]>
Date: Fri, 18 Nov 2011 10:51:48 -0800

>           Router Advertisement message.

That's the text from RFC 6204.  Currently, I-D.draft-ietf-v6ops-6204bis-02 says this:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement message.

That's better, but it's still confusing.  It's invalid to send M=1 and O=0, so it suffices to say this:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when the O flag is set to 1 in a received Router
           Advertisement message.

---

From: Wes Beebee <[email-masked]>
Date: Fri, 18 Nov 2011 13:53:22 -0500

Barbara -

The text in draft-ietf-v6ops-6204bis-02 is:
   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement message.

- Wes

---

From: Wes Beebee <[email-masked]>
Date: Fri, 18 Nov 2011 13:58:48 -0500

James,

>From RFC 4861:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

So, M=1 and O=0 is valid, the interpretation is that both addresses and
other information is available.

- Wes

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Nov 2011 20:00:27 +0100

James,

> It makes no sense to me that RFC 6204 expressly tells CPE router vendors they MUST start the DHCPv6 client even when O=0 in all router advertisements previously received on the WAN interface.  What…

let me see if I can recount the reasoning behind:
 - DHCP PD is a router to router protocol. 3633 was never written to have a dependency on M/O bits.
   routers do not listen to RAs.
 - the issue of addressing / prefix delegation is different from routing.
   default router discovery was not specified in 3633. there are multiple other ways of doing it.
   there are deployments that do not use RAs.
 - as the dual host/router mode on an interface is not described in any RFC, the text in 6204 is in unchartered
   territory, we didn't want to violate text in 4861/4862 too much
 - on a point to point WAN link there is no need for router discovery.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Nov 2011 20:04:37 +0100

Barbara,

> Please, can't we agree on this compromise? Pretty please?

I'm afraid not. the text is just fuzzing the issue.
what are the use case for a CPE not trying to acquire a prefix?

I do expect things to change as a "homenet router" gets defined.

let's hold off on 6204bis until we have real new requirements.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2011 21:41:19 +0000

On Nov 19, 2011, at 2:25 AM, "Brzozowski, John" <[email-masked]> wrote:
>> I think the "carrier transition

By "carrier" here I meant "layer one carrier" (e.g., ethernet carrier), not "ISP."   Transition means "the network went away and came back," not "the ISP slowly or quickly deployed IPv6."   :)

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 19 Nov 2011 05:19:22 +0000

Barbara,

I think we are close if not already there.  IMO if we are both aligned I
think we can move this work forward and focus on getting 6204bis out the
door.  I have been working closely with Chris Donley and appreciate your
willingness to collaborate.

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 19 Nov 2011 05:19:35 +0000

I agree with Barbara that we should move RFC6204bis forward.  I see no
reason why we should hold RFC6204bis any longer especially if two of the
primary customers for the work are in agreement.

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 19 Nov 2011 05:19:37 +0000

Ack, I clearly misinterpreted.

On 11/19/11 5:41 AM, "Ted Lemon" <[email-masked]> wrote:

>On Nov 19, 2011, at 2:25 AM, "Brzozowski, John"
><[email-masked]> wrote:
>By "carrier" here I meant "layer one carrier" (e.g., ethernet carrier),
>not "ISP."   Transition means "the network went away and came back," not
>"the ISP slowly or quickly deployed IPv6."   :)
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 20 Nov 2011 22:12:40 +0900

On Fri, Nov 18, 2011 at 07:55, james woodyatt <[email-masked]> wrote:

> advertisements.  As far as I can see, CPE router implementations that wait
> to receive a router advertisement on the WAN with O=1 before starting the
> DHCPv6 client still conforms to the recommendations and complies with the
> forthcoming IPv6Ready CPE Router Interoperability test specification.
>

You're right, I misspoke. CE routers don't have to ignore RAs, they're just
not required to wait for them before initiating DHCPv6.

---

From: "Frank Bulk" <[email-masked]>
Date: Mon, 21 Nov 2011 21:39:27 -0600

What's fuzzy?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ole Troan
Sent: Friday, November 18, 2011 1:05 PM
To: STARK, BARBARA H
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

<snip>

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Nov 2011 10:00:31 +0100

Frank,

> under the old requirement are still compliant under the new requirement.

CPE receives and RA with M=O=0, what is it supposed to do with regards to PD?
left up to the vendor to decide?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2011 18:20:10 +0900

> left up to the vendor to decide?

Not do PD. Also not do PD if it doesn't have an RA at all, since a prefix
without a route is useless.

Hmm, I think I can hear the cries already... "DHCPv6 PD is just a fax
replacement! Routing has nothing to do with addressing! Routers don't
listen to RAs!". IMO none of those are true. :-)

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 22 Nov 2011 03:59:48 -0600

Thanks for clarifying.

It's my understanding that if the CPE is using the unnumbered model it will
request a PD and if it's a device that must meet the CableLabs specs then it
will not request a PD.

Why do we have to specify behavior for M=O=0?

Frank

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Tuesday, November 22, 2011 3:01 AM
To: Frank Bulk
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

> under the old requirement are still compliant under the new requirement.

CPE receives and RA with M=O=0, what is it supposed to do with regards to
PD?
left up to the vendor to decide?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Nov 2011 11:03:36 +0100

Frank,

> request a PD and if it's a device that must meet the CableLabs specs then it

I'm aware of no such requirement. I haven't seen anything in DOCSIS 3.0 that require a CE router _not_ to request a PD.
the issue discussed has been about the "DHCP storm" created when IPv6 is enabled but the policy on the DHCP server is to not hand out addresses or prefixes. we've got a fix for that in DHCP.

> Why do we have to specify behavior for M=O=0?

there isn't a use case for an ISP wanting to _only_ do IA_PD?
as in not DHCP for other configuration information nor for address assignment.

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Tue, 22 Nov 2011 11:05:11 +0100

On Nov 22, 2011, at 10:20 AM, Lorenzo Colitti wrote:

> Not do PD. Also not do PD if it doesn't have an RA at all, since a prefix without a route is useless.
> 
> Hmm, I think I can hear the cries already... "DHCPv6 PD is just a fax replacement! Routing has nothing to do with addressing! Routers don't listen to RAs!". IMO none of those are true. :-)

Architectural arguments aside and more to running code, did we not hear that there is equipment in the field already that *expects* home routers to give up and send DHCPv6 even with no RA received? I think I have now heard two cases, from two different vendors, where we have this expectation today. Couple that with CE that send 3-4 RS and, if no RA received, start sending DHCPv6 from two different large retail CPE vendors, and I worry that cat is out of the bag on this one. "Conservative in what you send" already lost the battle, and "liberal in what you accept" is having to make up for it this time. 

- Mark

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 22 Nov 2011 04:25:35 -0600

You're right, there's nothing currently in the CableLabs specs that require
a CE router not to request a PD, but my understanding is that what the MSO
folks want to avoid the DHCPv6 storm.  Looping in Chris here to correct me
if I'm wrong.

I don't know of a use case for an ISP wanting to only do IA_PD.  As the
others have said, why get a prefix that's not routable out the WAN?
Hopefully someone else who knows of such a use case can pipe in.

The way the rfc6402bis (and others) are written today, is there anything
that would prevent the CPE from doing an IA_PD upon receiving an RA for
M=O=0?  If not, I think we've left in a good amount of flexibility for the
future.

Frank

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Tuesday, November 22, 2011 4:04 AM
To: [email-masked]
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

> request a PD and if it's a device that must meet the CableLabs specs then
it

I'm aware of no such requirement. I haven't seen anything in DOCSIS 3.0 that
require a CE router _not_ to request a PD.
the issue discussed has been about the "DHCP storm" created when IPv6 is
enabled but the policy on the DHCP server is to not hand out addresses or
prefixes. we've got a fix for that in DHCP.

there isn't a use case for an ISP wanting to _only_ do IA_PD?
as in not DHCP for other configuration information nor for address
assignment.

cheers,
Ole

---

From: [email-masked]
Date: Tue, 22 Nov 2011 11:25:40 +0100 (CET)

> there isn't a use case for an ISP wanting to _only_ do IA_PD?

I'd love to do only IA_PD (and not IA_NA) - but I would most likely
want to hand out DNS servers etc. also.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 22 Nov 2011 04:26:33 -0600

And you can do that if O=1, right?

Frank

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2011 19:27:13 +0900

> as in not DHCP for other configuration information nor for address

Yes, there is a use case for an ISP wanting to do only IA_PD and either
unnumbered or SLAAC on the WAN interface.

I think this should be indicated by M=0, O=1, as this is what's most
consistent with the current definition of the M/O bits in (RFC 4861; a
prefix is not "address information", and therefore it's "other
configuration information").

I believe that this is, for example, what the Apple implementation does -
in order to get it to do DHCPv6 PD, you need to send it an RA with O=1.

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Nov 2011 11:27:58 +0100

Frank,

> M=O=0?  If not, I think we've left in a good amount of flexibility for the

no, nothing would prevent it. nothing demands it either.
we're making it 'undefined'. is that what we really want?
the customer call with; my D-link works just fine, but my Linksys doesn't?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2011 19:30:18 +0900

> as in not DHCP for other configuration information nor for address

How can you argue that IA_PD is not other configuration information? You
could argue that a prefix is an address and therefore should be controlled
by M=1 (though I would disagree), but if it's not an address, then I would
say it has to be other configuration information.

I don't think you can say that "other configuration information" means
"other configuration information, but not a prefix".

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 22 Nov 2011 11:40:01 +0100

As I've pointed out before, we leave it open to our customer, read "isp/telco" to decide what they want to do with this.  If they decide to ignore the flags, and just apply what they've config'd in the DHCPv6 client, then they can do this.  
When they decide to listen, O-flag set indeed means stateless client, so all options (including ia_pd, which is just an option as any other)

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[email-masked]
tel.: +32 3 443 65 90

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: dinsdag 22 november 2011 10:01
To: Frank Bulk
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

from Barbara:

> specs) as to what to do when M=O=0, or no received RA. Devices 
> compliant under the old requirement are still compliant under the new requirement.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Nov 2011 11:44:41 +0100

Lorenzo,

> How can you argue that IA_PD is not other configuration information? You could argue that a prefix is an address and therefore should be controlled by M=1 (though I would disagree), but if it's not an address, then I would say it has to be other configuration information.
> 
> I don't think you can say that "other configuration information" means "other configuration information, but not a prefix".

I think I've given umpteen reasons why we shouldn't couple M/O bits with PD already.
the O bit means _stateless_ DHCP. PD is stateful. please let's stop talking about the M/O bits. we have a solution to the DHCP storm problem within DHCP.

cheers,
Ole

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 22 Nov 2011 05:13:18 -0600

If a service provider wants his customers to get an IPv6 address then he
should send out an RA with O=1.  The service provider should be implementing
configurations on their PE that, based on the RFCs, will allow most of his
customers to get online.

Frank

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Tuesday, November 22, 2011 4:28 AM
To: [email-masked]
Cc: IPv6 Operations; Chris Donley
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

cheers,
Ole

---

From: Hans Liu <[email-masked]>
Date: Tue, 22 Nov 2011 19:24:20 +0800

How about the flow in TR-124i2? Doesn't that suggest a RS and
DHCP-Solicitation in parallel?  That's my problem!

Hans

On Tuesday, November 22, 2011, Mark Townsley <[email-masked]> wrote:
> Architectural arguments aside and more to running code, did we not hear
that there is equipment in the field already that *expects* home routers to
give up and send DHCPv6 even with no RA received? I think I have now heard
two cases, from two different vendors, where we have this expectation
today. Couple that with CE that send 3-4 RS and, if no RA received, start
sending DHCPv6 from two different large retail CPE vendors, and I worry
that cat is out of the bag on this one. "Conservative in what you send"
already lost the battle, and "liberal in what you accept" is having to make
up for it this time.

-- 
Instead of following the fashion, we lead it through.

---

From: Hans Liu <[email-masked]>
Date: Tue, 22 Nov 2011 19:28:32 +0800

On Tuesday, November 22, 2011, Wuyts Carl <[email-masked]>
wrote:
> As I've pointed out before, we leave it open to our customer, read
"isp/telco" to decide what they want to do with this.  If they decide to
ignore the flags, and just apply what they've config'd in the DHCPv6
client, then they can do this.
> When they decide to listen, O-flag set indeed means stateless client, so
all options (including ia_pd, which is just an option as any other)

I think we are talking about retail products here. For tender project, of
course we do customizations.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 22 Nov 2011 12:53:50 +0100

Yes, the entire context of 6204 and bis is around setting default behavior "out of the box". Of course a user or service provider can override whatever they like, but we need to know where square one is. 

- Mark

On Nov 22, 2011, at 12:28 PM, Hans Liu wrote:

> 
> 
> On Tuesday, November 22, 2011, Wuyts Carl <[email-masked]> wrote:
> I think we are talking about retail products here. For tender project, of course we do customizations. 
> 
> --

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 22 Nov 2011 10:10:47 -0500

> left up to the vendor to decide?

Yes. Left up to the vendor and other specs.
Basically, we're saying (with the proposed new language) that M=O=0 will
not produce predictable results from a "6204bis" CE router. M=O=0
becomes a "don't care" state in "6204bis" CE routers. "Don't care"
states are a perfectly valid and ok, IMO. So long as we have states
defined that do allow us to achieve desired predictable behavior.

Previously (under the original 6204 requirement) the access network
could be sure that a CE router would do DHCPv6 Solicit whenever it
received an RA. Under the new proposed requirement, the access network
can only be sure of the Solicit if it sets M=1 or O=1. Since I'm not
aware of any access network provider who was planning on setting M=O=0
in the RA while operating a DHCPv6 server that was ready and waiting for
any and all Solicits, this doesn't create a hardship on access networks.
Even with the existing 6204 requirement, there was enough unease among
the access network guys (because of M/O history) as to whether the CE
routers would really do DHCPv6 if M=O=0, that they figured it was best
to always set one, the other, or both. It wasn't going to hurt anything,
and better safe than sorry. After all, there's nothing that says an
access network can't set M=O=1 and then only offer IA_PD. I haven't seen
anything that tells a device to go belly-up if it doesn't get offers
consistent with what it thinks M/O "promised". A provider could easily
do just IA_PD and set M=O=1, M=1/O=0, or M=0/O=1 and expect things to
work. According to either the current 6204 or the proposed 6204bis.
Please don't suggest that these bits can only be set if they are an
accurate representation of what is being offered. There's nothing
anywhere that says that.

So the access network still has a way to achieve the desired predictable
behavior. And the defined way is consistent with what the network
providers were planning on doing anyway.

Note that under the existing 6204 requirements, we already have some
"don't care" states defined. For example, if no RA is sent by the access
network, it cannot be predicted whether or not the "6204" CE router will
send a Solicit, anyway. This "don't care" (aka "fuzzy") state continues
to exist in the new 6204bis. So long as we have a well-defined way to
achieve the desired result, it's perfectly acceptable to have states
that produce unpredictable results.
Barbara

---

From: Wes Beebee <[email-masked]>
Date: Tue, 22 Nov 2011 10:15:06 -0500

> we're making it 'undefined'. is that what we really want?

Ole - 

We're allowing enough flexibility for BBF and CableLabs to do different
things with M=O=0 in their environments and still claim compliance with RFC
6204bis.  You would get rid of their flexibility?

- Wes

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Nov 2011 15:16:27 +0000

Barbara,

Fully with you on the analysis. What I don't get is what we are trying to
achieve with this change?

Cheers
Ole

---

From: Mark Townsley <[email-masked]>
Date: Tue, 22 Nov 2011 16:19:42 +0100

On Nov 22, 2011, at 12:24 PM, Hans Liu wrote:

> How about the flow in TR-124i2? Doesn't that suggest a RS and DHCP-Solicitation in parallel?  That's my problem!

I'll let the authors comment since they are here, but my understanding is that our current implementation tries RS 4 times and then falls back to DHCPv6 PD. For the "DHCP Storm" problem, this isn't much of a consolation.

- Mark

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 22 Nov 2011 10:34:16 -0500

We're trying to allow cable operators to do the things they want to do,
allow telco operators to do what they want, all while making sure that
the retail CE routers will work in either environment, without
overwhelming complexity. 

We're like the super committee trying to come up with a way to balance
the budget. Unless we're all willing to compromise and suffer shared
sacrifice, we're going to dig ourselves into a really deep hole. You
know you've got a reasonable compromise when nobody is completely happy
with the result, but most all reckon they can live with it. From my
perspective, this accurately describes the compromise we've defined.

Or as Dr. Phil asks, "Would you rather be right, or happy?" I'd rather
be happy.

Barbara

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Tuesday, November 22, 2011 10:16 AM
To: STARK, BARBARA H
Cc: Ole Troan; Frank Bulk; IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Barbara,

Fully with you on the analysis. What I don't get is what we are trying
to achieve with this change?

Cheers
Ole

On Tuesday, November 22, 2011, STARK, BARBARA H <[email-masked]> wrote:
>> CPE receives and RA with M=O=0, what is it supposed to do with
regards
>> to PD?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 22 Nov 2011 11:19:11 -0500

Yes, current TR-124i2 has RS and DHCPv6 Solicit in parallel. TR-124i2
RGs aren't defined for use in an MSO environment. They are defined to
meet the needs of DSL and PON (telco) providers.

The MSOs want the freedom to define their eRouters to not do DHCPv6 if
no RA is present or if RA has M=O=0. Both contingents want their devices
to be able to claim compliance to 6204(bis).

I don't think anybody is under the illusion that the proposed 6204bis
change will cause the number of CE routers to drop to zero, that are
operating on an MSO access network and that will do DHCPv6 every 2
minutes if there's no response. However, perhaps it is reasonable to
expect the number of such CE routers to drop to a manageable level, as a
result of this (6204bis) change.

As has been pointed out, it is possible to make access architecture
decisions, so that this CE router behavior does not bring the access
network to its knees. I would say that any provider who is procuring RGs
per TR-124i2 had best make sure that their access architecture can
tolerate the behavior of the CE routers that they are procuring to run
on their network.

If TR-124i2 requirements are causing problems for a particular operator,
there are options available: (1) modify or don't use TR-124i2
requirements when doing procurement of your RGs, and (2) in BBF, propose
a change to TR-124i2.

Barbara

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Tuesday, November 22, 2011 10:20 AM
To: Hans Liu
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

I'll let the authors comment since they are here, but my understanding
is that our current implementation tries RS 4 times and then falls back
to DHCPv6 PD. For the "DHCP Storm" problem, this isn't much of a
consolation.

- Mark

Hans

On Tuesday, November 22, 2011, Mark Townsley <[email-masked]> wrote:
> Architectural arguments aside and more to running code, did we not
hear that there is equipment in the field already that *expects* home
routers to give up and send DHCPv6 even with no RA received? I think I
have now heard two cases, from two different vendors, where we have this
expectation today. Couple that with CE that send 3-4 RS and, if no RA
received, start sending DHCPv6 from two different large retail CPE
vendors, and I worry that cat is out of the bag on this one.
"Conservative in what you send" already lost the battle, and "liberal in
what you accept" is having to make up for it this time.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 04:22:36 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Tuesday, November 22, 2011 5:45 AM
To: Lorenzo Colitti
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

>the O bit means _stateless_ DHCP. PD is stateful. please let's stop
talking about the M/O bits. we have a solution to the DHCP storm
>problem within DHCP.

I have said the same thing over and over again.  +1 to Ole's comments.
rfc6204bis should move forward with the MAX_SOL_RT solution to the
DHCPv6 server storm and please let's stop the M and the O bits
discussion.

Hemant

---

From: Ole Troan <[email-masked]>
Date: Wed, 23 Nov 2011 12:39:41 +0100

Barbara,

> We’re trying to allow cable operators to do the things they want to do, allow telco operators to do what they want, all while making sure that the retail CE routers will work in either environment, without overwhelming complexity.
>  
> We’re like the super committee trying to come up with a way to balance the budget. Unless we’re all willing to compromise and suffer shared sacrifice, we’re going to dig ourselves into a really deep hole. You know you’ve got a reasonable compromise when nobody is completely happy with the result, but most all reckon they can live with it. From my perspective, this accurately describes the compromise we’ve defined.
>  
> Or as Dr. Phil asks, “Would you rather be right, or happy?” I’d rather be happy.

I would be happier if we were reasonably certain we resolved the issues.
is there anything with the proposed solution in DHCP, that you don't think will make everyone equally unhappy?

without restarting the M/O bits, an RA there or not debate. cause that one we are not going to reach consensus on. didn't 10 years ago, didn't 5 years ago, didn't last year, don't now.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Nov 2011 12:52:14 +0000

On Nov 23, 2011, at 6:39 AM, Ole Troan wrote:
without restarting the M/O bits, an RA there or not debate. cause that one we are not going to reach consensus on. didn't 10 years ago, didn't 5 years ago, didn't last year, don't now.

I have come to believe that the reason we didn't achieve consensus on this was that we didn't have the right architecture, and in the architecture we had, the M and O bits didn't work.   I'm not convinced that, if we were to fix the architecture, the M and O bits wouldn't suddenly start to make sense.

---

From: Ole Troan <[email-masked]>
Date: Wed, 23 Nov 2011 14:02:40 +0100

Ted,

> I have come to believe that the reason we didn't achieve consensus on this was that we didn't have the right architecture, and in the architecture we had, the M and O bits didn't work.   I'm not co…

that's hard to argue against until you give us a proposed architecture.
having one configuration protocol depend on another configuration protocol before it can start? let's hope we don't invent yet another one. ;-)

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Nov 2011 13:17:12 +0000

On Nov 23, 2011, at 8:02 AM, Ole Troan wrote:
that's hard to argue against until you give us a proposed architecture.
having one configuration protocol depend on another configuration protocol before it can start? let's hope we don't invent yet another one. ;-)

The problem with DHCP and RA at present is that we don't have any knowledge of who we are listening to.   Suppose two routers send RAs on a wire.   Are they managed by the same organization, or different organizations?   Is there one DHCP server, or two?   Because we don't know which routers are in which provisioning domains, we have no way of telling whether we should treat the information from the two routers as indicative of the state of one provisioning domain, or two, and hence we have problems like flapping, where one router sets the M and O bits differently than the other, and we trigger DHCP state changes as a result.

If two routers have differing configurations, they are probably in different provisioning domains.   I'd like to see something in the RA that represents this information, so that we can tell, instead of having to guess.   I think if we did this, then M and O would actually work as originally intended, because the only time when M and O would disagree within a provisioning domain would be when the administrator had misconfigured the routers.

I'm not proposing that this is a complete architecture statement—it doesn't address the problem of multiple provisioning domains past the edge router—but I think that needs to be addressed in a similar way; even if there is only one router advertising both provisioning domains, the router advertisement needs to explicitly say that two provisioning domains are being advertised.

As far as DHCP goes, I think that if you have an advertised provisioning domain identifier in the RA, you can use it in DHCP as well, and this can be used to direct traffic appropriately.   If you get RAs from two separate provisioning domains, both of which indicate that you should do DHCP, then you originate two DHCP state machines, one for each provisioning domain.   Each state machine, when it sends a DHCP message, marks it with the provisioning domain identifier.   Hopefully the relay forwards such messages only to the DHCP server for that provisioning domain.

This prevents RA from breaking DHCP, and it allows DHCP to behave correctly in the multiple-provisioning-domain context, acquiring configuration information for each provisioning domain, rather than being forced to choose one or the other.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Nov 2011 09:02:01 -0500

> I have come to believe that the reason we didn't achieve consensus
> on this was that we didn't have the right architecture, and in the
> architecture we had, the M and O bits didn't work.  I'm not
> convinced that, if we were to fix the architecture, the M and O bits
> wouldn't suddenly start to make sense.

Classic problem with M/O bits: They were defined before we actually
had DHCP defined. I.e., we were guessing at what the bits would be
used for in the future, and we got it wrong.

If we could do it all over again, I would argue for:

 no M/O bits
 Every client always issues a DHCP request (and RS)
 No difference between address and non-address config
    request/protocol for DHCP
 Client always asks for config info, gets what the network operator
    has configured to send out, whether addresses or other stuff.
 mandate that clients do both DHCP/RAs

I.e., keep it simple/predictable for the client and operator both.

Thomas

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 23 Nov 2011 09:21:58 -0500

> I.e., keep it simple/predictable for the client and operator both.

Thomas, while there is a huge base deployed, all implementations already have to somewhat deal with this issue (mix dhcpv6+RA). So I wonder if it is, at the end, to better fix the architecture than having many conflicting RFCs or RFCs that slightly change one behavior after another to make it worst than fixing it all in one place. (however, that discussion should be held in 6man I guess.).

However, removing M/O bits won't help the "MIF problem" of how to merge config info received from multiple sources, that might or might not (and as Ted said: node does not know) come from same or different provisioning domains.

Marc.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 23 Nov 2011 15:49:09 +0100

IMVHO In short: the existence of AS boundaries is not fully reflected in 
some protocols.

Running those protocols over an administrative boundary may lead to 
problems.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2011 09:16:04 +1300

> I.e., keep it simple/predictable for the client and operator both.

Yes, that would have been nice. Cam we get there by making the recommendation
for the future exactly as above *except* that the first line would read
  ignore M/O bits
?

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 14:21:31 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Wednesday, November 23, 2011 3:16 PM
To: Thomas Narten
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

>  ignore M/O bits?

Which document do we add the new text to?  Node-req-bis would be one
choice?

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Nov 2011 12:17:05 +0900

On Tue, Nov 22, 2011 at 19:44, Ole Troan <[email-masked]> wrote:

> the O bit means _stateless_ DHCP. PD is stateful.

If you want to make the assertion that O means "stateless DHCPv6", you'll
have to find an RFC that says so. If you don't, then O means "other
configuration information" as stated in RFC 4861.

If you want to say that a CE router should ignore the M/O bits entirely,
sure. But you can't decide to use them and then say that PD should be
controlled by the M bit, or that PD shouldn't be controlled by either bit,
because that doesn't make any sense given how the bits are defined.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Nov 2011 03:23:51 +0000

On Nov 23, 2011, at 10:17 PM, Lorenzo Colitti wrote:
If you want to make the assertion that O means "stateless DHCPv6", you'll have to find an RFC that says so. If you don't, then O means "other configuration information" as stated in RFC 4861.

Strictly speaking, the M bit means "stateful."   The O bit doesn't mean "stateless," although it's only interesting when the M bit isn't set (and, hence, address configuration is stateless).

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Nov 2011 12:33:22 +0900

On Thu, Nov 24, 2011 at 12:23, Ted Lemon <[email-masked]> wrote:

>   If you want to make the assertion that O means "stateless DHCPv6",
> you'll have to find an RFC that says so. If you don't, then O means "other
>  Strictly speaking, the M bit means "stateful."   The O bit doesn't mean
> "stateless," although it's only interesting when the M bit isn't set (and,
> hence, address configuration is stateless).
>

Where is the text that says that M indicates stateful DHCPv6? I only see
text that says that M indicates managed address configuration.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Nov 2011 03:39:32 +0000

On Nov 23, 2011, at 10:33 PM, Lorenzo Colitti wrote:
Where is the text that says that M indicates stateful DHCPv6? I only see text that says that M indicates managed address configuration.

Yes.   Managed means stateful, unless you can give me an example of a stateless management process.   :)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Nov 2011 12:47:06 +0900

On Thu, Nov 24, 2011 at 12:39, Ted Lemon <[email-masked]> wrote:

> Yes.   Managed means stateful,
>

What you're saying is not "managed means stateful", it's "managed implies
stateful". Other configuration information could also be stateful, right?

> unless you can give me an example of a stateless management process.   :)
>

An example is a deterministic management process, where, if given MAC
address asks for an IP address, it gets the same IP address until the end
of time (or until the network is decommissioned).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Nov 2011 03:57:33 +0000

On Nov 23, 2011, at 10:47 PM, Lorenzo Colitti wrote:
An example is a deterministic management process, where, if given MAC address asks for an IP address, it gets the same IP address until the end of time (or until the network is decommissioned).

I think you are splitting hairs.   That would be identical to SLAAC, only without DAD, so it's not only useless, but harmful.   In practice, managed is stateful.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Nov 2011 04:04:18 +0000

On Nov 23, 2011, at 10:57 PM, Ted Lemon wrote:
I think you are splitting hairs.   That would be identical to SLAAC, only without DAD, so it's not only useless, but harmful.   In practice, managed is stateful.

Also, if you agree that the M bit means 'managed,' then you pretty much have to agree that it's what signals PD, because PD is quite clearly managed, whether you believe it's stateful or not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Nov 2011 14:46:15 +0900

On Thu, Nov 24, 2011 at 13:04, Ted Lemon <[email-masked]> wrote:

> I think you are splitting hairs.   That would be identical to SLAAC, only
> without DAD, so it's not only useless, but harmful.   In practice, managed
> is stateful.
>
>  Also, if you agree that the M bit means 'managed,' then you pretty much
> have to agree that it's what signals PD, because PD is quite clearly
> managed, whether you believe it's stateful or not.
>

The point I'm trying to make is that it doesn't matter what I believe, it
matters what the RFC says. The RFC says "managed address configuration". So
if it's not managed, and it doesn't involve addresses, it's not covered by
the M bit.

The fact that PD is managed doesn't mean it has to be covered by the M bit.
Everything given via DHCPv6 is managed - that's what DHCPv6 is for.

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Nov 2011 09:12:00 +0100

Lorenzo,

> What you're saying is not "managed means stateful", it's "managed implies stateful". Other configuration information could also be stateful, right?
>  

rat-hole alert. can we get back to the problem we're trying to solve?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Nov 2011 23:38:59 +0000

On Nov 24, 2011, at 12:46 AM, Lorenzo Colitti wrote:
The point I'm trying to make is that it doesn't matter what I believe, it matters what the RFC says. The RFC says "managed address configuration". So if it's not managed, and it doesn't involve addresses, it's not covered by the M bit.

The fact that PD is managed doesn't mean it has to be covered by the M bit. Everything given via DHCPv6 is managed - that's what DHCPv6 is for.

I think you were originally trying to make the point that the O bit is what signifies an interest in PD, but that's contrary to the intention of the working group at the time the spec was written.   The managed bit specifically refers to address allocation being managed.   PD is address allocation; hence, the managed bit signifies PD, not the Other bit.

In any case, if you look at section 12 of RFC3633, it specifically says that the requesting router is supposed to behave in the same way as described in RFC3315 for a client-initiated configuration exchange, which means that it has to do whatever a stateful DHCPv6 client would do, and _not_ what a stateless DHCPv6 client would do.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Nov 2011 10:03:17 +0900

On Fri, Nov 25, 2011 at 08:38, Ted Lemon <[email-masked]> wrote:

>  I think you were originally trying to make the point that the O bit is
> what signifies an interest in PD, but that's contrary to the intention of
> the working group at the time the spec was written.
>

What I'm trying to say that I think the current text of the spec says that
M = managed address configuration and O = other configuration, and that
unless you believe that a prefix is an address, DHCPv6 PD should not be
controlled by M.

I don't know what the intention was at the time the spec (which one are you
referring to?) was written, but if that was not the intention, then the
spec is poorly worded and we should fix it. That's all.

But yes, we're ratholing here.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Nov 2011 02:25:22 +0000

On Nov 24, 2011, at 8:03 PM, Lorenzo Colitti wrote:
What I'm trying to say that I think the current text of the spec says that M = managed address configuration and O = other configuration, and that unless you believe that a prefix is an address, DHCPv6 PD should not be controlled by M.

So despite the fact that RFC3633 explicitly states that the requesting router is supposed to follow the behavior specified in RFC3315, you think that we should do the opposite.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Nov 2011 16:30:59 +0900

On Fri, Nov 25, 2011 at 11:25, Ted Lemon <[email-masked]> wrote:

> So despite the fact that RFC3633 explicitly states that the requesting
> router is supposed to follow the behavior specified in RFC3315, you think
> that we should do the opposite.
>

What text are you referring to?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2011 08:28:13 +0000

> What text are you referring to?

Sections 11 and 12 of RFC3633.   These are the sum total of the text describing how requesting routers initiate configuration exchanges.   It's pretty clear that when Ralph wrote this he was saying "do what's done in RFC3315, only with IA_PD instead of IA_NA."   That's certainly what I remember him saying at the time.   However, there is an unfortunate degree of vagueness in the RFCs about this whole process.   I feel like we are debating different interpretations of Talmudic commentaries.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Nov 2011 17:42:25 +0900

On Mon, Nov 28, 2011 at 17:28, Ted Lemon <[email-masked]> wrote:

> Sections 11 and 12 of RFC3633.   These are the sum total of the text
> describing how requesting routers initiate configuration exchanges.   It's
> pretty clear that when Ralph wrote this he was saying "do what's done in
> RFC3315, only with IA_PD instead of IA_NA."   That's certainly what I
> remember him saying at the time.   However, there is an unfortunate degree
> of vagueness in the RFCs about this whole process.   I feel like we are
> debating different interpretations of Talmudic commentaries.
>

Agreed, the RFCs are vague. That said, what little they do say is in RFC
4861 (RFC 3633 doesn't mention router advertisements at all, except in the
background section), so I would say that's the place we need to look to see
what the semantics of the M and O bits should be.

Of course, if we want to change them or deprecate them (and have consensus
to do so) that's fine, but until we do, the meaning of the bits should be
as defined in RFC 4861, because they aren't mentioned anywhere else :-)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2011 08:50:13 +0000

On Nov 28, 2011, at 3:42 AM, Lorenzo Colitti wrote:
Agreed, the RFCs are vague. That said, what little they do say is in RFC 4861 (RFC 3633 doesn't mention router advertisements at all, except in the background section), so I would say that's the place we need to look to see what the semantics of the M and O bits should be.

Of course, if we want to change them or deprecate them (and have consensus to do so) that's fine, but until we do, the meaning of the bits should be as defined in RFC 4861, because they aren't mentioned anywhere else :-)

Right, but this is where we descend into Talmudic interpretation.   It's really clear to me that RFC3633 says "do what RFC3315 does," which means to me that requesting routers solicit prefix delegations under the same circumstances that DHCP clients solicit addresses.

You claim that RFC4861 says to do the opposite, because you claim that the M bit only applies to addresses, and a prefix delegation, despite being a range of addresses, is not an address, and therefore must be "other configuration information."

While I don't think the RFCs are crystal clear about this, your interpretation seems a bit surprising from my perspective as a DHCP protocol wonk who was around when RFC3633 was developed.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Nov 2011 17:55:35 +0900

On Mon, Nov 28, 2011 at 17:50, Ted Lemon <[email-masked]> wrote:

>  Of course, if we want to change them or deprecate them (and have
> consensus to do so) that's fine, but until we do, the meaning of the bits
> should be as defined in RFC 4861, because they aren't mentioned anywhere
> else :-)
>
>
> Right, but this is where we descend into Talmudic interpretation.   It's
> really clear to me that RFC3633 says "do what RFC3315 does," which means to
> me that requesting routers solicit prefix delegations under the same
> circumstances that DHCP clients solicit addresses.
>
>  You claim that RFC4861 says to do the opposite, because you claim that
> the M bit only applies to addresses, and a prefix delegation, despite being
> a range of addresses, is not an address, and therefore must be "other
> configuration information."
>
>  While I don't think the RFCs are crystal clear about this, your
> interpretation seems a bit surprising from my perspective as a DHCP
> protocol wonk who was around when RFC3633 was developed.
>

All I'm saying is that if you get a conflict between Talmudic
interpretation actual RFC text, then the actual text should take
precedence. It's all very well to say "this is what we meant to do do when
we designed it", but how is an implementer supposed to know this?

I think that if we're writing the standards, then we need to stand by the
standards that we write. :-) If we don't agree with them or we feel that
they're wrong, then we should change them. We can't just say "well, but
this is not what we intended when we wrote them".

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2011 08:57:45 +0000

On Nov 28, 2011, at 3:50 AM, Ted Lemon wrote:
While I don't think the RFCs are crystal clear about this, your interpretation seems a bit surprising from my perspective as a DHCP protocol wonk who was around when RFC3633 was developed.

To be clear, what I mean here is that if I were doing an implementation of an RFC3633 requesting router, the code I would write would depend on the M bit, not the O bit, based solely on reading RFCs.   It may be that you are correct, for some value of correct, but what matters is what implementors will do.   If we want implementors to do the right thing, the RFC should say _explicitly_ what to do, not leave it up to Talmudic interpretation.

BTW, we've digressed quite a bit from the original topic.   In case some people following this thread weren't aware, Ralph privately talked me out of my position that the MAX_SOL_RT option would create a denial of service opportunity.   If you still care about that debate, you might want to circle back.

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Nov 2011 10:12:08 +0100

Ted,

> To be clear, what I mean here is that if I were doing an implementation of an RFC3633 requesting router, the code I would write would depend on the M bit, not the O bit, based solely on reading RFC…

that's certainly _not_ the intention when we wrote 3633. where in section 6.2.7 of 4861 does it say a router should do anything with the M/O flags, apart from consistency checking them? 3633 is a protocol between _routers_.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Nov 2011 18:30:14 +0900

On Mon, Nov 28, 2011 at 18:12, Ole Troan <[email-masked]> wrote:

> that's certainly _not_ the intention when we wrote 3633. where in section
> 6.2.7 of 4861 does it say a router should do anything with the M/O flags,
> apart from consistency checking them? 3633 is a protocol between _routers_.
>

Section 6.2.7 of RFC 4861 doesn't say what nodes (either hosts or routers)
are supposed to do with the M and O flags. It only defines the meaning of
the flags.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2011 17:43:45 +0000

On Nov 28, 2011, at 4:12 AM, Ole Troan wrote:
that's certainly _not_ the intention when we wrote 3633. where in section 6.2.7 of 4861 does it say a router should do anything with the M/O flags, apart from consistency checking them? 3633 is a protocol between _routers_.

Interesting.   Of course, the requesting router isn't really a router until its request is satisfied.   Possibly it's a DHCP client that's only going to get an IA_NA.   But this is certainly a good point.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Nov 2011 10:58:28 +1300

Hemant,

> Which document do we add the new text to?  Node-req-bis would be one

No, let's have pity on that document. I think that the hermeneutics
of the M/O bits has come up in so many contexts that a stand-alone document
is needed. I am not volunteering.

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 22:30:16 -0600

Brian,

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 4:58 PM
To: Hemant Singh (shemant)
Cc: Thomas Narten; IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

>is needed. I am not volunteering.

Ok, I agree with you.

Thanks,

Hemant