Subject: Re: [dhcwg] Request for opinions for a question regarding the handling of M/O flags.

From: HYUN WOOK CHA <[email-masked]>
Date: Thu, 13 Mar 2008 15:04:56 +0000 (GMT)

Santosh, 
You can refer to the scenario which I discuss in the DHC wg session with the following URL.
http://www.ietf.org/mail-archive/web/dhcwg/current/msg08200.html
I agree that we do not need to solve a temporary problem caused by misconfiguration of routers. As you can see, my concern is regarding the intended scenario where routers which belong to different administrative domains are sending RA with conflict M/O flags. Since I observed that the behavior of Windows VIsta is different with RFC2462 in that it release addresses obtained via DHCPv6 on the receit of RA with M flag set to 0, I posted to discuss this issue almost two months ago. Could you explain why products by Microsoft take this behavior? 

Joseph 

------- Original Message -------
Sender : Santosh Chandwani<[email-masked]> 
Date   : 2008-03-13 18:13 (GMT+09:00)
Title  : RE: [dhcwg] Request for opinions for a question regarding the	handling
 of M/O flags.

I wasn't at the DHC meeting and don't have the context of the presentation Joseph refers to below. But based on the context I have from this thread, I don't see value in designing client behaviour for scenarios where the routers are temporarily misconfigured. That's not the steady state and should not occur except in very rare circumstances. If it happens more often than that, we have a bigger problem in that the technology is too complex for admins to handle. It is a given that when you misconfigure routers you will see behaviour less than ideal. So long as the systems recover after the misconfiguration in a reasonable amount of time, simpler behaviour is better.

I also don't have the context on Bernie's comment about people wanting to get rid of the M/O flags. However, I hope that people who suggest this realize that hundreds of millions of devices will have shipped assuming the current interpretation of A/M/O flags. Any changes made to the interpretation of these flags now will lead to a major migration and interop headache, since devices conforming to the current behaviour will still need to interop with devices that try to conform to any new behaviour which is defined. It costs enterprises millions to deploy a new version of a client or a server OS, and almost every large enterprise has a variety of OS'es in use at any given time. These customers will have a hard time choosing the right RA flag settings if we're not careful in selecting the RA flag behaviours.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: 13 March 2008 01:15
To: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Request for opinions for a question regarding the handling of M/O flags.

I just hope that this doesn't start the long drawn out debate that
existed on the wording of the M & O flags a while back.

---

One idea is to handle the M/O bits by making use of the RFC 4861
MaxRtrAdvInterval (which defaults to 600, with a maximum value of 1800
seconds) as follows:

When the node boots, the M and O bit are cleared.

When an RA is received that has the M-bit set, it is applied and the
M-timer is (re)started.
When an RA is received that has the O-bit set, it is applied and the
O-timer is (re)strarted.

If the M-timer goes off, the M-bit is cleared.
If the O-timer goes off, the O-bit is cleared.

Thus, once a bit is set, it can only be cleared after no RA is received
with the bit set within MaxRtrAdvInterval.

This means if you misconfigured a router and fix it, the new settings
(with clear M and/or O) will take MaxRtrAdvInterval seconds to take.

This means if you have multiple routers sending conflicting RAs, the
ones with the bit set will overrule the ones with the bit clear.

---

If a client has DHCPv6 leases, the existing leases (addresses or
prefixes) obtained via DHCPv6 to go through their normal lifecycle
regardless of what happens to the M bit.

When the DHCPv6 client sends a Solicit, it may check whether to continue
doing DHCPv6 based on the then current M bit. (The client should only
exit once all of the leases have expired.)

Note that the same applied for stateless client's when they send
Information-Requests (they can check the M/O bits).

---

I think there are some people that might want to get rid of the M and O
bits completely. But, I don't like that. In particular:
- If a node gets an RA with advertised prefixes and the A bit clear, it
COULD interprete that to mean to use DHCPv6.
- But, if an RA is received with no prefixes or with prefixes with the A
bit set, the node can't assume it should not run DHCPv6.

And, consider a cell wireless network which has 100,000 devices. If they
are all doing DHCPv6 once every 2 minutes, that's a lot of packets per
second which are a complete waste. Thus, having an RA tell them whether
or not to run DHCPv6 is very useful. Especially if there's a laptop or
other general purpose device connected via the mobile; that laptop or
device may not know what network is connected to.

Yes, if the cell operator makes a mistake and sets the M or O bit in the
RA, that would be bad. But, they can fix it (it would take 600-18000
seconds to clear, but that's far better than no ability to retract).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ???
Sent: Tuesday, March 11, 2008 11:00 AM
To: [email-masked]
Subject: [dhcwg] Request for opinions for a question regarding the
handling of M/O flags.

Hello, folks.

After my presentation in the DHC meeting, I discussed my concerns with
Ted, Stapp.
Generally I agree with the consensus that the issue I observed with
VIsta could not happen if the Vista followed RFC2462.
However, from the implemenation point of view, I want to discuss this
issue again. (Sorry !)

Question. Why DHCPv6 clients should keep running even if RA messages
inform that DHCP service is no longer available?

As for bindings, I agree that every finite binding which is supposed to
be used in real situation eventually expires and it will be ok. But, my
concern is regarding control of behavior of clients. From DHCPv6
specification, there might be several(or many) options. As long as I
understand about DHCP protocol including DHCPv4, it is most common to
keep clients searching another server by sending SOLICIT(DISCOVER)
messages again. (As Jinmei pointed, DHCP protocol itself does not have
protocol based interface to disable(stop) client service. ) This makes
me think that it is not good idea and behavior of Vista is clearer that
that.
I want to give an example scenario like this. If mobile host gets an
address from DHCPv6 server in the original network and move into another
network which has no DHCPv6 server and relay, addresses should be kept
until lifetimes expire and keep clients working(sending CONFIRM, RENEW,
REBIND, SOLICIT) even if the host receive RA message with M flag set to
0 from the new network. As long as protocol designers insist that this
is not criticial problem which can change protocol itself, device
vendors may feel uncomfortable with that. Personally, I am implementing
DHCPv6 client for our router product to behave like Vista but not to
misbehave under different M/O flags from multiple routers from different
administrative domains.
I want to share opinions regarding this point.

Thank you in advance.

Joseph HyunWook Cha

The truth will set you free !!!

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

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

---

From: HYUN WOOK CHA <[email-masked]>
Date: Thu, 13 Mar 2008 16:10:42 +0000 (GMT)

Bernie, 
Thank you for your idea which is based on timers. I think that your solution is almost same as the solution proposed by David Hankins when I posted this issue initially.

According to your idea, after addresses are obtained, a DHCPv6 client refers to M-bit and O-bit only when it restart to send SOLICIT. Why is this restrication required? I do not agree when I consider the scenario regarding mobile host moving to new link on which DHCPv6 service is not available and RA messages with M flag set to 0 are received. I would rather suggest that at the event of link reconnection, all timers should be cleared(expired) for M-bit and O-bit to be updated by RA messages from new access router(s) immediately, thereby M-bit will be 0 and this should make the mobile host to release all addresses of existing bindings and exit DHCPv6 client.

Joseph

------- Original Message -------
Sender : Bernie Volz (volz)<[email-masked]> 
Date   : 2008-03-13 04:44 (GMT+09:00)
Title  : RE: [dhcwg] Request for opinions for a question regarding the handling
 of M/O flags.

---

---

When the DHCPv6 client sends a Sgbrsolicit, it may check whether to continue
doing DHCPv6 based on the then current M bit. (The client should only
exit once all of the leases have expired.)

---

- Bernie

-----Original Message-----

Hello, folks.

Thank you in advance.

Joseph HyunWook Cha

Software Engineer 
Samsung Electronics

---

From: 차현욱 <[email-masked]>
Date: Thu, 13 Mar 2008 21:46:01 +0000 (GMT)

Kre, 

See my inline comments.

  | This means if you misconfigured a router and fix it, the new settings
  | (with clear M and/or O) will take MaxRtrAdvInterval seconds to take.

The alternative is to remember where the M & O bits came from, and
clear immediately if the same router sends something different (and no
others are sending the bits).   I think either is a reasonable
implementation, and both should be permitted.

(Joseph) This is exactly what I have in mind and am implementing. 

  | When the DHCPv6 client sends a Solicit, it may check whether to continue
  | doing DHCPv6 based on the then current M bit. (The client should only
  | exit once all of the leases have expired.)

Agreed except "should" - "might" - a client is always free to release or
even just plain abandon any lease at any time, it isn't required to
retain it until the lease expires (which is a good thing given the number
of commercial DHCP "servers" (that is, often, ADSL boxes, doubling as router
NAT, and DNS server) that send (v4 anyway) leases with lifetimes of
hundreds of years...)

If a client desires, it could release (or abandon) a lease, just because
it sees M go off.  I think that would be a pretty horrid implementation
to use, but it shouldn't (and really cannot sanely) be prohibited.

(Joseph) If we trust RA message and start DHCPv6 clients, what can prohibit clients from being stopped by RA notifying that there is no DHCP service. So far, I do not see any reason DHCPv6 clients should not be stopped(release addresses) by RA with M flag set to 0 if the issue which I presented can be resolved. 

Joseph

---

From: HYUN WOOK CHA <[email-masked]>
Date: Tue, 18 Mar 2008 04:59:59 +0000 (GMT)

Bernie, 

Thank you for the information about the DNA WG.
With CONFIRMing, DNA mechanism can be used to invalidate stateful addresses when it will be available.
IMO, invalidating stateful addresses means that addresses are released by a DHCPv6 client. So, this relates to the control of DHCPv6 client's behavior.
At this moment, we can not leverage the work of DNS WG as you know.

So, I just would like to use M/O flags to determine that DHCPv6 client will keep and try to renew stateful addresses or not at the event of link reconnection. 
After MaxRtrAdvInterval which can be reduced by probing actively with RS, DHCPv6 clients will release invalid stateful addresses in case that CONFIRMs sent by the client are not acked. 

Joseph 

------- Original Message -------
Sender : Bernie Volz (volz)<[email-masked]> 
Date   : 2008-03-16 12:28 (GMT+09:00)
Title  : RE: RE: Re: [dhcwg] Request for opinions for a question regarding the
 handling of M/O flags.

>PIOs in RAs can be used to infer that the node moved to
>different network, it seems to be out of scope of DHCPv6
>and does not give hint about availability of DHCPv6 service. 
 
The DHC WG didn't think this was an area that they should specify. There
is an entire IETF WG devoted to this issue (see
http://www.ietf.org/html.charters/dna-charter.html).

When the group was working on drafting what became RFC 3315, we knew we
didn't have all the answers for this issue and decided to keep the
language vague because exactly how a host determines whether/when it has
moved is likely to be very complex.

Think of it this way ... When does a client invalidate stateless
addresses? I'm sure that clients don't wait until those lifetimes expire
if the client has detected that it moved to a different network. The
same rules apply to stateful addresses (with the benefit of having
CONFIRM available to potentially provide input into the decision).

Please see the DNA WG work.

- Bernie