Subject: RA Option Guidelines

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Mar 2015 10:38:17 -0500

Hi all,

It seems to me that we need a document explaining what to follow when
proposing or developing new RA options.

What do you think?

Regards,

Behcet

---

From: Dan Lüdtke <[email-masked]>
Date: Fri, 27 Mar 2015 19:45:32 +0100

Hi Behcet and all,

I agree that such a document would be very appreciated.
I am willing to help, I can comment from the implementers point of view.

Cheers

Dan

> On 27 Mar 2015, at 16:38, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi all,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Fri, 27 Mar 2015 14:04:07 -0500

> proposing or developing new RA options.

Can you elaborate on what kinds of things would go in such a document?
I don't want to see a bunch of rules that usurp good engineering judgement.

Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Mar 2015 11:08:51 -0500

Hi Brian,

> I don't want to see a bunch of rules that usurp good engineering judgement.

Absolutely.

The idea should be to help engineers to define new options that are
implementable.

I am thinking of sections like what should a document proposing new
options be like,

considerations on
reusing existing options, i.e. combined options, and

defining new options or single or singleton options.

I think it should be BCP type of document.

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Mar 2015 18:51:16 +0200

> The idea should be to help engineers to define new options that are

Part of that could be the existing RFC which tells "flags options" RFC5175?

But just part, because there would be need for more advice.  Recently we 
discussed this fate sharing and all the other aspects of the discussions 
around RA.

Alex

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 31 Mar 2015 02:09:09 +0000 (UTC)

Hi Brian,

----- Original Message -----

From: Brian Haberman <[email-masked]>
To: [email-masked]
Cc: 
Sent: Saturday, 28 March 2015, 6:04
Subject: Re: RA Option Guidelines

/ I think it is pretty easy to state.

/ In the Internet architecture, routers aren't supposed to be involved in applications, because the network is supposed to be transparent and oblivious to applications (with payload encryption enforcing this model). Consequently, if it is necessary to upgrade a router to deploy a new application, then the network isn't transparent to the applications any more.

/ So using RA options to configure applications violates Internet application transparency because router upgrades are required to deploy those applications.

/ The "work around" to upgrade-requiring or unsupported/never supported RA options on routers would be to use DHCPv6 options to configure the application. To support a non-local DHCPv6 server, the router could operate as a DHCPv6 relay. DHCPv6 relays are DHCPv6 option transparent, so the router/DHCPv6 relay would not need to be upgraded to support new DHCPv6 options and therefore new applications. "Old" routers can support new applications in this model.

/ I think this DHCPv6 relay "work around" isn't actually a work around - it is the right solution in the first place. I think RA options should be limited to link-local/subnet specific parameters (i.e., layer 3 parameters only), and other parameters should be provided to hosts via a higher level, "multi-hop" protocol and end-to-end protocol such as DHCPv6.

/ I came to this realisation when I wanted to push as many service parameters as possible to IPv6 residential broadband customers via DHCPv6 a few years ago. The trouble was/is that IPv6 CPE operates as a DHCPv6 client on the WAN side and a DHCPv6 server on the LAN side. The same problem occurs in this WAN client/LAN server model - to deploy new DHCPv6 options to support new applications, a CPE upgrade is required because the CPE isn't DHCPv6 option transparent. In Australia a lot of CPE is BYO, so CPE upgrades is a next to impossible task. I wrote more about it here:

"IPv6 CE Device DHCPv6 Option Transparency"
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00

Regards,

Mark.

Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 31 Mar 2015 11:18:00 +0000

Mark,

The CE router behavior can be augmented with something like the text below.

If the CE sees stateless DHCPv6 operation on its LAN with an ORO option that the CE does not support, the CE relay-forwards the request upstream.  

You could work with your CE vendor and have them add this minor functionality.   You can also contact the homenet WG.  Maybe they have already added such a requirement to the CE router.  

Thanks,

Hemant

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
Sent: Monday, March 30, 2015 10:09 PM
To: Brian Haberman; [email-masked]
Subject: Re: RA Option Guidelines

Regards,

Mark.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 31 Mar 2015 13:11:14 +0000

One more comment.

The problem that Mark  raised and also provided a solution for is to add DHCPv6 relay functionality to the CE router.   He is also correct that RFC 6204 does not include DHCPv6 relay agent functionality in the CE router.  

The other choice for a solution is to include the DHCPv6 options in the RA.  For this solution to work the SP will send new DHCPv6 options in the RA to the CE router WAN.  The RA terminates at the CE WAN.  The CE generates a new RA for the LAN.   RFC 6204 does not include functionality to bridge the SP RA received on the CE WAN to the CE LAN.   So even for the RA solution to work, a new requirement would need to be added to RFC 6204.  Did I miss anything in the RA solution I described above?  If not, either way, one adds a new requirement to the CE router and if it's DHCPv6 options, let DHCPv6 protocol deal with it. 

Thanks,

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 31 Mar 2015 13:24:31 +0000

> The problem that Mark  raised and also provided a solution for is to add
> DHCPv6 relay functionality to the CE router.   He is also correct that RFC 6204
> does not include DHCPv6 relay agent functionality in the CE router.
> 
> The other choice for a solution is to include the DHCPv6 options in the RA.
> For this solution to work the SP will send new DHCPv6 options in the RA to
> the CE router WAN.  The RA terminates at the CE WAN.  The CE generates a
> new RA for the LAN.   RFC 6204 does not include functionality to bridge the SP
> RA received on the CE WAN to the CE LAN.   So even for the RA solution to
> work, a new requirement would need to be added to RFC 6204.  Did I miss
> anything in the RA solution I described above?  If not, either way, one adds a
> new requirement to the CE router and if it's DHCPv6 options, let DHCPv6
> protocol deal with it.

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.
Where the RFC3736 list of options is for DNS Recursive Name Servers, DNS search list, and SIP Servers.

My personal, as-a-consumer, freaking-out-about-privacy opinion is that the idea of my ISPs (both of them, but potentially 3) sending any configuration options they feel like down to my personal and private LAN host devices is not to my liking. I realize that some people are blithely happy to turn over their privacy to ISPs. So maybe relay of all unrecognized options could be something an ISP puts into CE routers they supply to their customers. I prefer for it not to be in the retail ones I purchase, and I would be adamant about it not being on by default in such retail CE routers. So let such relay requirements go into eRouter or BBF specs, but please keep them out of IETF and homenet specs.

Since I'm in the process of setting up my new homenet router (Pierre flashed my new router for me last week) to connect upstream to both my ISPs (one cable provider and one telco), I also really don't want dueling relayed options reaching my LAN hosts. I do think that in the future a significant number of people will choose to subscribe to multiple providers -- as long as it's easy to do. The ISPs get to configure the CE router WAN interfaces to work with their access networks -- and that needs to be the extent of their reach unless I specifically give them conscious permission to do more. If they want to configure devices inside my LAN, I think they should use a higher layer configuration protocol with mandatory and default-on security (which neither RA nor DHCPv6 have).

Barbara

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 31 Mar 2015 14:27:45 +0000

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.   What is one option you'd like the host on the LAN to include so that we can understand your use case better?  

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.  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.

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]] 
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: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Apr 2015 08:26:29 +1300

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. 

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.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 1 Apr 2015 01:51:57 +0000 (UTC)

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,

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,

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: Mark ZZZ Smith <[email-masked]>
Date: Wed, 1 Apr 2015 02:33:51 +0000 (UTC)

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

RFC 7084 already says: 

My personal, as-a-consumer, freaking-out-about-privacy opinion is that the idea of my ISPs (both of them, but potentially 3) sending any configuration options they feel like down to my personal and private LAN host devices is not to my liking. I realize that some people are blithely happy to turn over their privacy to ISPs. So maybe relay of all unrecognized options could be something an ISP puts into CE routers they supply to their customers. I prefer for it not to be in the retail ones I purchase, and I would be adamant about it not being on by default in such retail CE routers. So let such relay requirements go into eRouter or BBF specs, but please keep them out of IETF and homenet specs.
/ I think you're already trusting your ISP possibly much more than you might realise. They're already supplying you with the Internet addressing you use, you're probably using their DNS resolvers, you may be using their email servers, and of course they can tap your clear text traffic without you knowing.
/ Even if you only used their addressing and encrypted all of your traffic over a tunnel through their infrastructure, you'd still then be trusting the remote tunnel endpoint provider, likely to be another party other than yourself.
Since I'm in the process of setting up my new homenet router (Pierre flashed my new router for me last week) to connect upstream to both my ISPs (one cable provider and one telco), I also really don't want dueling relayed options reaching my LAN hosts. I do think that in the future a significant number of people will choose to subscribe to multiple providers -- as long as it's easy to do. The ISPs get to configure the CE router WAN interfaces to work with their access networks -- and that needs to be the extent of their reach unless I specifically give them conscious permission to do more. If they want to configure devices inside my LAN, I think they should use a higher layer configuration protocol with mandatory and default-on security (which neither RA nor DHCPv6 have).
/ So I think the world is moving in the other direction. People have been outsourcing the maintenance of their devices in droves as they adopt smartphones and tablets, and more recently with devices like Google's Chromebooks. They're giving up control rather than desiring more of it, for the gains of more convenience and lower costs.
/ Regards,Mark.

Barbara