Re: [mif] Five additional problem statements for mif ---- host routing

Lars Eggert <lars.eggert@nokia.com> Wed, 18 March 2009 04:14 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: mif@core3.amsl.com
Delivered-To: mif@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE993A6873 for <mif@core3.amsl.com>; Tue, 17 Mar 2009 21:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level:
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QgtNuKPXxT9 for <mif@core3.amsl.com>; Tue, 17 Mar 2009 21:14:40 -0700 (PDT)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 034A13A6802 for <mif@ietf.org>; Tue, 17 Mar 2009 21:14:38 -0700 (PDT)
Received: from 12-187-233-228.att-inc.com (12-187-233-228.att-inc.com [12.187.233.228] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2I4FD5Z039308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2009 06:15:15 +0200 (EET) (envelope-from lars.eggert@nokia.com)
Message-Id: <073A645F-0F8F-4611-A576-C924E9CA3853@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: Min Hui <huimin.cmcc@gmail.com>
In-Reply-To: <5dca10d30903172045g6bb8f43u3980dbc021a32932@mail.gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail-89--803008727"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 17 Mar 2009 21:15:12 -0700
References: <5dca10d30903172045g6bb8f43u3980dbc021a32932@mail.gmail.com>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Wed, 18 Mar 2009 06:15:16 +0200 (EET)
X-Virus-Scanned: ClamAV 0.94.2/9126/Wed Mar 18 01:07:14 2009 on fit.nokia.com
X-Virus-Status: Clean
Cc: mif <mif@ietf.org>
Subject: Re: [mif] Five additional problem statements for mif ---- host routing
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 18 Mar 2009 04:14:40 -0000

Hi,

well, you could also argue that the current source address selection  
is actually fine, and it's in fact the applications' fault, because  
they don't bind to a specific address. Not binding to an address is  
telling the OS "you choose for me". As long as there is only one  
interface, being lazy has no consequences, but if there are multiple  
interfaces, it does.

I agree that fixing this in the stack has distinct advantages over  
waiting for apps to be fixed, but I disagree that the current stack  
mechanism is broken - it isn't. It's the apps that are mostly broken.

Lars

On 2009-3-17, at 20:45, Min Hui wrote:

> Hi, everyone
>
> This is the first one: Host routing
>
> The host routing currently follows the default gateway mechanism,
> which will choose the unify gateway among more than one default routes
> ('0.0.0.0'), the detail is described in RFC1122. The default gateway
> guarantees there always has a route to network when the host can not
> find a specific route for a datagram in the route table.
> But when it comes to multiple interfaces situation, the default
> gateway mechanism in host routing will let all the IP flows go out
> through one interface except some specific assignment (e.g. static
> routing item). In this case, the applications can’t use different
> interfaces which are the aim of multiple interfaces. The reason is the
> application will not appoint a source address in most situations
> currently. The source address will be determined by host operating
> system after querying the host routing table, if there is any
> available routing item for the destination, the corresponding source
> address of this routing item will be selected. In most cases, the
> routing item of default gateway will be used, so that every
> application will use the same interface.
> In conclusion, the above host routing mechanism is one of problems in
> the way to maintain multiple interfaces work simultaneously.
>
> - Hui Min
>
> 2009/3/18 Min Hui <huimin.cmcc@gmail.com>:
>> Hi, all mif fans
>>
>> I have viewed the agenda of mif bof, and I notice some problem
>> statements for mif are not concluded in the current ps documents  
>> which
>> will be discussed in the meeting.
>> So I post these additional problems in the mail list for discussion,
>> all of them come from the draft
>> "draft-hui-ip-multiple-connections-ps-02" with some modifications
>> according to the comments received recently.
>> There are five problems in addition, which will be proposed in five
>> separated mails in order to have sufficient discussion for each of
>> them.
>> Five mails will be sent out following this mail, the structure is:
>> 1. Host routing
>> 2. DNS selection
>> 3. Different metric measurements
>> 4. Source address selection for IPv4
>> 5. TOS consideration
>>
>> Any comment is welcomed, and thanks for your notice.
>>
>> BR,
>> - Hui Min
>>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif