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

Erik Nordmark <erik.nordmark@sun.com> Mon, 14 July 2008 10:30 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C3228C253; Mon, 14 Jul 2008 03:30:57 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F17228C156 for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 03:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.694
X-Spam-Level:
X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZTzRUp+tc2F for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 03:30:55 -0700 (PDT)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 551A828C25C for <ipv6@ietf.org>; Mon, 14 Jul 2008 03:30:55 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.17.55]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6EAV1YV015447; Mon, 14 Jul 2008 10:31:01 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6EAUv3Z747367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 03:30:59 -0700 (PDT)
Message-ID: <487B2ADA.3090601@sun.com>
Date: Mon, 14 Jul 2008 03:30:50 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= <Jinmei_Tatuya@isc.org>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
References: <BB56240F3A190F469C52A57138047A03A9F348@xmb-rtp-211.amer.cisco.com> <m2r6a24lwi.wl%Jinmei_Tatuya@isc.org>
In-Reply-To: <m2r6a24lwi.wl%Jinmei_Tatuya@isc.org>
Cc: Thomas Narten <narten@us.ibm.com>, Bob Hinden <bob.hinden@nokia.com>, ipv6@ietf.org, Brian Haberman <brian@innovationslab.net>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

JINMEI Tatuya / 神明達哉 wrote:

> Anyway, I'm not convinced with this logic.  As I pointed out, killing
> on-link information caching effectively kills address caching, too, by
> making the cached address of almost no use.  Again, I'm personally not
> a fan of this caching trick, but effectively killing address caching
> with saying "we don't talk about address caching because it's out of
> scope of this document" sounds like an unfair action for me.

Jinmei,

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.

[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.

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

Regards,
    Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------