Subject: [dhcwg] review of ietf-dhcpv6-server-yang-06

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 May 2018 14:09:44 +0200 (CEST)

Hi,

I have tried to map what's possible to configure (and how it's configured) 
of odhcpd and odhcp6c in OpenWrt to what exists in the proposed dhcpv6 
server/client models. I looked at "could this support the DHCP model 
proposed in the IETF" and also "is the IETF proposed model missing 
something that is used in odhcpd".

My run-through yielded quote a lot of things that would work just fine to 
implement there, but there are some comments as well.

1. odhcpd has lease-times as operational data. This seems to be missing 
from the IETF server model? It seems like something that should be added.

2. The IETF model has lots of "mandatory true;" statements, for things 
that are not configurable in odhcpd. Some things are "lease time 
parameters" where odhcpd has a lease time that is configurable, and all 
the other values are just derived from that value. This means the other 
values are not configurable. Reading the IETF model, I think lots of 
"mandatory true;" can be removed without ill effects.

3. odhcpd has just one set of pools per server, and you can't create more 
advanced configurations. Being able to represent this with some kind of 
max-entry in lists would be beneficial.

4. odhcpd supports IPv4. If someone in the future wants to look into 
making an DHCPv4 IETF model, they can look into what's possible to do 
there.

The odhcpd model that we're currently working on can be found here:

https://github.com/sartura/dhcp/blob/devel/yang/terastream-dhcp%402017-12-07.yang

It contains most (if not all) configuration settings that is possible to 
do using the configuration interface for odhcpd (OpenWrt UCI/ubus). I am 
not proposing this as a standard model, but if someone wants more insight 
into what can be done with odhcpd, they'd probably get a better 
understanding by reading that one. It's by no means finished and we 
already have several things we're going to change in it, but ... just 
wanted people to be able to see it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Zihao He <[email-masked]>
Date: Tue, 15 May 2018 20:47:22 +0800

Hi Mikael,

Thanks for your suggestions regarding the further improvement of this IETF DHCPv6 YANG model. I think they look good but I have some questions about some of them. Please see the comments inline.

Besides, you are also welcome to comment directly by opening new issues on the official github if you have further comments.   https://github.com/dhcwg/yang/issues

Thanks,

Zihao

On 5/15/2018 20:09，Mikael Abrahamsson<[email-masked]> wrote：

Hi,

Zihao - Actually we have parameters such as "valid-lifetime", "preferred-lifetime", "renew-time" and "rebind-time" that can be configured at address/pd-pool level. Are these parameters "lease-times" that you mean?

Zihao - Thanks for your comment. But I am sorry that I don't quite understand the benefit of doing so. Could you please explain more about this?

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 May 2018 14:59:16 +0200 (CEST)

>       "lease-times" that you mean?

Correct, but i am talking about the "config false;" container server-state 
{}, not the configuration. I can't find any of the ones you're talking 
about in the operational data.

list binding-info {
 	        			key cli-id;
 	        			description "A list records a binding information for each DHCPv6
 	        				client that has already been alloated IPv6 prefixes.";

Here I imagine all the IA_NA and IA_PD bindings are listed (two different 
lists), but from what I can tell, there is no way to tell how much 
valid-lifetime there is left on these bindings?

>       Zihao - Thanks for your comment. But I am sorry that I don't quite understand the benefit of doing so. Could you please explain more about this?

If the NMS understands that there can be only one item in a list (or any 
value), then it will never try to configure a list with more items 
(causing the device to return an error). So being able to represent this 
limitation in the model would be beneficial.

---

From: Zihao He <[email-masked]>
Date: Wed, 16 May 2018 11:00:45 +0800

Hi Mikeal,

Thank you so much. I think I understand them. We will revise the model accordingly.

Also, thanks for your mentioning the  odhcpd model. I will read through it and try to find some insights from it. :)

Best,

Zihao

On 5/15/2018 20:59，Mikael Abrahamsson<[email-masked]> wrote：

Zihao - Actually we have parameters such as "valid-lifetime", "preferred-lifetime", "renew-time" and "rebind-time" that can be configured at address/pd-pool level. Are these parameters
"lease-times" that you mean?

list binding-info {
key cli-id;

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 May 2018 07:25:55 +0200 (CEST)

> Also, thanks for your mentioning the  odhcpd model. I will read through it and try to find some insights from it. :)

Thanks. You never replied to my "mandatory true;" comment in my original 
email, do you have any thoughts on that?

---

From: Zihao He <[email-masked]>
Date: Wed, 16 May 2018 13:54:58 +0800

Dear Mikeal,

Sorry for my carelessness. I agree with that comment. Actually we discussed this before but it seems there are still some superfluous 'mandatory true' statements. I would appreciate it if you could specify a few items that you think shouldn't be mandatory.

Thanks,

Zihao

On 5/16/2018 13:25，Mikael Abrahamsson<[email-masked]> wrote：

Hi Mikeal,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 May 2018 08:33:45 +0200 (CEST)

On Wed, 16 May 2018, Zihao He wrote:

> Dear Mikeal,
> Sorry for my carelessness. I agree with that comment. Actually we discussed this before but it seems there are still some superfluous 'mandatory true' statements. I would appreciate it if you could specify a
> few items that you think shouldn't be mandatory.

Ok, I'll just go through and paste some of them (there are 74 instances of 
the string "mandatory true;" in the document), with a comment for each. 
This is not an exhaustive list, but examples of comments.

  leaf network-description {
 	        	type string;
 	        	mandatory true;
 	        	description "description of the subnet";
 	        }

Not all dhcp servers will have the concept of "description of subnet".

leaf valid-lifetime {
               	type yang:timeticks;
               	mandatory true;
               	description "valid liftime for IA";
             	}
             	leaf renew-time {
               	type yang:timeticks;
               	mandatory true;
               	description "renew time";
               }
             	leaf rebind-time {
               	type yang:timeticks;
               	mandatory true;
               	description "rebind time";
             	}
             	leaf preferred-lifetime {
 	              type yang:timeticks;
 	              mandatory true;
 	              description "preferred lifetime for IA";
              	}

In odhcpd there is the concept of "leasetime", and all the other values 
are calculated from that. So most of the above aren't configurable at all.

             	leaf rapid-commit {
 	        			type boolean;
 	        			mandatory true;
 	        			description "A boolean value specifies whether the pool
 	        			supports client-server exchanges involving two messages.";
 		    			}

If the server doesn't support rapid-commit, it'd have to specifically 
deviate from this. Perhaps this should be changed into a feature or 
something.

             	leaf max-address-count {
               	type threshold;
               	mandatory true;
               	description "maximum count of addresses that can
               		be allocated in this pool. This value may be
               		less than count of total addresses.";
             	}

What if the server doesn't support this concept?

leaf max-pd-space-utlization {
                 type threshold;
                 mandatory true;
                 description "Maximum utilization of pd space in this pool";

Not all will support this.

list relays {
         	key relay-name;
         	description "relay agents";
         	leaf relay-name {
            	type string;
            	mandatory true;
            	description "relay agent name";
           }

What if the server doesn't support being a relay? Perhaps this should be 
turned into a feature. Or if a relay can't be a server? That perhaps also 
should be a feature.

So these are just some examples. I think you should go over the entire 
document and for each "mandatory true;" you should consider: "Will things 
not work at all without this?" If the answer is no, then it probably 
should not be mandatory?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 May 2018 08:43:56 +0200 (CEST)

On Wed, 16 May 2018, Mikael Abrahamsson wrote:

> turned into a feature. Or if a relay can't be a server? That perhaps 
> also should be a feature.

Hi, sorry, this might be unclear.

I am referring to:

https://tools.ietf.org/html/rfc6020#section-8.2

Since not everybody implements everything (relay/server/both), perhaps 
some of these can be done by means of "if-feature"?

---

From: Zihao He <[email-masked]>
Date: Wed, 16 May 2018 14:54:00 +0800

Hi Mikeal,

Thank you so much for listing these items. From these examples I think I got what kind of statements should be non-mandatory. We will revise them.

Actually I know what you imply by 'feature', but still many thanks for elaborating it. :)

Thanks again,

Zihao

On 5/16/2018 14:43，Mikael Abrahamsson<[email-masked]> wrote：

I am referring to:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 May 2018 15:54:54 +0000

This discussion got me to look at this again and I’m wondering why we have renew-time and rebind-time at all? These are supposed to be calculated based on the 0.5 and 0.85 (default) factors and not something that one would typically configure?

There are also cases where servers may not use the configured values – such as for failover where MCLT may limit value – and hence using “fixed” values is kind of pointless.

I’d think that overriding the 0.5 (renew) and 0.85 (rebind) time factors would be something useful, but not the explicit values.

BTW: regarding the “lease-time” question for odhcp in Mikael’s earlier thread, wouldn’t this perhaps map to the “valid-lifetime” (and “preferred-lifetime”)? What does odhcp send out for these two values (the same “lease-time”)?

-          Bernie

From: dhcwg <[email-masked]> On Behalf Of Zihao He
Sent: Wednesday, May 16, 2018 2:54 AM
To: Mikael Abrahamsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] review of ietf-dhcpv6-server-yang-06

Hi Mikeal,

Thanks again,
Zihao
On 5/16/2018 14:43，Mikael Abrahamsson<[email-masked]><mailto:[email-masked]> wrote：

I am referring to:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 May 2018 18:35:18 +0200 (CEST)

On Wed, 16 May 2018, Bernie Volz (volz) wrote:

> BTW: regarding the “lease-time” question for odhcp in Mikael’s earlier 
> thread, wouldn’t this perhaps map to the “valid-lifetime” (and 
> “preferred-lifetime”)? What does odhcp send out for these two values 
> (the same “lease-time”)?

With leasetime set to 43200 seconds and odhcpd as DHCPv4/v6 server, for 
IPv4 it takes the leasetime, but for IPv6 it takes the valid time on WAN 
for its RAs and leases there, and uses that to calculate timers for LAN 
for IA_NA and IA_PD (which is the right thing to do).

I have no idea how to work this into yang model magic since leasetime is 
then "ephemeral" and will change depending on what's happening on its WAN 
and the PD it has received.

18:29:55.489499 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto 
UDP (17), length 328)
     0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 64:66:b3:de:ff:fc, length 300, xid 0x296a47cc, Flags [none] (0x0000)
 	  Client-Ethernet-Address 64:66:b3:de:ff:fc
 	  Vendor-rfc1048 Extensions
 	    Magic Cookie 0x63825363
 	    DHCP-Message Option 53, length 1: Discover
 	    MSZ Option 57, length 2: 576
 	    Parameter-Request Option 55, length 8:
 	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
 	      Domain-Name, BR, NTP, Classless-Static-Route
 	    Vendor-Class Option 60, length 12: "udhcp 1.25.1"
 	    END Option 255, length 0
 	    PAD Option 0, length 0, occurs 28
18:29:55.490862 IP (tos 0x0, ttl 64, id 4696, offset 0, flags [none], proto UDP (17), length 331)
     192.168.1.1.67 > 192.168.1.228.68: [bad udp cksum 0x857e -> 0x94f8!] BOOTP/DHCP, Reply, length 303, xid 0x296a47cc, Flags [none] (0x0000)
 	  Your-IP 192.168.1.228
 	  Server-IP 192.168.1.1
 	  Client-Ethernet-Address 64:66:b3:de:ff:fc
 	  Vendor-rfc1048 Extensions
 	    Magic Cookie 0x63825363
 	    DHCP-Message Option 53, length 1: Offer
 	    Server-ID Option 54, length 4: 192.168.1.1
 	    Lease-Time Option 51, length 4: 43200
 	    RN Option 58, length 4: 21600
 	    RB Option 59, length 4: 37800
 	    Subnet-Mask Option 1, length 4: 255.255.255.0
 	    BR Option 28, length 4: 192.168.1.255
 	    Default-Gateway Option 3, length 4: 192.168.1.1
 	    Domain-Name-Server Option 6, length 4: 192.168.1.1
 	    Domain-Name Option 15, length 3: "lan"
 	    NTP Option 42, length 4: 192.168.1.1
 	    END Option 255, length 0
18:29:55.491559 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
     0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 64:66:b3:de:ff:fc, length 300, xid 0x296a47cc, Flags [none] (0x0000)
 	  Client-Ethernet-Address 64:66:b3:de:ff:fc
 	  Vendor-rfc1048 Extensions
 	    Magic Cookie 0x63825363
 	    DHCP-Message Option 53, length 1: Request
 	    Requested-IP Option 50, length 4: 192.168.1.228
 	    Server-ID Option 54, length 4: 192.168.1.1
 	    MSZ Option 57, length 2: 576
 	    Parameter-Request Option 55, length 8:
 	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
 	      Domain-Name, BR, NTP, Classless-Static-Route
 	    Vendor-Class Option 60, length 12: "udhcp 1.25.1"
 	    END Option 255, length 0
 	    PAD Option 0, length 0, occurs 16
18:29:55.492950 IP (tos 0x0, ttl 64, id 4697, offset 0, flags [none], proto UDP (17), length 331)
     192.168.1.1.67 > 192.168.1.228.68: [bad udp cksum 0x857e -> 0x91f8!] BOOTP/DHCP, Reply, length 303, xid 0x296a47cc, Flags [none] (0x0000)
 	  Your-IP 192.168.1.228
 	  Server-IP 192.168.1.1
 	  Client-Ethernet-Address 64:66:b3:de:ff:fc
 	  Vendor-rfc1048 Extensions
 	    Magic Cookie 0x63825363
 	    DHCP-Message Option 53, length 1: ACK
 	    Server-ID Option 54, length 4: 192.168.1.1
 	    Lease-Time Option 51, length 4: 43200
 	    RN Option 58, length 4: 21600
 	    RB Option 59, length 4: 37800
 	    Subnet-Mask Option 1, length 4: 255.255.255.0
 	    BR Option 28, length 4: 192.168.1.255
 	    Default-Gateway Option 3, length 4: 192.168.1.1
 	    Domain-Name-Server Option 6, length 4: 192.168.1.1
 	    Domain-Name Option 15, length 3: "lan"
 	    NTP Option 42, length 4: 192.168.1.1
 	    END Option 255, length 0
18:29:56.947376 IP6 (flowlabel 0xef3b8, hlim 1, next-header UDP (17) payload length: 114) fe80::6666:b3ff:fede:fffc.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=881468 (elapsed-time 103) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list server-unicast SNTP-servers NTP-server AFTR-Name opt_67 opt_82 opt_83 opt_94 opt_95 opt_96) (client-ID hwaddr type 1 6466b3defffc) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0))
18:29:56.948730 IP6 (hlim 64, next-header UDP (17) payload length: 170) fe80::222:7ff:fe6f:1512.547 > fe80::6666:b3ff:fede:fffc.546: [udp sum ok] dhcp6 advertise (xid=881468 (server-ID hwaddr type 1 0022076f1512) (client-ID hwaddr type 1 6466b3defffc) (opt_82) (DNS-server fe80::222:7ff:fe6f:1512) (DNS-search-list lan.) (reconfigure-accept) (IA_NA IAID:1 T1:1181 T2:1889 (IA_ADDR 2003:1c09:24:1538::d6f pltime:2362 vltime:2962)) (IA_PD IAID:1 T1:1181 T2:1889 (IA_PD-prefix 2003:1c09:24:153c::/62 pltime:2362 vltime:2962)))
18:29:57.218138 IP6 (flowlabel 0xef3b8, hlim 1, next-header UDP (17) payload length: 185) fe80::6666:b3ff:fede:fffc.546 > ff02::1:2.547: [udp sum ok] dhcp6 request (xid=49851b (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list server-unicast SNTP-servers NTP-server AFTR-Name opt_67 opt_82 opt_83 opt_94 opt_95 opt_96) (client-ID hwaddr type 1 6466b3defffc) (server-ID hwaddr type 1 0022076f1512) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2003:1c09:24:1538::d6f pltime:2362 vltime:2962)) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2003:1c09:24:153c::/62 pltime:2362 vltime:2962)))
18:29:57.219398 IP6 (hlim 64, next-header UDP (17) payload length: 202) fe80::222:7ff:fe6f:1512.547 > fe80::6666:b3ff:fede:fffc.546: [udp sum ok] dhcp6 reply (xid=49851b (server-ID hwaddr type 1 0022076f1512) (client-ID hwaddr type 1 6466b3defffc) (opt_82) (DNS-server fe80::222:7ff:fe6f:1512) (DNS-search-list lan.) (reconfigure-accept) (authentication proto: reconfigure, alg: HMAC-MD5, RDM: mono, RD: 5afc 5c85 0000 0006 reconfig-key value: 535397be 8c00db0c 8cfb968d 75bdeb37) (IA_NA IAID:1 T1:1180 T2:1888 (IA_ADDR 2003:1c09:24:1538::d6f pltime:2361 vltime:2961)) (IA_PD IAID:1 T1:1180 T2:1888 (IA_PD-prefix 2003:1c09:24:153c::/62 pltime:2361 vltime:2961)))

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 May 2018 18:10:49 +0000

In this case, wouldn’t it just report the lifetimes that it would give a client? This wouldn’t be something you can configure via the Yang model, but the device can certainly report those values if it were to be queried for the configuration via Yang model.

- Bernie

On 5/16/18, 12:35 PM, "Mikael Abrahamsson" <[email-masked]> wrote:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 May 2018 21:08:07 +0200 (CEST)

On Wed, 16 May 2018, Bernie Volz (volz) wrote:

> In this case, wouldn’t it just report the lifetimes that it would give a 
> client? This wouldn’t be something you can configure via the Yang model, 
> but the device can certainly report those values if it were to be 
> queried for the configuration via Yang model.

Right, but the consequence is that none of the lifetime settings should be 
"mandatory true;". At least in odhcpd, it seems this can't really be set 
(at least for IPv6 when PD has been received from somewhere else).

Operational data for these values can of course be shown, such as 
remaining lifetime of the lease.