From pierrick.seite@orange-ftgroup.com Mon Apr 4 02:07:01 2011 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 73C3F3A6908 for ; Mon, 4 Apr 2011 02:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=0.202, 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 LY7BcFv9si0u for ; Mon, 4 Apr 2011 02:06:53 -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 AEA023A6940 for ; Mon, 4 Apr 2011 02:06:52 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B890A8C000D; Mon, 4 Apr 2011 11:09:06 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8712D8C000C; Mon, 4 Apr 2011 11:09:06 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 11:08:34 +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, 4 Apr 2011 11:08:32 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462019D519B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] MIF and SCTP Thread-Index: AcvvgFGfSWCN8JhoSDiv/RS+pWYDxgDJ4mZw References: From: To: , X-OriginalArrivalTime: 04 Apr 2011 09:08:34.0351 (UTC) FILETIME=[E01AE3F0:01CBF2A7] Cc: mif@ietf.org Subject: Re: [mif] MIF and SCTP 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, 04 Apr 2011 09:07:01 -0000 Hi, The problem statement is not expected to deal with SCTP use-case. Now, = when translating your problem into a generic routing problem, it seems = that the issue is covered by 4.2/bullet 2 (examples given are not = supposed to be exhaustive). Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Mikael Abrahamsson > Envoy=E9=A0: jeudi 31 mars 2011 10:48 > =C0=A0: Scott Brim > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] MIF and SCTP >=20 > On Thu, 31 Mar 2011, Scott Brim wrote: >=20 > > Mikael (Mike?), > > > > If I understand correctly, you are looking for a way that your > > transport function can control which interface a packet goes out on. > > How to do that would be OS-specific. When you suggest two routing > > tables, I guess you want that because otherwise your OS won't know > > that it's okay to send the packet out a particular interface at all. >=20 > I want the multi-NIC host to use the strong host model. >=20 > > It's not an SCTP problem -- it's a problem with SCTP's environment. = I > > think you should send specific text for the MIF drafts, but about = the > > problem, not your proposed solution (since it is neither a problem = nor > > a current practice). >=20 > I can write text if someone can give guidance as to where my text = might > fit in. >=20 > It can be argued that my case is covered in > = 4.2, > but it doesn't include the traffic separation case, only ingress = filtering > case. >=20 > Is this a good place to add text to? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From phdgang@gmail.com Tue Apr 5 08:17:03 2011 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 2480D28C0EC for ; Tue, 5 Apr 2011 08:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 wEN3+Sxdvdrk for ; Tue, 5 Apr 2011 08:17:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6CB233A6949 for ; Tue, 5 Apr 2011 08:17:02 -0700 (PDT) Received: by vxg33 with SMTP id 33so442474vxg.31 for ; Tue, 05 Apr 2011 08:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tp0HDrbSVqpB1ZW2IaBTp2dWPclV9vN1KOku+ga04mo=; b=t1mO20miJBWdARx9rQuMsu9gRBtI+Cr6VcmMW90MdRL9HExJAQnUh0IyCEop6rCvfV vKsTVK1rNk6peVFV7Q1h3JrbMi7gR5UhCqJCOiEJoteN4rQWx83p1gJ+ow5W+ZeVO9fs hsRgy+qRlof+F8KKnJAEHFWoF6f5UgEPcXIgs= 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=Qq3InWc0x49pUWleN8WgeikJX46R4HfQUHSOkWztUZPvh4224mF1iA4c5SYtyHEScj WOzF31vk/RBDDFEHiFhD2mlLOnKbmMfmab8k8EuRVQCkoZIIfh+QJBG1qPb5Dek1Yz2X D9xjgvZ/qTHACxszLwdnShtT5BNvIUJrj4mfQ= MIME-Version: 1.0 Received: by 10.52.166.39 with SMTP id zd7mr7066517vdb.311.1302016725450; Tue, 05 Apr 2011 08:18:45 -0700 (PDT) Received: by 10.52.164.132 with HTTP; Tue, 5 Apr 2011 08:18:45 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962014D2E@008-AM1MPN1-036.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962014D2E@008-AM1MPN1-036.mgdnok.nokia.com> Date: Tue, 5 Apr 2011 23:18:45 +0800 Message-ID: From: GangChen To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 05 Apr 2011 15:17:03 -0000 Hello Teemu, Please see reply in line. Some thoughts updates have been included according to the meeting discussion. 2011/3/27, teemu.savolainen@nokia.com : > Hi, > > This is interesting work. Couple of questions: > > Is the value of I initially zero for any destination/hostname that has not > yet been connected to? [Gang] The value of I is supposed to be zero initially in preliminary algorithm proposal. > draft-ietf-mif-dhcpv6-route-option and RFC4191 allow definition of specific > routes. In the presence of specific routes it sounds, for me at least, > somewhat odd to send connection attempts via all interfaces. What about > incrementing I for a destination address that matches a more specific route? > Hence initial connection attempt would be sent over the interface that has > matching route and other interfaces would be tried only if no reply on the > preferred one? [Gang] We could take routing information into account for computing value I. Also, I have noticed there are several preconditions impacting on value I, like interface cost, higher layer service demanding, etc. All preconditions would contribute to value I computations. I guess we need to formulate a function to reflect all criteria. Multiple rules make algorithm complicated. I'm still working on modeling the different interface behavior based on several preconditions. Any suggestion about this? > How does the value of I relate to time? (i.e. if I is -1 does the node wait > 10ms before trying corresponding less-preferred interface). [Gang] How about absolute value of I*10 milliseconds which is in line with original Happy Eyeballs proposal > Why would the DNS query be sent over all interfaces? Is it because "I" for a > destination name is initially a zero? Like in routing case, if Improved DNS > Server Selection is in play, would the "I" be nonzero for those interfaces > over which DNS suffix matching the requested name has been received on? [Gang] I think that has same situation with second comments. Best Regards Gang From phdgang@gmail.com Tue Apr 5 08:37:15 2011 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 5E5C93A694C for ; Tue, 5 Apr 2011 08:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=-0.360, 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 XeHBenjndSip for ; Tue, 5 Apr 2011 08:37:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 7A0283A68E8 for ; Tue, 5 Apr 2011 08:37:14 -0700 (PDT) Received: by vxg33 with SMTP id 33so462782vxg.31 for ; Tue, 05 Apr 2011 08:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GqA85AnJgrp4C71Fw1T5WoEDfzxQHL3DzkJ1K7aCiEI=; b=lfRODArFxEp2hx8DaRYav/vsVJpuc392h98T6XL/Li3FuPAwsfR+HqPXqw3BKH35GZ p+BukHRbDXmsA80Vo0GSXwMh5hlw6qyX5rsgxV9lDbjGFLn7hzZgb2exTQrH+nCQL/wq eWkx4WzPinQjeVfXv6xnC+TJK/Aup9gi08K0k= 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=CfgqOf82gtv8XlMA2EEBhZ5S8/yCCKg3U/0Nm6gK8/rdsqM+7cnYi6LctYhRWaf7DI tNSPWs4LOjpddBaOOG9lujXUJl2e84K2Ws2oDryX1BRLhypViF1r3QQfBRgSukjkG3xj 1gKpKGgUU6fpUMPJy8GntGyAaBOp//oQOWmXo= MIME-Version: 1.0 Received: by 10.52.95.211 with SMTP id dm19mr6495196vdb.71.1302017937594; Tue, 05 Apr 2011 08:38:57 -0700 (PDT) Received: by 10.52.164.132 with HTTP; Tue, 5 Apr 2011 08:38:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Apr 2011 23:38:57 +0800 Message-ID: From: GangChen To: Scott Brim Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 05 Apr 2011 15:37:15 -0000 Hello Scott, Please see my reply inline. 2011/3/28, Scott Brim : > First, there are a lot of issues that go into making a choice between > interfaces. The ones I can think of immediately are interface cost, policy > rules, higher layer services sought, and real goodput measurement over time. > A simple integer preference for using a particular interface to reach a > particular prefix, based only on how fast a SYNACK comes back, cannot > reflect those. [Gang] Agree. The different interfaces may have different policies, so it is not only the connectivity but also policy. > I suspect that it would be better do this in two stages: first choose a set > of interfaces based on other criteria (like those listed above), and then > run this draft's mechanism on that set. [Gang] Yes. In first stage, multiple preconditions should be taken into account. The problem is how to formulate a function to accurately reflect these impacts. > > Second, I can't resist pointing out that goodput over time is more > significant than initial connectivity so in the long run we're better off > with MPTCP or SCTP and using real data packets on those interfaces. [Gang] I guess this goes beyond the scope of this draft. > Thanks... Scott > > - use multipathing (SCTP CMT, MPTCP) to determine > > I have concerns about the usefulness. I like Happy Eyeballs very much in its > original context. However, in the original context of Happy Eyeballs (IPv4 > vs IPv6, TCP vs SCTP), the goals are clear, the choices are clear, and the > metrics for the decision are clear. It's purely a problem of devising a good > mechanism to enable making a technical choice. However, in this case, t [Gang] Regarding the usefulness, Happy Eyeballs Extension could allow traffic falls back to suboptimal interface, when there are accidental problems happened on the optimal interface. Best Regards Gang From pierrick.seite@orange-ftgroup.com Wed Apr 6 06:37:22 2011 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 4198A28C0F5 for ; Wed, 6 Apr 2011 06:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 qZ+VWX4lRhul for ; Wed, 6 Apr 2011 06:37:21 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id AF78928C0E4 for ; Wed, 6 Apr 2011 06:37:20 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98B116F8013; Wed, 6 Apr 2011 15:39:37 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8DC386C0001; Wed, 6 Apr 2011 15:39:37 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 15:39:03 +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, 6 Apr 2011 15:39:02 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: Acvzp5bpMLQqIv1lStO7KGiHngVtHAAuFY4A References: From: To: , X-OriginalArrivalTime: 06 Apr 2011 13:39:03.0342 (UTC) FILETIME=[FE29E4E0:01CBF45F] Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 06 Apr 2011 13:37:22 -0000 Hi, Just a brief comment on happy eyeballs I-D. Basically, I'll second Scott = on complexity for choosing an interface. I agree that interface selection can be made using an interface = weighting method. However, weight computation needs to take into account = various criteria: obviously network access condition, but also the type = of application (applications may have different QoS requirements), user = preferences and operator policies, interface cost, L2/L3 = authentication/security capabilities, and so on... Interface weight must = be computed in advance but also be recomputed during session; network = condition may change during the session and interface reselection = triggered (if mobility supported). IMHO, the proposed algorithm is too = simplistic with regards to interface selection problem in MIF context. = Usually, interface selection is performed by a connection manager having = interfaces to different layers. I'm also concerned with DNS requests sent over all interfaces. IMHO, = this is a waste of resource; besides draft-ietf-mif-dns-server-selection = clearly states that this practice should be avoided.=20 Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > GangChen > Envoy=E9=A0: mardi 5 avril 2011 17:39 > =C0=A0: Scott Brim > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] Happy Eyeballs Extension for MIF >=20 > Hello Scott, >=20 > Please see my reply inline. >=20 > 2011/3/28, Scott Brim : > > First, there are a lot of issues that go into making a choice = between > > interfaces. The ones I can think of immediately are interface cost, > policy > > rules, higher layer services sought, and real goodput measurement = over > time. > > A simple integer preference for using a particular interface to = reach a > > particular prefix, based only on how fast a SYNACK comes back, = cannot > > reflect those. >=20 > [Gang] Agree. The different interfaces may have different policies, so > it is not only the connectivity but also policy. >=20 > > I suspect that it would be better do this in two stages: first = choose a > set > > of interfaces based on other criteria (like those listed above), and > then > > run this draft's mechanism on that set. >=20 > [Gang] Yes. In first stage, multiple preconditions should be taken > into account. > The problem is how to formulate a function to accurately reflect these > impacts. >=20 > > > > Second, I can't resist pointing out that goodput over time is more > > significant than initial connectivity so in the long run we're = better > off > > with MPTCP or SCTP and using real data packets on those interfaces. >=20 > [Gang] I guess this goes beyond the scope of this draft. >=20 > > Thanks... Scott > > > > - use multipathing (SCTP CMT, MPTCP) to determine > > > > I have concerns about the usefulness. I like Happy Eyeballs very = much in > its > > original context. However, in the original context of Happy Eyeballs > (IPv4 > > vs IPv6, TCP vs SCTP), the goals are clear, the choices are clear, = and > the > > metrics for the decision are clear. It's purely a problem of = devising a > good > > mechanism to enable making a technical choice. However, in this = case, t >=20 > [Gang] Regarding the usefulness, Happy Eyeballs Extension could allow > traffic falls back to suboptimal interface, when there are accidental > problems happened on the optimal interface. >=20 > Best Regards >=20 > Gang > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Wed Apr 6 13:24:18 2011 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 597313A69C3 for ; Wed, 6 Apr 2011 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.132 X-Spam-Level: X-Spam-Status: No, score=-106.132 tagged_above=-999 required=5 tests=[AWL=0.467, 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 Of4jqCNu5c08 for ; Wed, 6 Apr 2011 13:24:17 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 7B3733A6452 for ; Wed, 6 Apr 2011 13:24:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTZzMWFs7vrYwR0QzH++pl6PQJWmoS7GY@postini.com; Wed, 06 Apr 2011 13:26:01 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 973C21B8715 for ; Wed, 6 Apr 2011 13:26:00 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id 8C3D5190065 for ; Wed, 6 Apr 2011 13:26:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.18] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 13:26:00 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1084) From: Ted Lemon In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> Date: Wed, 6 Apr 2011 16:25:57 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 06 Apr 2011 20:24:18 -0000 On Apr 6, 2011, at 9:39 AM, = wrote: > I'm also concerned with DNS requests sent over all interfaces. IMHO, = this is a waste of resource; besides draft-ietf-mif-dns-server-selection = clearly states that this practice should be avoided.=20 The DNS server selection draft is a point solution to a very restricted = problem: how to deal with situations where DNS servers on different = interfaces will give different answers to queries for the same name. = It is not a general solution. In principal you are right that it would be better not to send duplicate = queries if the answers are going to be (as they should be) the same. = However, it is not the case that answers will in fact always be the = same, and there are common real-world scenarios where they are not. = One goal of this working group is (or at least IMHO should be) to = address those common real-world scenarios. Also, when you say that sending DNS requests is a waste of resources, I = think it's important to be clear about exactly what resources you think = are being wasted. E.g., are you talking about battery, or bandwidth, = or server utilization (or some other option I didn't think of:)? From pierrick.seite@orange-ftgroup.com Thu Apr 7 02:36:35 2011 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 164D528C0CF for ; Thu, 7 Apr 2011 02:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 zz6vRMdtonT2 for ; Thu, 7 Apr 2011 02:36:34 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 3503E3A69F4 for ; Thu, 7 Apr 2011 02:36:34 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 92AFE6C8003; Thu, 7 Apr 2011 11:38:51 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 878FE6C0001; Thu, 7 Apr 2011 11:38:51 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 11:38:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 11:38:16 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: Acv0mO2HN/UIm6TmT7Kj80N64RsaUgAbYDpQ References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 07 Apr 2011 09:38:17.0384 (UTC) FILETIME=[861D6280:01CBF507] Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 09:36:35 -0000 Hi Ted, [snip] >=20 > Also, when you say that sending DNS requests is a waste of resources, I > think it's important to be clear about exactly what resources you think > are being wasted. E.g., are you talking about battery, or bandwidth, or > server utilization=20 This is what I've in mind actually. I'm particularly concerned about wasting bandwidth on cellular network where bandwidth, specially for data services, is limited. Now, I don't know how much traffic is generated with an approach ala eyeballs. Br, Pierrick (or some other option I didn't think of:)? >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Thu Apr 7 05:04:45 2011 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 6288D3A6A03 for ; Thu, 7 Apr 2011 05:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 hxdCAY3LLEmj for ; Thu, 7 Apr 2011 05:04:44 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 786653A68AC for ; Thu, 7 Apr 2011 05:04:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ2ow602iudRXqJB4hADZqh8yUy6uog6@postini.com; Thu, 07 Apr 2011 05:06:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 37469F806F for ; Thu, 7 Apr 2011 05:06:27 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1E069190068; Thu, 7 Apr 2011 05:06:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 05:06:26 -0700 From: Ted Lemon To: "pierrick.seite@orange-ftgroup.com" Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL7Srehy09XOnCn0izXgjMvZZjpZRP6iqAgAFw0wCAAHGxgIAA3V8A//+0DpU= Date: Thu, 7 Apr 2011 12:06:26 +0000 Message-ID: <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> , <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 12:04:45 -0000 On Apr 7, 2011, at 5:38 AM, "pierrick.seite@orange-ftgroup.com" wrote: > I'm particularly concerned about > wasting bandwidth on cellular network where bandwidth, specially for > data services, is limited So specifically to what cell networks where a DNS packet is going to repres= ent a substantial amount of traffic that we need to optimize away? From Ted.Lemon@nominum.com Thu Apr 7 05:21:54 2011 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 6D3AC3A6922 for ; Thu, 7 Apr 2011 05:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZdiNqCDzpEcn for ; Thu, 7 Apr 2011 05:21:53 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id BE4773A6920 for ; Thu, 7 Apr 2011 05:21:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ2sxXoykH2k/QdTBaiZATbbJHdzhdlt@postini.com; Thu, 07 Apr 2011 05:23:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 77256F80D0 for ; Thu, 7 Apr 2011 05:23:33 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6BE62190060; Thu, 7 Apr 2011 05:23:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 05:23:33 -0700 From: Ted Lemon To: Ted Lemon Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL7Srehy09XOnCn0izXgjMvZZjpZRP6iqAgAFw0wCAAHGxgIAA3V8A//+0DpWAAATGJA== Date: Thu, 7 Apr 2011 12:23:32 +0000 Message-ID: <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> , <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> In-Reply-To: <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 12:21:54 -0000 On Apr 7, 2011, at 8:06 AM, "Ted Lemon" wrote: > So specifically to what cell networks where a DNS packet is going to repr= esent a substantial amount of traffic that we need to optimize away? Wow, that was hard for me to parse. Probably impossible for anyone else. = The question I am asking is, what cell networks exist where in practice DN= S traffic actually represents a significant load that we need to eliminate?= I could see this being an issue if we were talking about, say, video tra= ffic, but otherwise it seems like a premature optimization. = From fred@cisco.com Thu Apr 7 05:31:40 2011 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 B6CA028B56A for ; Thu, 7 Apr 2011 05:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Pmu9ICVfU-Ir for ; Thu, 7 Apr 2011 05:31:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9A0F23A690F for ; Thu, 7 Apr 2011 05:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1275; q=dns/txt; s=iport; t=1302179604; x=1303389204; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=ZudtY7BnqCYIkbVvl2kCdmzTer3AtTcQqyc1vMpITw8=; b=RvKqksvZA9kniNm4W/bLJTPY9cxHfuo+jBe/ECHlBnVVk5uAiOv8VUA+ y0/QQQBuGh6maRd6YOh+LD18hIzK+cTLJWo/Q/FvBO7TNKgas1OH5Oca3 Wlto/H9YaGPesacyLw3KJa6BecSKoApQDEjXJHVGQA5GYQfZs1SHbdViD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUEACKunU2Q/khLgWdsb2JhbACmBBQBAQsLJiWIeZt8nGWFbQSNRYNo X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="82609032" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2011 12:33:23 +0000 Received: from Freds-Computer.local (ams3-vpn-dhcp6167.cisco.com [10.61.88.22]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37CXIRu006619; Thu, 7 Apr 2011 12:33:23 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 07 Apr 2011 14:33:23 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 07 Apr 2011 14:33:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> Date: Thu, 7 Apr 2011 14:33:08 +0200 Message-Id: <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> , <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 12:31:40 -0000 On Apr 7, 2011, at 2:23 PM, Ted Lemon wrote: > On Apr 7, 2011, at 8:06 AM, "Ted Lemon" wrote: >=20 >> So specifically to what cell networks where a DNS packet is going to = represent a substantial amount of traffic that we need to optimize away? >=20 > Wow, that was hard for me to parse. Probably impossible for anyone = else. The question I am asking is, what cell networks exist where in = practice DNS traffic actually represents a significant load that we need = to eliminate? I could see this being an issue if we were talking = about, say, video traffic, but otherwise it seems like a premature = optimization.=20 I started to reply "networks designed primarily for SMS as opposed to = providing 'mobile internet' applications". I would agree that different = networks are designed with different levels of bandwidth. In 3GPP, I = share 2 MBPS with everyone else in my cell. In its predecessor, I share = 56 KBPS with everyone else in my cell. In GSM, I share 9.6. Note that I = once worked at a company that had ~100 people behind a single 9.6 link, = and the proto-Internet of the early-mid 1980's was entirely 56 KBPS.=20 The other thought that went through my mind is "commercially irrelevant = networks". From Ted.Lemon@nominum.com Thu Apr 7 05:50:42 2011 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 230103A6A0E for ; Thu, 7 Apr 2011 05:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 AhPsmLw21XHE for ; Thu, 7 Apr 2011 05:50:39 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 697AE3A692D for ; Thu, 7 Apr 2011 05:50:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ2zh//xP09/Ru8dCEfanL+ebopifK4T@postini.com; Thu, 07 Apr 2011 05:52:24 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 181ED1B8884 for ; Thu, 7 Apr 2011 05:52:23 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 08C0E190068; Thu, 7 Apr 2011 05:52:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 05:52:22 -0700 From: Ted Lemon To: Fred Baker Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL7Srehy09XOnCn0izXgjMvZZjpZRP6iqAgAFw0wCAAHGxgIAA3V8A//+0DpWAAATGJIAAeAgA//+QBgo= Date: Thu, 7 Apr 2011 12:52:21 +0000 Message-ID: <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> , <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com>, <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> In-Reply-To: <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 12:50:42 -0000 On Apr 7, 2011, at 8:33 AM, "Fred Baker" wrote: > The other thought that went through my mind is "commercially irrelevant n= etworks". Yes, that's exactly what I was thinking too. Also, "networks that will not= exist by the time we produce a spec.". IP over SMS sounds intriguing, but= at the rate messages are charged at least in the US, it's likely prohibiti= vely expensive. = From pierrick.seite@orange-ftgroup.com Thu Apr 7 05:55:05 2011 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 4B8C63A6A11 for ; Thu, 7 Apr 2011 05:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, 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 ZZZUlciBvlEs for ; Thu, 7 Apr 2011 05:55:04 -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 45F723A6A0F for ; Thu, 7 Apr 2011 05:55:04 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 75AA7FC4003; Thu, 7 Apr 2011 14:56:55 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 6AA59FC4001; Thu, 7 Apr 2011 14:56:55 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 14:56:47 +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: Thu, 7 Apr 2011 14:56:46 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A15BDA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL7Srehy09XOnCn0izXgjMvZZjpZRP6iqAgAFw0wCAAHGxgIAA3V8A//+0DpWAAATGJIAAAHiw References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr>, <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> From: To: X-OriginalArrivalTime: 07 Apr 2011 12:56:47.0929 (UTC) FILETIME=[415A5290:01CBF523] Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 12:55:05 -0000 > -----Message d'origine----- > De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Envoy=E9=A0: jeudi 7 avril 2011 14:24 > =C0=A0: Ted Lemon > Cc=A0: SEITE Pierrick RD-RESA-REN; mif@ietf.org > Objet=A0: Re: [mif] Happy Eyeballs Extension for MIF >=20 > On Apr 7, 2011, at 8:06 AM, "Ted Lemon" wrote: >=20 > > So specifically to what cell networks where a DNS packet is going to > represent a substantial amount of traffic that we need to optimize = away? >=20 > Wow, that was hard for me to parse. Probably impossible for anyone = else. > The question I am asking is, what cell networks exist where in = practice > DNS traffic actually represents a significant load that we need to > eliminate? I could see this being an issue if we were talking about, = say, > video traffic, but otherwise it seems like a premature optimization. You're right. Mobile operators have to face dramatic traffic increase; = of course this is not due to DNS traffic :-). I don't know if we really = have an issue when many 3GPP subscribers send unnecessary DNS requests = (i.e. when the non-3GPP interface is selected)... but I just meant that = some access networks (typically mobile/3gpp) have limited bandwidth = (while data usage is increasing), so it is preferable to use this = bandwidth for useful traffic instead of sending unnecessary signalling = (as a general principle). Generally, a mobile operator tries to optimize = signalling load and overhead.=20 Pierrick. From pierrick.seite@orange-ftgroup.com Thu Apr 7 06:07:59 2011 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 17EAB3A69BD for ; Thu, 7 Apr 2011 06:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 tinF+iExl5ry for ; Thu, 7 Apr 2011 06:07:57 -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 4E19C3A6910 for ; Thu, 7 Apr 2011 06:07:57 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 35660778004; Thu, 7 Apr 2011 15:15:52 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 2D7BD778003; Thu, 7 Apr 2011 15:15:52 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 15:09:41 +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: Thu, 7 Apr 2011 15:09:40 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL7Srehy09XOnCn0izXgjMvZZjpZRP6iqAgAFw0wCAAHGxgIAA3V8A//+0DpWAAATGJIAAeAgA//+QBgqAAAJ2EA== References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr>, <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com><7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com>, <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> From: To: , X-OriginalArrivalTime: 07 Apr 2011 13:09:41.0132 (UTC) FILETIME=[0E37BCC0:01CBF525] Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 13:07:59 -0000 > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de Ted > Lemon > Envoy=E9=A0: jeudi 7 avril 2011 14:52 > =C0=A0: Fred Baker > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] Happy Eyeballs Extension for MIF >=20 > On Apr 7, 2011, at 8:33 AM, "Fred Baker" wrote: >=20 > > The other thought that went through my mind is "commercially = irrelevant > networks". >=20 > Yes, that's exactly what I was thinking too. Also, "networks that = will > not exist by the time we produce a spec.". IP over SMS sounds = intriguing, Well, I don't know what "IP over SMS" is... but, each month, data = traffic on GPRS network increases significantly: web browsing of course, = but also video streaming (a lot). It's surprising, but some people are = watching TV on mobile at home. But we are digressing :-). > but at the rate messages are charged at least in the US, it's likely > prohibitively expensive. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From marc.blanchet@viagenie.ca Thu Apr 7 06:17:23 2011 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 573993A690F for ; Thu, 7 Apr 2011 06:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 L0j1cVhyIjiH for ; Thu, 7 Apr 2011 06:17:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0CFB93A690D for ; Thu, 7 Apr 2011 06:17:22 -0700 (PDT) Received: from mbl.lan (unknown [IPv6:2607:f2c0:f00e:6100:5ab0:35ff:fe6a:294a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AA70321F1F for ; Thu, 7 Apr 2011 09:19:05 -0400 (EDT) Message-ID: <4D9DB9C9.20902@viagenie.ca> Date: Thu, 07 Apr 2011 09:19:05 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: mif@ietf.org References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr>, <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com><7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com>, <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 13:17:23 -0000 Le 11-04-07 09:09, pierrick.seite@orange-ftgroup.com a écrit : > > > >> -----Message d'origine----- >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Ted >> Lemon >> Envoyé : jeudi 7 avril 2011 14:52 >> À : Fred Baker >> Cc : mif@ietf.org >> Objet : Re: [mif] Happy Eyeballs Extension for MIF >> >> On Apr 7, 2011, at 8:33 AM, "Fred Baker" wrote: >> >>> The other thought that went through my mind is "commercially irrelevant >> networks". >> >> Yes, that's exactly what I was thinking too. Also, "networks that will >> not exist by the time we produce a spec.". IP over SMS sounds intriguing, > > Well, I don't know what "IP over SMS" is... but, each month, data traffic on GPRS network increases significantly: web browsing of course, but also video streaming (a lot). It's surprising, but some people are watching TV on mobile at home. But we are digressing :-). actually not: if users are streaming video over mobile networks, then the cost of few additional dns packets is zero. Marc. > >> but at the rate messages are charged at least in the US, it's likely >> prohibitively expensive. >> _______________________________________________ >> 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 -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From pierrick.seite@orange-ftgroup.com Thu Apr 7 06:21:46 2011 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 DFD223A690F for ; Thu, 7 Apr 2011 06:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.173, 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 pxjBc2+Zaacf for ; Thu, 7 Apr 2011 06:21:45 -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 6BE993A6910 for ; Thu, 7 Apr 2011 06:21:45 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6DAC38C000E; Thu, 7 Apr 2011 15:24:02 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 66E578B800D; Thu, 7 Apr 2011 15:24:02 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 15:23:29 +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: Thu, 7 Apr 2011 15:23:28 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A15C06@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D9DB9C9.20902@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: Acv1JnQngZ1MShYjQUiM8KMosQMr6QAACN6g References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr>, <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com><7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com>, <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com><843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> From: To: , X-OriginalArrivalTime: 07 Apr 2011 13:23:29.0518 (UTC) FILETIME=[FBF968E0:01CBF526] Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 13:21:47 -0000 > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de Marc > Blanchet > Envoy=E9=A0: jeudi 7 avril 2011 15:19 > =C0=A0: mif@ietf.org > Objet=A0: Re: [mif] Happy Eyeballs Extension for MIF >=20 > Le 11-04-07 09:09, pierrick.seite@orange-ftgroup.com a =E9crit : > > > > > > > >> -----Message d'origine----- > >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Ted > >> Lemon > >> Envoy=E9 : jeudi 7 avril 2011 14:52 > >> =C0 : Fred Baker > >> Cc : mif@ietf.org > >> Objet : Re: [mif] Happy Eyeballs Extension for MIF > >> > >> On Apr 7, 2011, at 8:33 AM, "Fred Baker" wrote: > >> > >>> The other thought that went through my mind is "commercially > irrelevant > >> networks". > >> > >> Yes, that's exactly what I was thinking too. Also, "networks that = will > >> not exist by the time we produce a spec.". IP over SMS sounds > intriguing, > > > > Well, I don't know what "IP over SMS" is... but, each month, data > traffic on GPRS network increases significantly: web browsing of = course, > but also video streaming (a lot). It's surprising, but some people are > watching TV on mobile at home. But we are digressing :-). >=20 > actually not: if users are streaming video over mobile networks, then > the cost of few additional dns packets is zero. >=20 For that user, and that connection, yes. But what about the cost for the = operator when thousands of users send DNS packets on 3GPP, just to be = sure they can use the wifi network...? > Marc. >=20 > > > >> but at the rate messages are charged at least in the US, it's = likely > >> prohibitively expensive. > >> _______________________________________________ > >> 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 >=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 Implementation: http://postellation.viagenie.ca > NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Thu Apr 7 06:38:03 2011 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 BEBAF3A6918 for ; Thu, 7 Apr 2011 06:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 nsvKzCN6i8mf for ; Thu, 7 Apr 2011 06:38:03 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id D4D2E3A6916 for ; Thu, 7 Apr 2011 06:38:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ2+ogZ5mX4YNBjNsSHnm0rVnDDfnfHU@postini.com; Thu, 07 Apr 2011 06:39:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 35A1E1B86C3 for ; Thu, 7 Apr 2011 06:39:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2AC1C190068; Thu, 7 Apr 2011 06:39:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 06:39:46 -0700 From: Ted Lemon To: "pierrick.seite@orange-ftgroup.com" Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL7Srehy09XOnCn0izXgjMvZZjpZRP6iqAgAFw0wCAAHGxgIAA3V8A//+0DpWAAATGJIAAeAgA//+QBgqAAAJ2EIAAelqAgAABOgD//481yA== Date: Thu, 7 Apr 2011 13:39:46 +0000 Message-ID: References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr>, <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr>, <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com><7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com>, <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com><843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca>, <843DA8228A1BA74CA31FB4E111A5C46201A15C06@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201A15C06@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 13:38:04 -0000 On Apr 7, 2011, at 9:23 AM, "pierrick.seite@orange-ftgroup.com" wrote: > For that user, and that connection, yes. But what about the cost for the = operator when thousands of users send DNS packets on 3GPP, just to be sure = they can use the wifi network...? The problem is that while the scenario you describe does exist, there is no= reliable way to distinguish between this scenario and other scenarios wher= e a failure to use the 3G DNS server will result in a dissatisfactory user = experience. This is why I call it a premature optimization. It's likely tha= t the scenario you are concerned about will actually be largely eliminated = by optimizations like the P/I optimization anyway. It doesn't make sense t= o gunk up the protocol to optimize for this. Control traffic is important, = and we can't presume that it is wasted. = From ajs@shinkuro.com Thu Apr 7 06:54:09 2011 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 375C53A694D for ; Thu, 7 Apr 2011 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 bkndrzOa7HZQ for ; Thu, 7 Apr 2011 06:54:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 814353A68C4 for ; Thu, 7 Apr 2011 06:54:08 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 741AE1ECB41D for ; Thu, 7 Apr 2011 13:55:52 +0000 (UTC) Date: Thu, 7 Apr 2011 09:55:50 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110407135550.GD13162@crankycanuck.ca> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9DB9C9.20902@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 13:54:09 -0000 On Thu, Apr 07, 2011 at 09:19:05AM -0400, Marc Blanchet wrote: > actually not: if users are streaming video over mobile networks, > then the cost of few additional dns packets is zero. Exactly right. To illustrate, the DNSSEC-enabled response for MX for ietf.org that I did just this second reports ;; MSG SIZE rcvd: 1091. Optimizing away DNS traffic is the last place to start. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From pierrick.seite@orange-ftgroup.com Thu Apr 7 06:59:56 2011 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 F1F4328B56A for ; Thu, 7 Apr 2011 06:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.156, 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 CqplAkCNwpB9 for ; Thu, 7 Apr 2011 06:59:55 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 0DC5D3A6A0F for ; Thu, 7 Apr 2011 06:59:55 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 06AC86D8003; Thu, 7 Apr 2011 16:02:13 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id F0CA86C0001; Thu, 7 Apr 2011 16:02:12 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 16:01:38 +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: Thu, 7 Apr 2011 16:01:37 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20110407135550.GD13162@crankycanuck.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: Acv1K4S7wMU0GDukQmWeFFM3rw0QsAAAGCWA References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr><843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr><7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com><7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com><71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com><6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com><843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr><4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> From: To: , X-OriginalArrivalTime: 07 Apr 2011 14:01:38.0785 (UTC) FILETIME=[507BD510:01CBF52C] Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 13:59:56 -0000 > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Andrew Sullivan > Envoy=E9=A0: jeudi 7 avril 2011 15:56 > =C0=A0: mif@ietf.org > Objet=A0: Re: [mif] Happy Eyeballs Extension for MIF >=20 > On Thu, Apr 07, 2011 at 09:19:05AM -0400, Marc Blanchet wrote: > > actually not: if users are streaming video over mobile networks, > > then the cost of few additional dns packets is zero. >=20 > Exactly right. To illustrate, the DNSSEC-enabled response for MX for > ietf.org that I did just this second reports ;; MSG SIZE rcvd: 1091. > Optimizing away DNS traffic is the last place to start. >=20 I couldn't agree more. But it's not the purpose; the concern was about = sending DNS request on interface I1 to finally start the application on = interface I2. > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From marc.blanchet@viagenie.ca Thu Apr 7 07:16:11 2011 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 2623828C129 for ; Thu, 7 Apr 2011 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 FWK84pOglNAN for ; Thu, 7 Apr 2011 07:16:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5F22B28C127 for ; Thu, 7 Apr 2011 07:16:09 -0700 (PDT) Received: from h109.viagenie.ca (unknown [IPv6:2620:0:230:c000:5ab0:35ff:fef4:6fa]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 294DC20BE2 for ; Thu, 7 Apr 2011 10:17:53 -0400 (EDT) Message-ID: <4D9DC790.7000509@viagenie.ca> Date: Thu, 07 Apr 2011 10:17:52 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: mif@ietf.org References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr><843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr><7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com><7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com><71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com><6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com><843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr><4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 14:16:11 -0000 Le 11-04-07 10:01, pierrick.seite@orange-ftgroup.com a écrit : > > >> -----Message d'origine----- >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >> Andrew Sullivan >> Envoyé : jeudi 7 avril 2011 15:56 >> À : mif@ietf.org >> Objet : Re: [mif] Happy Eyeballs Extension for MIF >> >> On Thu, Apr 07, 2011 at 09:19:05AM -0400, Marc Blanchet wrote: >>> actually not: if users are streaming video over mobile networks, >>> then the cost of few additional dns packets is zero. >> >> Exactly right. To illustrate, the DNSSEC-enabled response for MX for >> ietf.org that I did just this second reports ;; MSG SIZE rcvd: 1091. >> Optimizing away DNS traffic is the last place to start. >> > > I couldn't agree more. But it's not the purpose; the concern was about sending DNS request on interface I1 to finally start the application on interface I2. > I understand. but: - I've been working for years with a very humble contribution on trying to restore end2end internet, by helping the ipv6 deployment. reality: even with ipv6, it won't happen. I have no more dreams... - we are in a situation here where we have been engineering mechanisms to establish connections (which was a given before...): STUN/TURN/ICE/Teredo/Nat keepalives/Happy eyeballs/... all of them require extra packets where most are triggers, test packets, etc... and most are at the end not used for the real connection. - so yes this is not pretty. - the fact that some mechanisms may end up sending additional small packets on the wrong interface, 3G or not, does not seem to me in any way a blocker. especially again that modern 3G trafic and bandwidth is many orders of magnitude larger than the little test dns packets. Moreover, about the 3G connection itself, just think about background notification of gaming/facebook/... that are done in the background for the user: maintains the 3G connection up all the time... It is just a consequence of where we are, and yes there are some causalities... Marc. >> A >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> _______________________________________________ >> 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 -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From denghui02@gmail.com Thu Apr 7 07:40:07 2011 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 D39D73A6935 for ; Thu, 7 Apr 2011 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 JuNqgbyPKnJp for ; Thu, 7 Apr 2011 07:40:04 -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 745BB28C129 for ; Thu, 7 Apr 2011 07:40:03 -0700 (PDT) Received: by fxm15 with SMTP id 15so1957830fxm.31 for ; Thu, 07 Apr 2011 07:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pm4fNnF8GDekkij/EXOiOTHRqMMZ35Nf4LjV6W1DOSs=; b=dYMmplo6+1N06kUNq7MrDP6hp9comcdJxkTPzIwIm+NsjncYSsLUcykqWKtKGKO7Zr FQEFIuqelX7ZlurH28m3nFHb+Bhx5cS8Nmrbcb9SilwcUdHm+Y0EQMEb1OLuRRZJkZha 35f0yAlydslz2bLWLN7jQQ3nXdGAp1dVnxjp4= 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=bZ+LUdeC0dA/ggKZPrWJif+2eC81gosWp8DP6X8iTXDPyzAxU4axxn05MQyH2QO174 /hMCvtUHr8dD4S2Jy23m2qmSB3wjE3yvFk+riwzItBDXD+BMk+6UleX671M70a4oRQ+f 0ODYr3FmkjMo3pWgrliQhMw5Np7su8U8bCZoA= MIME-Version: 1.0 Received: by 10.204.154.74 with SMTP id n10mr855541bkw.33.1302187307314; Thu, 07 Apr 2011 07:41:47 -0700 (PDT) Received: by 10.204.17.13 with HTTP; Thu, 7 Apr 2011 07:41:47 -0700 (PDT) In-Reply-To: <4D9DC790.7000509@viagenie.ca> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> <4D9DC790.7000509@viagenie.ca> Date: Thu, 7 Apr 2011 22:41:47 +0800 Message-ID: From: Hui Deng To: Marc Blanchet Content-Type: multipart/alternative; boundary=0015175cf8d4e22d6004a0551bbd Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 14:40:07 -0000 --0015175cf8d4e22d6004a0551bbd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all I try to explain how mobile signal behave, mobile vendors could correct if my explaination is not correct. 1) Compared with real traffic amount, dns resolve signaling is not that much. 2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP is still there but air interface is tentatively released) for 3G connection, if you need send dns resolve message, Mobile has to be waked up, then it will consume lots of air interface signaling, and because the control channel and traffic channel are seperate= d each other in 3G network, those signalings will consume control channel resource of air interface. Anyway, if Mobile is in the stage of connected, it won't consume much about air resource traffic channel. So in summary, it might be an issue for mobile network to send DNS resolve messages through multiple interfaces. thanks -Hui 2011/4/7 Marc Blanchet > Le 11-04-07 10:01, pierrick.seite@orange-ftgroup.com a =E9crit : > > >> >> -----Message d'origine----- >>> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >>> Andrew Sullivan >>> Envoy=E9 : jeudi 7 avril 2011 15:56 >>> =C0 : mif@ietf.org >>> Objet : Re: [mif] Happy Eyeballs Extension for MIF >>> >>> On Thu, Apr 07, 2011 at 09:19:05AM -0400, Marc Blanchet wrote: >>> >>>> actually not: if users are streaming video over mobile networks, >>>> then the cost of few additional dns packets is zero. >>>> >>> >>> Exactly right. To illustrate, the DNSSEC-enabled response for MX for >>> ietf.org that I did just this second reports ;; MSG SIZE rcvd: 1091. >>> Optimizing away DNS traffic is the last place to start. >>> >>> >> I couldn't agree more. But it's not the purpose; the concern was about >> sending DNS request on interface I1 to finally start the application on >> interface I2. >> >> > I understand. but: > - I've been working for years with a very humble contribution on trying t= o > restore end2end internet, by helping the ipv6 deployment. reality: even w= ith > ipv6, it won't happen. I have no more dreams... > - we are in a situation here where we have been engineering mechanisms to > establish connections (which was a given before...): > STUN/TURN/ICE/Teredo/Nat keepalives/Happy eyeballs/... all of them requir= e > extra packets where most are triggers, test packets, etc... and most are = at > the end not used for the real connection. > - so yes this is not pretty. > - the fact that some mechanisms may end up sending additional small packe= ts > on the wrong interface, 3G or not, does not seem to me in any way a block= er. > especially again that modern 3G trafic and bandwidth is many orders of > magnitude larger than the little test dns packets. Moreover, about the 3G > connection itself, just think about background notification of > gaming/facebook/... that are done in the background for the user: maintai= ns > the 3G connection up all the time... > > It is just a consequence of where we are, and yes there are some > causalities... > > Marc. > > > > A >>> >>> -- >>> Andrew Sullivan >>> ajs@shinkuro.com >>> Shinkuro, Inc. >>> _______________________________________________ >>> 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 >> > > > -- > =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 Implementation: http://postellation.viagenie.ca > NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --0015175cf8d4e22d6004a0551bbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
I try to explain how mobile signal=A0 behave, mobile vendors could cor= rect if=A0my explaination=A0is=A0not correct.=A0
1) Compared with real traffic amount, dns resolve signaling is not tha= t much.
2) The issue is when Mobile goes to=A0the idle/standby stage (Mobile 3= G=A0IP is still there=A0but air interface is tentatively released)
for 3G connection, if you need send dns resolve message, Mobile has to= be waked up, then it will consume lots of air interface
signaling, and because the control channel and traffic channel are sep= erated each other=A0in 3G network,=A0those signalings will
consume control channel resource of air interface. Anyway, if Mobile i= s in the stage of connected, it won't consume much about
air resource traffic channel.
=A0
So in summary, it might be an issue for mobile network to send=A0 DNS = resolve messages=A0through multiple interfaces.
=A0
thanks
=A0
-Hui
=A0
2011/4/7 Marc Blanchet <marc.blanchet@viagenie.ca>=
Le 11-04-07 10:01, pierrick.seite@or= ange-ftgroup.com a =E9crit :=20



-----Message d'origine-----<= br>De : mif-bounc= es@ietf.org [mailto:mif-bounces@ietf.org] De la part de
Andrew Sullivan
Envoy=E9 : jeudi 7 avril 2011 15:56
=C0 : mif@ietf.org
Objet : Re: [mif= ] Happy Eyeballs Extension for MIF

On Thu, Apr 07, 2011 at 09:19:05A= M -0400, Marc Blanchet wrote:
actually not: if users are strea= ming video over mobile networks,
then the cost of few additional dns pac= kets is zero.

Exactly right. =A0To illustrate, the DNSSEC-enabled respon= se for MX for
ietf.org that I did just this second reports ;; MSG SIZE rcvd: 1091.
Optimizing= away DNS traffic is the last place to start.


I couldn't agree more. But it's not the purpos= e; the concern was about sending DNS request on interface I1 to finally sta= rt the application on interface I2.


I underst= and. but:
- I've been working for years with a very humble contribution on trying= to restore end2end internet, by helping the ipv6 deployment. reality: even= with ipv6, it won't happen. I have no more dreams...
- we are in a = situation here where we have been engineering mechanisms to establish conne= ctions (which was a given before...): STUN/TURN/ICE/Teredo/Nat keepalives/H= appy eyeballs/... all of them require extra packets where most are triggers= , test packets, etc... and most are at the end not used for the real connec= tion.
- so yes this is not pretty.
- the fact that some mechanisms may end up = sending additional small packets on the wrong interface, 3G or not, does no= t seem to me in any way a blocker. especially again that modern 3G trafic a= nd bandwidth is many orders of magnitude larger than the little test dns pa= ckets. Moreover, about the 3G connection itself, just think about backgroun= d notification of gaming/facebook/... that are done in the background for t= he user: maintains the 3G connection up all the time...

It is just a consequence of where we are, and yes there are some causal= ities...

Marc.=20



A

--
Andrew Sullivanajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
mif ma= iling list
mif@ietf.or= g
https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing= list
mif@ietf.org=
https://www.ietf.org/mailman/listinfo/mif


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D
IPv6 book: Migratin= g to IPv6, Wiley. htt= p://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca<= /a>
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagen= ie.ca

_______________________________________________

--0015175cf8d4e22d6004a0551bbd-- From marc.blanchet@viagenie.ca Thu Apr 7 07:43:38 2011 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 B684028C125 for ; Thu, 7 Apr 2011 07:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 kBu51a+ECWCD for ; Thu, 7 Apr 2011 07:43:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id E4A623A68C4 for ; Thu, 7 Apr 2011 07:43:36 -0700 (PDT) Received: from h109.viagenie.ca (unknown [IPv6:2620:0:230:c000:5ab0:35ff:fef4:6fa]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7B4CB21EDC; Thu, 7 Apr 2011 10:45:20 -0400 (EDT) Message-ID: <4D9DCE00.3030104@viagenie.ca> Date: Thu, 07 Apr 2011 10:45:20 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hui Deng References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> <4D9DC790.7000509@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 14:43:38 -0000 Le 11-04-07 10:41, Hui Deng a écrit : > Hello all > I try to explain how mobile signal behave, mobile vendors could correct > if my explaination is not correct. > 1) Compared with real traffic amount, dns resolve signaling is not that > much. > 2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP > is still there but air interface is tentatively released) > for 3G connection, if you need send dns resolve message, Mobile has to > be waked up, then it will consume lots of air interface > signaling, and because the control channel and traffic channel are > seperated each other in 3G network, those signalings will > consume control channel resource of air interface. Anyway, if Mobile is > in the stage of connected, it won't consume much about > air resource traffic channel. I know all this. but as I wrote at the end of my previous message: - "Moreover, about the 3G connection itself, just think about background notification of gaming/facebook/... that are done in the background for the user: maintains the 3G connection up all the time... - all the nat traversal/session keepalives/... are all doing the wake up too. > So in summary, it might be an issue for mobile network to send DNS > resolve messages through multiple interfaces. I understand it is a potential issue. What I'm saying is that in reality, other stuff/usage/mechanisms already keep the mobile connected all the time and there is nothing we can do. Marc. > thanks > -Hui > 2011/4/7 Marc Blanchet > > > Le 11-04-07 10:01, pierrick.seite@orange-ftgroup.com > a écrit : > > > > -----Message d'origine----- > De : mif-bounces@ietf.org > [mailto:mif-bounces@ietf.org ] > De la part de > Andrew Sullivan > Envoyé : jeudi 7 avril 2011 15:56 > À : mif@ietf.org > Objet : Re: [mif] Happy Eyeballs Extension for MIF > > On Thu, Apr 07, 2011 at 09:19:05AM -0400, Marc Blanchet wrote: > > actually not: if users are streaming video over mobile > networks, > then the cost of few additional dns packets is zero. > > > Exactly right. To illustrate, the DNSSEC-enabled response > for MX for > ietf.org that I did just this second > reports ;; MSG SIZE rcvd: 1091. > Optimizing away DNS traffic is the last place to start. > > > I couldn't agree more. But it's not the purpose; the concern was > about sending DNS request on interface I1 to finally start the > application on interface I2. > > > I understand. but: > - I've been working for years with a very humble contribution on > trying to restore end2end internet, by helping the ipv6 deployment. > reality: even with ipv6, it won't happen. I have no more dreams... > - we are in a situation here where we have been engineering > mechanisms to establish connections (which was a given before...): > STUN/TURN/ICE/Teredo/Nat keepalives/Happy eyeballs/... all of them > require extra packets where most are triggers, test packets, etc... > and most are at the end not used for the real connection. > - so yes this is not pretty. > - the fact that some mechanisms may end up sending additional small > packets on the wrong interface, 3G or not, does not seem to me in > any way a blocker. especially again that modern 3G trafic and > bandwidth is many orders of magnitude larger than the little test > dns packets. Moreover, about the 3G connection itself, just think > about background notification of gaming/facebook/... that are done > in the background for the user: maintains the 3G connection up all > the time... > > It is just a consequence of where we are, and yes there are some > causalities... > > Marc. > > > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > 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 > > > > -- > ========= > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > > DTN Implementation: http://postellation.viagenie.ca > > NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From denghui02@gmail.com Thu Apr 7 08:23:25 2011 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 4933228C0F3 for ; Thu, 7 Apr 2011 08:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 XFXooBhcqbAk for ; Thu, 7 Apr 2011 08:23:24 -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 D4B7828C0D7 for ; Thu, 7 Apr 2011 08:23:23 -0700 (PDT) Received: by bwz13 with SMTP id 13so2384841bwz.31 for ; Thu, 07 Apr 2011 08:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FX3HYwhgvIT8anmsn2yqK47yKlnE9pHnYhEifsyfJV0=; b=sWoOPFLv4ZjDDLWj0QFa/HaYWsIHErWGGAfNPoaFEx7hPpa9qLC8uEKUsUy2rF1NBX d4J1DNHd6VnzlY77OUyBi2cckGTx1sHlV2k2c7znISr2DD3qxPIPzugxFwLrUbAynxGY OwEhdEnzf4bsG1Zusx2DOzPRYqo5/Uh/e39as= 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=KT69os83ipZxvEcbZbifbTHMSbrYGcefnmzaMGdgmXY9XZK/FKozt+jMttwlY+efpK Xb75SfRUk5A6Bf1rPL6RBFU4OUI3L88ssARr/RzMGN8gWNr4WPxv9LWI+c/9a0/8nwQm NVn8Oo500nYMo8Or/Zmud+SjaBUb7oZrPmF3k= MIME-Version: 1.0 Received: by 10.204.126.147 with SMTP id c19mr924801bks.60.1302189907726; Thu, 07 Apr 2011 08:25:07 -0700 (PDT) Received: by 10.204.17.13 with HTTP; Thu, 7 Apr 2011 08:25:07 -0700 (PDT) In-Reply-To: <4D9DCE00.3030104@viagenie.ca> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> <4D9DC790.7000509@viagenie.ca> <4D9DCE00.3030104@viagenie.ca> Date: Thu, 7 Apr 2011 23:25:07 +0800 Message-ID: From: Hui Deng To: Marc Blanchet Content-Type: multipart/alternative; boundary=0016e6d99ae1e17fb904a055b6bd Cc: mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 15:23:25 -0000 --0016e6d99ae1e17fb904a055b6bd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable before move, just say you are right, inline please, 2011/4/7 Marc Blanchet > Le 11-04-07 10:41, Hui Deng a =E9crit : > > Hello all >> I try to explain how mobile signal behave, mobile vendors could correct >> if my explaination is not correct. >> 1) Compared with real traffic amount, dns resolve signaling is not that >> much. >> 2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP >> is still there but air interface is tentatively released) >> for 3G connection, if you need send dns resolve message, Mobile has to >> be waked up, then it will consume lots of air interface >> signaling, and because the control channel and traffic channel are >> seperated each other in 3G network, those signalings will >> consume control channel resource of air interface. Anyway, if Mobile is >> in the stage of connected, it won't consume much about >> air resource traffic channel. >> > > I know all this. but as I wrote at the end of my previous message: > > - "Moreover, about the 3G connection itself, just think about background > notification of gaming/facebook/... that are done in the background for t= he > user: maintains the 3G connection up all the time... > - all the nat traversal/session keepalives/... are all doing the wake up > too. =3D=3D> Today some smart phones or applications, not all of them, does dete= ct whether the 3G connection is still there, if not, they will send message to wake up the connection to keep them alway= s online. But the number of user allowed to access for one cell is still limited at least for 3G/2G, and data plane is also shared link for accessed user. This behavior seems kind of unfair usage of air interface, operators does have some way to schedule it, and some application are changing their behavior today as well. This is the topic people who are working on now, some solutions are under trial today. -Hui > So in summary, it might be an issue for mobile network to send DNS >> resolve messages through multiple interfaces. >> > > I understand it is a potential issue. What I'm saying is that in reality, > other stuff/usage/mechanisms already keep the mobile connected all the ti= me > and there is nothing we can do. > > Marc. > --0016e6d99ae1e17fb904a055b6bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable before=A0move, just say=A0you are right, inline please,

2011/4/7 Marc Blanchet <marc.blanchet@viagenie.ca>=
Le 11-04-07 10:41, Hui Deng a = =E9crit :=20

Hello all
I try to explain ho= w mobile signal =A0behave, mobile vendors could correct
if my explainati= on is not correct.
1) Compared with real traffic amount, dns resolve signaling is not that
= much.
2) The issue is when Mobile goes to the idle/standby stage (Mobile= 3G IP
is still there but air interface is tentatively released)
for 3G connection, if you need send dns resolve message, Mobile has to
b= e waked up, then it will consume lots of air interface
signaling, and be= cause the control channel and traffic channel are
seperated each other i= n 3G network, those signalings will
consume control channel resource of air interface. Anyway, if Mobile is
= in the stage of connected, it won't consume much about
air resource = traffic channel.

I know all this. but as I wrote = at the end of my previous message:=20

- "Moreover, about the 3G connection itself, jus= t think about background notification of gaming/facebook/... that are done = in the background for the user: maintains the 3G connection up all the time= ...
- all the nat traversal/session keepalives/... are all doing the wake= up too.
=3D=3D> Today some smart phones or applications, not all of them,= =A0does detect whether the 3G connection is=A0still there,
if not, they will send message to wake up the connection to keep them = always online. But the number of user allowed to access for one cell is sti= ll limited at least for 3G/2G, and data plane is also shared link for acces= sed user. This behavior seems=A0kind of=A0unfair usage of air interface, op= erators does have some way to schedule it, and some application are changin= g their behavior today as well.
This is the topic people who are working on=A0now, some solutions are = under trial today.
=A0
-Hui
=A0
So in summary, it might be an is= sue for mobile network to send =A0DNS
resolve messages through multiple = interfaces.

I understand it is a potential issue. What I'm s= aying is that in reality, other stuff/usage/mechanisms already keep the mob= ile connected all the time and there is nothing we can do.

Marc.
--0016e6d99ae1e17fb904a055b6bd-- From phdgang@gmail.com Thu Apr 7 08:23:27 2011 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 EAB1528C134 for ; Thu, 7 Apr 2011 08:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, J_CHICKENPOX_101=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 7ZRJUMCJC30K for ; Thu, 7 Apr 2011 08:23:27 -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 12E8928C132 for ; Thu, 7 Apr 2011 08:23:26 -0700 (PDT) Received: by vws12 with SMTP id 12so2459235vws.31 for ; Thu, 07 Apr 2011 08:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sidOl43yYM3TgwtOaGHRveI8U5gGXUifsrHmoEsdmj0=; b=p/037+7Ub2xKWyLpZk6Dra1JSqgkoQfyBxU0DsiXDtJtAgUXqA+dQ0T+SLKdCNaH41 Bj+eINTZLwi/PoLeSb5gJQM3f7cw+C/DaqglbP8xDhd/0Rp7mB9p7Btfb8rPGIglaU7U 2Lj9KRP/JfsKOoQJzfPNKb7fZVIH9EICUHhc4= 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=gWC6+qvJYk4Er7xdh3QYH5SjXv3/3JVNFAfnclw65aDJXYrwa7LN6QcZLDUwEyErIg YWOKt16T76rEgdNWlwlVh++6ys7C+489I5+yuBZxGCkV7ArjDC+37xAZbqHcxBleJ6x6 ntXd0xjYGq+rMi1roeBrlzFNFTrKxueoMv39s= MIME-Version: 1.0 Received: by 10.52.71.243 with SMTP id y19mr1454073vdu.191.1302189911423; Thu, 07 Apr 2011 08:25:11 -0700 (PDT) Received: by 10.52.164.132 with HTTP; Thu, 7 Apr 2011 08:25:11 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> Date: Thu, 7 Apr 2011 23:25:11 +0800 Message-ID: From: GangChen To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org, scott.brim@gmail.com Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 15:23:28 -0000 2011/4/6, pierrick.seite@orange-ftgroup.com : > Hi, > I agree that interface selection can be made using an interface weighting > method. However, weight computation needs to take into account various > criteria: obviously network access condition, but also the type of > application (applications may have different QoS requirements), user > preferences and operator policies, interface cost, L2/L3 > authentication/security capabilities, and so on... Interface weight must = be > computed in advance but also be recomputed during session; network condit= ion > may change during the session and interface reselection triggered (if > mobility supported). IMHO, the proposed algorithm is too simplistic with > regards to interface selection problem in MIF context. Usually, interface > selection is performed by a connection manager having interfaces to > different layers. I'm trying to catch various criteria into account. In order to compute interface weighting, it should formulate a function. Li= ke Iweighting=3DF (Rule 1, Rule 2, =85., Rule n) Some rules can be quantified and some are not, like user preferences or operator policies. It will make algorithm become impractical. I think Happy Eyeball is targeting to HTTP context. Usage scope has limitation here. We can't expect interface weighting to judge interface selection for all kinds of application. BRs Gang From JuanCarlos.Zuniga@InterDigital.com Thu Apr 7 08:35:53 2011 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 DB0D23A6A11 for ; Thu, 7 Apr 2011 08:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_101=0.6] 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 U06Cgdo4AIfP for ; Thu, 7 Apr 2011 08:35:52 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id AC9503A69CB for ; Thu, 7 Apr 2011 08:35:52 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 11:37:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 11:37:35 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: Acv1OAZHxKUs40GmSg+Wjf9EZeEVEgAAIJow References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> From: "Zuniga, Juan Carlos" To: "GangChen" , X-OriginalArrivalTime: 07 Apr 2011 15:37:36.0644 (UTC) FILETIME=[B86F6440:01CBF539] Cc: scott.brim@gmail.com, mif@ietf.org Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 15:35:54 -0000 Hi, > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > GangChen > Sent: April 7, 2011 11:25 AM > To: pierrick.seite@orange-ftgroup.com > Cc: mif@ietf.org; scott.brim@gmail.com > Subject: Re: [mif] Happy Eyeballs Extension for MIF >=20 > 2011/4/6, pierrick.seite@orange-ftgroup.com ftgroup.com>: > > Hi, > > I agree that interface selection can be made using an interface > weighting > > method. However, weight computation needs to take into account > various > > criteria: obviously network access condition, but also the type of > > application (applications may have different QoS requirements), user > > preferences and operator policies, interface cost, L2/L3 > > authentication/security capabilities, and so on... Interface weight > must be > > computed in advance but also be recomputed during session; network > condition > > may change during the session and interface reselection triggered (if > > mobility supported). IMHO, the proposed algorithm is too simplistic > with > > regards to interface selection problem in MIF context. Usually, > interface > > selection is performed by a connection manager having interfaces to > > different layers. >=20 > I'm trying to catch various criteria into account. > In order to compute interface weighting, it should formulate a > function. Like > Iweighting=3DF (Rule 1, Rule 2, ...., Rule n) > Some rules can be quantified and some are not, like user preferences > or operator policies. > It will make algorithm become impractical. >=20 > I think Happy Eyeball is targeting to HTTP context. Usage scope has > limitation here. > We can't expect interface weighting to judge interface selection for > all kinds of application. Perhaps not for all kinds of applications, but it should take care of the main ones and the rest can be treated in a best effort manner. It should at least regard the most relevant ones, being the ones that cause more traffic, the ones that require higher QoS, the ones you have paid for, etc. This is why it is important to take other parameters into account, like operator policies, user preferences, network conditions, etc when taking the decision in the connection/session manager, and for that we need those interfaces with other layers/functions. Regards, Juan-Carlos >=20 > BRs >=20 > Gang > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Thu Apr 7 14:16:01 2011 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 0F8203A698C for ; Thu, 7 Apr 2011 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 sih3xN6mbS0D for ; Thu, 7 Apr 2011 14:16:00 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 341803A6982 for ; Thu, 7 Apr 2011 14:15:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ4p+JpSUI7w0wHljDg71YsPOPfU1jHm@postini.com; Thu, 07 Apr 2011 14:17:45 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 582081B8848 for ; Thu, 7 Apr 2011 14:17:44 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2763A190065; Thu, 7 Apr 2011 14:17:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 14:17:44 -0700 From: Ted Lemon To: Hui Deng Thread-Topic: [mif] Happy Eyeballs Extension for MIF Thread-Index: AQHL7Srehy09XOnCn0izXgjMvZZjpZRP6iqAgAFw0wCAAHGxgIAA3V8A//+0DpWAAATGJIAAeAgA//+QBgqAAAJ2EIAAelqAgAAKRQCAAAGdgIAABIsAgAAGroD///lH8Q== Date: Thu, 7 Apr 2011 21:17:43 +0000 Message-ID: References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> <4D9DC790.7000509@viagenie.ca>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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, 07 Apr 2011 21:16:01 -0000 On Apr 7, 2011, at 10:41 AM, "Hui Deng" wrote: > 2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP = is still there but air interface is tentatively released) > for 3G connection, if you need send dns resolve message, Mobile has to be= waked up, then it will consume lots of air interface > signaling, and because the control channel and traffic channel are sepera= ted each other in 3G network, those signalings will > consume control channel resource of air interface. Anyway, if Mobile is i= n the stage of connected, it won't consume much about > air resource traffic channel. > =20 > So in summary, it might be an issue for mobile network to send DNS resol= ve messages through multiple interfaces. It would be nice in this case if the layer two were able to signal to HE wh= at the marginal cost of transmitting the next packet is; if the link is alr= eady up, it would be low; if not, high. It would also be nice if the layer= two could be asked to notify the HE implementation when the cost to transm= it went low due to other traffic on the 3G link. However, ultimately this = seems like a bug in the layer two that we would hope to see eliminated at s= ome point. = From denghui02@gmail.com Thu Apr 7 23:30:10 2011 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 CF35A3A6892 for ; Thu, 7 Apr 2011 23:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 cIzNs-d0Ubsf for ; Thu, 7 Apr 2011 23:30:09 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id 8435C3A687E for ; Thu, 7 Apr 2011 23:30:09 -0700 (PDT) Received: by pxi20 with SMTP id 20so1831781pxi.27 for ; Thu, 07 Apr 2011 23:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=E7/B/zROhBlvXQm5J90ZeQ+Bqj3ulpDPT2CHzRP5MXA=; b=i+UnXkHa6c0CeW6riWu54TGXeaAgRqXjf76moqnFdextbK3c3C6mJqnszRIBSgCNAl GWh+p+qTif4Si0PRb2FvaKGbgFkZHnh4QfGF5JFLbSMvTd5TLDubQ6cG2oCHXqHc8lVY 5YMG7bSjafp5RXKc2Qb0OY+z9J0Et+mrLkRO0= 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=wcgkzEVfo8egpdc128UYq0MrTbRd5Vx5SF292eAmbDT1QsZWEAYYGjLB9tF9Z/1rKO iND7244QV7bQ+08SnonFp4jcsxqCUKmeq6aKE3C6tKxqzf5NxCy/tlV38K7gKNTz/fpy XYjnkp7Yq3VuO9k6gHitBNUUVEieO6n77ZKuM= MIME-Version: 1.0 Received: by 10.142.248.4 with SMTP id v4mr1555037wfh.145.1302244314583; Thu, 07 Apr 2011 23:31:54 -0700 (PDT) Received: by 10.68.49.98 with HTTP; Thu, 7 Apr 2011 23:31:54 -0700 (PDT) In-Reply-To: References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> <4D9DC790.7000509@viagenie.ca> Date: Fri, 8 Apr 2011 14:31:54 +0800 Message-ID: From: Hui Deng To: Ted Lemon Content-Type: multipart/alternative; boundary=00504502c9fdc812e704a0626122 Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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: Fri, 08 Apr 2011 06:30:11 -0000 --00504502c9fdc812e704a0626122 Content-Type: text/plain; charset=ISO-8859-1 User won't care much about layer 2 cost, people is always best effort doing something asap It's hard to say the layer 2 has some bug today, originally Internet host is designed to send packet like this, it seems 2G/3G air interface has different behavior, hope LTE could release this relief finally. By the way, what does HE stands for? -Hui 2011/4/8 Ted Lemon > On Apr 7, 2011, at 10:41 AM, "Hui Deng" wrote: > > > 2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP > is still there but air interface is tentatively released) > > for 3G connection, if you need send dns resolve message, Mobile has to be > waked up, then it will consume lots of air interface > > signaling, and because the control channel and traffic channel are > seperated each other in 3G network, those signalings will > > consume control channel resource of air interface. Anyway, if Mobile is > in the stage of connected, it won't consume much about > > air resource traffic channel. > > > > So in summary, it might be an issue for mobile network to send DNS > resolve messages through multiple interfaces. > > It would be nice in this case if the layer two were able to signal to HE > what the marginal cost of transmitting the next packet is; if the link is > already up, it would be low; if not, high. It would also be nice if the > layer two could be asked to notify the HE implementation when the cost to > transmit went low due to other traffic on the 3G link. However, ultimately > this seems like a bug in the layer two that we would hope to see eliminated > at some point. --00504502c9fdc812e704a0626122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
User won't care much about layer 2 cost,=A0people is always best e= ffort doing something asap
=A0
It's hard to say the layer 2 has some bug today, originally Intern= et host is designed to send packet like this,
it seems 2G/3G air interface has different behavior, hope LTE could re= lease this relief finally.
=A0
By the way, what does HE stands for?
=A0
-Hui
2011/4/8 Ted Lemon <Ted.Lemon@nominum.com>
On Apr 7, 2011, at 10:41 AM, "Hui Deng" <denghui02@gmail.com> wrote:
<= br>> 2) The issue is when Mobile goes to the idle/standby stage (Mobile = 3G IP is still there but air interface is tentatively released)
> for 3G connection, if you need send dns resolve message, Mobile has to= be waked up, then it will consume lots of air interface
> signaling,= and because the control channel and traffic channel are seperated each oth= er in 3G network, those signalings will
> consume control channel resource of air interface. Anyway, if Mobile i= s in the stage of connected, it won't consume much about
> air re= source traffic channel.
>
> So in summary, it might be an issue= for mobile network to send =A0DNS resolve messages through multiple interf= aces.

It would be nice in this case if the layer two were able to signa= l to HE what the marginal cost of transmitting the next packet is; if the l= ink is already up, it would be low; if not, high. =A0It would also be nice = if the layer two could be asked to notify the HE implementation when the co= st to transmit went low due to other traffic on the 3G link. =A0However, ul= timately this seems like a bug in the layer two that we would hope to see e= liminated at some point.

--00504502c9fdc812e704a0626122-- From Ted.Lemon@nominum.com Fri Apr 8 05:25:20 2011 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 31BD53A69C4 for ; Fri, 8 Apr 2011 05:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 JC19zoo+HORD for ; Fri, 8 Apr 2011 05:25:19 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 4773F3A6911 for ; Fri, 8 Apr 2011 05:25:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ7/FxbSgZeMUgzqTzTxIH4f2KYUJysn@postini.com; Fri, 08 Apr 2011 05:27:04 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9D490F8096 for ; Fri, 8 Apr 2011 05:27:03 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id 84E9A19006B; Fri, 8 Apr 2011 05:27:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.18] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Apr 2011 05:27:02 -0700 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 8 Apr 2011 08:27:02 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> <4D9DC790.7000509@viagenie.ca> To: Hui Deng X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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: Fri, 08 Apr 2011 12:25:20 -0000 On Apr 8, 2011, at 2:31 AM, Hui Deng wrote: > User won't care much about layer 2 cost, people is always best effort = doing something asap Of course. That's part of why it's important to fix the problem--the = users just want it to work. > It's hard to say the layer 2 has some bug today, originally Internet = host is designed to send packet like this, > it seems 2G/3G air interface has different behavior, hope LTE could = release this relief finally. Right, exactly. We have to deal with what we have, but we can hope = that this isn't a problem that will never go away, and we should do our = best to mitigate the user impact. > By the way, what does HE stands for? Happy Eyeballs! :) From denghui02@gmail.com Fri Apr 8 06:58:03 2011 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 A09453A691F for ; Fri, 8 Apr 2011 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 OAvv85i4ApyI for ; Fri, 8 Apr 2011 06:58:03 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id F2E543A690F for ; Fri, 8 Apr 2011 06:58:02 -0700 (PDT) Received: by pxi20 with SMTP id 20so2008727pxi.27 for ; Fri, 08 Apr 2011 06:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lNX4VF+S3XrjLXzAhz7dgr1GImECyGqJuP+5uxVqxn8=; b=poUm+1PmvI9J4ghFKZyV75OIlKEiv1OxjY5UZzE5CWY90Wtg+dFP6myf/6SdVTsgWx YtUh9rCS0C08Fo0XIvT33FHWOKq7KSDZRiyNQNvVk4sfbSkLYhEo+/+4REMDfCUQb1I6 6nFDGwV7flcyx3id7eBs7Sb+0vyK2KL2nC47c= 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=dAqfz/whTggGb+rzmux1Kzv0B+Sw+IeJl5iHonCNl2ORKZpzQ8WL9nPmSIFyeVGRkj Yy4rJYS/vbqlhlMEZacVqHETsfqW4JgNni+gtI7niWSUUgkd2eYM1DX/OV98+6Zs5glu jBxru48MWIK1BPv+SRIZTy46LpYVSMyRjn+9U= MIME-Version: 1.0 Received: by 10.142.139.18 with SMTP id m18mr1819195wfd.373.1302271188145; Fri, 08 Apr 2011 06:59:48 -0700 (PDT) Received: by 10.68.49.98 with HTTP; Fri, 8 Apr 2011 06:59:48 -0700 (PDT) In-Reply-To: References: <843DA8228A1BA74CA31FB4E111A5C462019D58ED@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462019D5B0F@ftrdmel0.rd.francetelecom.fr> <7D270196-EDEF-4C08-AC92-1C5BACF95E16@nominum.com> <7533EDAE-89C9-4688-9D48-5A45AF387597@nominum.com> <71AB5E9E-EF3E-409E-9EA2-CEE0E5962012@cisco.com> <6C5BFD5F-196B-4F63-9087-A75DCCFF8CC2@nominum.com> <843DA8228A1BA74CA31FB4E111A5C46201A15BF2@ftrdmel0.rd.francetelecom.fr> <4D9DB9C9.20902@viagenie.ca> <20110407135550.GD13162@crankycanuck.ca> <843DA8228A1BA74CA31FB4E111A5C46201A15C3A@ftrdmel0.rd.francetelecom.fr> <4D9DC790.7000509@viagenie.ca> Date: Fri, 8 Apr 2011 21:59:48 +0800 Message-ID: From: Hui Deng To: Ted Lemon Content-Type: multipart/alternative; boundary=000e0cd2dc609216fb04a068a3ed Cc: "mif@ietf.org" Subject: Re: [mif] Happy Eyeballs Extension for MIF 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: Fri, 08 Apr 2011 13:58:03 -0000 --000e0cd2dc609216fb04a068a3ed Content-Type: text/plain; charset=ISO-8859-1 inline please 2011/4/8 Ted Lemon > On Apr 8, 2011, at 2:31 AM, Hui Deng wrote: > > User won't care much about layer 2 cost, people is always best effort > doing something asap > > Of course. That's part of why it's important to fix the problem--the > users just want it to work. > > > It's hard to say the layer 2 has some bug today, originally Internet host > is designed to send packet like this, > > it seems 2G/3G air interface has different behavior, hope LTE could > release this relief finally. > > Right, exactly. We have to deal with what we have, but we can hope that > this isn't a problem that will never go away, and we should do our best to > mitigate the user impact. > Whether we need to do something will depend on how many years those 2G/3G base station will stand there. sometime operator would prefer to use VoLTE in how many years later, say 3-5-10? > > > By the way, what does HE stands for? > > Happy Eyeballs! :) > :) -Hui --000e0cd2dc609216fb04a068a3ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
inline please
2011/4/8 Ted Lemon <Ted.Lemon@nominum.com>
On Apr 8, 2011, at 2:31 AM, Hui Deng wrote:
> User = won't care much about layer 2 cost, people is always best effort doing = something asap

Of course. =A0 That's part of why it's = important to fix the problem--the users just want it to work.

> It's hard to say the layer 2 has some bug to= day, originally Internet host is designed to send packet like this,
>= it seems 2G/3G air interface has different behavior, hope LTE could releas= e this relief finally.

Right, exactly. =A0 We have to deal with what we have, but we can= hope that this isn't a problem that will never go away, and we should = do our best to mitigate the user impact.
Whether we need to do something will depend on how many years those 2G= /3G base station will stand there.
sometime operator would prefer to use VoLTE in how many years later, s= ay 3-5-10?
=A0

> By the way, what does HE stands for?

Happy Eyeballs! =A0 :)
:)
=A0
-Hui
=A0
--000e0cd2dc609216fb04a068a3ed-- From denghui02@gmail.com Sat Apr 9 21:29:56 2011 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 E52E13A6834 for ; Sat, 9 Apr 2011 21:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 8vx4sb5fDM9e for ; Sat, 9 Apr 2011 21:29:55 -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 886D03A694D for ; Sat, 9 Apr 2011 21:29:55 -0700 (PDT) Received: by pvh1 with SMTP id 1so2078815pvh.31 for ; Sat, 09 Apr 2011 21:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vIKUp4Yn/BAthNQl5A+Fitf3FpbJj4JBzISBYH50uTo=; b=LmNpZDHD1AJ2OeGkIKC1x2btCLvf/GT5KQTyr5LHBD6HkuLpfAf32n6Y0719vV6PeD hEQTFHa3G+36YQKZiXocIQiNYVYYU+KphBOeXwKseaqhUlred6Mh3lpBLADPWb7xZawd iNxWyIQWscsnBO759JHl2NeHPPIOeMo5l7RYg= 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=n08QP0Dembhra3VFKXIRq/F21oXo2mmVjVfi6VEiwh/FTIu5se+dhVhDzklu7jbiY5 q1yyFtDRWoVYPOtNUcZ0M3pOM99qg4fxi2zy06gHGgF+Qb4NXqIPGFS34PFck0nep3LX TtIJJxnZmhUIJ/YNf+WaG/VOgIBhi0Wglio+U= MIME-Version: 1.0 Received: by 10.142.48.20 with SMTP id v20mr3691320wfv.430.1302409901730; Sat, 09 Apr 2011 21:31:41 -0700 (PDT) Received: by 10.68.49.98 with HTTP; Sat, 9 Apr 2011 21:31:41 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> References: <4D90926D.3030700@piuha.net> <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> <843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> Date: Sun, 10 Apr 2011 12:31:41 +0800 Message-ID: From: Hui Deng To: pierrick.seite@orange-ftgroup.com Content-Type: multipart/alternative; boundary=000e0cd1512a8b713204a088efcd Cc: mif@ietf.org, Ted.Lemon@nominum.com Subject: Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) 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, 10 Apr 2011 04:29:57 -0000 --000e0cd1512a8b713204a088efcd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Today's most operators are using captive portal for wifi authentication, I would agree this problem exists widely and encourage to include it into the PS. thanks a lot -Hui 2011/3/31 > > Any other comments with regards to this text? Is there an agreement to > include it into the PS? > > > -----Message d'origine----- > > De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > > Envoy=E9 : lundi 28 mars 2011 17:47 > > =C0 : Ted.Lemon@nominum.com; jari.arkko@piuha.net > > Cc : draft-ietf-mif-current-practices@tools.ietf.org; mif@ietf.org > > Objet : RE: AD review of draft-ietf-mif-current-practices > > > > Ted, > > > > Good text. I agree the problem exist. The DNS server selection points t= o > > this issue as well: > > -- > > (DISCUSS: > > What about those DNS servers that instead of negative answer always > > return positive reply with an IP address of some captive portal?) > > -- > > > > IMHO the problem section should say that this problem (usually/always) > > disappears right after M1 has authenticated to the captive portal and > > interface becomes truly "up". I.e. human intervention is required to > clear > > the situation, but once cleared, things work as they should - until > > captive portal possibly wants to renew authentication.. > > > > This problem btw means the M1 cannot start validating responses until > > authentication with captive portal shas been completed. > > > > Best regards, > > > > Teemu > > > > > > > -----Original Message----- > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > > > ext Ted Lemon > > > Sent: 28. maaliskuuta 2011 17:25 > > > To: Jari Arkko > > > Cc: draft-ietf-mif-current-practices@tools.ietf.org; mif > > > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices > > > > > > FYI, this is a rough approximation of the text I would want to add: > > > > > > 4.1a. DNS resolution issues with captive portals > > > > > > A MIF node (M1) has an active interface(I1) connected to a network > > > (N1) which has its DNS server (S1) and another active interface > > > (I2) connected to a network (N2) which has its DNS server (S2). S= 1 > > > is configured to respond to any A or AAAA record query with the > > > IP address of a captive portal, so as to redirect web browsers to = an > > > access control portal web page. Any of the following situations > > > may occur: > > > > > > 1. M1 stack, based on its routing table, uses I2 to reach S1 to > > > resolve "a.example.com". M1 never reaches S1. The name > > > is not resolved. > > > 2. M1 keeps only one set of DNS server addresses from the receive= d > > > configuration objects and kept S2 address. M1 sends the > > > forward DNS query for a.example.com to S2. S2 responds with > the > > > correct answer, R1. M1 attempts to contact R1 by way of I1. > > > The connection fails. Or, the connection succeeds, > > > bypassing the security policy on N1, possibly exposing the > > > owner of M1 to prosecution. > > > 3. M1 keeps only one set of DNS server addresses from the receive= d > > > configuration objects and kept S1 address. M1 sends the DNS > > > query for a.example.com to S1. S1 provides the address of its > > > captive portal. S1 attempts to contact this IP address using > > > I1. The application tries to connect to the wrong destinatio= n > > > node, resulting in lack of service and possible security issue= s. > > > 4. M1 has resolved an FQDN to the IP address of the captive porta= l > > > connected to N1. If the node loses connection to N1, the node > > > may try to connect, via N2, to the same IP address as earlier, > > > but as the address was only locally valid, connection setup > > > fails. > > > _______________________________________________ > > > 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 > --000e0cd1512a8b713204a088efcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Today's most operators are using captive portal for wifi authentic= ation,
I would agree this problem exists widely=A0and encourage to include it= =A0into the PS.
=A0
thanks a lot
=A0
-Hui

2011/3/31 <pierrick.seite@orange-ftgroup.com&= gt;

Any other comments with rega= rds to this text? Is there an agreement to include it into the PS?

> -----Message d'origine-----
> De=A0: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]
> En= voy=E9=A0: lundi 28 mars 2011 17:47
> =C0=A0: Ted.Lemon@nominum.com= ; jari.arkko@piuha.net
&= gt; Cc=A0: draft-ietf-mif-current-practices@tools.ietf.org; mif@ietf.org
> Objet=A0: RE: AD review of draft-ietf-mif-current-practices
>> Ted,
>
> Good text. I agree the problem exist. The DNS se= rver selection points to
> this issue as well:
> --
> (DI= SCUSS:
> =A0 =A0What about those DNS servers that instead of negative answer al= ways
> =A0 =A0return positive reply with an IP address of some captiv= e portal?)
> --
>
> IMHO the problem section should say t= hat this problem (usually/always)
> disappears right after M1 has authenticated to the captive portal and<= br>> interface becomes truly "up". I.e. human intervention is = required to clear
> the situation, but once cleared, things work as t= hey should - until
> captive portal possibly wants to renew authentication..
>
>= ; This problem btw means the M1 cannot start validating responses until
= > authentication with captive portal shas been completed.
>
> Best regards,
>
> =A0 =A0 =A0 Teemu
>
>
>= ; > -----Original Message-----
> > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
> > ext Ted Lemon
> > Sent: 28. maaliskuuta 2011 17:25
&g= t; > To: Jari Arkko
> > Cc: draft-ietf-mif-current-practices@tools.ietf= .org; mif
> > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices<= br>> >
> > FYI, this is a rough approximation of the text I = would want to add:
> >
> > 4.1a. =A0DNS resolution issues= with captive portals
> >
> > =A0 =A0A MIF node (M1) has an active interface(I1) c= onnected to a network
> > =A0 =A0(N1) which has its DNS server (S1= ) and another active interface
> > =A0 =A0(I2) connected to a netw= ork (N2) which has its DNS server (S2). =A0S1
> > =A0 =A0is configured to respond to any A or AAAA record query wit= h the
> > =A0 =A0IP address of a captive portal, so as to redirect= web browsers to an
> > =A0 =A0access control portal web page. =A0= Any of the following situations
> > =A0 =A0may occur:
> >
> > =A0 =A01. =A0M1 stack= , based on its routing table, uses I2 to reach S1 to
> > =A0 =A0 = =A0 =A0resolve "a.= example.com". =A0M1 never reaches S1. =A0The name
> > =A0 =A0 =A0 =A0is not resolved.
> > =A0 =A02. =A0M1 keep= s only one set of DNS server addresses from the received
> > =A0 = =A0 =A0 =A0configuration objects and kept S2 address. =A0M1 sends the
&g= t; > =A0 =A0 =A0 =A0forward DNS query for a.example.com to S2. =A0S2 responds with the
> > =A0 =A0 =A0 =A0correct answer, R1. =A0 M1 attempts to contact R1 = by way of I1.
> > =A0 =A0 =A0 =A0The connection fails. =A0 =A0 Or,= the connection succeeds,
> > =A0 =A0 =A0 =A0bypassing the securit= y policy on N1, possibly exposing the
> > =A0 =A0 =A0 =A0owner of M1 to prosecution.
> > =A0 =A03.= =A0M1 keeps only one set of DNS server addresses from the received
>= > =A0 =A0 =A0 =A0configuration objects and kept S1 address. =A0M1 sends= the DNS
> > =A0 =A0 =A0 =A0query for a.example.com to S1. =A0S1 provides the address= of its
> > =A0 =A0 =A0 =A0captive portal. =A0 S1 attempts to contact this IP= address using
> > =A0 =A0 =A0 =A0I1. =A0 The application tries to= connect to the wrong destination
> > =A0 =A0 =A0 =A0node, resulti= ng in lack of service and possible security issues.
> > =A0 =A04. =A0M1 has resolved an FQDN to the IP address of the cap= tive portal
> > =A0 =A0 =A0 =A0connected to N1. =A0If the node los= es connection to N1, the node
> > =A0 =A0 =A0 =A0may try to connec= t, via N2, to the same IP address as earlier,
> > =A0 =A0 =A0 =A0but as the address was only locally valid, connect= ion setup
> > =A0 =A0 =A0 =A0fails.
> > _________________= ______________________________
> > mif mailing list
> > <= a href=3D"mailto:mif@ietf.org">mif@ietf.org
> > https://www.ietf.org/mailman/listinfo/mif
___________________= ____________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--000e0cd1512a8b713204a088efcd-- From maxpassion@gmail.com Sun Apr 10 20:06:32 2011 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 B0EE33A6A49 for ; Sun, 10 Apr 2011 20:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, 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 wTlsUDarTZ2o for ; Sun, 10 Apr 2011 20:06:31 -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 E2EF23A6A43 for ; Sun, 10 Apr 2011 20:06:27 -0700 (PDT) Received: by vws12 with SMTP id 12so4767100vws.31 for ; Sun, 10 Apr 2011 20:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZysKj0TouTvlAPtWGbYWV9FybbftkYIjdoGCq7d25fE=; b=AhkJ0xz62ZRbRyKNOc7RWyPyIhDgbZo7qECIYkMgp7T2JSr1h2ltxlCOaSP5bsRUv/ GPIetHVJ06VzQXxnXGF1DCAXTgL4s/Wk0Cedx4lr3F/QX+2VC3Iv4LK3O4NI6dErrG8C v/KKhZX53Yw4eOEw+cu2wUrCrlu4+CuDk3cxM= 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=kfprKO0dU1B2QCagicxIY6qMkTu1KuvFjcSJPbbe+f0YkOoUcNA8C0X2AsGIyksU9l V9XJsR/z0pETNi8QmncZ0bziRGZld5PkMy2OSUOhN7iCo1ZkpYAxf5GxCgzbaVTYVRBx sMBZ9/j+ZmZZ+aVumaUUI4BlUIpBxBKEbUAQM= MIME-Version: 1.0 Received: by 10.52.90.107 with SMTP id bv11mr6943634vdb.288.1302491187427; Sun, 10 Apr 2011 20:06:27 -0700 (PDT) Received: by 10.52.163.168 with HTTP; Sun, 10 Apr 2011 20:06:27 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B0055C6@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B0055C6@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 11 Apr 2011 11:06:27 +0800 Message-ID: From: liu dapeng To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Cc: "mif@ietf.org" Subject: Re: [mif] Comments on draft-liu-mif-api-extension-04 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, 11 Apr 2011 03:06:32 -0000 Hi Dave, Thanks for the comments. 2011/3/28, Dave Thaler : > First two comments from last IETF that have not been > addressed yet: > > 1) Although the draft does now include some text saying it > intends to define an abstract API, it actually defines a > concrete one. For example, saying that an API is a socket > option used with setsockopt makes it a concrete API. > And saying that a parameter is a "char *" rather than a > "string" makes it a concrete API. ==> We aggree to define only abstract API. probably we should just use setsockopt as one implementation example? will update in the next version. > 2) My understanding is that the POSIX socket APIs are defined > by the Austin Group, and standardized by the IEEE and the > Open Group. When we did RFC 3678, we learned that the > Austin Group now considers new socket options and ioctls > harmful, since they're not typesafe. As a result, the API was > fixed to use new methods instead. Unfortunately by then, > some implementations already started using socket options/ > ioctls, and so those were moved into an Appendix. ==> Thanks for the information. As mentioned above, we may use setsockopt as one possible implementation example. Regarding RFC3678, is that a concrete API? > New comments: > > 3) "struct parameter" is underspecified. In an abstract API > document, one would need to list the parameters and their > meanings and abstract types (string, integer, whatever). ==> Does abstract API need to list the detailed data structure or we can just give the functional description of the API? Best Regards, Dapeng Liu > 4) gethostbyname was obsoleted by getaddrinfo. And it's > not defined as a DNS API. For more info, see > http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostbyname.html > and RFC 6055. ==> This API will be redesigned in the updated version. > 5) For interface selection, there are existing (non-standard) > APIs on Windows and perhaps other OS's too. I'd recommend > looking at what is already in use today and making sure the > abstract API is defined with that information in mind. ==> Could you help to give a pointer of the non-standard Windows interface selection API? Thanks. > -Dave > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From teemu.savolainen@nokia.com Mon Apr 11 04:45:13 2011 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 49A6C3A6B07 for ; Mon, 11 Apr 2011 04:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 saoMUkVmf-vd for ; Mon, 11 Apr 2011 04:45:12 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 5E3C73A68CD for ; Mon, 11 Apr 2011 04:45:12 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3BBiqmF026670 for ; Mon, 11 Apr 2011 14:45:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 14:44:27 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Apr 2011 13:44:26 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Mon, 11 Apr 2011 13:44:26 +0200 From: To: Thread-Topic: DNS server selection and whether to support DHCPv4 or not Thread-Index: Acv4Pc45DRc3nzK3TiyBS7YNjOikSA== Date: Mon, 11 Apr 2011 11:44:25 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.157.91] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE4430969620209A3008AM1MPN1036mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2011 11:44:27.0513 (UTC) FILETIME=[CFEA6690:01CBF83D] X-Nokia-AV: Clean Subject: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 11:45:13 -0000 --_000_916CE6CF87173740BC8A2CE4430969620209A3008AM1MPN1036mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We discussed in Prague whether the DNS server selection options should be d= istributed also via DHCPv4. The use case would be e.g. access where DHCPv4+SLAAC combo is used without = support for Stateless DHCPv6. With DHCPv4 host could learn about suffixes a= nd then use IPv4 to talk to DNS servers for related queries. My main comment against that was the IPv4 host multihoming in presence of i= ncreasingly common RFC1918 addressed network has some serious issues. If I recall correctly, the plan was to discuss on mailing list whether DHCP= v4 should be supported. Opinions? Best regards, Teemu --_000_916CE6CF87173740BC8A2CE4430969620209A3008AM1MPN1036mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We discussed in Prague whether the DNS server select= ion options should be distributed also via DHCPv4.

 

The use case would be e.g. access where DHCPv4+S= LAAC combo is used without support for Stateless DHCPv6. With DHCPv4 host c= ould learn about suffixes and then use IPv4 to talk to DNS servers  fo= r related queries.

 

My main comment against that was the IPv4 host multi= homing in presence of increasingly common RFC1918 addressed network has som= e serious issues.

 

If I recall correctly, the plan was to discuss on ma= iling list whether DHCPv4 should be supported. Opinions?

 

Best regards,

 

        &nbs= p;       Teemu

--_000_916CE6CF87173740BC8A2CE4430969620209A3008AM1MPN1036mgdn_-- From Ted.Lemon@nominum.com Mon Apr 11 05:47:19 2011 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 684FB28C0F6 for ; Mon, 11 Apr 2011 05:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Cq9xvkO5OI86 for ; Mon, 11 Apr 2011 05:47:18 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 5A8523A6A10 for ; Mon, 11 Apr 2011 05:47:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTaL4VpOVUPookWHK9U0HagW5RkTNLRTz@postini.com; Mon, 11 Apr 2011 05:47:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B8E51F8034 for ; Mon, 11 Apr 2011 05:47:17 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id AC6F819005C; Mon, 11 Apr 2011 05:47:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) 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.2.176.0; Mon, 11 Apr 2011 05:47:16 -0700 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary="Apple-Mail-1--51197552" From: Ted Lemon In-Reply-To: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> Date: Mon, 11 Apr 2011 08:47:13 -0400 Message-ID: <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 12:47:19 -0000 --Apple-Mail-1--51197552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Apr 11, 2011, at 7:44 AM, wrote: > My main comment against that was the IPv4 host multihoming in presence = of increasingly common RFC1918 addressed network has some serious = issues. It seems to me that this is minimally different than the problem where = you have been given a default route on both interfaces, and have to = decide on which interface to send a DNS request without any help from = the routing table. It's entirely possible in this case that a host = reachable on one interface is not reachable on the other, despite having = valid default routes on both. The solution to this problem is that if I am asked to query a DNS server = based on configuration information received on interface A, I *must* = send my DNS requests to the next-hop router on interface A. If that is = not possible, the configuration is invalid. If it is possible to send = the query on interface B, I nevertheless must not attempt to do so. I think this approach completely eliminates the problem you're talking = about, Teemu, even if the two DNS servers have the exact same RFC1918 IP = address. Of course, that assumes that the stack is smart enough to = make it possible to implement the technique I just described... :) --Apple-Mail-1--51197552 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" teemu.savolainen@nokia.com&= gt;
My main comment against that was the IPv4 host = multihoming in presence of increasingly common RFC1918 addressed network = has some serious issues.

It = seems to me that this is minimally different than the problem where you = have been given a default route on both interfaces, and have to decide = on which interface to send a DNS request without any help from the = routing table.   It's entirely possible in this case that a host = reachable on one interface is not reachable on the other, despite having = valid default routes on both.

The solution to = this problem is that if I am asked to query a DNS server based on = configuration information received on interface A, I *must* send my DNS = requests to the next-hop router on interface A.   If that is not = possible, the configuration is invalid.   If it is possible to send = the query on interface B, I nevertheless must not attempt to do = so.

I think this approach completely eliminates = the problem you're talking about, Teemu, even if the two DNS servers = have the exact same RFC1918 IP address.   Of course, that assumes = that the stack is smart enough to make it possible to implement the = technique I just described... :)

= --Apple-Mail-1--51197552-- From teemu.savolainen@nokia.com Mon Apr 11 06:20:47 2011 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 BC0F028C0F5 for ; Mon, 11 Apr 2011 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 KPeJlVjsAVDH for ; Mon, 11 Apr 2011 06:20:39 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 50A1C3A69DE for ; Mon, 11 Apr 2011 06:20:39 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3BDKVNY017168; Mon, 11 Apr 2011 16:20:39 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 16:20:23 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Apr 2011 15:20:23 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Mon, 11 Apr 2011 15:20:23 +0200 From: To: Thread-Topic: [mif] DNS server selection and whether to support DHCPv4 or not Thread-Index: Acv4Pc45DRc3nzK3TiyBS7YNjOikSP//8AWA///XuuA= Date: Mon, 11 Apr 2011 13:20:22 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> In-Reply-To: <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.157.91] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962020C30008AM1MPN1036mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2011 13:20:23.0839 (UTC) FILETIME=[36F40AF0:01CBF84B] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 13:20:47 -0000 --_000_916CE6CF87173740BC8A2CE443096962020C30008AM1MPN1036mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I tried to refer to a bigger problem: a host connected to two different net= works from where it gets same numerical address for itself (192.168.1.2), o= r both have same subnet (192.168.0.0 with 255.255.255.0 mask), same default= gateway address (192.168.0.1) etc etc... and how to have reasonable way to= sort that mess out.. or from both interfaces DNS server address is same a= s default gateway's, but both try to point to different boxes.. i.e. IPv4 m= ulti-interface implementation would have to have some kind of solution for = worst-case RFC1918 address conflicts.. and that's why I'm personally more i= nterested in defining stuff for environments that are not filled with addre= ss conflicts:) When the IPv4 addresses of multiple interfaces are not in so such serious c= onflict that approach would work. The draft already btw says: -- The node SHOULD create a host specific route for the DNS server address. The route must point to the interface DNS server address was learned on. This is required to ensure DNS queries are sent out via the right interface. -- I wrote that IPv6 in mind, but probably would apply then for IPv4 as well:) Teemu From: ext Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: 11. huhtikuuta 2011 15:47 To: Savolainen Teemu (Nokia-CTO/Tampere) Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or no= t On Apr 11, 2011, at 7:44 AM, > > wrote: My main comment against that was the IPv4 host multihoming in presence of i= ncreasingly common RFC1918 addressed network has some serious issues. It seems to me that this is minimally different than the problem where you = have been given a default route on both interfaces, and have to decide on w= hich interface to send a DNS request without any help from the routing tabl= e. It's entirely possible in this case that a host reachable on one inter= face is not reachable on the other, despite having valid default routes on = both. The solution to this problem is that if I am asked to query a DNS server ba= sed on configuration information received on interface A, I *must* send my = DNS requests to the next-hop router on interface A. If that is not possib= le, the configuration is invalid. If it is possible to send the query on = interface B, I nevertheless must not attempt to do so. I think this approach completely eliminates the problem you're talking abou= t, Teemu, even if the two DNS servers have the exact same RFC1918 IP addres= s. Of course, that assumes that the stack is smart enough to make it poss= ible to implement the technique I just described... :) --_000_916CE6CF87173740BC8A2CE443096962020C30008AM1MPN1036mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I tried to refer to a bigger problem: a host connected to tw= o different networks from where it gets same numerical address for itself (= 192.168.1.2), or both have same subnet (192.168.0.0 with 255.255.255.0 mask), same default gatew= ay address (192.168.0.1) etc etc… and how to have reasonable way to s= ort that mess out..  or from both interfaces DNS server address is sam= e as default gateway’s, but both try to point to different boxes.. i.e. IPv4 multi-interface implementation would have t= o have some kind of solution for worst-case RFC1918 address conflicts.. and= that’s why I’m personally more interested in defining stuff fo= r environments that are not filled with address conflictsJ

 

When the IPv4 addresses of multiple interfaces are not in so= such serious conflict that approach would work.

 

The draft already btw says:

--

   The node SHOULD create a host specific route fo= r the DNS server

   address.  The route must point to the inte= rface DNS server address

   was learned on.  This is required to ensur= e DNS queries are sent out

   via the right interface.

--

I wrote that IPv6 in mind, but probably would apply then for= IPv4 as wellJ

 

Teemu

 

From: ext Ted = Lemon [mailto:Ted.Lemon@nominum.com]
Sent: 11. huhtikuuta 2011 15:47
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: mif@ietf.org
Subject: Re: [mif] DNS server selection and whether to support DHCPv= 4 or not

 

On Apr 11, 2011, at 7:44 AM, <teemu.savolainen@nokia.com>

My main comment aga= inst that was the IPv4 host multihoming in presence of increasingly common = RFC1918 addressed network has some serious issues.

 

It seems to me that this is minimally different than= the problem where you have been given a default route on both interfaces, = and have to decide on which interface to send a DNS request without any hel= p from the routing table.   It's entirely possible in this case that a host reachable on one interface is not reacha= ble on the other, despite having valid default routes on both.

 

The solution to this problem is that if I am asked t= o query a DNS server based on configuration information received on interfa= ce A, I *must* send my DNS requests to the next-hop router on interface A. =   If that is not possible, the configuration is invalid.   If it is possible to send the query on interface B, I n= evertheless must not attempt to do so.

 

I think this approach completely eliminates the prob= lem you're talking about, Teemu, even if the two DNS servers have the exact= same RFC1918 IP address.   Of course, that assumes that the stack is = smart enough to make it possible to implement the technique I just described... :)

 

--_000_916CE6CF87173740BC8A2CE443096962020C30008AM1MPN1036mgdn_-- From ajs@shinkuro.com Mon Apr 11 06:34:45 2011 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 8AD193A6B15 for ; Mon, 11 Apr 2011 06:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 Uj18aGNZz4P9 for ; Mon, 11 Apr 2011 06:34:45 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 030223A6A18 for ; Mon, 11 Apr 2011 06:34:45 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8059D1ECB41D for ; Mon, 11 Apr 2011 13:34:44 +0000 (UTC) Date: Mon, 11 Apr 2011 09:34:42 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110411133442.GC37910@crankycanuck.ca> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 13:34:45 -0000 On Mon, Apr 11, 2011 at 01:20:22PM +0000, teemu.savolainen@nokia.com wrote: > I tried to refer to a bigger problem: a host connected to two > different networks from where it gets same numerical address for > itself (192.168.1.2), or both have same subnet (192.168.0.0 with > 255.255.255.0 mask), same default gateway address (192.168.0.1) etc > etc... and how to have reasonable way to sort that mess out.. or > from both interfaces DNS server address is same as default > gateway's, but both try to point to different boxes. I would be fascinated to learn that there is a way to prefer one of those networks over another. As far as any routing can tell, surely, they're the same network. The usual advice is "don't do that", and I can't see any reason that we could suggest anything better. Trying to fix that sort of problem is in effect trying to do subclassing on identical address blocks. I think that way lies madness. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ted.Lemon@nominum.com Mon Apr 11 07:16:20 2011 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 5A49728C11C for ; Mon, 11 Apr 2011 07:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 HXniUoJto4TE for ; Mon, 11 Apr 2011 07:16:19 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 5A37F28C0CF for ; Mon, 11 Apr 2011 07:16:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTaMNMljB84AbS+RFlbMjdYA0CW9sHXyV@postini.com; Mon, 11 Apr 2011 07:16:20 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 46F46F8039 for ; Mon, 11 Apr 2011 07:16:18 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id 3B98919005C; Mon, 11 Apr 2011 07:16:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) 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.2.176.0; Mon, 11 Apr 2011 07:16:17 -0700 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110411133442.GC37910@crankycanuck.ca> Date: Mon, 11 Apr 2011 10:16:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 14:16:20 -0000 On Apr 11, 2011, at 9:34 AM, Andrew Sullivan wrote: > I would be fascinated to learn that there is a way to prefer one of > those networks over another. As far as any routing can tell, surely, > they're the same network. The usual advice is "don't do that", and I > can't see any reason that we could suggest anything better. You can certainly do it on a Linux machine. > Trying to fix that sort of problem is in effect trying to do > subclassing on identical address blocks. I think that way lies > madness. And yet, IPv6 link-local, which is exactly analogous, seems to work just = fine! :) From ajs@shinkuro.com Mon Apr 11 08:00:09 2011 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 129A928C12F for ; Mon, 11 Apr 2011 08:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 4Y8duwSXuTsG for ; Mon, 11 Apr 2011 08:00:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 050E83A6B20 for ; Mon, 11 Apr 2011 08:00:07 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9B5081ECB41D for ; Mon, 11 Apr 2011 15:00:06 +0000 (UTC) Date: Mon, 11 Apr 2011 11:00:04 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110411150003.GD37910@crankycanuck.ca> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 15:00:09 -0000 On Mon, Apr 11, 2011 at 10:16:13AM -0400, Ted Lemon wrote: > On Apr 11, 2011, at 9:34 AM, Andrew Sullivan wrote: > > I would be fascinated to learn that there is a way to prefer one of > > those networks over another. As far as any routing can tell, surely, > > they're the same network. The usual advice is "don't do that", and I > > can't see any reason that we could suggest anything better. > > You can certainly do it on a Linux machine. I should have been more precise: I'd be fascintated to learn that there is a way to prefer one of these networks over another on a case-by-case basis. I've never had an experience where I have two interfaces in the same RFC 1918 address space, where both networks think they're the same net block, where each network is offering a different service, and where I am able to reach each service reliably. If you're telling me that there is a way to make this work reliably, then I'm pleasantly surprised but I'd like a pointer to the fine manual. This is especially true where both networks are offering a different service of the same service type on the same address (such as, for instance, two DNS servers on 192.168.0.1, from two different interfaces -- a not completely unusual default in my experience). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ted.Lemon@nominum.com Mon Apr 11 08:16:46 2011 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 17DC33A69A6 for ; Mon, 11 Apr 2011 08:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 A0Sl-wazKDp0 for ; Mon, 11 Apr 2011 08:16:45 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 4FE913A6889 for ; Mon, 11 Apr 2011 08:16:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTaMbXYhUadnj5jfzlMBUKiEapQ72Q6k1@postini.com; Mon, 11 Apr 2011 08:16:46 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C895E1B8755 for ; Mon, 11 Apr 2011 08:16:44 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id BCB3719005C; Mon, 11 Apr 2011 08:16:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) 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.2.176.0; Mon, 11 Apr 2011 08:16:44 -0700 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110411150003.GD37910@crankycanuck.ca> Date: Mon, 11 Apr 2011 11:16:39 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> <20110411150003.GD37910@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 15:16:46 -0000 On Apr 11, 2011, at 11:00 AM, Andrew Sullivan wrote: > If you're telling me that there is a way to make this work reliably, > then I'm pleasantly surprised but I'd like a pointer to the fine > manual. This is especially true where both networks are offering a > different service of the same service type on the same address (such > as, for instance, two DNS servers on 192.168.0.1, from two different > interfaces -- a not completely unusual default in my experience). I'm not sure I get what you're saying here. This is the problem we are = trying to solve, not a problem that's solved. Right now the state of = the art is that if you have two interfaces, both of which are active and = configured at the same time, it's pretty easy for bad things to happen. = The MIF working group is supposed to be identifying the problems that = come up, and proposing ways to solve them. It is in fact true that as far as I know, if you get configuration = information on interface 1, and different configuration on interface 2, = current implements will attempt to use configuration information from = interface 1 on interface 2, and vice versa, depending on, essentially, = happenstance. From ajs@shinkuro.com Mon Apr 11 08:24:19 2011 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 450973A6A72 for ; Mon, 11 Apr 2011 08:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 XPhT7jgteD-p for ; Mon, 11 Apr 2011 08:24:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A71F43A697E for ; Mon, 11 Apr 2011 08:24:18 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CA7301ECB41D for ; Mon, 11 Apr 2011 15:24:17 +0000 (UTC) Date: Mon, 11 Apr 2011 11:24:16 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110411152415.GI37910@crankycanuck.ca> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> <20110411150003.GD37910@crankycanuck.ca> <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 15:24:19 -0000 On Mon, Apr 11, 2011 at 11:16:39AM -0400, Ted Lemon wrote: > I'm not sure I get what you're saying here. This is the problem we > are trying to solve, not a problem that's solved. That's what I thought, too, but you seemed to be suggesting it was a solved problem. What I was arguing is that this is impossible to fix. If you happen to connect to two networks both of which are 192.168.0.0/24, and they both have DNS servers on 192.168.0.1, there is not just in fact, but I claim in principle no way for you to make any kind of sensible decision about which way to send a given DNS query unless you want to inspect every packet and make a decision on the fly. (I think that'd be true of every other application using the network, too, but I'm not willing to say that with as great certainty. And what you're going to do about encrypted packets is a mystery to me.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ted.Lemon@nominum.com Mon Apr 11 08:39:12 2011 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 152BF3A697E for ; Mon, 11 Apr 2011 08:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 riKBv+hCFQke for ; Mon, 11 Apr 2011 08:39:11 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 350283A6A72 for ; Mon, 11 Apr 2011 08:39:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTaMgn0+SAV/+yRe5zwA49mcsxaDm9ArI@postini.com; Mon, 11 Apr 2011 08:39:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C0574F803A for ; Mon, 11 Apr 2011 08:39:10 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id B554219005C; Mon, 11 Apr 2011 08:39:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) 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.2.176.0; Mon, 11 Apr 2011 08:39:10 -0700 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110411152415.GI37910@crankycanuck.ca> Date: Mon, 11 Apr 2011 11:39:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> <20110411150003.GD37910@crankycanuck.ca> <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> <20110411152415.GI37910@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 15:39:12 -0000 On Apr 11, 2011, at 11:24 AM, Andrew Sullivan wrote: > What I was arguing is that this is impossible to fix. If you happen > to connect to two networks both of which are 192.168.0.0/24, and they > both have DNS servers on 192.168.0.1, there is not just in fact, but I > claim in principle no way for you to make any kind of sensible > decision about which way to send a given DNS query unless you want to > inspect every packet and make a decision on the fly. I don't see what's hard about this. In order to successfully mif, you = must maintain different routing tables for your different interfaces. = You must maintain different configuration information (e.g., DNS server = address) for your different interfaces. Supposing that this proposal = gets implemented, you'd have a hunk of config data that said "when = looking for names in splith.example.com, go to DNS server X," which = would be peculiar to one of your interfaces. When resolving a name by = following that configuration information, you would contact the DNS = server using that interface. What I meant was a solved problem was the problem of contacting IP = address X using interface Y. From ajs@shinkuro.com Mon Apr 11 08:57:10 2011 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 73BBF3A6B23 for ; Mon, 11 Apr 2011 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 YWtVWyUjXiAn for ; Mon, 11 Apr 2011 08:57:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D0B773A6A72 for ; Mon, 11 Apr 2011 08:57:09 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E2F361ECB41D for ; Mon, 11 Apr 2011 15:57:09 +0000 (UTC) Date: Mon, 11 Apr 2011 11:57:08 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110411155707.GJ37910@crankycanuck.ca> References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> <20110411150003.GD37910@crankycanuck.ca> <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> <20110411152415.GI37910@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 15:57:10 -0000 On Mon, Apr 11, 2011 at 11:39:05AM -0400, Ted Lemon wrote: > > I don't see what's hard about this. In order to successfully mif, > you must maintain different routing tables for your different > interfaces. You must maintain different configuration information > (e.g., DNS server address) for your different interfaces. Supposing > that this proposal gets implemented, you'd have a hunk of config > data that said "when looking for names in splith.example.com, go to > DNS server X," which would be peculiar to one of your interfaces. Aha! You've just crystallized for me exactly what it is that's been bugging me about all of this discussion. I'm a DNS resolver. I want to send a DNS query. How do I do that? I'm pretty sure, on any existing platform, what I do _not_ do is say, "Send this query on interface eth3." The interface is supposed to be Not My Problem, no? Similarly, if I'm the layer down in the network stack that is sending out the DNS query, surely it's supposed to be Not My Problem what the contents of that query are. If we're actually supposed to be fixing the case where 192.168.1.1[1] available on eth1 knows about zone one.example.com and 192.168.1.1[2] available on eth2 knows about zone two.example.com, I can think of no way to do that except deep packet inspection on everything. Quite apart from the overhead this is going to impose, I have a hard time understanding how this is going to be standardized in any general way. It seems like we're planning to standardize a giant ALG for every possible class of application (because, as we currently see in BEHAVE, as soon as you've done this for DNS names you'll have the IP address literal people at the door, demanding that their self-imposed problem is also solved). Now, I'm a bear of little brain, so I'm sure there's something I'm missing. What is it? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ted.Lemon@nominum.com Mon Apr 11 09:04:53 2011 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 9996A28C14C for ; Mon, 11 Apr 2011 09:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 4v1ingkRaLqm for ; Mon, 11 Apr 2011 09:04:53 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id D792228C135 for ; Mon, 11 Apr 2011 09:04:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTaMmpZ7P9DMLopOWGbj5bOqsOb/MqQT3@postini.com; Mon, 11 Apr 2011 09:04:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D151AF803B for ; Mon, 11 Apr 2011 09:04:52 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id C65B119005C; Mon, 11 Apr 2011 09:04:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) 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.2.176.0; Mon, 11 Apr 2011 09:04:52 -0700 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110411155707.GJ37910@crankycanuck.ca> Date: Mon, 11 Apr 2011 12:04:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <916CE6CF87173740BC8A2CE4430969620209A3@008-AM1MPN1-036.mgdnok.nokia.com> <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> <20110411150003.GD37910@crankycanuck.ca> <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> <20110411152415.GI37910@crankycanuck.ca> <20110411155707.GJ37910@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 16:04:53 -0000 On Apr 11, 2011, at 11:57 AM, Andrew Sullivan wrote: > I'm a DNS resolver. I want to send a DNS query. How do I do that? > I'm pretty sure, on any existing platform, what I do _not_ do is say, > "Send this query on interface eth3." The interface is supposed to be > Not My Problem, no? No. This is exactly what you are missing. The resolver *must* = specify the interface that it's sending on in order for MIF to work in = the case where two or more interfaces are connected to different = provisioning domains. If it does not, and if we accept (which I am not = arguing we should) that different DNS servers may return different = results for the same query, then a resolver that does not do this cannot = be relied upon. From ajs@shinkuro.com Mon Apr 11 09:25:42 2011 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 0CAF23A6A2F for ; Mon, 11 Apr 2011 09:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 koUfh-i0-DuJ for ; Mon, 11 Apr 2011 09:25:41 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 617773A68DC for ; Mon, 11 Apr 2011 09:25:41 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 156A21ECB41D for ; Mon, 11 Apr 2011 16:25:41 +0000 (UTC) Date: Mon, 11 Apr 2011 12:25:39 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110411162538.GK37910@crankycanuck.ca> References: <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> <20110411150003.GD37910@crankycanuck.ca> <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> <20110411152415.GI37910@crankycanuck.ca> <20110411155707.GJ37910@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 16:25:42 -0000 On Mon, Apr 11, 2011 at 12:04:47PM -0400, Ted Lemon wrote: > > No. This is exactly what you are missing. The resolver *must* > specify the interface that it's sending on in order for MIF to work > in the case where two or more interfaces are connected to different > provisioning domains. Ok, that's what I figured had to be the case, but it seems like a problem. How is the resolver going to do that? I'm not an implementer, and I therefore don't work on this code, so probably I don't know what I'm talking about. But do I understand this to mean that getaddrinfo() has to change in order to make this work? > If it does not, and if we accept (which I am > not arguing we should) that different DNS servers may return > different results for the same query, then a resolver that does not > do this cannot be relied upon. How does an application know that the resolver does in fact do this? I'm sorry to be asking stupid questions, and if this has all be thrashed out before and I should just work harder in the archives, please don't hesitate to tell me to go look there. I just haven't seen it so far. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Ted.Lemon@nominum.com Mon Apr 11 10:08:48 2011 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 007553A6938 for ; Mon, 11 Apr 2011 10:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Hzlqg0mYbrei for ; Mon, 11 Apr 2011 10:08:47 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 19F973A68DC for ; Mon, 11 Apr 2011 10:08:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTaM1niZ0KE/IbUDG0QEXOAe58Fkb/+oT@postini.com; Mon, 11 Apr 2011 10:08:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 666D1F803C for ; Mon, 11 Apr 2011 10:08:46 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id 5B6FF19005C; Mon, 11 Apr 2011 10:08:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) 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.2.176.0; Mon, 11 Apr 2011 10:08:45 -0700 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110411162538.GK37910@crankycanuck.ca> Date: Mon, 11 Apr 2011 13:08:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <240C9515-8B9C-4F9E-BD39-FB2E66C48F29@nominum.com> <916CE6CF87173740BC8A2CE443096962020C30@008-AM1MPN1-036.mgdnok.nokia.com> <20110411133442.GC37910@crankycanuck.ca> <4713FEC3-7EF9-48EE-A90F-2CAC5549A58C@nominum.com> <20110411150003.GD37910@crankycanuck.ca> <586EF7C6-EA8D-4744-936B-62E0D4C89FC9@nominum.com> <20110411152415.GI37910@crankycanuck.ca> <20110411155707.GJ37910@crankycanuck.ca> <20110411162538.GK37910@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not 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, 11 Apr 2011 17:08:48 -0000 On Apr 11, 2011, at 12:25 PM, Andrew Sullivan wrote: >=20 > Ok, that's what I figured had to be the case, but it seems like a > problem. How is the resolver going to do that? I'm not an > implementer, and I therefore don't work on this code, so probably I > don't know what I'm talking about. But do I understand this to mean > that getaddrinfo() has to change in order to make this work? =20 Whether the API exposes the configuration database selection or hides it = is an interesting question. I don't see any reason why getaddrinfo() = couldn't do the right thing without change, although in fact we're going = to propose a different API precisely because getaddrinfo() presumes a = synchronous model for name resolution which is probably not desirable. >=20 >> If it does not, and if we accept (which I am >> not arguing we should) that different DNS servers may return >> different results for the same query, then a resolver that does not >> do this cannot be relied upon. >=20 > How does an application know that the resolver does in fact do this? =20= I don't think the application has to know. I think the hope is that = the application won't have to know, because the resolver will just do = the right thing. I think it's worthwhile to *allow* the application to = know, but I don't know if any applications will take advantage of that, = and I don't think they have to in order to win. > I'm sorry to be asking stupid questions, and if this has all be > thrashed out before and I should just work harder in the archives, > please don't hesitate to tell me to go look there. I just haven't > seen it so far. It probably has been hashed out before, but I don't recall a specific = conversation on the mailing list, so I certainly don't mind your = questions! :) From Internet-Drafts@ietf.org Tue Apr 12 01:00:04 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B1DDE077B; Tue, 12 Apr 2011 01:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3SBSo1Qu-KV; Tue, 12 Apr 2011 01:00:03 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35F39E076D; Tue, 12 Apr 2011 01:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110412080003.12204.42885.idtracker@ietfc.amsl.com> Date: Tue, 12 Apr 2011 01:00:03 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-problem-statement-12.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:00:04 -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 and Provisioning Domains Problem Statement Author(s) : M. Blanchet, P. Seite Filename : draft-ietf-mif-problem-statement-12.txt Pages : 20 Date : 2011-04-12 This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains where some configuration objects are global to the node, others are local to the interface. Issues such as selecting the wrong interface to send trafic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simulatenous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses single interface nodes situation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-12.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-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-12005334.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Tue Apr 12 01:48:50 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 01496E06A6 for ; Tue, 12 Apr 2011 01:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rJKYhfhHqZF for ; Tue, 12 Apr 2011 01:48:44 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfc.amsl.com (Postfix) with ESMTP id B2636E0682 for ; Tue, 12 Apr 2011 01:48:43 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3D858858002; Tue, 12 Apr 2011 10:54:59 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 08A1F778001; Tue, 12 Apr 2011 10:54:58 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 10:48:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF8EE.6C271457" Date: Tue, 12 Apr 2011 10:48:40 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A16430@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) Thread-Index: Acv3ODKf/W/Zwd4DS1WHAm0LTDWMBwBs8epw References: <4D90926D.3030700@piuha.net><8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com><916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com><843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 12 Apr 2011 08:48:42.0027 (UTC) FILETIME=[6CBAAFB0:01CBF8EE] Cc: mif@ietf.org Subject: Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:48:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF8EE.6C271457 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 -11 of problem statement has succinct considerations on captive portal; = but clearly it is worth to be detailed. So, based on Ted's text, the = problem statement has been updated accordingly: = http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-12.t= xt (section 4.1) =20 Pierrick =20 =20 =20 ________________________________ De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : dimanche 10 avril 2011 06:32 =C0 : SEITE Pierrick RD-RESA-REN Cc : teemu.savolainen@nokia.com; Ted.Lemon@nominum.com; = jari.arkko@piuha.net; mif@ietf.org Objet : Re: [mif] prblem statement: DNS/captive portals - was (RE: AD = review of draft-ietf-mif-current-practices) =20 Today's most operators are using captive portal for wifi authentication, I would agree this problem exists widely and encourage to include it = into the PS. =20 thanks a lot =20 -Hui 2011/3/31 Any other comments with regards to this text? Is there an agreement to = include it into the PS? > -----Message d'origine----- > De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Envoy=E9 : lundi 28 mars 2011 17:47 > =C0 : Ted.Lemon@nominum.com; jari.arkko@piuha.net > Cc : draft-ietf-mif-current-practices@tools.ietf.org; mif@ietf.org > Objet : RE: AD review of draft-ietf-mif-current-practices > > Ted, > > Good text. I agree the problem exist. The DNS server selection points = to > this issue as well: > -- > (DISCUSS: > What about those DNS servers that instead of negative answer always > return positive reply with an IP address of some captive portal?) > -- > > IMHO the problem section should say that this problem (usually/always) > disappears right after M1 has authenticated to the captive portal and > interface becomes truly "up". I.e. human intervention is required to = clear > the situation, but once cleared, things work as they should - until > captive portal possibly wants to renew authentication.. > > This problem btw means the M1 cannot start validating responses until > authentication with captive portal shas been completed. > > Best regards, > > Teemu > > > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf = Of > > ext Ted Lemon > > Sent: 28. maaliskuuta 2011 17:25 > > To: Jari Arkko > > Cc: draft-ietf-mif-current-practices@tools.ietf.org; mif > > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices > > > > FYI, this is a rough approximation of the text I would want to add: > > > > 4.1a. DNS resolution issues with captive portals > > > > A MIF node (M1) has an active interface(I1) connected to a = network > > (N1) which has its DNS server (S1) and another active interface > > (I2) connected to a network (N2) which has its DNS server (S2). = S1 > > is configured to respond to any A or AAAA record query with the > > IP address of a captive portal, so as to redirect web browsers to = an > > access control portal web page. Any of the following situations > > may occur: > > > > 1. M1 stack, based on its routing table, uses I2 to reach S1 to > > resolve "a.example.com ". M1 never = reaches S1. The name > > is not resolved. > > 2. M1 keeps only one set of DNS server addresses from the = received > > configuration objects and kept S2 address. M1 sends the > > forward DNS query for a.example.com = to S2. S2 responds with the > > correct answer, R1. M1 attempts to contact R1 by way of I1. > > The connection fails. Or, the connection succeeds, > > bypassing the security policy on N1, possibly exposing the > > owner of M1 to prosecution. > > 3. M1 keeps only one set of DNS server addresses from the = received > > configuration objects and kept S1 address. M1 sends the DNS > > query for a.example.com to S1. S1 = provides the address of its > > captive portal. S1 attempts to contact this IP address = using > > I1. The application tries to connect to the wrong = destination > > node, resulting in lack of service and possible security = issues. > > 4. M1 has resolved an FQDN to the IP address of the captive = portal > > connected to N1. If the node loses connection to N1, the = node > > may try to connect, via N2, to the same IP address as = earlier, > > but as the address was only locally valid, connection setup > > fails. > > _______________________________________________ > > 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 =20 ------_=_NextPart_001_01CBF8EE.6C271457 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

-11 of problem = statement has succinct considerations on captive portal; but clearly it is worth to be = detailed. So, based on Ted’s text, the problem statement has been updated = accordingly: http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-st= atement-12.txt =A0=A0(section = 4.1)

 =

Pierrick

 

=A0

 =

De : Hui = Deng [mailto:denghui02@gmail.com]
Envoy=E9 : dimanche = 10 avril 2011 06:32
=C0 : SEITE Pierrick RD-RESA-REN
Cc : teemu.savolainen@nokia.com; Ted.Lemon@nominum.com; jari.arkko@piuha.net; mif@ietf.org
Objet : Re: [mif] = prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices)

 

Today's most operators are using captive portal for wifi authentication,

I would agree this problem exists widely and encourage to = include it into the PS.

 

thanks a lot

 

-Hui

2011/3/31 <pierrick.seite@orange-f= tgroup.com>


Any other comments with regards to this text? Is there an agreement to = include it into the PS?

> -----Message d'origine-----
> De : teemu.savolainen@nokia.com= [mailto:teemu.savolainen@nokia.com= ]
> Envoy=E9 : lundi 28 mars 2011 17:47
> =C0 : Ted.Lemon@nominum.com; jari.arkko@piuha.net
> Cc : draft-iet= f-mif-current-practices@tools.ietf.org; mif@ietf.org
> Objet : RE: AD review of draft-ietf-mif-current-practices
>
> Ted,
>
> Good text. I agree the problem exist. The DNS server selection = points to
> this issue as well:
> --
> (DISCUSS:
>    What about those DNS servers that instead of negative = answer always
>    return positive reply with an IP address of some = captive portal?)
> --
>
> IMHO the problem section should say that this problem = (usually/always)
> disappears right after M1 has authenticated to the captive portal = and
> interface becomes truly "up". I.e. human intervention is required to clear
> the situation, but once cleared, things work as they should - = until
> captive portal possibly wants to renew authentication..
>
> This problem btw means the M1 cannot start validating responses = until
> authentication with captive portal shas been completed.
>
> Best regards,
>
>       Teemu
>
>
> > -----Original Message-----
> > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
> > ext Ted Lemon
> > Sent: 28. maaliskuuta 2011 17:25
> > To: Jari Arkko
> > Cc: draft-iet= f-mif-current-practices@tools.ietf.org; mif
> > Subject: Re: [mif] AD review of = draft-ietf-mif-current-practices
> >
> > FYI, this is a rough approximation of the text I would want to = add:
> >
> > 4.1a.  DNS resolution issues with captive portals
> >
> >    A MIF node (M1) has an active interface(I1) = connected to a network
> >    (N1) which has its DNS server (S1) and another = active interface
> >    (I2) connected to a network (N2) which has its = DNS server (S2).  S1
> >    is configured to respond to any A or AAAA record = query with the
> >    IP address of a captive portal, so as to redirect = web browsers to an
> >    access control portal web page.  Any of the following situations
> >    may occur:
> >
> >    1.  M1 stack, based on its routing table, = uses I2 to reach S1 to
> >        resolve "a.example.com".  M1 never reaches S1.  The name
> >        is not resolved.
> >    2.  M1 keeps only one set of DNS server = addresses from the received
> >        configuration objects and kept S2 = address.  M1 sends the
> >        forward DNS query for a.example.com to = S2.  S2 responds with the
> >        correct answer, R1.   M1 = attempts to contact R1 by way of I1.
> >        The connection fails.     = Or, the connection succeeds,
> >        bypassing the security policy on = N1, possibly exposing the
> >        owner of M1 to prosecution.
> >    3.  M1 keeps only one set of DNS server = addresses from the received
> >        configuration objects and kept S1 = address.  M1 sends the DNS
> >        query for a.example.com to S1.  S1 provides the address = of its
> >        captive portal.   S1 attempts = to contact this IP address using
> >        I1.   The application tries to connect to the wrong destination
> >        node, resulting in lack of service = and possible security issues.
> >    4.  M1 has resolved an FQDN to the IP = address of the captive portal
> >        connected to N1.  If the node = loses connection to N1, the node
> >        may try to connect, via N2, to the = same IP address as earlier,
> >        but as the address was only locally = valid, connection setup
> >        fails.
> > _______________________________________________
> > 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

 

------_=_NextPart_001_01CBF8EE.6C271457-- From Internet-Drafts@ietf.org Tue Apr 12 04:00:02 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A430EE0675; Tue, 12 Apr 2011 04:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17+UVUd5BBlP; Tue, 12 Apr 2011 04:00:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9ED8E078F; Tue, 12 Apr 2011 04:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110412110001.1999.60971.idtracker@ietfc.amsl.com> Date: Tue, 12 Apr 2011 04:00:01 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-dns-server-selection-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 11:00: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 : Improved DNS Server Selection for Multi-Homed Nodes Author(s) : T. Savolainen, et al. Filename : draft-ietf-mif-dns-server-selection-02.txt Pages : 21 Date : 2011-04-12 A multi-homed node can be connected to multiple networks that may utilize different DNS namespaces. The node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When the multi-homed node needs to utilize DNS, it has to choose which of the servers to contact to. This document describes a policy based method for helping on selection of DNS server, for both forward and reverse DNS lookup procedures, with help of DNS suffix and IPv6 prefix information received via DHCPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-02.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-dns-server-selection-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-12034603.I-D@ietf.org> --NextPart-- From teemu.savolainen@nokia.com Tue Apr 12 05:06:00 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93EB5E0771 for ; Tue, 12 Apr 2011 05:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.557 X-Spam-Level: X-Spam-Status: No, score=-4.557 tagged_above=-999 required=5 tests=[AWL=-1.958, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJTPLKbuqtCV for ; Tue, 12 Apr 2011 05:05:59 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfc.amsl.com (Postfix) with ESMTP id CB2D0E0737 for ; Tue, 12 Apr 2011 05:05:59 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3CC4vxM004733 for ; Tue, 12 Apr 2011 15:05:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:05:50 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 12 Apr 2011 14:05:50 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Tue, 12 Apr 2011 14:05:49 +0200 From: To: Thread-Topic: [mif] I-D Action:draft-ietf-mif-dns-server-selection-02.txt Thread-Index: AQHL+QDMQDWiERuQJkqfuREMi7NQ0JRaIH/Q Date: Tue, 12 Apr 2011 12:05:49 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620215C4@008-AM1MPN1-036.mgdnok.nokia.com> References: <20110412110001.1999.60971.idtracker@ietfc.amsl.com> In-Reply-To: <20110412110001.1999.60971.idtracker@ietfc.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.157.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Apr 2011 12:05:50.0360 (UTC) FILETIME=[F6F71180:01CBF909] X-Nokia-AV: Clean Subject: Re: [mif] I-D Action:draft-ietf-mif-dns-server-selection-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:06:00 -0000 Hi, This version includes following main updates (also some lesser): - 3.1 comment that updated hosts can talk directly to correct DNS servers. = This relates to comment: "what if in new option only suffixes were communic= ated to hosts, not IP addresses of DNS servers". Plain suffixes would essen= tially mandate DNS proxy on the gateway that would then forward the questio= ns to correct places. Better not mandate such proxy, I think. - 4.3. Limitations of use section, quite significant - Appendix B: Use of different trust anchors for choosing between different= validated answers is now here DHCPv4 is not described as I don't see yet WG consensus for having, or not = having, it.=20 Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Internet-Drafts@ietf.org > Sent: 12. huhtikuuta 2011 14:00 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action:draft-ietf-mif-dns-server-selection-02.txt >=20 > 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. >=20 >=20 > Title : Improved DNS Server Selection for Multi-Homed > Nodes > Author(s) : T. Savolainen, et al. > Filename : draft-ietf-mif-dns-server-selection-02.txt > Pages : 21 > Date : 2011-04-12 >=20 > A multi-homed node can be connected to multiple networks that may > utilize different DNS namespaces. The node commonly receives DNS > server configuration information from all connected networks. Some of > the DNS servers may have information about namespaces other servers do > not have. When the multi-homed node needs to utilize DNS, it has to > choose which of the servers to contact to. This document describes a > policy based method for helping on selection of DNS server, for both > forward and reverse DNS lookup procedures, with help of DNS suffix and > IPv6 prefix information received via DHCPv6. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server- > selection-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From julien.ietf@gmail.com Tue Apr 12 11:02:25 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0A853E0812 for ; Tue, 12 Apr 2011 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCqnyZPFboEI for ; Tue, 12 Apr 2011 11:02:24 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0AAC5E067F for ; Tue, 12 Apr 2011 11:02:09 -0700 (PDT) Received: by fxm15 with SMTP id 15so5163207fxm.31 for ; Tue, 12 Apr 2011 11:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Hx1PB+BVIgMEq3ylFiHPacEA4Ev/n1b50bHfdY3wNMI=; b=DGoNgFTHf10EUg670YpRFz24Xv9FX7WzYk5qD5e0Y5mZmIcrMK/xJN8wbtY8U2rxG3 xl6i8Sga/ccVFy+c8uzKpjiRgrvrbcZ4I4GOHmoXymGHBJSLpzlWORzxKxsyFazG5J5C t8g9hR9rGW5LTiOp2TubYtDh70f2xhUUdF0Hs= 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=XCX1qmHViFSF55AbFiu8jKU+eJ4k2xC2YiE4iVxQtNRorzNtjdG6ZRlyBTa6KlTzyB EYj5ylNOIbELf7M42wp29/bEoE2/8SmWpddcC7krqyChgFt9mD69daiXWghAAXoWjvB/ v0y0JuhYsVGmOGL96A4AFHG9ifik7Pp45Baa8= MIME-Version: 1.0 Received: by 10.223.6.198 with SMTP id a6mr2557510faa.130.1302631314387; Tue, 12 Apr 2011 11:01:54 -0700 (PDT) Received: by 10.223.87.1 with HTTP; Tue, 12 Apr 2011 11:01:54 -0700 (PDT) In-Reply-To: References: <4D90926D.3030700@piuha.net> <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> <843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> Date: Tue, 12 Apr 2011 11:01:54 -0700 Message-ID: From: Julien Laganier To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:02:25 -0000 On a side note, the captive portal systems I've encountered lately do not reply with the IP address of the captive portal when queried with an arbitrary FQDN (e.g. example.com), but rather reply with the IP address of the queried FQDN, and then do IP masquerading as the destination IP address when they receive a TCP SYN on port 80. When the HTTP GET arrives, they operate an HTTP redirect to the captive portal. In this way no DNS cache poisoning happens... --julien On Sat, Apr 9, 2011 at 9:31 PM, Hui Deng wrote: > Today's most operators are using captive portal for wifi authentication, > I would agree this problem exists widely=A0and encourage to include it=A0= into > the PS. > > thanks a lot > > -Hui > > 2011/3/31 >> >> Any other comments with regards to this text? Is there an agreement to >> include it into the PS? >> >> > -----Message d'origine----- >> > De=A0: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] >> > Envoy=E9=A0: lundi 28 mars 2011 17:47 >> > =C0=A0: Ted.Lemon@nominum.com; jari.arkko@piuha.net >> > Cc=A0: draft-ietf-mif-current-practices@tools.ietf.org; mif@ietf.org >> > Objet=A0: RE: AD review of draft-ietf-mif-current-practices >> > >> > Ted, >> > >> > Good text. I agree the problem exist. The DNS server selection points = to >> > this issue as well: >> > -- >> > (DISCUSS: >> > =A0 =A0What about those DNS servers that instead of negative answer al= ways >> > =A0 =A0return positive reply with an IP address of some captive portal= ?) >> > -- >> > >> > IMHO the problem section should say that this problem (usually/always) >> > disappears right after M1 has authenticated to the captive portal and >> > interface becomes truly "up". I.e. human intervention is required to >> > clear >> > the situation, but once cleared, things work as they should - until >> > captive portal possibly wants to renew authentication.. >> > >> > This problem btw means the M1 cannot start validating responses until >> > authentication with captive portal shas been completed. >> > >> > Best regards, >> > >> > =A0 =A0 =A0 Teemu >> > >> > >> > > -----Original Message----- >> > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf O= f >> > > ext Ted Lemon >> > > Sent: 28. maaliskuuta 2011 17:25 >> > > To: Jari Arkko >> > > Cc: draft-ietf-mif-current-practices@tools.ietf.org; mif >> > > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices >> > > >> > > FYI, this is a rough approximation of the text I would want to add: >> > > >> > > 4.1a. =A0DNS resolution issues with captive portals >> > > >> > > =A0 =A0A MIF node (M1) has an active interface(I1) connected to a ne= twork >> > > =A0 =A0(N1) which has its DNS server (S1) and another active interfa= ce >> > > =A0 =A0(I2) connected to a network (N2) which has its DNS server (S2= ). =A0S1 >> > > =A0 =A0is configured to respond to any A or AAAA record query with t= he >> > > =A0 =A0IP address of a captive portal, so as to redirect web browser= s to >> > > an >> > > =A0 =A0access control portal web page. =A0Any of the following situa= tions >> > > =A0 =A0may occur: >> > > >> > > =A0 =A01. =A0M1 stack, based on its routing table, uses I2 to reach = S1 to >> > > =A0 =A0 =A0 =A0resolve "a.example.com". =A0M1 never reaches S1. =A0T= he name >> > > =A0 =A0 =A0 =A0is not resolved. >> > > =A0 =A02. =A0M1 keeps only one set of DNS server addresses from the = received >> > > =A0 =A0 =A0 =A0configuration objects and kept S2 address. =A0M1 send= s the >> > > =A0 =A0 =A0 =A0forward DNS query for a.example.com to S2. =A0S2 resp= onds with >> > > the >> > > =A0 =A0 =A0 =A0correct answer, R1. =A0 M1 attempts to contact R1 by = way of I1. >> > > =A0 =A0 =A0 =A0The connection fails. =A0 =A0 Or, the connection succ= eeds, >> > > =A0 =A0 =A0 =A0bypassing the security policy on N1, possibly exposin= g the >> > > =A0 =A0 =A0 =A0owner of M1 to prosecution. >> > > =A0 =A03. =A0M1 keeps only one set of DNS server addresses from the = received >> > > =A0 =A0 =A0 =A0configuration objects and kept S1 address. =A0M1 send= s the DNS >> > > =A0 =A0 =A0 =A0query for a.example.com to S1. =A0S1 provides the add= ress of its >> > > =A0 =A0 =A0 =A0captive portal. =A0 S1 attempts to contact this IP ad= dress using >> > > =A0 =A0 =A0 =A0I1. =A0 The application tries to connect to the wrong= destination >> > > =A0 =A0 =A0 =A0node, resulting in lack of service and possible secur= ity >> > > issues. >> > > =A0 =A04. =A0M1 has resolved an FQDN to the IP address of the captiv= e portal >> > > =A0 =A0 =A0 =A0connected to N1. =A0If the node loses connection to N= 1, the node >> > > =A0 =A0 =A0 =A0may try to connect, via N2, to the same IP address as= earlier, >> > > =A0 =A0 =A0 =A0but as the address was only locally valid, connection= setup >> > > =A0 =A0 =A0 =A0fails. >> > > _______________________________________________ >> > > 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 > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From Ted.Lemon@nominum.com Tue Apr 12 11:31:39 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 190B4E07E4 for ; Tue, 12 Apr 2011 11:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADexQK744iVB for ; Tue, 12 Apr 2011 11:31:34 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfc.amsl.com (Postfix) with ESMTP id 8FE51E065C for ; Tue, 12 Apr 2011 11:31:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTaSaheTWrMhIbSiv07jIshMRmYOY+tkw@postini.com; Tue, 12 Apr 2011 11:31:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9449EF8074 for ; Tue, 12 Apr 2011 11:31:33 -0700 (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 archivist.nominum.com (Postfix) with ESMTPS id 8B91319005D; Tue, 12 Apr 2011 11:31:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) 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.2.176.0; Tue, 12 Apr 2011 11:31:33 -0700 MIME-Version: 1.0 (Apple Message framework v1213) Content-Type: text/plain; charset="windows-1252" From: Ted Lemon In-Reply-To: Date: Tue, 12 Apr 2011 14:31:29 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <284D0C9A-A029-48BE-9D31-DE5E46DCFA94@nominum.com> References: <4D90926D.3030700@piuha.net> <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> <843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> To: Julien Laganier X-Mailer: Apple Mail (2.1213) Cc: mif@ietf.org Subject: Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:31:39 -0000 On Apr 12, 2011, at 2:01 PM, Julien Laganier wrote: > On a side note, the captive portal systems I've encountered lately do > not reply with the IP address of the captive portal when queried with > an arbitrary FQDN (e.g. example.com), but rather reply with the IP > address of the queried FQDN, and then do IP masquerading as the > destination IP address when they receive a TCP SYN on port 80. When > the HTTP GET arrives, they operate an HTTP redirect to the captive > portal. In this way no DNS cache poisoning happens=85 I'm not sure whether to laugh or cry. I guess this is an improvement, = at least=85 :) From Internet-Drafts@ietf.org Wed Apr 13 02:00:03 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55696E06C5; Wed, 13 Apr 2011 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxH4kRjnUVLA; Wed, 13 Apr 2011 02:00:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B4DEE06DC; Wed, 13 Apr 2011 02:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413090002.14548.7836.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 02:00:02 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-problem-statement-13.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:00:03 -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 and Provisioning Domains Problem Statement Author(s) : M. Blanchet, P. Seite Filename : draft-ietf-mif-problem-statement-13.txt Pages : 20 Date : 2011-04-13 This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains where some configuration objects are global to the node, others are local to the interface. Issues such as selecting the wrong interface to send trafic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simulatenous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses single interface nodes situation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13014628.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Wed Apr 13 02:08:55 2011 Return-Path: X-Original-To: mif@ietfc.amsl.com Delivered-To: mif@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00842E0674 for ; Wed, 13 Apr 2011 02:08:55 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFbUocNLQCBR for ; Wed, 13 Apr 2011 02:08:54 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfc.amsl.com (Postfix) with ESMTP id 49AB8E0689 for ; Wed, 13 Apr 2011 02:08:54 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 73BDBFC400F; Wed, 13 Apr 2011 11:09:01 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 65BCBFC4008; Wed, 13 Apr 2011 11:09:01 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 11:08:53 +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, 13 Apr 2011 11:08:52 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201A1676B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <284D0C9A-A029-48BE-9D31-DE5E46DCFA94@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) Thread-Index: Acv5P9t2MQVWddu8SF6IOy4IoPwSkwAd3y2w References: <4D90926D.3030700@piuha.net> <8D91C7B0-190C-4C82-868A-CA0507F9C09B@nominum.com> <916CE6CF87173740BC8A2CE443096962015946@008-AM1MPN1-036.mgdnok.nokia.com> <843DA8228A1BA74CA31FB4E111A5C462019B5E9B@ftrdmel0.rd.francetelecom.fr> <284D0C9A-A029-48BE-9D31-DE5E46DCFA94@nominum.com> From: To: , X-OriginalArrivalTime: 13 Apr 2011 09:08:53.0499 (UTC) FILETIME=[693C64B0:01CBF9BA] Cc: mif@ietf.org Subject: Re: [mif] prblem statement: DNS/captive portals - was (RE: AD review of draft-ietf-mif-current-practices) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:08:55 -0000 I've checked on Orange hotspot, recent release, and it works as Julien = said... Shame on me, I should have checked before... Anyway, the problem = statement is not supposed to be exhaustive on mechanisms used by captive = portal, but I've updated the document to clarify that DNS modification = is not the only way to do redirection. > -----Message d'origine----- > De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Envoy=E9=A0: mardi 12 avril 2011 20:31 > =C0=A0: Julien Laganier > Cc=A0: Hui Deng; SEITE Pierrick RD-RESA-REN; mif@ietf.org > Objet=A0: Re: [mif] prblem statement: DNS/captive portals - was (RE: = AD > review of draft-ietf-mif-current-practices) >=20 > On Apr 12, 2011, at 2:01 PM, Julien Laganier wrote: > > On a side note, the captive portal systems I've encountered lately = do > > not reply with the IP address of the captive portal when queried = with > > an arbitrary FQDN (e.g. example.com), but rather reply with the IP > > address of the queried FQDN, and then do IP masquerading as the > > destination IP address when they receive a TCP SYN on port 80. When > > the HTTP GET arrives, they operate an HTTP redirect to the captive > > portal. In this way no DNS cache poisoning happens... >=20 > I'm not sure whether to laugh or cry. I guess this is an = improvement, at > least... :) >=20 From denghui02@gmail.com Wed Apr 27 18:16:51 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF2E08E8 for ; Wed, 27 Apr 2011 18:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaMOlpCB+L8D for ; Wed, 27 Apr 2011 18:16:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD6E9E066F for ; Wed, 27 Apr 2011 18:16:49 -0700 (PDT) Received: by vxg33 with SMTP id 33so1995478vxg.31 for ; Wed, 27 Apr 2011 18:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=eh1RR1mc8neLFw8shy6Rk++3O2K7HmxhoXNGy7YAz5E=; b=Hme0BHnmikBUkT4zWeTa4W2dkyYHdT1UGnlr0ymKVQbctpwfYNNd5qCHX1m9SYqMLn u6zqs17aceaPbUIDkBjukrtaQq5js1kW0SqU235XSeFH9bO8prHqHctDZ5YkfvpOfe08 zpILlZMv78GdZw4bO/SlQ8egg4b5V34GF6AXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YCJnIDseTFa97kZ+eA049hs/1yhHnXdBA+UAsFEFGyGbaSv1qqQE6gL4wlvVsmMCE6 4GTmIMnU+xvI7re2bpf52NRoSiNgBDGnWLPaN48CMRFyhnosEZaTE1fEPx14mfy9PRmS 5bsF4oLRGm6jXVefdA3tFGCQoGgZtKWP3XkKA= MIME-Version: 1.0 Received: by 10.52.176.101 with SMTP id ch5mr4223157vdc.129.1303953409306; Wed, 27 Apr 2011 18:16:49 -0700 (PDT) Received: by 10.52.114.227 with HTTP; Wed, 27 Apr 2011 18:16:49 -0700 (PDT) Date: Thu, 28 Apr 2011 09:16:49 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=20cf3071c830c3efce04a1f04ffa Subject: [mif] MIF IETF 80th draft minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 01:16:51 -0000 --20cf3071c830c3efce04a1f04ffa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello all Please help to check the below draft minutes, thanks Jouni's kind help to take minutes. Forget who help to take jabber, thank you as well. There are several ..../??? in the minutes still, please help to correct them, thanks in advance -Chairs. MIF Monday 28.3.2011 1 Agenda bashing (Chairs, 5 min) 2 LC documents (Chairs, 10 min) >>draft-ietf-mif-problem-statement-05 Updated according to #79 discussions. New problems added: - On going session continuity, IP connectivity - TCP sessions break if host implements weak host model Jari Arkko: Discusses from other ADs. Are those addressed? Margaret: Will send mail and check whether all are addressed. Jari Arkko: Ralph Drom's discusses were pretty complicated. Dave Thaler: On the 1st problem. I do not understand the case. Interface change does not cause the connection to break but e.g. an ingress filtering. Margaret: We had a document on this in the last meting. One interface went down and other came up to as a backup. Dave Thaler: That is not about the weak host model. Margaret: Need to clarify the terms. Zhen Cao: Same problem with strong host model also. It is not only the weak host model. Dave Thaler: Asymmetric routing can cause the session go down but that is due filtering etc not the host model. Brian Carpenter: There's a architectural probelem that this document starts building a solution already. Ted Lemon: Two observations: the draft is already past WGLC thus little to do. Agree there is an architectural problem. Thomas: Seconds Brian. Architectural problem needs to be fixed before than doing other things in this space. Scott: Repeats.. get this document out and say these are the problems, and MIF is not probably the group to solve those (refers to architectural problems). Margaret: This group was to figure out some of those point solutions that are needed. The group is not currently chartered to solve the big (architectural) problem of all mif issues. Jari: We can try find an architecture that we should have. However, that does not seem to be optimistic. This document tries to describe these. Still OK to fix some of the known mif problems. Margatet: .. Jari: Not always necessary to define new protocols but document existing stacks. That is also useful. Ted Lemon: Anybody here understand the architecture we try to describe? :) Thinks one more scenario is missing but the timing is bad to introduce anything new to the document. Jari: Yes it is.. Ted: In the last IETF I complained about one point solution because my architectural view does not match what others had in mind. Scott: Not a problem statement only for the MIF WG but a problem statement for the whole internet. Marc blanket: Next steps? Margaret: Not going to define the architecture in this document. Rather ask the 3 ADs whether the document can progress as it is now. Jari: Hoping to move it to LC. Deng Hui: Ted's issue/problem needs to be included? Jari: Do not know what problem he is referring. current document has a limited scope. If the scope gets widened all kinds of new issues show up. Address Ted's issues/problem later. Ted: About different trusted provisioning domains. Those should be explained. like DNS servers lie to you. You do not switch from a working to nonworking sandbox.. Marc: This is already described but not in these exact words. Jari: It is about there is one network that is more trusted than other.. and that scenario is already described. Ted: It is about that the host automatically connects to unauthenticated WLAN when one comes up. Whether the user wants or not. Other scenarios described on detail but not this. Margaret: Asks Ted to post his issues/problem/scenario to the list. ???: Points that 3484bis.. whether something has been missed regarding mif. Margaret: Not really a problem of this WG? More like 6MAN's that is working on 3484bis. >>draft-ietf-mif-current-practices-02 Apple section removed due lack of info. 3 Current Practice Analysis (5 min) >> draft-cao-mif-analysis-01 Margaret: Little feedback from the WG. Does the WG think we need to continue with this work? Ted: Analysis and current practices look the same.. confused.. Margaret: Should contains material that comes after current practices when looking identified issues through the problem statement. Brian: Contains blanks.. those need to be filled in. Asks for architectural analysis. The analysis that needs to be in context of better architecture and not point solutions. Someone needs to do an architectural analysis. Scott: Agrees with Brian. Need to fork the document. Need to contribute to the bigger architecture, which might be out of scope of this group. i.e. two documents. Ted: Thinks is ok. Jari: I am interested. One document though. Margaret: The WG interested to do this? -> reasonable number shows hands. Please volunteer. 4 Working Group Documents >> draft-ietf-mif-dns-server-selection-01 (Teemu, 10 min) Most changes due the comments from Ted Lemon. Andrew: Likes the improvements. Applications area said none of these (for DNSSEC) are deployed today. Need to have the revised text. Teemu: Would you contribute the text (I do not know DNSSEC and trust anchors in detail enough). Peter Koch: A bit concerned about the operational issues. Is the trust anchor used to distinguish which answer is a good one? Teemu: Explains the NXDOMAIN case with intra and extra DSN servers (both validates) Ted: Split horizon issue.. I don't know how to deal with this problem and that is the reason why this document was produced. Peter: ... Ted: Like the draft much more now. The draft bases on that the mobile node trusting some provisioning domain more to select the DNS server. I need to look more into this. Teemu: ... Ted: How to distinguish between trusted domains? Dave: What about the case where the host does synthesis and other DNS server gives a native addresses? Which one to prefer. Andrew: Brings up validations and synthesis.. You are totally lost in that case. Teemu: How about IPv4? Any support needed for it? Ted: Did not even notice that (IPv4 being not addressed). Teemu: Multihoming with IPv4 is even more pain. We have serious problems there. Do we need to support for IPv4 or just stick with IPv6? Ted: Does not mind if it works only in IPv6. Teemu: Is ok not to support IPv4? Margaret: We should do both.. Ted: Do not put IPv4 addresses into DHCPv6. Margaret: If IPv4 needed -> do DHCPv4 solution. * general discussion different Mif models. IPv4 only WLAN, IPv4v6 (dual-stack) cellular.. in different domain. Dave: Says having IPv4 in DHCPv6 could be ok. Jari: ... Dave: What is the use case where you need different server per different name space that are delivered in the same DHCPv6 reply? Margaret: Explains the two interfaces cases, two DHCP servers and several domains through those. ... Ted: Brings up the case where DNS is configured using RAs (RFC6106). Then this solution is not applicable and one is tempted to use DHCPv4 options. Ted: So may different scenarios that are not thought in this document -> loads of standards work (DHCPv4, DHCPv6, ..) Dapeng: Need to support IPv4, maybe in a separate document. Andrew: We seem to be tempted to do split DNS work reliably, which is broken by definition. If you want to solve it in large, it won't work. scope it well. Thomas: Better scoping needed. Says only one DHCP response per interface and those have no conflict within an interface. Margaret: Trying to provide hints that there is no need to query all known DNS servers to get an answer. Thomas: Need better scoping. teemu: Move the discussion to the list. >> draft-ietf-mif-dhcpv6-route-option-01 (Woj, 20 min) Ted: Return nothing. (answer Woj's question). Margaret: Not in IESG yet, rtg area doing review in advance. 5 Re-charter, milestone discussion >> draft-liu-mif-api-extension-04 Note takes thinks most of these options are already provided most APIs.. like BSD ioctl()s. xyz: Why S_ADDR needed? Dapend: You need to do specify the source address. Margaret: Sockets API already allows you to do that. Marc: RFC3542..? Dave: Will send comments to list. Also discussion about abstract API. There was a WG consensus not to do concrete APIs. Margatet: Chartered to do abstract APIs. Dave: Austin Group owns the sockets API. For interface selection API there is no standard. We should look at what current OS APIs provide. Ted: Thinks the right way now is rewrite the whole document. Wants to be loop as he has lots of ideas here. Alan Ford: Seconds Dave. Points to mptcp astract API work and asks for collaboration. jabber: Asks why not using advanced API from RFC3542? >> draft-korhonen-mif-ra-offload-01 (Jouni, 10-15 min) Alexandru Petrescu: Question whether both networks have to be controlled by same administrator. Jouni: no, they don=92t have to. Ted Lemon: This document is more for addressing which network to prefer rather what address family to prefer. This approach could have some security implications (misuse). Additionally technical comment that shall be discussed offline. >> draft-chen-mif-happy-eyeballs-extension-00 (Chen, 10 min) 5.4 Multiple connections (Sri, if time allowed) scott: .. (missed) --20cf3071c830c3efce04a1f04ffa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Please help to check the below draft=A0minutes, thanks Jouni's kin= d help to take minutes.
Forget who help to take jabber, thank you as well.
=A0
There are several ..../??? in the minutes still, please help to correc= t them,
=A0
thanks in advance
=A0
-Chairs.
=A0
=A0
MIF Monday 28.3.2011
1 Agenda bashing (Chairs, 5 min)
2 LC documents (Chairs, 10 min)
>>draft-ietf-mif-problem-stat= ement-05
Updated according to #79 discussions.
New problems added:
=A0- O= n going session continuity, IP connectivity
=A0- TCP sessions break if h= ost implements weak host model
Jari Arkko: Discusses from other ADs. Are those addressed?
Margaret= : Will send mail and check whether all are addressed.
Jari Arkko: Ralph = Drom's discusses were pretty complicated.
Dave Thaler: On the 1st pr= oblem. I do not understand the case.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Interface change does not cause the co= nnection to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 break but e.g. an ingr= ess filtering.
Margaret: We had a document on this in the last meting. O= ne interface
=A0=A0=A0=A0=A0=A0=A0=A0=A0 went down and other came up to = as a backup.
Dave Thaler: That is not about the weak host model.
Margaret: Need to cl= arify the terms.
Zhen Cao: Same problem with strong host model also. It = is not only the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 weak host model.
Dave Tha= ler: Asymmetric routing can cause the session go down but that
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is due filtering etc not the host mode= l.
Brian Carpenter: There's a architectural probelem that this docum= ent
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 starts building a s= olution already.
Ted Lemon: Two observations: the draft is already past = WGLC thus little
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to do. Agree there is an architectural probl= em.
Thomas: Seconds Brian. Architectural problem needs to be fixed befor= e
=A0=A0=A0=A0=A0=A0=A0 than doing other things in this space.
Scott:= =A0 Repeats.. get this document out and say these are the problems,
=A0=A0=A0=A0=A0=A0=A0 and MIF is not probably the group to solve those (ref= ers to
=A0=A0=A0=A0=A0=A0=A0 architectural problems).
Margaret: This = group was to figure out some of those point solutions
=A0=A0=A0=A0=A0=A0= =A0=A0=A0 that are needed. The group is not currently chartered to
=A0=A0=A0=A0=A0=A0=A0=A0=A0 solve the big (architectural) problem of all mi= f issues.
Jari: We can try find an architecture that we should have. How= ever,
=A0=A0=A0=A0=A0 that does not seem to be optimistic. This document= tries to
=A0=A0=A0=A0=A0 describe these. Still OK to fix some of the kn= own mif
=A0=A0=A0=A0=A0 problems.
Margatet: ..
Jari: Not always necessary to = define new protocols but document
=A0=A0=A0=A0=A0 existing stacks. That = is also useful.
Ted Lemon: Anybody here understand the architecture we t= ry to describe? :)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thinks one more scenario is missing but the = timing is bad to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 introduce anything new t= o the document.
Jari: Yes it is..
Ted:=A0 In the last IETF I complain= ed about one point solution because
=A0=A0=A0=A0=A0 my architectural view does not match what others had in min= d.
Scott: Not a problem statement only for the MIF WG but a problem
= =A0=A0=A0=A0=A0=A0 statement for the whole internet.
Marc blanket: Next = steps?
Margaret: Not going to define the architecture in this document. = Rather
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ask the 3 ADs whether the document can progress= as it is now.
Jari: Hoping to move it to LC.
Deng Hui:=A0 Ted's = issue/problem needs to be included?
Jari: Do not know what problem he is= referring. current document has
=A0=A0=A0=A0=A0 a limited scope. If the scope gets widened all kinds of
= =A0=A0=A0=A0=A0 new issues show up. Address Ted's issues/problem later.=
Ted: About different trusted provisioning domains. Those should be
= =A0=A0=A0=A0 explained. like DNS servers lie to you. You do not switch from=
=A0=A0=A0=A0 a working to nonworking sandbox..
Marc: This is already des= cribed but not in these exact words.
Jari: It is about there is one netw= ork that is more trusted than
=A0=A0=A0=A0=A0 other.. and that scenario = is already described.
Ted: It is about that the host automatically connects to
=A0=A0=A0=A0 un= authenticated WLAN when one comes up. Whether the user wants
=A0=A0=A0= =A0 or not. Other scenarios described on detail but not this.
Margaret: = Asks Ted to post his issues/problem/scenario to the list.
???:=A0 Points that 3484bis.. whether something has been missed
=A0=A0= =A0=A0=A0 regarding mif.
Margaret: Not really a problem of this WG? More= like 6MAN's that is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 working on 3484bis.=
>>draft-ietf-mif-current-practices-02
Apple section removed due lack of info.

3 Current Practice Analysis (5 min)
>> draft-cao-mif-anal= ysis-01
Margaret: Little feedback from the WG. Does the WG think we need to=A0=A0=A0=A0=A0=A0=A0=A0=A0 continue with this work?
Ted: Analysis and = current practices look the same.. confused..
Margaret: Should contains m= aterial that comes after current practices
=A0=A0=A0=A0=A0=A0=A0=A0=A0 when looking identified issues through the prob= lem statement.
Brian: Contains blanks.. those need to be filled in. Asks= for
=A0=A0=A0=A0=A0=A0 architectural analysis. The analysis that needs = to be in
=A0=A0=A0=A0=A0=A0 context of better architecture and not point= solutions. Someone
=A0=A0=A0=A0=A0=A0 needs to do an architectural analysis.
Scott: Agrees = with Brian. Need to fork the document. Need to
=A0=A0=A0=A0=A0=A0 contri= bute to the bigger architecture, which might be out of
=A0=A0=A0=A0=A0= =A0 scope of this group. i.e. two documents.
Ted: Thinks is ok.
Jari: I am interested. One document though.
Margar= et: The WG interested to do this? -> reasonable number shows
=A0=A0= =A0=A0=A0=A0=A0=A0=A0 hands. Please volunteer.
4 Working Group Documents
>> draft-ietf-mif-dns-server-select= ion-01 (Teemu, 10 min)
Most changes due the comments from Ted Lemon.
Andrew: Likes the improvements. Applications area said none of these=A0=A0=A0=A0=A0=A0=A0 (for DNSSEC) are deployed today. Need to have the r= evised text.
Teemu: Would you contribute the text (I do not know DNSSEC = and trust
=A0=A0=A0=A0=A0=A0 anchors in detail enough).
Peter Koch: A bit concerne= d about the operational issues. Is the trust
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 anchor used to distinguish which answer is a good one?
Teemu: Exp= lains the NXDOMAIN case with intra and extra DSN servers
=A0=A0=A0=A0=A0=A0 (both validates)
Ted: Split horizon issue.. I don'= ;t know how to deal with this
=A0=A0=A0=A0 problem and that is the reaso= n why this document was produced.
Peter: ...
Ted: Like the draft much= more now. The draft bases on that the
=A0=A0=A0=A0 mobile node trusting some provisioning domain more to select=A0=A0=A0=A0 the DNS server. I need to look more into this.
Teemu: ...=
Ted: How to distinguish between trusted domains?
Dave: What about th= e case where the host does synthesis and other
=A0=A0=A0=A0=A0 DNS server gives a native addresses? Which one to prefer.Andrew: Brings up validations and synthesis.. You are totally lost
=A0= =A0=A0=A0=A0=A0=A0 in that case.
Teemu: How about IPv4? Any support need= ed for it?
Ted: Did not even notice that (IPv4 being not addressed).
Teemu: Multihoming with IPv4 is even more pain. We have serious
=A0=A0= =A0=A0=A0=A0 problems there. Do we need to support for IPv4 or just
=A0= =A0=A0=A0=A0=A0 stick with IPv6?
Ted: Does not mind if it works only in = IPv6.
Teemu: Is ok not to support IPv4?
Margaret: We should do both..
Ted: Do not put IPv4 addresses into DHCPv6= .
Margaret: If IPv4 needed -> do DHCPv4 solution.
* general discussion different Mif models. IPv4 only WLAN,
=A0IPv4v= 6 (dual-stack) cellular.. in different domain.
Dave: Says having IPv4 in DHCPv6 could be ok.
Jari: ...
Dave: Wh= at is the use case where you need different server per
=A0=A0=A0=A0=A0 d= ifferent name space that are delivered in the same
=A0=A0=A0=A0=A0 DHCPv= 6 reply?
Margaret: Explains the two interfaces cases, two DHCP servers a= nd
=A0=A0=A0=A0=A0=A0=A0=A0=A0 several domains through those.
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ...
Ted: Brings up the case where DNS is = configured using RAs (RFC6106).
=A0=A0=A0=A0 Then this solution is not a= pplicable and one is tempted to use
=A0=A0=A0=A0 DHCPv4 options.
Ted: So may different scenarios that are not thought in this
=A0=A0=A0= =A0 document -> loads of standards work (DHCPv4, DHCPv6, ..)
Dapeng: = Need to support IPv4, maybe in a separate document.
Andrew: We seem to b= e tempted to do split DNS work reliably, which is
=A0=A0=A0=A0=A0=A0=A0 broken by definition. If you want to solve it in larg= e, it
=A0=A0=A0=A0=A0=A0=A0 won't work. scope it well.
Thomas: Be= tter scoping needed. Says only one DHCP response per
=A0=A0=A0=A0=A0=A0= =A0 interface and those have no conflict within an interface.
Margaret: Trying to provide hints that there is no need to query all
=A0= =A0=A0=A0=A0=A0=A0=A0=A0 known DNS servers to get an answer.
Thomas: Nee= d better scoping.
teemu: Move the discussion to the list.
>> draft-ietf-mif-dhcpv6-route-option-01 (Woj, 20 min)
Ted:=A0=A0=A0=A0=A0 Return nothing. (answer Woj's question).
Ma= rgaret: Not in IESG yet, rtg area doing review in advance.

5 Re-charter, milestone discussion
>> draft-liu-mif-api-extension-04
Note takes thinks most of these options are already provided
most = APIs.. like BSD ioctl()s.
xyz:=A0=A0=A0=A0 Why S_ADDR needed?
Dapend:=A0 You need to do speci= fy the source address.
Margaret: Sockets API already allows you to do th= at.
Marc:=A0=A0 RFC3542..?
Dave: Will send comments to list. Also dis= cussion about abstract API.
=A0=A0=A0=A0=A0 There was a WG consensus not to do concrete APIs.
Margat= et: Chartered to do abstract APIs.
Dave:=A0=A0 Austin Group owns the soc= kets API. For interface selection API
=A0=A0=A0=A0=A0=A0=A0 there is no = standard. We should look at what current OS
=A0=A0=A0=A0=A0=A0=A0 APIs provide.
Ted:=A0=A0=A0 Thinks the right way n= ow is rewrite the whole document. Wants
=A0=A0=A0=A0=A0=A0=A0 to be loop= as he has lots of ideas here.
Alan Ford: Seconds Dave. Points to mptcp = astract API work and asks for
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 collaboration.
jabber:=A0=A0=A0=A0=A0 Ask= s why not using advanced API from RFC3542?

>> draft-korhonen-mif-ra-offload-01 (Jouni, 10-15 min)
Alexandru Petrescu: Question whether both networks have to be
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 controlled by same a= dministrator.
Jouni:=A0=A0=A0=A0=A0=A0=A0=A0=A0 no, they don=92t have to= .
Ted Lemon: This document is more for addressing which network to prefe= r
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rather what address family to prefer. T= his approach could
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 have some security im= plications (misuse). Additionally
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 technical comment that shall be discussed of= fline.
>> draft-chen-mif-happy-eyeballs-extension-00 (Chen, 10 min)
= =A0=A0=A0=A0=A0=A0=A0=A0=A0 5.4 Multiple connections (Sri, if time allowed)=
scott:=A0 .. (missed)
--20cf3071c830c3efce04a1f04ffa--