Re: Last Call: <draft-ietf-mif-current-practices-09.txt> (Current Practices for Multiple Interface Hosts) to Informational RFC
SM <sm@resistor.net> Mon, 25 April 2011 17:06 UTC
Return-Path: <sm@resistor.net>
X-Original-To: ietf@ietfc.amsl.com
Delivered-To: ietf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5AEEBE0774 for <ietf@ietfc.amsl.com>; Mon, 25 Apr 2011 10:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level:
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCQb8coPguFi for <ietf@ietfc.amsl.com>; Mon, 25 Apr 2011 10:06:35 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 65BEFE0767 for <ietf@ietf.org>; Mon, 25 Apr 2011 10:06:34 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3PH6NF5004692; Mon, 25 Apr 2011 10:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1303751192; bh=jfJWXrKn8fppC4tN9W7UK4aCdvkPha7jDB58hmLGN6E=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=mygy/QV7eh6m5ANkEAYDer052/VK9XxPFggZBmVO1y7Cf4ejruVrRI9gdWYOuB2ip SQsB4m1NKo+M26aE/VTQVzHliLt2D9K0J31vYjzRg/Z4p4TkBlTDMkvURWqFUi9M9O i6HFtKhXI2fBbiZ18oKN7rwep5DIzBRQixBjTczg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1303751192; bh=jfJWXrKn8fppC4tN9W7UK4aCdvkPha7jDB58hmLGN6E=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=zk/KD8nK/AQpY+v1lSjPH3awLENndT666zNbUCsvqAKmvd2+oddpbv8SFmVNu1IWu dTYKoPv0IydO39u/il08B4GyT+w0VM8U1x704IjJfFHb9yowluN0+wl7FNBY5SXB1G uf3fgNuWAqLcXNgj55U7ODGxt2wcLIxfMxncc0x0=
Message-Id: <6.2.5.6.2.20110425064026.03e7b6c8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 25 Apr 2011 07:31:28 -0700
To: ietf@ietf.org
From: SM <sm@resistor.net>
Subject: Re: Last Call: <draft-ietf-mif-current-practices-09.txt> (Current Practices for Multiple Interface Hosts) to Informational RFC
In-Reply-To: <20110328163814.1159.77824.idtracker@localhost>
References: <20110328163814.1159.77824.idtracker@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: Margaret Wasserman <mrw@painless-security.com>, Pierrick Seite <pierrick.seite@orange-ftgroup.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 17:06:37 -0000
At 09:38 28-03-2011, The IESG wrote: >The IESG has received a request from the Multiple Interfaces WG (mif) to >consider the following document: >- 'Current Practices for Multiple Interface Hosts' > <draft-ietf-mif-current-practices-09.txt> as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2011-04-11. Exceptionally, comments may be I missed the Last Call deadline. This I-D is worth reading if the person is interested in multiple-interface solutions implemented in some widely used operating systems. In Section 2.3.1: "On hosts with per-interface DNS server lists, different mechanisms are used to determine which DNS server is contacted for a given query. In most cases, the first DNS server listed on the "primary" interface is queried first, with back off to other servers if an answer is not received." This can result in the application trying to connect to the wrong destination node (Section 4.1 of draft-ietf-mif-problem-statement-13). In Section 3.1.3: "Depending on the network configuration, applications in reasearch In Motion (RIM) BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP connectivity or different application proxys to establish connections over the wireless network." There is a typo for "Research". See also "can use". In Section 3.2.1.3: "Windows uses a host-wide "effective" server list for an actual query, where the effective server list may be different for different names. In the list of DNS server addresses, the first server is considered the "primary" server, with all other servers being secondary." I suggest using "preferred" and avoid "primary" or "secondary" when discussing DNS servers in this context. In Section 3.2.1.3: "The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with specific instructions for each interface. However, each time new configuration data is received by the host from a DHCP server, regardless of which interface it is received on, the DHCP client rewrites the global configuration data, such as the default routes and the DNS server list (in /etc/resolv.conf) with the most recent information received. Therefore, the last configured interface always become the primary one. The ISC DHCPv6 client behaves similarly.: That rewrite can be overridden for OpenBSD dhclient ( http://www.openbsd.org/faq/faq6.html#DHCPclient ). Regards, -sm