Subject: [dhcwg] purpose of m/o bit

From: Thomas Narten <[email-masked]>
Date: Tue, 24 May 2005 10:52:59 -0400

Oops, should have sent this to both lists...

Thomas

------- Forwarded Message

From: Thomas Narten <[email-masked]>
To: [email-masked]
Date: Tue, 24 May 2005 10:45:19 -0400
Subject: purpose of m/o bit

I wonder if there is key question here that the community has simply
not agreed on (yet), and that that question is at the heart of all
this "confusion".

Does the community feel that operators need RA bits that
control/indicate whether a client is to invoke DHC? That is, is there
a need for the sys admin to signal to client whether DHC is to be
invoked?

Second, is it important that such a signal be honored by clients?
(That is, if clients end up mostly ignoring the flags, does their
presence become useless?)

For example, should the sys admin be able to say "do not run DHC,
doing so wastes local resources and won't get you any config info"?
(And should that be honored by clients?)

Fundamentally, it is only the access network that has knowledge of
whether running DHC is useful. Thus, by default, clients (arguably)
can't know whether running DHC is useful, so by default they shold
invoke DHC (unless the sys admin signals "don't invoke DHC").

Or (switching the argument), by default, client should not invoke DHC,
unless the local sys admin indicates doing so is appropriate.

If we can't agree that the above is necessary (i.e., is a "problem
statement" of sorts), I really have to wonder what purpose the R/A
bits can serve or whether we will ever have a shared understanding of
what they are supposed to do. Having them be a hint (that clients in
practice ignore half the time) would seem to solve no useful purpose
(IMO) and would provide the sys admin with useless tools (since
clients wouldn't respond to the usage of the tool in predicatable
ways). The result would simply be more confusion. (Oh, that is already
the state we are in!!! :-))

So, what is it? 

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

------- End of Forwarded Message

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 24 May 2005 23:23:09 -0400

I don't have any issues if we wanted to keep 2 bits - just figured
simpler is better.

Note that if we drop one of those bits, we would not want to reuse if
for another purpose for a long time -- that would allow backward
compatibility for those environments that need it.

But again, I really don't care if it is two bits.

- Bernie 

> -----Original Message-----
> From: Soohong Daniel [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, May 24, 2005 11:15 PM
> To: Bernie Volz (volz); 'Bound, Jim'; 'Thomas Narten'; 
> [email-masked]; [email-masked]
> Subject: RE: purpose of m/o bit
> 
> > But if the client supports both (really this means it is a 
> "full" 3315
> > client), does it do both in parallel, initiate stateful 
> (Solicits) and
> > failover to stateless at some point (and does it continue to 
> > do stateful in the background), or? These areas that are not well 
> > documented in the DHCPv6 specifications (3315 + 3736) and we 
> > need to clarify. We've discussed several proposals but I 
> don't think 
> > we've closed that discussion.
> 
> Exactly,
> 
> > Thus, I would suggest we:
> > - Have one bit that says "run DHCPv6". If the client is stateful, it
> > does "full" 3315". If the client is stateless (3736), it 
> does stateless
> > only.
> > - Have the DHC WG publish a draft to properly define the behavior of
> > clients (and servers) when stateful service is not 
> available and only
> > stateless is available. IE, when should a client switch to using
> > Information-Request or should all servers support Solicit and 
> > should an Advertise be able to carry "other configuration" options 
> > when addresses are not available. (Or perhaps there are 
> other options 
> > to be considered.)
> 
> As Jinmei pointed out, we should consider *backward-incompatibility*
> proir to saying any alternatives. We should make sure that is 
> not a trivial 
> consideration. 
> 
> 
> 
> ---------------------------------------------
> Daniel (Soohong Daniel Park)
> Mobile Platform Laboratory, SAMSUNG Electronics.
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 25 May 2005 13:38:51 -0400

>All of this, coupled with the fact that, AFAIK, no OS implements
DHCPv6, means that there is essentially zero experience with DHCPv6 in
the operational community. This means that at this time, there is little
point in asking the operational community what should happen with the M
and O bits.

Or perhaps this could be the ideal time to ask the operational community
what should happen with the M and O bits -- before software developers
go too far down a particular direction without operator guidance?

Some of us operators do more than just configure and test vendor
products.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Iljitsch van Beijnum
Sent: Wednesday, May 25, 2005 5:43 AM
To: Thomas Narten
Cc: [email-masked]; IETF IPv6 Mailing List
Subject: [dhcwg] Re: purpose of m/o bit

[Crossposted to dhcwg even though I'm not on that list, as people  
there may be able to add some useful insights.]

> a need for the sys admin to signal to client whether DHC is to be 

By a strange coincidence, I spent most of the day yesterday taking  
several DHCPv6 implementations for a test drive, for reasons  
unrelated to this discussion.

These implementations are: KAME DHCP6, the unnamed Linux fork of the  
KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco  
IOS implemenation.

Conclusion: the Cisco implementation is incomplete (no address  
assignment) and the other two are too immature to be of much use.

I'm impressed with the prefix delegation functionality, but as  
before, the prospect of running such a complex protocol just to  
optain a domain search list and some DNS resolvers makes me very  
uncomfortable.

All of this, coupled with the fact that, AFAIK, no OS implements  
DHCPv6, means that there is essentially zero experience with DHCPv6  
in the operational community. This means that at this time, there is  
little point in asking the operational community what should happen  
with the M and O bits.

In other words: this is not the time declare the bits useless and  
remove them.

> presence become useless?)

Depends. There are three possible ways this can play out:

- the DNS resolver issue is solved in a way that doesn't requite  
DHCP, so most people don't don't run DHCPv6 at all, others run it all  
the time -> no bits necessary
- the DNS resolver issue isn't solved in another way, so everyone  
runs some form of DHCPv6 all the time -> no bits necessary
- DHCP provides benefits but some people are reluctant to use it ->  
helpful to know whether to bother running DHCPv6

> (And should that be honored by clients?)

I think it's good to recognize that in the past, there have often  
been security issues with non-text based UDP protocols, so knowing  
there is no need to run DHCP and then not running it would be good  
security.

> unless the local sys admin indicates doing so is appropriate.

There isn't really a difference here, except for what happens when  
there are no RAs.

I would be interested in hearing viewpoints on the usefulness of  
running DHCPv6 even though the hints indicate that there is no need to.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 25 May 2005 13:54:51 -0400

So Rich, I'll ask. What would you like to see happen?

- Bernie 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Woundy, Richard
> Sent: Wednesday, May 25, 2005 1:39 PM
> To: Iljitsch van Beijnum; Thomas Narten
> Subject: RE: [dhcwg] Re: purpose of m/o bit
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 25 May 2005 16:45:41 -0400

Folks,

I can't speak on behalf of all cable operators, but I can provide my own
current perspective on IPv6 and the M/O flags.

There are three primary types of DHCPv4 clients in cable networks today:
cable modems, functional entities co-resident with the cable modems
(such as PacketCable MTA VoIP endpoints, CableHome gateways, etc.), and
customer computers and other customer-controlled equipment.

For our business, we want the ability to control which prefixes were
assigned to which customer devices. For example, we may want to assign
different prefixes to devices corresponding to non-customers and to
"not-yet-customers" (those that will self-provision their service).

Our current plans are that cable modems and co-resident functional
entities would use DHCPv6 for stateful address configuration as part of
their own boot process. DHCPv6 would also provide information for
configuration downloads, time servers, and domain name servers (as
needed). I don't think we would want to use address autoconfiguration
for those devices/entities.

Customer computers and other customer equipment tend to be a little
trickier, since such devices may be used in different service provider
contexts (e.g. wireless, where bandwidth is much more precious than in
cable), and since OS developers don't always worry about service
provider network requirements (especially if they are focused on
personal computing or enterprise network/IT requirements first).

One possible approach is that cable modems (or some subset of cable
modems) would use DHCPv6 prefix delegation (PD) to get a
customer-specific prefix, which could be learned by customer computers
through address autoconfiguration (e.g. the cable modem would become an
IPv6 router). The customer computers could use DHCPv6 (ala RFC 3736) to
obtain additional parameters (e.g. domain name servers), but DHCPv6 use
would be optional for network access. This plan presumes that PD scales
for our customer base, which today is largely residential broadband
customers.

The other approach is that each customer computer would use DHCPv6 for
stateful address configuration. This matches our current IPv4 deployment
model where every customer computer is a DHCPv4 client of our DHCP
servers. But this approach would mandate DHCPv6 use for network access,
which may be fairly painful when there are few/no DHCPv6 client
implementations in OS's today. :^(

What does that mean for the M/O flags discussion? I suspect we might try
to deploy both approaches for customer computer address allocation,
which would imply that we would want to use something like the M/O flags
to signal to customer computers when DHCPv6 is necessary for network
access, and when it is not.

While we expect cable modems to use DHCPv6 exclusively, I have heard of
other cable operators that want to experiment with address autoconfig
for cable modems -- although to be honest I am not really sure how that
would work.

I would think it is our responsibility (as service providers) to set the
M/O flag settings correctly and appropriately on our edge routers
(CMTSs).

Hope this perspective helps.

-- Rich

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 1:55 PM
To: Woundy, Richard; Iljitsch van Beijnum; Thomas Narten
Cc: [email-masked]; IETF IPv6 Mailing List
Subject: RE: [dhcwg] Re: purpose of m/o bit

- Bernie 

> the operational community. This means that at this time, there is 
> with the M

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 May 2005 16:49:59 -0400

Ron, 

Thanks for doing this and this permits us to discuss it simply :--).
Response on your matrix via my interpretation as implementer, no comment
on your needs and appreciate you sharing that here big time, I find it
very useful.  Thanks.

> There are nine scenarios, right?
> 
> 1) RA w/auto-conf, M off, O off

Stateful is not being requested by the site or admin.  No requirement to
use it.

> 2) RA w/auto-conf, M on, O off

use stateful and other configurations available.

> 3) RA w/auto-conf, M off, O on

use other configurations only.
 
> 4) RA w/auto-conf, M on, O on

Same as #2 is my view.

> 5) RA w/o auto-conf, M off, O off
> 6) RA w/o auto-conf, M on, O off
> 7) RA w/o auto-conf, M off, O on
> 8) RA w/o auto-conf, M on, O on

My read is if auto-conf off then these bits are invalid and stateless is
default.

> 9) No RA

Your lost and not connected have it your way :--)  Use link-local :--)

thanks
/jim

> 
> >From a cable deployment perspective, I would expect...
> 
> 1) CM stateless auto-conf from advertised route(s)
> 2) CM stateless auto-conf from advertised route(s) plus DHCPv6 for
> additional address(es)
> 3) CM stateless auto-conf from advertised route(s) plus DHCPv6 for
> addition info
> 4) CM stateless auto-conf from advertised route(s) plus DHCPv6 for
> additional address(es) and additional info
> 5) same behavior as #9 below ?
> 6) DHCPv6 for address(es) only
> 7) DHCPv6 for additional info only
> 8) DHCPv6 for address(es) and additional info
> 9) CM stateless auto-conf link local address followed by DHCPv6 for
> additional address(es) and/or other info (same behavior as #5)
> 
> This seems way to complicated though, and it would be much more
> deterministic for a CM to simply do #4 in all cases which 
> would make the
> M/O bits useless.
> 
> -ron
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 27 May 2005 09:49:16 -0400

Depends on what the DHCPv6 server is configured to do.

AAC and DHCPv6 can assign addresses on the same prefix, but I would
suspect that in most deployments there is little reason to do that.
Instead, DHCPv6 would likely assign addresses on prefixes that are not
AAC.

More likley is that you have a unique local prefix that you allow AAC
for. But, for a global unicast address you need to go to DHCPv6. The
DHCPv6 server would *NOT* likely assign another unique local address for
that client.

Just because a prefix is advertised as AAC or not, does not imply
ANYTHING about what DHCPv6 would do for that prefix. Though in practice
there is little reason to use both AAC and DHCPv6 on that single prefix.
Though there may be good reason to do AAC on some prefixes and DHCPv6 on
others if multiple prefixes are active.

- Bernie 

> On Behalf Of da Silva, Ron
> Sent: Friday, May 27, 2005 9:31 AM
> To: Iljitsch van Beijnum
> > To me, assuming the current specs, the following would make sense:
> 
> One of the permutations missing in your algorithm is if a device is
> configured for always-full-DHCPv6 on an interface AND it receives RA
> with AAC set...I presume in that case the device would get multiple
> addresses, right?
> 
> -ron
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 May 2005 12:30:33 -0400

the o bit was to state use dhcpv6 but not for addresses.  it is not
binary but ternary.
/jim 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernie Volz (volz)
> Sent: Friday, May 27, 2005 8:56 AM
> To: [email-masked]; Ralph Droms (rdroms); 
> [email-masked]; [email-masked]
> Subject: RE: [dhcwg] RE: purpose of m/o bit
> 
> We don't but it avoids issues with backwards compatibility (though I
> don't believe that is a big issue yet).
> 
> I think if we come to agreement on having no distinction between the
> bits, we should deprecate one of the bits (O-bit?); though 
> for backwards
> compatibility, we can't remove/reassign it until many years 
> from now (if
> ever).
> 
> - Bernie
> 
> > On Behalf Of [email-masked]
> > Sent: Friday, May 27, 2005 8:42 AM
> > To: Ralph Droms (rdroms); [email-masked]; [email-masked]
> > Subject: [dhcwg] RE: purpose of m/o bit
> > 
> > Ralph Droms <[email-masked]> wrote:
> > 
> > > Seems to me I'm hearing two requirements out of this thread:
> > > 
> > > 1) Ability to indicate to a host "DHCP is not available on 
> > this link",
> > >    with the expectation that the host won't send any DHCP messages
> > > 
> > > 2) Ability for a host to get all desired and available DHCP
> > >    configuration with a single DHCP message exchange
> > >    - if a host wants HCB, it sends an HCB request (Solicit)
> > > and receives
> > >      HCB and/or ICB replies
> > >    - if a host wants ICB, it sends an ICB request
> > > (Information-request)
> > >      and receives ICB replies
> > > 
> > > 1 is a requirement in scenarios with limited resources (e.g.,
> > > wireless), where polling for DHCP is unacceptable.  2 is a
> > > requirement to avoid timeout delays or other complexity in getting
> > > ICB reply when 
> > > host would
> > > prefer HCB reply.
> > > 
> > > If I've got that right, we can meet the two requirements 
> > with a couple
> > > of small updates to existing specs:
> > > 
> > > 1) If an RA is received with the M and/or the O bit is set, DHCP
> > >    service is available over the link through which the RA
> > > was received
> > >    (no differentiation between HCB and ICB DHCP)
> > > 
> > > 2) If a DHCP server receives an HCB request (Solicit) but can only
> > >    supply an ICB, the server can respond with the ICB reply 
> > (note that
> > >    according RFC 3115, the server would respond with an "HCB-nak"
> > >    [Advertise containing only an error code])
> > > 
> > > In addition to meeting the requirements, these updates are 
> > mostly (if
> > > not entirely) operationally compatible with existing clients and
> > > servers. 
> > 
> > I completely agree with this analysis and support proceeding on this
> > basis. But it does beg the question, why do we need two bits 
> > to signal a
> > binary condition?
> > 
> >  -- Mat
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 May 2005 12:32:12 -0400

m == use dhc for addresses, o == use dhc for just configuration bow do
you do this with one bit? neither m or o not set says don't use dhc.
thus my reason for ternary.

thx
/jim 

> On Behalf Of Ralph Droms
> Sent: Friday, May 27, 2005 8:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Mat - thanks for your review and input.  I specified the two bits only
> for backward compatibility with existing implementations.
> 
> I imagine we could design a specification that retains one bit and
> deprecates the other, with rules about the appearance of the depre
> backward compatibility.  At least, this spec would need a note
> explaining why there are two bits in the spec and 
> recommending that new
> implementations use, for example, just the M bit.
> 
> - Ralph
> 
> On Fri, 2005-05-27 at 13:41 +0100, [email-masked] wrote:
> > > 1) Ability to indicate to a host "DHCP is not available 
> on this link",
> > >    supply an ICB, the server can respond with the ICB 
> reply (note that
> > > In addition to meeting the requirements, these updates 
> are mostly (if
> > basis. But it does beg the question, why do we need two 
> bits to signal a
> > binary condition?
> > 
> >  -- Mat
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 May 2005 12:34:13 -0400

because thinking was router should be able to tell client use for
addresses and not configuration or use just for configuration, or don't
even use dhc.  no comment on that I agree or disagree this is just what
the purpose was.  agree or not agree can only happen once people get why
what is there is there.
/jim 

> On Behalf Of Bernie Volz (volz)
> Sent: Friday, May 27, 2005 9:18 AM
> To: Iljitsch van Beijnum
> Cc: [email-masked]; [email-masked]; Ralph Droms (rdroms)
> Why?
> If we update the DHCPv6 protocol to allow "other 
> configuration" options
> to be returned in an Advertise for a Solicit, 
> Information-Request/Reply
> and Solicit/Advertise are then essentially the same in a stateless
> DHCPv6 environment (though the Solicit does require a client 
> identifier
> and likely may require a IA_* option).
> 
> Note that this will require changes to 3315 and 3736 - since stateless
> servers will need to respond to Solicits with Advertises.
> 
> Clients that can do full 3315, would. And, if no stateful 
> DHCPv6 server
> is available but a stateless is, it will get "other configuration
> parameters".
> 
> Clients that only do 3736 would do that and get "other configuration
> parameters".
> 
> I think if we have two bits, we'll just be back to some of the edge
> conditions (what if M is set, but O isn't, etc).
> 
> These changes would potentially cause some issues with any deployments
> today because the clients and servers do not support this "new"
> behavior, but it that's why it is critical we work this out ASAP.
> However, those clients, if they use the M & O bits, could 
> continue to do
> what they do today -- since both bits are available. It is just new
> clients with old servers that may have issues.
> 
> - Bernie
> 
> > From: Iljitsch van Beijnum [mailto:[email-masked]] 
> > Sent: Friday, May 27, 2005 9:07 AM
> > To: Bernie Volz (volz)
> > Cc: [email-masked]; Ralph Droms (rdroms); 
> > Subject: Re: [dhcwg] RE: purpose of m/o bit
> > 
> > On 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote:
> > 
> > > bits, we should deprecate one of the bits (O-bit?); though for  
> > > backwards
> > > compatibility, we can't remove/reassign it until many years from  
> > > now (if
> > > ever).
> > 
> > I think having M = 0, O = 1 would be useful as an indication that  
> > clients should use the simplified stateless DHCPv6 rather than the  
> > full DHCPv6.
> > 
> > And I would object to any deprecation on the basis that 
> there isn't  
> > enough operational experience to be able to make a good decision.
> > 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 May 2005 12:41:55 -0400

hmmm I wonder if part of the confusion is for prefix delegation to
happen maybe that should be signaled by the m bit.  The o bit or its
function should be pristine to mean only use dhc for configuration data
like dns, link information, services information etc.

when m bit set it is client/server implementation defined by admins for
dhc whether stateless dhc is used or full dhc?

/jim 

> On Behalf Of Bound, Jim
> Sent: Friday, May 27, 2005 12:32 PM
> To: Ralph Droms; [email-masked]

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 May 2005 12:44:02 -0400

sure but breaking production code has to jump a higher bar regardless
and I am not convinced that all have come to good set of statements and
assumptions what those bits mean right now and I think that is prudent
before changing them. prefix delegation puts another and new variable in
the analysis I think now.

/jim 

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, May 27, 2005 12:40 PM
> To: Bound, Jim
> Cc: Bernie Volz (volz); [email-masked]; Iljitsch van Beijnum; 
> [email-masked]; Ralph Droms (rdroms)
> On May 27, 2005, at 9:35 AM, Bound, Jim wrote:
> > ughh. sorry know of three production servers in use Lucent, HP, and
> > Linux version.
> >
> 
> That's not what I mean.   The point is that it's early days, and  
> updating servers isn't a hard problem.   My point is that I don't  
> know of any widespread deployments we'd be breaking right now, not  
> that there are no implementations.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 May 2005 14:12:22 -0400

at least have discussion where all agree for sure.  not clear a document
is needed if we can put it in dhc or possibly biz update to 2462 yet
again :----)
/jim 

> From: Syam Madanapalli [mailto:[email-masked]] 
> Sent: Friday, May 27, 2005 1:41 PM
> To: [email-masked]; [email-masked]
> Cc: Ted Lemon; Bound, Jim; Iljitsch van Beijnum; Ralph Droms 
> (rdroms); Bernie Volz (volz); Thomas Narten; 
> [email-masked]
> Isn't it such a long idscussion a proof for the confusion in
> understanding the M/O
> bits? Instead of leaving the discussion here, thinking that there is
> no confusion or
> be fore taking any radical changes (either discarding M or O 
> or both flags, or 
> making changes to the DHCPv6 protocols), it is better to 
> document the inteded 
> use of M/O flags as an informational document, so that we 
> will have uniform 
> implementations in th future. I am sure this (intended use of M/O
> flags) is very
> obvious for some people here, but definitely help many others. Also
> this information
> will be handy for the implementer.
> 
> - Syam
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 May 2005 14:49:52 -0400

my input is dhcpv6 implementation and deployment state is quite flexible
for this topic and code affect and config/admin affect.  If we move to
unicast instead of multicast for dhc answer would be different ok.
/jim 

> On Behalf Of Ted Lemon
> Sent: Friday, May 27, 2005 2:40 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; Ralph Droms (rdroms); Erik Nordmark; 
> [email-masked]; Iljitsch van Beijnum
> On May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote:
> > If people are really concerned about this, we can always 
> add a DHCPv6
> > option to the Solicit that tells the server "I'm a new client and am
> > able to receive other configuration parameters even if you're not  
> > going
> > to give me any addresses." Thus, the old servers would ignore this
> > option and new servers would know that it is OK to do this.
> 
> DHCPv6 is not a full standard.   I don't think it's widely deployed  
> at this point.   I would rather take the risk, as you suggest, than  
> add an extra protocol to negotiate whether we can do this - it's  
> extra logic in the server that will be needed for zero clients two  
> years from now - just another piece of unused code that could be  
> buggy, because it's never used, and thus could be an avenue 
> of attack  
> for some enterprising young script kiddie.
> 
> The time to get conservative about breaking clients by sending them  
> unexpected responses will come, but it hasn't come yet, IMHO.   I  
> haven't heard anything to contradict this - has anyone else?
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 28 May 2005 13:54:44 -0400

for dhcp yes but for IPv6 it is now widespread in multiple target
markets.
/jim 

> Behalf Of Ted Lemon
> Cc: [email-masked]; Iljitsch van Beijnum; [email-masked]; 
> Bernie Volz (volz); Ralph Droms (rdroms)

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 28 May 2005 13:54:44 -0400

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 30 May 2005 16:23:12 -0400

Folks, the purpose of this thread is to define the purpose of the bits
for ND and addrconf not resolve how dhc works.  We need to finish that
first ok.

The router is sending m and o bits now.  What is their purpose and do
they work.  If we change them it affects far more than dhc.

The thread to how to do this in dhc is most likely truly a dhc wg effort
and not an ipv6 wg effort.

Again the m or o bit are to inform clients before they even contemplate
dhc within an ND packet. 

Do we need both bits but we need one for them for sure. 

thanks
/jim