Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

Thank you for providing the comments.

For #1 I agree with Bernie and Alexandru. There are two cases when a server
cannot provide a prefix:

1.  Servers which support prefix delegation, will not include an IA_PD
option in the Advertise   message.

2. Servers which support prefix delegation but cannot provide a prefix and
the time being, will return a status code of Noaddrsavail in the IA_PD
option.

The current document does assume all the servers could support prefix
delegation. I think we could add some text in “Receipt of Advertise message
by the Client” (section 3.3&4.3) describing these cases.

For #2 Yes, the client should stop sending RAs on its other interfaces. I
think we could add this text to section 4.1 “Creation of Solicit Message by
the Client”

> On Jul 23, 2015, at 6:38 AM, Alexandru Petrescu <alexandru.petrescu at gmail.com> wrote:
>
> Hello,
>
> I just read draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.
>
> I am happy this draft exists and I have two comments.  One is more
> general question in this context, and the other a potential improvement,
> but not a request.
>
> The draft assumes the Client is a Host which may request a prefix len at
> some point, and another one maybe later.  It seems the prefix is to be
> used on the interface which has issued that Solicit.  And it seems to
> face a Server sure to be willing to deliver a prefix.
>
> 1. What is the best way to query a DHCPv6 Server to ask it whether or
> not it supports Prefix Delegation at all?
>
> 2. when this Router changes mind and requests a different prefix, maybe
> with a different length, a specification like
> draft-cui-dhc-dhcpv6-prefix-length-hint-issue could recommend to
> deprecate that prefix with specific consideration to below it, not just
> to the Server.
>
> I mean this something like this:
>
> Current text:
>> 1.Deprecate the old prefix right away by sending a Release message to
>> the server, and switch over to the new prefix.
>
> New text:
>> 1.Deprecate the old prefix right away by sending a Release message to
>> the server, and switch over to the new prefix.  And by stopping
>> sending RAs on its other interfaces with the old prefix, stop
>> propagating it in the routing protocol.
>
> Alex
>
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg