Subject: RE: draft-ietf-ipv6-node-requirements-03.txt

From: "Bound, Jim" <[email-masked]>
Date: Mon, 10 Mar 2003 09:28:20 -0500

Hi Pekka,

> On Sun, 9 Mar 2003, Bound, Jim wrote:
> > 4.5.5 Stateful Address Autoconfiguration
> > Stateful Address Autoconfiguration MAY be supported. DHCP
> [DHCPv6] is
> > the standard stateful address configuration protocol. See
> section 5.3
> > for details on DHCP.
> > 
> > The above MAY should be a SHOULD.  There is not mention of stateful
> > support from ND M or O bits being MAY.  They simply can be 
> used.  It
> > is the option of the user not the standard.  To not support
> any bits
> > suggested for use by users equal to stateless in the ND spec is
> > irresponsible for interoperability requirements in this standards 
> > track document.  This not being a SHOULD can cause sever 
> > interoperability for clients where the user wants all 
> clients to use
> > stateful auto configuration.  Any assumption that it will
> not be used
> > is premature and we should error on the side of it being used.
> > 
> > The wording in 5.3 supports the reason for a SHOULD in this section.
> > 
> > I could argue it is a MUST but at minimum it is a SHOULD.
> 
> I think I can understand your argument here, but let me try to give a
> different perspective.
> 
> If the user (I'd call him admin) requires that only stateful auto
> configuration is acceptable in the network segment by setting 
> a few bits 
> in the advertisement, he should do this only when he knows 
> that all the 
> clients do support these mechanisms.

I would agree with that for sure.  I would assume when users define
their requirements for IPv6 adoption, in many cases, an RFP will be
issued to the vendors. Vendors would bid on the RFP, and in the RFP they
would be asked do they support DHCPv6 in many cases is my guess.  If the
RFP wanted DHCPv6 or stateful and the response to the RFP was not
supported then the vendor would not win the bid and business would go to
a competitor.  Say for example MS clients did not support DHCPv6, then
Linux desktops would be used or HP-UX did not support DHCPv6 servers,
but Solaris did then HP-UX looses.  Etc etc etc.  So this will all be
determined by the market. 

My fear is that not making it a SHOULD we are giving the wrong
impression to the market about the equal support and need for stateful.

From: RFC 2461 ND

Router Advertisements (and per-prefix flags) allow routers to inform
   hosts how to perform Address Autoconfiguration.  For example, routers
   can specify whether hosts should use stateful (DHCPv6) and/or
   autonomous (stateless) address configuration.  The exact semantics
   and usage of the address configuration-related information is
   specified in [ADDRCONF].

      M              1-bit "Managed address configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for address autoconfiguration in addition to any
                     addresses autoconfigured using stateless address
                     autoconfiguration.  The use of this flag is
                     described in [ADDRCONF].

      O              1-bit "Other stateful configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for autoconfiguration of other (non-address)
                     information.  The use of this flag is described in
                     [ADDRCONF].

In ND we clearly stated either could be used.  In additioin the "O" bit
is still needed to go retrieve many options not part of ND options or
parameters.  We are now revisiting the entire DNS Discovery discussion
to potentially use stateful.

From RFC 2462 Addrconf:

Abstract 

This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its
uniqueness on a link, determining what information should be
autoconfigured (addresses, other information, or both), and in the case
of addresses, whether they should be obtained through the stateless
mechanism, the stateful mechanism, or both. This document defines the
process for generating a link-local address, the process for generating
site-local and global addresses via stateless address autoconfiguration,
and the Duplicate Address Detection procedure. The details of
autoconfiguration using the stateful protocol are specified elsewhere.

And..................

 IPv6 defines both a stateful and stateless address autoconfiguration
mechanism. Stateless autoconfiguration requires no manual configuration
of hosts, minimal (if any) configuration of routers, and no additional
servers. The stateless mechanism allows a host to generate its own
addresses using a combination of locally available information and
information advertised by routers. Routers advertise prefixes that
identify the subnet(s) associated with a link, while hosts generate an
"interface identifier" that uniquely identifies an interface on a
subnet. An address is formed by combining the two. In the absence of
routers, a host can only generate link-local addresses. However,
link-local addresses are sufficient for allowing communication among
nodes attached to the same link. 
 In the stateful autoconfiguration model, hosts obtain interface
addresses and/or configuration information and parameters from a server.
Servers maintain a database that keeps track of which addresses have
been assigned to which hosts. The stateful autoconfiguration protocol
allows hosts to obtain addresses, other configuration information or
both from a server. Stateless and stateful autoconfiguration complement
each other. For example, a host can use stateless autoconfiguration to
configure its own addresses, but use stateful autoconfiguration to
obtain other information. Stateful autoconfiguration for IPv6 is the
subject of future work [DHCPv6]. 

END RFC 2462 text.

I feel some are also trying to kill stateful and that is wrong.
Stateless and Stateful are tools for IPv6 node autoconfiguration.
Stateful is one mechanism and not viewed less important than stateless
in the spirit of our IPv6 architecture.  In addition, as the last
sentence from RFC 2462 above states, Stateless and Stateful together can
provide a robust solution for nodes.  

Stateful should be a SHOULD in the node requirements.

>I agree the idea is not  
> it has to be, ie MAY seems enough (with current experience)
> -- but I could 
> just maybe accept SHOULD with strong disclaimers and clarifications.

A SHOULD is supportive of the IPv6 architecture.

> 
> Did I understand the issue properly?  Or was this about the
> hosts kernels executing DHCP when receiving M&O bits and 
> "DHCP: file not found" would be an acceptable and a 
> SHOULD-compliant outcome?

My issue is about stateless and stateful being required features within
IPv6 for auto configuration.  Both are needed and both are required.

Regards,
/jim

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Mar 2003 11:28:52 +0100

"Bound, Jim" wrote:

much deleted...
...
> IPv6 for auto configuration.  Both are needed and both are required.

I hope we all agree on this, using lower case. I think we have a genuine
problem here in they way RFC 2119 defines SHOULD - it makes it very strong
indeed, maybe a bit too strong for this case, whereas MAY is clearly
too weak. Maybe indeed we need to qualify the SHOULD,
e.g. 

Stateful Address Autoconfiguration SHOULD be supported, unless all 
possible use cases for the specific implementation concerned are clearly
satisfied by Stateless Address Autoconfiguration.

   Brian