Re: [dhcwg] Default Router information for DHCPv6

Tim Chown <tjc@ecs.soton.ac.uk> Sun, 23 May 2004 22:58 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12576; Sun, 23 May 2004 18:58:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1kE-0001Yn-G5; Sun, 23 May 2004 18:47:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1j1-0001QB-Q7 for dhcwg@optimus.ietf.org; Sun, 23 May 2004 18:45:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12143 for <dhcwg@ietf.org>; Sun, 23 May 2004 18:45:43 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS1iy-0001Tp-KC for dhcwg@ietf.org; Sun, 23 May 2004 18:45:44 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS1hy-0001E3-00 for dhcwg@ietf.org; Sun, 23 May 2004 18:44:43 -0400
Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BS1gv-0000kb-00; Sun, 23 May 2004 18:43:38 -0400
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4NMhWWE010738; Sun, 23 May 2004 23:43:33 +0100 (BST)
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA00748; Sun, 23 May 2004 23:43:28 +0100 (BST)
Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4NMhSJ10175; Sun, 23 May 2004 23:43:28 +0100
Date: Sun, 23 May 2004 23:43:28 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: dhcwg@ietf.org, ipv6@ietf.org
Subject: Re: [dhcwg] Default Router information for DHCPv6
Message-ID: <20040523224328.GB9749@login.ecs.soton.ac.uk>
Mail-Followup-To: dhcwg@ietf.org, ipv6@ietf.org
References: <DADF50F5EC506B41A0F375ABEB3206360143BF00@esebe023.ntc.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DADF50F5EC506B41A0F375ABEB3206360143BF00@esebe023.ntc.nokia.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

On Sat, May 22, 2004 at 05:22:32PM +0300, john.loughney@nokia.com wrote:
> 
> > Should we not update this before it goes final with the wording that has
> > been agreed for the M and O flags, and also to clarify the assertion below,
> > that RAs are the way to get default router and onlink prefix information?
> > 
> > It would be a shame to not convey this consensus in the nodes document.
> > In the draft, that's at least section 4.5.2 and 4.5.5 that probably need a 
> > tweak.
> 
> Take a look at the current draft, a copy can be found here: 
> http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt
> 
> and let me know what you think should be modified.  Please note that
> the idea was that this document should not update any existing RFCs,
> so we cannot prescribe new behavior.

Ah, good point.  However, the 2462 update is due to be submitted very soon,
so is it worth waiting on that one to get the more appropriate text in this
nodes document?

Regarding changes, there would be three I'd suggest.   The first two point
into 2462-bis, so we just need to (as Christian would say) use the "less is
more" maxim, so do something like this:

1.  In 5.3.1 change 

  "IPv6 Nodes that use DHCP for address assignment initiate DHCP
   to obtain IPv6 addresses and other configuration information upon
   receipt of a Router Advertisement with the 'M' flag set, as described
   in section 5.5.3 of RFC 2462."

to
  "The method by which IPv6 Nodes that use DHCP for address assignment 
   can obtain IPv6 addresses and other configuration information upon
   receipt of a Router Advertisement with the 'M' flag set is described
   in section 5.5.3 of RFC 2462."
 
(leaves the suggestion of M being "mandatory" without using the "MAY" term)

2.  In 5.3.2 change

  "Those IPv6 Nodes that use DHCP to obtain other configuration
   information initiate DHCP for other configuration information upon
   receipt of a Router Advertisement with the 'O' flag set, as described
   in section 5.5.3 of RFC 2462."

to

  "The method by which IPv6 Nodes that use DHCP to obtain other configuration
   information can obtain other configuration information upon receipt of a 
   Router Advertisement with the 'O' flag set is described in section 5.5.3 
   of RFC 2462."

(ideally that "can" would be a "may", but that suggests something that is
 not finalised yet, so would be a change of meaning, which you don't want)

3. Add a section 5.5.3:

  "5.3.3 Use of Router Advertisements in Managed Environments

   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 
   are expected to determine their default router information and on-link
   prefix information from received Router Advertisements."

(Perhaps some people may think this is saying too much, or the section 
 heading could be improved, but if the opinion on the list is consensus, 
 we should add it?  You may wish to add reference to Stateless DHCPv6 in
 that extra section too?)

Tim

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg