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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Mar 2008 17:38:16 -0400

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

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

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.

- Bernie

------- 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: Robert Elz <[email-masked]>
Date: Fri, 14 Mar 2008 07:10:41 +0700

Date:        Thu, 13 Mar 2008 17:38:16 -0400
    From:        "Bernie Volz (volz)" <[email-masked]>
    Message-ID:  <[email-masked]>

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

I think it is important to address that issue, but to be very careful not
to tell hosts what they must do.  One of the most annoying issues to have
to deal with is when someone says "so what if my network is misconfigured,
the spec says that you must interpret it as ..."

The right thing to do here is to specifically say that the host behaviour
is undefined, and anything is acceptable.

That even would include flip-flopping all over the place - which would be
a poor implementation, but not a disaster (remember the early MacOS
DHCP (v4) client that obtained an address whenever an application wanted to
use the network, and released it as soon as the application finished (using
the network) - with many clients that could mean lots of DHCP traffic
with leases coming and going at a pretty fast rate, but even there, many
people didn't even really notice.   We survive under loads like that.

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

That would be a reasonable implementation choice I think, but probably
not the best one.   Better would be to logically "and" the M bits, and
attempt DHCP only when all routers send M set (and I know I am taking
a risk opting for that method on a DHCP list... I'll explain why in
a second).   Similarly, if some routers are sending A for a prefix, and
others are not, I'd "or" the A bits for the prefix, that is, auto-config
if any router claims I should.

Once again, I don't think this should be specified as the correct behavior,
it's just the one I prefer.

The reason relates to rogue routers (at least until secure neighbour discovery
becomes widespread, and that's not likely any time particularly soon, I
expect) - a rogue router sending M==1 when all the real ones have M==0
(there being no genuine DHCP server) can either cause hosts to waste
resources attempting to find the DHCP server, or worse, trick it into
obtaining an address from a rogue DHCP server.   Only using DHCP when all
routers say it should be used dramatically reduces the effectiveness of
an attack like that.

The same applies to the A bits - we don't want a rogue router to prevent
a host obtaining an address by sending A==0, if any router claims that
hosts should auto-configure, then the safe thing to do is to believe that
(I think - I know there are issues with bogus prefix announcements with A==1,
so I might ignore a prefix that less than half the routers are announcing).

I'd tend to use those rules most of the time - but, for example, if anyone
is sending M==1 and I had no address on the interface, I'd be doing DHCP,
even if other routers were sending M==0 (again, that's the safer way, avoids
a rogue router denying config to hosts on a net where only DHCP is intended
to be the config mechanism).

The most important point here is that none of this should be codified, just
make the result undefined, and point out the issues to implementors, allow
different implementations to do different things - that way the only way
the net manager can get consistent predictable behaviour is to correctly
config the net.

kre

ps: Joseph, there is no way for a RA to "notify that there is no DHCP service".
The absence of M and O bits merely tells hosts that by default, they should
not bother with DHCP.  Hosts are the masters though, if they want to try
DHCP even without M or O set, nothing can stop them, and if a DHCP server is
there, and responds, nothing can stop that either.   Of course, no host is
required to do DHCP when M is set either.   RA information is meant
to make it possible for hosts to autoconfigure, not to prohibit any other
method of configuring them.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Mar 2008 17:54:08 -0700

Unfortunately, if you want to DoS a link or capture all traffic, all you really have to do is send an RA that causes devices to autoconfigure and send their traffic to you.   The whole M-bit configuring DHCP scheme is quite elaborate in comparison, and I don't think it really buys you much extra value, if any.   But your main point, that anything that can do stateful address configuration needs to pay attention to RAs in the aggregate and not just flip-flop every time a new one comes in, is certainly true.