RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

Dave Thaler <dthaler@microsoft.com> Thu, 01 March 2012 02:21 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941321E8014 for <ipv6@ietfa.amsl.com>; Wed, 29 Feb 2012 18:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.869
X-Spam-Level:
X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM-7HEM254PU for <ipv6@ietfa.amsl.com>; Wed, 29 Feb 2012 18:21:10 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6904E21E803A for <ipv6@ietf.org>; Wed, 29 Feb 2012 18:21:09 -0800 (PST)
Received: from mail68-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Mar 2012 02:21:09 +0000
Received: from mail68-ch1 (localhost [127.0.0.1]) by mail68-ch1-R.bigfish.com (Postfix) with ESMTP id D4DAD4001C1; Thu, 1 Mar 2012 02:21:08 +0000 (UTC)
X-SpamScore: -42
X-BigFish: VS-42(zz9371I1102K542M1432Ndf7Ozz1202hzz1033ILz2fh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail68-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail68-ch1 (localhost.localdomain [127.0.0.1]) by mail68-ch1 (MessageSwitch) id 1330568467808218_32643; Thu, 1 Mar 2012 02:21:07 +0000 (UTC)
Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail68-ch1.bigfish.com (Postfix) with ESMTP id BF226460045; Thu, 1 Mar 2012 02:21:07 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Mar 2012 02:21:07 +0000
Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 1 Mar 2012 02:20:58 +0000
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.17]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Wed, 29 Feb 2012 18:20:58 -0800
From: Dave Thaler <dthaler@microsoft.com>
To: Arifumi Matsumoto <arifumi@nttv6.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
Thread-Topic: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
Thread-Index: AQHM61TBqpyDXQSHVE+cgiqvxUSI2pZMJnCAgAiknaA=
Date: Thu, 1 Mar 2012 02:20:58 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <4EB3F3D6.4090302@innovationslab.net> <CAC1-dtnas++ahkBmpdyq7DbyAEg0W6bZY16qGzKmsP10vC39FQ@mail.gmail.com> <4EEA3D20.7020603@innovationslab.net> <CAKFn1SFvs0PzBXtEWWo814Oe5TJmbQEJBm5FeYJY5xzrr=KFSw@mail.gmail.com> <4EEA5793.8080800@gmail.com> <CAKFn1SHA-=cQ_=5rJVLVMvQYXoTL_D1dCR=uWZK-qFrcGp6P-w@mail.gmail.com> <4EEA7AF8.2090508@gmail.com> <CAC1-dtn9M8-9cPAmkhCiGV0Gi5+Gfs8GAssTOaA-ZFhyUY3feg@mail.gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <E6E7EE34-8244-40B6-84C1-C79E8BDE7921@nttv6.net> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net>
In-Reply-To: <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Thu, 01 Mar 2012 02:21:10 -0000

> -----Original Message-----
> From: Arifumi Matsumoto [mailto:arifumi@nttv6.net]
> Sent: Thursday, February 23, 2012 10:14 PM
> To: Brian E Carpenter
> Cc: Dave Thaler; Chris Grundemann; ipv6@ietf.org; Brian Haberman; Bob
> Hinden
> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
> 
> Dave,
> 
> in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found the response to
> this issue of ULA scope.
> 
> 10.6.  Configuring ULA Preference
> ...
>    Since ULAs are defined to have a /48 site prefix, an implementation
>    might choose to add such a row automatically on a machine with a ULA.
> 
>    It is also worth noting that ULAs are assigned global scope.  As
>    such, the existence of one or more rows in the prefix policy table is
>    important so that source address selection does not choose a ULA
>    purely based on longest match:
> 
>    Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
>    Destination Address List: ff00:1
>    Result: 2001:db8:1::1 (prefer matching label)
> 
> 
> IMO, this implicit specification causes several problems.
> 
> First of all, if you leave it to implementation, this creates an interoperability
> problem. In the sense that a site administrator, an application developer, a
> network designer, have to take care of the nodes with different address
> selection behavior.

Are you arguing it should be mandatory, not optional?  (I'm guessing so based
on the previous discussion of "macros" in the table.)

But still, you have to take care of nodes with different address selection behavior
anyway if you allow heterogeneous hosts, since you'll have
a) hosts that don't do RFC 3484
b) hosts that do RFC 3484
c) hosts that do 3484bis

And even within a category above, the IPv4 source address selection behavior
will vary since that's not specified.

At best you can argue to minimize the problem as much as possible, but
you can't make it go away.
 
> Second,
> when a user configures his policy table, the configured table is overwritten by
> this implementation dependent policy injection behavior ?
> Can the user suppress this behavior of policy injection ?
> This issue should arise also when a policy distributing mechanism is ready.

Good questions.  Do you have suggested answers to those questions?
I might throw out a strawman of:

Any automatic rows added by the implementation as a result of address
acquisition MUST NOT override a row for the same prefix configured
via other means.   That is, rows can be added but never updated
automatically.   An implementation SHOULD provide a means for
an administrator to disable automatic row additions.

-Dave