Subject: RE: RA Option Guidelines

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 2 Apr 2015 19:07:01 +0000

Mark,

The stateless DHCPv6 server in RFC3736 allows for new options to be served by the stateless server.   Read the first paragraph of section 5.3 in RFC3736.  So the new options you want to serve can be served by the CE stateless DHCPv6 server.   Now, if the service provider configures his/her DHCPv6 server to return new options to the CE WAN interface address acquisition, the CE uses the options on the LAN.  See bullet L-12 of RFC 7084.  Existing RFCs support your use case and no dhcpv6 relay is required in the CE.

Barbara,

For your use case, the service provider configures the DHCPv6 server to only serve options specified in RFC 7084.  Thus in this deployment no extra options exist to serve to the CE router LAN.

Both use cases can be supported using existing RFC’s.

Hemant

From: Mark ZZZ Smith [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:52 PM
To: Hemant Singh (shemant); STARK, BARBARA H; Brian Haberman; [email-masked]
Subject: Re: RA Option Guidelines

Hi Hemant,

________________________________
From: Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>>
To: "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>; Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>; Brian Haberman <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 1 April 2015, 1:27
Subject: RE: RA Option Guidelines

Barbara,

Thanks for replying.

Mark,

If new DHCPv6 options are added to be supported by RFC3736, then the SP includes the new option in the DHCPv6 responses to the CPE WAN.  Then the CPE includes the new option to its LAN DHCPv6 clients.

/  So here is a scenario.

/ As an ISP, my customers have VoIP handsets that might support the OPTION_GEOLOCATION DHCPv6 option (I might know that a portion of them do, because they've bought those VoIP handsets from me). How long is it going to take for me to get that option added to an updated RFC3736 and RFC7084, to get my CPE vendor to update and release their firmware to support that option, and test that new CPE firmware and then to deploy that new firmware?

/ I think I'd be lucky if it only took 2 years.

/ A few months later I decide I want to provide OPTION_NEW_POSIX_TIMEZONE to my customers if their hosts request it. So now I have to try to get OPTION_NEW_POSIX_TIMEZONE added to the updated RFC3736, to get my CPE vendor to update and release their firmware to support that option, and test that new CPE firmware and then to deploy that new firmware.

/ Now if I'm lucky I could add it to the draft for OPTION_GEOLOCATION, so it is still "only" 2 years to get to a point where I could provide those options to my customers. But what if that draft has progressed too far though the IETF publishing process? I have to create a new draft updating the to be published draft.

/ So, to achieve what should be a simple task of providing location or timezone information to customers' end hosts if they want it, we've just incurred the massive costs and time delays of the IETF publishing process, vendor firmware upgrades, firmware testing and firmware deployment. Sounds like how hard I understand it was to roll out features like CLI in PSTN networks ...

 What is one option you'd like the host on the LAN to include so that we can understand your use case better?

/ I'm going to make the problem much harder for you. I want the CPE to "support" or better, be transparent to, all current and future DHCPv6 options, and I don't want to have to upgrade or ask my customers to successfully upgrade their CPE each and every time there is a new DHCPv6 option defined that might be useful to me and them. I want to be able to provide service parameters to my customers hosts, directly or indirectly, without the software revision or model of their CPE being the constraint.

The SIP server is already included as one option supported by RFC3736.  Certainly, if the SIP server support is needed in the RA, I am open for it since the RA already includes DNS information.

/ I don't think DNS in RAs was a good idea, and neither were SIP options when they were proposed. See that time consuming and service disrupting firmware upgrade cycle for new DHCPv6 options? Same problem if you use RA options to achieve the same goal. New firmware upgrade each time you want to support a new RA option.

/ Duplication between RA options and DHCPv6 options also causes more problems. Which is preferred? Are they treated equally or does one take precedence over the other? As far as I'm aware, these questions haven't been answered for the DHCPv6 DNS and RA DNS options yet. It might be simple to come up with a simple rule for more DHCPv6 options are duplicated into RAs, however their might be some specific cases where the RA option value should be preferred over the DHCPv6 equivalent option and vice-versa.

However, I still ask the question as to how an RA received at the WAN of the CPE has its options propagated to the RA on the LAN?  At the time of writing RFC 6204 or RFC 7084, there is no such provision between the RA received on the WAN and the RA issued on the LAN of the CE router.

/ Use a DHCPv6 relay in the CPE. Then there isn't a problem, new DHCPv6 options that are unknown by the CPE will pass right through it transparently. The only complication is when stateful DHCPv6 addressing is used on the CPE LAN interface, and I suggested a hybrid mode of operation for a DHCPv6 server in that draft which I think solves that problem.

Others,

Also, why does one need an RA Option Guideline?  RFC4861 specifies a TLV format and an option Type.  I don't see anything else needed if I need to specify a new RA option.

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:
  L-12:  The IPv6 CE router SHOULD make available a subset of DHCPv6
          options (as listed in Section 5.3 of [RFC3736]) received from
          the DHCPv6 client on its WAN interface to its LAN-side DHCPv6
          server.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 3 Apr 2015 02:19:06 +0000 (UTC)

Hi Hemant,

________________________________
 From: Hemant Singh (shemant) <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>; "STARK, BARBARA H" <[email-masked]>; Brian Haberman <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, 3 April 2015, 6:07
Subject: RE: RA Option Guidelines

Mark,
 
The stateless DHCPv6 server in RFC3736 allows for new options to be served by the stateless server.   Read the first paragraph of section 5.3 in RFC3736.

/ So there are a few reasons why I wouldn't come to that conclusion without some very careful reading:

/ - The explicitly identified set of required and optional DHCPv6 options that can be supported by a stateless DHCPv6 server

/ - The lack of any overt discussion that this set of required and optional DHCPv6 options are a minimum, and that further DHCPv6 options could be provided by a stateless DHCPv6 server if supported by the implementation, are appropriate and requested by the client. It being a minimum is subtly eluded to in a few sentences in the Abstract and the Introduction, however I think they could easily be missed. I'd expect that if this is the case, it is much clearer and obvious.

/ - I think text you refer to in 5.3, "Clients and servers use the following options to pass configuration information to clients; note that other options for configuration information may be specified in future Internet Standards:" reads to me like a later version of this RFC will specify more stateless DHCPv6 server supported options. A statement such as "Other additional DHCPv6 options appropriate for stateless DHCPv6 operation may be supported by an implementation." would make it much clearer that the supported options were up to the implementer once the minimum had been implemented.
/ So if I were implementing a stateless DHCPv6 server as per RFC3736, I'd think the implementation was complete when I had implemented the options specified. I wouldn't put any effort into making it also transparent to any options that weren't identified in RFC3736, as there is no text discussing that.
  So the new options you want to serve can be served by the CE stateless DHCPv6 server.   Now, if the service provider configures his/her DHCPv6 server to return new options to the CE WAN interface address acquisition, the CE uses the options on the LAN.  See bullet L-12 of RFC 7084.  Existing RFCs support your use case and no dhcpv6 relay is required in the CE.

/ I also cannot find text in RFC3315 or its updates on how to handle received options that were not requested by the client in the Option Request Option. So if the CE WAN DHCPv6 client doesn't request an option in its ORO to the SP's DHCPv6 server, I don't think it is possible for the CE to pass options it doesn't know about onto the downstream LAN devices that do understand those DHCPv6 options.
/ If it is possible to send a DHCPv6 client "ORO type" options that it didn't request, then the behaviour is still ambiguous. If the DHCPv6 client is a host, then it would be quite reasonable and expected to silently ignore those received unknown options. However, if the DHCPv6 client is on the WAN side of a CE device, then those options should instead be passed to the LAN DHCPv6 server, which presumably should know how to correctly handle options it doesn't understand - in the specific CE case, remember those options in case a downstream LAN DHCPv6 client requests them. I think RFC7084 and it's ancestor RFC6204 are the only RFCs which describe this combination of DHCPv6 client/server working together, and neither of them have discussed passing unknown options from the DHCPv6 WAN client to the DHCPv6 LAN server.
/ Are you aware of any CE DHCPv6 WAN client/DHCPv6 LAN server implementations that are unknown DHCPv6 option transparent? Looking at RFC7084, this behaviour seems to be very explicitly prohibited, by limiting the LAN DHCPv6 server support to only those options described in RFC7084, or to those described in RFC3736.
/ I think this level of DHCPv6 option transparency between CE LAN attached hosts and the upstream SP's DHCPv6 server(s) can only be achieved by using a DHCPv6 relay on the CE LAN interface, because DHCPv6 relays are DHCPv6 option transparent. (A CE would still have a DHCPv6 client on its WAN interface for its own parameters and DHCPv6-PD prefixes).
/ Regards,/ Mark.
 Barbara,

 
Hemant

From:Mark ZZZ Smith [mailto:[email-masked]] 
Sent: Tuesday, March 31, 2015 9:52 PM
To: Hemant Singh (shemant); STARK, BARBARA H; Brian Haberman; [email-masked]
Subject: Re: RA Option Guidelines
 
Hi Hemant,

From:Hemant Singh (shemant) <[email-masked]>
To: "STARK, BARBARA H" <[email-masked]>; Mark ZZZ Smith <[email-masked]>; Brian Haberman <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Wednesday, 1 April 2015, 1:27
Subject: RE: RA Option Guidelines

Barbara,

Thanks for replying.    

Mark,

/  So here is a scenario.

 

 

/ I'm going to make the problem much harder for you. I want the CPE to "support" or better, be transparent to, all current and future DHCPv6 options, and I don't want to have to upgrade or ask my customers to successfully upgrade their CPE each and every time
 there is a new DHCPv6 option defined that might be useful to me and them. I want to be able to provide service parameters to my customers hosts, directly or indirectly, without the software revision or model of their CPE being the constraint.

 

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Apr 2015 11:09:50 +0000

Could the DHCPv6 gurus in Ralph, Bernie, and Ted please help resolve this thread for stateless DHCPv6 current vs. future options and the ORO option.

Thanks,

Hemant

From: Mark ZZZ Smith [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 10:19 PM
To: Hemant Singh (shemant); STARK, BARBARA H; Brian Haberman; [email-masked]
Subject: Re: RA Option Guidelines

Hi Hemant,

To: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>; "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>; Brian Haberman <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Mark,

/ Regards,
/ Mark.

Barbara,

Hemant

From:Mark ZZZ Smith [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:52 PM
To: Hemant Singh (shemant); STARK, BARBARA H; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: Re: RA Option Guidelines

Hi Hemant,

From:Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>>
To: "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>; Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>; Brian Haberman <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 1 April 2015, 1:27
Subject: RE: RA Option Guidelines

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 3 Apr 2015 11:33:13 +0000

I didn't study the complete thread but I am sure everyone would understand that new options should be allowed to be requested. The ORO list cannot be frozen ... At the time the rfc was written, that was the list. But new option documents are not required to update RFC3736.

There are no interop issues either as if either side (client or server) doesn't know of an option, it just doesn't include or ignores it.

- Bernie (from iPad)

On Apr 3, 2015, at 7:09 AM, Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Hemant

Hi Hemant,

Mark,

/ Regards,
/ Mark.

Barbara,

Hemant

Hi Hemant,

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Apr 2015 11:43:17 +0000

Bernie,

Appreciate the quick reply.  Let me summarize the issues and then you can clarify.

1.       The CE WAN interface does not include a new option in DHCPV6_NEW_OPTION1 in the ORO option of the SOLICIT to the server.  If the server is configured to return the DHCPV6_NEW_OPTION1 to clients, then will the server reply with DHCPV6_NEW_OPTION1 even when the client did not request the option in the ORO?   In this scenario, no code changes on the CE, and just the server configuration takes care of the issue.

2.       The CE WAN interface does include a new option in DHCPV6_NEW_OPTION1 in the ORO option of the SOLICIT to the server.  If the server is configured to return DHCPV6_NEW_OPTION1 to clients, then will the server reply with DHCPV6_NEW_OPTION1?

Mark,

Note Bernie agrees with how I and Wes Beebee (who I discussed this thread with) also interpreted RFC3736.  New options can be served by the stateless DHCPv6 server without revising RFC3736.

Thanks all,

Hemant

From: Bernie Volz (volz)
Sent: Friday, April 03, 2015 7:33 AM
To: Hemant Singh (shemant)
Cc: Mark ZZZ Smith; STARK, BARBARA H; Brian Haberman; [email-masked]; Ralph Droms (rdroms); Ted Lemon
Subject: Re: RA Option Guidelines

- Bernie (from iPad)

Thanks,

Hemant

Hi Hemant,

Mark,

/ Regards,
/ Mark.

Barbara,

Both use cases can be supported using existing RFC's.

Hemant

Hi Hemant,

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 3 Apr 2015 11:48:00 +0000

All options MUST be in ORO for server to return (there are some "protocol" options, such as client-id and server-id that are NOT supposed to be in ORO). So client controls the options it gets. So #1 is not true (some servers, such as CPNR, can be configured to return options the client did not request, but generally that is useless since the client will most likely ignore it).

#2 is normal DHCP operation.

Note that while I think you were discussing stateless, it is true for stateful and stateless dhcp.

- Bernie (from iPad)

On Apr 3, 2015, at 7:43 AM, Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>> wrote:

Bernie,

Mark,

Thanks all,

Hemant

From: Bernie Volz (volz)
Sent: Friday, April 03, 2015 7:33 AM
To: Hemant Singh (shemant)
Cc: Mark ZZZ Smith; STARK, BARBARA H; Brian Haberman; [email-masked]<mailto:[email-masked]>; Ralph Droms (rdroms); Ted Lemon
Subject: Re: RA Option Guidelines

- Bernie (from iPad)

Thanks,

Hemant

Hi Hemant,

Mark,

/ Regards,
/ Mark.

Barbara,

Hemant

Hi Hemant,

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Apr 2015 12:28:24 +0000

Bernie,

Got it - thanks much!  So the CE router implementation has to change to be configurable to include a new DHCPv6 option in the ORO for the WAN interface.  Once the new option is returned by the server, the CE uses the new option for stateless DHCPv6 services on the LAN.  Note, it is the same service provider who has configured the CE for the new DHCPv6 option and thus the same service provider also provisions the DHCPv6 server to return the new option, if asked for.  There is no need for DHCPv6 relay in the CE for this new option support.

In summary, both Mark's and Barbara's goals are met.

Thanks,

Hemant

From: Bernie Volz (volz)
Sent: Friday, April 03, 2015 7:48 AM
To: Hemant Singh (shemant)
Cc: Mark ZZZ Smith; STARK, BARBARA H; Brian Haberman; [email-masked]; Ralph Droms (rdroms); Ted Lemon
Subject: Re: RA Option Guidelines

- Bernie (from iPad)

Mark,

Thanks all,

Hemant

From: Bernie Volz (volz)

- Bernie (from iPad)

Thanks,

Hemant

Hi Hemant,

Mark,

/ Regards,
/ Mark.

Barbara,

Hemant

Hi Hemant,

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Apr 2015 12:35:59 +0000

Also, since RFC7084 was managed in v6ops, the minor DHC update to the CE router to cater to Mark's request, I plan to submit a short note to v6ops.

Hemant

From: ipv6 [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, April 03, 2015 8:28 AM
To: Bernie Volz (volz)
Cc: [email-masked]; Brian Haberman; Ralph Droms (rdroms); Ted Lemon
Subject: RE: RA Option Guidelines

Bernie,

Thanks,

Hemant

From: Bernie Volz (volz)

- Bernie (from iPad)

Mark,

Thanks all,

Hemant

From: Bernie Volz (volz)

- Bernie (from iPad)

Thanks,

Hemant

Hi Hemant,

Mark,

/ Regards,
/ Mark.

Barbara,

Hemant

Hi Hemant,

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Apr 2015 08:38:54 -0400

> 1.       The CE WAN interface does not include a new option in DHCPV6_NEW_OPTION1 in the ORO option of the SOLICIT to the server.  If the server is configured to return the DHCPV6_NEW_OPTION1 to cl…

There's no point in the DHCP server sending an option the client didn't request.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Apr 2015 13:28:57 +0000

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, April 03, 2015 8:39 AM
To: Hemant Singh (shemant)
Cc: Bernie Volz (volz); Mark ZZZ Smith; STARK, BARBARA H; Brian Haberman; [email-masked]; Ralph Droms (rdroms)
Subject: Re: RA Option Guidelines

>There's no point in the DHCP server sending an option the client didn't request.

Thanks, Ted.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Apr 2015 13:43:09 +0000

Hmm, after more discussion, I am now corrected that a new document is not needed.  RFC 7084 does not block a new DHCPv6 option to be included in the ORO sent by the WAN.  Thus if the CE is configured to use a new DHCPv6 option, the CE will work fine.  The CE includes the new option in the ORO on the WAN and serves the new option to the LAN via stateless DHCPv6 operation.

How the CE is configured for a new DHCPv6 option is out of scope for RFC7084.

Hemant

From: ipv6 [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, April 03, 2015 8:36 AM
To: Bernie Volz (volz); Fred Baker (fred)
Cc: Brian Haberman; [email-masked]; Ted Lemon; Ralph Droms (rdroms)
Subject: RE: RA Option Guidelines

Hemant

From: ipv6 [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, April 03, 2015 8:28 AM
To: Bernie Volz (volz)
Cc: [email-masked]<mailto:[email-masked]>; Brian Haberman; Ralph Droms (rdroms); Ted Lemon
Subject: RE: RA Option Guidelines

Bernie,

Thanks,

Hemant

From: Bernie Volz (volz)

- Bernie (from iPad)

Mark,

Thanks all,

Hemant

From: Bernie Volz (volz)

- Bernie (from iPad)

Thanks,

Hemant

Hi Hemant,

Mark,

/ Regards,
/ Mark.

Barbara,

Hemant

Hi Hemant,

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 3 Apr 2015 13:45:58 +0000

Thx. You've saved me from having to right an email explaining why I'm opposed to changes to RFC 7084 resulting from this discussion thread.
Barbara

Sent: Friday, April 03, 2015 9:43 AM

Hemant

Cc: Brian Haberman; [email-masked]<mailto:[email-masked]>; Ted Lemon; Ralph Droms (rdroms)

Hemant

Bernie,

Thanks,

Hemant

From: Bernie Volz (volz)

- Bernie (from iPad)

Mark,

Thanks all,

Hemant

From: Bernie Volz (volz)

- Bernie (from iPad)

Thanks,

Hemant

Hi Hemant,

Mark,

/ Regards,
/ Mark.

Barbara,

Hemant

Hi Hemant,

Barbara,

Thanks for replying.

Mark,

/  So here is a scenario.

Others,

Thanks,

Hemant

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:25 AM
To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: RE: RA Option Guidelines

RFC 7084 already says:

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Apr 2015 08:16:32 +1300

I'm glad y'all have got DHCPv6 sorted out. Now, as to the original
subject of this thread:
On 01/04/2015 08:26, Brian E Carpenter wrote:
> On 01/04/2015 03:27, Hemant Singh (shemant) wrote:
> ...
> Section 9 "Extensibility - Option Processing" gives some general advice, too.
> 
> The question is what do we collectively want. I liked Mark's restrictive
> criterion "RA options should be limited to link-local/subnet specific parameters
> (i.e., layer 3 parameters only)". DHCPv6 is available as the kitchen sink
> protocol for other stuff. I'm not sure whether we want to write this down;
> it seems as if  one or two sentences should be added to RFC4861bis if
> there ever is such a document.

Do we actually agree on this, or rather on a slightly expanded version:

RA options should be limited to link-local/subnet specific parameters
(i.e., layer 3 parameters only) necessary for a simple unmanaged network.
The only exception is RFC 6106 (DNS Configuration). More complex situations
are better handled by other configuration metods such as DHCPv6.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 3 Apr 2015 22:18:21 +0200

> are better handled by other configuration metods such as DHCPv6.

I agree only with this part:
“RA options should be limited to link-local/subnet specific parameters (i.e. layer 3 parameters only). The only exception is RFC6106 (DNS Configuration).”

RA’s aren’t unmanaged. they certainly don’t require the network to be simple.
there was a thread on the DHC list a while back appearing to reach the conclusion that DHCP should only be used to configure the network layer (although there are many exceptions).
the main difference between RA and DHCP is that one is per subnet, the other per host.

cheers,
Ole

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 3 Apr 2015 21:03:50 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Friday, April 03, 2015 16:18
> To: Brian E Carpenter
> Cc: 6man WG; Brian Haberman

I agree with this.

> the main difference between RA and DHCP is that one is per subnet, the other

Which is about as succinctly-put as I've ever seen.

Managing each host individually is a more complex problem that managing the network without focusing on individual hosts. Perhaps the only change to Brian's point is to delete the word "simple," then. I'd go with Ole's well-distilled single sentence.

Bert

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 4 Apr 2015 01:40:58 +0000 (UTC)

I don't think it is.

Can this ever work, because this is the scenario I'm talking about:

(LAN Host: DHCPV6_NEW_OPTION1, so ORO for it) <-> (CE: !DHCPV6_NEW_OPTION1, so no ORO for it) <-> (ISP: DHCPV6_NEW_OPTION1)

Is a combined DHCPv6 Client/DHCPv6 server, as in the CE scenario, *unknown* DHCPv6 option transparent, like a DHCPv6 relay is? I think the answer is no based on what Bernie said.

________________________________
From: Hemant Singh (shemant) <[email-masked]>
To: Bernie Volz (volz) <[email-masked]> 
Cc: Mark ZZZ Smith <[email-masked]>; "STARK, BARBARA H" <[email-masked]>; Brian Haberman <[email-masked]>; "[email-masked]" <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Ted Lemon <[email-masked]> 
Sent: Friday, 3 April 2015, 23:28
Subject: RE: RA Option Guidelines

Bernie,
 
Got it – thanks much!  So the CE router implementation has to change to be configurable to include a new DHCPv6 option in the ORO for the WAN interface.  Once the new option is returned by the server, the CE uses the new option for stateless DHCPv6 services on the LAN.  Note, it is the same service provider who has configured the CE for the new DHCPv6 option and thus the same service provider also provisions the DHCPv6 server to return the new option, if asked for.  There is no need for DHCPv6 relay in the CE for this new option support.  
 
In summary, both Mark’s and Barbara’s goals are met.
 
Thanks,
 
Hemant

From:Bernie Volz (volz) 

 

- Bernie (from iPad)

>From:Bernie Volz (volz) 
>On Apr 3, 2015, at 7:09 AM, Hemant Singh (shemant) <[email-masked]> wrote:
>>/ - The lack of any overt discussion that this set of required and optional DHCPv6 options are a minimum, and that further DHCPv6 options could be provided by a stateless DHCPv6 server if supported by the implementation, are appropriate and requested by the
client. It being a minimum is subtly eluded to in a few sentences in the Abstract and the Introduction, however I think they could easily be missed. I'd expect that if this is the case, it is much clearer and obvious.
>>/ As an ISP, my customers have VoIP handsets that might support the OPTION_GEOLOCATION DHCPv6 option (I might know that a portion of them do, because they've bought those VoIP handsets from me). How long is it going to take for me to get that option added to
an updated RFC3736 and RFC7084, to get my CPE vendor to update and release their firmware to support that option, and test that new CPE firmware and then to deploy that new firmware?
>>/ A few months later I decide I want to provide OPTION_NEW_POSIX_TIMEZONE to my customers if their hosts request it. So now I have to try to get OPTION_NEW_POSIX_TIMEZONE added to the updated RFC3736, to get my CPE vendor to update and release their firmware
to support that option, and test that new CPE firmware and then to deploy that new firmware.
>> 
>>/ Now if I'm lucky I could add it to the draft for OPTION_GEOLOCATION, so it is still "only" 2 years to get to a point where I could provide those options to my customers. But what if that draft has progressed too far though the IETF publishing process? I have
to create a new draft updating the to be published draft.
>> 
>>/ So, to achieve what should be a simple task of providing location or timezone information to customers' end hosts if they want it, we've just incurred the massive costs and time delays of the IETF publishing process, vendor firmware upgrades, firmware testing
and firmware deployment. Sounds like how hard I understand it was to roll out features like CLI in PSTN networks ...
>>/ I don't think DNS in RAs was a good idea, and neither were SIP options when they were proposed. See that time consuming and service disrupting firmware upgrade cycle for new DHCPv6 options? Same problem if you use RA options to achieve the same goal. New
firmware upgrade each time you want to support a new RA option.
>> 
>>/ Duplication between RA options and DHCPv6 options also causes more problems. Which is preferred? Are they treated equally or does one take precedence over the other? As far as I'm aware, these questions haven't been answered for the DHCPv6 DNS and RA DNS
options yet. It might be simple to come up with a simple rule for more DHCPv6 options are duplicated into RAs, however their might be some specific cases where the RA option value should be preferred over the DHCPv6 equivalent option and vice-versa. 
>>/ Use a DHCPv6 relay in the CPE. Then there isn't a problem, new DHCPv6 options that are unknown by the CPE will pass right through it transparently. The only complication is when stateful DHCPv6 addressing is used on the CPE LAN interface, and I suggested
a hybrid mode of operation for a DHCPv6 server in that draft which I think solves that problem.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 4 Apr 2015 01:45:52 +0000 (UTC)

So, 

RA options should be used for link specific attributes and parameters that all hosts attached to the link use, because it is hard to do host specific RAs and,

DHCPv6 options should be used for host specific attributes and parameters, because it is easy to do host specific DHCPv6 messages

?

----- Original Message -----
From: Ole Troan <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: Hemant Singh (shemant) <[email-masked]>; Barbara Stark <[email-masked]>; Mark ZZZ Smith <[email-masked]>; Brian Haberman <[email-masked]>; 6man WG <[email-masked]>
Sent: Saturday, 4 April 2015, 7:18
Subject: Re: RA Option Guidelines

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 4 Apr 2015 03:25:07 +0000

Yes, in that situation the CE would not have requested the option from the ISP. You would need to update firmware on CE.

As new options get assigned, clients & servers need to be updated to make use of them.

You could also provide some CE configuration to request and save arbitary options, but that only is useful to expert CE users and probably has security issues.

- Bernie (from iPad)

> On Apr 3, 2015, at 9:41 PM, Mark ZZZ Smith <[email-masked]> wrote:
> 
> I don't think it is.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 4 Apr 2015 04:34:04 +0000 (UTC)

Hi Bernie,
      From: Bernie Volz (volz) <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: Hemant Singh (shemant) <[email-masked]>; Brian Haberman <[email-masked]>; Ted Lemon <[email-masked]>; "[email-masked]" <[email-masked]>; Ralph Droms (rdroms) <[email-masked]> 
 Sent: Saturday, 4 April 2015, 14:25
 Subject: Re: RA Option Guidelines
   
Yes, in that situation the CE would not have requested the option from the ISP. You would need to update firmware on CE.
/ Thank you for confirming that.
/ Having to update firmware on the CE is the exact situation I think should be avoided.
/ If CE devices have to be upgraded to deploy new applications and services (and I think 'deployment' includes automated configuration of them), then in my opinion Internet (application) transparency has been lost.

As new options get assigned, clients & servers need to be updated to make use of them.
/ If the CE device is DHCPv6 option transparent (i.e., is running a LAN DHCPv6 relay), then upgrades are only required to the hosts that want to use the new DHCPv6 options, which is much less disruptive than also requiring CE firmware upgrades.

You could also provide some CE configuration to request and save arbitary options, but that only is useful to expert CE users and probably has security issues.
/ Agree, not practical for typical residential users.
/ Regards,/ Mark.

- Bernie (from iPad)

---

From: Roland Bless <[email-masked]>
Date: Sat, 04 Apr 2015 11:00:03 +0200

Hi,

On 03.04.2015 at 22:18 Ole Troan wrote:
>> RA options should be limited to link-local/subnet specific
>> parameters (i.e., layer 3 parameters only) necessary for a simple
>> unmanaged network. The only exception is RFC 6106 (DNS
>> Configuration). More complex situations are better handled by
>> other configuration metods such as DHCPv6.
> 
> I agree only with this part: “RA options should be limited to
> link-local/subnet specific parameters (i.e. layer 3 parameters
> only). The only exception is RFC6106 (DNS Configuration).”
> 
> RA’s aren’t unmanaged. they certainly don’t require the network to
> be simple. there was a thread on the DHC list a while back
> appearing to reach the conclusion that DHCP should only be used to
> configure the network layer (although there are many exceptions). 

+1

Regards,
 Roland

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 4 Apr 2015 12:05:04 +0000

Why is thus such a big deal? The same has been the case for v4 all along and has not been an issue. There are reasons to upgrade CE or the firmware periodically, i.e. security and new features. New options aren't added that frequently and those that have been recently are for softwire and for options that your home computer, phone, or tablet doesn't generally need.

See http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml.

- Bernie (from iPad)

On Apr 4, 2015, at 12:34 AM, Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bernie,

________________________________
From: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
To: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
Cc: Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>>; Brian Haberman <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, 4 April 2015, 14:25
Subject: Re: RA Option Guidelines

/ Regards,
/ Mark.

- Bernie (from iPad)

> On Apr 3, 2015, at 9:41 PM, Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>> wrote:
>
> I don't think it is.
>
> To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
> Cc: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>; "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>; Brian Haberman <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>
>>> From:Mark ZZZ Smith [mailto:[email-masked]<mailto:[email-masked]>]
>>> From:Mark ZZZ Smith [mailto:[email-masked]<mailto:[email-masked]>]
> [email-masked]<mailto:[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 4 Apr 2015 21:26:07 +0900

> are better handled by other configuration metods such as DHCPv6.

No, I strongly disagree.

There are other differences between RA and DHCP. The most important one I
see is that with DHCP it is basically impossible to change things
dynamically.

Dynamically changing stateful parameters requires that the client implement
reconfigure, and even then, it requires authentication, and requires either
that the DHCP server never crashes, or that DHCPv6 failover is in use.
Dynamically changing stateless options doesn't even seem possible at all -
you have to wait until the client asks again, and the minimum time that
must pass is 10 minutes (RFC 4242).

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 6 Apr 2015 22:41:03 +0000 (UTC)

Hi Bernie,

Actually, in many broadband networks IPv4 is quite different. The options you could convey to customers were limited to those that were supported by IPCP,

- IPv4 DNS

- Microsoft Netbios Name Servers addresses
- Mobile IPv4 address
everything else had to be manually configured by the customer, with the details provided on settings web pages such as this,

http://www.internode.on.net/support/guides/general_settings/

which is onerous and error prone, and in my opinion would be a very un-user friendly practice to continue in IPv6. Cars are learning drive themselves, and planes can fly themselves, so why do customers still have to cut and paste ISP service setting into their applications in this day and age?

There are certainly good reasons to upgrade CPE fairly regularly, however I'm not confident it is happening as much as people might believe, based on first hand experience at fairly residential broadband ISPs in Australia between 2005 and 2011, where the market is primarily BYO CPE, and a number of other presentations and articles I've seen on the topic such as these:

Black Hat USA 2014 - Network: Abuse of CPE Devices and Recommended Fixes
https://www.youtube.com/watch?v=JJF91GHm_7w

The Wild West by HD Moore
https://speakerdeck.com/hdm/derbycon-2012-the-wild-west

12 Million Home Routers Vulnerable to Takeover
https://threatpost.com/12-million-home-routers-vulnerable-to-takeover/109970

Australia in the Carna Botnet
https://docs.google.com/file/d/0BxMgdZPXsSLBX2VXUTBXYURkNlk/edit

Security updates could be considered a more important reason to upgrade than to support new DHCP options, so if security updates aren't happening, then updates to support new DHCP options are even less likely to occur.

IOW, upgrading routers to support new applications is not practical, and in my understanding, also not following the Internet (Application) Transparency model as described in RFC1958 and other RFCs. 

Regards,
Mark.

Sent: Saturday, 4 April 2015, 23:05

- Bernie (from iPad)

On Apr 4, 2015, at 12:34 AM, Mark ZZZ Smith <[email-masked]> wrote:

Hi Bernie,
>> Got it – thanks much!  So the CE router implementation has to change to be configurable to include a new DHCPv6 option in the ORO for the WAN interface.  Once the new option is returned by the server, the CE uses the new option for stateless DHCPv6 services
on the LAN.  Note, it is the same service provider who has configured the CE for the new DHCPv6 option and thus the same service provider also provisions the DHCPv6 server to return the new option, if asked for.  There is no need for DHCPv6 relay in the CE
for this new option support.  
>> All options MUST be in ORO for server to return (there are some "protocol" options, such as client-id and server-id that are NOT supposed to be in ORO). So client controls the options it gets. So #1 is not true (some servers, such as CPNR, can be configured
to return options the client did not request, but generally that is useless since the client will most likely ignore it).
>>> 1.    The CE WAN interface does not include a new option in DHCPV6_NEW_OPTION1 in the ORO option of the SOLICIT to the server.  If the server is configured to return the DHCPV6_NEW_OPTION1 to clients, then will the server reply with DHCPV6_NEW_OPTION1 even
when the client did not request the option in the ORO?  In this scenario, no code changes on the CE, and just the server configuration takes care of the issue.
>>>> / - I think text you refer to in 5.3, "Clients and servers use the following options to pass configuration information to clients; note that other options for configuration information may be specified in future Internet Standards:" reads to me like a later
version of this RFC will specify more stateless DHCPv6 server supported options. A statement such as "Other additional DHCPv6 options appropriate for stateless DHCPv6 operation may be supported by an implementation." would make it much clearer that the supported
options were up to the implementer once the minimum had been implemented.
>>>> 
>>>> / So if I were implementing a stateless DHCPv6 server as per RFC3736, I'd think the implementation was complete when I had implemented the options specified. I wouldn't put any effort into making it also transparent to any options that weren't identified
in RFC3736, as there is no text discussing that.
>>>> 
>>>> So the new options you want to serve can be served by the CE stateless DHCPv6 server.  Now, if the service provider configures his/her DHCPv6 server to return new options to the CE WAN interface address acquisition, the CE uses the options on the LAN. 
See bullet L-12 of RFC 7084.  Existing RFCs support your use case and no dhcpv6 relay is required in the CE.
>>>> 
>>>> / I also cannot find text in RFC3315 or its updates on how to handle received options that were not requested by the client in the Option Request Option. So if the CE WAN DHCPv6 client doesn't request an option in its ORO to the SP's DHCPv6 server, I don't
think it is possible for the CE to pass options it doesn't know about onto the downstream LAN devices that do understand those DHCPv6 options.
>>>> 
>>>> / If it is possible to send a DHCPv6 client "ORO type" options that it didn't request, then the behaviour is still ambiguous. If the DHCPv6 client is a host, then it would be quite reasonable and expected to silently ignore those received unknown options.
However, if the DHCPv6 client is on the WAN side of a CE device, then those options should instead be passed to the LAN DHCPv6 server, which presumably should know how to correctly handle options it doesn't understand - in the specific CE case, remember those
options in case a downstream LAN DHCPv6 client requests them. I think RFC7084 and it's ancestor RFC6204 are the only RFCs which describe this combination of DHCPv6 client/server working together, and neither of them have discussed passing unknown options from
the DHCPv6 WAN client to the DHCPv6 LAN server.
>>>> 
>>>> / Are you aware of any CE DHCPv6 WAN client/DHCPv6 LAN server implementations that are unknown DHCPv6 option transparent? Looking at RFC7084, this behaviour seems to be very explicitly prohibited, by limiting the LAN DHCPv6 server support to only those
options described in RFC7084, or to those described in RFC3736.
>>>> 
>>>> / I think this level of DHCPv6 option transparency between CE LAN attached hosts and the upstream SP's DHCPv6 server(s) can only be achieved by using a DHCPv6 relay on the CE LAN interface, because DHCPv6 relays are DHCPv6 option transparent. (A CE would
still have a DHCPv6 client on its WAN interface for its own parameters and DHCPv6-PD prefixes).
>>>> However, I still ask the question as to how an RA received at the WAN of the CPE has its options propagated to the RA on the LAN?  At the time of writing RFC 6204 or RFC 7084, there is no such provision between the RA received on the WAN and the RA issued
on
>> the LAN of the CE router.
>>>>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 6 Apr 2015 23:20:42 +0000 (UTC)

So that sounds to me like a limitation in DHCPv6 that should be fixed, rather than trying to work around it with RAs.
I think the fundamental question about what to use RAs for comes to:
Do we bind/tightly couple the ability to deploy new applications to the features supported by the local router or not?

My understanding of the Internet architecture as described in RFC1958 is we should not.
      From: Lorenzo Colitti <[email-masked]>
 To: Brian E Carpenter <[email-masked]> 
Cc: Hemant Singh (shemant) <[email-masked]>; "STARK, BARBARA H" <[email-masked]>; Mark ZZZ Smith <[email-masked]>; Brian Haberman <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Saturday, 4 April 2015, 23:26
 Subject: Re: RA Option Guidelines

On Sat, Apr 4, 2015 at 4:16 AM, Brian E Carpenter <[email-masked]> wrote:

No, I strongly disagree.
There are other differences between RA and DHCP. The most important one I see is that with DHCP it is basically impossible to change things dynamically.
Dynamically changing stateful parameters requires that the client implement reconfigure, and even then, it requires authentication, and requires either that the DHCP server never crashes, or that DHCPv6 failover is in use. Dynamically changing stateless options doesn't even seem possible at all - you have to wait until the client asks again, and the minimum time that must pass is 10 minutes (RFC 4242).

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Apr 2015 09:29:16 +0900

Bear in mind that AIUI there is pretty strong consensus in the dhc working
group that DHCP should *not* be used for general application configuration,
but only for bootstrapping networking parameters.

On Tue, Apr 7, 2015 at 8:20 AM, Mark ZZZ Smith <[email-masked]>
wrote:

> So that sounds to me like a limitation in DHCPv6 that should be fixed,
> rather than trying to work around it with RAs.
>
> Do we bind/tightly couple the ability to deploy new applications to the
> features supported by the local router or not?
>
>   ------------------------------
>  *From:* Lorenzo Colitti <[email-masked]>
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* Hemant Singh (shemant) <[email-masked]>; "STARK, BARBARA H" <
> [email-masked]>; Mark ZZZ Smith <[email-masked]>; Brian
> Haberman <[email-masked]>; "[email-masked]" <[email-masked]>
> *Sent:* Saturday, 4 April 2015, 23:26
> *Subject:* Re: RA Option Guidelines
>
>
>
> Dynamically changing stateful parameters requires that the client
> implement reconfigure, and even then, it requires authentication, and
> requires either that the DHCP server never crashes, or that DHCPv6 failover
> is in use. Dynamically changing stateless options doesn't even seem
> possible at all - you have to wait until the client asks again, and the
> minimum time that must pass is 10 minutes (RFC 4242).
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Apr 2015 14:02:20 +0200

Le 03/04/2015 21:16, Brian E Carpenter a écrit :
> subject of this thread: On 01/04/2015 08:26, Brian E Carpenter
> wrote:
>> On 01/04/2015 03:27, Hemant Singh (shemant) wrote: ...
>>> Also, why does one need an RA Option Guideline?  RFC4861
>>> specifies a TLV format and an option Type.   I don't see
>>> anything else needed if I need to specify a new RA option.
>>
>> The question is what do we collectively want. I liked Mark's
>> restrictive criterion "RA options should be limited to
>> link-local/subnet specific parameters (i.e., layer 3 parameters
>> only)". DHCPv6 is available as the kitchen sink protocol for other
>> stuff. I'm not sure whether we want to write this down; it seems
>> as if  one or two sentences should be added to RFC4861bis if there
>> ever is such a document.
>
> (i.e., layer 3 parameters only) necessary for a simple unmanaged
> network. The only exception is RFC 6106 (DNS Configuration). More
> complex situations are better handled by other configuration metods
> such as DHCPv6.

It makes sense.

But, would it be possible to tell link-local subnet of a particular
Router?  I am asking because currently it is the link-local subnet of
one particular interface, the "on-link" prefix;  and it would be good to
allow a prefix in one subnet of an interface of a router be announced on
another interface of same router as "other prefix nearby".

And still forbid one Router to read an RA and propagate its contents
further down the network.

Alex

>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 7 Apr 2015 23:18:17 +0000 (UTC)

Hi Lorenzo,

________________________________
From: Lorenzo Colitti <[email-masked]>
To: Mark ZZZ Smith <[email-masked]> 
Cc: Brian E Carpenter <[email-masked]>; Hemant Singh (shemant) <[email-masked]>; "STARK, BARBARA H" <[email-masked]>; Brian Haberman <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, 7 April 2015, 10:29
Subject: Re: RA Option Guidelines

Bear in mind that AIUI there is pretty strong consensus in the dhc working group that DHCP should *not* be used for general application configuration, but only for bootstrapping networking parameters.

/ I'm not sure I understand their view, although if 'network parameters' has been generalised to include application parameters then it makes more sense.

/ I'm considering "network parameters" to mean only network layer/layer 3 parameters. Other parameters belong to other upper layers, and those other layers are only implemented in hosts (or the (control plane located) host component/functions of a router), so they're host oriented rather than network parameters. Going by the name, it sounds like the Dynamic Host Configuration Protocol is either the best or a likely candidate protocol to configure these transport layer+ parameters.
/ RFC5505, "Principles of Internet Host Configuration" also creates a configuration distinction between the network layer ("Internet-Layer Configuration") and the upper layers ("Higher-Layer Configuration"), and also discusses the issue of DHCPv6 learned parameters been less dynamic in "Relationship between IP Configuration and Service Discovery".
/ Regards,Mark.

On Tue, Apr 7, 2015 at 8:20 AM, Mark ZZZ Smith <[email-masked]> wrote:

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 7 Apr 2015 23:39:38 +0000 (UTC)

From: Alexandru Petrescu <[email-masked]>
 To: [email-masked] 
 Sent: Tuesday, 7 April 2015, 22:02
 Subject: Re: RA Option Guidelines

It makes sense.

/ I think the Route Information Option is the RA option you're looking for (RFC4191).

/ I agree with this. With exception to the exceptional RA DNS options, all of the other RA option parameters are specific to the link the RA is sent over. Copying those values onto a different link doesn't make sense, because those values may not be correct for the different link. In other words, link specific RA option values need to be originated (not copied) for the link the RA is sent over.
/ RFC5505, "Principles of Internet Host Configuration" discusses these topics quite comprehensively. I'd read bits of it in the past, however I didn't realise comprehensive it was. Well worth a read.

/ Regards,/ Mark.

Alex