Re: [addr-select-dt] Proposed default policy table

Arifumi Matsumoto <arifumi@nttv6.net> Mon, 12 July 2010 09:16 UTC

Return-Path: <arifumi@nttv6.net>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8186D3A68D9 for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 02:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.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 5QbrsG10ulwH for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 02:16:56 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 0E30F3A659C for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 02:16:55 -0700 (PDT)
Received: from dhcp-3-143.nttv6.com (dhcp-3-143.nttv6.com [192.47.163.143]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o6C9H2W6024470; Mon, 12 Jul 2010 18:17:02 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Arifumi Matsumoto <arifumi@nttv6.net>
In-Reply-To: <4C3A5931.40709@tut.fi>
Date: Mon, 12 Jul 2010 18:17:02 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BEA2A00-5122-4946-884A-8AE873BB0781@nttv6.net>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi>
To: Aleksi Suhonen <Aleksi.Suhonen@tut.fi>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Mon, 12 Jul 2010 18:17:02 +0900 (JST)
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] Proposed default policy table
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 09:16:57 -0000

Hi,

I do not think it quite reasonable to leave much space between the rules, because the default rules can be cleared and overridden easily.

I agree with Alex in that the administrators tend to minimize the changes to the default rules. But it does mean to minimize the semantics changes, and not necessarily to minimize the lines of commands.

> Tony Hain also wrote:
> > Precedence  Label  Prefix
> > ----------  -----  --------------------------------
> ...
> >          1      6  fec0::/16
> 
> Aren't we removing site local completely while we're at it? Or if it should be kept around, then why not add 3ffe::/16 too for the same reason?

as per RFC3879,

4.  Deprecation



   This document formally deprecates the IPv6 site-local unicast prefix
   defined in [
RFC3513
], i.e., 1111111011 binary or FEC0::/10.  The
   special behavior of this prefix MUST no longer be supported in new
   implementations.  The prefix MUST NOT be reassigned for other use
   except by a future IETF standards action.  Future versions of the
   addressing architecture [
RFC3513
] will include this information.

   However, router implementations SHOULD be configured to prevent
   routing of this prefix by default.

   The references to site local addresses should be removed as soon as
   practical from the revision of the Default Address Selection for
   Internet Protocol version 6 [
RFC3484
], the revision of the Basic
   Socket Interface Extensions for IPv6 [
RFC3493
], and from the revision
   of the Internet Protocol Version 6 (IPv6) Addressing Architecture
   [
RFC3513
].  Incidental references to site local addresses should be
   removed from other IETF documents if and when they are updated.
   These documents include [RFC2772, 
RFC2894, RFC3082, RFC3111, RFC3142
,
   
RFC3177, and RFC3316
].

   Existing implementations and deployments MAY continue to use this
   prefix.


So, for the future use, we should not treat fec::/16 differently.
And for the time being, if we think about it may be used somewhere,
we should not treat fec::/16 differently.

And, it may be true for 3ffe::/16 also.


On 2010/07/12, at 8:52, Aleksi Suhonen wrote:

> Hi,
> 
> Tony wrote:
>> I suggest leaving 10, 40,&  80 in the precedence so people can move IPv4 or
>> ULA around without feeling the need to rewrite the other labels (they don't
>> have to, but an obvious hole to park it in reduces confusion).
> 
> The number of bits in the precedence value has not been defined, but I understand that most implementations use at least 32 bits anyway. I would like to see the default precedence values multiplied by 100 to leave more room for algorithmically generated entries and manual tinkering.
> 
> There are only 4 values available between fc00::/8 and fd00::/8 for example. Those could be easily consumed after a couple of corporate fusions.
> 
> I guess the idea has been that local administration can override all values to their liking. However, my understanding of the best practises for system and network administration is that the defaults are changed as little as possible. And the defaults should preferably "shine through" from under local modifications. This means that when the defaults are changed due to some software update, they might adversely interfere with the local changes.
> 
> I don't mind it if the default precedences are multiplied by even more than a hundred, I just feel it is important that there should be more space between the default values.
> 
> Tony Hain also wrote:
> > Precedence  Label  Prefix
> > ----------  -----  --------------------------------
> ...
> >          1      6  fec0::/16
> 
> Aren't we removing site local completely while we're at it? Or if it should be kept around, then why not add 3ffe::/16 too for the same reason?
> 
> -- 
> 	Aleksi Suhonen
> 	Department of Communications Engineering
> 	Tampere University of Technology
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt


--
Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories
  E-mail: arifumi@nttv6.net