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 22:50:12 +0000 (GMT)

Bernie, 

Please see my inline comments.

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

Joseph:

If a node detects a change in network attachment point (such as the case
where a DHCPv6 CONFIRM returns NotOnLink or RAs clearly indicated that
the node has moved), a node would most certainly take appropriate steps.
This is discussed in RFC 3315 (18.1.2). I do not think we need to
discuss that case - it is clear (though exactly how a node detects that
it has moved is certainly a bit involved).

(Joseph) I am sorry I can not agree. 
RFC3315 18.1.2 says, 
"If the client receives no responses before the message transmission
   process terminates, as described in section 14, the client SHOULD
   continue to use any IP addresses, using the last known lifetimes for
   those addresses, and SHOULD continue to use any other previously
   obtained configuration parameters."
If the node moved to new link on which there are no DHCPv6 servers and relays, it keep sending CONFIRMs during CNF_MAX_RD(10 sec) and then, using addresses which are not on link. 
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. 

I think the case we are discussing here is when the current lease(s) are
still valid and in such a case there is no reason to test the M and O
bits to determine whether they now indicate that DHCPv6 should not run
(and relaese immediately).

But, there are no prohibitions against clients releasing leases early
(after all we have a Release message) - and that is purely a client
implementation decision.

I think what we are trying to address here is:
- Misconfigured routers (where multiple routers send conflicting
information) - in this case we want predictable behavior and we
especially don't want clients repeatedly starting DHCPv6 and releasing
over and over based on the last received RA.

(joseph) I agree.

- Changes in policy on a network (where the network transitions from
stateful to stateless). Here, whether a particular client reacts
immediately to release or allows its existing leases to expire is not an
issue. However, a client would not normally be able to distinguish this
condition from the previous one (except if there were no conflicting RAs
received from all of the routers).

(joseph) I agree.

This last point does raise a further refinement in the algorithm I
mentioned with the timers - if a node keeps information about each RA
received (timing it out as appropriate), then it may apply the change to
clearing the M and/or O if all RAs received agree. Perhaps that would be
an easier implemention ... If a node keeps a list of the sources of RAs
and a record of the last received M & O bits from each source, then it
can OR all of the M and O bits together and use the result. That way, if
one router sends an M or O set, that bit is set; only if they all send
cleared M or O bits is the result a cleared M or O bit.

(joseph) I am currently implementing this idea. So far, I see two possible solutions which are distinguished as M-bit/O-bit timers based, sender(source) based. If you agree that this is the problem IETF should deal with, what do you think is next step we will take? 
  
Joseph

------- Original Message -------
Sender : ???<[email-masked]>  E4(??)/??/??1??(I/Infra)/????
Date   : 2008-03-14 01:10 (GMT+09:00)
Title  : Re: [dhcwg] Request for opinions for a question regarding the
handling
 of M/O flags.

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.

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

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: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 15 Mar 2008 23:28:08 -0400

>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

-----Original Message-----
From: HYUN WOOK CHA [mailto:[email-masked]] 
Sent: Thursday, March 13, 2008 6:50 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: RE: Re: [dhcwg] Request for opinions for a question
regarding the handling of M/O flags.

Bernie, 

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

Joseph:

(Joseph) I am sorry I can not agree. 
RFC3315 18.1.2 says, 
"If the client receives no responses before the message transmission
   process terminates, as described in section 14, the client SHOULD
   continue to use any IP addresses, using the last known lifetimes for
   those addresses, and SHOULD continue to use any other previously
   obtained configuration parameters."
If the node moved to new link on which there are no DHCPv6 servers and
relays, it keep sending CONFIRMs during CNF_MAX_RD(10 sec) and then,
using addresses which are not on link. 
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. 

(joseph) I agree.

(joseph) I agree.

(joseph) I am currently implementing this idea. So far, I see two
possible solutions which are distinguished as M-bit/O-bit timers based,
sender(source) based. If you agree that this is the problem IETF should
deal with, what do you think is next step we will take? 
  
Joseph

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

Bernie, 

Joseph

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

---

---

---

- Bernie

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

Hello, folks.

Thank you in advance.

Joseph HyunWook Cha

Software Engineer 
Samsung Electronics