Thanks for your remindness, Updated minutes based on your comment

=A0

Regards,

=A0

-Hui

2010/8/3 Marc Blanchet <marc.blanchet@viagenie.ca>=

thanks.
=A0the first page or = so, there is the use of "I", and "you", without clear i= ndication who is speaking, while the rest of the minutes it is more clear. = I'm guessing I means chairs and you means wg members. Might be appropri= ate for the note takers to add the speaker name as in the rest of the minut= es. That would be more clear to who speaks and on behalf of what.

Marc.

Le 10-08-03 05:00, Hui Deng a =E9crit :

Hello all
Thanks Scott's Minute and Behcet for Jab= ber.
Please feel free to comment on it
http://www.ietf.org/proc= eedings/78/minutes/mif.txt
Best regards,
-Hui

_______________________________________________
mif ma= iling list
mif@ietf.or= g
https://www.ietf.org/mailman/listinfo/mif

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D
IPv6 book: = Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW travers= al: http://numb.viag= enie.ca
DTN news service: = http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca
<= br>_______________________________________________
mif mailing list
mif@i= etf.org
https://www.ietf.org/mailman/listinfo/mif

--001636c5961dca28fe048cf6bb4e-- From teemu.savolainen@nokia.com Sat Aug 7 06:26:11 2010 Return-Path: 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 255CD3A6940 for ; Sat, 7 Aug 2010 06:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 sODYAFyjVMEb for ; Sat, 7 Aug 2010 06:26:07 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B7C633A6833 for ; Sat, 7 Aug 2010 06:26:07 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o77DQaZa032242 for ; Sat, 7 Aug 2010 08:26:38 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Aug 2010 16:26:36 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Aug 2010 16:26:31 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Aug 2010 16:26:26 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Sat, 7 Aug 2010 15:26:26 +0200 From: To: Date: Sat, 7 Aug 2010 15:26:25 +0200 Thread-Topic: Preferring IPv4 interface over IPv6 interface? A problem to be covered? Thread-Index: Acs2M2M8IvY90k9FTl6tBTFu8u3m7Q== Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Aug 2010 13:26:26.0646 (UTC) FILETIME=[232BBF60:01CB3634] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com Subject: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 13:26:11 -0000 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mif, Currently hosts generally prefer IPv6 over IPv4 communications. However, a = multi-homed host may have IPv6 available only on a less preferred interface= . For example, host's destination may be reachable over both IPv4 and IPv6,= but the host has an IPv6-only cellular (maybe less preferred) and IPv4-onl= y local WLAN interfaces (maybe more preferred). Do you think in such a case a MIF host should actually prefer IPv4 communic= ations instead of IPv6? Current single homed hosts would probably have chos= en to use WLAN for all communications anyway. Do you think this preference should be part of a distributed policy, or som= ething the host just should make its own mind about? Best regards, Teemu --_000_18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mif,

Currently hosts generally prefer IPv6 over IPv4 communications. However, a multi-homed host may have IPv6 available only on= a less preferred interface. For example, host’s destination may be reachable over both IPv4 and IPv6, but the host has an IPv6-only cellular (= maybe less preferred) and IPv4-only local WLAN interfaces (maybe more preferred).=

Do you think in such a case a MIF host should actually prefer IPv4 communications instead of IPv6? Current single homed hosts woul= d probably have chosen to use WLAN for all communications anyway.<= /p>

Do you think this preference should be part of a distr= ibuted policy, or something the host just should make its own mind about?

Best regards,

Teemu

--_000_18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03NOKEUMSG01mgd_-- From brian.e.carpenter@gmail.com Sat Aug 7 14:57:25 2010 Return-Path: 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 6DAA43A6A28 for ; Sat, 7 Aug 2010 14:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 61Eoul9TLkMa for ; Sat, 7 Aug 2010 14:57:24 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 1DC5D3A6831 for ; Sat, 7 Aug 2010 14:57:23 -0700 (PDT) Received: by pxi20 with SMTP id 20so3774174pxi.31 for ; Sat, 07 Aug 2010 14:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UjJhWCIhAjguCrldvIL1xnYJEJWbFDM7CmsDUimGrs4=; b=cltsYWgA4gFDLX3Q2GC5AZp224Ar1VAPFzbd7yPUU12cgAZJObXcNIemYZ+JKMKBx9 WkgerFXu0Uv6CA1tj3HIg5Crc3KkU8t+9fYC+bZxAaK5kTbZIR0EOx9WERIwRz0/glcD qaGwtNbdSjAN1eeQQECjQSX0Bo971p77UYA0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=OEEvZ9c8iDKLdkO1Ea8xSgsemFXuI2lbCKsr7Q+C+LxVRrEMMAQjUDS7aB5yldhFTP 2gXR6sa5kpKkGsxd4eZ2P66Clh7NYMo7P2qsBahVqQdR9fOTM/CE8F0exC3rzXT6HZ7V QVVwJvxs8bnVAG8ImzXCpejLEciXlq7NHvIG0= Received: by 10.114.59.1 with SMTP id h1mr16115124waa.28.1281218275748; Sat, 07 Aug 2010 14:57:55 -0700 (PDT) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id 33sm6192193wad.18.2010.08.07.14.57.53 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Aug 2010 14:57:55 -0700 (PDT) Message-ID: <4C5DD6DD.8090607@gmail.com> Date: Sun, 08 Aug 2010 09:57:49 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 21:57:25 -0000 Teemu, Shouldn't the decision about that be part of the RFC 3484 update discussion over in 6man? Or should we logically separate the question of 'preferred interface' from the question of 'preferred address prefix'? Then it can be a local policy issue whether you give priority to the interface choice or to the prefix choice. (Or to measured performance.) Regards Brian On 2010-08-08 01:26, teemu.savolainen@nokia.com wrote: > Mif, > > Currently hosts generally prefer IPv6 over IPv4 communications. However, a multi-homed host may have IPv6 available only on a less preferred interface. For example, host's destination may be reachable over both IPv4 and IPv6, but the host has an IPv6-only cellular (maybe less preferred) and IPv4-only local WLAN interfaces (maybe more preferred). > > Do you think in such a case a MIF host should actually prefer IPv4 communications instead of IPv6? Current single homed hosts would probably have chosen to use WLAN for all communications anyway. > > Do you think this preference should be part of a distributed policy, or something the host just should make its own mind about? > > Best regards, > > Teemu > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Sat Aug 7 15:36:27 2010 Return-Path: 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 108943A683E for ; Sat, 7 Aug 2010 15:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.136 X-Spam-Level: X-Spam-Status: No, score=-106.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 QKvL63p04nPi for ; Sat, 7 Aug 2010 15:36:26 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id A88963A67B2 for ; Sat, 7 Aug 2010 15:36:22 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTF3gBZYMdTIW6vWNWIpBpVfk12fLI+DH@postini.com; Sat, 07 Aug 2010 15:36:59 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F18AF1B8316; Sat, 7 Aug 2010 15:36:52 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 7 Aug 2010 15:36:52 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4C5DD6DD.8090607@gmail.com> Date: Sat, 7 Aug 2010 18:36:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1081) Cc: "Gabor.Bajko@nokia.com" , "mif@ietf.org" Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 22:36:27 -0000 On Aug 7, 2010, at 5:57 PM, Brian E Carpenter wrote: > Then it can be a local > policy issue whether you give priority to the interface choice or to = the > prefix choice. (Or to measured performance.) It can't be a matter of local policy, because there is no mechanism for = announcing that policy. It should not be the case that IPv4 is = preferred over IPv6, or that IPv6 is preferred over IPv4; rather, all = options should be tried, and the option that works best should be taken. From brian.e.carpenter@gmail.com Sat Aug 7 15:57:28 2010 Return-Path: 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 E94F63A688D for ; Sat, 7 Aug 2010 15:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3ExU+vxJ4Jxk for ; Sat, 7 Aug 2010 15:57:28 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 352A33A68C3 for ; Sat, 7 Aug 2010 15:57:28 -0700 (PDT) Received: by pvg7 with SMTP id 7so458293pvg.31 for ; Sat, 07 Aug 2010 15:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xNoUtRNjsFOAkEzNVHfBh0IRXrGsmejTCTTHsjBlZUw=; b=nIb9RNo5wSvJ8eqazY5GjxHrW1EvURTsNo7OmHulMXh0U/skCc7sHIa7p7wKtf9pLF 5Pm3XWMh6morqd7oM9G/leJr2vp9hgbAoNqkP06zHA73s/ZdsbRv/Crpy4MfpVkaCGML lGNVvDZnZJogME7Bw2hxRY0cTbeYPGzuM1Jms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=pmZRs9B8DebJq47+4m5IzOSkHXNcEERwOaQBCFBghvRCTXlZ/Iqi8Puri9KS9NEX8E Yz2I1CxHBS6urRy4XavS3z/87W4Ue9hT+0C5+Zcdu2Tyk6VwSRnPaK+cuWzjENF2j2Wx Lie6gBbcQv0qEzR4pTz9OVwWwmM49LWd/bQaA= Received: by 10.114.137.15 with SMTP id k15mr16080189wad.217.1281221880957; Sat, 07 Aug 2010 15:58:00 -0700 (PDT) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id n32sm6312356wag.11.2010.08.07.15.57.57 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Aug 2010 15:58:00 -0700 (PDT) Message-ID: <4C5DE4F2.7090608@gmail.com> Date: Sun, 08 Aug 2010 10:57:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Gabor.Bajko@nokia.com" , "mif@ietf.org" Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 22:57:29 -0000 On 2010-08-08 10:36, Ted Lemon wrote: > On Aug 7, 2010, at 5:57 PM, Brian E Carpenter wrote: >> Then it can be a local >> policy issue whether you give priority to the interface choice or to the >> prefix choice. (Or to measured performance.) > > It can't be a matter of local policy, because there is no mechanism for announcing that policy. There's very likely to be a defined mechanism for announcing local RFC3484(bis) policy. There's nothing to prevent such a mechanism also defining interface preferences. > It should not be the case that IPv4 is preferred over IPv6, or that IPv6 is preferred over IPv4; rather, all options should be tried, and the option that works best should be taken. That's a matter of opinion. There might well be a management decision to have a policy, or there might be a cost-based policy. All other things being equal, a REAP-like process to choose the best performance would be OK too. I don't think it's for the IETF to decide which approach suits the world best. Brian From Ted.Lemon@nominum.com Sat Aug 7 20:01:55 2010 Return-Path: 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 DFFE33A6782 for ; Sat, 7 Aug 2010 20:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.151 X-Spam-Level: X-Spam-Status: No, score=-106.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 U-PBkHFjFaO4 for ; Sat, 7 Aug 2010 20:01:55 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 1CB373A67ED for ; Sat, 7 Aug 2010 20:01:52 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTF4eP2CrYauGd1Vegl5TNF+1CecIPUg8@postini.com; Sat, 07 Aug 2010 20:02:28 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5D3461B827F; Sat, 7 Aug 2010 20:02:23 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 7 Aug 2010 20:02:22 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4C5DE4F2.7090608@gmail.com> Date: Sat, 7 Aug 2010 23:02:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> <4C5DE4F2.7090608@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1081) Cc: "Gabor.Bajko@nokia.com" , "mif@ietf.org" Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 03:01:56 -0000 On Aug 7, 2010, at 6:57 PM, Brian E Carpenter wrote: > There's nothing to prevent such a mechanism also > defining interface preferences. Yes, there is. Presumably, if there is some difference between the = interfaces, it will be because each interface is connected to a network = managed by a different entity. Thus, there is no reasonable basis for = assuming that what either entity defines as a policy is in fact valid = for the node. From brian.e.carpenter@gmail.com Sat Aug 7 21:56:27 2010 Return-Path: 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 7C3BF3A68BB for ; Sat, 7 Aug 2010 21:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hc2iWkgGT8AG for ; Sat, 7 Aug 2010 21:56:26 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 802AE3A67B8 for ; Sat, 7 Aug 2010 21:56:26 -0700 (PDT) Received: by pwj2 with SMTP id 2so1162072pwj.31 for ; Sat, 07 Aug 2010 21:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/i4HmoAwCop4XUbMURJSNIlkFSmomjPFP7HuNRJ6bP4=; b=dTWbrgjvRHGx11QL0tErTOK1Y+FznsR24zHfRtaSInWPLlaXqNQhhO/F7KwkXZVskY tW7v+2v7DwRK7e0mBLo13/6UWcPvOBiGfDjFCf/KWYjamsoXDuremdk7Ccdg7KhB+1QR tMutzuD05KEI+sT6W7gBZRg0hJSOThvUjhr2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=pHHIFit0Xi/Ays6RFx+pXQqZkAqPf6xxi+vq4GT8GqS1CvBHEaIclsxFRdvtMJKHd3 mqrhNFveSxngpANx0I7+X+D8wUwPFLaVe4n07DVcQZ3Wih8JRv9hAbe/2Ct3Y8Wcr1S7 J5mxAPRpcje7zDnm6FWMANqylIsqCY7XYkyvE= Received: by 10.114.26.20 with SMTP id 20mr16449955waz.222.1281243419526; Sat, 07 Aug 2010 21:56:59 -0700 (PDT) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id 33sm6990007wad.6.2010.08.07.21.56.55 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Aug 2010 21:56:58 -0700 (PDT) Message-ID: <4C5E3918.5080104@gmail.com> Date: Sun, 08 Aug 2010 16:56:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> <4C5DE4F2.7090608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Gabor.Bajko@nokia.com" , "mif@ietf.org" Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 04:56:27 -0000 On 2010-08-08 15:02, Ted Lemon wrote: > On Aug 7, 2010, at 6:57 PM, Brian E Carpenter wrote: >> There's nothing to prevent such a mechanism also >> defining interface preferences. > > Yes, there is. Presumably, if there is some difference between the interfaces, it will be because each interface is connected to a network managed by a different entity. Thus, there is no reasonable basis for assuming that what either entity defines as a policy is in fact valid for the node. That could well be, in which case the host's own policy should predominate. I guess my point is that we don't know the deployment scenario, so we need mechanisms that can be applied in a wide range of scenarios, not just yours or mine. Brian From teemu.savolainen@nokia.com Sun Aug 8 00:47:09 2010 Return-Path: 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 D80753A6768 for ; Sun, 8 Aug 2010 00:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Q1Q+5Pa+VaeN for ; Sun, 8 Aug 2010 00:47:08 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9E3833A6819 for ; Sun, 8 Aug 2010 00:47:06 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o787lWw7031998; Sun, 8 Aug 2010 10:47:36 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Aug 2010 10:47:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Aug 2010 10:47:27 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Sun, 8 Aug 2010 09:47:27 +0200 From: To: , Date: Sun, 8 Aug 2010 09:48:08 +0200 Thread-Topic: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? Thread-Index: Acs2zfH0rs33v/JYQdqby2821MAXDA== Message-ID: <1281253688.6185.11.camel@Nokia-N900> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1281253688618511camelNokiaN900_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2010 07:47:27.0920 (UTC) FILETIME=[F2C23300:01CB36CD] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: teemu.savolainen@nokia.com List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 07:47:10 -0000 --_000_1281253688618511camelNokiaN900_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBzY2VuYXJpbyBJIGhhdmUgaW4gbXkgbWluZCBpcyBmb2xsb3dpbmcuDQoNClRo ZSBjdXJyZW50IHZlcnkgY29tbW9uIHByYWN0aWNlIGlzIHRoYXQgc2luZ2xlIGhvbWVkIG1vYmls ZSBwaG9uZXMgc2VsZWN0IFdMQU4gb3ZlciBjZWxsdWxhciBpZiBib3RoIGtpbmRzIG9mIG5ldHdv cmtzIGFyZSByZWFjaGFibGUuDQoNCk5vdyBpZiB0aGUgbW9iaWxlIHBob25lIGJlY29tZXMgbXVs dGlob21lZCwgaXQgd2lsbCBkeW5hbWljYWxseSBjaG9vc2UgZm9yIGVhY2ggdHJhbnNwb3J0IHNl c3Npb24gd2hpY2ggaW50ZXJmYWNlIHRvIHVzZSAoYXNzdW1pbmcgYm90aCBhcmUgImRlZmF1bHQi KS4NCg0KSWYgdGhlIGNlbGx1bGFyIG9wZXJhdG9yIGlzIHF1aWNrZXIgdG8gZGVwbG95IElQdjYg dGhhbiBXTEFOIG9wZXJhdG9yLCBpdCBtaWdodCBiZWNvbWUgYSBwcm9ibGVtIHRoYXQgaG9zdCBm YXZvcnMgY2VsbHVsYXIgaW50ZXJmYWNlIHRvbyBtdWNoOiBmcm9tIGNlbGx1bGFyIG9wZXJhdG9y IGFuZCBtYXliZSBmcm9tIHVzZXIgcG9pbnQgb2YgdmlldyBhcyB3ZWxsICh0aGlzIHJlbGF0ZXMg dG8gInRyYWZmaWMgb2ZmbG9hZGluZyIpLiBUaGlzIG1heSBiZSBldmVuIGV4YWdnZXJhdGVkIGJ5 IE5BVDY0IGluIElQdjYtb25seSBjZWxsdWxhciBhY2Nlc3MgbWFraW5nIGFsbCBJUHY0IGludGVy bmV0IGxvb2sgbGlrZSBiZWluZyByZWFjaGFibGUgb3ZlciBJUHY2IChidXQgZm9yIHRoaXMgY2Fz ZSB3ZSBhcmUgYWxzbyB3b3JraW5nIGluIGJlaGF2ZSB0byBlbmFibGUgaG9zdCBkZXRlY3QgTkFU NjQgYW5kIGRvd25wcmlvcml0aXplIElQdjYgYWRkcmVzc2VzIHdpdGggSVNQIE5BVDY0IHByZWZp eCkuDQoNCkhlbmNlIGluIHN1Y2ggc2NlcmlvcyAtIGZvciBvcGVyYXRpb25hbCBhbmQgY29zdCBy ZWFzb25zIC0gd2UgdGhpbmsgdGhlcmUgbWlnaHQgYmUgbmVlZCBmb3IgaG9zdHMgdG8gcHJlZmVy IElQdjQgb3ZlciBJUHY2IGZvciAiYnVsayB0cmFmZmljIiAod2hlbiBhcHBsaWNhdGlvbiBkb2Vz IG5vdCBjYXJlIC0gb2YgY291cnNlIGFsd2F5cyBvbiBhcHBzLCBsaXN0ZW5lcnMsIFAyUCBldGMg bWF5IHByZWZlciBJUHY2IHN0aWxsKS4NCg0KQmVzdCByZWdhcmRzLA0KDQpUZWVtdQ0KDQotLS0t LSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tDQo+IE9uIDIwMTAtMDgtMDggMTU6MDIsIFRlZCBMZW1v biB3cm90ZToNCj4gPiBPbiBBdWcgNywgMjAxMCwgYXQgNjo1NyBQTSwgQnJpYW4gRSBDYXJwZW50 ZXIgd3JvdGU6DQo+ID4gPiBUaGVyZSdzIG5vdGhpbmcgdG8gcHJldmVudCBzdWNoIGEgbWVjaGFu aXNtIGFsc28NCj4gPiA+IGRlZmluaW5nIGludGVyZmFjZSBwcmVmZXJlbmNlcy4NCj4gPg0KPiA+ IFllcywgdGhlcmUgaXMuICAgIFByZXN1bWFibHksIGlmIHRoZXJlIGlzIHNvbWUgZGlmZmVyZW5j ZSBiZXR3ZWVuIHRoZQ0KPiBpbnRlcmZhY2VzLCBpdCB3aWxsIGJlIGJlY2F1c2UgZWFjaCBpbnRl cmZhY2UgaXMgY29ubmVjdGVkIHRvIGEgbmV0d29yaw0KPiBtYW5hZ2VkIGJ5IGEgZGlmZmVyZW50 IGVudGl0eS4gICAgVGh1cywgdGhlcmUgaXMgbm8gcmVhc29uYWJsZSBiYXNpcyBmb3INCj4gYXNz dW1pbmcgdGhhdCB3aGF0IGVpdGhlciBlbnRpdHkgZGVmaW5lcyBhcyBhIHBvbGljeSBpcyBpbiBm YWN0IHZhbGlkDQo+IGZvciB0aGUgbm9kZS4NCj4NCj4gVGhhdCBjb3VsZCB3ZWxsIGJlLCBpbiB3 aGljaCBjYXNlIHRoZSBob3N0J3Mgb3duIHBvbGljeSBzaG91bGQNCj4gcHJlZG9taW5hdGUuDQo+ IEkgZ3Vlc3MgbXkgcG9pbnQgaXMgdGhhdCB3ZSBkb24ndCBrbm93IHRoZSBkZXBsb3ltZW50IHNj ZW5hcmlvLCBzbyB3ZQ0KPiBuZWVkDQo+IG1lY2hhbmlzbXMgdGhhdCBjYW4gYmUgYXBwbGllZCBp biBhIHdpZGUgcmFuZ2Ugb2Ygc2NlbmFyaW9zLCBub3QganVzdA0KPiB5b3Vycw0KPiBvciBtaW5l Lg0KPg0KPiAgICAgIEJyaWFuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG1pZiBtYWlsaW5nIGxpc3QNCj4gbWlmQGlldGYub3JnPG1haWx0bzpt aWZAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlm DQo+DQoNCg== --_000_1281253688618511camelNokiaN900_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbD48aGVh ZD4NCiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD11dGYtOCI+DQogICAgPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJP c3NvIE5vdGVzIj4NCiAgICA8dGl0bGU+PC90aXRsZT48L2hlYWQ+DQo8Ym9keT4NCjxwPkhpLA0K PGJyPg0KPGJyPlRoZSBzY2VuYXJpbyBJIGhhdmUgaW4gbXkgbWluZCBpcyBmb2xsb3dpbmcuDQo8 YnI+DQo8YnI+VGhlIGN1cnJlbnQgdmVyeSBjb21tb24gcHJhY3RpY2UgaXMgdGhhdCBzaW5nbGUg aG9tZWQgbW9iaWxlIHBob25lcyBzZWxlY3QgV0xBTiBvdmVyIGNlbGx1bGFyIGlmIGJvdGgga2lu ZHMgb2YgbmV0d29ya3MgYXJlIHJlYWNoYWJsZS4gDQo8YnI+DQo8YnI+Tm93IGlmIHRoZSBtb2Jp bGUgcGhvbmUgYmVjb21lcyBtdWx0aWhvbWVkLCBpdCB3aWxsIGR5bmFtaWNhbGx5IGNob29zZSBm b3IgZWFjaCB0cmFuc3BvcnQgc2Vzc2lvbiB3aGljaCBpbnRlcmZhY2UgdG8gdXNlIChhc3N1bWlu ZyBib3RoIGFyZSAiZGVmYXVsdCIpLg0KPGJyPg0KPGJyPklmIHRoZSBjZWxsdWxhciBvcGVyYXRv ciBpcyBxdWlja2VyIHRvIGRlcGxveSBJUHY2IHRoYW4gV0xBTiBvcGVyYXRvciwgaXQgbWlnaHQg YmVjb21lIGEgcHJvYmxlbSB0aGF0IGhvc3QgZmF2b3JzIGNlbGx1bGFyIGludGVyZmFjZSB0b28g bXVjaDogZnJvbSBjZWxsdWxhciBvcGVyYXRvciBhbmQgbWF5YmUgZnJvbSB1c2VyIHBvaW50IG9m IHZpZXcgYXMgd2VsbCAodGhpcyByZWxhdGVzIHRvICJ0cmFmZmljIG9mZmxvYWRpbmciKS4gVGhp cyBtYXkgYmUgZXZlbiBleGFnZ2VyYXRlZCBieSBOQVQ2NCBpbiBJUHY2LW9ubHkgY2VsbHVsYXIg YWNjZXNzIG1ha2luZyBhbGwgSVB2NCBpbnRlcm5ldCBsb29rIGxpa2UgYmVpbmcgcmVhY2hhYmxl IG92ZXIgSVB2NiAoYnV0IGZvciB0aGlzIGNhc2Ugd2UgYXJlIGFsc28gd29ya2luZyBpbiBiZWhh dmUgdG8gZW5hYmxlIGhvc3QgZGV0ZWN0IE5BVDY0IGFuZCBkb3ducHJpb3JpdGl6ZSBJUHY2IGFk ZHJlc3NlcyB3aXRoIElTUCBOQVQ2NCBwcmVmaXgpLg0KPGJyPg0KPGJyPkhlbmNlIGluIHN1Y2gg c2NlcmlvcyAtIGZvciBvcGVyYXRpb25hbCBhbmQgY29zdCByZWFzb25zIC0gd2UgdGhpbmsgdGhl cmUgbWlnaHQgYmUgbmVlZCBmb3IgaG9zdHMgdG8gcHJlZmVyIElQdjQgb3ZlciBJUHY2IGZvciAi YnVsayB0cmFmZmljIiAod2hlbiBhcHBsaWNhdGlvbiBkb2VzIG5vdCBjYXJlIC0gb2YgY291cnNl IGFsd2F5cyBvbiBhcHBzLCBsaXN0ZW5lcnMsIFAyUCBldGMgbWF5IHByZWZlciBJUHY2IHN0aWxs KS4NCjxicj4NCjxicj5CZXN0IHJlZ2FyZHMsDQo8YnI+DQo8YnI+VGVlbXUgDQo8YnI+DQo8YnI+ LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLQ0KPGJyPiZndDsgT24gMjAxMC0wOC0wOCAxNTow MiwgVGVkIExlbW9uIHdyb3RlOg0KPGJyPiZndDsgJmd0OyBPbiBBdWcgNywgMjAxMCwgYXQgNjo1 NyBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo8YnI+Jmd0OyAmZ3Q7ICZndDsgVGhlcmUn cyBub3RoaW5nIHRvIHByZXZlbnQgc3VjaCBhIG1lY2hhbmlzbSBhbHNvDQo8YnI+Jmd0OyAmZ3Q7 ICZndDsgZGVmaW5pbmcgaW50ZXJmYWNlIHByZWZlcmVuY2VzLg0KPGJyPiZndDsgJmd0OyANCjxi cj4mZ3Q7ICZndDsgWWVzLCB0aGVyZSBpcy4mbmJzcDsgJm5ic3A7ICYjMzI7UHJlc3VtYWJseSwg aWYgdGhlcmUgaXMgc29tZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlDQo8YnI+Jmd0OyBpbnRlcmZh Y2VzLCBpdCB3aWxsIGJlIGJlY2F1c2UgZWFjaCBpbnRlcmZhY2UgaXMgY29ubmVjdGVkIHRvIGEg bmV0d29yaw0KPGJyPiZndDsgbWFuYWdlZCBieSBhIGRpZmZlcmVudCBlbnRpdHkuJm5ic3A7ICZu YnNwOyAmIzMyO1RodXMsIHRoZXJlIGlzIG5vIHJlYXNvbmFibGUgYmFzaXMgZm9yDQo8YnI+Jmd0 OyBhc3N1bWluZyB0aGF0IHdoYXQgZWl0aGVyIGVudGl0eSBkZWZpbmVzIGFzIGEgcG9saWN5IGlz IGluIGZhY3QgdmFsaWQNCjxicj4mZ3Q7IGZvciB0aGUgbm9kZS4NCjxicj4mZ3Q7IA0KPGJyPiZn dDsgVGhhdCBjb3VsZCB3ZWxsIGJlLCBpbiB3aGljaCBjYXNlIHRoZSBob3N0J3Mgb3duIHBvbGlj eSBzaG91bGQNCjxicj4mZ3Q7IHByZWRvbWluYXRlLg0KPGJyPiZndDsgSSBndWVzcyBteSBwb2lu dCBpcyB0aGF0IHdlIGRvbid0IGtub3cgdGhlIGRlcGxveW1lbnQgc2NlbmFyaW8sIHNvIHdlDQo8 YnI+Jmd0OyBuZWVkDQo8YnI+Jmd0OyBtZWNoYW5pc21zIHRoYXQgY2FuIGJlIGFwcGxpZWQgaW4g YSB3aWRlIHJhbmdlIG9mIHNjZW5hcmlvcywgbm90IGp1c3QNCjxicj4mZ3Q7IHlvdXJzDQo8YnI+ Jmd0OyBvciBtaW5lLg0KPGJyPiZndDsgDQo8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICYj MzI7QnJpYW4NCjxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo8YnI+Jmd0OyBtaWYgbWFpbGluZyBsaXN0DQo8YnI+Jmd0OyA8YSBocmVmPSJt YWlsdG86bWlmQGlldGYub3JnIj5taWZAaWV0Zi5vcmc8L2E+DQo8YnI+Jmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8L2E+DQo8YnI+Jmd0OyANCjxicj48YnI+PC9wPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_1281253688618511camelNokiaN900_-- From zehn.cao@gmail.com Sun Aug 8 01:53:57 2010 Return-Path: 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 1598F3A67F8 for ; Sun, 8 Aug 2010 01:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 QeD9LFx8Y0uX for ; Sun, 8 Aug 2010 01:53:56 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9E86B3A6783 for ; Sun, 8 Aug 2010 01:53:55 -0700 (PDT) Received: by bwz10 with SMTP id 10so955172bwz.31 for ; Sun, 08 Aug 2010 01:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hScq0bvmwaECXcp5tv73jgPbOdNcgMGpmvfD0fuXoro=; b=d5xVqT6gSPa6wpgY3W8nV4JcbOr4ASNOOrcLY/ks8Fj9TRMb8mCIT5GR/7gzZ74Bae 3VmarI0gtdds8xaMpdtlcIPXka5vAoOv8IsixnjNgst/rR5WoJ4JF8fAQDLj9PPxRO5c 7YFJfQnJIjPo1BiKUW2tjOlWh9J2iTJ3WW3II= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SQ11AyzC9DuAQTeh59x40UaLCPhCsKCmksT/a9WNjwvM3qvu36OKcN9ODf0cYfqk7H 58SWGieHbrAWFAtc2DSc/p1XvSPuqlhT1ijiqQUbpJedElAw6zrg9fCodtRKMm+aPCOt 5dpbTEmq25fvCs+eg12MhrkDD9YO+PIcLCQPk= MIME-Version: 1.0 Received: by 10.204.82.130 with SMTP id b2mr1800844bkl.12.1281257667612; Sun, 08 Aug 2010 01:54:27 -0700 (PDT) Received: by 10.204.174.194 with HTTP; Sun, 8 Aug 2010 01:54:27 -0700 (PDT) In-Reply-To: <1281253688.6185.11.camel@Nokia-N900> References: <1281253688.6185.11.camel@Nokia-N900> Date: Sun, 8 Aug 2010 16:54:27 +0800 Message-ID: From: Zhen Cao To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gabor.Bajko@nokia.com, mif@ietf.org, Ted.Lemon@nominum.com Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 08:53:57 -0000 Hi This problem has been discussed in the list before, as http://www.ietf.org/mail-archive/web/mif/current/msg00700.html http://www.ietf.org/mail-archive/web/mif/current/msg00701.html Address selection of the current problem statement may have already covered this issue implicitly. -Zhen On Sun, Aug 8, 2010 at 3:48 PM, wrote: > Hi, > > The scenario I have in my mind is following. > > The current very common practice is that single homed mobile phones selec= t > WLAN over cellular if both kinds of networks are reachable. > > Now if the mobile phone becomes multihomed, it will dynamically choose fo= r > each transport session which interface to use (assuming both are "default= "). > > If the cellular operator is quicker to deploy IPv6 than WLAN operator, it > might become a problem that host favors cellular interface too much: from > cellular operator and maybe from user point of view as well (this relates= to > "traffic offloading"). This may be even exaggerated by NAT64 in IPv6-only > cellular access making all IPv4 internet look like being reachable over I= Pv6 > (but for this case we are also working in behave to enable host detect NA= T64 > and downprioritize IPv6 addresses with ISP NAT64 prefix). > > Hence in such scerios - for operational and cost reasons - we think there > might be need for hosts to prefer IPv4 over IPv6 for "bulk traffic" (when > application does not care - of course always on apps, listeners, P2P etc = may > prefer IPv6 still). > > Best regards, > > Teemu > > ----- Original message ----- >> On 2010-08-08 15:02, Ted Lemon wrote: >> > On Aug 7, 2010, at 6:57 PM, Brian E Carpenter wrote: >> > > There's nothing to prevent such a mechanism also >> > > defining interface preferences. >> > >> > Yes, there is.=A0 =A0 Presumably, if there is some difference between = the >> interfaces, it will be because each interface is connected to a network >> managed by a different entity.=A0 =A0 Thus, there is no reasonable basis= for >> assuming that what either entity defines as a policy is in fact valid >> for the node. >> >> That could well be, in which case the host's own policy should >> predominate. >> I guess my point is that we don't know the deployment scenario, so we >> need >> mechanisms that can be applied in a wide range of scenarios, not just >> yours >> or mine. >> >>=A0 =A0 =A0 Brian >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From scott.brim@gmail.com Sun Aug 8 05:25:36 2010 Return-Path: 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 EC1293A6944 for ; Sun, 8 Aug 2010 05:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 H8L+BH+vPWva for ; Sun, 8 Aug 2010 05:25:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 967083A6837 for ; Sun, 8 Aug 2010 05:25:35 -0700 (PDT) Received: by bwz10 with SMTP id 10so1010264bwz.31 for ; Sun, 08 Aug 2010 05:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=cCq+4WbFQziNrVsA4jXE7Wgq8dlZNApUEHn3qS4G/xo=; b=PQorgU/GhduECSUsv8Mv54TnCi2AQ/lY+gFV25SExSztS/0QjfljrLBL8Y0nYzS5c0 DvZTcKIgFSq0ACN6wx7B2AZPPsuFkyRFWDg0CNDW6QCIxjeLobJpc20PeVN0TPCbM097 YG1L+HHbJoWZFWcrrjsrgpXEDvsMoJ6E/d53o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rI8/W8RzTrrRsIZhWIgx+JhPREQd+zEsqoQRdfV1wyy7DtT1Mtl6cEWWDAdGVOI6Ye x5UwCn5Sj7vcYkG0eZIcuJ1F7mGMHQogtxgnuP+JE2NC73ee5HEYUbrhHr4XpJWF2qgu 6gVHovAREn52d+yJwoz6bs3E+ej+GK5WGDh28= MIME-Version: 1.0 Received: by 10.204.136.71 with SMTP id q7mr1942880bkt.111.1281270368027; Sun, 08 Aug 2010 05:26:08 -0700 (PDT) Received: by 10.204.19.199 with HTTP; Sun, 8 Aug 2010 05:26:06 -0700 (PDT) Received: by 10.204.19.199 with HTTP; Sun, 8 Aug 2010 05:26:06 -0700 (PDT) In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> Date: Sun, 8 Aug 2010 08:26:06 -0400 Message-ID: From: Scott W Brim To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=0015174befdc25c6b3048d4f01fc Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 12:25:37 -0000 --0015174befdc25c6b3048d4f01fc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I see three different factors: The multihomed device may need to blend policy from multiple networks. We do want to support cases within a single administration but an endpoint mus= t be able to handle connectivity to arbitrary unexpected networks as well. MIF covers this well. Modulo policy the device needs to test actual connectivity. The "happy eyeballs" approach seems most effective. Connectivity doesn't mean actual goodput, and the only way to test the usefulness of a path, which changes over time, is with real data. Of the possibilities I would recommend SCTP CMT (or perhaps multipath TCP). It wil= l soon be turned on by default in FreeBSD. If we know we have the second and third, that allows us to look at the firs= t with a different prrspective. I'm away from any decent Internet access but I'll join in a more thorough discussion in a few days. Scott On Aug 7, 2010 9:26 AM, wrote: Mif, Currently hosts generally prefer IPv6 over IPv4 communications. However, a multi-homed host may have IPv6 available only on a less preferred interface= . For example, host=92s destination may be reachable over both IPv4 and IPv6, but the host has an IPv6-only cellular (maybe less preferred) and IPv4-only local WLAN interfaces (maybe more preferred). Do you think in such a case a MIF host should actually prefer IPv4 communications instead of IPv6? Current single homed hosts would probably have chosen to use WLAN for all communications anyway. Do you think this preference should be part of a distributed policy, or something the host just should make its own mind about? Best regards, Teemu _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --0015174befdc25c6b3048d4f01fc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I see three different factors:

The multihomed device may need to blend policy from multiple networks.= =A0 We do want to support cases within a single administration but an endpo= int must be able to handle connectivity to arbitrary unexpected networks as= well.=A0 MIF covers this well.

Modulo policy the device needs to test actual connectivity. The "ha= ppy eyeballs" approach seems most effective.

Connectivity doesn't mean actual goodput, and the only way to test t= he usefulness of a path, which changes over time,=A0 is with real data. Of = the possibilities I would recommend SCTP CMT (or perhaps multipath TCP). It= will soon be turned on by default in FreeBSD.

If we know we have the second and third, that allows us to look at the f= irst with a different prrspective.

I'm away from any decent Internet access but I'll join in a more= thorough discussion in a few days.

Scott

On Aug 7, 2010 9:26 AM, <teemu.savolainen@nokia.com> wrote:
<= br>

Mif,

=A0

Currently hosts generally prefer IPv6 over IPv4 communications. However, a multi-homed host may have IPv6 available only on= a less preferred interface. For example, host=92s destination may be reachable over both IPv4 and IPv6, but the host has an IPv6-only cellular (= maybe less preferred) and IPv4-only local WLAN interfaces (maybe more preferred).=

=A0

Do you think in such a case a MIF host should actual= ly prefer IPv4 communications instead of IPv6? Current single homed hosts woul= d probably have chosen to use WLAN for all communications anyway.

=A0

Do you think this preference should be part of a dis= tributed policy, or something the host just should make its own mind about?

=A0

Best regards,

=A0

Teemu

=A0

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--0015174befdc25c6b3048d4f01fc-- From Ted.Lemon@nominum.com Sun Aug 8 06:47:52 2010 Return-Path: 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 09A643A6914 for ; Sun, 8 Aug 2010 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xWSbftrp-sP3 for ; Sun, 8 Aug 2010 06:47:50 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 9CE233A686B for ; Sun, 8 Aug 2010 06:47:46 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTF61olgUfCgmQJSq2VZJYnYxgoisuAwL@postini.com; Sun, 08 Aug 2010 06:48:24 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3DA361B82C1; Sun, 8 Aug 2010 06:48:18 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 8 Aug 2010 06:48:18 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <1281253688.6185.11.camel@Nokia-N900> Date: Sun, 8 Aug 2010 09:48:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <01DFBF5E-610B-4BA9-8634-6223CA5ECBE7@nominum.com> References: <1281253688.6185.11.camel@Nokia-N900> To: "teemu.savolainen@nokia.com" X-Mailer: Apple Mail (2.1081) Cc: "Gabor.Bajko@nokia.com" , "mif@ietf.org" Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 13:47:52 -0000 On Aug 8, 2010, at 3:48 AM, wrote: > If the cellular operator is quicker to deploy IPv6 than WLAN operator, = it might become a problem that host favors cellular interface too much: = from cellular operator and maybe from user point of view as well (this = relates to "traffic offloading"). This may be even exaggerated by NAT64 = in IPv6-only cellular access making all IPv4 internet look like being = reachable over IPv6 (but for this case we are also working in behave to = enable host detect NAT64 and downprioritize IPv6 addresses with ISP = NAT64 prefix).=20 >=20 > Hence in such scerios - for operational and cost reasons - we think = there might be need for hosts to prefer IPv4 over IPv6 for "bulk = traffic" (when application does not care - of course always on apps, = listeners, P2P etc may prefer IPv6 still).=20 But in this scenario, what you really want is for the host to prefer the = one interface over the other. The fact that you need it to prefer IPv4 = over IPv6 is immaterial--if the situation were reversed, and the WLAN = operator were providing IPv6 only, while the mobile operator were only = providing IPv4, you would want it to prefer IPv6. So it doesn't really make sense to talk about this in terms of IPv6 or = IPv4--what you want is to be able to prefer one interface over the = other. From Gabor.Bajko@nokia.com Sun Aug 8 09:57:11 2010 Return-Path: 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 7660D3A67F0 for ; Sun, 8 Aug 2010 09:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vzuBS3vHMV5P for ; Sun, 8 Aug 2010 09:57:10 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BA7D23A67EF for ; Sun, 8 Aug 2010 09:57:09 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o78GvaTU000795; Sun, 8 Aug 2010 19:57:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Aug 2010 19:57:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Aug 2010 19:57:33 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Sun, 8 Aug 2010 18:57:33 +0200 From: To: , Date: Sun, 8 Aug 2010 18:57:28 +0200 Thread-Topic: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? Thread-Index: Acs3AGDiUPkYcyc9TbCDA4/DvyioNAAGI8gg Message-ID: References: <1281253688.6185.11.camel@Nokia-N900> <01DFBF5E-610B-4BA9-8634-6223CA5ECBE7@nominum.com> In-Reply-To: <01DFBF5E-610B-4BA9-8634-6223CA5ECBE7@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2010 16:57:33.0951 (UTC) FILETIME=[CBE2D8F0:01CB371A] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 16:57:11 -0000 What I want is to prefer interface A and IPv6. Now, if interface A does not= support IPv6, the device either has to choose a different interface or cho= ose to use IPv4.=20 If I stick to the interface and use IPv4, my apps may lose end-to-end conne= ctivity. If I stick to IPv6 and interface B, I may end up with lower available bandw= idth and higher costs. In a device which can have both interfaces on simultaneously (not practical= because of battery consumption), the apps may choose depending on the cost= /connectivity factor, but in devices with only one interface active, some a= pps will suffer. - gabor -----Original Message----- From: ext Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Sunday, August 08, 2010 6:48 AM To: Savolainen Teemu (Nokia-MS/Tampere) Cc: brian.e.carpenter@gmail.com; Bajko Gabor (Nokia-CIC/MtView); mif@ietf.o= rg Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem= to be covered? On Aug 8, 2010, at 3:48 AM, wrote: > If the cellular operator is quicker to deploy IPv6 than WLAN operator, it= might become a problem that host favors cellular interface too much: from = cellular operator and maybe from user point of view as well (this relates t= o "traffic offloading"). This may be even exaggerated by NAT64 in IPv6-only= cellular access making all IPv4 internet look like being reachable over IP= v6 (but for this case we are also working in behave to enable host detect N= AT64 and downprioritize IPv6 addresses with ISP NAT64 prefix).=20 >=20 > Hence in such scerios - for operational and cost reasons - we think there= might be need for hosts to prefer IPv4 over IPv6 for "bulk traffic" (when = application does not care - of course always on apps, listeners, P2P etc ma= y prefer IPv6 still).=20 But in this scenario, what you really want is for the host to prefer the on= e interface over the other. The fact that you need it to prefer IPv4 over= IPv6 is immaterial--if the situation were reversed, and the WLAN operator = were providing IPv6 only, while the mobile operator were only providing IPv= 4, you would want it to prefer IPv6. So it doesn't really make sense to talk about this in terms of IPv6 or IPv4= --what you want is to be able to prefer one interface over the other. From teemu.savolainen@nokia.com Sun Aug 8 11:59:47 2010 Return-Path: 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 A628A3A696F for ; Sun, 8 Aug 2010 11:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 OLxj2A0aK3nP for ; Sun, 8 Aug 2010 11:59:46 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7FD523A67B1 for ; Sun, 8 Aug 2010 11:59:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o78J0D4r008743; Sun, 8 Aug 2010 22:00:14 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Aug 2010 22:00:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Aug 2010 22:00:08 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Sun, 8 Aug 2010 21:00:08 +0200 From: To: Date: Sun, 8 Aug 2010 21:00:48 +0200 Thread-Topic: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? Thread-Index: Acs3K+sxfVfROzazRJeGPSf2mbBAFQ== Message-ID: <1281294048.1968.6.camel@Nokia-N900> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_128129404819686camelNokiaN900_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2010 19:00:08.0734 (UTC) FILETIME=[EBADABE0:01CB372B] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com, mif@ietf.org, Ted.Lemon@nominum.com Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: teemu.savolainen@nokia.com List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 18:59:47 -0000 --_000_128129404819686camelNokiaN900_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcyBmb3IgdGhlIHBvaW50ZXJzIChJIGhhZCBtaXNzZWQgdGhhdCBkaXNjdXNz aW9uIGZvciBzb21lIHJlYXNvbikuIEkgdGhpbmsgSSBhZ3JlZSB3aXRoIHlvdSBaaGVuIHRoYXQg dGhpcyBjYXNlIGlzIG5vdCBjb3ZlcmVkIGluIFJGQzM0ODQuLiBJLmUuIEhvc3Qgd2l0aCBkdWFs LXN0YWNrIGludGVyZmFjZSAoYm90aCBwdWJsaWMgYWRkcikgc2hvdWxkIHVzdWFsbHkgcHJlZmVy IElQdjYuIEhvc3Qgd2l0aCBvbmUgSVB2NCBpbnRlcmZhY2UgYW5kIG9uZSBJUHY2IGludGVyZmFj ZSBtYXkgb3IgbWF5IG5vdCB3YW50IHRvIHByZWZlciBJUHY2LCBkZXBlbmRpbmcgb24gdGhlIHNj ZW5hcmlvIGF0IGhhbmQuDQoNClRoZSBwcm9ibGVtIHN0YXRlbWVudCdzIHNlY3Rpb24gNC4yIGJ1 bGxldCAyIGNvbWVzIHJlYWxseSBjbG9zZSB0byB0aGlzLCBidXQgY291bGQgY2xhcmlmeSAoYWRk KSB0aGUgY2FzZSB3aGVyZSBkZXN0aW5hdGlvbiBpcyBkdWFsLXN0YWNrIHJlYWNoYWJsZSBidXQg d2l0aCBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzIChlLmcuIENvc3RzKSBmb3IgZGlmZmVyZW50 IEFGcy4NCg0KQmVzdCByZWdhcmRzLA0KDQpUZWVtdQ0KDQotLS0tLSBPcmlnaW5hbCBtZXNzYWdl IC0tLS0tDQo+IEhpDQo+DQo+IFRoaXMgcHJvYmxlbSBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gdGhl IGxpc3QgYmVmb3JlLCBhcw0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bWlmL2N1cnJlbnQvbXNnMDA3MDAuaHRtbA0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDA3MDEuaHRtbA0KPg0KPiBBZGRyZXNzIHNlbGVjdGlv biBvZiB0aGUgY3VycmVudCBwcm9ibGVtIHN0YXRlbWVudCBtYXkgaGF2ZSBhbHJlYWR5DQo+IGNv dmVyZWQgdGhpcyBpc3N1ZSBpbXBsaWNpdGx5Lg0KPg0KPiAtWmhlbg0KPg0KPiBPbiBTdW4sIEF1 ZyA4LCAyMDEwIGF0IDM6NDggUE0sICA8dGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb208bWFpbHRv OnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tPj4gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBU aGUgc2NlbmFyaW8gSSBoYXZlIGluIG15IG1pbmQgaXMgZm9sbG93aW5nLg0KPiA+DQo+ID4gVGhl IGN1cnJlbnQgdmVyeSBjb21tb24gcHJhY3RpY2UgaXMgdGhhdCBzaW5nbGUgaG9tZWQgbW9iaWxl IHBob25lcw0KPiBzZWxlY3QNCj4gPiBXTEFOIG92ZXIgY2VsbHVsYXIgaWYgYm90aCBraW5kcyBv ZiBuZXR3b3JrcyBhcmUgcmVhY2hhYmxlLg0KPiA+DQo+ID4gTm93IGlmIHRoZSBtb2JpbGUgcGhv bmUgYmVjb21lcyBtdWx0aWhvbWVkLCBpdCB3aWxsIGR5bmFtaWNhbGx5IGNob29zZQ0KPiBmb3IN Cj4gPiBlYWNoIHRyYW5zcG9ydCBzZXNzaW9uIHdoaWNoIGludGVyZmFjZSB0byB1c2UgKGFzc3Vt aW5nIGJvdGggYXJlDQo+ICJkZWZhdWx0IikuDQo+ID4NCj4gPiBJZiB0aGUgY2VsbHVsYXIgb3Bl cmF0b3IgaXMgcXVpY2tlciB0byBkZXBsb3kgSVB2NiB0aGFuIFdMQU4gb3BlcmF0b3IsDQo+IGl0 DQo+ID4gbWlnaHQgYmVjb21lIGEgcHJvYmxlbSB0aGF0IGhvc3QgZmF2b3JzIGNlbGx1bGFyIGlu dGVyZmFjZSB0b28gbXVjaDoNCj4gZnJvbQ0KPiA+IGNlbGx1bGFyIG9wZXJhdG9yIGFuZCBtYXli ZSBmcm9tIHVzZXIgcG9pbnQgb2YgdmlldyBhcyB3ZWxsICh0aGlzDQo+IHJlbGF0ZXMgdG8NCj4g PiAidHJhZmZpYyBvZmZsb2FkaW5nIikuIFRoaXMgbWF5IGJlIGV2ZW4gZXhhZ2dlcmF0ZWQgYnkg TkFUNjQgaW4NCj4gSVB2Ni1vbmx5DQo+ID4gY2VsbHVsYXIgYWNjZXNzIG1ha2luZyBhbGwgSVB2 NCBpbnRlcm5ldCBsb29rIGxpa2UgYmVpbmcgcmVhY2hhYmxlDQo+IG92ZXIgSVB2Ng0KPiA+IChi dXQgZm9yIHRoaXMgY2FzZSB3ZSBhcmUgYWxzbyB3b3JraW5nIGluIGJlaGF2ZSB0byBlbmFibGUg aG9zdCBkZXRlY3QNCj4gTkFUNjQNCj4gPiBhbmQgZG93bnByaW9yaXRpemUgSVB2NiBhZGRyZXNz ZXMgd2l0aCBJU1AgTkFUNjQgcHJlZml4KS4NCj4gPg0KPiA+IEhlbmNlIGluIHN1Y2ggc2Nlcmlv cyAtIGZvciBvcGVyYXRpb25hbCBhbmQgY29zdCByZWFzb25zIC0gd2UgdGhpbmsNCj4gdGhlcmUN Cj4gPiBtaWdodCBiZSBuZWVkIGZvciBob3N0cyB0byBwcmVmZXIgSVB2NCBvdmVyIElQdjYgZm9y ICJidWxrDQo+IHRyYWZmaWMiICh3aGVuDQo+ID4gYXBwbGljYXRpb24gZG9lcyBub3QgY2FyZSAt IG9mIGNvdXJzZSBhbHdheXMgb24gYXBwcywgbGlzdGVuZXJzLCBQMlANCj4gZXRjIG1heQ0KPiA+ IHByZWZlciBJUHY2IHN0aWxsKS4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPg0KPiA+IFRl ZW11DQo+ID4NCj4gPiAtLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tDQo+ID4gPiBPbiAyMDEw LTA4LTA4IDE1OjAyLCBUZWQgTGVtb24gd3JvdGU6DQo+ID4gPiA+IE9uIEF1ZyA3LCAyMDEwLCBh dCA2OjU3IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gPiA+ID4gPiBUaGVyZSdzIG5v dGhpbmcgdG8gcHJldmVudCBzdWNoIGEgbWVjaGFuaXNtIGFsc28NCj4gPiA+ID4gPiBkZWZpbmlu ZyBpbnRlcmZhY2UgcHJlZmVyZW5jZXMuDQo+ID4gPiA+DQo+ID4gPiA+IFllcywgdGhlcmUgaXMu ICAgICAgUHJlc3VtYWJseSwgaWYgdGhlcmUgaXMgc29tZSBkaWZmZXJlbmNlIGJldHdlZW4NCj4g dGhlDQo+ID4gPiBpbnRlcmZhY2VzLCBpdCB3aWxsIGJlIGJlY2F1c2UgZWFjaCBpbnRlcmZhY2Ug aXMgY29ubmVjdGVkIHRvIGENCj4gbmV0d29yaw0KPiA+ID4gbWFuYWdlZCBieSBhIGRpZmZlcmVu dCBlbnRpdHkuICAgICAgVGh1cywgdGhlcmUgaXMgbm8gcmVhc29uYWJsZSBiYXNpcw0KPiBmb3IN Cj4gPiA+IGFzc3VtaW5nIHRoYXQgd2hhdCBlaXRoZXIgZW50aXR5IGRlZmluZXMgYXMgYSBwb2xp Y3kgaXMgaW4gZmFjdCB2YWxpZA0KPiA+ID4gZm9yIHRoZSBub2RlLg0KPiA+ID4NCj4gPiA+IFRo YXQgY291bGQgd2VsbCBiZSwgaW4gd2hpY2ggY2FzZSB0aGUgaG9zdCdzIG93biBwb2xpY3kgc2hv dWxkDQo+ID4gPiBwcmVkb21pbmF0ZS4NCj4gPiA+IEkgZ3Vlc3MgbXkgcG9pbnQgaXMgdGhhdCB3 ZSBkb24ndCBrbm93IHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvLCBzbyB3ZQ0KPiA+ID4gbmVlZA0K PiA+ID4gbWVjaGFuaXNtcyB0aGF0IGNhbiBiZSBhcHBsaWVkIGluIGEgd2lkZSByYW5nZSBvZiBz Y2VuYXJpb3MsIG5vdCBqdXN0DQo+ID4gPiB5b3Vycw0KPiA+ID4gb3IgbWluZS4NCj4gPiA+DQo+ ID4gPiBCcmlhbg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+IG1pZiBtYWlsaW5nIGxpc3QNCj4gPiA+IG1pZkBpZXRmLm9yZzxtYWls dG86bWlmQGlldGYub3JnPg0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9taWYNCj4gPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gbWlmIG1haWxpbmcgbGlzdA0KPiA+IG1pZkBpZXRm Lm9yZzxtYWlsdG86bWlmQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWlmDQo+ID4NCj4gPg0KPg0KDQo= --_000_128129404819686camelNokiaN900_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbD48aGVh ZD4NCiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD11dGYtOCI+DQogICAgPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJP c3NvIE5vdGVzIj4NCiAgICA8dGl0bGU+PC90aXRsZT48L2hlYWQ+DQo8Ym9keT4NCjxwPkhpLA0K PGJyPg0KPGJyPlRoYW5rcyBmb3IgdGhlIHBvaW50ZXJzIChJIGhhZCBtaXNzZWQgdGhhdCBkaXNj dXNzaW9uIGZvciBzb21lIHJlYXNvbikuIEkgdGhpbmsgSSBhZ3JlZSB3aXRoIHlvdSBaaGVuIHRo YXQgdGhpcyBjYXNlIGlzIG5vdCBjb3ZlcmVkIGluIFJGQzM0ODQuLiBJLmUuIEhvc3Qgd2l0aCBk dWFsLXN0YWNrIGludGVyZmFjZSAoYm90aCBwdWJsaWMgYWRkcikgc2hvdWxkIHVzdWFsbHkgcHJl ZmVyIElQdjYuIEhvc3Qgd2l0aCBvbmUgSVB2NCBpbnRlcmZhY2UgYW5kIG9uZSBJUHY2IGludGVy ZmFjZSBtYXkgb3IgbWF5IG5vdCB3YW50IHRvIHByZWZlciBJUHY2LCBkZXBlbmRpbmcgb24gdGhl IHNjZW5hcmlvIGF0IGhhbmQuDQo8YnI+DQo8YnI+VGhlIHByb2JsZW0gc3RhdGVtZW50J3Mgc2Vj dGlvbiA0LjIgYnVsbGV0IDIgY29tZXMgcmVhbGx5IGNsb3NlIHRvIHRoaXMsIGJ1dCBjb3VsZCBj bGFyaWZ5IChhZGQpIHRoZSBjYXNlIHdoZXJlIGRlc3RpbmF0aW9uIGlzIGR1YWwtc3RhY2sgcmVh Y2hhYmxlIGJ1dCB3aXRoIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3MgKGUuZy4gQ29zdHMpIGZv ciBkaWZmZXJlbnQgQUZzLiANCjxicj4NCjxicj5CZXN0IHJlZ2FyZHMsDQo8YnI+DQo8YnI+VGVl bXUNCjxicj4NCjxicj4tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tDQo8YnI+Jmd0OyBIaQ0K PGJyPiZndDsgDQo8YnI+Jmd0OyBUaGlzIHByb2JsZW0gaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRo ZSBsaXN0IGJlZm9yZSwgYXMNCjxicj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9taWYvY3VycmVudC9tc2cwMDcwMC5odG1sIj5odHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDA3MDAuaHRtbDwvYT4NCjxi cj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9taWYv Y3VycmVudC9tc2cwMDcwMS5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbWlmL2N1cnJlbnQvbXNnMDA3MDEuaHRtbDwvYT4NCjxicj4mZ3Q7IA0KPGJyPiZndDsgQWRk cmVzcyBzZWxlY3Rpb24gb2YgdGhlIGN1cnJlbnQgcHJvYmxlbSBzdGF0ZW1lbnQgbWF5IGhhdmUg YWxyZWFkeQ0KPGJyPiZndDsgY292ZXJlZCB0aGlzIGlzc3VlIGltcGxpY2l0bHkuDQo8YnI+Jmd0 OyANCjxicj4mZ3Q7IC1aaGVuDQo8YnI+Jmd0OyANCjxicj4mZ3Q7IE9uIFN1biwgQXVnIDgsIDIw MTAgYXQgMzo0OCBQTSwmbmJzcDsgJiMzMjsmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZW11LnNhdm9s YWluZW5Abm9raWEuY29tIj50ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3Rl Og0KPGJyPiZndDsgJmd0OyBIaSwNCjxicj4mZ3Q7ICZndDsgDQo8YnI+Jmd0OyAmZ3Q7IFRoZSBz Y2VuYXJpbyBJIGhhdmUgaW4gbXkgbWluZCBpcyBmb2xsb3dpbmcuDQo8YnI+Jmd0OyAmZ3Q7IA0K PGJyPiZndDsgJmd0OyBUaGUgY3VycmVudCB2ZXJ5IGNvbW1vbiBwcmFjdGljZSBpcyB0aGF0IHNp bmdsZSBob21lZCBtb2JpbGUgcGhvbmVzDQo8YnI+Jmd0OyBzZWxlY3QNCjxicj4mZ3Q7ICZndDsg V0xBTiBvdmVyIGNlbGx1bGFyIGlmIGJvdGgga2luZHMgb2YgbmV0d29ya3MgYXJlIHJlYWNoYWJs ZS4NCjxicj4mZ3Q7ICZndDsgDQo8YnI+Jmd0OyAmZ3Q7IE5vdyBpZiB0aGUgbW9iaWxlIHBob25l IGJlY29tZXMgbXVsdGlob21lZCwgaXQgd2lsbCBkeW5hbWljYWxseSBjaG9vc2UNCjxicj4mZ3Q7 IGZvcg0KPGJyPiZndDsgJmd0OyBlYWNoIHRyYW5zcG9ydCBzZXNzaW9uIHdoaWNoIGludGVyZmFj ZSB0byB1c2UgKGFzc3VtaW5nIGJvdGggYXJlDQo8YnI+Jmd0OyAiZGVmYXVsdCIpLg0KPGJyPiZn dDsgJmd0OyANCjxicj4mZ3Q7ICZndDsgSWYgdGhlIGNlbGx1bGFyIG9wZXJhdG9yIGlzIHF1aWNr ZXIgdG8gZGVwbG95IElQdjYgdGhhbiBXTEFOIG9wZXJhdG9yLA0KPGJyPiZndDsgaXQNCjxicj4m Z3Q7ICZndDsgbWlnaHQgYmVjb21lIGEgcHJvYmxlbSB0aGF0IGhvc3QgZmF2b3JzIGNlbGx1bGFy IGludGVyZmFjZSB0b28gbXVjaDoNCjxicj4mZ3Q7IGZyb20NCjxicj4mZ3Q7ICZndDsgY2VsbHVs YXIgb3BlcmF0b3IgYW5kIG1heWJlIGZyb20gdXNlciBwb2ludCBvZiB2aWV3IGFzIHdlbGwgKHRo aXMNCjxicj4mZ3Q7IHJlbGF0ZXMgdG8NCjxicj4mZ3Q7ICZndDsgInRyYWZmaWMgb2ZmbG9hZGlu ZyIpLiBUaGlzIG1heSBiZSBldmVuIGV4YWdnZXJhdGVkIGJ5IE5BVDY0IGluDQo8YnI+Jmd0OyBJ UHY2LW9ubHkNCjxicj4mZ3Q7ICZndDsgY2VsbHVsYXIgYWNjZXNzIG1ha2luZyBhbGwgSVB2NCBp bnRlcm5ldCBsb29rIGxpa2UgYmVpbmcgcmVhY2hhYmxlDQo8YnI+Jmd0OyBvdmVyIElQdjYNCjxi cj4mZ3Q7ICZndDsgKGJ1dCBmb3IgdGhpcyBjYXNlIHdlIGFyZSBhbHNvIHdvcmtpbmcgaW4gYmVo YXZlIHRvIGVuYWJsZSBob3N0IGRldGVjdA0KPGJyPiZndDsgTkFUNjQNCjxicj4mZ3Q7ICZndDsg YW5kIGRvd25wcmlvcml0aXplIElQdjYgYWRkcmVzc2VzIHdpdGggSVNQIE5BVDY0IHByZWZpeCku DQo8YnI+Jmd0OyAmZ3Q7IA0KPGJyPiZndDsgJmd0OyBIZW5jZSBpbiBzdWNoIHNjZXJpb3MgLSBm b3Igb3BlcmF0aW9uYWwgYW5kIGNvc3QgcmVhc29ucyAtIHdlIHRoaW5rDQo8YnI+Jmd0OyB0aGVy ZQ0KPGJyPiZndDsgJmd0OyBtaWdodCBiZSBuZWVkIGZvciBob3N0cyB0byBwcmVmZXIgSVB2NCBv dmVyIElQdjYgZm9yICJidWxrDQo8YnI+Jmd0OyB0cmFmZmljIiAod2hlbg0KPGJyPiZndDsgJmd0 OyBhcHBsaWNhdGlvbiBkb2VzIG5vdCBjYXJlIC0gb2YgY291cnNlIGFsd2F5cyBvbiBhcHBzLCBs aXN0ZW5lcnMsIFAyUA0KPGJyPiZndDsgZXRjIG1heQ0KPGJyPiZndDsgJmd0OyBwcmVmZXIgSVB2 NiBzdGlsbCkuDQo8YnI+Jmd0OyAmZ3Q7IA0KPGJyPiZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsDQo8 YnI+Jmd0OyAmZ3Q7IA0KPGJyPiZndDsgJmd0OyBUZWVtdQ0KPGJyPiZndDsgJmd0OyANCjxicj4m Z3Q7ICZndDsgLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLQ0KPGJyPiZndDsgJmd0OyAmZ3Q7 IE9uIDIwMTAtMDgtMDggMTU6MDIsIFRlZCBMZW1vbiB3cm90ZToNCjxicj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7IE9uIEF1ZyA3LCAyMDEwLCBhdCA2OjU3IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90 ZToNCjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUncyBub3RoaW5nIHRvIHByZXZl bnQgc3VjaCBhIG1lY2hhbmlzbSBhbHNvDQo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRl ZmluaW5nIGludGVyZmFjZSBwcmVmZXJlbmNlcy4NCjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IA0K PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgWWVzLCB0aGVyZSBpcy4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmIzMyO1ByZXN1bWFibHksIGlmIHRoZXJlIGlzIHNvbWUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo8 YnI+Jmd0OyB0aGUNCjxicj4mZ3Q7ICZndDsgJmd0OyBpbnRlcmZhY2VzLCBpdCB3aWxsIGJlIGJl Y2F1c2UgZWFjaCBpbnRlcmZhY2UgaXMgY29ubmVjdGVkIHRvIGENCjxicj4mZ3Q7IG5ldHdvcmsN Cjxicj4mZ3Q7ICZndDsgJmd0OyBtYW5hZ2VkIGJ5IGEgZGlmZmVyZW50IGVudGl0eS4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzMyO1RodXMsIHRoZXJlIGlzIG5vIHJlYXNvbmFibGUgYmFzaXMNCjxi cj4mZ3Q7IGZvcg0KPGJyPiZndDsgJmd0OyAmZ3Q7IGFzc3VtaW5nIHRoYXQgd2hhdCBlaXRoZXIg ZW50aXR5IGRlZmluZXMgYXMgYSBwb2xpY3kgaXMgaW4gZmFjdCB2YWxpZA0KPGJyPiZndDsgJmd0 OyAmZ3Q7IGZvciB0aGUgbm9kZS4NCjxicj4mZ3Q7ICZndDsgJmd0OyANCjxicj4mZ3Q7ICZndDsg Jmd0OyBUaGF0IGNvdWxkIHdlbGwgYmUsIGluIHdoaWNoIGNhc2UgdGhlIGhvc3QncyBvd24gcG9s aWN5IHNob3VsZA0KPGJyPiZndDsgJmd0OyAmZ3Q7IHByZWRvbWluYXRlLg0KPGJyPiZndDsgJmd0 OyAmZ3Q7IEkgZ3Vlc3MgbXkgcG9pbnQgaXMgdGhhdCB3ZSBkb24ndCBrbm93IHRoZSBkZXBsb3lt ZW50IHNjZW5hcmlvLCBzbyB3ZQ0KPGJyPiZndDsgJmd0OyAmZ3Q7IG5lZWQNCjxicj4mZ3Q7ICZn dDsgJmd0OyBtZWNoYW5pc21zIHRoYXQgY2FuIGJlIGFwcGxpZWQgaW4gYSB3aWRlIHJhbmdlIG9m IHNjZW5hcmlvcywgbm90IGp1c3QNCjxicj4mZ3Q7ICZndDsgJmd0OyB5b3Vycw0KPGJyPiZndDsg Jmd0OyAmZ3Q7IG9yIG1pbmUuDQo8YnI+Jmd0OyAmZ3Q7ICZndDsgDQo8YnI+Jmd0OyAmZ3Q7ICZn dDsgQnJpYW4NCjxicj4mZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPGJyPiZndDsgJmd0OyAmZ3Q7IG1pZiBtYWlsaW5nIGxpc3QN Cjxicj4mZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIj5taWZAaWV0 Zi5vcmc8L2E+DQo8YnI+Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9taWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWlmPC9hPg0KPGJyPiZndDsgJmd0OyAmZ3Q7IA0KPGJyPiZndDsgJmd0OyANCjxicj4m Z3Q7ICZndDsgDQo8YnI+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo8YnI+Jmd0OyAmZ3Q7IG1pZiBtYWlsaW5nIGxpc3QNCjxicj4mZ3Q7 ICZndDsgPGEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyI+bWlmQGlldGYub3JnPC9hPg0KPGJy PiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8L2E+DQo8YnI+ Jmd0OyAmZ3Q7IA0KPGJyPiZndDsgJmd0OyANCjxicj4mZ3Q7IA0KPGJyPjxicj48L3A+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_128129404819686camelNokiaN900_-- From teemu.savolainen@nokia.com Mon Aug 9 01:32:37 2010 Return-Path: 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 082D228C0D0 for ; Mon, 9 Aug 2010 01:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WyUeSXE2u9QD for ; Mon, 9 Aug 2010 01:32:35 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3428B3A6AAB for ; Mon, 9 Aug 2010 01:32:34 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o798WscW012392; Mon, 9 Aug 2010 03:33:04 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 11:32:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 11:32:29 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 9 Aug 2010 10:32:29 +0200 From: To: Date: Mon, 9 Aug 2010 10:32:27 +0200 Thread-Topic: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? Thread-Index: Acs3AGDiUPkYcyc9TbCDA4/DvyioNAAnEkcA Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AF78@NOK-EUMSG-01.mgdnok.nokia.com> References: <1281253688.6185.11.camel@Nokia-N900> <01DFBF5E-610B-4BA9-8634-6223CA5ECBE7@nominum.com> In-Reply-To: <01DFBF5E-610B-4BA9-8634-6223CA5ECBE7@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2010 08:32:29.0302 (UTC) FILETIME=[67522160:01CB379D] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:32:37 -0000 > > Hence in such scerios - for operational and cost reasons - we think > there might be need for hosts to prefer IPv4 over IPv6 for "bulk > traffic" (when application does not care - of course always on apps, > listeners, P2P etc may prefer IPv6 still). >=20 > But in this scenario, what you really want is for the host to prefer > the one interface over the other. The fact that you need it to prefer > IPv4 over IPv6 is immaterial--if the situation were reversed, and the > WLAN operator were providing IPv6 only, while the mobile operator were > only providing IPv4, you would want it to prefer IPv6. >=20 > So it doesn't really make sense to talk about this in terms of IPv6 or > IPv4--what you want is to be able to prefer one interface over the > other. Gabor put it nicely:"What I want is to prefer interface A and IPv6.".=20 So indeed you are right, interface sometimes need to be preferred above add= ress family. Teemu From remi.despres@free.fr Mon Aug 9 01:59:04 2010 Return-Path: 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 CFDD33A6AB6 for ; Mon, 9 Aug 2010 01:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 fDYGGIdAnXra for ; Mon, 9 Aug 2010 01:59:04 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id A57823A6AAE for ; Mon, 9 Aug 2010 01:59:03 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id D864D7000091; Mon, 9 Aug 2010 10:59:36 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 3CCEC700008B; Mon, 9 Aug 2010 10:59:36 +0200 (CEST) X-SFR-UUID: 20100809085936249.3CCEC700008B@msfrf2304.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4C5DD6DD.8090607@gmail.com> Date: Mon, 9 Aug 2010 10:59:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> To: Teemu Savolainen , Brian Carpenter X-Mailer: Apple Mail (2.1081) Cc: Gabor Bajko , mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:59:04 -0000 Hi, Teemu and Brian, =20 Le 7 ao=FBt 2010 =E0 23:57, Brian E Carpenter a =E9crit : > Teemu, >=20 > Shouldn't the decision about that be part of the RFC 3484 update > discussion over in 6man? Concerning the choice between IPv4 and IPv6 depending on which prefixes = are available, this 6man discussion is IMHO the right place. > Or should we logically separate the question of 'preferred interface' > from the question of 'preferred address prefix'? In my understanding, we should, to keep the problem manageable. =20 > Then it can be a local > policy issue whether you give priority to the interface choice or to = the > prefix choice. Unless I miss something, recommending to first choose the interface, and = then a source-destination couple available at this interface, can be = recommended as a basic requirement. It apparently works in typical scenarios, and anything else would in my = understanding be far more complex.=20 > (Or to measured performance.) Later maybe, but for a start, let's "Keep It Simple, Stupid". >=20 > Regards > Brian >=20 > On 2010-08-08 01:26, teemu.savolainen@nokia.com wrote: >> Mif, >>=20 >> Currently hosts generally prefer IPv6 over IPv4 communications. = However, a multi-homed host may have IPv6 available only on a less = preferred interface. For example, host's destination may be reachable = over both IPv4 and IPv6, but the host has an IPv6-only cellular (maybe = less preferred) and IPv4-only local WLAN interfaces (maybe more = preferred). >>=20 >> Do you think in such a case a MIF host should actually prefer IPv4 = communications instead of IPv6? Current single homed hosts would = probably have chosen to use WLAN for all communications anyway. At least when both source and destination can be public IPv4, using them = independently of any IPv6 availability seems to me the right choice. If the IPv4 source can only be private IPv4 while both source and = destination can be public IPv6, choosing IPv6 could be recommended = because it should preserves e2e transparency. I said should because of danger that some deployments would have NAT64s = with Network-Specific Prefixes; =20 The end result would be that hosts could no longer distinguish really = e2e transparent native addresses from addresses that are IPv4-embeded = IPv6 addresses (a terrible danger for IPv6 IMHO). >> Do you think this preference should be part of a distributed policy, = or something the host just should make its own mind about? Choice 2, at least to start with. Regards, RD >>=20 >> Best regards, >>=20 >> Teemu >>=20 >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From jari.arkko@piuha.net Mon Aug 9 06:22:55 2010 Return-Path: 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 066683A6AD3 for ; Mon, 9 Aug 2010 06:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZRbAiOLiZ1L9 for ; Mon, 9 Aug 2010 06:22:54 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E17393A6AD1 for ; Mon, 9 Aug 2010 06:22:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 432802CEB5; Mon, 9 Aug 2010 16:23:27 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spkaS+U-yXAW; Mon, 9 Aug 2010 16:23:26 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CA3662CCC0; Mon, 9 Aug 2010 16:23:25 +0300 (EEST) Message-ID: <4C60014C.3000006@piuha.net> Date: Mon, 09 Aug 2010 16:23:24 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: mif , draft-ietf-mif-problem-statement@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] AD review of mif-problem-statement (new version) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:22:55 -0000 I have reviewed the new version. It is much better, thanks! I have sent the draft forward to IETF Last Call. However, I did note the following issues that you might want to correct in the meantime: > 2. On a MIF host, some source addresses are not valid if used on > some interfaces. In this situation, the source address > should be taken into account in the routing table; but > current host implementations do not support such a feature. > ... used on some interfaces or even on some default routers on the same interface. > 1. In the MIF context, routing information could be specific to > each interface. This could lead to routing issue because, in > current host implementations,Routing tables are node-scoped. > Some formatting issues here. Jari From teemu.savolainen@nokia.com Mon Aug 9 06:50:59 2010 Return-Path: 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 0B7003A68ED for ; Mon, 9 Aug 2010 06:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dtd9HWeyumKI for ; Mon, 9 Aug 2010 06:50:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1987B3A695A for ; Mon, 9 Aug 2010 06:50:56 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o79Dp9ON015211; Mon, 9 Aug 2010 16:51:27 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 16:51:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 16:51:17 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 9 Aug 2010 15:51:17 +0200 From: To: , Date: Mon, 9 Aug 2010 15:51:15 +0200 Thread-Topic: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? Thread-Index: Acs3oUPVW7aZF1AMSzCm0T/Z26p3ZwAJwr6g Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2010 13:51:17.0605 (UTC) FILETIME=[F0AD8950:01CB37C9] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:50:59 -0000 Hi, > -----Original Message----- > From: ext R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: 09. elokuuta 2010 12:00 > To: Savolainen Teemu (Nokia-MS/Tampere); Brian Carpenter > Cc: Bajko Gabor (Nokia-CIC/MtView); mif@ietf.org > Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A > problem to be covered? >=20 > > Shouldn't the decision about that be part of the RFC 3484 update > > discussion over in 6man? >=20 > Concerning the choice between IPv4 and IPv6 depending on which prefixes > are available, this 6man discussion is IMHO the right place. Agree. > > Or should we logically separate the question of 'preferred interface' > > from the question of 'preferred address prefix'? >=20 > In my understanding, we should, to keep the problem manageable. There is a current practice to deal with problems as has been described (st= ick to use one of the available interface). We shall improve, and for that = we must walk into the land current implementations have not dared to go:) > > Then it can be a local > > policy issue whether you give priority to the interface choice or to > the > > prefix choice. >=20 > Unless I miss something, recommending to first choose the interface, > and then a source-destination couple available at this interface, can > be recommended as a basic requirement. If I understood your point correctly, that is the current practice. The hos= t chooses an interface and then does its best with it, while... > It apparently works in typical scenarios, and anything else would in my > understanding be far more complex. .. in MIF we want to improve that and allow all interfaces to be used when = doing source-destination selection. Possibly added with weighting addresses= of some interface higher than of others (i.e. having preferred interface b= ut not limiting to it). > > (Or to measured performance.) >=20 > Later maybe, but for a start, let's "Keep It Simple, Stupid". The current practice is simple, we want something smart now:) > If the IPv4 source can only be private IPv4 while both source and > destination can be public IPv6, choosing IPv6 could be recommended > because it should preserves e2e transparency. This hits my point. What I'm saying is that in some scenarios host should p= refer private NAT44444'ed IPv4 address over native IPv6, if the application= does not really care (uses e.g. connectbyname-like calls), and the physica= l interface providing IPv4 is preferred over the physical interface providi= ng IPv6. =20 > I said should because of danger that some deployments would have NAT64s > with Network-Specific Prefixes; > The end result would be that hosts could no longer distinguish really > e2e transparent native addresses from addresses that are IPv4-embeded > IPv6 addresses (a terrible danger for IPv6 IMHO). The NSP can be detected by the host OS or even by application itself, as wa= s discussed in behave WG. It requires some effort, though... Best regards, Teemu From wwwrun@core3.amsl.com Mon Aug 9 07:15:56 2010 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EC82D3A635F; Mon, 9 Aug 2010 07:15:52 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100809141552.EC82D3A635F@core3.amsl.com> Date: Mon, 9 Aug 2010 07:15:51 -0700 (PDT) Cc: mif@ietf.org Subject: [mif] Last Call: draft-ietf-mif-problem-statement (Multiple Interfaces Problem Statement) to Informational RFC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 14:15:56 -0000 The IESG has received a request from the Multiple Interfaces WG (mif) to consider the following document: - 'Multiple Interfaces Problem Statement ' 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 2010-08-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19231&rfc_flag=0 From remi.despres@free.fr Mon Aug 9 08:47:25 2010 Return-Path: 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 D33FA3A6AF0 for ; Mon, 9 Aug 2010 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] 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 ew1mWAWKaEFS for ; Mon, 9 Aug 2010 08:47:24 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id 787973A6AEE for ; Mon, 9 Aug 2010 08:47:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 2D868700009B; Mon, 9 Aug 2010 17:47:58 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id B335E7000098; Mon, 9 Aug 2010 17:47:57 +0200 (CEST) X-SFR-UUID: 20100809154757734.B335E7000098@msfrf2108.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 9 Aug 2010 17:47:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97895B7C-EE71-4A01-8E0C-0F42E1089C59@free.fr> References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1081) Cc: Gabor Bajko , mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 15:47:26 -0000 Thanks Teemu for your comments. Continued discussion below. Le 9 ao=FBt 2010 =E0 15:51, a =E9crit : > Hi, >=20 >> -----Original Message----- >> From: ext R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >> Sent: 09. elokuuta 2010 12:00 >> To: Savolainen Teemu (Nokia-MS/Tampere); Brian Carpenter >> Cc: Bajko Gabor (Nokia-CIC/MtView); mif@ietf.org >> Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A >> problem to be covered? >>=20 >>> Shouldn't the decision about that be part of the RFC 3484 update >>> discussion over in 6man? >>=20 >> Concerning the choice between IPv4 and IPv6 depending on which = prefixes >> are available, this 6man discussion is IMHO the right place. >=20 > Agree. >=20 >>> Or should we logically separate the question of 'preferred = interface' >>> from the question of 'preferred address prefix'? >>=20 >> In my understanding, we should, to keep the problem manageable. >=20 > There is a current practice to deal with problems as has been = described (stick to use one of the available interface). We shall = improve, and for that we must walk into the land current implementations = have not dared to go:) >=20 >>> Then it can be a local >>> policy issue whether you give priority to the interface choice or to >> the >>> prefix choice. >>=20 >> Unless I miss something, recommending to first choose the interface, >> and then a source-destination couple available at this interface, can >> be recommended as a basic requirement. >=20 > If I understood your point correctly, that is the current practice. = The host chooses an interface and then does its best with it, while... >=20 >> It apparently works in typical scenarios, and anything else would in = my >> understanding be far more complex. >=20 > .. in MIF we want to improve that and allow all interfaces to be used = when doing source-destination selection. Possibly added with weighting = addresses of some interface higher than of others (i.e. having preferred = interface but not limiting to it). >=20 >>> (Or to measured performance.) >>=20 >> Later maybe, but for a start, let's "Keep It Simple, Stupid". >=20 > The current practice is simple, we want something smart now:) >=20 >> If the IPv4 source can only be private IPv4 while both source and >> destination can be public IPv6, choosing IPv6 could be recommended >> because it should preserves e2e transparency. >=20 > This hits my point. What I'm saying is that in some scenarios host = should prefer private NAT44444'ed IPv4 address over native IPv6, if the = application does not really care (uses e.g. connectbyname-like calls), = and the physical interface providing IPv4 is preferred over the physical = interface providing IPv6. Connect by name is indeed a promising approach (BTW, I support Christian = Vogt's proposal of a name oriented socket interface). If the best interface is chosen first (e.g. Wifi vs 3G+) the remaining = preference could be, for outgoing connections: - SRC&DST public v4 - SRC&DST public v6 - DST public v4, SRC private v4 - DST public v6, SRC private v6 - DST private v4, SRC private v4=20 - DST private v6, SRC private v6 This would only solve a subset of the mif general problem, but, if = agreed, would at least be a guidance on what to do on a single = dual-stack interface. Besides, inbound connections received on some interface would use this = interface for outgoing traffic. Scenarios where this isn't sufficient need IMHO to be identified to = usefully discuss more sophisticated mechanisms. >> I said should because of danger that some deployments would have = NAT64s >> with Network-Specific Prefixes; >> The end result would be that hosts could no longer distinguish really >> e2e transparent native addresses from addresses that are IPv4-embeded >> IPv6 addresses (a terrible danger for IPv6 IMHO). >=20 > The NSP can be detected by the host OS or even by application itself, = as was discussed in behave WG. It requires some effort, though... That's where I see a danger. As long as there isn't a clean and safe conclusion to this discussion, = the danger remains to badly destroy the guarantee of e2e transparency = for SRC&DST public IPv6 addresses. IPv6-only client hosts and IPv6-only applications SHOULD only = communicate with IPv6-enabled peers. It shouldn't be possible that dual-stack hosts that use public IPv6 = addresses, SRC&DST, reach IPv4 servers (via NAT64s) without knowing that = e2e transparency won't be available. Said differently, all hosts that may need connectivity with some servers = that don't have IPv6 enabled SHOULD remain DUAL-STACK.=20 They may get their IPv4 addresses, public or private, across tunnels = over IPv6, but in no case their public IPv6 traffic should be permitted = to traverse NAT64s as long as their IPv6-capable applications have no = way to know it. Cheers, RD >=20 > Best regards, >=20 > Teemu From root@core3.amsl.com Wed Aug 11 13:15:01 2010 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DC4883A6A94; Wed, 11 Aug 2010 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100811201501.DC4883A6A94@core3.amsl.com> Date: Wed, 11 Aug 2010 13:15:01 -0700 (PDT) Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-current-practices-03.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Current Practices for Multiple Interface Hosts Author(s) : M. Wasserman, P. Seite Filename : draft-ietf-mif-current-practices-03.txt Pages : 20 Date : 2010-08-11 An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-current-practices-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-11130514.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Wed Aug 11 13:37:25 2010 Return-Path: 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 091B33A6AA0 for ; Wed, 11 Aug 2010 13:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 Hot6MNFgeHpH for ; Wed, 11 Aug 2010 13:37:24 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 1BEE83A69BC for ; Wed, 11 Aug 2010 13:37:24 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFB4B8B8014; Wed, 11 Aug 2010 22:38:15 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2BBF88B800D; Wed, 11 Aug 2010 22:38:12 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Aug 2010 22:37:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Aug 2010 22:37:30 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462010A1400@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C60014C.3000006@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of mif-problem-statement (new version) Thread-Index: Acs3xhZKPO4rQNxaRXq+FUYmXjbgmgBzqL6w References: <4C60014C.3000006@piuha.net> From: To: , , X-OriginalArrivalTime: 11 Aug 2010 20:37:31.0576 (UTC) FILETIME=[0585DB80:01CB3995] Subject: Re: [mif] AD review of mif-problem-statement (new version) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:37:25 -0000 Hi Jari, The PS draft has been updated accordingly. Thanks. Pierrick > -----Message d'origine----- > De=A0: Jari Arkko [mailto:jari.arkko@piuha.net] > Envoy=E9=A0: lundi 9 ao=FBt 2010 15:23 > =C0=A0: mif; draft-ietf-mif-problem-statement@tools.ietf.org > Objet=A0: AD review of mif-problem-statement (new version) >=20 > I have reviewed the new version. It is much better, thanks! I have = sent > the draft forward to IETF Last Call. However, I did note the following > issues that you might want to correct in the meantime: >=20 > > 2. On a MIF host, some source addresses are not valid if used on > > some interfaces. In this situation, the source address > > should be taken into account in the routing table; but > > current host implementations do not support such a feature. > > >=20 > ... used on some interfaces or even on some default routers on the = same > interface. >=20 > > 1. In the MIF context, routing information could be specific to > > each interface. This could lead to routing issue because, in > > current host implementations,Routing tables are node-scoped. > > >=20 > Some formatting issues here. >=20 > Jari From root@core3.amsl.com Wed Aug 11 13:45:02 2010 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 20C653A6AA2; Wed, 11 Aug 2010 13:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100811204502.20C653A6AA2@core3.amsl.com> Date: Wed, 11 Aug 2010 13:45:02 -0700 (PDT) Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-problem-statement-06.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Multiple Interfaces Problem Statement Author(s) : M. Blanchet, P. Seite Filename : draft-ietf-mif-problem-statement-06.txt Pages : 16 Date : 2010-08-11 A multihomed host receives node configuration information from each of its provisioning domain. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-problem-statement-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-11133310.I-D@ietf.org> --NextPart-- From scott.brim@gmail.com Wed Aug 11 14:11:31 2010 Return-Path: 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 AD4C23A6872 for ; Wed, 11 Aug 2010 14:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 z9jKHdPcsFtE for ; Wed, 11 Aug 2010 14:11:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 2A8E53A683C for ; Wed, 11 Aug 2010 14:11:29 -0700 (PDT) Received: by vws10 with SMTP id 10so456462vws.31 for ; Wed, 11 Aug 2010 14:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=wwl+0BCjxteU6NwIhqtO8hW2U/xuurWetm4lCy4nSqE=; b=T/Sss7K3AYsdNL0mPdJWccpMeqDZRQ7Xu2USSoBt2gshe1+e/TQG5xPWOLS7Kcb2s4 cHaWQKs9W98EvB9dLCjSBdT+MG74KoUL/nagv3h5VljyC3M7AJYQdbbhhiX4vM/EIHRG uqUXFeBtVsJslghhWFpfRJDHGLH53K4ylggsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=U6ibmgK2Yoq+0do0RVkQElwYaZtuVRDe4fnp/SK2QIfO6Y+FRdKQx53nFr5o86siwn yDYXVgV/vptqGc7ZCsnwj4n0339DDQyrktNzREf/HPvBeaTHyrAsTS/OWPQUpT///jmj 5VkAGRzs9nuol3rC3ynLvJft6feEEi1CLCVs4= Received: by 10.220.122.151 with SMTP id l23mr4710884vcr.22.1281561126152; Wed, 11 Aug 2010 14:12:06 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id m30sm360609vbr.19.2010.08.11.14.12.04 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 14:12:05 -0700 (PDT) Message-ID: <4C631222.2000705@gmail.com> Date: Wed, 11 Aug 2010 17:12:02 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 21:11:31 -0000 On 08/09/2010 09:51 EDT, teemu.savolainen@nokia.com wrote: > This hits my point. What I'm saying is that in some scenarios host > should prefer private NAT44444'ed IPv4 address over native IPv6, if > the application does not really care (uses e.g. connectbyname-like > calls), and the physical interface providing IPv4 is preferred over > the physical interface providing IPv6. (Back from vacation ...) My concern with much of this discussion is that it seems to treat the problem as if the answer has to be figured out a priori and then set as policy for a particular configuration, not taking actual performance into account. Networks are fluid, but hosts can observe their environment and adapt as the environment changes. A behavior choice at one moment may not be the correct one in a few seconds. Scott From pierrick.seite@orange-ftgroup.com Wed Aug 11 14:29:53 2010 Return-Path: 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 0BB643A68AD for ; Wed, 11 Aug 2010 14:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] 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 EW1gso9NN2cT for ; Wed, 11 Aug 2010 14:29:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 747803A6AAF for ; Wed, 11 Aug 2010 14:29:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6326D76000D; Wed, 11 Aug 2010 23:33:02 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 59EA076000C; Wed, 11 Aug 2010 23:33:02 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Aug 2010 23:30:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Aug 2010 23:29:40 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462010A1403@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <97895B7C-EE71-4A01-8E0C-0F42E1089C59@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Preferring IPv4 interface over IPv6 interface? A problemto be covered? Thread-Index: Acs32lVfmgG83pInTgGNvM0v9NwzKwBwdedA References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com><4C5DD6DD.8090607@gmail.com><18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> <97895B7C-EE71-4A01-8E0C-0F42E1089C59@free.fr> From: To: , X-OriginalArrivalTime: 11 Aug 2010 21:30:27.0497 (UTC) FILETIME=[6A84F190:01CB399C] Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problemto be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 21:29:53 -0000 Hi guys, This is a very interesting discussion, but it seems to me that it is a = 6man discussion and that we digress from the MIF problem statement. If I = browse the emails, it seems that _for MIF_ the question is (quoting = Teemu): Should we add the case where destination is dual-stack reachable but = with different characteristics (e.g. Costs) for different AFs.=20 It is true that it is slightly different from the problem statement's = routing section which focuses on the selection of the path to reach a = single IP address. However I think this use-case is specific to V4/V6 = cohabitation and is out of MIF scope. MIF could tackle with a use-case = where a server could be reachable via two IP addresses. However, I do = not see this use-case realistic. Other opinion? BR, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de R=E9mi > Despr=E9s > Envoy=E9=A0: lundi 9 ao=FBt 2010 17:48 > =C0=A0: teemu.savolainen@nokia.com > Cc=A0: Gabor Bajko; mif@ietf.org > Objet=A0: Re: [mif] Preferring IPv4 interface over IPv6 interface? A > problemto be covered? >=20 > Thanks Teemu for your comments. > Continued discussion below. >=20 >=20 > Le 9 ao=FBt 2010 =E0 15:51, a =E9crit : >=20 > > Hi, > > > >> -----Original Message----- > >> From: ext R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > >> Sent: 09. elokuuta 2010 12:00 > >> To: Savolainen Teemu (Nokia-MS/Tampere); Brian Carpenter > >> Cc: Bajko Gabor (Nokia-CIC/MtView); mif@ietf.org > >> Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A > >> problem to be covered? > >> > >>> Shouldn't the decision about that be part of the RFC 3484 update > >>> discussion over in 6man? > >> > >> Concerning the choice between IPv4 and IPv6 depending on which = prefixes > >> are available, this 6man discussion is IMHO the right place. > > > > Agree. > > > >>> Or should we logically separate the question of 'preferred = interface' > >>> from the question of 'preferred address prefix'? > >> > >> In my understanding, we should, to keep the problem manageable. > > > > There is a current practice to deal with problems as has been = described > (stick to use one of the available interface). We shall improve, and = for > that we must walk into the land current implementations have not dared = to > go:) > > > >>> Then it can be a local > >>> policy issue whether you give priority to the interface choice or = to > >> the > >>> prefix choice. > >> > >> Unless I miss something, recommending to first choose the = interface, > >> and then a source-destination couple available at this interface, = can > >> be recommended as a basic requirement. > > > > If I understood your point correctly, that is the current practice. = The > host chooses an interface and then does its best with it, while... > > > >> It apparently works in typical scenarios, and anything else would = in my > >> understanding be far more complex. > > > > .. in MIF we want to improve that and allow all interfaces to be = used > when doing source-destination selection. Possibly added with weighting > addresses of some interface higher than of others (i.e. having = preferred > interface but not limiting to it). > > > >>> (Or to measured performance.) > >> > >> Later maybe, but for a start, let's "Keep It Simple, Stupid". > > > > The current practice is simple, we want something smart now:) > > > >> If the IPv4 source can only be private IPv4 while both source and > >> destination can be public IPv6, choosing IPv6 could be recommended > >> because it should preserves e2e transparency. > > > > This hits my point. What I'm saying is that in some scenarios host > should prefer private NAT44444'ed IPv4 address over native IPv6, if = the > application does not really care (uses e.g. connectbyname-like calls), = and > the physical interface providing IPv4 is preferred over the physical > interface providing IPv6. >=20 > Connect by name is indeed a promising approach (BTW, I support = Christian > Vogt's proposal of a name oriented socket interface). >=20 > If the best interface is chosen first (e.g. Wifi vs 3G+) the remaining > preference could be, for outgoing connections: > - SRC&DST public v4 > - SRC&DST public v6 > - DST public v4, SRC private v4 > - DST public v6, SRC private v6 > - DST private v4, SRC private v4 > - DST private v6, SRC private v6 >=20 > This would only solve a subset of the mif general problem, but, if = agreed, > would at least be a guidance on what to do on a single dual-stack > interface. > Besides, inbound connections received on some interface would use this > interface for outgoing traffic. >=20 > Scenarios where this isn't sufficient need IMHO to be identified to > usefully discuss more sophisticated mechanisms. >=20 >=20 > >> I said should because of danger that some deployments would have = NAT64s > >> with Network-Specific Prefixes; > >> The end result would be that hosts could no longer distinguish = really > >> e2e transparent native addresses from addresses that are = IPv4-embeded > >> IPv6 addresses (a terrible danger for IPv6 IMHO). > > > > The NSP can be detected by the host OS or even by application = itself, as > was discussed in behave WG. It requires some effort, though... >=20 > That's where I see a danger. > As long as there isn't a clean and safe conclusion to this discussion, = the > danger remains to badly destroy the guarantee of e2e transparency for > SRC&DST public IPv6 addresses. >=20 > IPv6-only client hosts and IPv6-only applications SHOULD only = communicate > with IPv6-enabled peers. > It shouldn't be possible that dual-stack hosts that use public IPv6 > addresses, SRC&DST, reach IPv4 servers (via NAT64s) without knowing = that > e2e transparency won't be available. >=20 > Said differently, all hosts that may need connectivity with some = servers > that don't have IPv6 enabled SHOULD remain DUAL-STACK. > They may get their IPv4 addresses, public or private, across tunnels = over > IPv6, but in no case their public IPv6 traffic should be permitted to > traverse NAT64s as long as their IPv6-capable applications have no way = to > know it. >=20 > Cheers, > RD >=20 >=20 >=20 >=20 > > > > Best regards, > > > > Teemu >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From brian.e.carpenter@gmail.com Wed Aug 11 14:38:29 2010 Return-Path: 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 3E0F93A6ABC for ; Wed, 11 Aug 2010 14:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.786 X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 31RJ-2tQAYmU for ; Wed, 11 Aug 2010 14:38:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 29D973A6ABB for ; Wed, 11 Aug 2010 14:38:28 -0700 (PDT) Received: by wwj40 with SMTP id 40so529486wwj.13 for ; Wed, 11 Aug 2010 14:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1mji72c/AliWQaptzaBt5ujTlzBEDDr6ARjMLEjuyA8=; b=T59PMlLwGs1xar94F/OvIcSS94tM56J6GWby5M5OXZ5SMcfUP88evT/+CkzwXSZ8CS /k8V+WiLDEE9+qCVZb8iL7fUgDy9Yqrpn3PrU6sylMlhffYuazDhuTf8IvQ8ZN44RwkO wD5hfJIfD6DVCdCQWS5bzGgfyaaC+c3D+RTf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QgGZCcEVOYP5hLNN1j/lgVIWLL1XdaVIe+uEvzMBtblJN71a8xiDBwk72kjMW9V8q/ +IhQ6FyOlseE6QC4e7ZMxG7LV/C3Dk3nx91s6TywfzgvCbd454dQ+56F2f6xhcX16Us/ AjQ5ABuvsm+F5aa5WAQmEX1bfQAuKQl4F4meY= Received: by 10.216.234.132 with SMTP id s4mr5896169weq.0.1281562743823; Wed, 11 Aug 2010 14:39:03 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l55sm431704weq.41.2010.08.11.14.38.59 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 14:39:03 -0700 (PDT) Message-ID: <4C63185E.8090207@gmail.com> Date: Thu, 12 Aug 2010 09:38:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> <4C631222.2000705@gmail.com> In-Reply-To: <4C631222.2000705@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Gabor.Bajko@nokia.com, mif@ietf.org Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 21:38:29 -0000 On 2010-08-12 09:12, Scott Brim wrote: > On 08/09/2010 09:51 EDT, teemu.savolainen@nokia.com wrote: >> This hits my point. What I'm saying is that in some scenarios host >> should prefer private NAT44444'ed IPv4 address over native IPv6, if >> the application does not really care (uses e.g. connectbyname-like >> calls), and the physical interface providing IPv4 is preferred over >> the physical interface providing IPv6. > > (Back from vacation ...) My concern with much of this discussion is that > it seems to treat the problem as if the answer has to be figured out a > priori and then set as policy for a particular configuration, not taking > actual performance into account. Networks are fluid, but hosts can > observe their environment and adapt as the environment changes. A > behavior choice at one moment may not be the correct one in a few seconds. I completelly agree. As RFC3484 experience shows, a default policy and no run-time flexibility clearly create bad user experience. I can't guess how many times I've switched the network.dns.disableIPv6 flag in Firefox around as I've travelled with my laptop. I would much prefer my computer to make this decision automatically based on performance. Brian Brian From yuri@ismailov.eu Thu Aug 12 05:32:04 2010 Return-Path: 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 5E2AC3A6950 for ; Thu, 12 Aug 2010 05:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kGssn0g2wCd9 for ; Thu, 12 Aug 2010 05:32:03 -0700 (PDT) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.16]) by core3.amsl.com (Postfix) with ESMTP id DE7A63A6949 for ; Thu, 12 Aug 2010 05:32:00 -0700 (PDT) Received: from [213.159.189.47] (unknown [213.159.189.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 294BE576AB9 for ; Thu, 12 Aug 2010 14:32:36 +0200 (CEST) Message-ID: <4C63E8C6.2060603@ismailov.eu> Date: Thu, 12 Aug 2010 14:27:50 +0200 From: Yuri Ismailov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100812 Thunderbird/3.1.1 MIME-Version: 1.0 To: mif@ietf.org References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> <4C631222.2000705@gmail.com> <4C63185E.8090207@gmail.com> In-Reply-To: <4C63185E.8090207@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:32:04 -0000 Hi all, The discussion is interesting but isn't it obvious that an application chooses an interface first and then preferred address family. It is not possible to choose IPv6 GPRS for 128K coded stream. It will not work. /yuri On 08/11/10 23:38, Brian E Carpenter wrote: > On 2010-08-12 09:12, Scott Brim wrote: >> On 08/09/2010 09:51 EDT, teemu.savolainen@nokia.com wrote: >>> This hits my point. What I'm saying is that in some scenarios host >>> should prefer private NAT44444'ed IPv4 address over native IPv6, if >>> the application does not really care (uses e.g. connectbyname-like >>> calls), and the physical interface providing IPv4 is preferred over >>> the physical interface providing IPv6. >> >> (Back from vacation ...) My concern with much of this discussion is that >> it seems to treat the problem as if the answer has to be figured out a >> priori and then set as policy for a particular configuration, not taking >> actual performance into account. Networks are fluid, but hosts can >> observe their environment and adapt as the environment changes. A >> behavior choice at one moment may not be the correct one in a few seconds. > > I completelly agree. As RFC3484 experience shows, a default policy and no > run-time flexibility clearly create bad user experience. I can't guess how > many times I've switched the network.dns.disableIPv6 flag in Firefox > around as I've travelled with my laptop. I would much prefer my computer > to make this decision automatically based on performance. > > Brian > > Brian > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From Ted.Lemon@nominum.com Thu Aug 12 07:18:52 2010 Return-Path: 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 2CC6C3A682A for ; Thu, 12 Aug 2010 07:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.163 X-Spam-Level: X-Spam-Status: No, score=-106.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 BS3923nV4PVC for ; Thu, 12 Aug 2010 07:18:51 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 359633A6A3F for ; Thu, 12 Aug 2010 07:18:48 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTGQCywqRkUCi6ivlRdH03AP7zuzpFS33@postini.com; Thu, 12 Aug 2010 07:19:28 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 451531B82D3; Thu, 12 Aug 2010 07:18:45 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 12 Aug 2010 07:18:44 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4C63E8C6.2060603@ismailov.eu> Date: Thu, 12 Aug 2010 10:18:40 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <5B3FB57B-FA0F-45B4-9660-7FB3CD1F931C@nominum.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044AC03@NOK-EUMSG-01.mgdnok.nokia.com> <4C5DD6DD.8090607@gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F5F004B3F57@NOK-EUMSG-01.mgdnok.nokia.com> <4C631222.2000705@gmail.com> <4C63185E.8090207@gmail.com> <4C63E8C6.2060603@ismailov.eu> To: Yuri Ismailov X-Mailer: Apple Mail (2.1081) Cc: "mif@ietf.org" Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe:

1) Split-DNS solution:
a specification of DHCPv6 options allow= ing client nodes to perform
route table configuration, to avoid all flo= ws being led to the
default route."
=A0
2) DHCPv6 routing co= nfiguration:

a specification of DHCPv6 options allowing client nodes to perform

route table configuration.
=A0
3) MIF API:
an abstract API d= escribing how applications can exploit additional
features of multiple = interface enabled stack. While MIF
does not need any application change= s, this API could provide additional services
to MIF related functions, such as first-hop selection, source address selec= tion, DNS
selection, etc.
=A0
=A0Goals and Milestones
Nov 2010= : Initial WG draft on Split-DNS solution
Nov 2010: Initial WG draft on D= HCPv6 option for routing configuration
Nov 2010: Initial WG draft on MIF API extension.=A0=A0
Nov 2011: Submit= Split-DNS solution to IESG for publication as
=A0a Proposed Standard R= FC
Nov 2011: Submit DHCPv6 extension solution to IESG for publication as= a
=A0Proposed Standard RFC
Nov 2011: Submit MIF API extension solution to= IESG for publication
=A0as an Informational RFC

--00221532ccc88995cb048f071406-- From mrw@lilacglade.org Mon Aug 30 03:00:29 2010 Return-Path: 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 820D63A688C for ; Mon, 30 Aug 2010 03:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5urS3779O-2f for ; Mon, 30 Aug 2010 03:00:28 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id B8C8D3A6828 for ; Mon, 30 Aug 2010 03:00:28 -0700 (PDT) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 0ZyA1f0010cQ2SLAAa10RR; Mon, 30 Aug 2010 10:01:00 +0000 Received: from [10.36.0.42] ([98.110.155.200]) by omta10.emeryville.ca.mail.comcast.net with comcast id 0a0g1f0094Khd5e8Wa0kXE; Mon, 30 Aug 2010 10:00:57 +0000 Message-Id: <9232F326-D2F1-4BDA-B398-F6AF4780F253@lilacglade.org> From: Margaret Wasserman To: Hui Deng In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Aug 2010 06:00:40 -0400 References: X-Mailer: Apple Mail (2.936) Cc: mif@ietf.org, rdroms@cisco.com Subject: Re: [mif] Recharter discussion - update X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 10:00:29 -0000 Hi Hui, On Aug 30, 2010, at 4:59 AM, Hui Deng wrote: > > 1) Split-DNS solution: > a specification of DHCPv6 options allowing client nodes to perform > route table configuration, to avoid all flows being led to the > default route." This does not seem like the right text for Split DNS. Could this be a cut-and-paste error? This section previously said: "a specification for describing a way for a network to communicate to nodes information required to perform advanced DNS server selection in split-DNS deployments. The specification shall describe the information to be delivered for nodes and the protocol to be used for delivery." > > 2) DHCPv6 routing configuration: > a specification of an option to DHCPv6 to inform hosts information > required to perform advanced routing table configuration, to avoid > the all flows being led to the default route. I like the wording you had included above better: > a specification of DHCPv6 options allowing client nodes to perform > route table configuration, to avoid all flows being led to the > default route." I would make one change though: s/led/sent > > 3) MIF API: > an abstract API describing how applications can exploit additional > features of multiple interface enabled stack. While MIF > does not need any application changes, this API could provide > additional services > to MIF related functions, such as first-hop selection, source > address selection, DNS > selection, etc. I don't feel comfortable the use of "MIF" as a noun, as though it were a protocol... Maybe the second sentence could say: "While no changes are needed for applications to run on multiple interface hosts, this API could provide additional services to applications running on multiple interface hosts, such as..." I would also reword a couple of the milestones: > Goals and Milestones > Nov 2010: Initial WG draft on Split-DNS solution > Nov 2010: Initial WG draft on DHCPv6 option for routing configuration > Nov 2010: Initial WG draft on MIF API extension. > Nov 2011: Submit Split-DNS solution to IESG for publication as > a Proposed Standard RFC > Nov 2011: Submit DHCPv6 extension solution to IESG for publication > as a > Proposed Standard RFC s/extension solution/routing configuration option > Nov 2011: Submit MIF API extension solution to IESG for publication > as an Informational RFC s/MIF API extension solution/abstract MIF API description Let me know what you think. Margaret From pierrick.seite@orange-ftgroup.com Mon Aug 30 04:46:08 2010 Return-Path: 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 B58F13A69AD for ; Mon, 30 Aug 2010 04:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.983 X-Spam-Level: X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 rCaBYkeVqIv2 for ; Mon, 30 Aug 2010 04:46:07 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id E9D1E3A6835 for ; Mon, 30 Aug 2010 04:45:33 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA547760007; Mon, 30 Aug 2010 13:48:59 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id BFA0C760003; Mon, 30 Aug 2010 13:48:59 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Aug 2010 13:46:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Aug 2010 13:46:02 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201139C69@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9232F326-D2F1-4BDA-B398-F6AF4780F253@lilacglade.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recharter discussion - update Thread-Index: ActIKlMuYnzFmOKwR4aIFD/Kc+YPHAADG+CQ References: <9232F326-D2F1-4BDA-B398-F6AF4780F253@lilacglade.org> From: To: , X-OriginalArrivalTime: 30 Aug 2010 11:46:04.0025 (UTC) FILETIME=[ECE8F690:01CB4838] Cc: mif@ietf.org, rdroms@cisco.com Subject: Re: [mif] Recharter discussion - update X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 11:46:08 -0000 Hi Margaret, Hui, I'd suggest a slight modification of API item. Please see inline. Pierrick > -----Message d'origine----- > De=A0: Margaret Wasserman [mailto:mrw@lilacglade.org] > Envoy=E9=A0: lundi 30 ao=FBt 2010 12:01 > =C0=A0: Hui Deng > Cc=A0: SEITE Pierrick RD-RESA-REN; mif@ietf.org; jari.arkko@piuha.net; > rdroms@cisco.com > Objet=A0: Re: Recharter discussion - update >=20 >=20 > Hi Hui, >=20 > On Aug 30, 2010, at 4:59 AM, Hui Deng wrote: > > > > 1) Split-DNS solution: > > a specification of DHCPv6 options allowing client nodes to perform > > route table configuration, to avoid all flows being led to the > > default route." >=20 > This does not seem like the right text for Split DNS. Could this be a > cut-and-paste error? >=20 > This section previously said: >=20 > "a specification for describing a way for a network to communicate to > nodes information required to perform advanced DNS server selection > in split-DNS deployments. The specification shall describe the > information to be delivered for nodes and the protocol to be used > for delivery." >=20 > > > > 2) DHCPv6 routing configuration: > > a specification of an option to DHCPv6 to inform hosts information > > required to perform advanced routing table configuration, to avoid > > the all flows being led to the default route. >=20 > I like the wording you had included above better: >=20 > > a specification of DHCPv6 options allowing client nodes to perform > > route table configuration, to avoid all flows being led to the > > default route." >=20 > I would make one change though: s/led/sent >=20 > > > > 3) MIF API: > > an abstract API describing how applications can exploit additional > > features of multiple interface enabled stack. While MIF > > does not need any application changes, this API could provide > > additional services > > to MIF related functions, such as first-hop selection, source > > address selection, DNS > > selection, etc. >=20 > I don't feel comfortable the use of "MIF" as a noun, as though it were > a protocol... Maybe the second sentence could say: >=20 > "While no changes are needed for applications to run on multiple > interface hosts, this API could provide additional services to > applications running on multiple interface hosts, such as..." >=20 I like this sentence but, we are also meant to address single interface = terminals. So, I'd propose the following: While no changes are needed for applications to run on multiple = interface hosts, this API could provide additional services to = applications running on hosts attached to multiple provisioning domains. = For instance, these services could help in solving first-hop, source = address and/or DNS selection issues. > I would also reword a couple of the milestones: >=20 > > Goals and Milestones > > Nov 2010: Initial WG draft on Split-DNS solution > > Nov 2010: Initial WG draft on DHCPv6 option for routing = configuration > > Nov 2010: Initial WG draft on MIF API extension. > > Nov 2011: Submit Split-DNS solution to IESG for publication as > > a Proposed Standard RFC > > Nov 2011: Submit DHCPv6 extension solution to IESG for publication > > as a > > Proposed Standard RFC >=20 > s/extension solution/routing configuration option >=20 > > Nov 2011: Submit MIF API extension solution to IESG for publication > > as an Informational RFC >=20 > s/MIF API extension solution/abstract MIF API description >=20 > Let me know what you think. >=20 > Margaret >=20 From rdroms.ietf@gmail.com Mon Aug 30 12:56:05 2010 Return-Path: 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 AD6343A6876; Mon, 30 Aug 2010 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aHH1tYUGj90p; Mon, 30 Aug 2010 12:56:04 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 3C5613A6870; Mon, 30 Aug 2010 12:56:04 -0700 (PDT) Received: by qyk9 with SMTP id 9so5411069qyk.10 for ; Mon, 30 Aug 2010 12:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mSVuYD+HooDNCL/O7CM3U4NGFSt0kqmQC/+ENdWFtfc=; b=OEDpBv5TeQO90srusIaNYarJY8TkYn1Kew9t9ptgc5vedVo9g+qWr7cBGjLjRLiP4g 9MIILt6j69wA9bhg/aNFEVXSRtY+xIpqSAT9VsS2+MAw0D5yun/eIHUkzWIlBL85ZK/5 l9OnODAtVDYnsnY1lNunDNMnCvUXceH81MN48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=IgS6ERL73NDARz8WwXEf5iUyYRHbE9J+PSE7obkM3hoAXb63ZWQTijwDEXpjUKIAS9 YpqcULw5yLQVOyp1IlaxGRYdWYqjMVusdI+Z+h4hwiDgEckZ0071oE8u9xyssJbSsigN jTjA3JYZfdTvwr8h6mXhMbU4xKHh/QjPCvs+o= Received: by 10.224.73.134 with SMTP id q6mr3343541qaj.40.1283198194799; Mon, 30 Aug 2010 12:56:34 -0700 (PDT) Received: from bxb-rdroms-8718.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id r38sm8727828qcs.2.2010.08.30.12.56.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 12:56:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4C77CEAA.7060401@piuha.net> Date: Mon, 30 Aug 2010 15:55:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100826192451.19395.16476.idtracker@localhost> <4C77CEAA.7060401@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1078) Cc: mif , IESG Subject: Re: [mif] Next steps on draft-ietf-mif-problem-statement-07.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 19:56:05 -0000 Jari - your plan sounds appropriate to me. I will, of course, review = the revised document when it comes to the IESG and would be happy to = provide any guidance the WG might find helpful as it updates the = document. - Ralph On Aug 27, 2010, at 10:41 AM 8/27/10, Jari Arkko wrote: > We discussed this document today on the IESG call. Two major comments = were made. First, Lars Eggert made the point that the document's = explanation of interface choice based on interface characteristics = (Problem 3.2 in Section 5) is far too simplistic. Interface speed, for = instance, is just one factor among many, and that in reality, = congestion, path characteristics and perhaps even application traffic = patterns would have to be taken into account; most likely you would not = know what kind of characteristics you can get before actually using the = interface for the task at hand. Interface selection in order to optimize = application performance is a very hard problem, perhaps unsolvable in = the general case. >=20 > Second, Ralph Droms made the point that not all problems associated = with the multiple interfaces are merely due to merging node-scoped = information. Overlapping address space on different interfaces is a = fundamental problem that cannot be solved through better host = configuration mechanisms, for instance. The document currently focuses = mostly on the configuration part of the problem today. >=20 > We also talked quite a bit about what the next steps for resolving = these issues are. My opinion is that the document would be most useful = when it describes the full scope of the problem. It would be = particularly valuable to describe the fundamental issues, as that may = help us understand potential limits of solutions. Here's what I would = suggest that we do: >=20 > 1. Go through the document and expand/correct it to describe both the = configuration merging problem and other fundamental issues around = multiple interfaces (such as address or name space overlap). >=20 > 2. Change the parts of the document that talk aboout interface = selection based on characteristics, and point out that for proper = selection, many factors have to be considered. >=20 > 3. Go through the document and make a clearer statement about what = problems it discusses are hard. For instance, Section 6 says: = "Therefore, there is a need to define the appropriate behavior of an IP = stack and possibly define protocols to manage these cases." This needs = to be expanded in order to explain what issues are solvable through = configuration object management, and what issues remain as fundamentally = hard problems (address space overlap, knowing what throughput the path = from one interface will give you, etc). >=20 > These changes are extensive, but in my opinion doable. I am sending = the document back to the working group in order to make the next = revision, and we will be doing a new WGLC/IETF Last Call when the = revision is ready. >=20 > Thoughts? Comments? Does this plan work for everyone? >=20 > Jari >=20 > Ralph's Discuss: >=20 >> I have a fundamental problem with the way in which this document = characterizes the problems resulting from the simultaneous use of = multiple interfaces as all resulting from receiving different = configuration objects from different administrative domains. In my = opinion, some of the example problems in the document are a result of = other problems inherent with the simlutaneous use of multiple = interfaces. This distinction is important because , again in my = opinion, there are mif problems which cannot be solved by changes to the = configuration behavior in the host. >>=20 >> For example, in section 4.1, the symptom: >>=20 >> 4. S1 or S2 has been used to resolve "a.private.example.com" to an >> [RFC1918] address. Both N1 and N2 are [RFC1918] addressed >> networks. IPv4 source address selection may face challenges, as >> due address overlapping the source/destination IP addresses do >> not necessarily provide enough information for making proper >> address selection decisions. >>=20 >> is inherent in having interfaces connected to networks using = overlapping address spaces, and cannot be solved by improvements to the = configuration behavior. >>=20 >> Similarly in section 4.1: >>=20 >> 5. H1 has resolved an FQDN to locally valid IP address when >> connected to N1. After movement from N1 to N2, the host tries to >> connect to the same IP address as earlier, but as the address was >> only locally valid, connection setup fails. Similarly, H1 may >> have received NXDOMAIN for an FQDN when connected to N1. After >> movement from N1 to N2, the host should not assume the FQDN >> continues to be nonexistent. >>=20 >> How is this problem caused by configuration objects from different = domains? >>=20 >>=20 >=20 >> I see two ways to address my concern: either be explicit in limiting = the problem statement and mif deliverables to those problems that can be = solved with proper handling of configuration information from multiple = admin domains or extend the scope of this document to include any = problems that may result from the disparate environments (IP = reachability, DNS resolution, QoS) to which interfaces are attached. >>=20 >=20 > Lars' Discuss: >=20 >> Section 3., paragraph 1: >>=20 >>>> 2. Interfaces of a MIF host can provide different >>>> characteristics (e.g. round-trip time, least cost, better >>>> bandwidth, etc....). So, user, applications or network >>>> provider may wish to influence routing to take benefit of >>>> this heterogeneity. However, with current host >>>> implementations, neither the Type-of-Service nor path >>>> characteristics can be taken into account in the routing >>>> table. >>>=20 >>=20 >> DISCUSS: I don't think MIF can solve this problem. Yes, interfaces = are >> the first hops into *paths* of different characteristics, but what >> service quality an application sees across a path depends on the >> destination, the transport protocol in use and the communication >> patterns of the application. There is nothing here that can be >> optimized without taking these into account. >>=20 >=20 >=20 From denghui02@gmail.com Mon Aug 30 19:53:51 2010 Return-Path: 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 6A0B23A6452 for ; Mon, 30 Aug 2010 19:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Kn5sBNTIKdFP for ; Mon, 30 Aug 2010 19:53:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BB9853A63C9 for ; Mon, 30 Aug 2010 19:53:49 -0700 (PDT) Received: by iwn3 with SMTP id 3so5981175iwn.31 for ; Mon, 30 Aug 2010 19:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hXJGoAvO4EMs+j5XGQst0bwIT8mFTITJNFOVDcARMb0=; b=e2RYb3AVvE43lCNG2yyM6STmlcxtVc0x9JJVONVvLCENICiabHEBnAWSJyveXWPcWi vGZTayBbluit9l7EXq7I2mDaeVkTCuGT/5oGk7qv+1wvBOvpUZizbDqIvtTMBtmlPhZ4 0DdwUZx3MRsnmwtOfD3JM0KhNwlBp1z7o5Dlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lry6sn5/q4Id+fj+53KN74f6WLO7b2PeTodL+vYbKlIXBvLuNyjQlUISGPj+2bD8Js qTZIs0G8kBWA7Xd02jpRwhCW3wxeaamPnzKI4znKUq8i+kVoz8kariH2yPGUTAiAr2lU f8ketDNGV3jGy7BIxCizk5tFQ2dfHlgIcl7qQ= MIME-Version: 1.0 Received: by 10.231.161.68 with SMTP id q4mr6144767ibx.79.1283223260577; Mon, 30 Aug 2010 19:54:20 -0700 (PDT) Received: by 10.231.153.146 with HTTP; Mon, 30 Aug 2010 19:54:20 -0700 (PDT) In-Reply-To: <9837C711-82F3-4B25-8E19-DF3287F7897D@gmail.com> References: <9837C711-82F3-4B25-8E19-DF3287F7897D@gmail.com> Date: Tue, 31 Aug 2010 10:54:20 +0800 Message-ID: From: Hui Deng To: Margaret Wasserman Content-Type: multipart/alternative; boundary=0050450140b59d3fdc048f15b234 Cc: mif@ietf.org, rdroms@cisco.com Subject: Re: [mif] Recharter discussion - update X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 02:53:51 -0000 --0050450140b59d3fdc048f15b234 Content-Type: text/plain; charset=ISO-8859-1 Hi Margaret, Thanks, that was copy past mistake, others have been updated together with Pierrick. Regards, -Hui 2010/8/30 Margaret Wasserman > > Hi Hui, > > > On Aug 30, 2010, at 4:59 AM, Hui Deng wrote: > >> >> 1) Split-DNS solution: >> a specification of DHCPv6 options allowing client nodes to perform >> route table configuration, to avoid all flows being led to the >> default route." >> > > This does not seem like the right text for Split DNS. Could this be a > cut-and-paste error? > > This section previously said: > > "a specification for describing a way for a network to communicate to > nodes information required to perform advanced DNS server selection > in split-DNS deployments. The specification shall describe the > information to be delivered for nodes and the protocol to be used > for delivery." > > > >> 2) DHCPv6 routing configuration: >> a specification of an option to DHCPv6 to inform hosts information >> required to perform advanced routing table configuration, to avoid >> the all flows being led to the default route. >> > > I like the wording you had included above better: > > > a specification of DHCPv6 options allowing client nodes to perform >> route table configuration, to avoid all flows being led to the >> default route." >> > > I would make one change though: s/led/sent > > > >> 3) MIF API: >> an abstract API describing how applications can exploit additional >> features of multiple interface enabled stack. While MIF >> does not need any application changes, this API could provide additional >> services >> to MIF related functions, such as first-hop selection, source address >> selection, DNS >> selection, etc. >> > > I don't feel comfortable the use of "MIF" as a noun, as though it were a > protocol... Maybe the second sentence could say: > > "While no changes are needed for applications to run on multiple interface > hosts, this API could provide additional services to applications running on > multiple interface hosts, such as..." > > I would also reword a couple of the milestones: > > > Goals and Milestones >> Nov 2010: Initial WG draft on Split-DNS solution >> Nov 2010: Initial WG draft on DHCPv6 option for routing configuration >> Nov 2010: Initial WG draft on MIF API extension. >> Nov 2011: Submit Split-DNS solution to IESG for publication as >> a Proposed Standard RFC >> Nov 2011: Submit DHCPv6 extension solution to IESG for publication as a >> Proposed Standard RFC >> > > s/extension solution/routing configuration option > > > Nov 2011: Submit MIF API extension solution to IESG for publication >> as an Informational RFC >> > > s/MIF API extension solution/abstract MIF API description > > Let me know what you think. > > Margaret > > > --0050450140b59d3fdc048f15b234 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Margaret,

=A0

Thanks, that was copy past mistake,

others have been updated together with Pierrick.

=A0

Regards,

=A0

-Hui

2010/8/30 Margaret Wasserman &= lt;margaretw42@gmail.com>

Hi Hui,=20

On Aug 30, 2010, at 4:59 AM, Hui Deng wrote:

1) Split-DNS solution:
a = specification of DHCPv6 options allowing client nodes to perform
route t= able configuration, to avoid all flows being led to the
default route."

This does not seem like the = right text for Split DNS. =A0Could this be a cut-and-paste error?

Th= is section previously said:

"a specification for describing a w= ay for a network to communicate to
nodes information required to perform advanced DNS server selection
in s= plit-DNS deployments. The specification shall describe the
information t= o be delivered for nodes and the protocol to be used
for delivery."= =20

2) DHCPv6 routing configurat= ion:
a specification of an option to DHCPv6 to inform hosts information<= br> required to perform advanced routing table configuration, to avoid
the a= ll flows being led to the default route.

I like t= he wording you had included above better:=20

a specification of DHCPv6 option= s allowing client nodes to perform
route table configuration, to avoid a= ll flows being led to the
default route."

I would make one change thou= gh: =A0s/led/sent=20

3) MIF API:
an abstract A= PI describing how applications can exploit additional
features of multip= le interface enabled stack. While MIF
does not need any application changes, this API could provide additional se= rvices
to MIF related functions, such as first-hop selection, source add= ress selection, DNS
selection, etc.

I don'= t feel comfortable the use of "MIF" as a noun, as though it were = a protocol... =A0Maybe the second sentence could say:

"While no changes are needed for applications to run on multiple i= nterface hosts, this API could provide additional services to applications = running on multiple interface hosts, such as..."

I would also r= eword a couple of the milestones:=20

Goals and Milestones
Nov 2010= : Initial WG draft on Split-DNS solution
Nov 2010: Initial WG draft on D= HCPv6 option for routing configuration
Nov 2010: Initial WG draft on MIF API extension.
Nov 2011: Submit Split-= DNS solution to IESG for publication as
=A0a Proposed Standard RFC
No= v 2011: Submit DHCPv6 extension solution to IESG for publication as a
=A0Proposed Standard RFC

s/extension solution/rou= ting configuration option=20

Nov 2011: Submit MIF API extensi= on solution to IESG for publication
=A0as an Informational RFC

s/MIF API extension solution/abstract MIF API description

= Let me know what you think.

Margaret

=

--0050450140b59d3fdc048f15b234-- From denghui02@gmail.com Mon Aug 30 19:56:23 2010 Return-Path: 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 6D5F13A6860 for ; Mon, 30 Aug 2010 19:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 rV794NOY4ZzU for ; Mon, 30 Aug 2010 19:56:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 61C633A6452 for ; Mon, 30 Aug 2010 19:56:22 -0700 (PDT) Received: by iwn3 with SMTP id 3so5983407iwn.31 for ; Mon, 30 Aug 2010 19:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=REuVvyRzzT9jLDX497m4EwUKj1gP2kEHdvYH4CFpbp8=; b=DAE1WUI71TiJSzqSl3056nK9VS4MKU5NBsnyis1KqccORH9EN61C2pc16gh5UKU44X w4th+crUeL3jt2Z8qyJv8mLCjZeVDARrzZn7t/9EzeG6NOhLEb8T65RIRO/YN7TFcWOv W9by0OSwvYzts48x1XCaz8XCbQyYVBHP1VAzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Tg7SldkH3GG0PpF0xCast5bM41lFooxkjCmbR3rFjthVz5peXJEu4QoS2gOxP3cwAa /D5Andg2Wi0bMfvcTuz5WjbuFotT7s80RevhEqFG4EyLCjlk9ex9ok00DNoUz2w9wzbs Nz8K6IW+AYcCdZ9dadOQGyI7VlzZBpG6LyB5U= MIME-Version: 1.0 Received: by 10.231.79.77 with SMTP id o13mr6517748ibk.36.1283223412441; Mon, 30 Aug 2010 19:56:52 -0700 (PDT) Received: by 10.231.153.146 with HTTP; Mon, 30 Aug 2010 19:56:52 -0700 (PDT) Date: Tue, 31 Aug 2010 10:56:52 +0800 Message-ID: From: Hui Deng To: Margaret Wasserman Content-Type: multipart/alternative; boundary=001485f872caaa9372048f15bbcf Cc: mif@ietf.org, rdroms@cisco.com Subject: [mif] Recharter discussion - update again X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 02:56:23 -0000 --001485f872caaa9372048f15bbcf Content-Type: text/plain; charset=ISO-8859-1 Hi All Update it again, check below: Regards, -Hui 1) Split-DNS solution: a specification for describing a way for a network to communicate to nodes information required to perform advanced DNS server selection in split-DNS deployments. The specification shall describe the information to be delivered for nodes and the protocol to be used for delivery. 2) DHCPv6 routing configuration: a specification of DHCPv6 options allowing client nodes to perform route table configuration. 3) MIF API: While no changes are needed for applications to run on multiple interface hosts, this API could provide additional services to applications running on hosts attached to multiple provisioning domains. For instance, these services could help in solving first-hop, source address and/or DNS selection issues. Goals and Milestones Nov 2010: Initial WG draft on Split-DNS solution Nov 2010: Initial WG draft on DHCPv6 option for routing configuration Nov 2010: Initial WG draft on MIF API extension. Nov 2011: Submit Split-DNS solution to IESG for publication as a Proposed Standard RFC Nov 2011: Submit DHCPv6 routing configuration option to IESG for publication as a Proposed Standard RFC Nov 2011: Submit MIF API extension solution to IESG for publication as an Informational RFC --001485f872caaa9372048f15bbcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All

=A0

Update it again, check below:

=A0

Regards,

=A0

-Hui

=A0

1) Split-DNS solution:
a specification for describing a way for a = network to communicate to
nodes information required to perform advanced= DNS server selection
in split-DNS deployments. The specification shall = describe the
information to be delivered for nodes and the protocol to be used
for de= livery.
=A0
2) DHCPv6 routing configuration:
a specification of D= HCPv6 options allowing client nodes to perform
route table configuration= .
=A0
3) MIF API:
While no changes are needed for applications to run = on multiple
interface hosts, this API could provide additional services= to
applications running on hosts attached to multiple provisioning domains. For instance, these services could help in solving
first-hop, = source address and/or DNS selection issues.

=A0

=A0Goals and Milestones
Nov 2010: Initial WG draft on Split-DNS sol= ution
Nov 2010: Initial WG draft on DHCPv6 option for routing configurat= ion
Nov 2010: Initial WG draft on MIF API extension.=A0=A0
Nov 2011:= Submit Split-DNS solution to IESG for publication as
=A0a Proposed Standard RFC
Nov 2011: Submit DHCPv6 routing configuration= option to IESG for publication as a
=A0Proposed Standard RFC
Nov 20= 11: Submit MIF API extension solution to IESG for publication
=A0as an I= nformational RFC

--001485f872caaa9372048f15bbcf-- From pierrick.seite@orange-ftgroup.com Tue Aug 31 06:51:57 2010 Return-Path: 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 960033A694E; Tue, 31 Aug 2010 06:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 7cc+uK3nVhvO; Tue, 31 Aug 2010 06:51:56 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id B85293A6995; Tue, 31 Aug 2010 06:51:55 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4E7D2FC4009; Tue, 31 Aug 2010 15:52:10 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 23304FC4019; Tue, 31 Aug 2010 15:51:38 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Aug 2010 15:50:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2010 15:50:58 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620113A04D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C780DA8.7080305@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Next steps on draft-ietf-mif-problem-statement-07.txt Thread-Index: ActGG51kcwHwJ/QXS9KuXfoDpSqCYAC90khQ References: <20100826192451.19395.16476.idtracker@localhost> <4C77CEAA.7060401@piuha.net> <4C780DA8.7080305@viagenie.ca> From: To: , X-OriginalArrivalTime: 31 Aug 2010 13:50:59.0469 (UTC) FILETIME=[8AF4B3D0:01CB4913] Cc: draft-ietf-mif-problem-statement@tools.ietf.org, mif@ietf.org, iesg@ietf.org, rdroms@cisco.com Subject: Re: [mif] Next steps on draft-ietf-mif-problem-statement-07.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 13:51:57 -0000 Hi Jari, I agree with your plan too. We will also take into account comments from = other reviewers (review from Routing Area Directorate, revision of = security considerations,...). BR, Pierrick > -----Message d'origine----- > De=A0: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] > Envoy=E9=A0: vendredi 27 ao=FBt 2010 21:11 > =C0=A0: Jari Arkko > Cc=A0: mif; IESG; Ralph Droms; draft-ietf-mif-problem- > statement@tools.ietf.org > Objet=A0: Re: [mif] Next steps on = draft-ietf-mif-problem-statement-07.txt >=20 > When I first started the -00 draft, the problems were not totally = clear, > and were specifically about multiple interfaces, hence the wg name. = Then > the wg moved to multiple admin/prov domains, then discussions on > mobility, connection manager, etc... In the process, we updated the > document "roughly" only by fixing words in sentences. The doc got lost > in the forest... I guess the problem space to describe has grown = enough > through the discussions of the wg that I somewhat agree with the need = to > revisit and look at a larger edit in order to describe the full scope = of > the problem. >=20 > So I agree with Jari's plan (even if I would have preferred to work on > something else... ;-)). Co-editors will discuss offline on how to do = the > new revision. >=20 > Marc. >=20 > Le 10-08-27 10:41, Jari Arkko a =E9crit : > > We discussed this document today on the IESG call. Two major = comments > > were made. First, Lars Eggert made the point that the document's > > explanation of interface choice based on interface characteristics > > (Problem 3.2 in Section 5) is far too simplistic. Interface speed, = for > > instance, is just one factor among many, and that in reality, > > congestion, path characteristics and perhaps even application = traffic > > patterns would have to be taken into account; most likely you would = not > > know what kind of characteristics you can get before actually using = the > > interface for the task at hand. Interface selection in order to = optimize > > application performance is a very hard problem, perhaps unsolvable = in > > the general case. > > > > Second, Ralph Droms made the point that not all problems associated = with > > the multiple interfaces are merely due to merging node-scoped > > information. Overlapping address space on different interfaces is a > > fundamental problem that cannot be solved through better host > > configuration mechanisms, for instance. The document currently = focuses > > mostly on the configuration part of the problem today. > > > > We also talked quite a bit about what the next steps for resolving = these > > issues are. My opinion is that the document would be most useful = when it > > describes the full scope of the problem. It would be particularly > > valuable to describe the fundamental issues, as that may help us > > understand potential limits of solutions. Here's what I would = suggest > > that we do: > > > > 1. Go through the document and expand/correct it to describe both = the > > configuration merging problem and other fundamental issues around > > multiple interfaces (such as address or name space overlap). > > > > 2. Change the parts of the document that talk aboout interface = selection > > based on characteristics, and point out that for proper selection, = many > > factors have to be considered. > > > > 3. Go through the document and make a clearer statement about what > > problems it discusses are hard. For instance, Section 6 says: > > "Therefore, there is a need to define the appropriate behavior of an = IP > > stack and possibly define protocols to manage these cases." This = needs > > to be expanded in order to explain what issues are solvable through > > configuration object management, and what issues remain as = fundamentally > > hard problems (address space overlap, knowing what throughput the = path > > from one interface will give you, etc). > > > > These changes are extensive, but in my opinion doable. I am sending = the > > document back to the working group in order to make the next = revision, > > and we will be doing a new WGLC/IETF Last Call when the revision is > ready. > > > > Thoughts? Comments? Does this plan work for everyone? > > > > Jari > > > > Ralph's Discuss: > > > >> I have a fundamental problem with the way in which this document > >> characterizes the problems resulting from the simultaneous use of > >> multiple interfaces as all resulting from receiving different > >> configuration objects from different administrative domains. In my > >> opinion, some of the example problems in the document are a result = of > >> other problems inherent with the simlutaneous use of multiple > >> interfaces. This distinction is important because , again in my > >> opinion, there are mif problems which cannot be solved by changes = to > >> the configuration behavior in the host. > >> > >> For example, in section 4.1, the symptom: > >> > >> 4. S1 or S2 has been used to resolve "a.private.example.com" to an > >> [RFC1918] address. Both N1 and N2 are [RFC1918] addressed > >> networks. IPv4 source address selection may face challenges, as > >> due address overlapping the source/destination IP addresses do > >> not necessarily provide enough information for making proper > >> address selection decisions. > >> > >> is inherent in having interfaces connected to networks using > >> overlapping address spaces, and cannot be solved by improvements to > >> the configuration behavior. > >> > >> Similarly in section 4.1: > >> > >> 5. H1 has resolved an FQDN to locally valid IP address when > >> connected to N1. After movement from N1 to N2, the host tries to > >> connect to the same IP address as earlier, but as the address was > >> only locally valid, connection setup fails. Similarly, H1 may > >> have received NXDOMAIN for an FQDN when connected to N1. After > >> movement from N1 to N2, the host should not assume the FQDN > >> continues to be nonexistent. > >> > >> How is this problem caused by configuration objects from different > >> domains? > >> > > > >> I see two ways to address my concern: either be explicit in = limiting > >> the problem statement and mif deliverables to those problems that = can > >> be solved with proper handling of configuration information from > >> multiple admin domains or extend the scope of this document to = include > >> any problems that may result from the disparate environments (IP > >> reachability, DNS resolution, QoS) to which interfaces are = attached. > > > > Lars' Discuss: > > > >> Section 3., paragraph 1: > >>> > 2. Interfaces of a MIF host can provide different > >>> > characteristics (e.g. round-trip time, least cost, better > >>> > bandwidth, etc....). So, user, applications or network > >>> > provider may wish to influence routing to take benefit of > >>> > this heterogeneity. However, with current host > >>> > implementations, neither the Type-of-Service nor path > >>> > characteristics can be taken into account in the routing > >>> > table. > >> > >> DISCUSS: I don't think MIF can solve this problem. Yes, interfaces = are > >> the first hops into *paths* of different characteristics, but what > >> service quality an application sees across a path depends on the > >> destination, the transport protocol in use and the communication > >> patterns of the application. There is nothing here that can be > >> optimized without taking these into account. > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > DTN news service: http://reeves.viagenie.ca > NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From margaretw42@gmail.com Tue Aug 31 10:28:48 2010 Return-Path: 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 690153A683C for ; Tue, 31 Aug 2010 10:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 PMhZvLt0qAof for ; Tue, 31 Aug 2010 10:28:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D8A673A685E for ; Tue, 31 Aug 2010 10:28:46 -0700 (PDT) Received: by fxm18 with SMTP id 18so4715579fxm.31 for ; Tue, 31 Aug 2010 10:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=AZj3ny03dsy/fMmHX3oKPLr37KFVH/GwcmFQcJNdKAQ=; b=qdUxNj/gLbGECmYNFzcd0IsGSt3qCrvr/3iLm4OoAW//YsKtiVrXT3NtMpgp/RWZdr B93voNL9hTakaRaztC3DgHZOZR+fIgLuatLoOG7x7baRzaHLnaar51dQ3o4NCq/3QR6x +m+9SnxyyFu+WlVtE2CSQ23DMYfaspLOLJNhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=aVSTuOAKJkOT7kk458XD+R5vnygQ/N6nPiGKnHjHnHWJi/7OA+7oayBcXamGMJKNmF ulsujhoMClGqXbJJmt3rpDxuE8xM4hS/8iwRk7zJvS6znLZBwY3bqkwI2bpHbwDtxALr 8C9pvG3tkJYDYH/2/7JNwthyK3b95GM5rFEzc= Received: by 10.103.173.17 with SMTP id a17mr599254mup.84.1283275756915; Tue, 31 Aug 2010 10:29:16 -0700 (PDT) Received: from [10.36.0.42] (pool-98-110-155-200.bstnma.fios.verizon.net [98.110.155.200]) by mx.google.com with ESMTPS id s29sm2962528vcr.47.2010.08.31.10.29.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 10:29:15 -0700 (PDT) Message-Id: <3BFC24E4-6F05-461A-A48C-E61348113AB7@gmail.com> From: Margaret Wasserman To: Hui Deng In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 31 Aug 2010 13:29:13 -0400 References: <9837C711-82F3-4B25-8E19-DF3287F7897D@gmail.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 31 Aug 2010 17:53:44 -0700 Cc: mif@ietf.org, rdroms@cisco.com Subject: Re: [mif] Recharter discussion - update X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 17:28:48 -0000 Sounds good, Hui. Thanks for putting this all together! Margaret On Aug 30, 2010, at 10:54 PM, Hui Deng wrote: > Hi Margaret, > > Thanks, that was copy past mistake, > others have been updated together with Pierrick. > > Regards, > > -Hui > > 2010/8/30 Margaret Wasserman > > Hi Hui, > > > On Aug 30, 2010, at 4:59 AM, Hui Deng wrote: > > 1) Split-DNS solution: > a specification of DHCPv6 options allowing client nodes to perform > route table configuration, to avoid all flows being led to the > default route." > > This does not seem like the right text for Split DNS. Could this be > a cut-and-paste error? > > This section previously said: > > "a specification for describing a way for a network to communicate to > nodes information required to perform advanced DNS server selection > in split-DNS deployments. The specification shall describe the > information to be delivered for nodes and the protocol to be used > for delivery." > > > > 2) DHCPv6 routing configuration: > a specification of an option to DHCPv6 to inform hosts information > required to perform advanced routing table configuration, to avoid > the all flows being led to the default route. > > I like the wording you had included above better: > > > a specification of DHCPv6 options allowing client nodes to perform > route table configuration, to avoid all flows being led to the > default route." > > I would make one change though: s/led/sent > > > > 3) MIF API: > an abstract API describing how applications can exploit additional > features of multiple interface enabled stack. While MIF > does not need any application changes, this API could provide > additional services > to MIF related functions, such as first-hop selection, source > address selection, DNS > selection, etc. > > I don't feel comfortable the use of "MIF" as a noun, as though it > were a protocol... Maybe the second sentence could say: > > "While no changes are needed for applications to run on multiple > interface hosts, this API could provide additional services to > applications running on multiple interface hosts, such as..." > > I would also reword a couple of the milestones: > > > Goals and Milestones > Nov 2010: Initial WG draft on Split-DNS solution > Nov 2010: Initial WG draft on DHCPv6 option for routing configuration > Nov 2010: Initial WG draft on MIF API extension. > Nov 2011: Submit Split-DNS solution to IESG for publication as > a Proposed Standard RFC > Nov 2011: Submit DHCPv6 extension solution to IESG for publication > as a > Proposed Standard RFC > > s/extension solution/routing configuration option > > > Nov 2011: Submit MIF API extension solution to IESG for publication > as an Informational RFC > > s/MIF API extension solution/abstract MIF API description > > Let me know what you think. > > Margaret > > >