Re: RA Option Guidelines

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

      From: Alexandru Petrescu <[e-mail]>
 To: [e-mail] 
 Sent: Tuesday, 7 April 2015, 22:02
 Subject: Re: RA Option Guidelines
   
Le 03/04/2015 21:16, Brian E Carpenter a écrit :
> I'm glad y'all have got DHCPv6 sorted out. Now, as to the original
> subject of this thread: On 01/04/2015 08:26, Brian E Carpenter
> wrote:
>> 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.
>
> Do we actually agree on this, or rather on a slightly expanded
> version:
>
> RA options should be limited to link-local/subnet specific parameters
> (i.e., layer 3 parameters only) necessary for a simple unmanaged
> network. The only exception is RFC 6106 (DNS Configuration). More
> complex situations are better handled by other configuration metods
> such as DHCPv6.

It makes sense.

But, would it be possible to tell link-local subnet of a particular
Router?  I am asking because currently it is the link-local subnet of
one particular interface, the "on-link" prefix;  and it would be good to
allow a prefix in one subnet of an interface of a router be announced on
another interface of same router as "other prefix nearby".
/ I think the Route Information Option is the RA option you're looking for (RFC4191).

And still forbid one Router to read an RA and propagate its contents
further down the network.

/ I agree with this. With exception to the exceptional RA DNS options, all of the other RA option parameters are specific to the link the RA is sent over. Copying those values onto a different link doesn't make sense, because those values may not be correct for the different link. In other words, link specific RA option values need to be originated (not copied) for the link the RA is sent over.
/ RFC5505, "Principles of Internet Host Configuration" discusses these topics quite comprehensively. I'd read bits of it in the past, however I didn't realise comprehensive it was. Well worth a read.

/ Regards,/ Mark.

Alex




>
> Brian
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------