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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Sun, 12 September 2010 15:27 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 209BB3A6896; Sun, 12 Sep 2010 08:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 Xe4CWFsGdcKw; Sun, 12 Sep 2010 08:27:39 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 69CD63A6817; Sun, 12 Sep 2010 08:27:36 -0700 (PDT)
Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id A38E494010D; Sun, 12 Sep 2010 17:27:57 +0200 (CEST)
Message-ID: <4C8CF178.5070002@gmail.com>
Date: Sun, 12 Sep 2010 17:27:52 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; 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: <C8B247DB.150B3%hesham@elevatemobile.com>
In-Reply-To: <C8B247DB.150B3%hesham@elevatemobile.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100912-0, 12/09/2010), Outbound message
X-Antivirus-Status: Clean
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: Sun, 12 Sep 2010 15:27:41 -0000

Le 12/09/2010 01:03, Hesham Soliman a écrit :
>
>>> =>   I thought we were discussing the specific issue of how to
>>> solve this problem in _this_WG_ as I mentioned in my first email.
>>> I know what the RFC says and I wouldn't have done it this way but
>>> given this, I don't know how else you can solve it _here_.
>>
>> I am open to solve it here and I have suggestion :
>>
>> - make DHCPv6-PD-NEMO assign a default route to the Mobile Router
>> at home.
>>
>> What do you think?
>
> =>  That can work but I don't understand why you don't like the host
>  on egress interface behaviour. The RFC seems inconsistent on its
> requirements for the egress interface at home, but it's been a long
> time since I read it so I may have forgotten some of the reasons. I
> think it can work and at least it will lead to a consistent
> implementation.

I am not sure which RFC you mean seem inconsistent?  If rfc3963 - yes,
it says MR MAY use the received RAs on the egress interface to
autoconfigure an address and form a default route.  However, I think in
practice pure linux does not do it (or am I missing radvd procsys
options?).  One would have to check the public NEMOv6 implementations
too.  Without NEMOv6 implementation this does not work (i.e. that MAY is
interpreted as a no on pure linux).  With it I don't know.

I myself have forgotten many of the reasons.  I think I vaguely remember
Pascal insisting of that being MR-autoconfigure an address as a MAY
because IIRC a Cisco router would autoconfigure an address and a default
route.  I am not very precise on this remembering.

If you mean RFC4861 then I think it is consistent andgood it has this
distinction between Host and Router (Router doesn't autoconfigure a
default route, etc.).  A router is more dangerous to Internet than a
host, so one would make sure things don't get autoconfigured in such a
dangerous manner as to break things and make loops.

> Extending DHCP can work but whether it's done here or in dhc or mif
> is not really important to me.

Same for me.

Remark that this behaviour (install a default route on a Router's
interface when DHCPv6-PD is used) should work irespective to whether or
not Mobile IPv6 is used (NEMOv6), whether or not that router has one or
multiple interfaces (MIF).

In this sense this default router installation upon DHCPv6-PD should be
probably DHC WG.  But they somebody there seemsto say the RR (requesting
router) uses SLAAC to autoconfigure a default route, not DHCP.  And that
a machine acts simultaneously as a host and a router (autoconfigure a
default route _and_ forward packets).  Which seems to be saying what you
were first saying, but still incoherent with that linux forward flag.

Alex

>
> Hesham
>
>>
>> I also followed advice and went asking to DHC WG.  I got redirected
>> to MIF soon-Charter DHCP options route table, and got mentioned
>> draft-ietf-v6ops-ipv6-cpe-router req W-3 talking DHCPv6-PD and
>> default route.
>>
>> Alex
>>
>>
>>>
>>> Hesham
>>>
>>>
>>>
>>>
>>>
>>
>
>
>