[mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option

Tomasz Mrugalski <tomasz.mrugalski@gmail.com> Thu, 27 October 2011 12:18 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 54D1321F858C for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 05:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xCH1TvNgFoOy for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 05:18:01 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6C88221F8541 for <mif@ietf.org>; Thu, 27 Oct 2011 05:18:01 -0700 (PDT)
Received: by wyh22 with SMTP id 22so3232225wyh.31 for <mif@ietf.org>; Thu, 27 Oct 2011 05:17: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 :content-type:content-transfer-encoding; bh=xtCFd1EhoXs/yDEiwcueWftX5u+z56VHGaw6IooAp9U=; b=QIGMMbw/HGeDi4H6teAglM9pCDOAcKJXwi0r2PotaM6ZXHad6TzuIe7IxD+L2VBAlT f1PW7iUosSKohrVzaExdlmKZTsuF07nwz7wJSjprfQ2I8la+8+WiQPAqPiGiFBPbqzAk oCQ+tD0utoUZDzS2zIq64cBU5BInjZ3yObmjE=
Received: by with SMTP id fv19mr15512221wbb.27.1319717878874; Thu, 27 Oct 2011 05:17:58 -0700 (PDT)
Received: from [] (host-109-107-11-157.ip.jarsat.pl. []) by mx.google.com with ESMTPS id fi11sm9038274wbb.9.2011. (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 05:17:57 -0700 (PDT)
Message-ID: <4EA94BF6.5020501@gmail.com>
Date: Thu, 27 Oct 2011 14:17:58 +0200
From: Tomasz Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: mif@ietf.org
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: Margaret Wasserman <margaretw42@gmail.com>, Hui Deng <denghui02@hotmail.com>
Subject: [mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option
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: Thu, 27 Oct 2011 12:18:02 -0000

Dear Chairs, Dear MIF,

DHCPv6 Route Option draft has been presented in MIF several times. It
was also presented in DHC WG and most* (see below) comments were addressed.

I would also like to point out that this draft incorporates changes
after Routing Directorate review, especially insightful comments from
Joel Halpern about potential problems in networks that use dynamic
routing. The lastest (-03) drafts contains clear warning that
configuring routing over DHCPv6 in networks that use dynamic routing is
a very bad idea (unless you exactly now what you are doing).

* Authors chose to not incorporate some of the comments, raised by
authors of dlro draft. There was a discussion in MIF list. Route option
authors believe that:

1. defining separate option for just default route would be wrong. Let
me qoute Ted Lemon (DHC chair): "It's always a bad idea to have two ways
of specifying the same information—it creates a very clear potential for
interoperability problems.". On a related note, I was involved in work
on DS-Lite configuration over DHCPv6 and we initially had the same idea
- define two options (address and FQDN) for the same thing. This
approach was firmly rejected during IESG review. The message was clear:
"choose one option".

2. conveying MAC (or link-layer in general) address is not necessary.
There are other mechanisms like ND to obtain that information. Forcing
this information on every client is just a waste of space as all clients
that I know of can obtain this information on their own. They can do
that in a timely manner, so raised argument about speed-up is not valid
in my opinion. Another aspect is operational consideration. It would be
very cumbersome to deploy and use. If operator changes interface in its
router, DHCP configuration had to be updated and reconfigure procedure
initiated. It could work in theory, but reconfigure is not commonly
supported. DHCP server configuration would require knowledge of
link-layer addresses of announced router(s). We could gain nothing by
including MAC address, but get a lot of problems in the process.
Therefore dhcpv6-route-option authors chose to not include link-layer
information field.

I would like to point out again that route-option proposal is
extensible. It is designed as a minimal useful set of informations
necessary for routing configuration. There are many more aspects of
routing that may be useful in *some* cases. Therefore we made it clear
that proposed options are extensible. If there are valid cases when
extra information is useful, it should be defined as extension option.
That's they recommendation I offer to anyone who says "can you add
parameter X to route options? I really need it".

To summarize this summary, we believe that mif-dhcpv6-route-option draft
received enough reviews by experts in MIF, DHC and routing fields and is
ready for WGLC. Therefore I'd like to ask MIF chairs to announce one.

If we choose to have LC done in a timely fashion, we could discuss the
results in Taipei. If that is the case, I would like to request time
slot in Taipei meeting. I can't guess how many comments we will receive
during WGLC, but I hope 10 or 15 minutes will be enough.