Subject: RE: Stateful != M , Stateless != O

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 12 Aug 2004 10:31:42 -0400

> > => Right, but there is no need to have the O flag off. To 
 > me RFC 3736 is 
 > > something useful for server vendors and should not be 
 > associated with
 > > setting the O flag.
 > 
 > You mean we can always set O flag ? I don't make sense why RFC3736
 > should not be associated with setting the O flag.

=> ??

 > 
 > RFC2461bis says O flag (when set) indicates a subset of 
 > DHCPv6 [RFC3736] is available for autoconfiguration of other
 > (non-address) information...

=> Because the O flag is a subset of all configuration. But that _doesn't_
mean that the server MUST implement _only_ 3736 for the O flag to be set...

Hesham 

 > 
 > 
 > 
 > - Daniel (Soohong Daniel Park)
 > - Mobile Platform Lab. Samsung Electronics.
 > 
 >  
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 12 Aug 2004 10:40:03 -0400

> As Jinmei-san pointed out, RFC 3736 provides implementation
 > guidelines for servers, relay agents and clients.
 > 
 > After reading this thread, I think the text currently in RFC2461bis
 > is headed in the right direction; that is, it explicitly
 > references "a subset of DHCPv6" and cites RFC 3736 for the
 > definition of that subset.  However, as Greg points out,
 > it's not necessarily the case that RFC 3736 was used in the
 > implementation of that subset.

=> That's exactly right. I'll see if I can improve
the text in 2461bis.

Hesham

 > 
 > - Ralph
 > 
 > At 12:46 PM 8/12/2004 +1000, Greg Daley wrote:
 > >Hi Daniel,
 > >
 > >S. Daniel Park wrote:
 > >It does make sense, since RFC 3736 is for servers and relays,
 > >not hosts.
 > >
 > >If an RFC 3315 server is available on a network, but network
 > >policy discourages use of stateful addresses, we may
 > >wish to advertise O=on, M=off.
 > >
 > DHCPv6 [RFC3736] 
 > >>is available for autoconfiguration of other
 > >This is wrong.
 > >a subset of DHCP is available, but this doesn't imply
 > >RFC3736.
 > >
 > >Greg
 > >
 > >

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 12 Aug 2004 11:33:31 -0700

> If M is set(1), a client able to do stateful, does stateful (or full
3315)
> and ignores the O bit. 

More precisely, the M bit indicates that a client wishing to do stateful
may do it, and the M=0 bit indicates that the client should not try.

If the router wants to not enable stateless, then the M bit is not the
right tool. The router should simply not advertise that prefixes are
available for stateless auto-configuration.

-- Christian Huitema

---

From: "Elwyn Davies" <[email-masked]>
Date: Fri, 13 Aug 2004 17:30:41 +0100

Having been reviewing the combined ICMPv6 drafts and following this thread,
I would support Stig's ideas here.

The wording around 3315/3736 needs to be cleared up because a naive reader
*would be* confused by the juxtaposition of 'stateful', 3736 and 3315 - but
that has been done to death - Hopefully Jinmei-san will have a proposal for
us.

A related point is exactly what 'other config' a host might expect to
obtain.  This has been deliberately left vague and I don't have a problem
with that, but I think it would be useful to make it clear whether or not
the stuff that may be in an RA but which isn't prefix info (and isn't the M
and O flags!)is something that could be obtained from a DHCPv6 server
(either statefully or statelessly).  If it can or could be obtained from
both RA and DHCP then some words should be added about how the two sources
should be combined (related to the discussion on getting info from multiple
routers).  I appreciate that it is possible this was discussed a long time
ago - in any case I think the position ought to be documented. This is
probably another area where policy needs to be defined.

At least two or three of the values (MTU, Reachability Time and
Restransmission Time) are useful/needed on links without routers (or without
RAs).

Some of this may need to go into RFC2461bis rather than 2462bis.

I think it would also be helpful to reiterate in the protcol overview what
is implied by the final sentence in 5.5 of 2462bis - that the default
out-of-the-box settings MUST enable stateless autoconfiguration so that
hosts are 'plug-and-play' by default as is intended by the design goals.

Regards,
Elwyn

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 13 August 2004 10:16
> To: JINMEI Tatuya / ?$B?@L@C#:H
> Cc: [email-masked]; [email-masked]
> Subject: Re: Stateful != M , Stateless != O
> 
> 
> On Fri, Aug 13, 2004 at 02:28:46PM +0900, JINMEI Tatuya / 
> ?$B?@L@C#:H wrote:
> [...]
> > Why?  In this (i.e., the latter) scenario, does M=1/O=0 simply mean
> > that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is
> > available but Information Request is not?  Perhaps this is
> > inconvenient, but I don't see why this combination is invalid.
> 
> I tried to say something about that in my previous mail. I think it
> should be invalid.
> 
> A DHCPv6 server should either be a server according to RFC 3315 in
> which case it must support all these messages, or it must support
> the subset listed in RFC 3736 (Information-Request/Reply). Is someone
> seriously suggesting the possibility of servers supporting only
> Solicit/Advertise/Request/Reply? I think that would be a bad idea.
> If server supports all of RFC 3315, it doesn't make sense to make
> clients only use part of the available functionality.
> 
> I also believe some DHCP clients may use both Request/Renew/Rebind
> and Information-Request. A client may initially do a Request to
> obtain an address and other infortmation. There might be reasons for
> a host to later ask for another option long before it needs to renew
> its addresses. In that case it might be reasonable for the client to
> do only an Information-Request.
> 
> If you define O to show whether information-request can be done or
> not, that's fine by me. It would then follow that M=1, O=0 is what
> you say, but I'm arguing that it doesn't make sense. I would prefer
> saying that this combination should not be used and ignored, or that
> when M is set, the O is ignored.
> 
> Actually I think the really best would be to combine M and O into a
> 2-bit value (2*M+O) so that you have values 0-3 where we define 0, 1
> and 3, while the value 2 is reserved for future use. By definining M
> and O separately per the current proposal it's hard to use M=1, O=0
> for something completely different in the future, it will probably
> end up not being used for anything.
> 
> Stig
>

---

From: [email-masked]
Date: Mon, 23 Aug 2004 13:27:05 +0300

Tim &Jinmei,

> > But we need to be careful too in that the Node Requirements draft is
> > just coming out of the oven and was baked using a different 
> recipe :)
> 
> That's perhaps true, though I don't think there will be a big gap
> between the description of the node-req document and (future versions
> of) the M/O document.

Node Requirements is just an informational document, so it should not
be considered Normative in any sense.  If there is a discrepancy between
an informational and a PS/DS/FS then the standard wins out.  I don't
think we really need to wory about this.

John

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 23 Aug 2004 08:33:50 -0400

Well put John I had forgotten about that.  So Tim this answers a lot of
your questions.

The bottom line is DHCPv6 is for stateful address configuration and a by
product is prefix delegation.  How the market uses that is not our
concern we need to specify for both.

/jim 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, August 23, 2004 6:27 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Stateful != M , Stateless != O
> 
> Tim &Jinmei,
> 
> Node Requirements is just an informational document, so it 
> should not be considered Normative in any sense.  If there is 
> a discrepancy between an informational and a PS/DS/FS then 
> the standard wins out.  I don't think we really need to wory 
> about this.
> 
> John
>