Re: [v6ops] IA_PD bit in RA

[Owen DeLong <[e-mail]>]

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

Well...

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

I suppose it is possible that someone would run a DHCP server strictly for PD and not offer up other configuration options to hosts (remember, O bit means ask DHCP for "other information"), so without the M bit, you shouldn't be expecting DHCP to provide an address.

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

The O bit doesn't specifically indicate to ask for prefix, true. However, it does indicate that there is a DHCP server available and that other information should be requested from said DHCP server.

I would think that the rational thing to do in an environment where you want to provide DHCP-PD and not other information via DHCP (which is hard for me to imagine why, but let's ignore that for the moment) would be to advertise an O bit and then answer with empty or negative responses for non PD requests.

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

But it's not going to be any worse than what happens while you don't have a prefix.

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

I believe I discussed ways to mitigate this above.

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

Why not? They're no worse off than they would have been if they'd been stuck waiting for a DHCP response.

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

If you can't be sure the flows expired (easy with TCP, harder with other protocols), then you use the Valid timer and you're done.

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

Perhaps that is because many years of research and experience has shown that these mechanisms work.

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

Mobile is a tough problem to solve, to be sure. There's lots of work and optimization to be done in this area in the future. I'm still not convinced that adding a "PD available" flag to RA provides a benefit.

Owen