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

Tim Chown <tjc@ecs.soton.ac.uk> Sun, 11 July 2010 15:38 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 5886F3A67F5 for <addr-select-dt@core3.amsl.com>; Sun, 11 Jul 2010 08:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 bBuQeWNdjv+F for <addr-select-dt@core3.amsl.com>; Sun, 11 Jul 2010 08:38:31 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 208923A67B1 for <addr-select-dt@ietf.org>; Sun, 11 Jul 2010 08:38:30 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFcVHH030400 for <addr-select-dt@ietf.org>; Sun, 11 Jul 2010 16:38:31 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6BFcVHH030400
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278862711; bh=SPDgymgEjv8oEkPc0/o2LP4vk0Y=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=3rXhJTMnAXzZtUl9UJ6/gOOHXv50q/wkKUIe2Izd5ZWbmEpn5HO38HISSQB7xEniQ gLvGs/da4+lD185HVZk5JS1W2DE0FblWM9GED8o+gC+BXlRamSC4JZ0qEJV6zsqqAA TAuhZ/huXBtN/5rYVrTDyHgBmZdTnKBV9yyRDzuw=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id m6AGcV0540022400XK ret-id none; Sun, 11 Jul 2010 16:38:31 +0100
Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFcMk8016516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <addr-select-dt@ietf.org>; Sun, 11 Jul 2010 16:38:22 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
Date: Sun, 11 Jul 2010 16:38:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|f5316910468fa190c3198bf253519332m6AGcV03tjc|ecs.soton.ac.uk|E64E8887-0AFA-47F6-BA27-C584BDD3690B@ecs.soton.ac.uk>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <E64E8887-0AFA-47F6-BA27-C584BDD3690B@ecs.soton.ac.uk>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6AGcV054002240000; tid=m6AGcV0540022400XK; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6BFcVHH030400
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
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: Sun, 11 Jul 2010 15:38:33 -0000

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.

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