Subject: RFC7084

From: Wuyts Carl <[email-masked]>
Date: Mon, 9 Dec 2013 14:01:39 +0000

All,

Not sure I should sent this one to DHCPv6 WG or the global IETF v6, so feel free to forward it if needed.

Last week, RFC7084 got posted.  I did already post a message on a rather badly phrased req (a SHOULD one regarding "long-enough", but bumped into the next one today (this one being a lot worse!!).

""
WAA-6:   If the IPv6 CE router receives a Router Advertisement
            message (described in [RFC4861]) with the M flag set to 1,
            the IPv6 CE router MUST do DHCPv6 address assignment
            (request an IA_NA option).
""
I'm not sure who came up with this one, but this is really a no-go.
So, according to this req, the DHCPv6 client must request an ia_na option if an M=1 is being received on his link ???  I might have understood it all wrong, but as far as I know, M=1 is not linked directly to ia_na, ia_pd is enough on its own, no ??  So, the CPE is expected to change its DHCPv6 client configuration based upon receiving an RA with this M=1 content ?
Extract from RFC4861:
""
M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol

""

I'm very curious on the replies now, but this seems really be going the wrong way.  You can launch a CPE which either listen to RA or not, and bound accordingly, however, listen + bind + force ia_na looks a bit too much to me.

regs
Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION

[email-masked]<mailto:[email-masked]>
tel.: +32 3 443 65 90
[Visit technicolor.com]<http://www.technicolor.com/> [Visit i-speak-qeo.com] <http://www.i-speak-qeo.com/>
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
www.technicolor.com<http://www.technicolor.com/> - www.i-speak-qeo.com<http://www.i-speak-qeo.com/>

[Follow Technicolor on Facebook]Facebook<http://www.facebook.com/TechnicolorCo>

[Follow Technicolor on Twitter]Twitter<http://twitter.com/TechnicolorCo>

[Follow Technicolor on YouTube]YouTube<http://www.youtube.com/technicolor>

[Follow Technicolor on LinkedIn]LinkedIn<http://www.linkedin.com/company/technicolor>

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

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 9 Dec 2013 15:02:06 +0000

RFC7084-compliant CE routers are defined to work in an environment where the access network makes the rules. RFC7084-compliant CE routers, by definition of the scope of that RFC, must be able to operate in the access networks defined by CableLabs and BBF, at the very least. These CE routers don't get to make the rules. The supported-for-interoperability access networks include ones that require IA_NA for proper operation. They also include ones that do "unnumbered" model and use only IA_PD. They even include access networks that support SLAAC + IA_PD (with no IA_NA). An RFC7084-compliant CE router will automatically work in all of these access networks, with no special configuration. This was a core goal of the requirements in RFC7084.

If an access network is designed to require CE routers to acquire IA_NA, then that CE router needs to acquire the IA_NA in order to function on that access network. This is not negotiable, and is not something the CE router can "choose" not to do because it doesn't feel like it. It was agreed that an access network that expects IA_NA to be requested will signal this by always setting M=1 in its RA messages. If the access network does not set M=1, it cannot be sure the CE router will request IA_NA. If it does set M=1, it *can* be sure the RFC7084-compliant CE router will request IA_NA.

What was agreed, was that CE routers MUST request IA_NA if M=1 in the RA. You are completely correct in your reading of the requirement. If the access network is designed so that IA_PD is enough, then it will not supply IA_NA in response to the CE router's request. Such access networks have no difficulty in not providing IA_NA.  If the access network is designed to require IA_NA, then it will supply the IA_NA in its response. Since nothing prevents the CE router from always requesting IA_NA, anyway, the access network has to be resilient in the presence of such requests. The CE router is able to work properly in both types of access networks.

There is nothing in the description of the "M" bit in RFC 4861 that would forbid designing an IPv6 host to always request IA_NA whenever it sees M=1. Therefore, this does not go against RFC 4861.
Barbara

From: ipv6 [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Monday, December 09, 2013 9:02 AM
To: <[email-masked]>
Subject: RFC7084

All,

""

""

regs
Carl Wuyts

---

From: Sander Steffann <[email-masked]>
Date: Mon, 9 Dec 2013 22:56:16 +0100

Hi Carl,

> Last week, RFC7084 got posted.  I did already post a message on a rather badly phrased req (a SHOULD one regarding “long-enough”, but bumped into the next one today (this one being a lot worse!!).
>  
> “”
> “”
> I’m not sure who came up with this one, but this is really a no-go.
> So, according to this req, the DHCPv6 client must request an ia_na option if an M=1 is being received on his link ???  I might have understood it all wrong, but as far as I know, M=1 is not linked directly to ia_na, ia_pd is enough on its own, no ??

Actually the other way around: M=1 is linked to ia_na but not to ia_pd. A CPE always does ia_pd, regardless of the M flag, but the ia_na is only requested when M=1.

>  So, the CPE is expected to change its DHCPv6 client configuration based upon receiving an RA with this M=1 content ?

Yep, that's the meaning :-)

> I’m very curious on the replies now, but this seems really be going the wrong way.  You can launch a CPE which either listen to RA or not, and bound accordingly, however, listen + bind + force ia_na looks a bit too much to me.

You always have to listen to RA, otherwise you won't have your default gateway. If you don't want a global address on the CPE WAN link (assuming that A=0 in the prefix option, but it doesn't have to be) you could ignore the M=1 flag and not do ia_na.

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Dec 2013 23:02:03 +0100

>> Not sure I should sent this one to DHCPv6 WG or the global IETF v6, so feel free to forward it if needed.

this is a product of the v6ops working group, so probably the discussion belongs there.

> Actually the other way around: M=1 is linked to ia_na but not to ia_pd. A CPE always does ia_pd, regardless of the M flag, but the ia_na is only requested when M=1.

the text is written so that there does not have to be any binding between RA processing and the DHCP state machine.
a CPE can simply ignore the O/M flags, and always request an IA_NA.

> Yep, that's the meaning :-)

or it can ignore it, see above.

> You always have to listen to RA, otherwise you won't have your default gateway. If you don't want a global address on the CPE WAN link (assuming that A=0 in the prefix option, but it doesn't have t…

cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Mon, 9 Dec 2013 23:14:11 +0100

Hi,

> a CPE can simply ignore the O/M flags, and always request an IA_NA.

Ah, good to know. I always interpreted the M flag as 'there is a stateful DHCPv6 server available'. I never really though about doing IA_NA when M=0, but I guess the client is always free to try :-)

Thanks,
Sander

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Dec 2013 15:07:41 +0900

On Tue, Dec 10, 2013 at 12:02 AM, STARK, BARBARA H <[email-masked]> wrote:

>  RFC7084-compliant CE routers are defined to work in an environment where
> the access network makes the rules. RFC7084-compliant CE routers, by
> definition of the scope of that RFC, must be able to operate in the access
> networks defined by CableLabs and BBF, at the very least. These CE routers
> don’t get to make the rules. The supported-for-interoperability access
> networks include ones that require IA_NA for proper operation. They also
> include ones that do “unnumbered” model and use only IA_PD. They even
> include access networks that support SLAAC + IA_PD (with no IA_NA). An
> RFC7084-compliant CE router will automatically work in all of these access
> networks, with no special configuration. This was a core goal of the
> requirements in RFC7084.
>
>
>
> If an access network is designed to require CE routers to acquire IA_NA,
> then that CE router needs to acquire the IA_NA in order to function on that
> access network. This is not negotiable, and is not something the CE router
> can “choose” not to do because it doesn’t feel like it. It was agreed that
> an access network that expects IA_NA to be requested will signal this by
> always setting M=1 in its RA messages. If the access network does not set
> M=1, it cannot be sure the CE router will request IA_NA. If it does set
> M=1, it **can** be sure the RFC7084-compliant CE router will request
> IA_NA.
>
>
Do these networks also support hosts plugging in directly?

Designing a network where DHCPv6 is a MUST would seem to me to be a
violation of the stated node requirements, where it is merely a SHOULD.

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 10 Dec 2013 06:55:16 +0000

Sorry Barbara,

But I still don't agree.
I read below:
""
If the access network does not set M=1, it cannot be sure the CE router will request IA_NA. If it does set M=1, it *can* be sure the RFC7084-compliant CE router will request IA_NA.
""
Again, you're binding WRONG the M to ia_na.  this is really not good.  Let us implement standards based upon what they are designed for.  The M-flag was initially designed to flag the device to be Managed, not to be "numbered" flag, in this case, make it N=1! If we keep bending all kind of rules for the sake of access networks, or whatever other reason, then let's just stop making standards completely, as they serve no goal.  If today one reads IPv6 RFCs, (s)he will never map M=1 to ia_na request or not, and this is how it should be.
So, why not just ask all options all together then ?  the access network can cope, and no matter what you ask, something will be served !!

Stop pleasing setting these silly requirements.  The "if prefix is too small" req was already very badly phrased, but this is a lot worse.
I hear on congresses that "the CPE router" is often a problem in v6 deployment, although not that much anymore recently, but please consider it as a mature device in the network, not let it bending all kind of rules for whatever sake.
Standards are defined for a reason, so let's all stick to it please, and not "tweaking" them for whatever reason.  If you want the CPE to ask ia_na, fine with me, but then create the statement to ask for it ALL the time, not just because of M=1 setting.

Please note we merely operate in a managed CPE-environment, so know upfront whether ia_na is needed or not, but you here state that the access network is dictating the M=1 to be translated by ANY CPE router as" ask ia_na.   this can only be handled by vendors by ALWAYS asking ia_na I'm afraid.  Please stop glueing things together which are not serving any real goal.  Keep it simple.  If you always want ia_na, fine with me, but make a req to just ask ia_na rather than to bind it to the wrong flag.

Just FYI.  A lot of our customers don't even use ia_na.  And yes, they are using M=1, nearly all of them.

Regs
Carl

From: ipv6 [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: maandag 9 december 2013 16:02
To: Wuyts Carl; <[email-masked]>
Subject: RE: RFC7084

From: ipv6 [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Monday, December 09, 2013 9:02 AM
To: <[email-masked]<mailto:[email-masked]>>
Subject: RFC7084

All,

""

""

regs
Carl Wuyts

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Dec 2013 08:10:27 +0100 (CET)

On Tue, 10 Dec 2013, Wuyts Carl wrote:

> Again, you're binding WRONG the M to ia_na.  this is really not good. 
> Let us implement standards based upon what they are designed for.  The 
> M-flag was initially designed to flag the device to be Managed, not to

>From RFC4861:

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

I interpret this as M=1 means addresses are available via DHCPv6, that 
means IA_NA and/or IA_PD, one or both might be available. I don't really 
understand why you do not. What do you think the M flag means? Reading the 
above text seems to indicate that you think it has something to do with 
managing the CPE?

> are using M=1, nearly all of them.

That's fine. The CPE should however ask for both, if the network doesn't 
give ia_na to it, then that's fine.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 10 Dec 2013 07:13:14 +0000

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: dinsdag 10 december 2013 8:10
To: Wuyts Carl
Cc: STARK, BARBARA H; <[email-masked]>; [email-masked]
Subject: RE: RFC7084

I interpret this as M=1 means addresses are available via DHCPv6, that means IA_NA and/or IA_PD, one or both might be available. I don't really understand why you do not. What do you think the M flag means? Reading the above text seems to indicate that you think it has something to do with managing the CPE?

[Carl] Correct, as you state and/OR, not AND only.  RFC7084 today says AND.

> are using M=1, nearly all of them.

That's fine. The CPE should however ask for both, if the network doesn't give ia_na to it, then that's fine.
[Carl] why ask for both ?  Why making diff between the 2 if you always ask for both ?  Why not asking all options and just wait and see what you get back ?

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Dec 2013 12:08:54 +0100

Hi Mikael,

> I interpret this as M=1 means addresses are available via DHCPv6, that means IA_NA and/or IA_PD, one or both might be available. I don't really understand why you do not. What do you think the M fl…

As far as I know the M flag is linked only to IA_NA. As far as I can see IA_PD is not linked to the M flag at all.

Cheers,
Sander

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 10 Dec 2013 13:34:52 +0000

Erik,

From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Kline
Sent: Tuesday, December 10, 2013 1:08 AM
To: STARK, BARBARA H
Cc: <[email-masked]>
Subject: Re: RFC7084

>Do these networks also support hosts plugging in directly?

Yes.  The host is a standalone CPE router.  The CPE is sitting behind a modem that bridges the RA of the access network to the CPE.  Thus the access network still controls the CPE behavior for DHCPv6 and IA_NA.

>Designing a network where DHCPv6 is a MUST would seem to me to be a violation of the stated node requirements, where it is merely a SHOULD.

DHCPv6 is also required for the CPE to acquire the IA_PD.   RFC 7084 does support the WAN interface being unnumbered (interface has only an IPv6 link-local address) or the WAN uses SLAAC to acquire its global IPv6 address(es).

Hemant

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Dec 2013 09:21:30 -0500

> [Carl] Correct, as you state and/OR, not AND only.  RFC7084 today says AND.

Am I the only one not understanding Carl's point? I would really like to 
understand...

> [Carl] why ask for both ?  Why making diff between the 2 if you always ask for both ?  Why not asking all options and just wait and see what you get back ?

As others previously explained, you're free to implement it that way if 
you prefer: do SLAAC and DHCPv6 simultaneously, and see what you get back.

If I was implementing a CPE, that's what I would do. I would completely 
ignore the M bit, and the SLAAC and DHCPv6 processes would be like ships 
in the night.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 10 Dec 2013 14:25:45 +0000

The thing to understand is that, imho:

M=1 should not be equal to force request ia_na.  And yes, our CPEs can do this perfectly, but no, this should not be enforced.  I'm just trying to stick as close as possible to standards, after all, what's the purpose of having separate options (ia_na and ia_pd)  if you're going to request both of them anyway ?

Regs
Carl

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: dinsdag 10 december 2013 15:22
To: [email-masked]
Subject: Re: RFC7084

Le 2013-12-10 02:13, Wuyts Carl a écrit :
>> Let us implement standards based upon what they are designed for.  
>> The M-flag was initially designed to flag the device to be Managed, 
>> not to
>
>  From RFC4861:
>

Am I the only one not understanding Carl's point? I would really like to understand...

> [Carl] why ask for both ?  Why making diff between the 2 if you always ask for both ?  Why not asking all options and just wait and see what you get back ?

As others previously explained, you're free to implement it that way if you prefer: do SLAAC and DHCPv6 simultaneously, and see what you get back.

If I was implementing a CPE, that's what I would do. I would completely ignore the M bit, and the SLAAC and DHCPv6 processes would be like ships in the night.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Dec 2013 09:28:16 -0500

Le 2013-12-10 09:25, Wuyts Carl a écrit :
> M=1 should not be equal to force request ia_na.

What should M=1 mean then?

> what's the purpose of having separate options (ia_na and ia_pd)  if you're going to request both of them anyway ?

The answer to that seems simple to me: an end host would never request 
IA_PD. Only routers would.

Simon

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 10 Dec 2013 14:29:58 +0000

M=1 equals Managed flag = request ia_na or/and ia_pd.
Please note a router is also acting as host.

Regs
Carl

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: dinsdag 10 december 2013 15:28
To: Wuyts Carl; [email-masked]
Subject: Re: RFC7084

> what's the purpose of having separate options (ia_na and ia_pd)  if you're going to request both of them anyway ?

The answer to that seems simple to me: an end host would never request IA_PD. Only routers would.

Simon

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Dec 2013 15:58:52 +0100

Carl,

> Please note a router is also acting as host.

that is wrong. the M-flag does not give a hint about prefix delegation.
the M flag is a hint from the network that stateful address assignment might be available.

cheers,
Ole

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 10 Dec 2013 15:01:26 +0000

Agree, but it does not mandate ia_na, does it ?

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: dinsdag 10 december 2013 15:59
To: Wuyts Carl
Cc: Simon Perreault; 6man WG
Subject: Re: RFC7084

Carl,

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Dec 2013 16:13:51 +0100

Carl,

> Agree, but it does not mandate ia_na, does it ?

it is a hint, but wouldn't it be quite silly of an implementation to not try to get an address with whatever method works?
(if I implemented a CPE I would ignore the M/O flags).

cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Dec 2013 16:32:46 +0000

> Designing a network where DHCPv6 is a MUST would seem to me to be a violation of the stated node requirements, where it is merely a SHOULD.

First I'll tackle the 2nd sentence. The node requirements (RFC6434 -- an informational RFC) define the most basic capabilities of what should be expected of an IPv6 node. There is no requirement anywhere that all networks must be designed to allow all nodes (that meet these basic requirements) to connect to them. It is also (IMO) a well-established practice that it's not ok to weaken a referenced RFC's requirements (changing MUST to SHOULD), but it is ok to strengthen them (SHOULD to MUST) when defining a specific subset of devices that are expected to go above and beyond that RFC's expectations. It's also (IMO) perfectly ok to define networks that only allow for connectivity by such a subset. The decision on whether or not to do that is generally based on whether it's possible to reasonably expect (or set expectations) that users of the network will understand and accept such limitations on the set of connectible hosts, and whether there's benefit or good reason to limit the set.

My approach in designing CE routers is that the LAN side of the router needs to allow for connectivity by the most basic RFC 6434 nodes. The RFC7084 LAN-side requirements are intended to accommodate this. That is because consumers (reasonably) expect that all their smart TVs, smartphones, PCs, tablets, NAS boxes, etc. will "just work" when they plug them in. The LAN side of the CE router needs to meet this expectation, or there will be trouble calls. 

Consumers (as a generalization) do not expect to be able to connect their smart TVs, tablets, etc. directly to any access network and have it just work. Very rare is the access network where this works. Therefore, this is a well-set expectation limit and service providers consider it ok for access networks to have tighter expectations and not support connectivity by any RFC6434 node. This does not result in trouble calls. In fact, by having tighter expectations, trouble calls are reduced. When the company I worked for 10 years ago started shipping really basic DSL modem/routers to all customers and stopped offering DSL PCI cards, DSL USB modems, PPPoE PC clients or bridged DSL modems, trouble calls with installation went down dramatically. 

So now I'll answer the first question. Instead of interpreting the question literally (yes, a RFC7084 CE router is also a host and can plug in directly, therefore there exist hosts that can plug in directly), I'm going to interpret the question as "Do these networks also support *all RFC6434-compliant* hosts plugging in directly?" 
No. They do not. I can't speak to the CableLabs-defined access networks, but BBF TR-177 access networks are only defined for connectivity by DHCPv6-capable hosts.
From TR-177:
"The main focus of TR-177 is on following scenarios:
 - a subscriber having a routed RG. This RG can be connected to the access loop either directly
or through a bridged RG. The routed RG acts as a Requesting Router (as per RFC 3633), and
possibly embeds DHCPv6-based address allocation capabilities.
 - a subscriber having a bridged RG, in which case the first hop router for their hosts is the
BNG. The subscriber hosts support DHCPv6 address allocation capabilities."

Some service provider instantiations of TR-177 access networks probably won't even support all RFC7084-compliant CE routers, because those service providers require customers to use the provider-provided routers. For those who are upset by this statement: Please don't see my saying this as my having any sort of emotional attachment to this practice or recommending it. I'm just saying it because it is an accurate statement that may be useful to understand. It is what it is.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2013 11:51:41 -0500

> As far as I know the M flag is linked only to IA_NA. As far as I can see IA_PD is not linked to the M flag at all.

There is no agreement on what the M and O bits do.   Some people think M means stateful address management; some think M means IA_NA and O means IA_PD.   RFC 4861 is actually fairly clear, at least to my reading of it, that "M" means IA_NA and IA_PD, and that "O" means stateless DHCPv6, but I've heard people argue vehemently that "M" means _only_ IA_NA, and that "O" means IA_PD, because prefixes aren't addresses.

So if you believe my reading of RFC 4861, you would set 'M' and expect the HG to get both IA_NA and IA_PD; RFC 7084 makes it clear that _either_ the 'M' or 'O' bit being set triggers the HG to do prefix delegation.

So if you want to do prefix delegation and not stateful address assignment, set the 'O' bit and _not_ the 'M' bit, even though that contradicts what RFC 4861 says.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Dec 2013 17:55:45 +0100

Hi Ted,

> So if you want to do prefix delegation and not stateful address assignment, set the 'O' bit and _not_ the 'M' bit, even though that contradicts what RFC 4861 says.

What a mess...
Sander

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Dec 2013 18:14:56 +0100

Ted,

> There is no agreement on what the M and O bits do.   Some people think M means stateful address management; some think M means IA_NA and O means IA_PD.   RFC 4861 is actually fairly clear, at least…

that's incorrect. there are no flags in the RA that indicates if prefix delegation is available or not.
prefix delegation is between routers, routers don't listen to RAs was the rationale.

> So if you believe my reading of RFC 4861, you would set 'M' and expect the HG to get both IA_NA and IA_PD; RFC 7084 makes it clear that _either_ the 'M' or 'O' bit being set triggers the HG to do p…

a RFC6204 CPE must act as a requesting router and request IA_PD in all cases.
it may choose to request the IA_NA based on the M flag or it might do so regardless, both
approaches are fine.

> So if you want to do prefix delegation and not stateful address assignment, set the 'O' bit and _not_ the 'M' bit, even though that contradicts what RFC 4861 says.

no, that's not what these flags mean.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 10 Dec 2013 18:17:01 +0100

> As far as I know the M flag is linked only to IA_NA. As far as I can see IA_PD is not linked to the M flag at all.

The IA_PD should be linked to a requirement that has to do more with
Routers at the Edge in general, and just in particular to CPE.

Any Router at the Edge that needs to self-configure has no cleaner[*]
alternative to using DHCP-PD, in addition to DHCP and/or SLAAC for address.

Examples of Routers at the Edge: CPE, homenet Routers, smartphone
hotspots, Mobile Routers as deployed in e.g. vehicles, road-side units,
etc. All could benefit from IA_PD.

This requirement is surprisingly present in the IPv6 cellular hosts RFC
(although this a Router), and surprisingly absent from the IPv6 Node
Requirements RFC (although a Node could be a Host or a Router sometimes).

Alex
[*]: for some value for 'clean'.
Alternatives include 64share, IPv6NAT, NPT, ND-PD, NAT64, 6to4,
IPv6transition...

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

---

From: Owen DeLong <[email-masked]>
Date: Tue, 10 Dec 2013 09:30:33 -0800

My understanding from reading the various documents is that M = IA_NA, O= everything else. Further, if M=1, O doesn’t really matter.

In no case do I believe that M or O provide any indication about IA_PD.

I agree that it makes no sense for an HG (among others) not to do IA_PD.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2013 12:40:18 -0500

> In no case do I believe that M or O provide any indication about IA_PD.

You should read RFC 7084 again, then.

Standards say what they say, not what you think they should say!   :)

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Dec 2013 18:44:44 +0100

> Standards say what they say, not what you think they should say!   :)

RFC7084 isn't a standard.
can we please stop this now. having the M/O debate one more time is unlikely to provide a different result than the previous times we have had this debate.

Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Dec 2013 23:38:26 +0000

I understand that Ole wants to end this discussion, but I think there were a few key points made.
 1. RFC6204 and RFC7084 both have WAA-6 that requires the CE router to request IA_NA when RA has M=1. This has been a CE router requirement for years now. Whether or not someone interprets M as also potentially meaning other things, it does not seem unreasonable (to me) for access networks to expect this of CE routers wanting to attach to them.

2. There is nothing in RFC6204 or RFC7084 that prohibits a CE router from always requesting IA_NA, no matter what M is, and no matter if there is even an RA. Both RFCs allow the CE router to always request IA_NA. Just (in RFC7084) not more frequently than SOL_MAX_RT, if it isn't assigned IA_NA.

3. WPD-4 changed from RFC6204 to RFC7084. RFC6204 required DHCPv6 to always occur and IA_PD to always be requested. RFC7084 backs off from this and only requires IA_PD to always be requested if M=1 or O=1.

4. There is nothing in RFC7084 that prohibits the CE router from always requesting IA_PD, no matter what (as in RFC6204). If IA_PD is simply always requested (with or without even waiting for RA), and an RA happens to appear with M=1 or O=1, the CE router has successfully met the RFC7084 WPD-4. If the RA never appears or has M=O=0, then the IA_PD request is still perfectly fine.

5. Since the CE router is still free to function as in RFC6204 WPD-4, this loosening of the requirement only really impacts CE routers that for some reason feel obligated or otherwise have a strong desire *not* to request IA_PD if M=O=0. For example, if the network operator they are developing CE routers for asks them to do this. [Note that BBF TR-124 requires the CE router always to request IA_PD and IA_NA, independent of whether an RA was received or what RA flags might be set, so a BBF TR-124 CE router cannot opt not to request when M=O=0; CableLabs eRouter may have different expectations, but that's not for me to say.]

6. The access network operator could be seen as being impacted by this change. Previously (under RFC6204), the network operator could assume the CE routers would always request IA_PD. [Under both RFCs, the network operator could only assume the CE router would request IA_NA if M=1. The CE router might go ahead and request IA_NA no matter what, but this couldn't be assumed.] The network operator who cared about IA_PD but not IA_NA could be completely unconcerned about the setting of RA M/O flags. But the reality is that all network operators who intend to send RA messages and provide IA_PD by DHCPv6 are setting either M=1 or O=1. So this didn't change anything for them and there's no real impact to them. 

The end effect is that some operators now have the freedom to ask their CE router vendors not to do DHCPv6 when the RA has M=O=0, and they can still claim compliance with RFC7084. And since BBF TR-124 didn't change, I think this might suggest that the desire for this change didn't come from operators who make use of BBF TR-124.
Barbara

---

From: Sander Steffann <[email-masked]>
Date: Wed, 11 Dec 2013 00:45:21 +0100

Hi Barbara,

> The end effect is that some operators now have the freedom to ask their CE router vendors not to do DHCPv6 when the RA has M=O=0, and they can still claim compliance with RFC7084. And since BBF TR-…

Thank you for this nice summary!
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 10 Dec 2013 17:05:18 +0000

> So if you want to do prefix delegation and not stateful address assignment, set the 'O' bit and _not_ the 'M' bit, even though that contradicts what RFC 4861 says.

<head spins>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 11 Dec 2013 01:58:54 +0000

> So if you want to do prefix delegation and not stateful address assignment, set the 'O' bit and _not_ the 'M' bit, even though that contradicts what RFC 4861 says.

This discussion is most enlightening. But I don't see any contradiction with RFC 4861.

It seems to me, RFC 4861 sets M=1 when a host can get the entire address ("it indicates that addresses are available"), from DHCPv6, emulating DHCPv4. At the same time, M=1 does not preclude any other information from being available, so of course prefixes may also be available. RFC 4861: "If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information."

Presumably, that would include a list of prefixes.

But RFC 4861 does not limit what "other" information is available when the O bit is set. One would certainly not expect full addresses to be available, since the M bit exists for that purpose, but RFC 4861 only gives a couple of examples of info available with O=1: "Examples of such information are DNS-related information or information on other servers within the network." This does not say that prefixes aren't available.

I don't see any contradiction here. If M=0 and O=1, the full address assignment isn't available in the DHCPv6 server. However, prefixes may well be.

I may want to prevent any host from sending packets through my edge router, unless the host uses IP addresses I assign. For that, I'd want to set M=1. If I don't care about specific addresses, if all I need is for clients to configure a routable address, then I set M=0 and O=1, and let the host choose the IID.

Take the case of a peer-peer network, sans DNS. In that case, I need for hosts to use only a set of prescribed IP addresses, which I distribute via DHCPv6 and the Client Identifier Option. I'd set M=1 for that. The clients may choose to auto-configure their own routable addresses, and I would feel free to NOT route their packets.

Bert

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2013 21:00:40 -0500

> I don't see any contradiction here. If M=0 and O=1, the full address assignment isn't available in the DHCPv6 server. However, prefixes may well be.

That's certainly not an unreasonable assumption, but don't forget the per-prefix 'a' bit, which controls slaac...

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 11 Dec 2013 02:21:38 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Manfredi, Albert E
Sent: Tuesday, December 10, 2013 8:59 PM
To: Ted Lemon
Cc: <[email-masked]>
Subject: RE: [v6ops] RFC7084

>I may want to prevent any host from sending packets through my edge router, unless the host uses IP addresses I assign. For that, I'd want to set M=1. If I don't care about specific addresses, if all I need is for >clients to configure a routable address, then I set M=0 and O=1, and let the host choose the IID.

>Take the case of a peer-peer network, sans DNS. In that case, I need for hosts to use only a set of prescribed IP addresses, which I distribute via DHCPv6 and the Client Identifier Option. I'd set M=1 for that. The >clients may choose to auto-configure their own routable addresses, and I would feel free to NOT route their packets.

Agree.  Whether hosts on the CPE router LAN acquire address(es) via DHCPv6 or SLAAC, or any other means, the CPE router can support a unicast RPF (uRPF) feature that will drop packets received on a LAN interface if the uRPF check fails. 

Hemant

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Dec 2013 01:21:58 -0500

On Dec 10, 2013, at 12:14 PM, Ole Troan <[email-masked]> wrote:
> that's incorrect. there are no flags in the RA that indicates if prefix delegation is available or not.   prefix delegation is between routers, routers don't listen to RAs was the rationale.

It's certainly true that RFC 4861 doesn't mention prefix delegation, and this is a plausible rationale for not doing so.   However, the HG is clearly a router, and it's being required to listen to RAs, so the distinction you are making is _extremely_ artificial.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Dec 2013 10:45:32 +0100

Le 10/12/2013 18:44, Ole Troan a écrit :
> RFC7084 isn't a standard. can we please stop this now. having the M/O
> debate one more time is unlikely to provide a different result than
> the previous times we have had this debate.

I agree we should go past the typical M/O debate, learn from it.

One way I read the ongoing discussion, if I am not wrong, is that there
is difficulty created by the lack of a flag specific to IA_PD ("As far
as I know the M flag is linked only to IA_NA. As far as I can see IA_PD
is not linked to the M flag at all.").

Am I the only to read this as maybe a hint towards necessity of creation
of a new flag akin to M/O but specific to IA_PD? I.e. it would be allow
a Router to see whether it may be able to specifically request a
Delegated Prefix even when it would self-configure its address by other
means than DHCP.

(in the past some local thought was given about how RA would advertise a
capability of delegating prefixes, e.g. this 'D' flag in a draft:

>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |     Code      |           Checksum            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Cur Hop Limit |M|O|H|Prf|P|D|r|        Router Lifetime        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
)

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Dec 2013 11:04:33 +0100

> M=1 equals Managed flag = request ia_na or/and ia_pd.

How about a new 3rd flag?

> Please note a router is also acting as host.

YEs and no.

YEs in that it may act as a DHCP Client (which is typically a Host).

No in that, e.g., the link-scoped multicast groups are different among 
Routers and Nodes (Node being an additional quirk).

Alex

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 11 Dec 2013 10:04:34 +0000

Although I agree that asking address info whatever flag-settings, i.e. ignoring the flag, is not a bad approach to get things up and running from time-to-time.  On the other hand, it is a pitty that we just can't use them of course, i.e. use them where they are designed for.
Next to that, I don't agree that "trying to get an IP address (i.e. ia_na, not meaning ia_pd)"  all the time is often ok.  Reason is that the majority of our customer base is not numbering the WAN-link through ia_na nor slaac.  Although pd_excluce with ia_na is a nice extra thing to number them in a "clean" way.

Thx for the responses.  
Carl

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: dinsdag 10 december 2013 16:14
To: Wuyts Carl
Cc: Simon Perreault; 6man WG
Subject: Re: RFC7084

Carl,

cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Wed, 11 Dec 2013 19:08:44 +0900

> Delegated Prefix even when it would self-configure its address by other

I'm not sure I understand how's that materially different/better than
a node just trying to request a PD if it wants one, and coping with
the response (whatever it may be), like it does today.

I think at best you'd end up saving a few unnecessary packets per
device per uptime cycle.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Dec 2013 11:21:06 +0100

Le 11/12/2013 11:08, Erik Kline a écrit :
>> Am I the only to read this as maybe a hint towards necessity of
>> creation of a new flag akin to M/O but specific to IA_PD? I.e. it
>> would be allow a Router to see whether it may be able to
>> specifically request a Delegated Prefix even when it would
>> self-configure its address by other means than DHCP.
>
> I'm not sure I understand how's that materially different/better
> than a node just trying to request a PD if it wants one, and coping
> with the response (whatever it may be), like it does today.

Well, as you suggest below, it may save some bytes on the wire, i.e.
would not send the expensive Solicit if the preceding RA said no PD
available.

I suppose this is the same reason of presence of other flags in the RA,
like the H (HMIPv6) and P (PMIPv6).

Alex

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 11 Dec 2013 10:20:14 +0000

Hi Barbara,

Nice summary indeed, however, as Ole mentioned already before, not ok for the WPD-4 req.  The rest is negotiable I'd say, we can cope with those.

But WPD-4 is not ok, for the simple reason that O=1 means stateless.  You now mandate to ask IA_PD always, and that it won't harm to do this, but stateless = information request, hence no solicit, hence no IA possible to request.  This is clear form RFC4861, which is a standard, not informational.
In this case, it's just ignoring the flags, nothing more, nothing less, and always run the full solicit-... state machine.  Although this is a possible approach (to not listen I mean), this would make information-requests obsolete, so I'd say this is changing the standards on DHCPv6 too.
So, as Ole says, this has been changed wrongly form RFC6204.  So, imho, this should be corrected (and not for me nor company, we can ignore flags if needed, but for the sake of clearness and standardization).  It's already difficult to have the IPv6 enabled at customers (although improving lately of couse), so let's try to make things as clear as possible.  Telling them they can sent whatever they want in flags doesn't seem to contribute to this.

Tx and regs
Carl

---

From: Ray Hunter <[email-masked]>
Date: Wed, 11 Dec 2013 12:25:05 +0100

> It's certainly true that RFC 4861 doesn't mention prefix delegation, and this is a plausible rationale for not doing so.   However, the HG is clearly a router, and it's being required to listen to…

Actually I happen to think the distinction between labeling a _device_
as a "router" or an "end node" is itself artificial.

There are plenty of functions where a typical CPE device has to function
as an end node (basically for anything where it is terminating traffic).

I think it would be better to make the distinction between "router" and
"end node" based on whether the _traffic_ is being forwarded by the
device or terminated on the device.

Then for PD and SLAAC autoconfig you would have an end node that could
learn a default route or upstream interface GUA prefix via RA, and more
specific information via a routing protocol.

-- 
Regards,
RayH

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 11 Dec 2013 15:02:22 +0000

> But WPD-4 is not ok, for the simple reason that O=1 means stateless.  

Per RFC4861 "When set, it [the O flag] indicates that other configuration information is available via DHCPv6."
The word "stateless" is not present. As has been discussed, the word "addresses" in the M-flag definition is interpreted differently by different people, and some think it includes prefixes and some don't. My interpretation of "other" in the O-flag definition is everything other than "addresses". Therefore, I disagree that your interpretation of the words "addresses" and "other" is necessarily the only or the correct interpretation.

> You now mandate to ask IA_PD always, 

No, RFC6204 *previously* mandated always doing IA_PD. RFC7084 changes this by allowing IA_PD *not* to be requested when M=O=0. Note RFC4861 says "If neither M nor O flags are set, this indicates that no information is available via DHCPv6." For me, this is a fairly unambiguous statement. I'm not aware of multiple interpretations of "no information". Therefore, I see no problem with allowing providers who explicitly want their routers to interpret M=O=0 as meaning "don't do DHCPv6, because there's no information available."

> and that it won't harm to do this, but
> stateless = information request, hence no solicit, hence no IA possible to
> request.  This is clear form RFC4861, 

I disagree with your interpretation of "other" == "stateless". These 2 words are neither equal nor equivalent. Therefore I disagree that your interpretation that "other" == "stateless" is somehow "clear" from RFC4861. 

> which is a standard, not informational.
> In this case, it's just ignoring the flags, nothing more, nothing less, and always
> run the full solicit-... state machine.  Although this is a possible approach (to
> not listen I mean), this would make information-requests obsolete, so I'd say
> this is changing the standards on DHCPv6 too.

No, it's not changing DHCPv6 standards and it's not obsoleting information-request. It does mean that a RFC7084 CE router will never send information-request. But RFC7084 has absolutely no influence on the vast majority of IP-capable devices.
BTW, I think it's also important to note that the service provider is free to set M=1 and then not offer IA_NA. Just because the CE router is going to ask for it, doesn't mean it has to be offered. So if you or anyone else wants to use M=1 to indicate availability of IA_PD without IA_NA, go for it. This will work.
Now if you want to design a CE router that doesn't do IA_PD when it has been statically configured with a prefix, that's fine, and it can still be an RFC7084 CE router, as long as it has the logic to request IA_PD either always or at the very least when M=1 or O=1 when no prefix is configured. The RFC7084 logic is not intended to prevent static configuration from being able to disable the capabilities it specifies.
Also, since RFC7084 is informational, there is absolutely no requirement that IETF places upon you to design a CE router per its guidance.

> So, as Ole says, this has been changed wrongly form RFC6204.  

I read Ole as saying that it was right to always request IA_PD, no matter the RA flags (the original RFC6204 language). I read you as saying that it's *not* right to request any stateful option if M=0 and O=1.  It seems like you would also then object to requesting stateful options when M=O=0, but I'm not clear if you think that. As I mentioned, the effect of the change is that it's now allowed not to do IA_PD when M=O=0. So your objecting to the change to me suggests that you believe there should be IA_PD when M=O=0. And it really confuses me as to the logic of "do IA_PD when M=O=0, but not when M=0 and O=1". In either case, you are disagreeing with Ole. I do not read Ole as saying that there should be no IA_PD when M=0 and O=1.

> So, imho, this
> should be corrected (and not for me nor company, we can ignore flags if
> needed, but for the sake of clearness and standardization).  It's already
> difficult to have the IPv6 enabled at customers (although improving lately of
> couse), so let's try to make things as clear as possible.  Telling them they can
> sent whatever they want in flags doesn't seem to contribute to this.

Since I don't see it as an error nor as causing any problems, I disagree. But if you want to create a draft proposing this and try to get support for your draft -- that is of course something you can do. I will not be in favor of changing this yet again. There were several ISPs who felt very strongly that they needed the freedom to specifically ask their CE routers (CE routers that meet not only RFC7084 but also their more specific requirements) not to do any DHCPv6 when they set M=O=0. They insisted on this change (allowing CE routers not to do any DHCPv6 when M=O=0) over Ole's objections. However, I think it's safe to say there was agreement among the authors that there is widespread disagreement regarding the precise DHCPv6 options implied by M and O bits. It is widely recognized that many people do not agree that O means "stateless".  Therefore, getting consensus that RFC4861 somehow forbids or mandates any particular client behavior in response to M or O flag values is, IMO, highly unlikely and will take someone really committed to getting rid of the current ambiguity. And as long as nothing is breaking (and I'm not convinced that http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-00 suggests a problem with these flags that's worth solving, especially in the context of RFC7084), then I don't see a real need to change RFC4861 or its flags. It's not yet clear to me that anything is really broken (in a way that will impact the average consumer). So I have no desire to spend effort fixing it.
Barbara

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 11 Dec 2013 15:26:51 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Wednesday, December 11, 2013 10:02 AM
To: Wuyts Carl; <[email-masked]>
Subject: RE: [v6ops] RFC7084

>And as long as nothing is breaking (and I'm not convinced that http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-00 suggests a problem with these flags that's worth solving, especially in the context of >RFC7084), then I don't see a real need to change RFC4861 or its flags. It's not yet clear to me that anything is really broken (in a way that will impact the average consumer). So I have no desire to spend effort fixing it.

Agreed.  I do not see any confusion with the M-, the O-, and the A-bits in RFC 4861 including any confusion with the bits and a CPE router operation.  I am a strong proponent of making protocols work with zero or least configuration variables.   Thus I too am not in favor of draft-ietf-v6ops-dhcpv6-slaac-problem-00 because I have yet to see a problem to be solved. 

Hemant

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Dec 2013 16:53:33 +0100

Le 11/12/2013 16:02, STARK, BARBARA H a écrit :
> Per RFC4861 "When set, it [the O flag] indicates that other
> configuration information is available via DHCPv6." The word
> "stateless" is not present. As has been discussed, the word
> "addresses" in the M-flag definition is interpreted differently by
> different people, and some think it includes prefixes and some
> don't.

I agree some times people mix address and prefix in common talk.

There is a multiple distinction to be made.

First, yes, an address configured on an interface must have a prefix
length (as in IPv4 it must have a subnet mask).  By language abuse, or
simple convenience, some say an address and prefix are configured by
SLAAC, when actually just an address is configured by SLAAC.  (the plen
of the configured address is actually obtained by a substraction
operation from a predefined length of Interface ID; the plen offered in
RA is not for forming an address, but for on-link determination of ND).

Second, there is a difference between the prefix advertised by RA, and a
delegated prefix.  The difference is the following:

The prefix advertised by RA is to be used on that link, or on other
links on the side of the router originating the RA; whereas the prefix
delivered by a Prefix Delegation operation must not be used on that
link, and should be used on other links on the side of the router
requesting this prefix.

(this second difference is so much missed by specifiers at 3GPP.)

Alex

---

From: Owen DeLong <[email-masked]>
Date: Wed, 11 Dec 2013 10:46:25 -0800

On Dec 11, 2013, at 1:45 AM, Alexandru Petrescu <[email-masked]> wrote:

> is not linked to the M flag at all.”).

> Delegated Prefix even when it would self-configure its address by other

I don’t see the need. A router which wants a prefix should ask for one.

The worst case is it doesn’t get an answer.

The next worst case is it is denied.

What is the benefit of having a flag to (sometimes) say that prefixes are
available for the asking?

> capability of delegating prefixes, e.g. this 'D' flag in a draft:

I wasn’t around for that discussion, but my guess would be that the discussion
likely came to the same conclusion I did… If you want a prefix, ask. A D flag
wouldn’t really improve anything.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 11 Dec 2013 10:51:18 -0800

> would not send the expensive Solicit if the preceding RA said no PD

I hardly think that an RS packet could legitimately be called “expensive”.

It’s a relatively small multicast datagram.

> like the H (HMIPv6) and P (PMIPv6).

As near as I can tell, those flags are for capabilities that are:

	1.	unlikely to be present on the majority of networks
	2.	would be much more difficult/expensive to negotiate without
		information in the RA.

The P flag isn’t alone in the RA, it’s also accompanied by a MAP option
in the RA that provides information about the MAP.

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 11 Dec 2013 20:33:53 +0100

Hi,

> Delegated Prefix even when it would self-configure its address by other

Yes.  A CPE does IA_PD, always, unless manually configured otherwise.

No need for a flag here.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Dec 2013 23:21:18 -0500

> the response (whatever it may be), like it does today.

The usual concern is that a bazillion devices all requesting PDs every so often adds up to a lot of traffic.   But since the existing spec doesn't forbid this, we're stuck with it.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Dec 2013 00:03:03 -0500

My reading of this discussion is that while we have a good (although
evolving) specification for the CPE devices in broadband situations,
we do not have a good specification for what the ISP is supposed to do.

The Broadband forum TR-187 (and TR-124) says a lot
  <http://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf>

(pages 19 onwards)

but it doesn't really say that much about how one picks SLAAC vs
DHCPv6/IA_NA, so nothing about M=1/O=1.

This discussion has been very useful to me, at least to clue me in that there
is something I should pay attention to, as I'm building ISP side product
right now.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Dec 2013 11:02:10 +0100

> The usual concern is that a bazillion devices all requesting PDs every so often adds up to a lot of traffic.   But since the existing spec doesn't forbid this, we're stuck with it.

then you're understanding of "usual" is different from mine. :-)
as far as I know this can only happen in very specific circumstances during transition.

we should be more concerned about this idea of using one protocol to provision another.
in this case ND to configure DHCP. is that a good design principle to follow?

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Dec 2013 12:08:50 +0100

Le 12/12/2013 11:02, Ole Troan a écrit :
>>> than a node just trying to request a PD if it wants one, and
>>> coping with the response (whatever it may be), like it does
>>> today.
>>
>> The usual concern is that a bazillion devices all requesting PDs
>> every so often adds up to a lot of traffic.   But since the
>> existing spec doesn't forbid this, we're stuck with it.
>
> then you're understanding of "usual" is different from mine. :-) as
> far as I know this can only happen in very specific circumstances
> during transition.
>
> we should be more concerned about this idea of using one protocol to
> provision another. in this case ND to configure DHCP. is that a good
> design principle to follow?

PRobably not.  Stated as such it would be too limiting (ND to help
running _just_ DHCP).

Maybe Radius as well.  The RA would just say that some means is
available to offer a delegated prefix, w/o saying which, without saying 
whether it is stateful or stateless, secure or insecure, etc.

Alex

> cheers, Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Dec 2013 12:15:24 +0100

Alexandru,

> available to offer a delegated prefix, w/o saying which, without saying whether it is stateful or stateless, secure or insecure, etc.

for what purpose?
would the CE behave any differently if the network advertised that PD was available or not?

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Dec 2013 13:13:26 +0100

> available for the asking?

Just as with addresses, it may be more reliable to configure prefixes by 
starting with a beacon announcing availability.

But yes, it's just another 'what if' case.

> wouldn’t really improve anything.

It was a local non-IETF discussion.

The later versions of that draft eliminated that D flag but I forgot 
why.  It may be as you say.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Dec 2013 13:17:03 +0100

Le 11/12/2013 19:51, Owen DeLong a écrit :
>>>> Am I the only to read this as maybe a hint towards necessity
>>>> of creation of a new flag akin to M/O but specific to IA_PD?
>>>> I.e. it would be allow a Router to see whether it may be able
>>>> to specifically request a Delegated Prefix even when it would
>> Well, as you suggest below, it may save some bytes on the wire,
>> i.e. would not send the expensive Solicit if the preceding RA said
>> no PD available.
>

Well, I meant DHCP Solicit, not RS.

The DHCP exchange would be 4 messages, not two, and spaced by
pre-programmed timers and repeats.

But yes, on today's fast and fat links with good DHCP implementations,
that may be negligible.

>> I suppose this is the same reason of presence of other flags in the
>> RA, like the H (HMIPv6) and P (PMIPv6).
>
> 1.	unlikely to be present on the majority of networks 2.	would be
> much more difficult/expensive to negotiate without information in the
> RA.
>
> The P flag isn’t alone in the RA, it’s also accompanied by a MAP
> option in the RA that provides information about the MAP.

(should the RA provide the delegated prefix as well to compare favorably
to the PMIP example? but again this is the 'what if' branch, deviating
from the main CPE discussion)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Dec 2013 13:18:06 +0100

> Yes.  A CPE does IA_PD, always, unless manually configured otherwise.

And is there agreement that manual configuration is best?

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Dec 2013 14:27:23 +0100

Hi,

> And is there agreement that manual configuration is best?

For non-default setups, certainly.  Default for CPEs needs to be "fully
automatic, with prefix delegation", unless it is known for sure that there
is no prefix delegation in that particular environment (like: the CPE
has no "LAN" links of any sort, by being a node with just a single network
interface, or being just a host without routing functionality).

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Dec 2013 11:05:47 -0800

> from the main CPE discussion)

I don’t think anyone really wants to move PD into RA. I think that would be inappropriate, personally.

Without moving the PD functionality into RA, then, I would say that the current situation is fine.

CPE should ask for PD if it wants a prefix.
It should deal with one of five possible results in response:

	1.	No response
	2.	Denial
	3.	Requested prefix size granted
	4.	Longer prefix (smaller net block) granted
	5.	Shorter prefix (larger net block) granted

Nobody has yet made a good case for why this behavior is problematic.

Owen

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Dec 2013 20:59:34 +0100

Hi,

> Nobody has yet made a good case for why this behavior is problematic.

We can't do it that way, because we don't do that in IPv4!!  Can't you
see?  And with DHCP-PD, we can't do NAT!

No, this wasn't a serious or useful statement, but half of the discussion
wasn't either.  Just to reinforce that.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Dec 2013 12:22:02 +0100

Le 12/12/2013 20:05, Owen DeLong a écrit :
> 1.No response

As one senses it, implementing it is not easy.

How would one implement the decision 'no response' other than waiting 
for one a certain amount of time?  That wait is what makes people think 
it takes too long, especially mobile people.

Alex

> 2.Denial
> 3.Requested prefix size granted
> 4.Longer prefix (smaller net block) granted
> 5.Shorter prefix (larger net block) granted
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Dec 2013 09:56:23 -0500

> then you're understanding of "usual" is different from mine. :-)

I mean "the concern that is usually raised."

> in this case ND to configure DHCP. is that a good design principle to follow?

It's a bit late to be asking that question.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Dec 2013 10:17:35 -0500

On Dec 13, 2013, at 10:06 AM, Nick Hilliard <[email-masked]> wrote:
> it's a legitimate question and has been asked by many people for as long as
> we've had working dhcpv6 implementations.

I didn't say it wasn't a legitimate question.   I said it's a bit late.   This does not mean we can't propose doing something about it, but bear in mind that the depths of that rathole have been extensively plumbed by previous efforts.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Dec 2013 15:06:45 +0000

Nick

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Dec 2013 07:49:24 -0800

On Dec 13, 2013, at 3:22 AM, Alexandru Petrescu <[email-masked]> wrote:

> How would one implement the decision 'no response' other than waiting for one a certain amount of time?  That wait is what makes people think it takes too long, especially mobile people.

Treat it as no response until you get one. Really, what are you going to do differently after you get denied a prefix (assuming a model of active denial like you suggest) than you can do while you’re waiting and haven’t yet received a prefix?

Either way, you have nothing to delegate to your subordinate networks.

---

From: Ole Troan <[email-masked]>
Date: Fri, 13 Dec 2013 17:01:41 +0100

Ted,

> It's a bit late to be asking that question.

I think it is most prudent. in that the IETF is in the process of standardising IPv6 protocol extensions to disable IPv4 (and vice versa),
and protocol extensions to IPv6 provisioning to enable IPv4 transport...

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Dec 2013 17:10:52 +0100

Le 13/12/2013 16:49, Owen DeLong a écrit :
>>>> (should the RA provide the delegated prefix as well to compare
>>>> favorably to the PMIP example? but again this is the 'what if'
>>>> branch, deviating from the main CPE discussion)
>>>
>>> CPE should ask for PD if it wants a prefix. It should deal with
>>> one of five possible results in response:
>>>
>>> 1.No response
>>
>> How would one implement the decision 'no response' other than
>> waiting for one a certain amount of time?  That wait is what makes
>> people think it takes too long, especially mobile people.
>
> Treat it as no response until you get one.

There is a problem in the until.

Until one gets an answer one can't decide whether or not there is
DHCP-PD available.  And if one does not have enough time to wait then
one would quickly decide there is no DHCP-PD available.

On another hand, frequent beacon telling precisely whether or not
DHCP-PD is available would lead to more informed decisions.

> Really, what are you going to do differently after you get denied a
> prefix (assuming a model of active denial like you suggest) than you
> can do while you’re waiting and haven’t yet received a prefix?

But there is a difference in being denied a particular prefix and DHCP
service absence altogether.

If the DHCP service is present, there are DHCP means to insist upon
being denied a particular prefix (requester another one, etc).

If the service is absent there is no reason to insist.

> Either way, you have nothing to delegate to your subordinate

Right.

If the network tells the node there is no DHCP service to look for, then
the node may decide to fall back into a 64share mode, or so.  This can
happen very quickly (it boils down to evaluating the probability of time
length between the random link up signal and the next periodic RA).

If on another hand the network does not tell the node whether DHCP is
present, then the node must emit a request and wait for a response.  If
it waits too short and decides there is no service DHCP, even if there
is one, then the subsequent decision to use 64share is a wrong decision.

That's why conservative DHCP discovery phases take long, and also that's
why conservative WiFi AP discovery clients take long, whereas quick such
clients often miss some important Access Point.

This distinction is even more important for entities which are mainly
mobile, doing frequent handovers.

(I guess it is also the reason why 802.11p removes altogether all
beaconing and discovery activities of 802.11bgn, and proposes a new
timestamp beacon - too long for essentially moving devices.)

Alex

>
>>
>> Alex
>>
>>> 2.Denial 3.Requested prefix size granted 4.Longer prefix
>>> (smaller net block) granted 5.Shorter prefix (larger net block)
>>> granted
>>>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Dec 2013 08:39:14 -0800

> There is a problem in the until.

Is there? What? What would you do differently with a deterministic no?

> one would quickly decide there is no DHCP-PD available.

Does it matter? What matters is that you don't have a prefix to delegate.

Again, I ask... What do you do differently with a deterministic no vs. a lack of information?

> DHCP-PD is available would lead to more informed decisions.

It would also lead to a number of other problems in many networks.

> service absence altogether.

If you have DHCP service present, then, you should get a denial response to IA_PD relatively quickly if you ask. The timeout should only apply to circumstances where there is no DHCP.

> being denied a particular prefix (requester another one, etc).

If the DHCP service is present, you should see an M or O bit in the RA. However, that shouldn't control whether you indicate your desire for a prefix or not.

> If the service is absent there is no reason to insist.

I'm not sure what you mean by insist in this context. I would agree that there is no reason to persist with alternative requests in the absence of a denial. That you should, instead, retry the same request until receiving an acknowledgement or a denial.

> length between the random link up signal and the next periodic RA).

Is there any reason not to use 64share mode until you receive a positive DHCP response?

> is one, then the subsequent decision to use 64share is a wrong decision.

No, it must emit a request. It does not have to wait for the response, the response can be processed asynchronously. I don't see the decision to use 64share is wrong so much as suboptimal. It's not at all invalid to use 64share until receiving the PD and then switch to the delegated prefix. If you want to provide a better user experience, 64share behavior can be preserved for some duration until early flows expire. Simply stop including 64share prefix in locally generated RAs and wait for valid timer to count down.

> clients often miss some important Access Point.

Discovering an AP has nothing to do with DHCP and has to happen well before the first piece of the DHCP process.

> mobile, doing frequent handovers.

If you're doing frequent handovers and they are changing your layer 3 topology frequently then you already have a number of other problems which go well beyond the difficulties you are describing here.

Most frequent handovers in the mobile world do not affect the layer 3 information.

> timestamp beacon - too long for essentially moving devices.)

Among other reasons.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Dec 2013 18:42:46 +0100

Le 13/12/2013 17:39, Owen DeLong a écrit :
>> DHCP-PD available.  And if one does not have enough time to wait
>> then one would quickly decide there is no DHCP-PD available.
>
>>> Really, what are you going to do differently after you get
>>> denied a prefix (assuming a model of active denial like you
>>> suggest) than you can do while you’re waiting and haven’t yet
>>> received a prefix?
>>
>> But there is a difference in being denied a particular prefix and
>> DHCP service absence altogether.
>
> If you have DHCP service present, then, you should get a denial
> response to IA_PD relatively quickly if you ask. The timeout should
> only apply to circumstances where there is no DHCP.
>
> If the DHCP service is present, you should see an M or O bit in the
> RA. However, that shouldn't control whether you indicate your desire
> for a prefix or not.

Well, I think I disagree.

Since the widespread SLAAC has no PD feature it's easy to consider that
a node would SLAAC its address and DHCP-PD its prefix for behind.  Or
DHCP its address and prefix.

But the M/O bits can't indicate to SLAAC address and DHCP-PD prefix.

> I'm not sure what you mean by insist in this context. I would agree
> that there is no reason to persist with alternative requests in the
> absence of a denial. That you should, instead, retry the same
> request until receiving an acknowledgement or a denial.
>
>> If the network tells the node there is no DHCP service to look
>> for, then the node may decide to fall back into a 64share mode, or
>> so. This can happen very quickly (it boils down to evaluating the
>> probability of time length between the random link up signal and
>> the next periodic RA).
>

Sure.  There are reasons to not use 64share altogether.  It does not
work on 4G links like CDC-Ethernet.  It has other drawbacks described in
a draft.

Instlaling 64share followed by a positive DHCP-PD Ack involves
renumbering the Host in smartphone's network, i.e. breaking their
ongoing communications (the prefix of 64share is different than the
prefix obtained by DHCP PD).

>> If on another hand the network does not tell the node whether DHCP
>> is present, then the node must emit a request and wait for a
>> response.  If it waits too short and decides there is no service
>> DHCP, even if there is one, then the subsequent decision to use
>> 64share is a wrong decision.
>
> No, it must emit a request. It does not have to wait for the
> response, the response can be processed asynchronously. I don't see
> the decision to use 64share is wrong so much as suboptimal. It's not
> at all invalid to use 64share until receiving the PD and then switch
> to the delegated prefix.

The smartphone may switch, but renumbering all the Hosts in smartphone's
hotspot?

> If you want to provide a better user experience, 64share behavior can
> be preserved for some duration until early flows expire. Simply stop
> including 64share prefix in locally generated RAs and wait for valid
> timer to count down.

I agree.  Althoug measuring how flows may expire may not be straightforward.

>> That's why conservative DHCP discovery phases take long, and also
>> that's why conservative WiFi AP discovery clients take long,
>> whereas quick such clients often miss some important Access Point.
>
> Discovering an AP has nothing to do with DHCP and has to happen well
> before the first piece of the DHCP process.

Hmmm... they have nothing to do (different layers).  Yes, link
association must happen before DHCP process.  Link association involves
a discovery phase.  Worse, the 3 can't be parallelized.

Their discovery algorithms work in the same way: their messages and core
data structures have similar semantics: ND's RS and DHCP's Request is
WiFi's Ass'n Request, ND's RA and DHCP's Reply is WiFi's Beacon, ND
cache and DHCP's cache is WiFi's preferred networks, etc.

>> This distinction is even more important for entities which are
>> mainly mobile, doing frequent handovers.
>
> If you're doing frequent handovers and they are changing your layer
> 3 topology frequently then you already have a number of other
> problems which go well beyond the difficulties you are describing
> here.

YEs, just to say they exacerbate this perspective.

> Most frequent handovers in the mobile world do not affect the layer

YEs, I agree.

I guess by most mobile world is meant smartphones on cellular links.
YEs, they are widely deployed and involve expensive business cases.

The good thing is thatthere's more to it than that: smartphones handing
over between wifi and cellular links, smartphones handing over from one
operator to another, bus train and roadside IP deployments, DMM
concepts, etc.

Alex

>>>>> (smaller net block) granted 5.Shorter prefix (larger net
>>>>> block) granted
>>>>>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Dec 2013 10:17:26 -0800

> Well, I think I disagree

Well...

> DHCP its address and prefix.

I suppose it is possible that someone would run a DHCP server strictly for PD and not offer up other configuration options to hosts (remember, O bit means ask DHCP for "other information"), so without the M bit, you shouldn't be expecting DHCP to provide an address.

> But the M/O bits can't indicate to SLAAC address and DHCP-PD prefix.

The O bit doesn't specifically indicate to ask for prefix, true. However, it does indicate that there is a DHCP server available and that other information should be requested from said DHCP server.

I would think that the rational thing to do in an environment where you want to provide DHCP-PD and not other information via DHCP (which is hard for me to imagine why, but let's ignore that for the moment) would be to advertise an O bit and then answer with empty or negative responses for non PD requests.

> work on 4G links like CDC-Ethernet.  It has other drawbacks described in

But it's not going to be any worse than what happens while you don't have a prefix.

> prefix obtained by DHCP PD).

I believe I discussed ways to mitigate this above.

> The smartphone may switch, but renumbering all the Hosts in smartphone's

Why not? They're no worse off than they would have been if they'd been stuck waiting for a DHCP response.

> I agree.  Althoug measuring how flows may expire may not be straightforward.

If you can't be sure the flows expired (easy with TCP, harder with other protocols), then you use the Valid timer and you're done.

> cache and DHCP's cache is WiFi's preferred networks, etc.

Perhaps that is because many years of research and experience has shown that these mechanisms work.

> operator to another, bus train and roadside IP deployments, DMM

Mobile is a tough problem to solve, to be sure. There's lots of work and optimization to be done in this area in the future. I'm still not convinced that adding a "PD available" flag to RA provides a benefit.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Dec 2013 22:27:18 +0100

On 13/12/2013 19:17, Owen DeLong wrote:
>>> If the DHCP service is present, you should see an M or O bit in
>>> the RA. However, that shouldn't control whether you indicate
>>> your desire for a prefix or not.
>>
>> Well, I think I disagree
>
> Well...
>
>> Since the widespread SLAAC has no PD feature it's easy to consider
>> that a node would SLAAC its address and DHCP-PD its prefix for
>> behind.  Or DHCP its address and prefix.
>
> I suppose it is possible that someone would run a DHCP server
> strictly for PD and not offer up other configuration options to
> hosts (remember, O bit means ask DHCP for "other information"), so
> without the M bit, you shouldn't be expecting DHCP to provide an
> address.
>
> The O bit doesn't specifically indicate to ask for prefix, true.
> However, it does indicate that there is a DHCP server available and
> that other information should be requested from said DHCP server.

Right, I missed this part.

> I would think that the rational thing to do in an environment where
> you want to provide DHCP-PD and not other information via DHCP
> (which is hard for me to imagine why, but let's ignore that for the
> moment) would be to advertise an O bit and then answer with empty or
> negative responses for non PD requests.

Right - reset M, set O and answer negatively to non-PD DHCP requests.

But how about when the Delegated Prefix is available,
but via 'other other' means than DHCP such as Radius, or via PPP?  There 
is no bit for that either.  The 'O' and 'M' bits apply only to DHCP.

It would be clearer if there were 1 bit for each of the fundamental 
addressing aspects (address, default route, delegated prefix, etc.) and 
each would be 'O' - Address available by other means than this RA, 
Default route available by other means than this RA, Delegated prefix 
available by other means than this RA, etc.

Alex

>>> I'm not sure what you mean by insist in this context. I would
>>> agree that there is no reason to persist with alternative
>>> requests in the absence of a denial. That you should, instead,
>>> retry the same request until receiving an acknowledgement or a
>>> denial.
>>>
>>>>  for, then the node may decide to fall back into a 64share
>>>> mode, or so. This can happen very quickly (it boils down to
>>>> evaluating the probability of time length between the random
>>>> link up signal and the next periodic RA).
>>>
>> Sure.  There are reasons to not use 64share altogether.  It does
>> not work on 4G links like CDC-Ethernet.  It has other drawbacks
>> described in a draft.
>

Right.

>>>> If on another hand the network does not tell the node whether
>>>> DHCP is present, then the node must emit a request and wait
>>>> for a response.  If it waits too short and decides there is no
>>>> service DHCP, even if there is one, then the subsequent
>>>> decision to use 64share is a wrong decision.
>>>
>>> response, the response can be processed asynchronously. I don't
>>> see the decision to use 64share is wrong so much as suboptimal.
>>> It's not at all invalid to use 64share until receiving the PD
>>> and then switch to the delegated prefix.
>>
>> The smartphone may switch, but renumbering all the Hosts in
>> smartphone's hotspot?
>
>>> If you want to provide a better user experience, 64share
>>> behavior can be preserved for some duration until early flows
>>> expire. Simply stop including 64share prefix in locally generated
>>> RAs and wait for valid timer to count down.
>>
> If you can't be sure the flows expired (easy with TCP, harder with
> other protocols), then you use the Valid timer and you're done.

I haven't seen this done elsewhere...

Alex

>>>> That's why conservative DHCP discovery phases take long, and
>>>> also that's why conservative WiFi AP discovery clients take
>>>> long, whereas quick such clients often miss some important
>>>> Access Point.
>>>
>>> Discovering an AP has nothing to do with DHCP and has to happen
>>> well before the first piece of the DHCP process.
>>
>> association must happen before DHCP process.  Link association
>> involves a discovery phase.  Worse, the 3 can't be parallelized.
>>
>> Their discovery algorithms work in the same way: their messages
>> and core data structures have similar semantics: ND's RS and
>> DHCP's Request is WiFi's Ass'n Request, ND's RA and DHCP's Reply is
>> WiFi's Beacon, ND cache and DHCP's cache is WiFi's preferred
>> networks, etc.
>
>>> If you're doing frequent handovers and they are changing your
>>> layer 3 topology frequently then you already have a number of
>>> other problems which go well beyond the difficulties you are
>>> describing here.
>>
>> I guess by most mobile world is meant smartphones on cellular
>> links. YEs, they are widely deployed and involve expensive
>> business cases.
>>
>> The good thing is thatthere's more to it than that: smartphones
>> handing over between wifi and cellular links, smartphones handing
>> over from one operator to another, bus train and roadside IP
>> deployments, DMM concepts, etc.
>
> Mobile is a tough problem to solve, to be sure. There's lots of work
> and optimization to be done in this area in the future. I'm still
> not convinced that adding a "PD available" flag to RA provides a
> benefit.
>
> Owen
>
>

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Dec 2013 14:01:19 -0800

> is no bit for that either.  The 'O' and 'M' bits apply only to DHCP.

There’s no support for this, nor do I think I would expect there to be support for this in RA.

In the cases of PPP and RADIUS, you are already having an authentication or other negotiation process with the server and I would presume that there would be mechanisms in those negotiations to handle this. For example, in RADIUS, the prefix(es) should be sent as additional attribute/value pairs. In PPP, I presume it would be part of the IPCP6 process, but I admit I haven’t looked at those details.

> available by other means than this RA, etc.

I don’t see the advantage to this way of approaching it. Please present a use case where this offers a clear advantage over the existing mechanisms which would warrant an incompatible modification to everyone else’s expectations and existing software. Absent a compelling advantage to such a change, I just don’t think the risk/reward proposition makes sesne.

> I haven't seen this done elsewhere…

The neighbor discovery RFC is pretty clear about it from my reading. What is unique in what I propose is that you stop resetting the client-side valid-time and desired-time timers when you receive a service-side RA that would normally result in resetting them. However, for renumbering the client side from 64share to delegated prefix, it seems to me that it is very reasonable to immediately poison the desired time and then withdraw the prefix from subsequent RAs. This will allow the clients to preserve their existing flows until the valid timer counts down to zero. The router can remove the prefix from the interface at time <t_last_ra_issued>+<valid_time_in_last_ra_issued>.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Dec 2013 23:39:34 +0100

On 13/12/2013 23:01, Owen DeLong wrote:
>>> I would think that the rational thing to do in an environment
>>> where you want to provide DHCP-PD and not other information via
>>> DHCP (which is hard for me to imagine why, but let's ignore that
>>> for the moment) would be to advertise an O bit and then answer
>>> with empty or negative responses for non PD requests.
>>
>> But how about when the Delegated Prefix is available, but via
>> 'other other' means than DHCP such as Radius, or via PPP?  There is
>> no bit for that either.  The 'O' and 'M' bits apply only to DHCP.
>
> There’s no support for this,

Well...

In addition to Radius and PPP, there are the migration v4-v6 mechanisms 
which may offer a v6 Delegated Prefix as well.

> nor do I think I would expect there to be support for this in RA.

But one _would_ expect RA to always be there.

> In the cases of PPP and RADIUS, you are already having an
> authentication or other negotiation process with the server and I
> would presume that there would be mechanisms in those negotiations to
> handle this. For example, in RADIUS, the prefix(es) should be sent as
> additional attribute/value pairs. In PPP, I presume it would be part
> of the IPCP6 process, but I admit I haven’t looked at those details.
>
>> It would be clearer if there were 1 bit for each of the
>> fundamental addressing aspects (address, default route, delegated
>> prefix, etc.) and each would be 'O' - Address available by other
>> means than this RA, Default route available by other means than
>> this RA, Delegated prefix available by other means than this RA,
>> etc.
>
> I don’t see the advantage to this way of approaching it. Please
> present a use case where this offers a clear advantage over the
> existing mechanisms which would warrant an incompatible modification
> to everyone else’s expectations and existing software. Absent a
> compelling advantage to such a change, I just don’t think the
> risk/reward proposition makes sesne.

I agree.

No particular use case.  This is on the 'what-if' branch.

Alex

>
>>> If you can't be sure the flows expired (easy with TCP, harder
>>> with other protocols), then you use the Valid timer and you're
>>> done.
>>
> The neighbor discovery RFC is pretty clear about it from my reading.
>  What is unique in what I propose is that you stop resetting the
> client-side valid-time and desired-time timers when you receive a
> service-side RA that would normally result in resetting them.
> However, for renumbering the client side from 64share to delegated
> prefix, it seems to me that it is very reasonable to immediately
> poison the desired time and then withdraw the prefix from subsequent
> RAs. This will allow the clients to preserve their existing flows
> until the valid timer counts down to zero. The router can remove the
> prefix from the interface at time
> <t_last_ra_issued>+<valid_time_in_last_ra_issued>.
>
> Owen
>

---

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Dec 2013 14:57:42 -0800

On Dec 13, 2013, at 2:39 PM, Alexandru Petrescu <[email-masked]> wrote:

> In addition to Radius and PPP, there are the migration v4-v6 mechanisms which may offer a v6 Delegated Prefix as well.

Examples, please?

> But one _would_ expect RA to always be there.

The ubiquitous presence of RA doesn’t mean that we should bloat those RAs with a bit for every conceivable possible choice of configuration mechanism that some person might want to use in some obscure application. Indeed, I would argue that it means quite the opposite, that we should be very judicious in what kind of bloat we stuff into RAs.

RDNSS had a pretty compelling case, IMHO. Short of an equally compelling case, I really don’t think it’s worth the tradeoffs.

> No particular use case.  This is on the 'what-if' branch.

What-ifs are all well and good, but if you want to create the kind of protocol upheaval that you are suggesting, then I think more than what-ifs are necessary. I think that would require a very compelling use case.

Owen

---

From: [email-masked]
Date: Sat, 14 Dec 2013 07:56:28 +0100 (CET)

> But one _would_ expect RA to always be there.

Not necessarily. Some of us would like to use DHCPv6 for this, and
be rid of RA. Yes, I'm very much aware that this isn't supported
today,

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 14 Dec 2013 12:40:59 +0100

On 13/12/2013 23:57, Owen DeLong wrote:
>
> On Dec 13, 2013, at 2:39 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>>>>> I would think that the rational thing to do in an
>>>>> environment where you want to provide DHCP-PD and not other
>>>>> information via DHCP (which is hard for me to imagine why,
>>>>> but let's ignore that for the moment) would be to advertise
>>>>> an O bit and then answer with empty or negative responses for
>>>>> non PD requests.
>>>>
>>>> 'other other' means than DHCP such as Radius, or via PPP?
>>>> There is no bit for that either.  The 'O' and 'M' bits apply
>>>> only to DHCP.
>>>
>> In addition to Radius and PPP, there are the migration v4-v6
>> mechanisms which may offer a v6 Delegated Prefix as well.
>
> Examples, please?

64rd for example.

And Prefix Delegation for Mobile IPv6 based on DHCPv6 over a tunnel.

And I guess IKE as well may provide a Delegated Prefix (just a guess).

> The ubiquitous presence of RA doesn’t mean that we should bloat those
>  RAs with a bit for every conceivable possible choice of
> configuration mechanism that some person might want to use in some
> obscure application.

I agree.

But I said just the fundamental addressing aspects, those common
parameters involved in most basic setups.

And, the bits wouldn't be tied to one particular protocol (DHCP) but to
any Other protocols.  The 'O's would mean any Other, not just any  Other
DHCP.

> Indeed, I would argue that it means quite the opposite, that we
> should be very judicious in what kind of bloat we stuff into RAs.

Right, bloat should be avoided.  This could be done by this Other word, 
and by the RA flags expansion option anyways (existing RFC).

> RDNSS had a pretty compelling case, IMHO. Short of an equally
> compelling case, I really don’t think it’s worth the tradeoffs.

I agree.

>>> authentication or other negotiation process with the server and
>>> I would presume that there would be mechanisms in those
>>> negotiations to handle this. For example, in RADIUS, the
>>> prefix(es) should be sent as additional attribute/value pairs. In
>>> PPP, I presume it would be part of the IPCP6 process, but I admit
>>> I haven’t looked at those details.
>>>
>>>> fundamental addressing aspects (address, default route,
>>>> delegated prefix, etc.) and each would be 'O' - Address
>>>> available by other means than this RA, Default route available
>>>> by other means than this RA, Delegated prefix available by
>>>> other means than this RA, etc.
>>>
>>> existing mechanisms which would warrant an incompatible
>>> modification to everyone else’s expectations and existing
>>> software. Absent a compelling advantage to such a change, I just
>>> don’t think the risk/reward proposition makes sesne.
>>
>> I agree.
>>
> What-ifs are all well and good, but if you want to create the kind of
>  protocol upheaval that you are suggesting, then I think more than
> what-ifs are necessary. I think that would require a very compelling
> use case.

I agree.

Alex

---

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 14 Dec 2013 16:11:05 +0000

> But how about when the Delegated Prefix is available, but via 'other other'
> means than DHCP such as Radius, or via PPP?  There is no bit for that either.
> The 'O' and 'M' bits apply only to DHCP.

PPP is at a lower layer than IP. PPP clients are specifically configured to establish PPP (with PPP login and password). Once PPP is established, the client can try to establish IPv6 per RFC5072. This uses IPV6CP to negotiate the interface identifier of the client's WAN interface, which can then be used to construct the IPv6 Link-local address of this interface.

RFC7084 references that PPP may be established below IP (WLL-2, WLL-3). Once that link-local address exists on the PPP link, the RFC7084-compliant CE router sets up the rest of IPv6 exactly as it does for IPv6 directly over Ethernet (with RS/RA [though it's ok for there to be no RA since default route is the PPP link; but try it anyway in case there's a SLAAC prefix], DHCPv6). This is also consistent with BBF TR-124. The goal was to minimize the number of different ways of doing the same thing that would need to be coded in a CE router.

I can't address networks that might do RADIUS directly from the CE router, because I'm not familiar with any such networks. BBF TR-177 and TR-187 do support using RADIUS in the access network, but the CE router doesn't know this. The access network can pick up the CE router's authentication parameters from access line identification information in the RS (inserted by the access node, and not the CE router) or from PPP. Since the CE router has no concept of RADIUS, it's not possible for it to do something different in response to RADIUS. I'd like to keep it this way.

I think it's very good that there are no special RA bits for PPP or RADIUS.
Barbara