Re: RFC 3315 17.1.3. Receipt of Advertise Messages
Shahid Mahmood
Fri Feb 17 15:39:34 2017
On Wed, Feb 15, 2017 at 10:42 AM, Shahid Mahmood <shahid.avaya@xxxxxxxxx>
wrote:
>
>
> On 2/14/2017 6:51 PM, Neal P. Murphy wrote:
>
> On Tue, 14 Feb 2017 22:26:04 +0000
> Roy Marples <roy@xxxxxxxxxxxx> <roy@xxxxxxxxxxxx> wrote:
>
>
> Hi
>
> On 13/02/2017 16:31, Shahid Mahmood wrote:
>
> On Sun, Feb 12, 2017 at 5:12 PM, Roy Marples <roy@xxxxxxxxxxxx<mailto:roy@xxxxxxxxxxxx> <roy@xxxxxxxxxxxx>> wrote:
>
> Hi Shahid
>
> On 10/02/17 15:37, Shahid Mahmood wrote:
> > Hello Roy,
> > Just a quick question on section 17.1.3 of RFC 3315. It states 3
> options
> > available to the client in order to select and Advertise message:
> >
> > --- quote
> >
> > Upon receipt of one or more valid Advertise messages, the client
> > selects one or more Advertise messages based upon the following
> > criteria.
> >
> > - Those Advertise messages with the highest server preference
> value
> > are preferred over all other Advertise messages.
> >
> > - Within a group of Advertise messages with the same server
> > preference value, a client MAY select those servers whose
> > Advertise messages advertise information of interest to the
> > client. For example, the client may choose a server that
> returned
> > an advertisement with configuration options of interest to the
> > client.
> >
> > - The client MAY choose a less-preferred server if that server
> has a
> > better set of advertised parameters, such as the available
> > addresses advertised in IAs.
> >
> > --- end quote
> >
> > Specifically, when does client pick the last option:
> >
> > - The client MAY choose a less-preferred server if that server
> has a
> > better set of advertised parameters, such as the available
> > addresses advertised in IAs.
> >
> > Also, can application influence this choice (with parameter or
> something)?
>
> Currently there is no preference selection available.
> dhcpcd binds the first one received and keeps it. It does not change to
> another lease as such.
>
>
> It is observed that dhcpc picks the first server if two happen to send
> Advertize almost simultaneously.
> The first advertize has Pref-Value 250, 2nd one 253. It does not seem to
> follow 1st bullet in sec 17.1.3 in RFC 3315.
>
>
>
> Because dhcpcd can trivially remove the lease it applied, changing to a
> new lease from a new server wouldn't be too onerous. How would you say
> to prefer one over another?
>
>
> At this point, I just wanted to confirm if the behavior is in accordance
> with the RFC.
>
> Section 17.1.3 says the client MAY select a better server, not MUST.
> So yes, in the strict sense dhcpcd is in compliance even though it
> ignores the option.
>
> Making dhcpcd react to a more preferred server right away would be quite
> easy.
> Storing the adverts for a period of time and then choosing the more
> preferred one to bind to would be trickier.
> Right now, I'm not sure which is the better solution.
>
> Or maybe something in the middle. Save the first advert received. Then for 2-5 seconds, receive an advert, compare it with the saved advert, and save the 'better' one. At timeout, use the saved advert. Of course, determining 'better' may be the real challenge.
>
> Does it make sense to choose a route now, then later change if a better offer comes along?
>
> N
>
> As per RFC section quoted above:
>
> - Those Advertise messages with the highest server preference
> value. Those Advertise messages with the highest server preference
> value
>
> Is this a *must* or *may* ?
>
>
>
Hi Roy,
Can you clarify this please. Need to document the behavior in case of
multiple IPv6 Advertisements received within 1s.
True or false:
- dhcpcd picks the very first Advertisement, ignoring any other
- dhcpcd does not implement RFC sec 17.1.3 bullet one as mentioned above.
- dhccpd still complies to all *must* RFC requirements.
Also please point out if it is documented somewhere.
Thanks.
-shahid
Archive administrator: postmaster@marples.name