Re: [v6ops] IA_PD bit in RA

[Alexandru Petrescu <[e-mail]>]

Le 13/12/2013 16:49, Owen DeLong a écrit :
>
> On Dec 13, 2013, at 3:22 AM, Alexandru Petrescu
> <[e-mail]> wrote:
>
>> Le 12/12/2013 20:05, Owen DeLong a écrit :
>>>> (should the RA provide the delegated prefix as well to compare
>>>> favorably to the PMIP example? but again this is the 'what if'
>>>> branch, deviating from the main CPE discussion)
>>>
>>> I don’t think anyone really wants to move PD into RA. I think
>>> that would be inappropriate, personally.
>>>
>>> Without moving the PD functionality into RA, then, I would say
>>> that the current situation is fine.
>>>
>>> CPE should ask for PD if it wants a prefix. It should deal with
>>> one of five possible results in response:
>>>
>>> 1.No response
>>
>> As one senses it, implementing it is not easy.
>>
>> How would one implement the decision 'no response' other than
>> waiting for one a certain amount of time?  That wait is what makes
>> people think it takes too long, especially mobile people.
>
> Treat it as no response until you get one.

There is a problem in the until.

Until one gets an answer one can't decide whether or not there is
DHCP-PD available.  And if one does not have enough time to wait then
one would quickly decide there is no DHCP-PD available.

On another hand, frequent beacon telling precisely whether or not
DHCP-PD is available would lead to more informed decisions.

> Really, what are you going to do differently after you get denied a
> prefix (assuming a model of active denial like you suggest) than you
> can do while you’re waiting and haven’t yet received a prefix?

But there is a difference in being denied a particular prefix and DHCP
service absence altogether.

If the DHCP service is present, there are DHCP means to insist upon
being denied a particular prefix (requester another one, etc).

If the service is absent there is no reason to insist.

> Either way, you have nothing to delegate to your subordinate
> networks.

Right.

If the network tells the node there is no DHCP service to look for, then
the node may decide to fall back into a 64share mode, or so.  This can
happen very quickly (it boils down to evaluating the probability of time
length between the random link up signal and the next periodic RA).

If on another hand the network does not tell the node whether DHCP is
present, then the node must emit a request and wait for a response.  If
it waits too short and decides there is no service DHCP, even if there
is one, then the subsequent decision to use 64share is a wrong decision.

That's why conservative DHCP discovery phases take long, and also that's
why conservative WiFi AP discovery clients take long, whereas quick such
clients often miss some important Access Point.

This distinction is even more important for entities which are mainly
mobile, doing frequent handovers.

(I guess it is also the reason why 802.11p removes altogether all
beaconing and discovery activities of 802.11bgn, and proposes a new
timestamp beacon - too long for essentially moving devices.)

Alex

>
>>
>> Alex
>>
>>> 2.Denial 3.Requested prefix size granted 4.Longer prefix
>>> (smaller net block) granted 5.Shorter prefix (larger net block)
>>> granted
>>>
>>> Nobody has yet made a good case for why this behavior is
>>> problematic.
>>>
>>> Owen
>>>
>>
>
>
>