Re: [v6ops] IA_PD bit in RA

[Alexandru Petrescu <[e-mail]>]

On 13/12/2013 23:01, Owen DeLong wrote:
>>> 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.
>
> There’s no support for this,

Well...

In addition to Radius and PPP, there are the migration v4-v6 mechanisms 
which may offer a v6 Delegated Prefix as well.

> nor do I think I would expect there to be support for this in RA.

But one _would_ expect RA to always be there.

> In the cases of PPP and RADIUS, you are already having an
> authentication or other negotiation process with the server and I
> would presume that there would be mechanisms in those negotiations to
> handle this. For example, in RADIUS, the prefix(es) should be sent as
> additional attribute/value pairs. In PPP, I presume it would be part
> of the IPCP6 process, but I admit I haven’t looked at those details.
>
>> 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.
>
> I don’t see the advantage to this way of approaching it. Please
> present a use case where this offers a clear advantage over the
> existing mechanisms which would warrant an incompatible modification
> to everyone else’s expectations and existing software. Absent a
> compelling advantage to such a change, I just don’t think the
> risk/reward proposition makes sesne.

I agree.

No particular use case.  This is on the 'what-if' branch.

Alex

>
>>> 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…
>
> The neighbor discovery RFC is pretty clear about it from my reading.
>  What is unique in what I propose is that you stop resetting the
> client-side valid-time and desired-time timers when you receive a
> service-side RA that would normally result in resetting them.
> However, for renumbering the client side from 64share to delegated
> prefix, it seems to me that it is very reasonable to immediately
> poison the desired time and then withdraw the prefix from subsequent
> RAs. This will allow the clients to preserve their existing flows
> until the valid timer counts down to zero. The router can remove the
> prefix from the interface at time
> <t_last_ra_issued>+<valid_time_in_last_ra_issued>.
>
> Owen
>


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