Re: RA Option Guidelines

["Bernie Volz (volz)" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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) <[e-mail]>
> To: Bernie Volz (volz) <[e-mail]> 
> Cc: Mark ZZZ Smith <[e-mail]>; "STARK, BARBARA H" <[e-mail]>; Brian Haberman <[e-mail]>; "[e-mail]" <[e-mail]>; Ralph Droms (rdroms) <[e-mail]>; Ted Lemon <[e-mail]> 
> 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) 
> Sent: Friday, April 03, 2015 7:48 AM
> To: Hemant Singh (shemant)
> Cc: Mark ZZZ Smith; STARK, BARBARA H; Brian Haberman; [e-mail]; Ralph Droms (rdroms); Ted Lemon
> Subject: Re: RA Option Guidelines
> 
> 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) <[e-mail]> wrote:
>> 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; [e-mail]; Ralph Droms (rdroms); Ted Lemon
>> Subject: Re: RA Option Guidelines
>> 
>> 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) <[e-mail]> wrote:
>>> 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:[e-mail]] 
>>> Sent: Thursday, April 02, 2015 10:19 PM
>>> To: Hemant Singh (shemant); STARK, BARBARA H; Brian Haberman; [e-mail]
>>> Subject: Re: RA Option Guidelines
>>> 
>>> Hi Hemant,
>>> 
>>> 
>>> ________________________________
>>> From: Hemant Singh (shemant) <[e-mail]>
>>> To: Mark ZZZ Smith <[e-mail]>; "STARK, BARBARA H" <[e-mail]>; Brian Haberman <[e-mail]>; "[e-mail]" <[e-mail]> 
>>> 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,
>>> 
>>> 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:[e-mail]] 
>>> Sent: Tuesday, March 31, 2015 9:52 PM
>>> To: Hemant Singh (shemant); STARK, BARBARA H; Brian Haberman; [e-mail]
>>> Subject: Re: RA Option Guidelines
>>> 
>>> Hi Hemant,
>>> 
>>> 
>>> ________________________________
>>> 
>>> From:Hemant Singh (shemant) <[e-mail]>
>>> To: "STARK, BARBARA H" <[e-mail]>; Mark ZZZ Smith <[e-mail]>; Brian Haberman <[e-mail]>; "[e-mail]" <[e-mail]> 
>>> 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:[e-mail]] 
>>> Sent: Tuesday, March 31, 2015 9:25 AM
>>> To: Hemant Singh (shemant); Mark ZZZ Smith; Brian Haberman; [e-mail]
>>> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------