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

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

Bernie, 

I have a question regarding your proposal. 
Is it possible for a DHCPv6 client to operate in both mode(stateful and stateless) simultaneously?
What If there are two routers one of which is sending RA with M flag set to 1 and the other sending RA with only O flag set to 1?
I guess, only stateful client will be fine even if two routers have their own policies. (Am I right?)

If I am not wrong, I think that we can use only one timer instead of two only if last arrival times of RA with M or O flag set to 1 are recorded, because the timer which cares for M-bit currently can take care of O-bit  when it expires if elapsed time since the last O-bit setting time is less than MaxRtrAdvInterval.  

Thank you for the discussion. 

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: Tue, 18 Mar 2008 09:14:28 -0400

>Is it possible for a DHCPv6 client to operate in both mode(stateful and
stateless) simultaneously?
 
I presume you mean can the client do this and the answer is MOST
DEFINITELY. The two (stateless and stateful) are not mutually exclusive.
Networks may use stateless, stateful, or BOTH. A DHCPv6 client would
normally just do stateful. The IPv6 stack would handle stateless.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of HYUN WOOK CHA
Sent: Tuesday, March 18, 2008 5:20 AM
To: Bernie Volz (volz); [email-masked]
Subject: [dhcwg] Fwd: Re: RE: Re: Request for opinions for a question
regarding the handling of M/O flags.

Bernie, 

I have a question regarding your proposal. 
Is it possible for a DHCPv6 client to operate in both mode(stateful and
stateless) simultaneously?
What If there are two routers one of which is sending RA with M flag set
to 1 and the other sending RA with only O flag set to 1?
I guess, only stateful client will be fine even if two routers have
their own policies. (Am I right?)

If I am not wrong, I think that we can use only one timer instead of two
only if last arrival times of RA with M or O flag set to 1 are recorded,
because the timer which cares for M-bit currently can take care of O-bit
when it expires if elapsed time since the last O-bit setting time is
less than MaxRtrAdvInterval.  

Joseph

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

---

---

---

- Bernie

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

Hello, folks.

Thank you in advance.

Joseph HyunWook Cha

Software Engineer 
Samsung Electronics

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 18 Mar 2008 08:36:15 -0700

> normally just do stateful. The IPv6 stack would handle stateless.

One potential advantage to performing both stateful and stateless*
DHCPv6 operations is that a stateless client is free to select from
multiple Replies or to combine configuration from multiple Replies in
some semi-deterministic fashion with other config data (consider that
multiple DHCPv6 servers may be present).

So it remains unknown as to what actual OS integrators will do, but
I think there are both accidental and purposeful reasons to run both
simultaneously.

There has been some discussion lately about the case where two
different administrative domains meet, and observe differing configs
for whether clients should engage in statelessness or statefullness.

Note that many DHCPv6 clients (I think all?) engaging in stateful
operations will only "bind" to one DHCPv6 server.  So even where
two ISPs are advertising managed configuration on the same link, you
will not see the clients addressed out of both prefixes.  Instead,
you will see each client get a single address from one prefix, and
will rely upon DHCPv6 lease timers (valid lifetimes) to switch
addresses in the event one provider fails.

"Very cold standby."

If networks are going to deliver access to a single physical link
and address their customers via DHCPv6, I suggest we should create
an option (or server DUID definition? but this means providers would
have at most one DHCPv6 server) DHCPv6 servers can advertise to help
clients differentiate service providers.  It must at some point drill
down to a GUI that allows the user to adjust, from defaults, which
domain(s) to acheive configuration from, and a binary DUID is a poor
indicator.

Otherwise I would probably offer the reverse-lookup DNS names of e.g.
the advertised nameservers, or the domain-search contents, but these
are potentially poor disambiguators from company/trademark names (if
they are present in replies at all).

Essentially, the idea being for a client to be able to select (n) of
(2n) Advertising DHCPv6 servers to actually bind to; one from each
ISP.  This would be performed by sorting any advertisements along
the contents of this option, and performing selection within
advertisements with the same contents.  It could also be used
statelessly; simplifying the bulk of configuration state to consider
down to one Reply from each administrative domain.

However.

I think probably networks will not deliver net onto the same physical
wire, but will instead at best deliver net onto two different physical
wires, which are received by one or more routers whose task is in
translating from the network access providers' administrative domains
into the local network operator's single administrative domain.
Accepting downstream prefixes to configure and addressing itself as
advertised.

At least one reason for this is paranoia among network operators to
share anything more than extremely simple physical broadcast domains
with even their customers; who often produce switch layer loops
without running spanning tree or similar kinds of misconfiguration.

Meeting your peers on the same broadcast domain at an IX is bad
enough, it would be the invocation of strong memories of nightmares to
do so across a customer's access lines and premise switches.

And this is of course also assuming that you don't place multiple
customers on the same broadcast domain, which I think is a poor
assumption considering current practices.

* - I think "stateless DHCPv6" is somewhat poorly named, as RFC4242
    requires the keeping of event state, and RFC3315 requires the
    keeping of retransmission state and heavily suggests the keeping
    of configuration state (one would have to wonder why you bother
    with DHCPv6 at all if not for this).

    A better term would be perhaps "simple DHCPv6" or just more
    directly "Information-request" or some abbreviation.

    Perhaps "bindless."

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg