Subject: [Dhcpv6bis] Omission in 3633

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Jun 2014 11:18:29 -0400

I don't know if this is on your radar or not, but Ian and I were talking about PD and the prefix length negotiation, and we noticed that the document doesn't constrain the value of the prefix length field if the client sends a prefix length with a zero prefix.   What happens if the client sends 0 for the prefix length?   Is that equivalent to not sending an IAPREFIX option?   This is arguably a harmful omission, since there have been some router implementations that assumed they would get a /64 and did bad things when they got something else.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Jun 2014 15:36:06 +0000

At least for the Cisco Prime Network Registrar DHCP server, we treat 0 as if it was unspecified (same is if just an IA_PD without an IAPREFIX was requested). This gets the 'default' value configured by the administrator (it defaults to /64) for the prefix(es) from which the server will delegate for that request.

For all other values, we obviously bound the values to what is configured to be allowed (so if a client asks for a /1 but you only allow /60 to /64, we assume client asked for /60).

The issue of what this 'hint' means is also a tricky one. For example, 'how hard' should the server try to meet the requested length (obviously within the bounds of what the server is configured to return).

Take for example the following sequence (let's assume everything is within allowed bounds):
- Client solicits for a /60, advertise returned with /60 ... Request/Reply exchanged.
- Before lease expires on server, Client reboots and solicits for a /64 (same IA_PD IA_ID) ... should the /60 be returned or should a /64 be offered? (Or perhaps client asks for /56.)
- Or, instead of /64, what if Solicit didn't specify a requested length (or /0)?

We can leave these to be policy issues for servers. But it might be better to give a bit of guidance (at the 'should' level)?

My recommendation would be that the server should try to give the client what it requested (within bounds of the what is allowed). (Our server doesn't do that as well as it could today, but there have been changes made to do so in a future release.) I suspect that once more IPv6 is in real use and more complex home networks exist, this could be an issue as it is more likely that CPEs will alter what they request over time.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Friday, June 27, 2014 11:18 AM
To: dhcpv6bis
Subject: [Dhcpv6bis] Omission in 3633

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Jun 2014 15:40:43 +0000

FYI - There is issue #114 which Fred T raised regarding hints for 3315. And I expanded it some a while back to include the PD hints (though the 0 issue wasn't part of that so I'll edit that to indicate we should clarify this).

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Friday, June 27, 2014 11:36 AM
To: Ted Lemon; dhcpv6bis
Subject: Re: [Dhcpv6bis] Omission in 3633

- Bernie