Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 10 September 2010 14:34 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA943A6A4F; Fri, 10 Sep 2010 07:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6]
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 Ny9CO75bG3j6; Fri, 10 Sep 2010 07:34:22 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 287763A6A4A; Fri, 10 Sep 2010 07:34:16 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8AEYMYA028413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Sep 2010 16:34:22 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8AEYMWh027842; Fri, 10 Sep 2010 16:34:22 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8AEYLgS029167; Fri, 10 Sep 2010 16:34:22 +0200
Message-ID: <4C8A41ED.40402@gmail.com>
Date: Fri, 10 Sep 2010 16:34:21 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: Hesham Soliman <hesham@elevatemobile.com>
Subject: Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard
References: <C8B05DC7.14FB7%hesham@elevatemobile.com>
In-Reply-To: <C8B05DC7.14FB7%hesham@elevatemobile.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: IETF Discussion <ietf@ietf.org>, mext <mext@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2010 14:34:24 -0000

Le 10/09/2010 14:12, Hesham Soliman a écrit :
>
>
>
>>
>> When it is away from home it is fully a Host on the egress
>> interface. When at home fully Router on same.  I am happy with it
>> this way.
>>
>
> =>  Ok that doesn't make any sense to me.

Well, let me rephrase as the RFC text puts it: when the MR is at home it
joins the all-routers multicast address, otherwise it joins the
all-hosts address.  ND spec says similar.  Similarly, when MR at home it
can send RAs on the egress, if away it MUST NOT send RAs on it.  It must
always send RAs on the ingress.  This is to make sure MR doesn't break
the Internet routing.

Does this sound better?

>>> If so then let it do the same at home. Otherwise, I don't know
>>> how you want to fix this in this WG.
>>
>> It would mean to specify it to be a at home, be first a Host (get
>> default route) then change and become a Router, but still at home.
>
> =>  Ditto.

Let me phrase otherwise.

Current DHCPv6-PD-NEMO text draft-ietf-mext-nemo-pd-06 says:
> 3.2. Exchanging DHCPv6 messages when MR is at home
>
>
> When the MR is on its home link, the HA uses the home link to
> exchange DHCPv6PD messages with the MR (Figure 3).

It should say: "when the MR is on its homelink, it can obtain an IPv6
address and a default route with SLAAC (if it acts as a Host), or simply
an IPv6 address and no default route, with DHCPv6; then, the HA uses the
home link to exchange DHCPv6PD..."

And in this section:
> 3.5. Other DHCPv6 functions
>
>
> The DHCPv6 messages exchanged between the MR and the HA MAY also be
> used for other DHCPv6 functions in addition to DHCPv6PD.  For
> example, the HA MAY assign global addresses to the MR and MAY pass
> other configuration information such as a list of available  DNS
> recursive name servers [RFC3646] to the MR using the same DHCPv6
> messages as used for DHCPV6PD.

It should say: "neither DHCPv6-PD nor SLAAC allow MR to autoconfigure a
default route".  Is this better?

Do you think there's no need to autoconfigure a default route on the MR
at home?

Do you think there's no problem in the fact that RFC forbids MR to
autoconfigure a default route while connected at home?

Do you think there's no problem in the fact that SLAAC and DHCPv6-PD
implementations dont offer a default route to MR at home?

Do you think nothing should be done at IETF about default route,
DHCPv6-PD and NEMOv6 MR at home?

Alex