Re: [v6ops] IA_PD bit in RA

[Alexandru Petrescu <[e-mail]>]

On 13/12/2013 23:57, Owen DeLong wrote:
>
> On Dec 13, 2013, at 2:39 PM, Alexandru Petrescu
> <[e-mail] <mailto:[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?

64rd for example.

And Prefix Delegation for Mobile IPv6 based on DHCPv6 over a tunnel.

And I guess IKE as well may provide a Delegated Prefix (just a guess).


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

I agree.

But I said just the fundamental addressing aspects, those common
parameters involved in most basic setups.

And, the bits wouldn't be tied to one particular protocol (DHCP) but to
any Other protocols.  The 'O's would mean any Other, not just any  Other
DHCP.

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

Right, bloat should be avoided.  This could be done by this Other word, 
and by the RA flags expansion option anyways (existing RFC).

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

I agree.

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

I agree.

Alex

>
> Owen
>


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