Subject: RE: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)

From: "Bound, Jim" <[email-masked]>
Date: Wed, 28 Apr 2004 23:25:02 -0400

I agree with Ralph.  Also HP-UX will provide a production implementation
of full DHCPv6 as product to Moonv6 for complete interoperability
testing in a real world IPv6 network in August 2004.  Beta will be
available to Moonv6 soon for initial testing and in the UNH IOL IPv6
Lab. Linux also supports a full DHCPv6.  Both of these support both m
and o bits.  Removing them is not an option now.  Regarding DHCPv6 most
users will use it instead of stateless in Enterprises for control
reasons.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Wednesday, April 28, 2004 11:17 AM
> To: [email-masked]
> Subject: Re: the protocols for the M/O flags (Re: 
> [rfc2462bis] whether we need the M/O flags)
> 
> Well, picking up the thrown gauntlet - can't resist just this 
> once - if the IETF hadn't spent so much time deciding how 
> many spokes to put on all the wheels being reinvented, we'd 
> have a complete and fully operational set of specs for a 
> deployable IPv6 service by now.
> 
> - Ralph
> 
> 
> 
> 
> At 03:46 PM 4/28/2004 +0300, Markku Savela wrote:
> >I believe DHCP for IPv6 is totally incorrect direction. It's 
> a leftover 
> >dinosaur from IPv4 way of thinking.
> >
> >The whole DHCP6 concept should not have been designed. Instead, the 
> >effort should have gone to extend the standard IPv6 configuration
> >framework: neighbor discovery.
> >
> >If configuration is needed, add new messages to the ND ICMP's, or 
> >options to the router advertisement.
> >
> >
> >--------------------------------------------------------------------
> >IETF IPv6 working group mailing list
> >[email-masked]
> >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> >--------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 

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

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 28 Apr 2004 23:26:06 -0400

And if people would read the spec they would deduce for themselves what
Ralph states below.
/jim 

> Sent: Wednesday, April 28, 2004 12:16 PM
> To: [email-masked]
> I think the O flag (if we keep it!) should simply specify 
> DHCPv6, with no implication about the way in which DHCPv6 is used.
> 
> "Stateless DHCPv6" is simply a way to use some of the 
> messages from the full specification in RFC 3315.  RFC 3376 
> is a guideline to the implementation of
> DHCPv6 that uses just Information-request/Reply messages.  A 
> client can choose to use the Request/Reply or the 
> Information-request/Reply message exchange to obtain other 
> configuration information without address assignment.
> 
> - Ralph
> 
> 
> At 01:28 PM 4/28/2004 +0100, Tim Chown wrote:
> >On Wed, Apr 28, 2004 at 07:28:39PM +0900, JINMEI Tatuya / 
> ?$B?@L@C#:H wrote:
> > >
> > > My point in this message is that IMO we should specify 
> the protocols 
> > > corresponding to these flags clearly and concretely, 
> without leaving 
> > > any ambiguity (I've changed the subject accordingly.)  That is, I 
> > > strongly believe we should clearly say in rfc2462bis, 
> *for example*,
> > >
> > > - the protocol that should be invoked by the M flag is DHCPv6
> > >   (RFC3315), and nothing else
> > > - the protocol that should be invoked by the O flag is stateless
> > >   DHCPv6 (RFC3736), and nothing else
> >
> >But in reality nodes will have full DHCPv6 client support in them 
> >(3315) whether or not they then see the M or O flag that is 
> what they will use?
> >
> >All the DHCPv6 servers implemented to date, to my knowledge, 
> are 3315 
> >and not the 3736 subset.
> >
> >So it is better to just say O flag is other (non address) 
> configuration 
> >data, regardless of full/subset of DHCPv6 used?
> >
> >Tim
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 28 Apr 2004 23:27:51 -0400

This makes sense except I agree with Ralph o bit should just be DHCPv6 and m bit too.  Also DHCPv6 implementations must coexist with stateless.
/jim 

> Behalf Of Christian Huitema
> Sent: Wednesday, April 28, 2004 12:29 PM
> To: JINMEI Tatuya / 神明達哉; Tim Chown
> Cc: [email-masked]
> Subject: RE: the protocols for the M/O flags (Re: 
> I think a whole lot of the issue has to do with the 
> supposedly mandatory nature of the M flag, which leads to 
> phrases like "do DHCP, and only if it fails do auto-config." 
> It would be much simpler to simply define the flags as 
> "announcing an available service", as in:
> 
> 1) The "M" flag is set to indicate that a DHCPv6 address 
> configuration service is available on this link, as specified 
> in RFC3315.
> 
> 2) The "O" flag is set to indicate that a DHCPv6 information 
> service is available on this link, as specified in RFC3736.
> 
> We should then leave it at that, and leave it to nodes to 
> decide whether they want to use these services or not. For 
> example, a server with a configured address will never use 
> DHCPv6 address configuration; an appliance that never has to 
> resolve DNS names will never use the information service. By 
> setting the flags to indicate service availability, we will 
> reduce the amount of useless chatter on the link when the 
> services are not in fact available.
> 
> We should note that, from a protocol point of view, there is 
> no need to use the M bit to control stateless address 
> configuration. This function is already achieved by the 
> "Autonomous flag" in the prefix information option. If the 
> flag is not set, the hosts will not configure information 
> from the prefix. 
> 
> -- Christian Huitema
> 
1H>����"�+��fj)b�	b�ة�����+�f�x�������z����!��l��0�X���+����Y���b�ا~���