Re: [v6ops] Objection: draft-ietf-v6ops-ipv6-cpe-router-09.txt

Rémi Després <remi.despres@free.fr> Tue, 21 December 2010 14:55 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97323A69F3 for <v6ops@core3.amsl.com>; Tue, 21 Dec 2010 06:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.262
X-Spam-Level:
X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 Kxy8zh69SPmS for <v6ops@core3.amsl.com>; Tue, 21 Dec 2010 06:55:23 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by core3.amsl.com (Postfix) with ESMTP id 825A73A68B5 for <v6ops@ietf.org>; Tue, 21 Dec 2010 06:55:23 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id D16B57000094; Tue, 21 Dec 2010 15:57:18 +0100 (CET)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id 5EAA9700008E; Tue, 21 Dec 2010 15:57:18 +0100 (CET)
X-SFR-UUID: 20101221145718387.5EAA9700008E@msfrf2209.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <EMEW3|efea6f59b4133972bcd7a238a757dc7fmBKCe903tjc|ecs.soton.ac.uk|26FEAE1D-A904-4787-9FF5-60FAA875CFB4@ecs.soton.ac.uk>
Date: Tue, 21 Dec 2010 15:57:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EB460D6-8393-4CC8-A127-C37DB10E61DD@free.fr>
References: <20101220180002.20601.96769.idtracker@localhost> <4D0FA944.4070301@gmail.com> <7BBE2CDB-1444-4341-9D5F-62620034C942@ecs.soton.ac.uk> <EMEW3|38da676a2c661937f336f3701a7cb170mBJKB403tjc|ecs.soton.ac.uk|7BBE2CDB-1444-4341-9D5F-62620034C942@ecs.soton.ac.uk> <53752ADB-6F34-4F45-979C-6ED4204A570E@apple.com> <4D0FC646.2040009@gmail.com> <732C2D41-FCD9-462E-A51A-01B69BF10E37@apple.com> <C210C609-CA14-4841-863B-1FB24F8A2E4F@cisco.com> <4D0FDD83.6080205@gmail.com> <4081B8F0-90EE-46BD-9668-930959D18A20@free.fr> <A92F8177-52FB-478B-9CE6-34247D537140@ecs.soton.ac.uk> <EMEW3|2015ee665b9c7a6dbe9d480481ed6441mBKAMx03tjc|ecs.soton.ac.uk|A92F8177-52FB-478B-9CE6-34247D537140@ecs.soton.ac.uk> <2E17533E-9B5B-483F-BA8A-2EB99DBBE6C8@free.fr> <26FEAE1D-A904-4787-9FF5-60FAA875CFB4@ecs.soton.ac.uk> <EMEW3|efea6f59b4133972bcd7a238a757dc7fmBKCe903tjc|ecs.soton.ac.uk|26FEAE1D-A904-4787-9FF5-60FAA875CFB4@ecs.soton.ac.uk>
To: Tim Chown <tjc@ecs.soton.ac.uk>
X-Mailer: Apple Mail (2.1082)
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Objection: draft-ietf-v6ops-ipv6-cpe-router-09.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Dec 2010 14:55:24 -0000

Le 21 déc. 2010 à 13:40, Tim Chown a écrit :

> 
> On 21 Dec 2010, at 11:39, Rémi Després wrote:
> 
>>> I think there's some confusion here.    The MUST is that CE is able to *generate* a randomised ULA prefix as per RFC4193.    ULA-1 isn't about what is advertised.   Indeed the default for whether ULAs are advertised or not is not prescribed in the text. 
>> 
>> Right, good point.
>> 
>> The proposal should better have been:
>> "ULAL-1:   The IPv6 CE router SHOULD be capable of generating a pseudo-random ULA prefix [RFC4193]. If it isn't, it still MUST have an IPv6 prefix to use when its WAN interface is not operational, e.g. a ULA-like constant values like fd01::/48."
>> 
>> Note that, since user configuration of ULA prefixes is permitted, defaulting to fd00::/48 is equivalent, in unmanaged CPEs, to having a magic hand configuring it (fd00::/48 is a permitted possible of a pseudo-random generation).
> 
> Well, as it was in the -08 version, ULA-1 and ULA-2 taken together allow a CE to have its ULA prefix either automatically or manually configured, though the latter is a SHOULD.    So you don't need your extra text encouraging use of fd01::/48.


>   Yes, some users may do that, but I don't think we should suggest it.

In my reading of -08, the ability to  it may either be pseudo-randomly or manually generated.
- This doesn't include a CPE that uses a predefined local prefix without manual configuration.
- This doesn't include either an ISP provided CPE that keeps using its last global IPv6 prefix when the WAN interface is down. (This is AFAIK what IPv6 users of Free have had since 2007, to their entire satisfaction).  

Do we want to formally exclude IPv6 operational behaviors that have proved to work?


> The ULA concept isn't really stated anywhere in the text.

IMHO, the reference to RFC4193 is enough (no need to revise -09 for this).

>   Perhaps section 3.2.1 should say something like "Internal IPv6 LAN interfaces may be provisioned concurrently with both a delegated globally unique prefix and a ULA prefix.   The global prefix may then be used for communications to external hosts, while ULAs may be used on the internal network to give persistent addressing through external renumbering events (even for single LAN sites) or in the event of no external connectivity being available".   This may help avoid readers of the draft associating ULAs with NAT66.

This part of the discussion has been closed.
AFAIK, the relationship with NAT66 is no longer asked to influence the document. 

> In practice the usefulness of ULAs - at least with current IPv4-style models and without considering SmartGrid type scenarios - will depend on whether IPv6 ISPs give customers dynamic IPv6 prefixes. While you can argue ULAs may help in the event of a temporary connectivity outage, the existing global prefix should still be sufficient to maintain internal connectivity.

Indeed.

>    I think these issues are more likely to be incorporated in more detail in the -bis Advanced draft, but we shouldn't preclude the option to provision ULAs in the 'basic' CE definition.

With a SHOULD, it isn't precluded, and some CPEs that do work don't see their behavior precluded.

Regards,
RD