Subject: [dhcwg] What triggers a DHCP Information Request?

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 09:53:06 -0500

When a new router is seen that sets the 'O' bit in its RA?   When a new prefix is seen, for the same router?   Only when a new link is detected?

I think that it should happen whenever a new prefix is seen for a router that's set the O bit, but Lorenzo Colitti thinks that a new prefix doesn't (and shouldn't) trigger a new Information Request.

Any thoughts about this?

---

From: Timothy Winters <[email-masked]>
Date: Thu, 16 Oct 2014 11:01:49 -0400

Hi Ted,
	 At the IOL I'm not aware of many DHCPv6 clients that trigger the DHCPv6 Information Request based on addresses being added.  I could see the case of when you lose all Global address (including ULA) a device might send one, but I would be surprised if they send when when new prefixes are found.   I can look closer into this to see what triggers it, give me a couple of days and I'll report back. 

~Tim

On Oct 16, 2014, at 10:53 AM, Ted Lemon <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 10:25:34 -0500

> 	 At the IOL I'm not aware of many DHCPv6 clients that trigger the DHCPv6 Information Request based on addresses being added.  I could see the case of when you lose all Global address (including UL…

That seems broken, because you probably want to refresh the source address selection policy table whenever you see a new prefix.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Oct 2014 15:42:19 +0000

This might be a good issue to add in the 3315bis issues list - recommendations on when to initiate an Information-Request based on network changes.

I would guess that most clients trigger it when the refresh time (OPTION_INFORMATION_REFRESH_TIME option) expires or when some application request some data that hasn't been obtained (if the OS has this capability)?

Probably something (at least for the address selection policy table) that should have been covered in RFC 7078.

The text there is:

   The received information can be considered stale in several cases,
   e.g., when the interface goes down, the DHCP server does not respond
   for a certain amount of time, or the Information Refresh Time has
   expired.

Of course, the list is just 'e.g.' so could include more.

And, there might be some rate limiting that is applicable in case there is flapping of the RA prefix information.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2014 11:28:35 -0500

> And, there might be some rate limiting that is applicable in case there is flapping of the RA prefix information.

I think that the fix there is to fix the RA flapping.   Having a burst of DHCP messages might be a useful indicator of network health.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Oct 2014 13:14:37 -0400

Bernie Volz (volz) <[email-masked]> wrote:
    > I would guess that most clients trigger it when the refresh time
    > (OPTION_INFORMATION_REFRESH_TIME option) expires or when some
    > application request some data that hasn't been obtained (if the OS has
    > this capability)?

I think that maybe DHC WG should consider if having such an API defined
would be important now... I think that applications *should* be given such an
API would use it more.

I imagine that there are OS (and on Linux, distro-specific) ways to get the
information, but I know of none that let an application request new info.

(In some cases, it should be unified with a service discovery system)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Oct 2014 18:33:29 +0000

Here's a link to Microsoft's - http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx.

If you know of others, perhaps worth providing those links.

Perhaps someone has interest in working to define such an API.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Thursday, October 16, 2014 1:15 PM
To: dhcwg
Subject: [dhcwg] DHCPv6 APIs for applications

    > application request some data that hasn't been obtained (if the OS has

I think that maybe DHC WG should consider if having such an API defined would be important now... I think that applications *should* be given such an API would use it more.

I imagine that there are OS (and on Linux, distro-specific) ways to get the information, but I know of none that let an application request new info.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 17 Oct 2014 10:49:22 +0200

Le 16/10/2014 16:53, Ted Lemon a écrit :
> When a new router is seen that sets the 'O' bit in its RA?   When a
> new prefix is seen, for the same router?   Only when a new link is
> detected?
>
> I think that it should happen whenever a new prefix is seen for a
> router that's set the O bit, but Lorenzo Colitti thinks that a new
> prefix doesn't (and shouldn't) trigger a new Information Request.
>
> Any thoughts about this?

Along these lines, in Mobile IP implementations, a mobile node triggers 
a BU when a new prefix is received in the RA. (because it thinks that if 
a new prefix is in the RA then it must form a new Care-of Address, and 
supposedly it moved towards a new attachment point).

It makes sense that a new prefix shows up, and has O bit set, the node 
should trigger an Information Request.

This would be desirable tandem working between RA and DHCP, if possible.

Alex

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Oct 2014 11:03:16 -0700

At Thu, 16 Oct 2014 09:53:06 -0500,

> I think that it should happen whenever a new prefix is seen for a router that's set the O bit, but Lorenzo Colitti thinks that a new prefix doesn't (and shouldn't) trigger a new Information Request.

Are you asking what should happen per the protocol specification
(RFCs), or what should happen operationally?  Or what actual
implementations do, or something else?

Regarding the first, my understanding is that this is actually open.
As you probably know, the semantics of 'O' bit is way too unclear
(partially intentionally so at the time of RFC 4861, and has never
been clarified sufficiently).  So, for example, triggering DHCPv6
information request based on seeing a new IPv6 prefix is not a
protocol-defined behavior, but wouldn't break the protocol either.

I don't know whether there's a commonly agreed behavior of different
implementations.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2014 13:45:07 -0500

> implementations do, or something else?
The middle two.

> protocol-defined behavior, but wouldn't break the protocol either.

Yes.  I think it should be a protocol-defined behavior, at least as recommended behavior.

---

From: Tim Chown <[email-masked]>
Date: Sun, 19 Oct 2014 23:50:12 +0100

Hi,

> And, there might be some rate limiting that is applicable in case there is flapping of the RA prefix information.

I agree with Bernie and Ted. 

It would make sense to fetch at the very least a (potentially) new policy table when a new prefix is advertised. 

With hindsight I wish we’d added, or proposed adding, “or a new prefix information is received” in the RFC 7078 text above while it was still in draft status, at least to flush out consensus on the question back then.  

But we should get a clear recommendation somewhere to maximise consistency in behaviour. If a 3315-bis is in the works, that seems as good a place as any, given that also obviously predates RFC 4242 on the refresh timer.

Tim

---

From: Simon Hobson <[email-masked]>
Date: Mon, 20 Oct 2014 09:17:01 +0100

> It would make sense to fetch at the very least a (potentially) new policy table when a new prefix is advertised. 

+1
IMO if the RAs being advertised change - whether that's a router appearing or disappearing, or a prefix being added or deleted - then that means "something" has changed on the network. When that happens it makes sense to ask what the current config for our devide looks like - even if the current config is "no change" from the previous config.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 20 Oct 2014 08:03:56 +0100

+1

---

From: Timothy Winters <[email-masked]>
Date: Mon, 20 Oct 2014 09:06:18 -0400

Hi Ted,
	After some quick research here at the UNH-IOL, we don’t have any OS that will send a DHCPv6 Information Request when a new prefix arrives in an RA.   It would seem that most implementations only trigger it when the O flag changes.   There might be some other cases that send DHCPv6 Information Request depending on what parameters change, Router lifetime for example.   Let me know if you want us to look into other things.

~Tim

> On Oct 20, 2014, at 3:03 AM, Simon Hobson <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Oct 2014 09:27:36 -0400

> 	After some quick research here at the UNH-IOL, we don’t have any OS that will send a DHCPv6 Information Request when a new prefix arrives in an RA.   It would seem that most implementations only t…

Wow, thanks for the quick response!   I guess we have our work cut out for us!