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

"Wes Beebee (wbeebee)" <> Thu, 10 July 2008 17:38 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 8735D3A6A17; Thu, 10 Jul 2008 10:38:21 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B16E53A6A1A for <>; Thu, 10 Jul 2008 10:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QFkNSzRNgTAD for <>; Thu, 10 Jul 2008 10:38:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6DE6C3A69AB for <>; Thu, 10 Jul 2008 10:38:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="13858259"
Received: from ([]) by with ESMTP; 10 Jul 2008 17:38:33 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m6AHcXwE030333; Thu, 10 Jul 2008 13:38:33 -0400
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m6AHcXx6009574; Thu, 10 Jul 2008 17:38:33 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 13:38:33 -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 13:38:52 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjiS/sGCjzEIIn7QqO4cUPjvJttCgAWfRAgAAMlhKA=
From: "Wes Beebee (wbeebee)" <>
To: "Hemant Singh (shemant)" <>, <>, "Suresh Krishnan" <>
X-OriginalArrivalTime: 10 Jul 2008 17:38:33.0162 (UTC) FILETIME=[C6286AA0:01C8E2B3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4393; t=1215711513; x=1216575513; c=relaxed/simple; s=rtpdkim1001; 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=22Hemant=20Singh=20(shemant)=22=20< m>,=20<>,=0A=20=20=20=20=20=20=20=20=22 Suresh=20Krishnan=22=20<>; bh=dMP9IqI2V1fiPBPFyDdvh87thZQKhlkzn1+v4gohzQs=; b=i2SWeROYNJiPgkF4NPJkVwSjjucBaY++CPFUyRRis2BnBmbiVEroCDgXth wWqA4LwPatC/r2PmLxRPAogqOOONYIi1JPcB4OZJXOUEK0pA5USyVzElSAiB ConUel1o0P;
Authentication-Results: rtp-dkim-1;; 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

We're against blind caching and re-use of unverified (and possibly
bogus) information.  If that information is deprecated and later
verified (as it is in DNA) - then the information can be re-used without
a problem.

Tatuya - 
In the new text, we have eliminated any normative language.  Therefore,
the draft is simply clarifying this point by demonstrating via example
what can go wrong if unverified cached information is later reused

We have also changed the title of section 2 from "Host Behavior Rules"
to "Host Behavior and Rules".

- Wes 

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Thursday, July 10, 2008 12:09 PM
To: ''org'; 'Suresh Krishnan'
Cc: Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden;
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt


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 old text of bullet 3 was:

       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

New text is as follows:

                  If on-link determination persists across IPv6
interface initializations,
                  then lack of IPv6 connectivity can result.  For
example, a host receives
                  an RA from a router with on-link prefix A.  The host
reboots.  During the 
                  reboot, the router sends out prefix A with on-link bit
set and a zero 
                  lifetime to indicate a renumbering.  The host misses
the renumbering.  
                  The host comes online.  Then, the router sends an RA
with no PIO.
                  The host uses cached on-link prefix A and issues NS's
instead of sending
                  traffic to a default router.  The "Observed Incorrect
Implementation Behavior"
                  section below describes how this can result in lack of
IPv6 connectivity. 


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

At Wed, 9 Jul 2008 20:54:04 -0400,
"Hemant Singh (shemant)" <> wrote:

> Thanks for the reply. Let's see if we can meet common ground with you.
> Our justification for prohibiting on-link caching is only in emails to

> 6man as follows:
>  "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."

And I replied to this justification, saying this itself cannot justify
killing on-link caching while (perhaps implicitly) allowing address

> Also, when Suresh Krishnan pointed out that he supports bullet 3, he 
> made us explicitly mention in the bullet that it's a new rule. We have

> been clear in the draft where there is a new rule and where it's 
> clarification. Besides this new rule, the rest of the draft is 
> clarification.

Suresh has his right to express his opinion, of course, and so do I.
I would not like this document to set new rules (note, again, that I'm
not objecting to discussing new changes to RFC4861/4862.  I'm simply
objecting to doing that in this document).

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