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

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 14:38:34 +0200

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

---

From: Dan Seibel <[email-masked]>
Date: Thu, 23 Jul 2015 06:54:30 -0600

For #1 I would think sending a solicit with IA_PD is how you can find out if the server supports it.  If it does you will get a prefix returned, if not you will get a Noaddrsavail for the IA.

> On Jul 23, 2015, at 6:38 AM, Alexandru Petrescu <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 23 Jul 2015 13:41:32 +0000

Actually for IA_PD you would get NoPrefixAvail (and that is in the Status Code option encapsulated in the IA_PD).

I think there may be servers that do not support (implement) IA_PD at all, which would result in no IA_PD in the Advertise (or Reply).

So a client should handle both cases.

---

Also, the best way to assure a completely new delegated prefix (or an address), is to send a new IAID in the IA_PD. This assures the device would get a new delegated prefix. The client can release the old one or just let it gracefully expire.

There are some negative consequences with this changing the IAID of the IA_PD if the device has no persistent storage since rebooting the device would cause it to use the original IAID on the IA_PD and then it would either get another prefix or the original one back (if the original hadn't been released or expired, ignoring any kind of grace time issues that a server might use).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Dan Seibel
Sent: Thursday, July 23, 2015 8:55 AM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

> 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.
> 
> 2. when this Router changes mind and requests a different prefix, 
> maybe with a different length, a specification like 
> deprecate that prefix with specific consideration to below it, not 
> just to the Server.
>

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 27 Jul 2015 16:20:58 +0200

Alexandru,

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

>> propagating it in the routing protocol.

Marcin