Comments on 'draft-ietf-ipv6-rfc2462bis-08.txt'

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 29 August 2006 00:16 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrHF-0002L0-VJ; Mon, 28 Aug 2006 20:16:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrHE-0002Kq-62 for ipv6@ietf.org; Mon, 28 Aug 2006 20:16:24 -0400
Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHrHA-00079H-Tk for ipv6@ietf.org; Mon, 28 Aug 2006 20:16:24 -0400
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7T0GIv7003602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ipv6@ietf.org>; Mon, 28 Aug 2006 19:16:18 -0500 (CDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k7T0GICt000434 for <ipv6@ietf.org>; Mon, 28 Aug 2006 19:16:18 -0500 (CDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7T0GIsb000427 for <ipv6@ietf.org>; Mon, 28 Aug 2006 19:16:18 -0500 (CDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 17:16:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Aug 2006 17:16:17 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774262@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <20060827040014.2F60A28E@cyteen.hactrn.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on 'draft-ietf-ipv6-rfc2462bis-08.txt'
Thread-Index: AcbJn3v5aA//Jr08Rai5iGV7r76xoQBWc2cA
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: ipv6@ietf.org
X-OriginalArrivalTime: 29 Aug 2006 00:16:18.0221 (UTC) FILETIME=[591DEDD0:01C6CB00]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: Comments on 'draft-ietf-ipv6-rfc2462bis-08.txt'
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

I have two meta-comments and two specific comments on this
document:

1) (meta-comment) The specification speaks of only two classes
of unicast addresses (link-local and global) but we now have a
third class (ULAs - RFC4193) and others may be definied in the
future (e.g., PI). The term "global (address)" should therefore
be somehow relaxed throughout the document to allow for stateless
autoconfiguration of non-link-local unicast addresses other than
just normal global addresses.

2) (meta-comment) Section 5.4 introduces new text that disallows
the optimization of testing for uniqueness of link-locals only
and skipping the test for additional addresses. Therefore, new
implementations will need to do DAD for addresses that derive
from both organic information (link-locals) and information
learned from the network (non-link-locals). This suggests that
the configuration variable 'DupAddrDetectTransmits' is over-
loaded in the new specification since DAD considerations for
link-locals and non-link-locals may be different in some
environments. Suggested fix is to split the configuration
variable into two separate variables ('DupAddrDetectTransmits'
and 'DupAddrDetectTransmitsLL') with the former used for DAD
tests of non-link-locals and the latter used for DAD tests of
link-locals. New implememtations would use the separate variables,
and existing implementations would continue to use the single
variable. Text changes throughout the document for consistency
also required.

3) (specific) Section 5.3, third bullet, second sentence, change
to: "This includes the case where the attached link is dynamically
changed, e.g., due to a change of the access point of wireless
networks."

4) (specific) Section 5.5.3, item d), the phrase: "configured by
stateless autoconfiguration" - why was this phrase added?
Prefer that it be removed.

Fred
fred.l.templin@boeing.com 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------