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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 13 September 2011 18:28 UTC

Return-Path: <alexandru.petrescu@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 898D911E808E for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 11:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 CodYcJ8JPIfN for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 11:28:49 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1722011E80A2 for <mif@ietf.org>; Tue, 13 Sep 2011 11:28:39 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8DIUjYh016933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <mif@ietf.org>; Tue, 13 Sep 2011 20:30:45 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DIUjWi011919 for <mif@ietf.org>; Tue, 13 Sep 2011 20:30:45 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DIUfF9020649 for <mif@ietf.org>; Tue, 13 Sep 2011 20:30:45 +0200
Message-ID: <4E6FA151.7000906@gmail.com>
Date: Tue, 13 Sep 2011 20:30:41 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: mif@ietf.org
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
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: Tue, 13 Sep 2011 18:28:49 -0000

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?

Did DHCPv4 already offer routes?  Is there a document thanks?

This is quite an interesting question, and at first it may confuse.

I suppose you mean "Time To Live", as it could be the lifetime of a
route (and not as the TTL field of IPv4 datagrams which is an integer of
hops, as hopcount, despite its "Time" in "TTL").

In this sense, indeed, the question can be raised why a route
communicated with DHCP should have a lifetime associated with it.  And
answers exist.

In another sense, in IPv6 the TTL of IP datagrams (the hopcount, not the
time value) is "Hop Limit".  ND's RA does communicate a suggested Hop
Limit value for end hosts to configure on their local data structures.
E.g. RFC4861 uses a "Cur Hop Limit" value in an RA.

We have debated locally about proposing that "Cur Hop Limit" in DHCP as
well, alternatively to it being communicated by DHCP.

(sorry for dissecting the TTL question).

Alex

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