Re: [v6ops] IA_PD bit in RA

[Alexandru Petrescu <[e-mail]>]

On 13/12/2013 19:17, Owen DeLong wrote:
>>> 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.

Right, I missed this part.

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

Right - reset M, set O and answer negatively to non-PD DHCP requests.

But how about when the Delegated Prefix is available,
but via 'other other' means than DHCP such as Radius, or via PPP?  There 
is no bit for that either.  The 'O' and 'M' bits apply only to DHCP.

It would be clearer if there were 1 bit for each of the fundamental 
addressing aspects (address, default route, delegated prefix, etc.) and 
each would be 'O' - Address available by other means than this RA, 
Default route available by other means than this RA, Delegated prefix 
available by other means than this RA, etc.

Alex


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

Right.

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

I haven't seen this done elsewhere...

Alex

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


---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com