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

Arifumi Matsumoto <arifumi@nttv6.net> Mon, 12 July 2010 09:23 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 947DE3A688D for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 02:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.476
X-Spam-Level:
X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 xN1NniuWRhau for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 02:23:37 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 32F813A683C for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 02:23:36 -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 o6C9NA4W024516; Mon, 12 Jul 2010 18:23:10 +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: <alpine.BSF.2.00.1007120857410.21959@mignon.ki.iif.hu>
Date: Mon, 12 Jul 2010 18:23:10 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C357E96-7B8C-4751-A414-FAC8AADA7CC8@nttv6.net>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <E64E8887-0AFA-47F6-BA27-C584BDD3690B@ecs.soton.ac.uk> <EMEW3|f5316910468fa190c3198bf253519332m6AGcV03tjc|ecs.soton.ac.uk|E64E8887-0AFA-47F6-BA27-C584BDD3690B@ecs.soton.ac.uk> <alpine.BSF.2.00.1007120857410.21959@mignon.ki.iif.hu>
To: Mohacsi Janos <mohacsi@niif.hu>
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:23:11 +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:23:38 -0000

Hi,

On 2010/07/12, at 16:01, Mohacsi Janos wrote:

> 
> 
> 
> On Sun, 11 Jul 2010, Tim Chown wrote:
> 
>> Tony,
>> 
>> Now that 6rd is done, what's the view on 6to4?
>> 
>> I know a lot of people would be quite keen to see 6to4 deprecated.
> 
> I think 6to4 and teredo should be treated similarly - after ipv4. They should be used as a last resort acess to IPv6 resources. I think 6to4 should be kept since 6to4 is the most implemented IPv6 of the CPE equipments.
> 
> Best Regards,
> 		Janos Mohacsi

I agree.
It is clear to me that there is no longer preferences for 6to4 over IPv4, as well as preferences for Teredo over IPv4.

But, between 6to4 and Teredo, I tend to prefer 6to4.
Especially 6to4 host to 6to4 host communication is direct, there are some essential reasons to prioritize 6to4 over Teredo.

Regards,

> 
> 
>> 
>> Tim
>> 
>> On 8 Jul 2010, at 18:08, Tony Hain wrote:
>> 
>>> For updating 3484-revise section 2.2, the table I have been running at home
>>> for some time is:
>>> 
>>> Precedence  Label  Prefix
>>> ----------  -----  --------------------------------
>>>       90      0  ::1/128
>>>       75      1  fc00::/8
>>>       70      1  fd00::/8
>>>       50      2  2001::/16
>>>       50      2  2400::/8
>>>       50      2  2600::/8
>>>       50      2  2a00::/8
>>>       50      2  2c00::/8
>>>       40      3  2002::/16
>>>       30      3  2001::/32
>>>       20      4  ::/0
>>>       10      5  ::ffff:0:0/96
>>>        5      6  ::/96
>>>        4      6  fec0::/16
>>> 
>>> The explicit label 2 set is due to a bug in the vista stack, as that should
>>> be a single entry of 2000::/3, (and the fec0 should be /10). The differences
>>> from the proposed one in the October text are:
>>> - Adding explicit entries for each half of the ULA space to prefer local
>>> when possible (rule 2).
>>> - Explicitly listing 2000::/3 to avoid default resulting in the ambiguous
>>> choice of ula as src.
>>> - Keeping teredo and 6to4 as tunnels labeled the same.
>>> - Tunnels before default to avoid the ambiguous choices default will result
>>> in.
>>> - packaging all deprecated prefixes in the same label.
>>> 
>>> The currently proposed table in 2.2 does not solve the problem in 1.1, so it
>>> would be good to move that example to an appendix or at least after the 2.2
>>> discussion, and replace it with the one of a host selecting between Internet
>>> access and a closed network.
>>> 
>>> I understand the desire to move teredo to less than IPv4. While I disagree
>>> with the premise, a resulting policy table that does that might look like:
>>> 
>>> Precedence  Label  Prefix
>>> ----------  -----  --------------------------------
>>>       90      0  ::1/128
>>>       75      1  fc00::/8
>>>       70      1  fd00::/8
>>>       60      2  2000::/3
>>>       50      3  ::/0
>>>       30      4  2002::/16
>>>       20      5  ::ffff:0:0/96
>>>        5      4  2001::/32
>>>        1      6  ::/96
>>>        1      6  fec0::/16
>>> 
>>> 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). I haven't
>>> tried that, and don't have time before I leave today, but I will put that in
>>> and see how it works before the IETF meeting. It should be close to what the
>>> current text was trying to get to, but with the explicit ula and gua
>>> prefixes to avoid default it should work more consistently.
>>> 
>>> Tony
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> addr-select-dt mailing list
>>> addr-select-dt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>> 
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>> 
> _______________________________________________
> 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