[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: draft ra guidelines: Worth the effort?
From:       Mark Smith <markzzzsmith () gmail ! com>
Date:       2015-09-03 9:42:36
Message-ID: CAO42Z2xBAEWwhU3ZNFe7Q8xnPMGrPbWb3e771z3-Ra3wJQxryw () mail ! gmail ! com
[Download RAW message or body]

Hi Dan,

On 3 September 2015 at 17:38, Dan Lüdtke <mail@danrl.de> wrote:
> Hi Mark,
> 
> > Having briefly looked though it, one thing I was hoping it would
> > provide an overt answer to is when are RA options appropriate compared
> > to DHCPv6 options.
> 
> This is, currently, not in the scope of the document. RA vs. DHCPv6 is a
> non-easy discussion, from my point of view including some very good political
> arguments. I'd rather not put that into a draft or RFC.
> 

So I'd firstly say we shouldn't be listening to political arguments,
because they're not engineering ones!

I did think the discussion of choice between using RAs and DHCPv6 was
in scope, and in part it seems to be, as there is discussion of the
characteristics of using RAs is in "Configuration using Router
Advertisements". Looking at RFC7227, I think there is the equivalent
discussion about use of DHCPv6 in "When to Use DHCPv6", which makes
sense if you're used it as a template.

So I think the more overt answer I'd like to see between when to use
RAs options verses when to use DHCPv6 options could be achieved by
mentioning in the "Configuration using Router Advertisements" section
that discussion of when to use DHCPv6 options is covered in RFC7227.

> > 
> > It does mention that RAs normally go to all hosts, which means that if
> > there are host specific parameters, then DHCPv6 should be used, so the
> > corresponding option should be a DHCPv6 one (or perhaps something
> > else).
> 
> How about: RAs normally go to all hosts, which means that if there are host
> specific parameters, then RAs may not be the best solution. Other
> configuration protocols, such as DHCPv6, may be suited better.
> 
> I'd rather not suggest using DHCPv6 in such a strong way. I don't think that
> suits a RA guideline draft well.
> 

I think there are strong reasons to use RA options in some situations,
and strong reasons to use DHCPv6 options in others. So I don't think
the "may not be the best solution" and "may be suited better"
terminology should be used, because I think it implies that there
isn't much difference between them, meaning that the choice between
RAs and DHCPv6 is nearly arbitrary.

I think if the reader has read this draft's "Configuration using
Router Advertisements" section, and read RFC7227's "When to Use
DHCPv6" sections, it should be quite obvious to them which one to use.

I think that could be helped in this draft by mentioning that to
support new RA options the router's control plane software would need
to be upgraded, which is likely to also disrupt the router's packet
forwarding, and that would disrupt forwarding for hosts that may not
have any use for the new RA option. Although it seems a bit out of
scope, I think it would be worth mentioning that deploying new DHCPv6
options is not as disruptive as deploying new RA options, as only the
DHCPv6 server providing the new option, and DHCPv6 clients interested
in the new option, both residing on hosts, need to be upgraded. The
disruption to non-interested hosts during new DHCPv6 option deployment
will be minimal or non-existent, unless the DHCPv6 server is also
located on a router's control plane, meaning a disruptive router
restart may also be required.

Regards,
Mark.


> > 
> > [Upgrading discussion]
> 
> I see the point, but I don't see how this affects the design of a new RA option. If \
> someone reads and applies this draft, the decision for proposing a new RA option \
> has probably already been made. This decision is out of the scope of the document. 
> 
> Thanks for your input and apologies for the late reply!
> 
> Best regards
> 
> Dan

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]