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

[Marcin Siodelski <[e-mail]>]

Alexandru,

On 23.07.2015 14:38, Alexandru Petrescu 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.
> 

Where is this stated in the draft that the prefix will be used on the
interface on which the Solicit has been issued?

Per this section of RFC3633:

"   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router."

the requesting router must not use the prefix on the server facing
interface.


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

Marcin