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

From: 차현욱 <[email-masked]>
Date: Tue, 11 Mar 2008 14:59:38 +0000 (GMT)

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Mar 2008 15:44:34 -0400

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

Software Engineer 
Samsung Electronics

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Mar 2008 04:14:41 +0700

Date:        Wed, 12 Mar 2008 15:44:34 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

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

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

Some implementations compare RA's for consistency and simply bitch and
moan (and ignore) ones that differ from the first received (ie: from that
most recently received from the first router).  That is, network
inconsistently configured, someone please fix it...

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

Agreed.

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

kre

ps: in many networks, the max rtr adv interval is set much lower than
the default (let alone the upper limit) - unless there are LOTS of routers,
the cost is negligible.

---

From: Santosh Chandwani <[email-masked]>
Date: Thu, 13 Mar 2008 16:31:18 +0800

Having hosts continue to hold onto an IPv6 address obtained on a previous network when it moves to a new network which has the M flag set to 0 does not make sense in all scenarios. If the network is not managed by stateful DHCPv6, why should the client continue using an address that was obtained through DHCPv6?

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

Hello, folks.

Thank you in advance.

Joseph HyunWook Cha

Software Engineer
Samsung Electronics

---

From: Santosh Chandwani <[email-masked]>
Date: Thu, 13 Mar 2008 17:13:31 +0800

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.

---

---

---

- Bernie

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

Hello, folks.

Thank you in advance.

Joseph HyunWook Cha

Software Engineer
Samsung Electronics