[mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 02 August 2011 15:22 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 C041C21F8783 for <mif@ietfa.amsl.com>; Tue, 2 Aug 2011 08:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw-bzWHVFoex for <mif@ietfa.amsl.com>; Tue, 2 Aug 2011 08:22:12 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id CA91E21F8781 for <mif@ietf.org>; Tue, 2 Aug 2011 08:22:11 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p72FMKV7010763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 17:22:20 +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 p72FMJRs004959; Tue, 2 Aug 2011 17:22:19 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p72FMJiY010347; Tue, 2 Aug 2011 17:22:19 +0200
Message-ID: <4E38162B.1040507@gmail.com>
Date: Tue, 02 Aug 2011 17:22:19 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: mif <mif@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02
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, 02 Aug 2011 15:22:12 -0000

Hello MIF WG,

Recently, there were comments on the mailing list about default route,
source address and draft-ietf-mif-dhcpv6-route-option "DHCPv6 Route
Options" (subsequently called "route-option" draft).  Moreover, I
commented on the microphone during the MIF WG meeting in Québec, IETF81.

I would like to further detail these comments by email.

- I need a means to communicate the default route to a Host by using
   DHCPv6 (instead of RA).

- the route-option draft specifies to use DHCPv6 to communicate routes
   (tuples prefix-nexthop) to a Client.  This can indeed be used to
   communicate a default route as a particular kind of route (i.e. use
   "::/0" as prefix and the IP  address of a default router as
   "nexthop".)

   The encoding used by the route-option draft is of the form:
   nexthop-prefix, nexthop-prefix-prefix-prefix, etc.

   Whereas this use of this route-option mechanism to communicate
   default routes is possible, and is extensible, it currently lacks a
   number of features necessary to communicate default routes.

- it is a waste of memory and bandwidth to communicate 136bits of
   prefix, as the route-option draft does, when it is known that that
   prefix is ::/0 in the case of default route (RFC).  We don't see a
   simple means to optimize the format of the Route Prefix Option
   (including the mandatory 136bits) of the current route-option draft.

- the default route is special ("when everything else fails"), it is
   not a simple prefix-nexthop route, because:

- the default route appears in a linux routing table as another typical
   route but it appears as well in the mandatory ND Default Router List
   associated with more parameters (actually dereferenced pointers to
   the Neighbor Cache).

- the default route is better if it uses a Lifetime.  It is assumed ND
   is already implemented by the vast majority of IPv6 Hosts.  (1) The
   current route-option draft mentions Lifetime to be managed according
   to general events of DHCP (and not of ND) - this may lead to
   incoherent behaviour when both DHCP and ND are run on same Host.  (2)
   The Lifetime of DHCP is on 32bits whereas of ND is on 16bit.

- it may be advantageous to communicate the MAC address of the gw of
   the default route, with DHCP.  This may speed up implementation,
   because it avoids the Host to need to perform NS/NA for the IP
   address of the gw of the default route.  The draft route-option does
   not communicate a MAC address.

- the route-option draft can communicate several default routes as
   follows: nexthop-prefix, nexthop-prefix,...  However, a more
   efficient scheme is possible as follows: 1bit, nexthop, nexthop,...

- the scope of the route-option draft reads as environments where
   routing protocols are more appropriate, whereas a more reduced scope
   could be to focus exclusively on the obtention of the default route
   as part of basic IP connectivity (not necessarily the complex
   topologies afforded by routing protocols).

We believe a better technique is possible to communicate default route
with DHCPv6.

What do people think about these comments?

Yours,

Alex