Re: [v6ops] IA_PD bit in RA

[Owen DeLong <[e-mail]>]

>> Treat it as no response until you get one.
> 
> There is a problem in the until.
> 

Is there? What? What would you do differently with a deterministic no?

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

Does it matter? What matters is that you don't have a prefix to delegate.

Again, I ask... What do you do differently with a deterministic no vs. a lack of information?

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

It would also lead to a number of other problems in many networks.

>> 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 you have DHCP service present, then, you should get a denial response to IA_PD relatively quickly if you ask. The timeout should only apply to circumstances where there is no DHCP.

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

If the DHCP service is present, you should see an M or O bit in the RA. However, that shouldn't control whether you indicate your desire for a prefix or not.

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

I'm not sure what you mean by insist in this context. I would agree that there is no reason to persist with alternative requests in the absence of a denial. That you should, instead, retry the same request until receiving an acknowledgement or a denial.

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

Is there any reason not to use 64share mode until you receive a positive DHCP response?

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

No, it must emit a request. It does not have to wait for the response, the response can be processed asynchronously. I don't see the decision to use 64share is wrong so much as suboptimal. It's not at all invalid to use 64share until receiving the PD and then switch to the delegated prefix. If you want to provide a better user experience, 64share behavior can be preserved for some duration until early flows expire. Simply stop including 64share prefix in locally generated RAs and wait for valid timer to count down.

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

Discovering an AP has nothing to do with DHCP and has to happen well before the first piece of the DHCP process.

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

If you're doing frequent handovers and they are changing your layer 3 topology frequently then you already have a number of other problems which go well beyond the difficulties you are describing here.

Most frequent handovers in the mobile world do not affect the layer 3 information.

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

Among other reasons.

Owen

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