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

Arifumi Matsumoto <arifumi@nttv6.net> Fri, 24 February 2012 06:15 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 3196321F883B for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2012 22:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.29
X-Spam-Level:
X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 EZ+tvRMxLdmI for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2012 22:15:12 -0800 (PST)
Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8556E21F87C9 for <ipv6@ietf.org>; Thu, 23 Feb 2012 22:15:10 -0800 (PST)
Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1O6G55N083720; Fri, 24 Feb 2012 15:16: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: <4F3ABFBA.8060605@gmail.com>
Date: Fri, 24 Feb 2012 15:13:59 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <29EBA88D-BDB1-464C-915F-B9063578DC51@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>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: Bob Hinden <bob.hinden@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>, Dave Thaler <dthaler@microsoft.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, 24 Feb 2012 06:15:13 -0000

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.

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.

Kindest regards,

On 2012/02/15, at 5:10, Brian E Carpenter wrote:

> On 2012-02-15 05:49, Arifumi Matsumoto wrote:
>> Dave,
>> 
>> one quick question below.
>> 
>> On 2012/02/11, at 11:41, Dave Thaler wrote:
> 
> ...
>>> As such, I believe the correct fix is not to put fc00::/7 into the policy
>>> table, but instead to update section 3.1 to say that we map ULAs to
>>> multicast site-local scope.   The existing scope rules would then have
>>> the effects I argue are the right answers above.
>> 
>> So, you are suggesting to map ULAs(fc00::/7) to site-local scope also for unicast ?
>> Then, I don't see how the former case can be solved by this fix.
>> The ULAs should be chosen for both src and dst addresses, if they have smaller
>> scope than global addresses, right ?
> 
> IMHO we have to be very careful about messing with the formal scope of ULAs.
> They are unambiguously defined *architecturally* as having global scope,
> and address selection rules have to respect that (unless we make a major
> architectural effort, since IMNSHO our whole concept of unicast scope is
> broken).
> 
> In other words - in the unicast domain, ULAs have to stay global, and longest-
> match or explicit rules are the only solution.
> 
> Multicast is a different matter, since site-local scope is well defined there.
> 
>> 
>> Or, are you suggesting to map only ULAs that is in the same prefix to site-local scope ?
> 
> Not needed; longest match takes care of that. The tricky case is where you
> have several ULA prefixes in use on the same site.
> 
>    Brian


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