Re: [mif] IPv4 similarity in DefRoute-distinct-from-RouteOption (was: Comments on draft-mouton-mif-dhcpv6-drlo-00)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 26 September 2011 13:04 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 C987621F8C2A for <mif@ietfa.amsl.com>; Mon, 26 Sep 2011 06:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.385
X-Spam-Level:
X-Spam-Status: No, score=-4.385 tagged_above=-999 required=5 tests=[AWL=1.864, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 X-u4lAvl0A8I for <mif@ietfa.amsl.com>; Mon, 26 Sep 2011 06:04:59 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id E7E3521F8BF3 for <mif@ietf.org>; Mon, 26 Sep 2011 06:04:58 -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.2) with ESMTP id p8QD7e9H020941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <mif@ietf.org>; Mon, 26 Sep 2011 15:07:40 +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 p8QD7eQe016433 for <mif@ietf.org>; Mon, 26 Sep 2011 15:07:40 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.183]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8QD7akZ021800 for <mif@ietf.org>; Mon, 26 Sep 2011 15:07:39 +0200
Message-ID: <4E807918.1020308@gmail.com>
Date: Mon, 26 Sep 2011 15:07:36 +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> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <B987CA14-569C-428C-8D8A-C97A0E42EF48@nominum.com> <4E6FA049.1040309@viagenie.ca> <4E803AE5.2000203@gmail.com>
In-Reply-To: <4E803AE5.2000203@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [mif] IPv4 similarity in DefRoute-distinct-from-RouteOption (was: 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 13:04:59 -0000

Maximilien,

With respect to one particular point you mention below:

Le 26/09/2011 10:42, maximilien mouton a écrit :
> Hi Simon and Ted,
>
> Le 13/09/2011 20:26, Simon Perreault a écrit :
>> Ted Lemon wrote, on 09/13/2011 02:22 PM:
>>> Could you please clearly articulate a use case where this option
>>> is necessary, and the existing proposed option is not adequate?
>>> Please do not mention operating system data structures. Please do
>>> not say "I find it to be the case that.." Without a use case, I
>>> just don't see the point in discussing this further.
>>
>> +1
[...]
> You can notice that router option and static route option (the
> stateful one) are defined separately since rfc 2132 (DHCP Options).
> Moreover, rfc 3442 (Route Option for DHCP version 4) has a similar
> point of view than what we propose with DRLO.

Looking through RFC2132 and RFC3442 I understand that DHCPv4 uses
distinct options for classful - and incidentally default - route (option
code 33), than for classless routes (121).  The reason for a new option
121 seems to have been the classlessness absence in classful routes at
thetime, and worse 33 option seems non-extensible.

Nonetheless, the IPv4 software ended up with distinct options: one for
default route and one for classless routes.  It would be little
straightforward to port that IPv4 software to IPv6 if this latter had
only one option for both route and default route.

Alex
[...]