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

Tim Chown <tjc@ecs.soton.ac.uk> Wed, 14 July 2010 10:03 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 504EA3A6A10 for <addr-select-dt@core3.amsl.com>; Wed, 14 Jul 2010 03:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 cJOjqFyn6Zbe for <addr-select-dt@core3.amsl.com>; Wed, 14 Jul 2010 03:03:55 -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 D2B9D3A67C2 for <addr-select-dt@ietf.org>; Wed, 14 Jul 2010 03:03:50 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6EA3rN9024703 for <addr-select-dt@ietf.org>; Wed, 14 Jul 2010 11:03:53 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6EA3rN9024703
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1279101833; bh=MyH/eAXANjVu+sFmzlwu41kCWGA=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=UxXVzO2GzXwwW9pdW/hXOHSDxwCz94hcqo1yyhMNihKnqZoOZ7Y9AEhLCn34dHt1D AS58XDrvlMt/ZlEz5FmESdx4xQZ5uLDCWtsuJQXDDO/o4Xihr3l+urr1AxJqHB75QF ps8bjLHmZH789gCBa6uJ+nmi4pRt7RlbOznOTewU=
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 m6DB3r0540038419hX ret-id none; Wed, 14 Jul 2010 11:03:53 +0100
Received: from ip-102-085.wireless.soton.ac.uk (ip-102-085.wireless.soton.ac.uk [152.78.102.85] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6EA3mOq022728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <addr-select-dt@ietf.org>; Wed, 14 Jul 2010 11:03:48 +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: <031f01cb22b7$daf1f280$90d5d780$@net>
Date: Wed, 14 Jul 2010 11:03:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|9ad1042ff9a4ca24061f8aad1b623bf0m6DB3r03tjc|ecs.soton.ac.uk|F1CB3122-22F1-4E4D-AD84-598AFF3AA02A@ecs.soton.ac.uk>
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> <031f01cb22b7$daf1f280$90d5d780$@net> <F1CB3122-22F1-4E4D-AD84-598AFF3AA02A@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=m6DB3r054003841900; tid=m6DB3r0540038419hX; 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: o6EA3rN9024703
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: Wed, 14 Jul 2010 10:03:56 -0000

I think that just reinforces why different policies are needed in different scenarios.   Using 6to4 for an enterprise would be 'brave' while in SOHO networks the view may be different.   An OS vendor/implementor can't cater with default settings for both.

Tim

On 13 Jul 2010, at 19:18, Tony Hain wrote:

> They server different communities. The people that actually provide a
> service would use 6rd, while people that want access despite their lethargic
> local loop provider would use 6to4. The people that want to deprecate 6to4
> want to force the world to be managed and keep the pesky users in their
> place. 
> 
> Tony
> 
> 
>> -----Original Message-----
>> From: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
>> bounces@ietf.org] On Behalf Of Tim Chown
>> Sent: Sunday, July 11, 2010 8:38 AM
>> To: addr-select-dt@ietf.org
>> Subject: Re: [addr-select-dt] Proposed default policy table
>> 
>> 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
>> 
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>