RE: RA Option Guidelines

["Hemant Singh (shemant)" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>
Subject: Re: RA Option Guidelines

Hi Hemant,


________________________________
From: Hemant Singh (shemant) <[e-mail]<mailto:[e-mail]>>
To: Mark ZZZ Smith <[e-mail]<mailto:[e-mail]>>; "STARK, BARBARA H" <[e-mail]<mailto:[e-mail]>>; Brian Haberman <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>
Subject: Re: RA Option Guidelines

Hi Hemant,


________________________________

From:Hemant Singh (shemant) <[e-mail]<mailto:[e-mail]>>
To: "STARK, BARBARA H" <[e-mail]<mailto:[e-mail]>>; Mark ZZZ Smith <[e-mail]<mailto:[e-mail]>>; Brian Haberman <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[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.