Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 13 March 2011 20:40 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 16A1F3A6A51 for <v6ops@core3.amsl.com>; Sun, 13 Mar 2011 13:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.444
X-Spam-Level:
X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 48Fg0paI-xP1 for <v6ops@core3.amsl.com>; Sun, 13 Mar 2011 13:40:08 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id AB2193A6A7C for <v6ops@ietf.org>; Sun, 13 Mar 2011 13:40:07 -0700 (PDT)
Received: by ywi6 with SMTP id 6so2396377ywi.31 for <v6ops@ietf.org>; Sun, 13 Mar 2011 13:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=okIJwipSkJhaanlMz7IsNopXKgjJTap8Tgve1YPixas=; b=UgOoE3CzB2cTM97QivrZLkT8jbjecsMX1tIkWwYhdAm5ek4RSQUkI4wDghXQ9o4ty7 DlTZV2ojBqeXY2WB0RdHgwH2nZe+cF3Jc+kv5JWG1lPBPuH/WXwoD105usWMewpaz4UM J2rb6+J7vlibtgctY9fapDU4yq98NnKd7ukLI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=gTKGhgKr6Mlw9gfAr+FlUEarJ0MHWPVeEcMCQZmQFHjAkUMg9xzMlTeR3rgJCsvZU9 BmEU3JxmHS/2NiXzzDVLhGfDqSrMv13TYJR+Qd2GwU9xKOoqxHiHQgqIpJcuRetKAy+e DiP7WLJaAq5GdV+uLuqBMCB3/8AeFjPhIzBj0=
Received: by 10.236.139.233 with SMTP id c69mr5690282yhj.141.1300048889859; Sun, 13 Mar 2011 13:41:29 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y21sm4681782yhc.18.2011.03.13.13.41.27 (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 13:41:28 -0700 (PDT)
Message-ID: <4D7D2BF5.9020400@gmail.com>
Date: Mon, 14 Mar 2011 09:41:25 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: v6ops@ietf.org
References: <20110305184502.18531.25548.idtracker@localhost>
In-Reply-To: <20110305184502.18531.25548.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.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: Sun, 13 Mar 2011 20:40:09 -0000

Hi,

> 3.  Conceptual Configuration Variables
> 
>    The CE Router maintains such a list of conceptual optional
>    configuration variables.
> 
>    1.  Enable an IGP on the LAN.

This section seems very strange with just one item sitting
there on its own, and no discussion in the draft of which
IGPs are candidates for support.

> 5.1.  DNS
> 
>    D-1:  For local DNS queries for configuration, the CE Router MAY
>          include a DNS server to handle local queries.  

What is the reason to include the words "for configuration"?

What is the meaning of "local queries"? Is this intended to imply that
there are names such as printer1.example.com that are only meaningful
and visible "inside" the CPE boundary? If so, what is the domain name?
Is the CPE supposed to know an appropriate domain name and if so, how?

>    D-2:  The local DNS server MAY also handle renumbering from the
>          Service Provider provided prefix for local names used
>          exclusively inside the home (the local AAAA and PTR records are
>          updated).  This capability provides connectivity using local
>          DNS names in the home after a Service Provider renumbering.  A

This is the only mention of renumbering in the draft. Is renumbering support
a goal? If so, please look at draft-jiang-ipv6-site-renum-guideline.
It is clearly not enough to just mention it as part of DNS support.

>          CE Router MAY add local DNS entries based on dynamic requests
>          from the LAN segment(s).  The protocol to carry such requests
>          from hosts to the CE Router is yet to be described.

Surely it should be RFC 3007?

>    LNDP-1:  If the CE Router has only one /64 prefix to be used across
>             multiple LAN interfaces and the CE Router supports any two
>             LAN interfaces that cannot bridge data between them because
>             the two interfaces have disparate MAC layers, then the CE
>             Router MUST support Proxying Neighbor Advertisements as
>             specified in Section 7.2.8 of [RFC4861].  If any two LAN
>             interfaces support bridging between the interfaces, then
>             Proxying Neighbor Advertisements is not necessary between
>             the two interfaces.  Legacy 3GPP networks have the following
>             requirements:

There needs to be a paragraph break before "Legacy 3GPP..."

Just below:

>             4.  No NAT66 is to be used.

Is this referring to NPTv6 or something else? It's important to be
clear, since trying to stop stateful NAPT66 is one battle, and trying to
stop NPTv6 is another.

>    The IPv6 CE Router SHOULD implement DS-Lite functionality as
>    specified in [I-D.ietf-softwire-dual-stack-lite].
...
>    The IPv6 CE Router SHOULD implement 6rd functionality as specified in
>    [RFC5969].

I'm really not sure about these SHOULDs. It's not they are bad things to include,
but there may be situations where they are insufficient and some other
form of tunnel is needed. At the very least say that other backhaul tunnel
mechanisms MAY be supported, without specifying them. Then add a corresponding
point in the next section:

> 5.5.3.  Transition Technologies Coexistence
> 
>    Run the following four in parallel to provision CPE router
>    connectivity to the Service Provider:
> 
>    1.  Initiate IPv4 address acquisition.
> 
>    2.  Initiate IPv6 address acquisition as specified by
>        [I-D.ietf-v6ops-ipv6-cpe-router].
> 
>    3.  If 6rd is provisioned, initiate 6rd.
> 
>    4.  If DS-Lite is provisioned, initiate DS-Lite.

  If this procedure fails, some other form of tunnel MAY be initiated.

Also, I think section 5.5.3 should recommend that the CPE be configurable
to block protocol 41 v6-in-v4 mechanisms when IPv6 connectivity is
available.

> 6.  Security Considerations
> 
>    None.

I think you need a few more words there, e.g.

This document introduces no security concerns that are
not discussed in the referenced specifications.

Finally,  idnits shows about 20 unused references.

Regards
   Brian Carpenter