review of ietf-dhcpv6-server-yang-06

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

review of ietf-dhcpv6-server-yang-06

Mikael Abrahamsson

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: [hidden email]

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

hezihao
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[hidden email] wrote:

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.

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?


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.

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?


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: [hidden email]

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

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

Mikael Abrahamsson
On Tue, 15 May 2018, Zihao He wrote:

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

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?


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

--
Mikael Abrahamsson    email: [hidden email]

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

hezihao
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[hidden email] wrote:
On Tue, 15 May 2018, Zihao He wrote:

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.

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?

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?


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.

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.

--
Mikael Abrahamsson    email: [hidden email]

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

Mikael Abrahamsson
On Wed, 16 May 2018, Zihao He wrote:

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

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

--
Mikael Abrahamsson    email: [hidden email]
_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

hezihao
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[hidden email] wrote:
On Wed, 16 May 2018, Zihao He wrote:

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

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

--
Mikael Abrahamsson    email: [hidden email]

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

Mikael Abrahamsson
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?

--
Mikael Abrahamsson    email: [hidden email]
_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

Mikael Abrahamsson
On Wed, 16 May 2018, Mikael Abrahamsson wrote:

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

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

--
Mikael Abrahamsson    email: [hidden email]

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

hezihao
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[hidden email] wrote:
On Wed, 16 May 2018, Mikael Abrahamsson wrote:

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.

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

--
Mikael Abrahamsson    email: [hidden email]

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

Bernie Volz (volz)

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

 

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[hidden email] wrote:

On Wed, 16 May 2018, Mikael Abrahamsson wrote:

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.


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

--
Mikael Abrahamsson    email: [hidden email]


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

Mikael Abrahamsson
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)))



--
Mikael Abrahamsson    email: [hidden email]
_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

Bernie Volz (volz)
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" <[hidden email]> wrote:

    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)))
   
   
   
    --
    Mikael Abrahamsson    email: [hidden email]

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: review of ietf-dhcpv6-server-yang-06

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

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