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

JINMEI Tatuya / 神明達哉 <> Fri, 18 July 2008 02:27 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 5ACB73A6A38; Thu, 17 Jul 2008 19:27:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9E043A6A05 for <>; Thu, 17 Jul 2008 19:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hMGkHKEGjJcs for <>; Thu, 17 Jul 2008 19:27:34 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:3:36::162]) by (Postfix) with ESMTP id 7E5773A6A1C for <>; Thu, 17 Jul 2008 19:27:34 -0700 (PDT)
Received: from (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by (Postfix) with ESMTP id 864EA33C2E; Thu, 17 Jul 2008 19:28:06 -0700 (PDT)
Date: Thu, 17 Jul 2008 19:28:06 -0700
Message-ID: <>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <>
To: Erik Nordmark <>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Cc: Thomas Narten <>, Bob Hinden <>,, Brian Haberman <>
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

At Mon, 14 Jul 2008 03:30:50 -0700,
Erik Nordmark <>; wrote:

> there are currently two places where we treat autoconfigured addresses 
> differently than on-link prefixes.
> One is the text about storing the address and associated lifetime in RFC 
> 4862 that we are debating here.
> The other one is the 2 hour rule that was very explicitly added only for 
> the addrconf property of the prefix and not the on-link property.
> I don't recall the different treatment for the first case.
> But for the second case I clearly recall the argument that loosing the 
> IP address (by an accidental or malicious RA with a zero valid lifetime 
> for the prefix) was considered a lot worse than loosing the on-link 
> property. Basically that loosing the IP address for a short time (it 
> might be re-added by the next RA) is something we must avoid, but that 
> "routing" (the on-link property) is something which must be able to 
> recover from temporary failures in any case.

Yes, I recall that discussion, too.

> [I don't know if the same argument was present when the storing of 
> addresses was discussed.]
> > I'd accept, if
> > 
> > 1. we prohibit both address caching and on-link caching (with
> >    reasonable argument, of course)
> > or,
> > 2. we don't talk about on-link caching (either allow or prohibit) if
> >    we don't talk about address caching
> > 
> > but it would be unfair if
> > 3. we prohibit on-link caching while ignoring its effect on address
> >    caching.
> If we are going to require that all aspects of a prefix should be 
> treated identically then to be consistent we must also make the 2 hour 
> rule be consistent (by either removing it for the addrconf property or 
> adding it to the on-link property).
> FWIW I think forcing such consistency is not necessary; it would just 
> result in unneeded changes to already deployed standards.

There's a subtle difference.  In the two-hour-rule case, we assume we
have a working router.  So even if the host looses its on-link prefix
information, it can still send packets to the router, having it
forward the packets and/or send a redirect back, etc.

In the address storing case, (at least in my understanding) we
consider the case when a router is temporarily out of service.  And
since we dropped the on-link-by-default rule, the cached address will
effectively be of no use.

> Is your concern that there are deployed implementations which store 
> on-link prefixes across reboots?

No, it's rather a meta level concern.  What I wanted to say (in case I
was not clear) is that we should not pretend that killing on-link
prefix caching is independent from address caching.  If we kill the
former, we will effectively also kill the latter (which has
implementors - note: we don't implement it).  So, IMO, if this
document wants to kill on-link caching, it should at least note that
it also kills address caching in effect.  If implementors of address
caching still think it's acceptable, then I have no objection to that
(I have no stake in that area, anyway).

I hope I'm clear this time.

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