Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

maximilien mouton <maximilien.mouton@gmail.com> Mon, 26 September 2011 08:41 UTC

Return-Path: <maximilien.mouton@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F047B21F8B50 for <mif@ietfa.amsl.com>; Mon, 26 Sep 2011 01:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBTBVjhHynzj for <mif@ietfa.amsl.com>; Mon, 26 Sep 2011 01:41:18 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1CE921F8B3F for <mif@ietf.org>; Mon, 26 Sep 2011 01:41:17 -0700 (PDT)
Received: by eye4 with SMTP id 4so3510124eye.31 for <mif@ietf.org>; Mon, 26 Sep 2011 01:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Nimjn21Owog7VFt11w6l8vKHfJBPAcp8EqfgyUSlsr8=; b=AUgc/vI/bhGU+0cqwv4NV8Wj4PiQzuLday8VLNckcLxCM3n/BnJm8fXvcMQDZ869rL Pywq/an1f1KEHSU5J0wRnEKRD8vyuTvvov/Up7qIW0JLll59Nr8y6ZlkfUGKFX32wTe8 tFaUoEAQU4dEpkX6aLMsy/s9OSfNE2hfxyf3Q=
Received: by 10.213.27.68 with SMTP id h4mr1543142ebc.108.1317026638094; Mon, 26 Sep 2011 01:43:58 -0700 (PDT)
Received: from [127.0.0.1] ([158.64.77.102]) by mx.google.com with ESMTPS id v9sm57832778eej.5.2011.09.26.01.43.57 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 01:43:57 -0700 (PDT)
Message-ID: <4E803B3A.7010905@gmail.com>
Date: Mon, 26 Sep 2011 10:43:38 +0200
From: maximilien mouton <maximilien.mouton@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <CFDF82EE-052B-4A61-AE1B-152337822B6E@nominum.com> <4E6F967B.5030909@gmail.com> <F7334D5F-6C4D-4B60-9F30-A0A9C729DE29@nominum.com>
In-Reply-To: <F7334D5F-6C4D-4B60-9F30-A0A9C729DE29@nominum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "<mif@ietf.org>" <mif@ietf.org>
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2011 08:41:19 -0000

Hi Ted again,

Le 13/09/2011 19:56, Ted Lemon a écrit :
> On Sep 13, 2011, at 1:44 PM, Maximilien MOUTON wrote:
>> Even if I grant It would imply big changes in DHCP, I think it
>> would be interesting for DHCP to imitate ND dynamic behavior
>> because in this draft we are trying to challenge ND by allowing
>> DHCP to provide an entire IP/Internet configuration by its own.
>
> We never had a TTL on the route offered in DHCPv4. Why is DHCPv6
> different?

DHCPv6 could be different because of ND.
Why include a lifetime in default router list option(DRLO)?

ND has been chosen as the best way for default router configuration
because it provides a dynamic autoconfiguration.

But in some case RA is not set or not desirable. This is what describes
Ralph Droms in draft-droms-dhc-dhcpv6-default-router-00. This is why
DHCP should provide default router also.

Use cases for using default router lifetime are actually each cases in
which you can use ND for autoconf and either you can't or don't want to.
An example of scenario is given in the draft.

As we are here challenging ND as an autoconfiguration mechanism we
propose a solution which tries to imitate its dynamic behavior. This is
why we propose a lifetime.
Here's a concrete case to illustrate this:

A client has multiple default routers available. Usually if those
routers use RA if the selected default router fails, the connectivity of
the client is down while the lifetime of the router in its default
router list is not null. At this time another default router is selected.
But if a static configuration is used without lifetime, as far as I
know, the default router list is not updated and the client connectivity
is never recovered whereas it could be.
The default router lifetime could solve this problem by making the
failed router expire in the client's default router list and let another
one take its place.

We receive also questions about the interest of providing a link layer
address.
Why a link layer address field?

Because it avoids unnecessary NS/NA exchange which represents an economy
of network resources (very useful for some resource constraint networks)
and a gain of time because client don't need to wait for NA anymore.
This field is also useful if ND is nor present in the link between the
client and the router.

Maximilien

>
>
>
> _______________________________________________ mif mailing list
> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif