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

"Wes Beebee (wbeebee)" <> Thu, 10 July 2008 20:21 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9EAC73A683F; Thu, 10 Jul 2008 13:21:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DC6E3A6824 for <>; Thu, 10 Jul 2008 13:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.873
X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AeCfdr2PZ+mm for <>; Thu, 10 Jul 2008 13:21:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B1373A683F for <>; Thu, 10 Jul 2008 13:21:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,340,1212364800"; d="scan'208";a="51506025"
Received: from ([]) by with ESMTP; 10 Jul 2008 20:21:17 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m6AKLHI2023234; Thu, 10 Jul 2008 13:21:17 -0700
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m6AKLF4n019237; Thu, 10 Jul 2008 20:21:16 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 16:21:16 -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: Thu, 10 Jul 2008 16:21:35 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjixrcJrBrHuESRSsOoM0fDVqi3UAAAfnjw
From: "Wes Beebee (wbeebee)" <>
To: =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= <>, "Hemant Singh (shemant)" <>
X-OriginalArrivalTime: 10 Jul 2008 20:21:16.0613 (UTC) FILETIME=[81A0CF50:01C8E2CA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3552; t=1215721277; x=1216585277; c=relaxed/simple; s=sjdkim2002; 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; bh=qGOvbtd5hdyCSIdpPQIK48gcYmJKGXML1+JVYz+OtMk=; b=oNiSJT5Bs23ldJ3mfqifMV4aRIYqkF3oC8x/JAUW7WusJ6/6JS2b4iflKV 2RlRruJRXV1Tid3T84UAYOQVbSm5B5a/AYxxVPZUzFyk9KbEk2ZLi91UD8hm nJaCziBHMx;
Authentication-Results: sj-dkim-2;; dkim=pass ( sig from verified; );
Cc: Thomas Narten <>,, Brian Haberman <>, Bob Hinden <>, Suresh Krishnan <>
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="iso-2022-jp"
Content-Transfer-Encoding: 7bit

The problem is that one problem is FAR more likely to happen than the other.

I shutdown my machine every night and power it on again in the morning when I come to work.
Therefore, every night of every workday I experience the type of outage described in our draft.
Furthermore, I occasionally go on vacations too - so the outage may last more than a day.

What this means for an administrator is that he has to predict, in advance, how long I may 
be on vacation so that the RA deprecating the old prefix can last long enough.  That puts
an unreasonable expectation on the network administrator.  Furthermore, I don't want to
have to get permission from my network administrator in order to go on vacation.

On the other hand, switch/router outages are typically noticed right away by many angry engineers
and are usually fixed in a matter of hours by the same administrators who control the RA.

This is not a minor implementation detail.  Fortunately, the DNA people also realized that this
was a potential problem and they have a solution specified - first deprecate the cached information
and verify before using it.  This solution will fix the blind cache reuse problem.  We propose this 
same solution in our new text (last paragraph of section 2) that Hemant just sent out.

- Wes

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [] 
Sent: Thursday, July 10, 2008 3:54 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden;
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Thu, 10 Jul 2008 12:09:01 -0400,
"Hemant Singh (shemant)" <>; wrote:

> Since you don't want any new rules added by our draft, we changed 
> bullet
> 3 related to caching on-link determination. The new bullet text does 
> not add any normative requirements but clearly says why it is a bad 
> idea to cache on-link determination.  Also, our draft is about on-link 
> determination - we are not adding anything related to IPv6 address 
> caching - we have said repeatedly, save it for another day.

The new text does not make sense to me.

In this scenario, the same problem can occur when a host (that just keeps working, without a reboot) happens to fail to receive the RAs containing 0-lifetime prefixes (such a failure can happen for various reasons: there may be a temporary failure in an intermediate switch; the host may have been just too busy and cannot handle the RAs, etc).  So, what's wrong in this scenario is that the router doesn't keep advertising 0-lifetime-prefixes sufficiently long.  This scenario itself doesn't explain 'why caching on-link prefix is a bad idea'.

This story also explains why I previously said "such caching is a minor implementation detail".  In terms of external behavior, a node that caches configured address/on-link prefix and reuses it after a reboot is often indistinguishable from a node that happens to fail receiving some updates from RA for some period.  Killing the former (while forgetting the latter) can just miss the more fundamental problem.

Aside from this essential point, the new bullet does also not make sense in the context of 'A correctly implemented IPv6 host MUST adhere to the following rules'.  If we find any valid 'justification' like this, it should be described outside this listing, somewhere more appropriate in the entire context.

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