RE: RA Option Guidelines

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

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:[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]<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]<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.