Re: [v6ops] IA_PD bit in RA

[Alexandru Petrescu <[e-mail]>]

Le 13/12/2013 17:39, Owen DeLong a écrit :
>>> 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.

Well, I think I disagree.

Since the widespread SLAAC has no PD feature it's easy to consider that
a node would SLAAC its address and DHCP-PD its prefix for behind.  Or
DHCP its address and prefix.

But the M/O bits can't indicate to SLAAC address and DHCP-PD prefix.

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

Sure.  There are reasons to not use 64share altogether.  It does not
work on 4G links like CDC-Ethernet.  It has other drawbacks described in
a draft.

Instlaling 64share followed by a positive DHCP-PD Ack involves
renumbering the Host in smartphone's network, i.e. breaking their
ongoing communications (the prefix of 64share is different than the
prefix obtained by DHCP PD).

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

The smartphone may switch, but renumbering all the Hosts in smartphone's
hotspot?

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

I agree.  Althoug measuring how flows may expire may not be straightforward.

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

Hmmm... they have nothing to do (different layers).  Yes, link
association must happen before DHCP process.  Link association involves
a discovery phase.  Worse, the 3 can't be parallelized.

Their discovery algorithms work in the same way: their messages and core
data structures have similar semantics: ND's RS and DHCP's Request is
WiFi's Ass'n Request, ND's RA and DHCP's Reply is WiFi's Beacon, ND
cache and DHCP's cache is WiFi's preferred networks, etc.

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

YEs, just to say they exacerbate this perspective.

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

YEs, I agree.

I guess by most mobile world is meant smartphones on cellular links.
YEs, they are widely deployed and involve expensive business cases.

The good thing is thatthere's more to it than that: smartphones handing
over between wifi and cellular links, smartphones handing over from one
operator to another, bus train and roadside IP deployments, DMM
concepts, etc.

Alex

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