Re: RA Option Guidelines

[Mark ZZZ Smith <[e-mail]>]

Hi Behcet,




________________________________
From: Behcet Sarikaya <[e-mail]>
To: Mark ZZZ Smith <[e-mail]> 
Cc: "STARK, BARBARA H" <[e-mail]>; Hemant Singh (shemant) <[e-mail]>; "[e-mail]" <[e-mail]> 
Sent: Friday, 3 April 2015, 3:53
Subject: Re: RA Option Guidelines


On Wed, Apr 1, 2015 at 6:23 PM, Mark ZZZ Smith
<[e-mail]> wrote:
> Hi Behcet,
>
>
> ----- Original Message -----
> From: Behcet Sarikaya <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>
> Cc: "STARK, BARBARA H" <[e-mail]>; Hemant Singh (shemant) <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Thursday, 2 April 2015, 6:21
> Subject: Re: RA Option Guidelines
>
> I don't understand why DHCPv6 is being discussed under RA Option Guidelines?
> If DHCPv6 is being used instead of RA, like in Australia, that
> supports our position that we should also define DHCPv6 options for
> SADR.
>
> / DHCPv6 isn't being used instead of RAs in Australia.
>
> / I think the fundamental problem is people are considering RAs and DHCPv6 to be functional equivalents (like e.g., OSPF vs IS-IS), and therefore thinking that DHCPv6 options should be imported into RAs and vice versa.
>

No, I don't think anybody proposed that, not at myself.
I think you are missing the context here.


/ I think when ever there is a proposal to add options to RAs and to DHCPv6 to carry literally the same values, then I think people are considering them to be functional equivalents, even though they aren't.

> / There are critical operational limitations that RAs have that DHCPv6 doesn't (because the RA mechanisms are much simpler), and by trying to use RAs for the same purpose as DHCPv6,

No, I don't know how you got this? I am sure it is not from SADR discussions.

/ I thought this thread was about what should and shouldn't go into RA options. 

> all the problems already solved for DHCPv6 would have to be solved again for RAs. The desired simplicity of using RAs only would disappear because the complexity of replicating DHCPv6 mechanisms, and the additional significant operational overheads of constant firmware upgrades to routers to add RA options.
>

Yes, there are some parallels like DHCP option guidelines document. I
think that you are blowing it out of proportion.
If it were like you thought then one would say whatever DHCP
guidelines says applies to RA options also and that's it.

The context as I see it is that there are new RA options that are
being defined, maybe it is time to come up with some guidelines. I
view it is natural that this is happening because IPv6 is being
deployed more and more.

/ Right. I agree with guidelines. What I'm pointing out is that the decision on what to put in RAs or not is strongly influenced by factors people seem to not commonly be recognising, including one as fundamental as Internet application transparency. 


DHCP options in this context came about because some people say maybe
we should define the corresponding DHCP options not vice versa. Please
see
http://tools.ietf.org/wg/mif/draft-ietf-mif-mpvd-arch/

and
https://tools.ietf.org/html/draft-ietf-mif-mpvd-ndp-support-01
https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-01

/ I'll have a more thorough read to better understand the problem, however the fundamental question I have is are those provisioning domain parameters (which may be useful to consider more generally in an RA guidelines document)

(a) link specific (meaning that every attached host is part of the same provisioning domain, and more explicitly, different hosts can't be part of different provisioning domains when they're attached to the same link)?

(b) host specific (meaning different hosts attached to the same link can be part of different provisioning domains, even if commonly they might be part of the same provisioning domain when attached to the same link)?

If the answer is (a), then I think those options are probably appropriate in RAs, as RA contents can't or can't easily be made host specific (i.e., in the later case you have to stop multicasting RAs, and build host specific unicast RAs, and you only have link-local or MAC addresses to identify the individual hosts). DHCPv6 might still be a better place for them because it is a more flexible protocol, and allows host by host piecemeal deployment of new options.

If the answer is (b), then DHCPv6 is the more appropriate location, because DHCPv6 is fundamentally designed to provide host specific parameters e.g., through the use of host specific attributes such as Client Identification Option, the Vendor Class Option or the Vendor-specific Information Option.


Looking at the example in MPVD architecture, with my limited understanding, I think the answer is both (a) and (b) above, but not duplication across both:


"Typical examples of information in a provisioning domain learned
from the network are:

*  Source address prefixes for use by connections within the
provisioning domain

*  IP address(es) of DNS server(s)

*  Name of HTTP proxy server (if available)

*  DNS suffixes associated with the network

*  Default gateway address"



- Source address prefixes for use by connections within the provisioning domain and Default gateway address are link specific (the same for all hosts attached to the link), so should be conveyed in PV specific RAs options


-  DNS server addresses, proxy servers, DNS suffixes are can be host specific, so should be conveyed in PV specific DHCPv6 options


That break down might not be correct, if all of those parameters are host specific, then they should be conveyed in DHCPv6 because DHCPv6 has the mechanisms to do host specific parameters.

I always think it is important to fall back to this fundamental principle from RFC1958, "Architectural Principles of the Internet", which is why I think it is a choice between RA options or DHCPv6 options, rather than doing both:


"3.2 If there are several ways of doing the same thing, choose one.
If a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution unless
there is a good technical reason not to.  Duplication of the same
protocol functionality should be avoided as far as possible, without
of course using this argument to reject improvements."

I suspect the argument for putting DHCPv6-like information into RAs is fundamentally, "what if there isn't a DHCPv6 server (relay) to use". My answer would be that if you want to do XYZ, then you need a DHCPv6 server (instead of overloading RAs with DHCPv6 functionality.)



Regards,
Mark.




Regards,




Behcet


> Regards,
>
> Mark.
>
>
>
> Regards,
> Behcet
>
>
> On Tue, Mar 31, 2015 at 9:33 PM, Mark ZZZ Smith
> <[e-mail]> wrote:
>> Hi Barbara,
>>
>> ________________________________
>> From: "STARK, BARBARA H" <[e-mail]>
>> To: Hemant Singh (shemant) <[e-mail]>; Mark ZZZ Smith
>> <[e-mail]>; Brian Haberman <[e-mail]>;
>> "[e-mail]" <[e-mail]>
>> Sent: Wednesday, 1 April 2015, 0:24
>> Subject: RE: RA Option Guidelines
>>
>>
>>
>>> 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.
>>
>> / 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
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>