Re: RA Option Guidelines

[Behcet Sarikaya <[e-mail]>]

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.

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

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

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

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