Tatuya, Thanks for digging up BSD code. Your suggestion for the extra one sentence in bullet 2 in Section 2 of our drafts makes total sense. I will add the new bullet suggested by you to the draft and also add RFC4291 as a Normative Reference to the References section of our draft.
Thanks. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 7:57 PM To: Erik Nordmark Cc: IPV6 Mailing List; Ralph Droms (rdroms) Subject: Re: Review of draft-wbeebee-on-link-and-off-link-determination-02 At Tue, 11 Mar 2008 07:36:48 -0700, Erik Nordmark <[EMAIL PROTECTED]> wrote: > I agree that "subnet" by itself is underspecified; in some cases it > should just be a prefix. I don't think this document uses subnet" to > mean "link". > > However, I do think we should refer to "subnet prefix" in some places. > If nothing else to make it easier for folks with an IPv4 background to > understand what we are talking about. The "subnet prefix" term is > specified in RFC 4291 (the addressing architecture) thus I don't think > need to completely purge it. Actually, I've just realized the word "subnet" might be the source of confusion. I've looked at the FreeBSD's ifconfig source code to recall why the default prefix length was chosen to be 64 and found the following code fragment: if (explicit_prefix == 0) { /* Aggregatable address architecture defines all prefixes are 64. So, it is convenient to set prefixlen to 64 if it is not specified. */ setifprefixlen("64", 0, s, afp); /* in6_getprefix("64", MASK) if MASK is available here... */ } Although the notion of "aggregatable address" was deprecated, I think the sense of this comment could still apply if the implementor refers to RFC4291. That is, Section 2.5 gives the following structure | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ and states as follows: All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), (this means the subnet prefix is 64). And, as others pointed out, since the notion of "subnet" is not really clear, it's not surprising even if the implementor interprets a "subnet prefix" as on-link prefix. Along with the context of this draft, I believe an IPv6 address should be considered at the "minimum" level as described in RFC4291: At a minimum, a node may consider that unicast addresses (including its own) have no internal structure: | 128 bits | +-----------------------------------------------------------------+ | node address | +-----------------------------------------------------------------+ If this makes sense, I'd propose revising bullet #2 of Section 2 as follows: 2. The configuration of an IPv6 address, whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual configuration does not imply that any prefix is on- link. This means the address should initially be considered the one having no internal structure as shown in [RFC4291]. A host is explicitly told that prefixes or addresses are on-link through the means specified in [RFC4861]. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------