RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

"Wes Beebee (wbeebee)" <> Wed, 09 July 2008 14:07 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 35B3D28C108; Wed, 9 Jul 2008 07:07:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11DB63A68E1 for <>; Wed, 9 Jul 2008 07:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.51
X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M3MeknMyM4iT for <>; Wed, 9 Jul 2008 07:07:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A867F3A67EB for <>; Wed, 9 Jul 2008 07:07:32 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,331,1212364800"; d="scan'208";a="13661207"
Received: from ([]) by with ESMTP; 09 Jul 2008 14:07:44 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m69E7i8b029143; Wed, 9 Jul 2008 10:07:44 -0400
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m69E7igX005767; Wed, 9 Jul 2008 14:07:44 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 10:07:44 -0400
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Date: Wed, 9 Jul 2008 10:08:02 -0400
Message-ID: <>
Thread-Topic: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjhZjRKKe9UvDqVSjSw3h+ylzpfNAAZErXwAACe9bA=
From: "Wes Beebee (wbeebee)" <>
To: =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= <>
X-OriginalArrivalTime: 09 Jul 2008 14:07:44.0160 (UTC) FILETIME=[285A2200:01C8E1CD]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5902; t=1215612464; x=1216476464; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20< m> |Subject:=20RE=3A=206MAN=20WG=20Last=20Call=3Adraft-ietf-6m an-ipv6-subnet-model-00.txt |Sender:=20 |To:=20=3D?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIz pIGyhC?=3D=20<>; bh=eGkFg0kbbzrd5Ne31+W5F+oxiPu4+dYxIAIenwUsEgs=; b=zEvqC96KMcejp53FdfeLmpEjsrk9lMx2qUduWSmDJZeDeNyYqkAhNFqu1b z0+xu3HYE6w/TjIp2YHrZSsxnL17MOm4yjXRKnb2futRR6uOXq5EM46Y7cAw muRjii/7Ky;
Authentication-Results: rtp-dkim-2;; dkim=pass ( sig from verified; );
Cc: Thomas Narten <>,, Brian Haberman <>, Bob Hinden <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


Please see in line below between <wb> and </wb> 

-----Original Message-----
From: []
Sent: Tuesday, July 08, 2008 9:50 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden;
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Thu, 3 Jul 2008 17:07:34 -0400,
"Wes Beebee (wbeebee)" <>; wrote:

> >    3.  On-link determination SHOULD NOT persist across IPv6 interface
> >        initializations.  Note that section 5.7 of [RFC4862] describes
> >        the use of stable storage for addresses acquired with stateless
> >        address autoconfiguration with a note that the Preferred and
> >        Valid Lifetimes must be retained if this approach is used.
> >        However no RFC suggests or recommends retaining the on-link
> >        prefixes.
> Hmm. I agree that the current specs don't suggest doing this, but is 
> it forbidden or wrong? I.e., is caching on-link information any worse 
> than caching the generated addresses? The PIO has Lifetime fields, and 
> as long as they are honored... ANd indeed, that is what point 4 
> reinforces...
> <hs>True, but what if someone has manually configured an IPv6 address 
> with prefix length, what are the Lifetime values for such a prefix? I 
> am not sure what happens here. Why not be then explicit and include 
> such a bullet. Also, the subject of our draft is focused on on-link 
> determination so we added such a bullet for completeness sake since
> RFC4862 mentions persistent data across initializations. It is RFC4861 
> that deals with on-link determination. So why not have RFC4861 have 
> such text for on-link determination related to persistent storage.
> </hs>
> <wb>
> What if there are cache-inconsistency problems, prefix renumbering, or 
> stale information?  I think it's better just to get rid of caching 
> on-link information in stable storage and get such information fresh 
> from RA's.  That way, administrators can better rationalize the 
> behavior of their network from the configured RA's.
> </wb>

The same argument applies to caching the address, so it cannot be a reason why we specifically prohibit the (on-link) prefix part of this behavior.  

We agree - and we believe implementations shouldn't be caching the address either - but, unfortunately, the text of RFC4862 already allows it and an implementation already does it - so that is something we cannot change.  However, our draft is dealing with on-link determination and we've shown clear problems with caching on-link determination.  RFC4861 and RFC4862 do not mention caching on-link information, so we can add this rule to our draft.

Actually, I see it can rather be harmful if we only prohibit the on-link prefix part of this behavior.  Recall that the background motivation of address caching is that it may help the situation of a temporary outage of a router.  Now that we've deprecated the 'on-link by default' behavior, if the host doesn't also cache the on-link information, the cached address is almost meaningless.

Again, they probably shouldn't be caching the address anyway - but that's an argument for another day.  We have already given our justification why on-link determination should not be cached.

I'm not necessarily a fan of this tricky behavior, but prohibiting one aspect of feature that will make the other aspect meaningless makes logically no sense to me.

So, I tend to agree with Thomas here:

> I don't see right off why rule 3 is needed.

After all, such caching is a minor implementation detail.  I suspect it doesn't do any harm in practice even if we remove this dicey bullet.

No - screwing up on-link determination is not a minor thing nor caching of it. See section 3 of our draft where we give one example of how data forwarding by a host may totally break down if a wrong on-link determination is made.

Another note about the wording if still decide to keep this point:
this bullet does not correctly reflect the sense of the referred part of RFC4862: "Note that section 5.7 of [RFC4862] describes the use of stable storage for addresses acquired with stateless address autoconfiguration..."  The intent of Section 5.7 of RFC4862 was not to "describe" this behavior.  It was written because there was one known implementation that supports this behavior and we thought it might be useful to make note **just in case** other implementations want to do the same thing.  This is why this section uses weak wording such as "An implementation ... may want to retain..." and makes an explicit note of "Further details on this kind of extension are beyond the scope of this document."

As stated above, I'd rather suggest remove this bullet, in which case this concern will be resolved automatically.  But if we keep it, I'd like the wording to reflect the original intent of RFC4862.

We would like to keep this bullet. But we totally agree with your analysis above related to the intent of section 5.7 of RFC4862. We have replaced the word "describes" in our 3rd bullet with "mentions". See new text below - does this work for you?

                  On-link determination SHOULD NOT 
                  persist across IPv6 interface initializations. 
                  This is a new requirement compared to [RFC4861].
                  Note that section 5.7 of [RFC4862] mentions the 
                  use of stable storage for addresses acquired 
                  with stateless address autoconfiguration but no RFC has any 
                  similar text about retaining or not retaining the on-link


Wes & Hemant

JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
Administrative Requests: