Subject: [mif] Preserving ND data structures when DHCP default route, why, command to issue

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Mar 2012 20:06:40 +0200

In a discussion, I was shown a command line, and told that adding a
default route is as simple as typing this, why bothering this much.

# route add default ...

I wanted then to say this below but didn't have time.

# ip -6 route show
default via 2002:c130:13c1:11f::ff dev eth0  proto kernel metric 1024
expires 7752sec mtu 1500 advmss 1440 hoplimit 0
         ^^^^

Note that 'expires' field.  If RS/RA are not used, but DHCPv6
route-option is used with 32bit lifetimes instead of 16bit lifetimes,
would one think there may be a risk for that 'expires' field to
overflow?  Or to be understood wrongly by ND (if present), like not
knowing when to send the RS to update the data?  Or like simply crashing?

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Mar 2012 20:31:40 +0000

> expires 7752sec mtu 1500 advmss 1440 hoplimit 0

Okay, the route has a lifetime <7752s.   So?

> knowing when to send the RS to update the data?  Or like simply crashing?

How do you think the route show command computed that value?   Do you think there's a field in a routing table entry somewhere that contains the number 7752, and a process somewhere that subtracts one from that field once every second?   No, the field in the structure contains (time_t)now + 7752, and the route command subtracted (time_t)now from the value of the field to give you the number 7752.

So yes, of course there's a risk that an implementation will be broken.   This risk exists whether the offset is 16 bits or 32 bits; it depends solely on how soon it is before (time_t) overflows.   If someone codes up a routing table implementation that contains this flaw, I'm sure much lulz will come of it, but there is little we can do to prevent other people from making mistakes, and making the offset smaller in the DHCP packet certainly isn't an example of something that would have that result.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Mar 2012 13:47:42 +0200

Le 27/03/2012 22:31, Ted Lemon a écrit :
>> # ip -6 route show default via 2002:c130:13c1:11f::ff dev eth0
>> proto kernel metric 1024 expires 7752sec mtu 1500 advmss 1440
>> hoplimit 0 ^^^^
>
> Okay, the route has a lifetime<7752s.   So?

So what happens when it expires.  Should an RS be issued?  Should a DHCP
message be issued?

Alex

>> route-option is used with 32bit lifetimes instead of 16bit
>> lifetimes, would one think there may be a risk for that 'expires'
>> field to overflow?  Or to be understood wrongly by ND (if present),
>> like not knowing when to send the RS to update the data?  Or like
>> simply crashing?
>
> How do you think the route show command computed that value?   Do you
> think there's a field in a routing table entry somewhere that
> contains the number 7752, and a process somewhere that subtracts one
> from that field once every second?   No, the field in the structure
> contains (time_t)now + 7752, and the route command subtracted
> (time_t)now from the value of the field to give you the number 7752.
>
> So yes, of course there's a risk that an implementation will be
> broken.   This risk exists whether the offset is 16 bits or 32 bits;
> it depends solely on how soon it is before (time_t) overflows.   If
> someone codes up a routing table implementation that contains this
> flaw, I'm sure much lulz will come of it, but there is little we can
> do to prevent other people from making mistakes, and making the
> offset smaller in the DHCP packet certainly isn't an example of
> something that would have that result.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 11:54:30 +0000

> So what happens when it expires.  Should an RS be issued?  Should a DHCP

This is a really good question.   I think in order to address this question, we need 32-bit timers, so that the DHCP server can specify a lifetime longer than that of the assigned address, if any, even if that lifetime is greater than 18 hours.   In the case of stateless DHCPv6, the lifetime of the address should be greater than or equal to the IRT (RFC4242), and the document should require conforming clients to implement the IRT.