Re: IA_PD bit in RA

[Owen DeLong <[e-mail]>]

On Dec 13, 2013, at 2:39 PM, Alexandru Petrescu <[e-mail]> wrote:

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

Examples, please?

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

The ubiquitous presence of RA doesn’t mean that we should bloat those RAs with a bit for every conceivable possible choice of configuration mechanism that some person might want to use in some obscure application. Indeed, I would argue that it means quite the opposite, that we should be very judicious in what kind of bloat we stuff into RAs.

RDNSS had a pretty compelling case, IMHO. Short of an equally compelling case, I really don’t think it’s worth the tradeoffs.

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

What-ifs are all well and good, but if you want to create the kind of protocol upheaval that you are suggesting, then I think more than what-ifs are necessary. I think that would require a very compelling use case.

Owen