Re: [v6ops] IA_PD bit in RA

[Owen DeLong <[e-mail]>]

>> 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, nor do I think I would expect there to be support for this in RA.

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.

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