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

Arifumi Matsumoto <arifumi@nttv6.net> Fri, 16 March 2012 10:31 UTC

Return-Path: <arifumi@nttv6.net>
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 EC85421F8601 for <ipv6@ietfa.amsl.com>; Fri, 16 Mar 2012 03:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.338
X-Spam-Level:
X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, 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 skEmoM98eq9r for <ipv6@ietfa.amsl.com>; Fri, 16 Mar 2012 03:31:23 -0700 (PDT)
Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1D05721F85F9 for <ipv6@ietf.org>; Fri, 16 Mar 2012 03:31:23 -0700 (PDT)
Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q2GAW577065556; Fri, 16 Mar 2012 19:32:05 +0900 (JST) (envelope-from arifumi@nttv6.net)
Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="us-ascii"
From: Arifumi Matsumoto <arifumi@nttv6.net>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Date: Fri, 16 Mar 2012 19:30:07 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8827D58-5C69-4A44-B9CE-86791466814E@nttv6.net>
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> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
To: Dave Thaler <dthaler@microsoft.com>
X-Mailer: Apple Mail (2.1257)
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: Fri, 16 Mar 2012 10:31:24 -0000

Dave,

On 2012/03/01, at 11:20, Dave Thaler wrote:

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

Rather, my question was about the design choice.

Regarding the design of ULA and how to use the ULA, can we agree that 
ULA-to-ULA communication within the same /48 prefix is not always preferred
over other communications using IPv4 or IPv6 global addresses ?

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


My suggested answer for this was to use macros, which can be
added/deleted by a user, and interpreted as the actual prefix
attached to the hosts.

Best regards,

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: arifumi@nttv6.net
  TEL +81-422-59-3334 FAX +81-422-59-6364