From v6ops@globis.net Thu Sep 1 12:56:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5211121F92A7 for ; Thu, 1 Sep 2011 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWOILCO=1.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEzQtKYzskaC for ; Thu, 1 Sep 2011 12:56:34 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id A5FDF21F9292 for ; Thu, 1 Sep 2011 12:56:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C303C87005F; Thu, 1 Sep 2011 21:58:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvs4Ut7Ffeem; Thu, 1 Sep 2011 21:57:56 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 96D3E870085; Thu, 1 Sep 2011 21:57:55 +0200 (CEST) Message-ID: <4E5FE3C3.3000807@globis.net> Date: Thu, 01 Sep 2011 21:57:55 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: multipart/alternative; boundary="------------010203080906090705060703" Cc: satoru.matsushima@tm.softbank.co.jp, Ole Troan Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 19:56:35 -0000 This is a multi-part message in MIME format. --------------010203080906090705060703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit v6ops-request@ietf.org wrote: > Subject: > [v6ops] I-D Action: > draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt > From: > internet-drafts@ietf.org > Date: > Wed, 31 Aug 2011 23:23:37 -0700 > > To: > i-d-announce@ietf.org > CC: > v6ops@ietf.org > > Content-Transfer-Encoding: > quoted-printable > Precedence: > list > MIME-Version: > 1.0 > Message-ID: > <20110901062337.13131.28709.idtracker@ietfa.amsl.com> > Content-Type: > text/plain; charset="utf-8" > Message: > 1 > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : IPv6 Multihoming without Network Address Translation > Author(s) : Ole Troan > David Miles > Satoru Matsushima > Tadahisa Okimoto > Dan Wing > Filename : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt > Pages : 21 > Date : 2011-08-31 > > Network Address and Port Translation (NAPT) works well for conserving > global addresses and addressing multihoming requirements, because an > IPv4 NAPT router implements three functions: source address > selection, next-hop resolution and optionally DNS resolution. For > IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT > should be avoided, if at all possible, to permit transparent end-to- > end connectivity. In this document, we analyze the use cases of > multihoming. We also describe functional requirements and possible > solutions for multihoming without the use of NAT in IPv6 for hosts > and small IPv6 networks that would otherwise be unable to meet > minimum IPv6 allocation criteria. Nevertheless, we mention that the > possible needs for IPv6 NAT in the transition phase to the fully > deployment of the proposed solutions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt > > IMHO This is very useful work for the IETF, and I think multihoming will be very much a requirement for IPv6, and in particular homenet. The UK gas company has just announced today that it is rolling out smart meters to two million homes before the end of 2012. They will be equipped with GPRS for the Internet uplink and zigbee for the in-house communication to devices such as fridges etc. Multihoming will very likely become commonplace at least in Europe, as roll out of smart meters are the subject of an EU directive. You then have to ask whether you are going to treat this as a separate Internet, with home devices choosing to peer with just this smart meter Internet or just to another upstream connection in the home, or whether to use one as a backup for the upstream Internet link in a main/standby scenario. I think the consumer is going to expect that different Internet networks will cooperate to increase overall end to end reliability, and also to extend the range of e.g. zigbee around the home, which means there will be a need for the technology identified in this draft. There has been some discussion on this topic on another (non IETF) list, and on various other drafts. It seems to me that the problem for source and destination address selection, DNS server selection, and next hop selection, in a multi-homed environment without inter AS routing, shares a lot in common with the problem of selecting the "correct" address family ala Happy Eyeballs. The draft doesn't mention such parallels, which rather surprises me given the authors. I could certainly imagine a viable solution to simple multihoming in the absence of better (routing) information to be "assign all hosts a GUA IPv6 address from each upstream provider prefix. Each host can then try all combinations of DNS Server, source address, destination address, and next hop router, and remember/cache what worked to establish a working session for this source-destination pair." The policy could be used to handicap the order in which DNS servers and source and destination addresses and next hop are tested. Invalid combinations of source address and next hop will anyway be filtered by the ingress filters of any good ISP or homenet egress filter, so that won't cause any worrisome upstream traffic, just one or two wasted LAN packets. Another alternative is that ISP's will cooperate locally to "right home" any stray source address traffic asap into the correct upstream network via source address routing/policy based routing and local peering agreements. Which may still leave some minimal "overhead" upstream traffic to figure out which destination is available via which upstream ISP network, given that the home devices only have a simple default route. Again replies from a multi-homed desinatation would also be filtered for inappropriate combinations of source address/ next hop. So successful sessions should only be built over appropriate paths. There'd of course be a trade off between how many sessions you'd be prepared to kick off in parallel / wasted syn/syn acks / and session start up delay, versus the speed of detecting the working combination(s) between any source and destination pair where both the source and destination where multihomed. There'd also be some need to detect when to refresh/ age out the cache. But none of this needs to be fundamentally different to AF selection of Happy Eyeballs IMVHO. regards, RayH --------------010203080906090705060703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit v6ops-request@ietf.org wrote:
Subject:
[v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt
From:
internet-drafts@ietf.org
Date:
Wed, 31 Aug 2011 23:23:37 -0700
To:
i-d-announce@ietf.org
CC:
v6ops@ietf.org
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0
Message-ID:
<20110901062337.13131.28709.idtracker@ietfa.amsl.com>
Content-Type:
text/plain; charset="utf-8"
Message:
1		 

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : IPv6 Multihoming without Network Address Translation
	Author(s)       : Ole Troan
                          David Miles
                          Satoru Matsushima
                          Tadahisa Okimoto
                          Dan Wing
	Filename        : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt
	Pages           : 21
	Date            : 2011-08-31

   Network Address and Port Translation (NAPT) works well for conserving
   global addresses and addressing multihoming requirements, because an
   IPv4 NAPT router implements three functions: source address
   selection, next-hop resolution and optionally DNS resolution.  For
   IPv6 hosts one approach could be the use of IPv6 NAT.  However, NAT
   should be avoided, if at all possible, to permit transparent end-to-
   end connectivity.  In this document, we analyze the use cases of
   multihoming.  We also describe functional requirements and possible
   solutions for multihoming without the use of NAT in IPv6 for hosts
   and small IPv6 networks that would otherwise be unable to meet
   minimum IPv6 allocation criteria.  Nevertheless, we mention that the
   possible needs for IPv6 NAT in the transition phase to the fully
   deployment of the proposed solutions.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt
IMHO This is very useful work for the IETF, and I think multihoming will be very much a requirement for IPv6, and in particular homenet.

The UK gas company has just announced today that it is rolling out smart meters to two million homes before the end of 2012. They will be equipped with GPRS for the Internet uplink and zigbee for the in-house communication to devices such as fridges etc. Multihoming will very likely become commonplace at least in Europe, as roll out of smart meters are the subject of an EU directive. You then have to ask whether you are going to treat this as a separate Internet, with home devices choosing to peer with just this smart meter Internet or just to another upstream connection in the home, or whether to use one as a backup for the upstream Internet link in a main/standby scenario. I think the consumer is going to expect that different Internet networks will cooperate to increase overall end to end reliability, and also to extend the range of e.g. zigbee around the home, which means there will be a need for the technology identified in this draft.

There has been some discussion on this topic on another (non IETF) list, and on various other drafts.

It seems to me that the problem for source and destination address selection, DNS server selection, and next hop selection, in a multi-homed environment without inter AS routing, shares a lot in common with the problem of selecting the "correct" address family ala Happy Eyeballs.

The draft doesn't mention such parallels, which rather surprises me given the authors.

I could certainly imagine a viable solution to simple multihoming in the absence of better (routing) information to be "assign all hosts a GUA IPv6 address from each upstream provider prefix. Each host can then try all combinations of DNS Server, source address, destination address, and next hop router, and remember/cache what worked to establish a working session for this source-destination pair." The policy could be used to handicap the order in which DNS servers and source and destination addresses and next hop are tested.

Invalid combinations of source address and next hop will anyway be filtered by the ingress filters of any good ISP or homenet egress filter, so that won't cause any worrisome upstream traffic, just one or two wasted LAN packets.

Another alternative is that ISP's will cooperate locally to "right home" any stray source address traffic asap into the correct upstream network via source address routing/policy based routing and local peering agreements.

Which may still leave some minimal "overhead" upstream traffic to figure out which destination is available via which upstream ISP network, given that the home devices only have a simple default route. Again replies from a multi-homed desinatation would also be filtered for inappropriate combinations of source address/ next hop. So successful sessions should only be built over appropriate paths.

There'd of course be a trade off between how many sessions you'd be prepared to kick off in parallel / wasted syn/syn acks / and session start up delay, versus the speed of detecting the working combination(s) between any source and destination pair where both the source and destination where multihomed. There'd also be some need to detect when to refresh/ age out the cache.

But none of this needs to be fundamentally different to AF selection of Happy Eyeballs IMVHO.

regards,
RayH
--------------010203080906090705060703-- From dwing@cisco.com Thu Sep 1 16:16:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D67021F96D3 for ; Thu, 1 Sep 2011 16:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.469 X-Spam-Level: X-Spam-Status: No, score=-101.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWOILCO=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVcto49FJzTA for ; Thu, 1 Sep 2011 16:16:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3761521F96CF for ; Thu, 1 Sep 2011 16:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5658; q=dns/txt; s=iport; t=1314919062; x=1316128662; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=VXFRUJJBn/s6X3Nl5W4xuIfL37sbG2mHxV0n0Slxrdk=; b=WpuHGSygbKfLurD7NgEvvoAO0ogWSVzSzxcgWw17M2fZs8Hvss8ZmRDc 2YdoTEkt3v4CCOWpO4xUYRBFAf0GZ5bgi1RyUI45w3vyBE9BhULC35Z5D iPfbnlGQwnDqx/QpX6VjT9fxvoFYkp+j2kGM7tnhPw7RRzaKk7wRlOTpv I=; X-IronPort-AV: E=Sophos;i="4.68,316,1312156800"; d="scan'208";a="18672715" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 01 Sep 2011 23:17:41 +0000 Received: from dwingWS (dhcp-128-107-105-96.cisco.com [128.107.105.96]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p81NHfXZ031415; Thu, 1 Sep 2011 23:17:41 GMT From: "Dan Wing" To: "'Ray Hunter'" , References: <4E5FE3C3.3000807@globis.net> In-Reply-To: <4E5FE3C3.3000807@globis.net> Date: Thu, 1 Sep 2011 16:17:41 -0700 Message-ID: <065501cc68fd$58e44030$0aacc090$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acxo4Xn2N3+DOESeSIK7welc8OYUGgAGiYcA Content-Language: en-us Cc: 'Ole Troan' , satoru.matsushima@tm.softbank.co.jp, draft-chen-mif-happy-eyeballs-extension@tools.ietf.org, carlw@mcsr-labs.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 23:16:09 -0000 > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Thursday, September 01, 2011 12:58 PM > To: v6ops@ietf.org > Cc: Ole Troan; Dan Wing; t.okimoto@rdc.west.ntt.co.jp; > satoru.matsushima@tm.softbank.co.jp > Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without- > ipv6nat-01.txt ... > IMHO This is very useful work for the IETF, and I think multihoming > will be very much a requirement for IPv6, and in particular homenet. > > The UK gas company has just announced today that it is rolling out > smart meters to two million homes before the end of 2012. They will be > equipped with GPRS for the Internet uplink and zigbee for the in-house > communication to devices such as fridges etc. Multihoming will very > likely become commonplace at least in Europe, as roll out of smart > meters are the subject of an EU directive. You then have to ask whether > you are going to treat this as a separate Internet, with home devices > choosing to peer with just this smart meter Internet or just to another > upstream connection in the home, or whether to use one as a backup for > the upstream Internet link in a main/standby scenario. I think the > consumer is going to expect that different Internet networks will > cooperate to increase overall end to end reliability, and also to > extend the range of e.g. zigbee around the home, which means there will > be a need for the technology identified in this draft. > > There has been some discussion on this topic on another (non IETF) > list, and on various other drafts. > > It seems to me that the problem for source and destination address > selection, DNS server selection, and next hop selection, in a multi- > homed environment without inter AS routing, shares a lot in common with > the problem of selecting the "correct" address family ala Happy > Eyeballs. > > The draft doesn't mention such parallels, which rather surprises me > given the authors. So far, when there are multiple viable uplinks to the Internet, it seems one of them has a limitation of some sort -- it is slower (e.g., high latency such as 3G), more expensive (e.g., $ per KB), bandwidth capped (e.g., above 2GB per month the cost skyrockets). There is some sort of hand-waving 'policy' decision involved here. For example, if all your friends are visiting to watch the football game, you're probably going to spend the extra $5 to use your high-cost backup link. Someone else might be willing to use whichever upstream ISP can provide the fastest connection (but that might or might not correspond to the 'best' connection if round-trip time doesn't correspond to bandwidth). Someone else might only want to use an expensive backup link in an emergency (to call the fire department). The policy decisions aren't something Happy Eyeballs can help with too much. But, after the policy has decided that a certain interface should be tried, a Happy Eyeballs-like mechanism can be useful. The document draft-chen-mif-happy-eyeballs-extension is one place this interaction between policy and Happy Eyeballs is discussed. Andrew Yourtchenko gave a presentation at IETF81 which explains where we hope to separate Happy Eyeballs from the 'policy'. Slides are at http://www.ietf.org/proceedings/81/slides/mif-4.ppt and that room's audio should be http://www.ietf.org/audio/ietf81/ietf81-208ab-20110728-1256-pm.mp3 > I could certainly imagine a viable solution to simple multihoming in > the absence of better (routing) information to be "assign all hosts a > GUA IPv6 address from each upstream provider prefix. Each host can then > try all combinations of DNS Server, source address, destination > address, and next hop router, and remember/cache what worked to > establish a working session for this source-destination pair." The > policy could be used to handicap the order in which DNS servers and > source and destination addresses and next hop are tested. > > Invalid combinations of source address and next hop will anyway be > filtered by the ingress filters of any good ISP or homenet egress > filter, so that won't cause any worrisome upstream traffic, just one or > two wasted LAN packets. > > Another alternative is that ISP's will cooperate locally to "right > home" any stray source address traffic asap into the correct upstream > network via source address routing/policy based routing and local > peering agreements. The ISPs would have to know about each other to do that, and cooperate to achieve that. So far, even when they know about each other they don't do such cooperation. > Which may still leave some minimal "overhead" upstream traffic to > figure out which destination is available via which upstream ISP > network, given that the home devices only have a simple default route. > Again replies from a multi-homed desinatation would also be filtered > for inappropriate combinations of source address/ next hop. So > successful sessions should only be built over appropriate paths. > > There'd of course be a trade off between how many sessions you'd be > prepared to kick off in parallel / wasted syn/syn acks / and session > start up delay, versus the speed of detecting the working > combination(s) between any source and destination pair where both the > source and destination where multihomed. There'd also be some need to > detect when to refresh/ age out the cache. > > But none of this needs to be fundamentally different to AF selection of > Happy Eyeballs IMVHO. Agreed they are closely related. -d > regards, > RayH From internet-drafts@ietf.org Wed Sep 14 11:08:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29B021F8BE5; Wed, 14 Sep 2011 11:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3fiW3igMRFy; Wed, 14 Sep 2011 11:08:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCBD21F8BD7; Wed, 14 Sep 2011 11:08:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914180818.5793.58299.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 11:08:18 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-happy-eyeballs-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:08:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Happy Eyeballs: Success with Dual-Stack Hosts Author(s) : Dan Wing Andrew Yourtchenko Filename : draft-ietf-v6ops-happy-eyeballs-04.txt Pages : 15 Date : 2011-09-14 When the IPv4 server and path is working but the IPv6 server or IPv6 path is down, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this delay, and provides an example algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-04.txt From dwing@cisco.com Wed Sep 14 11:15:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5014621F8CA0 for ; Wed, 14 Sep 2011 11:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaANVsQku1dO for ; Wed, 14 Sep 2011 11:15:10 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6BA21F8CA5 for ; Wed, 14 Sep 2011 11:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=519; q=dns/txt; s=iport; t=1316024240; x=1317233840; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=qwRn/qSGYkG4Nn0jBhHI3Ika2WriQ7GhH9PergHx5i0=; b=ZNBdYBC24uWIma9HVrWOJzHdc9qzsbZMyL/lGH4rKO5vbfxH8DQV6j1u 1jp5/an60EZnWAIhAPedl3RGFM7gIuKTKKOeW3/Is2RJ2+kcgC/QoSU71 SJ9Tn6VdfJ3MItfuv5gDMWLGhW60RjG/BR00S9jNCTUzP3EO8Wsom6Mp7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAN/ucE6rRDoH/2dsb2JhbABBmQ6BKY0PeIFaCAoBFQIQPw0FGFAjHAEEHheHWZY8AZ5Nhm4Eh26dFg X-IronPort-AV: E=Sophos;i="4.68,381,1312156800"; d="scan'208";a="2133036" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 14 Sep 2011 18:17:15 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8EIHFcK032517; Wed, 14 Sep 2011 18:17:15 GMT From: "Dan Wing" To: Date: Wed, 14 Sep 2011 11:17:15 -0700 Message-ID: <009501cc730a$882009d0$98601d70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxzCofFxjoDOG4sSxaHHPk8ys5o4g== Content-Language: en-us Cc: draft-ietf-v6ops-happy-eyeballs@tools.ietf.org Subject: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:15:11 -0000 We just posted draft-ietf-v6ops-happy-eyeballs-04, which includes the following changes: o Better explained why IPv6 needs to be preferred o Don't query A6 and some other general editing and clarification based on feedback we received. Side-by-side differences are at http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-happy-eyeballs-04.txt Comments welcome. The authors feel this document is probably about ready for WGLC -- there isn't much more that can be said about this topic. -d From fred@cisco.com Wed Sep 14 11:58:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060CE21F8CC5 for ; Wed, 14 Sep 2011 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjAbOHeLukBP for ; Wed, 14 Sep 2011 11:58:11 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8073321F8CC2 for ; Wed, 14 Sep 2011 11:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2774; q=dns/txt; s=iport; t=1316026821; x=1317236421; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=uKBhIkKz+xPVh8t3tLlr8uoVBYf+ehwmngDS+6myhlQ=; b=cQLxMrGA0EbjsFnqyYfnRnWPgu7aykY+LBuhSgeiJk/7pd6uqR6jGvnJ MQLKJjb3blAH4POYJy9RRz4y2mgigTuT3x62l6e89WnZoFBAf3nESHDkK y5tBVaLSunjT50Nku3PICXtUUL+C7tLsQZXBCVlo9ahvU7zH0VoEgyQi/ Q=; X-IronPort-AV: E=Sophos;i="4.68,382,1312156800"; d="scan'208";a="2143181" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 14 Sep 2011 19:00:21 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8EJ0KH2024744; Wed, 14 Sep 2011 19:00:21 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Wed, 14 Sep 2011 12:00:21 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Wed, 14 Sep 2011 12:00:21 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <009501cc730a$882009d0$98601d70$@com> Date: Wed, 14 Sep 2011 12:00:12 -0700 Message-Id: <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> References: <009501cc730a$882009d0$98601d70$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:58:12 -0000 Reading through, I could imagine some edits for english prose, which I = might suggest during last call, but unless the WG has comments, I think = it's close. That said... I find it a little odd to make this about IPv6 vs IPv4; the same problem = happens if the system has multiple IPv4 addresses, one of which has = inconsistent connectivity or routing, or if the system has multiple IPv6 = addresses one of which has inconsistent connectivity or routing. You see = it as an IPv6 deployment problem that conceivably goes away with IPv4; I = see it as a multihoming problem that will happen to any system that has = multiple viable addresses. If you want, I can suggest text changes that = would reflect a multihoming perspective. One place where this comes up in spades is in section 4.4, the comment = that HTTP: The design of some sites can break because of HTTP cookies that incorporate the client's IP address and require all connections be from the same IP address.=20 No doubt some http sites are of that persuasion. I'll bet they change = their persuasion as Microsoft's privacy addressing (which changes the = address it initiates connections with daily) becomes prevalent. In an = IPv4 world it might make some sense, although laptops that move from LAN = to LAN frequently are an issue. In an IPv6 world with = constantly-changing addresses, it is untenable. I think it might be of = value to simply say that. If I were to suggest text, it would start from the perspective that at = any given time a host has a set of addresses, which might at any time = include zero or more (not just zero or one) IPv4 and zero or more (not = just zero or one) IPv6 addresses, and in any event changes over time for = multiple reasons. Any state maintained might score prefix pairs (peer = prefix and my prefix) and over time be used both in suggesting the first = to try and one that might want to be retried in case something had = changed. On Sep 14, 2011, at 11:17 AM, Dan Wing wrote: > We just posted draft-ietf-v6ops-happy-eyeballs-04, which includes the > following changes: >=20 > o Better explained why IPv6 needs to be preferred > o Don't query A6 >=20 > and some other general editing and clarification based on feedback we > received. >=20 >=20 > Side-by-side differences are at > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-happy-eyeballs-04.tx= t >=20 > Comments welcome. The authors feel this document is probably about = ready > for WGLC -- there isn't much more that can be said about this topic. >=20 > -d >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Wed Sep 14 12:05:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3394E21F8D20 for ; Wed, 14 Sep 2011 12:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ4kASu2F+cE for ; Wed, 14 Sep 2011 12:05:36 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6F821F8D1C for ; Wed, 14 Sep 2011 12:05:36 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 31CCD2AF85; Wed, 14 Sep 2011 15:07:46 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 14 Sep 2011 15:07:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=kD4 SOpxzx58EZtGCEyq2Wi/oYTg=; b=eW8my/ASDqeW3l+IBSTbW2uKKU9r+GYJmkY V6ksq224VUg4q0H8p7gQPeJN0rpgJU3aauZq1XaoE9QmsPEbH1U9GVnqA+2RK/3H 33MpKgYTgw1OeLbsyN0qXoG/8fRSbGOxvzDxLKDdHqBt6Yw34829QFKlV42+cIhi vdIidw74= X-Sasl-enc: JrCubVBhi1oZeAuubqL5QCzxZX6ftHUxucYCigRu5dFg 1316027265 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E3F054077B; Wed, 14 Sep 2011 15:07:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23-565131884 From: Keith Moore In-Reply-To: <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> Date: Wed, 14 Sep 2011 15:07:44 -0400 Message-Id: References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 19:05:37 -0000 --Apple-Mail-23-565131884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 14, 2011, at 3:00 PM, Fred Baker wrote: > I find it a little odd to make this about IPv6 vs IPv4; the same = problem happens if the system has multiple IPv4 addresses, one of which = has inconsistent connectivity or routing, or if the system has multiple = IPv6 addresses one of which has inconsistent connectivity or routing. = You see it as an IPv6 deployment problem that conceivably goes away with = IPv4; I see it as a multihoming problem that will happen to any system = that has multiple viable addresses. +1. And the problem certainly doesn't go away when IPv4 goes away; = actually the v6 idea of having multiple prefixes per network segment = exacerbates the problem. Keith --Apple-Mail-23-565131884 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I find it a = little odd to make this about IPv6 vs IPv4; the same problem happens if = the system has multiple IPv4 addresses, one of which has inconsistent = connectivity or routing, or if the system has multiple IPv6 addresses = one of which has inconsistent connectivity or routing. You see it as an = IPv6 deployment problem that conceivably goes away with IPv4; I see it = as a multihoming problem that will happen to any system that has = multiple viable addresses.

+1. =  And the problem certainly doesn't go away when IPv4 goes away; = actually the v6 idea of having multiple prefixes per network segment = exacerbates the = problem.

Keith

= --Apple-Mail-23-565131884-- From brian.e.carpenter@gmail.com Wed Sep 14 15:15:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C521F8D57 for ; Wed, 14 Sep 2011 15:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BlHf36sIeLr for ; Wed, 14 Sep 2011 15:15:23 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92D8D21F8D62 for ; Wed, 14 Sep 2011 15:15:23 -0700 (PDT) Received: by yie12 with SMTP id 12so2041969yie.31 for ; Wed, 14 Sep 2011 15:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eeejQnbCP2sSK3wujyQwDK5xgD0S9DyKaWymAzcw1bw=; b=UeVwrWcIG5lweUJyFgtv2MItOXOx9lcVxFlS/Acg/OoPDjAX1rlo9b1ima6lAOgQP7 BFdc0Du65+nOH6xL7imwEFYOD7FB7Gq2xt8UG9lfCYirrwfrqst0ThloBODAh05eN1n8 XjzmpdM+J6UMBz8/Dco2xAiJSsisl6aQmid+Q= Received: by 10.236.175.66 with SMTP id y42mr2101629yhl.108.1316038652341; Wed, 14 Sep 2011 15:17:32 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id z24sm1674807yhj.5.2011.09.14.15.17.29 (version=SSLv3 cipher=OTHER); Wed, 14 Sep 2011 15:17:31 -0700 (PDT) Message-ID: <4E7127D6.8070206@gmail.com> Date: Thu, 15 Sep 2011 10:16:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 22:15:24 -0000 On 2011-09-15 07:07, Keith Moore wrote: > On Sep 14, 2011, at 3:00 PM, Fred Baker wrote: > >> I find it a little odd to make this about IPv6 vs IPv4; the same problem happens if the system has multiple IPv4 addresses, one of which has inconsistent connectivity or routing, or if the system has multiple IPv6 addresses one of which has inconsistent connectivity or routing. You see it as an IPv6 deployment problem that conceivably goes away with IPv4; I see it as a multihoming problem that will happen to any system that has multiple viable addresses. > > +1. And the problem certainly doesn't go away when IPv4 goes away; actually the v6 idea of having multiple prefixes per network segment exacerbates the problem. I can't speak to multiple IPv4 addresses, which strikes me as an uninteresting problem since we are within ~3 years of running out of them. For multiple IPv6 addresses, we already have a standardised solution, and there are learnings from that solution about the performance of reachability testing. If I may toot my own trumpet: http://www.cs.auckland.ac.nz/~brian/iccnt2010_reap.pdf H. Naderi, B. Carpenter, A Performance Study on REAchability Protocol in Large Scale IPv6 Networks, Second International Conference on Computer and Network Technology (ICCNT 2010), Bangkok, (April 2010) 28-32. The advantages of shim6 are that its logic is hidden below the socket interface, and that it directly negotiates the address set in use, bypassing extra DNS calls. This seems like a useful complement to happy-eyeballs. Brian From dwing@cisco.com Wed Sep 14 18:33:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC94121F8B8D for ; Wed, 14 Sep 2011 18:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNOS7S+hg1iv for ; Wed, 14 Sep 2011 18:33:50 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 003E921F8B86 for ; Wed, 14 Sep 2011 18:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6181; q=dns/txt; s=iport; t=1316050560; x=1317260160; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=mkqGo2bJEDGcPwqAB7ZlCa+uBEnuc96cgSiZIKim73E=; b=KvODGoqlBT4h49tAeLk4OpZG05Np4n4BxvB+Uk4AFyxBwhwpPq9whO1R pAmTt5mpm78hHLj92KH4ksofIAxtlupgyKs6zPkoC9eXJzW+hgmW5gVve zgPL8wGgbMtpIs8a6BNtXsYfA05/Oxh67l5UtX6MJG7EE4ruxJSlC7Yu1 w=; X-IronPort-AV: E=Sophos;i="4.68,384,1312156800"; d="scan'208";a="2213034" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 15 Sep 2011 01:35:59 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8F1Zwt7025507; Thu, 15 Sep 2011 01:35:58 GMT From: "Dan Wing" To: "'Fred Baker'" References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> In-Reply-To: <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> Date: Wed, 14 Sep 2011 18:35:57 -0700 Message-ID: <024701cc7347$d12a14d0$737e3e70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxzEJJqZ9pRqOimTPmS3XFtqMIuBwAMstbg Content-Language: en-us Cc: 'IPv6 Operations' Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 01:33:50 -0000 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, September 14, 2011 12:00 PM > To: Dan Wing > Cc: IPv6 Operations > Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 > > Reading through, I could imagine some edits for english prose, which I > might suggest during last call, but unless the WG has comments, I think > it's close. That said... > > I find it a little odd to make this about IPv6 vs IPv4; That is the industry's pain point at the moment. > the same > problem happens if the system has multiple IPv4 addresses, one of which > has inconsistent connectivity or routing, or if the system has multiple > IPv6 addresses one of which has inconsistent connectivity or routing. Happy Eyeballs is trying to solve the immediate problem, which is a host with one IPv4 address and one IPv6 address. Most hosts don't have multiple (active) IPv4 interfaces today. It's true that many of us plug our laptops into Ethernet while our radios are on (thus, two IPv4 addresses), but I do not believe it has been a significant enough problem that it warrants the IETF making suggestions to implementers for IPv4. I agree that a host with multiple IPv6 addresses will occur. But those other addresses are also likely to have special characteristics, such as additional cost or bandwidth limits (e.g., 3G, satellite) which will cause people to only use them as a very "last resort" or only after doing something special to enable that "costly" interface. Andrew gave a presentation at IETF81 in MIF about the future of draft-chen-mif-happy-eyeballs-extension (*) where we hope to bring together "policy" (to filter which interfaces a user wants to use) with happy eyeballs (to quickly make connection attempts using those interfaces as the source address). (*) http://www.ietf.org/proceedings/81/slides/mif-4.ppt > You see it as an IPv6 deployment problem that conceivably goes away > with IPv4; I see it as a multihoming problem that will happen to any > system that has multiple viable addresses. If you want, I can suggest > text changes that would reflect a multihoming perspective. > > One place where this comes up in spades is in section 4.4, the comment > that > > HTTP: The design of some sites can break because of HTTP cookies > that incorporate the client's IP address and require all > connections be from the same IP address. > > No doubt some http sites are of that persuasion. There are not many. I know of a specific banking site that does exactly that. I know both Google Plus and Facebook do not directly include the client IP address as authentication information, as I remain am often able to use them without re-authenticating when my IP address changes. These sorts of things can be done smartly, too -- if you use the same 3-4 addresses, for example; and to accommodate IPv6 privacy addressing, the authentication could just remember the first 64 bits of the IPv6 address. > I'll bet they change > their persuasion as Microsoft's privacy addressing (which changes the > address it initiates connections with daily) becomes prevalent. Yes, I agree some sites may not want to force the user to re- authenticate every day -- it creates an extra burden to using the site. > In an > IPv4 world it might make some sense, although laptops that move from > LAN to LAN frequently are an issue. In an IPv6 world with constantly- > changing addresses, it is untenable. I think it might be of value to > simply say that. > If I were to suggest text, it would start from the perspective that at > any given time a host has a set of addresses, which might at any time > include zero or more (not just zero or one) IPv4 and zero or more (not > just zero or one) IPv6 addresses, and in any event changes over time > for multiple reasons. I revised the paragraph as follows. New and modified lines start with "*", HTTP: The design of some sites can break because of HTTP cookies that incorporate the client's IP address and require all connections be from the same IP address. If some connections from the same client are arriving from different IP addresses (or worse, different * IP address families), such applications will break. Such a design is * discouraged, because the host may legitimately change its IP address * because of IPv6 Privacy Addresses [RFC4941], because one interface * went down, traffic on an interface was slow (and became a less- * preferred interface), or network policy changed * [I-D.ietf-6man-addr-select-opt]). Additionally for HTTP, using the non-winning connection can interfere with the browser's Same Origin Policy (see Section 5.8). If we want to provide more guidance to developers of HTTP sites and how they can work with IPv6, it probably needs to be in a W3C documents or an IETF apps-area document? > Any state maintained might score prefix pairs > (peer prefix and my prefix) and over time be used both in suggesting > the first to try and one that might want to be retried in case > something had changed. A browser's same origin policy will already 'stick' with the previously- working address. Right now, that is only overridden by someone doing a Shift-Reload (or equivalent). -d > On Sep 14, 2011, at 11:17 AM, Dan Wing wrote: > > > We just posted draft-ietf-v6ops-happy-eyeballs-04, which includes the > > following changes: > > > > o Better explained why IPv6 needs to be preferred > > o Don't query A6 > > > > and some other general editing and clarification based on feedback we > > received. > > > > > > Side-by-side differences are at > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-happy-eyeballs- > 04.txt > > > > Comments welcome. The authors feel this document is probably about > ready > > for WGLC -- there isn't much more that can be said about this topic. > > > > -d > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed Sep 14 19:20:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91A921F8A70 for ; Wed, 14 Sep 2011 19:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuZ4sktLZsfS for ; Wed, 14 Sep 2011 19:20:36 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46421F8A6C for ; Wed, 14 Sep 2011 19:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2419; q=dns/txt; s=iport; t=1316053367; x=1317262967; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=g4s6afFhe7wbE65SYYdEj+au8P1RpALufwRJIVi3jnc=; b=DsLzfO51odnd55PH2XG1vAARVQjyQollk9uk5wYT7lIRtRmSgPrOnZTg qSveHa8lM+n/3qGl9XutG4ebk+St4PCrkkJVaLdy0PsfZAv+jbzlUGW85 qJkYflTtiqULZfMR//YB8J/NzS4G8VLvper4qHL3VhRRb1A2z1CX8czFH Q=; X-IronPort-AV: E=Sophos;i="4.68,384,1312156800"; d="scan'208";a="2211833" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 15 Sep 2011 02:22:47 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8F2Mked008568; Thu, 15 Sep 2011 02:22:46 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Wed, 14 Sep 2011 19:22:46 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Wed, 14 Sep 2011 19:22:46 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <024701cc7347$d12a14d0$737e3e70$@com> Date: Wed, 14 Sep 2011 19:22:37 -0700 Message-Id: <91A43DDB-7ABC-45CB-8B2B-7F0390242EF6@cisco.com> References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <024701cc7347$d12a14d0$737e3e70$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Operations' Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 02:20:37 -0000 On Sep 14, 2011, at 6:35 PM, Dan Wing wrote: >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Wednesday, September 14, 2011 12:00 PM >> To: Dan Wing >> Cc: IPv6 Operations >> Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 >>=20 >> Reading through, I could imagine some edits for english prose, which = I >> might suggest during last call, but unless the WG has comments, I = think >> it's close. That said... >>=20 >> I find it a little odd to make this about IPv6 vs IPv4; >=20 > That is the industry's pain point at the moment. =20 Well, yes, but RFCs often last for a while longer than "the industry = pain point of the moment" >> In an >> IPv4 world it might make some sense, although laptops that move from >> LAN to LAN frequently are an issue. In an IPv6 world with constantly- >> changing addresses, it is untenable. I think it might be of value to >> simply say that. >> If I were to suggest text, it would start from the perspective that = at >> any given time a host has a set of addresses, which might at any time >> include zero or more (not just zero or one) IPv4 and zero or more = (not >> just zero or one) IPv6 addresses, and in any event changes over time >> for multiple reasons. >=20 > I revised the paragraph as follows. New and modified lines start=20 > with "*", >=20 > HTTP: The design of some sites can break because of HTTP cookies > that incorporate the client's IP address and require all connections > be from the same IP address. If some connections from the same > client are arriving from different IP addresses (or worse, different > * IP address families), such applications will break. Such a design = is > * discouraged, because the host may legitimately change its IP = address > * because of IPv6 Privacy Addresses [RFC4941], because one interface > * went down, traffic on an interface was slow (and became a less- > * preferred interface), or network policy changed > * [I-D.ietf-6man-addr-select-opt]). Additionally for HTTP, using the > non-winning connection can interfere with the browser's Same Origin > Policy (see Section 5.8). >=20 > If we want to provide more guidance to developers of HTTP sites and > how they can work with IPv6, it probably needs to be in a W3C=20 > documents or an IETF apps-area document? Works for me. Thanks. From brian.e.carpenter@gmail.com Wed Sep 14 20:52:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAC821F84D8 for ; Wed, 14 Sep 2011 20:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCYirbNLpDan for ; Wed, 14 Sep 2011 20:52:20 -0700 (PDT) Received: from mail-pz0-f46.google.com (mail-pz0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7021F84D7 for ; Wed, 14 Sep 2011 20:52:20 -0700 (PDT) Received: by pzk32 with SMTP id 32so1407002pzk.19 for ; Wed, 14 Sep 2011 20:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t+0qRVtgH2pJuswya/P2Wq81T1UHMvg3Pb92aZJUi5M=; b=WnKexY+0YL7Xmzt75P93cY1h7za4hwIqf5sJ7Krovvr41+JaahNV4ITTTQOVrlnE7H mVG+Z48wD+fZyjkQOq0qVo0Gh4eKI3GPh5bXgBfzZUx/zgkoSRzquWG659iDmgQaHLWm DA9xxJEvVpoNeUUM+IN4o1ouiBvxJyRcNGLgQ= Received: by 10.68.41.136 with SMTP id f8mr1182091pbl.196.1316058870830; Wed, 14 Sep 2011 20:54:30 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id f8sm19136287pbc.3.2011.09.14.20.54.28 (version=SSLv3 cipher=OTHER); Wed, 14 Sep 2011 20:54:30 -0700 (PDT) Message-ID: <4E717718.2080007@gmail.com> Date: Thu, 15 Sep 2011 15:55:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <024701cc7347$d12a14d0$737e3e70$@com> In-Reply-To: <024701cc7347$d12a14d0$737e3e70$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'IPv6 Operations' Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 03:52:20 -0000 Dan, > -- if you use the same 3-4 addresses, for example; > and to accommodate IPv6 privacy addressing, the authentication could > just remember the first 64 bits of the IPv6 address. Um, that would "authenticate" anyone on the same subnet, for example someone else on the same free public Wi-Fi. Regards Brian Carpenter From dwing@cisco.com Wed Sep 14 21:48:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E47B21F877F for ; Wed, 14 Sep 2011 21:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1e9jsRItXiL for ; Wed, 14 Sep 2011 21:48:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 415E221F85C7 for ; Wed, 14 Sep 2011 21:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=734; q=dns/txt; s=iport; t=1316062250; x=1317271850; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=l2OXp7BgsRiJY877pBjeW4qLyifwu/eeWRT+ARSuMh8=; b=dZfCBGQVObqFGpgvnMrhbCsr/iAF6ehQ+wiN4n+HqaRZoZSApGcXucmG m0NX0DDpVfpAqozSQoMO5lPjcKc1nGjuWgdczNSwrY3uOV9UkJjBi9hx8 xEpj2cfLCPNEgh7LIKWVvdr+IlB9ABw/j6OmJwePneY3IhO/wlrVU13Z6 E=; X-IronPort-AV: E=Sophos;i="4.68,385,1312156800"; d="scan'208";a="115502891" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 15 Sep 2011 04:50:48 +0000 Received: from dwingWS ([10.32.240.194]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8F4ojSx003385; Thu, 15 Sep 2011 04:50:46 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <024701cc7347$d12a14d0$737e3e70$@com> <4E717718.2080007@gmail.com> In-Reply-To: <4E717718.2080007@gmail.com> Date: Wed, 14 Sep 2011 21:50:44 -0700 Message-ID: <029b01cc7363$089c0160$19d40420$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxzWyzvM5dB2rfORIWBNkJbhBYCmwAB6lQg Content-Language: en-us Cc: 'IPv6 Operations' Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 04:48:40 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Wednesday, September 14, 2011 8:55 PM > To: Dan Wing > Cc: 'Fred Baker'; 'IPv6 Operations' > Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 > > Dan, > > > -- if you use the same 3-4 addresses, for example; > > and to accommodate IPv6 privacy addressing, the authentication could > > just remember the first 64 bits of the IPv6 address. > > Um, that would "authenticate" anyone on the same subnet, for > example someone else on the same free public Wi-Fi. The 64 bits would not be the sole authenticator, any more so than the IPv4 address at Starbucks is not today's sole authenticator. -d From fred@cisco.com Wed Sep 14 22:39:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9090721F8715 for ; Wed, 14 Sep 2011 22:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiKta2ixz+KR for ; Wed, 14 Sep 2011 22:39:06 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0891B21F856B for ; Wed, 14 Sep 2011 22:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=484; q=dns/txt; s=iport; t=1316065277; x=1317274877; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=cV0Mfzm3HFiZFejy6+H6lSUGYZKWRKeJ85TD4tjsrMs=; b=Y0fFBhOi7++sKbHeMC+PhXRowbjS776+dy3OPENMX5jz66GLDrGHNmn9 PQ2qf2gCQO4rYL+Co+DHVFDpSWupS+7oSwqTexwzDrHSpyoJ4FXVaZjKY TwAUZtwrblisRMMVM6yyWXuu8gyjr7SSVJpWJqhTW71am6EKKrTnn0zjg Q=; X-IronPort-AV: E=Sophos;i="4.68,385,1312156800"; d="scan'208";a="2241158" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 15 Sep 2011 05:41:17 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8F5fGs1022954; Thu, 15 Sep 2011 05:41:16 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Wed, 14 Sep 2011 22:41:17 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Wed, 14 Sep 2011 22:41:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E717718.2080007@gmail.com> Date: Wed, 14 Sep 2011 22:41:09 -0700 Message-Id: <0287EE5D-445F-4E13-A69F-236D2F588569@cisco.com> References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <024701cc7347$d12a14d0$737e3e70$@com> <4E717718.2080007@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Operations' Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 05:39:06 -0000 On Sep 14, 2011, at 8:55 PM, Brian E Carpenter wrote: > Dan, >=20 >> -- if you use the same 3-4 addresses, for example; >> and to accommodate IPv6 privacy addressing, the authentication could >> just remember the first 64 bits of the IPv6 address. >=20 > Um, that would "authenticate" anyone on the same subnet, for > example someone else on the same free public Wi-Fi. I think he means the EID. That doesn't help with privacy addresses, but = it helps with EUI-64.= From joelja@bogus.com Sat Sep 17 13:27:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79621F8696 for ; Sat, 17 Sep 2011 13:27:58 -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.251, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFgU8JddUm+u for ; Sat, 17 Sep 2011 13:27:57 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C68A921F85EF for ; Sat, 17 Sep 2011 13:27:57 -0700 (PDT) Received: from Zorch.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p8HKUDfP034787 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 17 Sep 2011 20:30:14 GMT (envelope-from joelja@bogus.com) Message-ID: <4E750355.3070107@bogus.com> Date: Sat, 17 Sep 2011 13:30:13 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Keith Moore References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 17 Sep 2011 20:30:14 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 20:27:58 -0000 On 9/14/11 12:07 , Keith Moore wrote: > On Sep 14, 2011, at 3:00 PM, Fred Baker wrote: > >> I find it a little odd to make this about IPv6 vs IPv4; the same >> problem happens if the system has multiple IPv4 addresses, one of >> which has inconsistent connectivity or routing, or if the system has >> multiple IPv6 addresses one of which has inconsistent connectivity or >> routing. You see it as an IPv6 deployment problem that conceivably >> goes away with IPv4; I see it as a multihoming problem that will >> happen to any system that has multiple viable addresses. > > +1. And the problem certainly doesn't go away when IPv4 goes away; > actually the v6 idea of having multiple prefixes per network segment > exacerbates the problem. how is multiple prefixes per segment different than multiple segments with different prefixes? joel > Keith > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Sat Sep 17 14:15:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370B921F85D1 for ; Sat, 17 Sep 2011 14:15:54 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnowvaP7tbs3 for ; Sat, 17 Sep 2011 14:15:53 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 958E021F85CE for ; Sat, 17 Sep 2011 14:15:53 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id EF57A2B78A; Sat, 17 Sep 2011 17:18:11 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 17 Sep 2011 17:18:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=L/I5vpzMnvhtpnX6U3U08Rv4jNo=; b=Bb pNL9BOBN1FlwcrN+MGZKaV6moUTakaiph096Ss1YzKPLGC2yNUV1KHcvNDKgx8yu LcjNj1iI97eqPWl4DYGxamxua0iZYZ5/F6G7+lYE040xdf6gFVoNv9XMFcNRcris auymp98v/dUfEolY9rvHO2GB6usMHZ4LZjVumzBWM= X-Sasl-enc: oLra1bSw6swds+Olu9ZDl3WO87OJbR01NLpEmZCsHyrI 1316294291 Received: from [192.168.1.68] (adsl-98-86-50-19.tys.bellsouth.net [98.86.50.19]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C82B560229; Sat, 17 Sep 2011 17:18:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E750355.3070107@bogus.com> Date: Sat, 17 Sep 2011 17:18:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <4E750355.3070107@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 21:15:54 -0000 On Sep 17, 2011, at 4:30 PM, Joel jaeggli wrote: > On 9/14/11 12:07 , Keith Moore wrote: >> On Sep 14, 2011, at 3:00 PM, Fred Baker wrote: >>=20 >>> I find it a little odd to make this about IPv6 vs IPv4; the same >>> problem happens if the system has multiple IPv4 addresses, one of >>> which has inconsistent connectivity or routing, or if the system has >>> multiple IPv6 addresses one of which has inconsistent connectivity = or >>> routing. You see it as an IPv6 deployment problem that conceivably >>> goes away with IPv4; I see it as a multihoming problem that will >>> happen to any system that has multiple viable addresses. >>=20 >> +1. And the problem certainly doesn't go away when IPv4 goes away; >> actually the v6 idea of having multiple prefixes per network segment >> exacerbates the problem. >=20 > how is multiple prefixes per segment different than multiple segments > with different prefixes? If the prefixes on a segment aren't assured to be equivalent in terms of = scope and routability, it isn't. Keith From brian.e.carpenter@gmail.com Sat Sep 17 15:43:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A40721F8513 for ; Sat, 17 Sep 2011 15:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSgnK0blGQ2U for ; Sat, 17 Sep 2011 15:43:19 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D49B621F84CB for ; Sat, 17 Sep 2011 15:43:18 -0700 (PDT) Received: by fxd18 with SMTP id 18so3050626fxd.31 for ; Sat, 17 Sep 2011 15:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tUG6whOnwyYpGVGwJ9WlWFekRRiUIDz5zU2tCY1qw7g=; b=XN5vFSt3kq3tryJZVxqB+bw9Einsnb5Nj6YUNuqNHFhBrzUaMEniT1VF1y/ha2IBQo s2aAb/W5U2vYCn0XwKvQU3d2e3n8IL5kjhwbVuLrZDdZMPnmqb0fbC9mmcpb6eH6ysfI RKZCLmvkqrXTfTw/eICuTKXQIvr6aMT8c0kTU= Received: by 10.223.58.139 with SMTP id g11mr1973943fah.14.1316299533239; Sat, 17 Sep 2011 15:45:33 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id i5sm7205659fai.15.2011.09.17.15.45.29 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 15:45:32 -0700 (PDT) Message-ID: <4E7522FD.7060407@gmail.com> Date: Sun, 18 Sep 2011 10:45:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <4E750355.3070107@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 22:43:19 -0000 On 2011-09-18 09:18, Keith Moore wrote: > On Sep 17, 2011, at 4:30 PM, Joel jaeggli wrote: > >> On 9/14/11 12:07 , Keith Moore wrote: >>> On Sep 14, 2011, at 3:00 PM, Fred Baker wrote: >>> >>>> I find it a little odd to make this about IPv6 vs IPv4; the same >>>> problem happens if the system has multiple IPv4 addresses, one of >>>> which has inconsistent connectivity or routing, or if the system has >>>> multiple IPv6 addresses one of which has inconsistent connectivity or >>>> routing. You see it as an IPv6 deployment problem that conceivably >>>> goes away with IPv4; I see it as a multihoming problem that will >>>> happen to any system that has multiple viable addresses. >>> +1. And the problem certainly doesn't go away when IPv4 goes away; >>> actually the v6 idea of having multiple prefixes per network segment >>> exacerbates the problem. >> how is multiple prefixes per segment different than multiple segments >> with different prefixes? > > If the prefixes on a segment aren't assured to be equivalent in terms of scope and routability, it isn't. Indeed. As MIF has been discussing without exactly saying it, the concept of "default router" can become meaningless in some scenarios, and there is a complex relationship between which first-hop router the host chooses, which egress router that first-hop router chooses, and the existence or otherwise of ingress filtering in the transit provider that the egress router chooses. This is not simple and doesn't seem to be any business of application layer software. Brian From moore@network-heretics.com Sat Sep 17 15:55:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5DC21F86A0 for ; Sat, 17 Sep 2011 15:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwnMVVvs0-m for ; Sat, 17 Sep 2011 15:55:37 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1795E21F8678 for ; Sat, 17 Sep 2011 15:55:37 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9FA812B8D4; Sat, 17 Sep 2011 18:57:55 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 17 Sep 2011 18:57:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=26stC/kUUjuCm+2lbjZMo4wrXxM=; b=nf pCbJGPChixUBTz6/IT9IhytCBO5panK2/l1DdpfZXcEsNAnklxXB/kEorayM0oVx LmOHiPgNrN6/JdDtRbQfFy4xNqMllW26T5JCO85LEAyF0iJoOXDga0rTgDVBF8Ng vmQ946Nr34OcQ1xZINtL87Aa1fSVV7sx8Fim25VIM= X-Sasl-enc: ZyNkCU7UIkqm+pMNXZU/ofN7tUr0YnwpVAZS3Au3EN4i 1316300275 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A2B6C5602AE; Sat, 17 Sep 2011 18:57:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E7522FD.7060407@gmail.com> Date: Sat, 17 Sep 2011 18:57:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86CCE501-D136-4768-BE32-A769047246BB@network-heretics.com> References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <4E750355.3070107@bogus.com> <4E7522FD.7060407@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 22:55:37 -0000 On Sep 17, 2011, at 6:45 PM, Brian E Carpenter wrote: >>> how is multiple prefixes per segment different than multiple = segments >>> with different prefixes? >>=20 >> If the prefixes on a segment aren't assured to be equivalent in terms = of scope and routability, it isn't. >=20 > Indeed. As MIF has been discussing without exactly saying it, the = concept > of "default router" can become meaningless in some scenarios, and = there > is a complex relationship between which first-hop router the host > chooses, which egress router that first-hop router chooses, and the > existence or otherwise of ingress filtering in the transit provider > that the egress router chooses. >=20 > This is not simple and doesn't seem to be any business of application > layer software. ...except that the choice of source interface, source address, and = destination address are inherently influenced by application = considerations. It really matters to your application whether it gets = a path that is low or high bandwidth, low or high jitter, low or high = packet loss, low or high cost, whether the network connection continues = to forward packets as the host moves, whether the address-to-host = bindings are stable or ephemeral, whether the addresses used have global = or limited scope, global or limited reachability, are filtered by = firewalls, etc. =20 Traditional internet service tries to be "good enough" in most of these = areas for most applications, but applications keep making more demands = of the network. But when you add wireless services, LSNs, ULIAs, etc. = to the mix you end up with different tradeoffs. Right now, the only = way for many applications to work effectively in a multiple interface / = multiple address environment is to try to manage interface and address = selection by itself. Keith From fred@cisco.com Sat Sep 17 16:11:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C807121F849C for ; Sat, 17 Sep 2011 16:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.78 X-Spam-Level: X-Spam-Status: No, score=-102.78 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xexQk5Vt6vTx for ; Sat, 17 Sep 2011 16:11:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0123021F849A for ; Sat, 17 Sep 2011 16:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1994; q=dns/txt; s=iport; t=1316301248; x=1317510848; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=+clYfKBY51WtZ5Y17mlK4ZGYNh9BKG2lH3I1BWeGMNw=; b=cIwbihRfGrKLjnJs12vWe4W8JYI2NEBvf3wXT6mBcS/mOOBl2K7dcNss G3BOcPSpT4gfxAD31im6x8wC0IAK1qUSBgpQRh1RcxgnnJfbL8B5P8eeU O8tU6fQwPKhE8T57na9p4hkRKv+pDS1Aat7+K9y2i0HFS7OwBe037FFww A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALAodU6rRDoH/2dsb2JhbABBp2J3gVMBAQEBAxIBJz8QC0ZXBjWfTwGdAIYYYASHb4tahR2MMA X-IronPort-AV: E=Sophos;i="4.68,399,1312156800"; d="scan'208";a="2778437" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 17 Sep 2011 23:14:08 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8HNE675007860; Sat, 17 Sep 2011 23:14:07 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Sat, 17 Sep 2011 16:14:07 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Sat, 17 Sep 2011 16:14:07 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <86CCE501-D136-4768-BE32-A769047246BB@network-heretics.com> Date: Sat, 17 Sep 2011 16:13:55 -0700 Message-Id: References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <4E750355.3070107@bogus.com> <4E7522FD.7060407@gmail.com> <86CCE501-D136-4768-BE32-A769047246BB@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 23:11:50 -0000 On Sep 17, 2011, at 3:57 PM, Keith Moore wrote: > ...except that the choice of source interface, source address, and = destination address are inherently influenced by application = considerations. It really matters to your application whether it gets = a path that is low or high bandwidth, low or high jitter, low or high = packet loss, low or high cost, whether the network connection continues = to forward packets as the host moves, whether the address-to-host = bindings are stable or ephemeral, whether the addresses used have global = or limited scope, global or limited reachability, are filtered by = firewalls, etc. =20 True enough. I'm drawing a blank, though. I once worked on a protocol = that would enable an application to get answers to those kinds of = questions. I don't know of applications that use it or any other OS API = that would get them that information, and I'm not altogether sure, if = someone asked me which one might help them, what API to point them to. As near as I can tell, applications translate a name into a set of = addresses, and by some algorithm pick a source address and connect to a = destination address. The history of RFC 3484 and its successors tells me = that absent information that hosts usually don't have - which you just = specified - picking an address pair is Really Hard. At most, you can = guess that if one address pair has a longer string of most significant = bits that are the same than another address pair has, that might be a = reasonable guess at which pair to try first. But it is just that - a = guess - and counterexamples abound. =46rom my perspective, the Happy Eyeballs considerations don't answer = all of those questions, but they do come up with a route (from the = host's perspective, an address pair) that can successfully exchange = datagrams in human-reasonable elapsed time. We haven't automated the job = of network design, nor have we put the operator out of a job.= From moore@network-heretics.com Sat Sep 17 16:18:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E723621F84CB for ; Sat, 17 Sep 2011 16:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlejpvl+WFRv for ; Sat, 17 Sep 2011 16:18:28 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4E821F84C9 for ; Sat, 17 Sep 2011 16:18:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DC6602B93B; Sat, 17 Sep 2011 19:20:44 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 17 Sep 2011 19:20:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=yy1Y+dco0wYBN07dYbXidR/BRgw=; b=Jl JiNNFKWKKRK4sWgxfIx1wqqwR0+MP/+VEgT5qrJ5mPz/aIGEGXZy7PgrQT91XlQ/ G9fu6Cm7vYdiEKBrpluY+oecfZF0a9kjRGA30ORpH6s4He5BStPUiUORS2MeYD6T k+LHKhQ59wgr9BL2o8QsyjY8DIgY/2hEIuBMOelEk= X-Sasl-enc: e82RZcdoGhGAHEdE6y4iqo6Al8DO6rIUylhbfM6NoYGA 1316301644 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BECEF5602C1; Sat, 17 Sep 2011 19:20:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sat, 17 Sep 2011 19:20:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <4E750355.3070107@bogus.com> <4E7522FD.7060407@gmail.com> <86CCE501-D136-4768-BE32-A769047246BB@network-heretics.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 23:18:29 -0000 On Sep 17, 2011, at 7:13 PM, Fred Baker wrote: > On Sep 17, 2011, at 3:57 PM, Keith Moore wrote: >=20 >> ...except that the choice of source interface, source address, and = destination address are inherently influenced by application = considerations. It really matters to your application whether it gets = a path that is low or high bandwidth, low or high jitter, low or high = packet loss, low or high cost, whether the network connection continues = to forward packets as the host moves, whether the address-to-host = bindings are stable or ephemeral, whether the addresses used have global = or limited scope, global or limited reachability, are filtered by = firewalls, etc. =20 >=20 > True enough. I'm drawing a blank, though. I once worked on a protocol = that would enable an application to get answers to those kinds of = questions. I don't know of applications that use it or any other OS API = that would get them that information, and I'm not altogether sure, if = someone asked me which one might help them, what API to point them to. And I once tried to design an API that would do that, and it ended up = looking so complex that I couldn't convince myself that it would get = much use. (Which doesn't mean, of course, that my first stab at the = problem is the best solution possible. Actually I think that multipath = TCP has a lot of promise at being more general - though not universal -, = particularly if the app can somehow tell the network stack something = about what kinds of paths to favor.) > As near as I can tell, applications translate a name into a set of = addresses, and by some algorithm pick a source address and connect to a = destination address. The history of RFC 3484 and its successors tells me = that absent information that hosts usually don't have - which you just = specified - picking an address pair is Really Hard. At most, you can = guess that if one address pair has a longer string of most significant = bits that are the same than another address pair has, that might be a = reasonable guess at which pair to try first. But it is just that - a = guess - and counterexamples abound. yes. > =46rom my perspective, the Happy Eyeballs considerations don't answer = all of those questions, but they do come up with a route (from the = host's perspective, an address pair) that can successfully exchange = datagrams in human-reasonable elapsed time. Happy Eyeballs is just fine for the part of the problem that it purports = to solve. Last time I looked anyway, it didn't claim to be an = all-encompassing solution. It's definitely worth abstracting happy = eyeballs for applications that work well with it, we just shouldn't = pretend that it solves the general problem. > We haven't automated the job of network design, nor have we put the = operator out of a job. No, but there has been pressure of various kinds to make the host and/or = app take on part of the role of what traditionally was exclusively the = networks' job. Keith From fred@cisco.com Sat Sep 17 16:39:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5A021F86A4 for ; Sat, 17 Sep 2011 16:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKUgyXTOfKDt for ; Sat, 17 Sep 2011 16:39:13 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BA50621F8678 for ; Sat, 17 Sep 2011 16:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3193; q=dns/txt; s=iport; t=1316302892; x=1317512492; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=pLf8k+aKHNa+l+Eme8i+Wq0vcdKjBvnDV7nmw/OzPrI=; b=PAjLXdxTp8pjwHYl3UGaTVSsoqME/sW4vaF3n6wgjRCGadwAbR4V3pjD N55ClPBKJ8uvTSh47fNtM23pqnm3UG+Lt33KEMFEds4zUC0Wj8HvEPGi+ 4B0HoJElEMXerO1vV7SnNQ8bYaTuD8gqk7+0JaMlIRrIAwDIFPuBSrLcj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKwvdU6rRDoH/2dsb2JhbABBp2J3gVMBAQEBAgESASc/EAsYLlcGLgeHVZg5AZ0AhhhgBIdvi1qFHYww X-IronPort-AV: E=Sophos;i="4.68,399,1312156800"; d="scan'208";a="2779145" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 17 Sep 2011 23:41:31 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8HNfT7g017247; Sat, 17 Sep 2011 23:41:29 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Sat, 17 Sep 2011 16:41:30 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Sat, 17 Sep 2011 16:41:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 17 Sep 2011 16:41:16 -0700 Message-Id: <656BA5E6-F254-481F-8BFB-BBD08411E484@cisco.com> References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <4E750355.3070107@bogus.com> <4E7522FD.7060407@gmail.com> <86CCE501-D136-4768-BE32-A769047246BB@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 23:39:14 -0000 On Sep 17, 2011, at 4:20 PM, Keith Moore wrote: > On Sep 17, 2011, at 7:13 PM, Fred Baker wrote: >> On Sep 17, 2011, at 3:57 PM, Keith Moore wrote: >>> ...except that the choice of source interface, source address, and = destination address are inherently influenced by application = considerations. It really matters to your application whether it gets = a path that is low or high bandwidth, low or high jitter, low or high = packet loss, low or high cost, whether the network connection continues = to forward packets as the host moves, whether the address-to-host = bindings are stable or ephemeral, whether the addresses used have global = or limited scope, global or limited reachability, are filtered by = firewalls, etc. =20 >>=20 >> True enough. I'm drawing a blank, though. I once worked on a protocol = that would enable an application to get answers to those kinds of = questions. I don't know of applications that use it or any other OS API = that would get them that information, and I'm not altogether sure, if = someone asked me which one might help them, what API to point them to. >=20 > And I once tried to design an API that would do that, and it ended up = looking so complex that I couldn't convince myself that it would get = much use. (Which doesn't mean, of course, that my first stab at the = problem is the best solution possible. Actually I think that multipath = TCP has a lot of promise at being more general - though not universal -, = particularly if the app can somehow tell the network stack something = about what kinds of paths to favor.) Well, yes, sort of. What mptcp can do is open a single session from a = set of addresses to a set of addresses. In operation, it could send data = across the cross-product of those sets and discard address pairs that = seem suboptimal. Note "seem"; it doesn't know the rate of the bottleneck = on any given path, nor its current routing, nor much of anything else. = It knows that last time it tried an address pair it liked or didn't like = what it experienced.=20 >> =46rom my perspective, the Happy Eyeballs considerations don't answer = all of those questions, but they do come up with a route (from the = host's perspective, an address pair) that can successfully exchange = datagrams in human-reasonable elapsed time. >=20 > Happy Eyeballs is just fine for the part of the problem that it = purports to solve. Last time I looked anyway, it didn't claim to be an = all-encompassing solution. It's definitely worth abstracting happy = eyeballs for applications that work well with it, we just shouldn't = pretend that it solves the general problem. To my knowledge, nobody has suggested it solved a general problem. It = does a better job on the problem it does try to solve than approaches = that preceded it. I would invite a better solution. If it involves a protocol, and I can't = imagine it doesn't (today's routing protocols don't address the set of = issues you bring up either, and I think you're describing routing in at = least a general sense), I would suggest you take it to the routing ADs = and ask advice on where it might fit.= From moore@network-heretics.com Sat Sep 17 17:13:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89521F8564 for ; Sat, 17 Sep 2011 17:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njFxW+2GvSkl for ; Sat, 17 Sep 2011 17:13:26 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id A703421F8562 for ; Sat, 17 Sep 2011 17:13:26 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 28AE02BB79; Sat, 17 Sep 2011 20:15:45 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 17 Sep 2011 20:15:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=ddt+sTUm+0yQUKwj6gTLgdtW40Q=; b=d6 u1g7Dw/fFmgmLSfnKlJ4zV8kYr/Ok5QZ09wueqmZxkhHSOUS7LHTng0hmpXp08sR g6Xp9cOgyiisR1CPZN/2ULqWge+pbj/dkLoSy1ZnteKfA+QId3/9GyOTzBOfS1y3 LuMe8KCTPvoixPhbK0ivyPkk2MIYtmJoW55wEpBJA= X-Sasl-enc: 1XCQNctBuFg7eOnt07ZMnqWcFapInXiiapTYalZSetG8 1316304944 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 28246560304; Sat, 17 Sep 2011 20:15:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <656BA5E6-F254-481F-8BFB-BBD08411E484@cisco.com> Date: Sat, 17 Sep 2011 20:15:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4319452E-F0DE-499B-B807-69058968E875@network-heretics.com> References: <009501cc730a$882009d0$98601d70$@com> <0CCFB7D0-2786-4DC9-BF70-0DD8AF5B7A31@cisco.com> <4E750355.3070107@bogus.com> <4E7522FD.7060407@gmail.com> <86CCE501-D136-4768-BE32-A769047246BB@network-heretics.com> <656BA5E6-F254-481F-8BFB-BBD08411E484@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 00:13:27 -0000 On Sep 17, 2011, at 7:41 PM, Fred Baker wrote: > On Sep 17, 2011, at 4:20 PM, Keith Moore wrote: >> On Sep 17, 2011, at 7:13 PM, Fred Baker wrote: >>> On Sep 17, 2011, at 3:57 PM, Keith Moore wrote: >>>> ...except that the choice of source interface, source address, and = destination address are inherently influenced by application = considerations. It really matters to your application whether it gets = a path that is low or high bandwidth, low or high jitter, low or high = packet loss, low or high cost, whether the network connection continues = to forward packets as the host moves, whether the address-to-host = bindings are stable or ephemeral, whether the addresses used have global = or limited scope, global or limited reachability, are filtered by = firewalls, etc. =20 >>>=20 >>> True enough. I'm drawing a blank, though. I once worked on a = protocol that would enable an application to get answers to those kinds = of questions. I don't know of applications that use it or any other OS = API that would get them that information, and I'm not altogether sure, = if someone asked me which one might help them, what API to point them = to. >>=20 >> And I once tried to design an API that would do that, and it ended up = looking so complex that I couldn't convince myself that it would get = much use. (Which doesn't mean, of course, that my first stab at the = problem is the best solution possible. Actually I think that multipath = TCP has a lot of promise at being more general - though not universal -, = particularly if the app can somehow tell the network stack something = about what kinds of paths to favor.) >=20 > Well, yes, sort of. What mptcp can do is open a single session from a = set of addresses to a set of addresses. In operation, it could send data = across the cross-product of those sets and discard address pairs that = seem suboptimal. Note "seem"; it doesn't know the rate of the bottleneck = on any given path, nor its current routing, nor much of anything else. = It knows that last time it tried an address pair it liked or didn't like = what it experienced.=20 One thing that I like is the ability of the mptcp approach to not only = adapt to initial conditions, but also dynamically adapt to changing = conditions, as viewed by the endpoints. But if there were some sort of = protocol between hosts and the network that tried to give hosts a way to = compare conditions along different paths without having to actively = probe those conditions, that help a lot with allowing hosts or apps to = make good choices for initial conditions. >>> =46rom my perspective, the Happy Eyeballs considerations don't = answer all of those questions, but they do come up with a route (from = the host's perspective, an address pair) that can successfully exchange = datagrams in human-reasonable elapsed time. >>=20 >> Happy Eyeballs is just fine for the part of the problem that it = purports to solve. Last time I looked anyway, it didn't claim to be an = all-encompassing solution. It's definitely worth abstracting happy = eyeballs for applications that work well with it, we just shouldn't = pretend that it solves the general problem. >=20 > To my knowledge, nobody has suggested it solved a general problem. It = does a better job on the problem it does try to solve than approaches = that preceded it. agree. Keith From shagen@sunny.ch Sun Sep 18 03:13:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC7121F8508 for ; Sun, 18 Sep 2011 03:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHPAzxCOTe9E for ; Sun, 18 Sep 2011 03:13:10 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:42:919::99]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEFB21F84DF for ; Sun, 18 Sep 2011 03:13:09 -0700 (PDT) Received: from HPWSSilvia (static-c-213-160-42-58.customer.ggaweb.ch [213.160.42.58]) (Authenticated sender: shagen@sunny.ch) by gozo.iway.ch (Postfix) with ESMTPA id EC4EA8001144; Sun, 18 Sep 2011 12:15:26 +0200 (CEST) Mime-Version: 1.0 Date: 18 Sep 2011 12:15:35 +0200 References: 1304440901.11456.dachs,S=8651 In-Reply-To: 1304440901.11456.dachs,S=8651 Message-ID: <4E75E0E7.8D74.0096.1@sunny.ch> X-Mailer: GroupWise 8.0 From: "Silvia Hagen" To: lorenzo@google.com Content-Type: multipart/alternative; boundary="____UIYDNTMDGOFYIBGYKDLL____" Cc: v6ops@ietf.org Subject: [v6ops] Friends from Rome X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 10:13:11 -0000 --____UIYDNTMDGOFYIBGYKDLL____ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline; modification-date="Mon, 18 Sep 2011 14:15:35 +0200" SGkgTG9yZW56bw0KDQpJIHdhcyBzcGVha2luZyBvbiBJUHY2IGluIFJvbWUgbGFzdCBGcmlkYXku IEEgZ3V5IGNhbWUgdXAgdG8gbWUgYW5kIGFza2VkIGlmIEkga25ldyB5b3UuDQoNCkhpcyBuYW1l IGlzIEFuZHJlYSBUb21hc3NpIGFuZCBoZSBtZW50aW9uZWQgdGhlIFVuaXZlcnNpdHkgUm9tYTMg YW5kIEdpdXNlcHBlIERpIEJhdHRpc3RhLg0KSGUgYXNrZWQgbWUgdG8gcGFzcyBoaXMgZ3JlZXRp bmdzLg0KDQpqdXN0IGluIGNhc2UsIGhpcyBlbWFpbCBpcyBhbmRyZWEudG9tYXNzaUBtYWlsLndp bmQuaXQNCg0KQ2hlZXJzDQpTaWx2aWENCg0KDQpTdW5ueSBDb25uZWN0aW9uIEFHDQp3d3cuc3Vu bnkuY2gNCis0MSAoMCk0NCA4ODcgNjIgMTANCnNoYWdlbkBzdW5ueS5jaA0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhlIDJuZCBlZGl0aW9u IG9mIG91ciBHZXJtYW4gSVB2NiBCb29rICJJUHY2IC0gR3J1bmRsYWdlbiwgRnVua3Rpb25hbGl0 w6R0LCBJbnRlZ3JhdGlvbiBoYXMgYmVlbiBwdWJsaXNoZWQgaW4gT2N0b2JlciAyMDA5LiANCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCk91ciB3 ZWJzaXRlIGlzIGR1YWwtc3RhY2sgYW5kIGNhbiBiZSANCmFjY2Vzc2VkIHdpdGggSVB2NCBhbmQg SVB2Ng0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg== --____UIYDNTMDGOFYIBGYKDLL____ Content-Type: multipart/related; boundary="____NOFHIMCTTCQJAHXRQRAC____" --____NOFHIMCTTCQJAHXRQRAC____ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline; modification-date="Mon, 18 Sep 2011 14:15:35 +0200" PEhUTUw+PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC41 ODgwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBzdHlsZT0iTUFSR0lOOiA0cHggNHB4 IDFweDsgRk9OVDogMTBwdCBWZXJkYW5hIj4NCjxESVY+SGkgTG9yZW56bzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+SSB3YXMgc3BlYWtpbmcgb24gSVB2NiBpbiBSb21lIGxhc3QgRnJp ZGF5LiBBIGd1eSBjYW1lIHVwIHRvIG1lIGFuZCBhc2tlZCBpZiBJIGtuZXcgeW91LjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SGlzIG5hbWUgaXMgQW5kcmVhIFRvbWFzc2kgYW5kIGhl IG1lbnRpb25lZCB0aGUgVW5pdmVyc2l0eSBSb21hMyBhbmQgR2l1c2VwcGUgRGkgQmF0dGlzdGEu PC9ESVY+DQo8RElWPkhlIGFza2VkIG1lIHRvIHBhc3MgaGlzIGdyZWV0aW5ncy48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPmp1c3QgaW4gY2FzZSwgaGlzIGVtYWlsIGlzIDxBIGhyZWY9 Im1haWx0bzphbmRyZWEudG9tYXNzaUBtYWlsLndpbmQuaXQiPmFuZHJlYS50b21hc3NpQG1haWwu d2luZC5pdDwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkNoZWVyczwvRElWPg0K PERJVj5TaWx2aWE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPlN1bm55IENvbm5lY3Rpb24gQUc8QlI+d3d3 LnN1bm55LmNoPEJSPis0MSAoMCk0NCA4ODcgNjIgMTA8QlI+c2hhZ2VuQHN1bm55LmNoPEJSPioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8QlI+VGhl IDJuZCBlZGl0aW9uIG9mIG91ciBHZXJtYW4gSVB2NiBCb29rICJJUHY2IC0gR3J1bmRsYWdlbiwg RnVua3Rpb25hbGl0w6R0LCBJbnRlZ3JhdGlvbiBoYXMgYmVlbiBwdWJsaXNoZWQgaW4gT2N0b2Jl ciAyMDA5LiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+Kioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxCUj5PdXIg d2Vic2l0ZSBpcyBkdWFsLXN0YWNrIGFuZCBjYW4gYmUgPEJSPmFjY2Vzc2VkIHdpdGggSVB2NCBh bmQgSVB2NjxCUj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+ --____NOFHIMCTTCQJAHXRQRAC____-- --____UIYDNTMDGOFYIBGYKDLL____-- From shagen@sunny.ch Sun Sep 18 03:19:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7216321F8549 for ; Sun, 18 Sep 2011 03:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLUGuTgVTt1u for ; Sun, 18 Sep 2011 03:19:17 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:42:919::99]) by ietfa.amsl.com (Postfix) with ESMTP id B9CDE21F850B for ; Sun, 18 Sep 2011 03:19:17 -0700 (PDT) Received: from HPWSSilvia (static-c-213-160-42-58.customer.ggaweb.ch [213.160.42.58]) (Authenticated sender: shagen@sunny.ch) by gozo.iway.ch (Postfix) with ESMTPA id 3FE658001143 for ; Sun, 18 Sep 2011 12:21:37 +0200 (CEST) Mime-Version: 1.0 Date: 18 Sep 2011 12:21:43 +0200 References: <4DC02EE7020000969911C616@sunny.ch> <4E75E0DE02000096000246FB@sunny.ch> In-Reply-To: <4E75E0DE02000096000246FB@sunny.ch> Message-ID: <4E75E257.8D74.0096.1@sunny.ch> X-Mailer: GroupWise 8.0 From: "Silvia Hagen" To: v6ops@ietf.org Content-Type: multipart/alternative; boundary="____GPHSKIMYEAWNFUJUDQOP____" Subject: [v6ops] Friends from Rome X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 10:19:18 -0000 --____GPHSKIMYEAWNFUJUDQOP____ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline; modification-date="Mon, 18 Sep 2011 14:21:43 +0200" c29ycnkgZm9yIG1pc3Rha2VubHkgc2VuZGluZyB0byB2Nm9wcw0KDQo7LSkNCg0Kc2lsdmlhDQoN ClN1bm55IENvbm5lY3Rpb24gQUcNCnd3dy5zdW5ueS5jaA0KKzQxICgwKTQ0IDg4NyA2MiAxMA0K c2hhZ2VuQHN1bm55LmNoDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQpUaGUgbmV3IGJvb2sgIlBsYW5uaW5nIGZvciBJUHY2IiBoYXMganVzdCBi ZWVuIHJlbGVhc2Ugd2l0aCBPJ1JlaWxseS4gDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQpPdXIgd2Vic2l0ZSBpcyBkdWFsLXN0YWNrIGFuZCBj YW4gYmUgDQphY2Nlc3NlZCB3aXRoIElQdjQgYW5kIElQdjYNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio= --____GPHSKIMYEAWNFUJUDQOP____ Content-Type: multipart/related; boundary="____WFRHGYHFOUYWKLYWAZFB____" --____WFRHGYHFOUYWKLYWAZFB____ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline; modification-date="Mon, 18 Sep 2011 14:21:43 +0200" PEhUTUw+PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC41 ODgwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBzdHlsZT0iTUFSR0lOOiA0cHggNHB4 IDFweDsgRk9OVDogMTBwdCBWZXJkYW5hIj4NCjxESVY+c29ycnkgZm9yIG1pc3Rha2VubHkgc2Vu ZGluZyB0byB2Nm9wczwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Oy0pPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5zaWx2aWE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+U3VubnkgQ29ubmVjdGlvbiBBRzxCUj53d3cu c3VubnkuY2g8QlI+KzQxICgwKTQ0IDg4NyA2MiAxMDxCUj5zaGFnZW5Ac3VubnkuY2g8QlI+Kioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxCUj5UaGUm bmJzcDtuZXcgYm9vayAiUGxhbm5pbmcgZm9yIElQdjYiIGhhcyBqdXN0IGJlZW4gcmVsZWFzZSB3 aXRoIE8nUmVpbGx5LiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h IHNpemU9Mj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPEJSPk91ciB3ZWJzaXRlIGlzIGR1YWwtc3RhY2sgYW5kIGNhbiBiZSA8QlI+YWNjZXNzZWQg d2l0aCBJUHY0IGFuZCBJUHY2PEJSPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKio8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4= --____WFRHGYHFOUYWKLYWAZFB____-- --____GPHSKIMYEAWNFUJUDQOP____-- From randy@psg.com Sun Sep 18 06:39:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BDE21F84D3 for ; Sun, 18 Sep 2011 06:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKisiJEbZrcH for ; Sun, 18 Sep 2011 06:39:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2842B21F84CF for ; Sun, 18 Sep 2011 06:39:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R5Hcu-0006DI-7Y; Sun, 18 Sep 2011 13:41:44 +0000 Date: Sun, 18 Sep 2011 15:41:45 +0200 Message-ID: From: Randy Bush To: "Silvia Hagen" In-Reply-To: <4E75E257.8D74.0096.1@sunny.ch> References: <4DC02EE7020000969911C616@sunny.ch> <4E75E0DE02000096000246FB@sunny.ch> <4E75E257.8D74.0096.1@sunny.ch> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] Friends from Rome X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 13:39:27 -0000 > sorry for mistakenly sending to v6ops that is ok, i am in roma :) randy From internet-drafts@ietf.org Tue Sep 20 00:41:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C3221F86EE; Tue, 20 Sep 2011 00:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IFjT1E36PD4; Tue, 20 Sep 2011 00:41:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D0F21F85AA; Tue, 20 Sep 2011 00:41:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110920074110.10834.49828.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2011 00:41:10 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 07:41:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-06.txt Pages : 35 Date : 2011-09-20 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-06.txt From v6ops@globis.net Tue Sep 20 01:46:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0365821F8B40 for ; Tue, 20 Sep 2011 01:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLjb-ZOoqglE for ; Tue, 20 Sep 2011 01:46:29 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1625721F8AB9 for ; Tue, 20 Sep 2011 01:46:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 950528700F2; Tue, 20 Sep 2011 10:48:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKC8N32kkA3N; Tue, 20 Sep 2011 10:48:47 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 03FB3870046; Tue, 20 Sep 2011 10:48:47 +0200 (CEST) Message-ID: <4E78536F.3090207@globis.net> Date: Tue, 20 Sep 2011 10:48:47 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter Content-Type: multipart/alternative; boundary="------------080008070109010403070901" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6 prefix notation (Nathan Ward) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 08:46:30 -0000 This is a multi-part message in MIME format. --------------080008070109010403070901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Message: 8 > Date: Tue, 20 Sep 2011 16:50:32 +1200 > From: Brian E Carpenter > To: Randy Bush > Cc: ipv6 deployment prevention > Subject: Re: IPv6 prefix notation > Message-ID:<4E781B98.7080007@gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 2011-09-20 15:58, Randy Bush wrote: > >>>> >>> I think that RFC 5952 (an update on RFC 4291) provides the guidance >>>> >>> you describe in section 4.2.3. >>>> >>> >> I see that it does (and the errata on 4291 do not). Thanks. >>> >> >>> >> A reasonable prefix will end with at least 64 zeros, so :: will >>> >> always be the last element according to RFC 5952. (Unless someone >>> >> uses prefixes longer than /64, in which case I for one don't care.) >>> >> > >> > a shame. once upon a time, the academics in the ietf did care about >> > operational networks. >> > > I'm not sure that I've yet seen a case where>64 is operationally > justified, except for the /126 or whatever discussion we had a while > back for pt2pt links - where I don't think the problem that started > this thread would apply. > > Wait a minute. Have I really understood this statement "A reasonable prefix will end with at least 64 zeros" correctly? Firstly, I have not seen any discussion in the IETF that says IPv6 MUST NOT support CIDR beyond /64. I would oppose any such an assertion. In fact, I have written (but have not published) a sketch ID on how IPv6 SLAAC could be extended to support non /64 prefixes in the future. Secondly, there are people who code IPv4 prefixes into IPv6 prefixes to combine them in a single DB table of rules e.g. IPv6 ::ffff:10.0.0.0/104 is used to represent the equivalent of IPv4 10/8 [although I've since come to the conclusion myself that it's simply better and easier to have one DB table per address family] regards, RayH --------------080008070109010403070901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Message: 8
Date: Tue, 20 Sep 2011 16:50:32 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: Randy Bush <randy@psg.com>
Cc: ipv6 deployment prevention <ipv6@ietf.org>
Subject: Re: IPv6 prefix notation
Message-ID: <4E781B98.7080007@gmail.com>
Content-Type: text/plain; charset=UTF-8

On 2011-09-20 15:58, Randy Bush wrote:
  
>>> I think that RFC 5952 (an update on RFC 4291) provides the guidance
>>> you describe in section 4.2.3.
        
>> I see that it does (and the errata on 4291 do not). Thanks.
>>
>> A reasonable prefix will end with at least 64 zeros, so :: will
>> always be the last element according to RFC 5952. (Unless someone
>> uses prefixes longer than /64, in which case I for one don't care.)
      
> 
> a shame.  once upon a time, the academics in the ietf did care about
> operational networks.
    

I'm not sure that I've yet seen a case where >64 is operationally
justified, except for the /126 or whatever discussion we had a while
back for pt2pt links - where I don't think the problem that started
this thread would apply.

Wait a minute. Have I really understood this statement "A reasonable prefix will end with at least 64 zeros" correctly?

Firstly, I have not seen any discussion in the IETF that says IPv6 MUST NOT support CIDR beyond /64.

I would oppose any such an assertion. In fact, I have written (but have not published) a sketch ID on how IPv6 SLAAC could be extended to support non /64 prefixes in the future.

Secondly, there are people who code IPv4 prefixes into IPv6 prefixes to combine them in a single DB table of rules e.g. IPv6 ::ffff:10.0.0.0/104 is used to represent  the equivalent of IPv4 10/8 [although I've since come to the conclusion myself that it's simply better and easier to have one DB table per address family]

regards,
RayH
--------------080008070109010403070901-- From v6ops@daork.net Tue Sep 20 01:54:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65FF21F86B3 for ; Tue, 20 Sep 2011 01:54:53 -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=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6JM3qNkxWm2 for ; Tue, 20 Sep 2011 01:54:53 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFBD21F8512 for ; Tue, 20 Sep 2011 01:54:53 -0700 (PDT) Received: by yie12 with SMTP id 12so212048yie.31 for ; Tue, 20 Sep 2011 01:57:18 -0700 (PDT) Received: by 10.147.154.12 with SMTP id g12mr3137096yao.36.1316509038266; Tue, 20 Sep 2011 01:57:18 -0700 (PDT) Received: from [192.168.0.39] ([121.98.251.230]) by mx.google.com with ESMTPS id 1sm7523727ani.6.2011.09.20.01.57.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 01:57:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nathan Ward In-Reply-To: <4E78536F.3090207@globis.net> Date: Tue, 20 Sep 2011 20:57:08 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <0FAF7E6D-FE56-48FC-B53B-9F26B0D3E283@daork.net> References: <4E78536F.3090207@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1244.3) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6 prefix notation (Nathan Ward) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 08:54:54 -0000 On 20/09/2011, at 8:48 PM, Ray Hunter wrote: > Wait a minute. Have I really understood this statement "A reasonable = prefix will end with at least 64 zeros" correctly? >=20 > Firstly, I have not seen any discussion in the IETF that says IPv6 = MUST NOT support CIDR beyond /64. >=20 > I would oppose any such an assertion. In fact, I have written (but = have not published) a sketch ID on how IPv6 SLAAC could be extended to = support non /64 prefixes in the future. >=20 > Secondly, there are people who code IPv4 prefixes into IPv6 prefixes = to combine them in a single DB table of rules e.g. IPv6 = ::ffff:10.0.0.0/104 is used to represent the equivalent of IPv4 10/8 = [although I've since come to the conclusion myself that it's simply = better and easier to have one DB table per address family] That's funny, postgres has a column type that handles IPv4 and IPv6 in = the same column. I use that :-) My advice to people deploying IPv6 is that within your network, /112s or = whatever are great for link-nets, between routers. Where there are any = servers etc., use /64s. Where you don't own/control all the devices on = the link (i.e. customer links), use /64s. Not really sure how this thread got on to v6ops or how it got my name in = the subject, did I push a wrong button somewhere? -- Nathan Ward= From achatz@forthnet.gr Tue Sep 20 06:14:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6060E21F8BD7 for ; Tue, 20 Sep 2011 06:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcEK7QpBvlta for ; Tue, 20 Sep 2011 06:14:50 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4621621F8C33 for ; Tue, 20 Sep 2011 06:14:49 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8KDHCx2001218 for ; Tue, 20 Sep 2011 16:17:12 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8KDHCXb007723 for ; Tue, 20 Sep 2011 16:17:12 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8KDHBqA008861; Tue, 20 Sep 2011 16:17:11 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnet.gr; auth=pass (PLAIN) Message-ID: <4E789257.7080508@forthnet.gr> Date: Tue, 20 Sep 2011 16:17:11 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet S.A. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 13:14:51 -0000 Hello, I'm trying to find a doc describing the expected behavior regarding the advertisement of IPv6 MTU by the CPE to LAN devices. The only relevant, but not clear enough, is the following from RFC 4861 The MTU option is used in Router Advertisement messages to ensure that all nodes on a link use the same MTU value in those cases where the link MTU is not well known. This option MUST be silently ignored for other Neighbor Discovery messages. In configurations in which heterogeneous technologies are bridged together, the maximum supported MTU may differ from one segment to another. If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers can be configured to use the MTU option to specify the maximum MTU value that is supported by all segments. Can someone please enlighten me about the the following? If the WAN MTU is somehow manually/automatically configured in the DSL CPE, what should happen with the LAN (interface) & RA (included in LAN Router Advertisement) MTUs? 1a) The LAN MTU should always be 1500 1b) The LAN MTU should be equal to WAN MTU 2a) The RA MTU should always be 1500 2b) The RA MTU should be equal to LAN MTU 2c) The RA MTU should be equal to WAN MTU I'm not putting user configurable as an option, since i haven't seen that in most retail CPEs. Vendors seem to prefer options 1a and 2a, which seem wrong to me, because if the host respects the RA MTU, then you can avoid the "packet too big" messages sent by the CPE. -- Tassos From swmike@swm.pp.se Tue Sep 20 06:22:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363BA21F8ABD for ; Tue, 20 Sep 2011 06:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8h6qAgAPR7P for ; Tue, 20 Sep 2011 06:22:14 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 598A821F8514 for ; Tue, 20 Sep 2011 06:22:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C2DD9C; Tue, 20 Sep 2011 15:24:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 891889A; Tue, 20 Sep 2011 15:24:38 +0200 (CEST) Date: Tue, 20 Sep 2011 15:24:38 +0200 (CEST) From: Mikael Abrahamsson To: Tassos Chatzithomaoglou In-Reply-To: <4E789257.7080508@forthnet.gr> Message-ID: References: <4E789257.7080508@forthnet.gr> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 13:22:15 -0000 On Tue, 20 Sep 2011, Tassos Chatzithomaoglou wrote: > 1a) The LAN MTU should always be 1500 > 1b) The LAN MTU should be equal to WAN MTU > > 2a) The RA MTU should always be 1500 > 2b) The RA MTU should be equal to LAN MTU > 2c) The RA MTU should be equal to WAN MTU > > Vendors seem to prefer options 1a and 2a, which seem wrong to me, > because if the host respects the RA MTU, then you can avoid the "packet > too big" messages sent by the CPE. I have 1a and 2c in my home. -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Tue Sep 20 06:43:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3921F8C81 for ; Tue, 20 Sep 2011 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.775 X-Spam-Level: X-Spam-Status: No, score=-102.775 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm5lQ1B5A6FP for ; Tue, 20 Sep 2011 06:43:41 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F205A21F8C4F for ; Tue, 20 Sep 2011 06:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2801; q=dns/txt; s=iport; t=1316526367; x=1317735967; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=+IKcZxV3ckcbhvOARuc/j9UeKt3cJj4zfghLamq0dgE=; b=Gi8zBuKcI0nCrctmTal0t0HfG6h0g6G3/yk5CqfYvQ/MRShA4aNma11i HfVdvkp2BNu97tGrRUofpDDvr4oe5QrdBxNRqKjc6eosWmyitNWwwO8PU l18pOaicdEfTqmPfHZTwugud7awt1QvhYY+lvySufoUPAMBG1CJc0L5kG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALqYeE6rRDoJ/2dsb2JhbABCp114gVMBAQEBAgESASc/BQsLDjhXBiwJh1UGlUgBnkeGHWAEh3CLW4UejDE X-IronPort-AV: E=Sophos;i="4.68,411,1312156800"; d="scan'208";a="3185213" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Sep 2011 13:46:07 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8KDk6pM022360; Tue, 20 Sep 2011 13:46:06 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Tue, 20 Sep 2011 06:46:06 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Tue, 20 Sep 2011 06:46:06 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E789257.7080508@forthnet.gr> Date: Tue, 20 Sep 2011 06:45:34 -0700 Message-Id: <8D883FDD-4545-4F5E-BF41-9D216B17430B@cisco.com> References: <4E789257.7080508@forthnet.gr> To: Tassos Chatzithomaoglou X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 13:43:41 -0000 On Sep 20, 2011, at 6:17 AM, Tassos Chatzithomaoglou wrote: > If the WAN MTU is somehow manually/automatically configured in the DSL = CPE, what should happen with the LAN (interface) & RA (included in LAN = Router Advertisement) MTUs? Let me outline a picture for you. Chair hat off. //---\\ //---\\ ISP 1 ISP 2 \\---// \\---// / / / / / / +----+---+ +----+---+ |Router 1| |Router 2| +---+----+ +---+----+ | | -----+-+-----------------+-+-------- | | +--+---+ +----+---+ |Host 1| |Router 3| +------+ +--+-----+ | --------+-+---------- | +--+---+ |Host 2| +------+ Now, to your premise, the link between Router 1 and its ISP has a tunnel = in it and as a result is using a reduced PMTU. Host 2 has three obvious = targets for sessions it might open - Host 1, other hosts via ISP 1, and = still other hosts via ISP 2. What PMTU should it use for those various = sessions? How would that information be communicated? I could imagine = that R1-ISP1 has a PMTU of 1280, R2-ISP2 has a PMTU of 1500, and the two = LANs and R3 are quite happy with a 9K PMTU. If you need it more complicated, imagine that during a session the route = between the two peers changes from ISP 2 to ISP 1. =46rom my perspective, Path MTU is a characteristic of the route, and = the fact that one potential route requires a certain value doesn't imply = that another does. Hence, whatever signaling is involved is something = along the route and needs to be able to happen at any point in the life = of a session. The usual approach is to apply one of two technologies: https://tools.ietf.org/html/rfc1981 1981 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul. August 1996. (Format: TXT=3D34088 bytes) (Status: DRAFT STANDARD) https://tools.ietf.org/html/rfc4821 4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner. March 2007. (Format: TXT=3D75665 bytes) (Status: PROPOSED STANDARD) To be honest, I personally prefer the latter, although it doesn't right = now have wide deployment. We see operators filtering out ICMP and = ICMPv6, and as a result short-circuiting RFC 1981. RFC 4821 specifically = addresses that issue.= From fred@cisco.com Tue Sep 20 07:30:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBDC21F8C0C for ; Tue, 20 Sep 2011 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVOJ+WvuJGSv for ; Tue, 20 Sep 2011 07:30:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F024F21F8C0B for ; Tue, 20 Sep 2011 07:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5083; q=dns/txt; s=iport; t=1316529153; x=1317738753; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=/Opaawqc1+OnNjEyOoBqVSzYNdq1w98neZzTxjKPnNg=; b=Iqt2lrV/xkeNApNQ1wo8vEIZWkiXLiOZZJ4hL3zyI/ujtDtT2fNpKCik tRiMq7VzAxwiIcHwxZyyRY8xLAUv5tvY7rSSz4tDDhBho+REzvqiyU9vF Ubd5NbON304wXz/21YdjZE+NUvuvdincpe7IcN0tHOfPwLhA/cZ4SBLoi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAEijeE6rRDoG/2dsb2JhbABCpXaBZ3iBUwEBAQECARIBJz8FCwsOCi5XBjWHVZVPAZ5Bhh1gBIdwi1uFHowx X-IronPort-AV: E=Sophos;i="4.68,411,1312156800"; d="scan'208";a="3193913" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Sep 2011 14:32:33 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8KEWWvP011809; Tue, 20 Sep 2011 14:32:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Tue, 20 Sep 2011 07:32:32 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Tue, 20 Sep 2011 07:32:32 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <8D883FDD-4545-4F5E-BF41-9D216B17430B@cisco.com> Date: Tue, 20 Sep 2011 07:32:23 -0700 Message-Id: <21F2693A-090D-4F4F-9C85-B6D49F2AA892@cisco.com> References: <4E789257.7080508@forthnet.gr> <8D883FDD-4545-4F5E-BF41-9D216B17430B@cisco.com> To: Tassos Chatzithomaoglou X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 14:30:08 -0000 On Sep 20, 2011, at 6:45 AM, Fred Baker wrote: >=20 > On Sep 20, 2011, at 6:17 AM, Tassos Chatzithomaoglou wrote: >=20 >> If the WAN MTU is somehow manually/automatically configured in the = DSL CPE, what should happen with the LAN (interface) & RA (included in = LAN Router Advertisement) MTUs? >=20 > Let me outline a picture for you. Chair hat off. >=20 > //---\\ //---\\ > ISP 1 ISP 2 > \\---// \\---// > / / > / / > / / > +----+---+ +----+---+ > |Router 1| |Router 2| > +---+----+ +---+----+ > | | > -----+-+-----------------+-+-------- > | | > +--+---+ +----+---+ > |Host 1| |Router 3| > +------+ +--+-----+ > | > --------+-+---------- > | > +--+---+ > |Host 2| > +------+ >=20 > Now, to your premise, the link between Router 1 and its ISP has a = tunnel in it and as a result is using a reduced PMTU. Host 2 has three = obvious targets for sessions it might open - Host 1, other hosts via ISP = 1, and still other hosts via ISP 2. What PMTU should it use for those = various sessions? How would that information be communicated? I could = imagine that R1-ISP1 has a PMTU of 1280, R2-ISP2 has a PMTU of 1500, and = the two LANs and R3 are quite happy with a 9K PMTU. On Sep 20, 2011, at 6:17 AM, Tassos Chatzithomaoglou wrote: > If the WAN MTU is somehow manually/automatically configured in the DSL = CPE, what should happen with the LAN (interface) & RA (included in LAN = Router Advertisement) MTUs? >=20 > 1a) The LAN MTU should always be 1500 > 1b) The LAN MTU should be equal to WAN MTU >=20 > 2a) The RA MTU should always be 1500 > 2b) The RA MTU should be equal to LAN MTU > 2c) The RA MTU should be equal to WAN MTU Bringing it back specifically to this, I would expect that the LAN MTU = is technology-specific. IEEE 802.3 generally specifies an MTU of 1500 = bytes, but gigabit interfaces often (non-standardly) in fact support = MTUs of 9180 bytes. On such a LAN, I don't see any purpose in forcing = the hosts to use 1500 byte MTUs. If you look at other RFCs that discuss = topics like this, notably RFC 1191, this has wide variation. The = following is from page 17 of RFC 1191: Plateau MTU Comments Reference ------ --- -------- --------- 65535 Official maximum MTU RFC 791 65535 Hyperchannel RFC 1044 65535 32000 Just in case 17914 16Mb IBM Token Ring ref. [6] 17914 8166 IEEE 802.4 RFC 1042 8166 4464 IEEE 802.5 (4Mb max) RFC 1042 4352 FDDI (Revised) RFC 1188 4352 (1%) 2048 Wideband Network RFC 907 2002 IEEE 802.5 (4Mb recommended) RFC 1042 2002 (2%) 1536 Exp. Ethernet Nets RFC 895 1500 Ethernet Networks RFC 894 1500 Point-to-Point (default) RFC 1134 1492 IEEE 802.3 RFC 1042 1492 (3%) 1006 SLIP RFC 1055 1006 ARPANET BBN 1822 1006 576 X.25 Networks RFC 877 544 DEC IP Portal ref. [10] 512 NETBIOS RFC 1088 508 IEEE 802/Source-Rt Bridge RFC 1042 508 ARCNET RFC 1051 508 (13%) 296 Point-to-Point (low delay) RFC 1144 296 68 Official minimum MTU RFC 791 Table 7-1: Common MTUs in the Internet As to the RA's MTU, I can imagine two rules: (1) since the address can be used on the LAN the RA is advertised on, = the MTU should be that of the LAN. (2) since the host presumably has at least a link-local address that it = can use on the LAN, the RA should advertise the MTU that is to be used = (or used first) when using a source address within that prefix. In my example above, I'm at a loss for a way to tell Hosts 1 and 2 that = they can communicate with each other using a 9K MTU if the RA's MTU is = that of its WAN link (e.g., is following the second rule), from which it = presumably derived the prefix being advertised in the RA. Hence, I think it has to be rule (1), and leave the "but what if..." = cases to PMTU.= From brian.e.carpenter@gmail.com Tue Sep 20 15:20:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC65A1F0C56 for ; Tue, 20 Sep 2011 15:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT0wvVzBPFID for ; Tue, 20 Sep 2011 15:20:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7A1F0C43 for ; Tue, 20 Sep 2011 15:20:19 -0700 (PDT) Received: by gxk19 with SMTP id 19so897352gxk.31 for ; Tue, 20 Sep 2011 15:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qLvtoRCLrOeweaqXL2bh71dm9S/tQyXa54TUNW0jv64=; b=A3lQN/ESlwVMWY/jR4g6rADFAEhurbFxisw3bCF1dUBri7Br5lpMHhdP5uw6m/ALIq IJxiC6fvc9KPTkJpFGV2vCW4zTQ2LN0F6qweN4jiVhCjQZi692IwZKclDE6RRhhM7zTs 206MW1x8eADmSKqMIj1//Qch+kJE9EeqRtTy0= Received: by 10.236.186.35 with SMTP id v23mr145121yhm.80.1316557365868; Tue, 20 Sep 2011 15:22:45 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id f63sm3823965yhj.14.2011.09.20.15.22.43 (version=SSLv3 cipher=OTHER); Tue, 20 Sep 2011 15:22:45 -0700 (PDT) Message-ID: <4E791230.1060603@gmail.com> Date: Wed, 21 Sep 2011 10:22:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <4E78536F.3090207@globis.net> In-Reply-To: <4E78536F.3090207@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6 prefix notation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 22:20:20 -0000 Ray, On 2011-09-20 20:48, Ray Hunter wrote: >> >> Message: 8 >> Date: Tue, 20 Sep 2011 16:50:32 +1200 >> From: Brian E Carpenter >> To: Randy Bush >> Cc: ipv6 deployment prevention >> Subject: Re: IPv6 prefix notation >> Message-ID:<4E781B98.7080007@gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> On 2011-09-20 15:58, Randy Bush wrote: >> >>>>> >>> I think that RFC 5952 (an update on RFC 4291) provides the >>>>> guidance >>>>> >>> you describe in section 4.2.3. >>>>> >>>> >> I see that it does (and the errata on 4291 do not). Thanks. >>>> >> >>>> >> A reasonable prefix will end with at least 64 zeros, so :: will >>>> >> always be the last element according to RFC 5952. (Unless someone >>>> >> uses prefixes longer than /64, in which case I for one don't care.) >>>> >>> > > a shame. once upon a time, the academics in the ietf did care >>> about >>> > operational networks. >>> >> >> I'm not sure that I've yet seen a case where>64 is operationally >> justified, except for the /126 or whatever discussion we had a while >> back for pt2pt links - where I don't think the problem that started >> this thread would apply. >> >> > > Wait a minute. Have I really understood this statement "A reasonable > prefix will end with at least 64 zeros" correctly? Yes, in the context of any prefix handed out to a user; that should be at the *longest* a /64. RFC 6177. In that case, the notation as defined by RFC 5952 settles the original question in this thread (which has mysteriously jumped between WGs). Of course ISPs may choose to use longer prefixes inside the ISP network, out to /127 (as Steinar said; my /126 was a mistake) but that isn't the majority case. > Firstly, I have not seen any discussion in the IETF that says IPv6 MUST > NOT support CIDR beyond /64. > > I would oppose any such an assertion. In fact, I have written (but have > not published) a sketch ID on how IPv6 SLAAC could be extended to > support non /64 prefixes in the future. But SLAAC today doesn't do that, so it isn't a current operational issue. > Secondly, there are people who code IPv4 prefixes into IPv6 prefixes to > combine them in a single DB table of rules e.g. IPv6 ::ffff:10.0.0.0/104 > is used to represent the equivalent of IPv4 10/8 [although I've since > come to the conclusion myself that it's simply better and easier to have > one DB table per address family] Yes, which is why the ::ffff:0:0/96 prefix was defined as long ago as RFC 1884 for IPv4-mapped IPv6 addresses. I have written it as RFC 5952 requires, and it's clear that ::ffff/96 is *not* the same - its correct interpretation can only be equal to ::/96. Brian From achatz@forthnet.gr Tue Sep 20 23:41:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2867F21F8C6B for ; Tue, 20 Sep 2011 23:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjathZPLRpcv for ; Tue, 20 Sep 2011 23:41:22 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3E80721F8C6F for ; Tue, 20 Sep 2011 23:41:21 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8L6hmiG031712; Wed, 21 Sep 2011 09:43:48 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8L6hlsl003020; Wed, 21 Sep 2011 09:43:47 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8L6hlpl019892; Wed, 21 Sep 2011 09:43:47 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnet.gr; auth=pass (PLAIN) Message-ID: <4E7987A1.9040303@forthnet.gr> Date: Wed, 21 Sep 2011 09:43:45 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet S.A. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 MIME-Version: 1.0 To: Fred Baker References: <4E789257.7080508@forthnet.gr> <8D883FDD-4545-4F5E-BF41-9D216B17430B@cisco.com> <21F2693A-090D-4F4F-9C85-B6D49F2AA892@cisco.com> In-Reply-To: <21F2693A-090D-4F4F-9C85-B6D49F2AA892@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 06:41:23 -0000 Thanks for taking the time to answer Fred, > As to the RA's MTU, I can imagine two rules: > > (1) since the address can be used on the LAN the RA is advertised on, the MTU should be that of the LAN. > (2) since the host presumably has at least a link-local address that it can use on the LAN, the RA should advertise the MTU that is to be used (or used first) when using a source address within that prefix. > > In my example above, I'm at a loss for a way to tell Hosts 1 and 2 that they can communicate with each other using a 9K MTU if the RA's MTU is that of its WAN link (e.g., is following the second rule), from which it presumably derived the prefix being advertised in the RA. > > Hence, I think it has to be rule (1), and leave the "but what if..." cases to PMTU. I was actually hoping to find a doc describing the required behavior by the CPE (RFC6204 doesn't provide any hint, nor does the advanced draft). Although i'm not an expert, maybe something along the scopes of RFC4191 or the mif area (i.e. dhcpv6-route-option) could be used to also pass MTU information per prefix, so that communication between hosts in the same LAN uses the max MTU available (like 9k), while all other communication uses the WAN MTU as the upper limit.Then it would be up to the host to use a PMTUD method for further refinement. Regards, Tassos From narten@us.ibm.com Wed Sep 21 07:28:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE63721F8ACA for ; Wed, 21 Sep 2011 07:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNBNpBtzkCHq for ; Wed, 21 Sep 2011 07:28:15 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by ietfa.amsl.com (Postfix) with ESMTP id 06AC821F84A8 for ; Wed, 21 Sep 2011 07:28:14 -0700 (PDT) Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Wed, 21 Sep 2011 10:24:11 -0400 Received: from d01relay01.pok.ibm.com ([9.56.227.233]) by us.ibm.com ([192.168.1.103]) with XMail ESMTP; Wed, 21 Sep 2011 10:23:57 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8LENUw0218266 for ; Wed, 21 Sep 2011 10:23:30 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8LENUMY017459 for ; Wed, 21 Sep 2011 10:23:30 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-237-178.mts.ibm.com [9.65.237.178]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p8LENPD9016848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 10:23:26 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p8LENNwU007065; Wed, 21 Sep 2011 10:23:24 -0400 Message-Id: <201109211423.p8LENNwU007065@cichlid.raleigh.ibm.com> To: Tassos Chatzithomaoglou In-reply-to: <4E789257.7080508@forthnet.gr> References: <4E789257.7080508@forthnet.gr> Comments: In-reply-to Tassos Chatzithomaoglou message dated "Tue, 20 Sep 2011 16:17:11 +0300." Date: Wed, 21 Sep 2011 10:23:23 -0400 From: Thomas Narten x-cbid: 11092114-8974-0000-0000-00000050AE0B Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 14:28:15 -0000 Tassos Chatzithomaoglou writes: > Hello, > I'm trying to find a doc describing the expected behavior regarding > the advertisement of IPv6 MTU by the CPE to LAN devices. In most cases, and by default, there is no reason for a CPE to set the MTU value in RAs. One needs to set it only if one needs to override the standard value for the link MTU. > The only relevant, but not clear enough, is the following from RFC 4861 > The MTU option is used in Router Advertisement > messages to ensure that all nodes on a link use the > same MTU value in those cases where the link MTU is > not well known. > This option MUST be silently ignored for other > Neighbor Discovery messages. > In configurations in which heterogeneous > technologies are bridged together, the maximum > supported MTU may differ from one segment to > another. If the bridges do not generate ICMP > Packet Too Big messages, communicating nodes will > be unable to use Path MTU to dynamically determine > the appropriate MTU on a per-neighbor basis. In > such cases, routers can be configured to use the > MTU option to specify the maximum MTU value that is > supported by all segments. I think the above is actually pretty clear, and this is the first time I can recall that anyone raising a question about it. If you read 4861 (or just look at all references to MTU), it's pretty clear that the above refers to the "link MTU", not a "path MTU". The example above (about bridges) refers specifically to a single link (from an IP perspective) that has bridged components, where the different components have different MTUs, but the bridges don't send ICMP packet too big. So a host on a segment that thinks the link MTU should be X (a big number) may not be able to send packets successfully to another node on the same link (but on a different segment) where the segment/link MTU value is smaller. The case above may well be a non-issue these days (I'm not sure). But back when we wrote the above, token rings still existed (they have bigger MTUs than ethernet), and there were devices that bridged between token ring and Ethernet. So you could have IP links where by default, hosts would use different values for the link MTU. For a CPE on a typical home network, there is no need for the CPE to include the link MTU in RAs. And taking the MTU from the WAN side to decide what the MTU should be on the link side is totally wrong. Fred outlined how you can get into trouble. Hope this helps... Thomas From internet-drafts@ietf.org Wed Sep 21 21:52:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED1721F8CDA; Wed, 21 Sep 2011 21:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAK2AqWa3o2h; Wed, 21 Sep 2011 21:52:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B1921F8CCC; Wed, 21 Sep 2011 21:52:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110922045230.24152.82232.idtracker@ietfa.amsl.com> Date: Wed, 21 Sep 2011 21:52:30 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 04:52:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-07.txt Pages : 35 Date : 2011-09-21 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt From fred@cisco.com Thu Sep 22 08:00:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0299121F8BB7 for ; Thu, 22 Sep 2011 08:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.772 X-Spam-Level: X-Spam-Status: No, score=-102.772 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0ZvRUXhebXr for ; Thu, 22 Sep 2011 07:59:59 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8F31D21F8B80 for ; Thu, 22 Sep 2011 07:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=221; q=dns/txt; s=iport; t=1316703751; x=1317913351; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=NyJTZ84PhX4zze82/m1JzcLKQcttnBLhAUTLmdFbEIQ=; b=S37X0ZCQ3i91K3MDI1scKk1vv7xqcWWXAFiQA8zGk4Z+dtGV0FXCNqXY 4Hb9/4HXO2saz7IPJkrtcbEhsINmuG6W6QiMemI5OHrMnYNHqN7Q3bmA4 gQnmAeercCgzM+s4c3cIeLegPuGoLUGfu2+rubAa3/i4pFRdW2iVid3Po 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAE1Ne06rRDoH/2dsb2JhbABCqAB4gWwBCh2BfTWdAoEmAZ4shh1gBIdxi1+FH4ww X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="3682772" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Sep 2011 15:02:31 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8MF2VbL029876 for ; Thu, 22 Sep 2011 15:02:31 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 22 Sep 2011 08:02:31 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 22 Sep 2011 08:02:31 -0700 From: Fred Baker Date: Thu, 22 Sep 2011 08:02:20 -0700 Message-Id: <1792E9DA-8700-4750-B20E-3FF0FB48C4BF@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 15:00:00 -0000 Time to put together an agenda for the coming meeting. Based on current = drafts and discussion, it might be a short one. As at IETF 81, we're looking for posted internet drafts that have = discussion on the list.= From rajiva@cisco.com Thu Sep 22 12:45:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8D821F8B62 for ; Thu, 22 Sep 2011 12:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUVY1RueoAjS for ; Thu, 22 Sep 2011 12:45:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6821F8B5D for ; Thu, 22 Sep 2011 12:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6135; q=dns/txt; s=iport; t=1316720900; x=1317930500; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BDxhJrhzTpE5k4LVkJOXjB+uN893ZqLEpVMVcg7JHzk=; b=ZZMrJRekY+L5gSaeBFkGiFoksyJZdQY7yYNR9EvlJDSeRK091qHlX3C5 fHvMigUcE+1OkEaV2UdgxitbVN1g4sEmP73FqB1dSPc+8unB1hc/HMuka 5rVjNgilpcJHHFKTrigjjMJEpfUAYoGFRdXnYYR9gYwNvUlHFdI/4TLfC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAAFaQe06tJV2Z/2dsb2JhbABCmQuOd3iBUwEBAQECAQEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodWBpcUAZ4shh1gBIdxkQeMJQ X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="23398516" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 22 Sep 2011 19:48:19 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8MJmJ7A009927; Thu, 22 Sep 2011 19:48:19 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 14:48:19 -0500 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, 22 Sep 2011 14:48:18 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05F95295@XMB-RCD-111.cisco.com> In-Reply-To: <21F2693A-090D-4F4F-9C85-B6D49F2AA892@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices Thread-Index: Acx3oixHNPf1HurqRLmZdfg2HFSI4gBudP7g References: <4E789257.7080508@forthnet.gr><8D883FDD-4545-4F5E-BF41-9D216B17430B@cisco.com> <21F2693A-090D-4F4F-9C85-B6D49F2AA892@cisco.com> From: "Rajiv Asati (rajiva)" To: "Fred Baker (fred)" , "Tassos Chatzithomaoglou" X-OriginalArrivalTime: 22 Sep 2011 19:48:19.0563 (UTC) FILETIME=[941CABB0:01CC7960] Cc: v6ops@ietf.org Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 19:45:49 -0000 > > If the WAN MTU is somehow manually/automatically configured in the DSL CPE, > what should happen with the LAN (interface) & RA (included in LAN Router > Advertisement) MTUs?=09 The (RA) advertised MTU, by default, must correspond to LAN interface media on which the RA is sent.=20 Sure, one could allow for the config to override it.=20 Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred > Baker (fred) > Sent: Tuesday, September 20, 2011 10:32 AM > To: Tassos Chatzithomaoglou > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices >=20 >=20 > On Sep 20, 2011, at 6:45 AM, Fred Baker wrote: >=20 > > > > On Sep 20, 2011, at 6:17 AM, Tassos Chatzithomaoglou wrote: > > > >> If the WAN MTU is somehow manually/automatically configured in the DSL CPE, > what should happen with the LAN (interface) & RA (included in LAN Router > Advertisement) MTUs? > > > > Let me outline a picture for you. Chair hat off. > > > > //---\\ //---\\ > > ISP 1 ISP 2 > > \\---// \\---// > > / / > > / / > > / / > > +----+---+ +----+---+ > > |Router 1| |Router 2| > > +---+----+ +---+----+ > > | | > > -----+-+-----------------+-+-------- > > | | > > +--+---+ +----+---+ > > |Host 1| |Router 3| > > +------+ +--+-----+ > > | > > --------+-+---------- > > | > > +--+---+ > > |Host 2| > > +------+ > > > > Now, to your premise, the link between Router 1 and its ISP has a tunnel in > it and as a result is using a reduced PMTU. Host 2 has three obvious targets > for sessions it might open - Host 1, other hosts via ISP 1, and still other > hosts via ISP 2. What PMTU should it use for those various sessions? How would > that information be communicated? I could imagine that R1-ISP1 has a PMTU of > 1280, R2-ISP2 has a PMTU of 1500, and the two LANs and R3 are quite happy with > a 9K PMTU. >=20 >=20 >=20 > On Sep 20, 2011, at 6:17 AM, Tassos Chatzithomaoglou wrote: >=20 > > If the WAN MTU is somehow manually/automatically configured in the DSL CPE, > what should happen with the LAN (interface) & RA (included in LAN Router > Advertisement) MTUs?=09 > > > > 1a) The LAN MTU should always be 1500 > > 1b) The LAN MTU should be equal to WAN MTU > > > > 2a) The RA MTU should always be 1500 > > 2b) The RA MTU should be equal to LAN MTU > > 2c) The RA MTU should be equal to WAN MTU >=20 > Bringing it back specifically to this, I would expect that the LAN MTU is > technology-specific. IEEE 802.3 generally specifies an MTU of 1500 bytes, but > gigabit interfaces often (non-standardly) in fact support MTUs of 9180 bytes. > On such a LAN, I don't see any purpose in forcing the hosts to use 1500 byte > MTUs. If you look at other RFCs that discuss topics like this, notably RFC > 1191, this has wide variation. The following is from page 17 of RFC 1191: >=20 >=20 > Plateau MTU Comments Reference > ------ --- -------- --------- > 65535 Official maximum MTU RFC 791 > 65535 Hyperchannel RFC 1044 > 65535 > 32000 Just in case > 17914 16Mb IBM Token Ring ref. [6] > 17914 > 8166 IEEE 802.4 RFC 1042 > 8166 > 4464 IEEE 802.5 (4Mb max) RFC 1042 > 4352 FDDI (Revised) RFC 1188 > 4352 (1%) > 2048 Wideband Network RFC 907 > 2002 IEEE 802.5 (4Mb recommended) RFC 1042 > 2002 (2%) > 1536 Exp. Ethernet Nets RFC 895 > 1500 Ethernet Networks RFC 894 > 1500 Point-to-Point (default) RFC 1134 > 1492 IEEE 802.3 RFC 1042 > 1492 (3%) > 1006 SLIP RFC 1055 > 1006 ARPANET BBN 1822 > 1006 > 576 X.25 Networks RFC 877 > 544 DEC IP Portal ref. [10] > 512 NETBIOS RFC 1088 > 508 IEEE 802/Source-Rt Bridge RFC 1042 > 508 ARCNET RFC 1051 > 508 (13%) > 296 Point-to-Point (low delay) RFC 1144 > 296 > 68 Official minimum MTU RFC 791 >=20 > Table 7-1: Common MTUs in the Internet >=20 >=20 > As to the RA's MTU, I can imagine two rules: >=20 > (1) since the address can be used on the LAN the RA is advertised on, the MTU > should be that of the LAN. > (2) since the host presumably has at least a link-local address that it can > use on the LAN, the RA should advertise the MTU that is to be used (or used > first) when using a source address within that prefix. >=20 > In my example above, I'm at a loss for a way to tell Hosts 1 and 2 that they > can communicate with each other using a 9K MTU if the RA's MTU is that of its > WAN link (e.g., is following the second rule), from which it presumably > derived the prefix being advertised in the RA. >=20 > Hence, I think it has to be rule (1), and leave the "but what if..." cases to > PMTU. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Thu Sep 22 16:46:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4E21F8AD8 for ; Thu, 22 Sep 2011 16:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8cUW6htJDEg for ; Thu, 22 Sep 2011 16:46:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4077121F8AD1 for ; Thu, 22 Sep 2011 16:46:51 -0700 (PDT) Received: from Zorch.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p8MNnNA4034685 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 22 Sep 2011 23:49:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4E7BC97D.5040505@bogus.com> Date: Thu, 22 Sep 2011 16:49:17 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 22 Sep 2011 23:49:23 +0000 (UTC) Subject: [v6ops] Important milestone dates between now and Taiwan IETF meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 23:46:51 -0000 2011-10-13 (Thursday): Preliminary agenda published for comment. * 2011-10-17 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). 2011-10-21 (Friday): Final agenda to be published. * 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. * 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. 2011-11-04 (Friday): Early Bird registration and payment cut-off at 17:00 PT (00:00 UTC). 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. 2011-11-13 - 2011-11-18: 82nd IETF Meeting in Taipei, Taiwan. From fred@cisco.com Thu Sep 22 17:08:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76E21F8A95 for ; Thu, 22 Sep 2011 17:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MHnG8UqhswM for ; Thu, 22 Sep 2011 17:08:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 68B9F21F8A97 for ; Thu, 22 Sep 2011 17:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1590; q=dns/txt; s=iport; t=1316736683; x=1317946283; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=S8peHFU4b80IntjYNGy+/uZFpdZLh0wzE1KTsth66gY=; b=PKPEPS7ZR0XJ4C+0rWBncBwNm4bBX1IAkT3hFznNhV0fcyX0ghw23eZj y0myEFX8AQn4MfYgFeAKZ+vgm0GRLEKobViUjR42ahbxjhqzjxIOF7Z90 mQWUz6qgZT31k6PzFEYXsNDDzEpSHPZZMQjXtHmbnxgFGbIN050gjWApU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANXNe05Io8US/2dsb2JhbABCqAV4gVMBAQEBAgEBAQEPASc0CxALRicwBhMih1YGlw8BniSGHWAEh3GLX4UfjDA X-IronPort-AV: E=Sophos;i="4.68,426,1312156800"; d="scan'208";a="116799049" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 23 Sep 2011 00:11:20 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8N0BGxb014700; Fri, 23 Sep 2011 00:11:18 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 22 Sep 2011 17:11:19 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 22 Sep 2011 17:11:19 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E7BC97D.5040505@bogus.com> Date: Thu, 22 Sep 2011 17:10:20 -0700 Message-Id: References: <4E7BC97D.5040505@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Important milestone dates between now and Taiwan IETF meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 00:08:51 -0000 Thanks, Joel. For the record, for us to post an agenda, we need to see "I'm = interested" comments on the list on drafts. To see "I'm interested" = comments, we need to have authors post drafts and ask the working group = to comment on them. Authors have four weeks to get their drafts in the = mill, and earlier is better than later. On Sep 22, 2011, at 4:49 PM, Joel jaeggli wrote: >=20 > 2011-10-13 (Thursday): Preliminary agenda published for comment. >=20 > * 2011-10-17 (Monday): Working Group Chair approval for initial = document > (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). >=20 > 2011-10-21 (Friday): Final agenda to be published. >=20 > * 2011-10-24 (Monday): Internet Draft Cut-off for initial document = (-00) > submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission = Tool. >=20 > * 2011-10-31 (Monday): Internet Draft final submission cut-off by = 17:00 > PT (00:00 UTC), upload using IETF ID Submission Tool. >=20 > 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT > (00:00 UTC), upload using IETF Meeting Materials Management Tool. >=20 > 2011-11-04 (Friday): Early Bird registration and payment cut-off at > 17:00 PT (00:00 UTC). >=20 > 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT > (00:00 UTC), upload using IETF Meeting Materials Management Tool. >=20 > 2011-11-13 - 2011-11-18: 82nd IETF Meeting in Taipei, Taiwan. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Thu Sep 22 22:16:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6ED21F8B8B for ; Thu, 22 Sep 2011 22:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.77 X-Spam-Level: X-Spam-Status: No, score=-102.77 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMNoPNRoVRKc for ; Thu, 22 Sep 2011 22:16:20 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 382C521F8B8A for ; Thu, 22 Sep 2011 22:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=615; q=dns/txt; s=iport; t=1316755134; x=1317964734; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=5mo6IudSqJ77toKmgG+pIyeDCIzl1hKI0cFFLvpEW3o=; b=DG0jRXto+TDDTvj4Zmw1dhwse0ebB1nATmycBlOifcBOd3Guqrl/bSWh kZlviu3yhILUEYqtAzn7XQZjLnRLqVuqLLihUhJWrQjlmcRBaHQo3lA87 jQE5TReAMnbsTJ87TTcJvfNzVHyNM6UGkqpQ3oFcFx6DIaOw3jHrS40u8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMIAA0WfE6rRDoI/2dsb2JhbABDmVKOOniBbAEnP4FznkABnieGHWAEh3KLYIUgjDE X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208";a="3813475" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 23 Sep 2011 05:18:53 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8N5Iqkj002128; Fri, 23 Sep 2011 05:18:52 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 22 Sep 2011 22:18:53 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 22 Sep 2011 22:18:53 -0700 From: Fred Baker Date: Thu, 22 Sep 2011 22:18:41 -0700 Message-Id: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 05:16:21 -0000 This is to initiate a two week working group last call of = draft-ietf-v6ops-happy-eyeballs. Please read it now. If you find nits = (spelling errors, minor suggested wording changes, etc), comment to the = authors; if you find greater issues, such as disagreeing with a = statement or finding additional issues that need to be addressed, please = post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= From mark@townsley.net Fri Sep 23 02:59:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3591C21F8BB0 for ; Fri, 23 Sep 2011 02:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EXzt10EylvG for ; Fri, 23 Sep 2011 02:59:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BED321F8BA4 for ; Fri, 23 Sep 2011 02:59:28 -0700 (PDT) Received: by wwf22 with SMTP id 22so2330664wwf.13 for ; Fri, 23 Sep 2011 03:02:01 -0700 (PDT) Received: by 10.216.166.84 with SMTP id f62mr3586931wel.59.1316772121522; Fri, 23 Sep 2011 03:02:01 -0700 (PDT) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id w31sm15637793wbm.12.2011.09.23.03.01.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 03:02:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> Date: Fri, 23 Sep 2011 12:01:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE37361-AEF9-4CD1-89FA-D4600C0C02EF@townsley.net> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 09:59:29 -0000 I highly support the publication of this document.=20 One note: Perhaps it is obvious, but I think there may be room for a = sentence pointing out that network operators may need to be more = diligent with IPv6 diagnostic and measurement on dual-stacked networks = as HE-enabled applications and OSes appear. i.e., people with happy = eyeballs are far less likely to alert an administrator if something is = wrong with IPv6 (or IPv4 one day?) Also, I wonder if the document should be a BCP given that we now have = current practice, and that it is documented in the spec.=20 Nits: > In order to use applications over IPv6, it is necessary that users = enjoy nearly identical performance as compared to IPv4.=20 s/identical identical or better > This usually means giving preferring IPv6 over IPv4, although... s/preferring/preference to - Mark On Sep 23, 2011, at 7:18 AM, Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-happy-eyeballs. Please read it now. If you find nits = (spelling errors, minor suggested wording changes, etc), comment to the = authors; if you find greater issues, such as disagreeing with a = statement or finding additional issues that need to be addressed, please = post your comments to the list. >=20 > We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Fri Sep 23 09:09:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DBE21F8C73 for ; Fri, 23 Sep 2011 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.77 X-Spam-Level: X-Spam-Status: No, score=-102.77 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axvS28W9p1jY for ; Fri, 23 Sep 2011 09:09:23 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C398221F8C83 for ; Fri, 23 Sep 2011 09:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=296; q=dns/txt; s=iport; t=1316794307; x=1318003907; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Xb6zRDtU8wiTutwXarigh+KN0Xg/NkL4kPHHdcY/v18=; b=C9kHGxNFQrsxqy5VbT251GqYNaFL9n8T7v+0nDy8Vg+fTkeL0EdyXBiO AqpTIl4NFVH36gwhIAgVM2rFAse59cDZFD7x0m3W6ZkoT/hyrmVMi7dXM btc2OANekOBA62k+NcyP80n/mt8atwpmB5HoYdErxMA7hXHMg0UaRkrin Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEuvfE6rRDoI/2dsb2JhbABCqBN4gVMBAQEDARIBJz8FCwtGVwY1h1aYUgGeL4YhYASHcotghSCMMQ X-IronPort-AV: E=Sophos;i="4.68,431,1312156800"; d="scan'208";a="3907548" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 23 Sep 2011 16:11:47 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8NGBlcj013705; Fri, 23 Sep 2011 16:11:47 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 23 Sep 2011 09:11:47 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 23 Sep 2011 09:11:47 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <6FE37361-AEF9-4CD1-89FA-D4600C0C02EF@townsley.net> Date: Fri, 23 Sep 2011 09:11:15 -0700 Message-Id: <988DBFA6-B589-43FD-A47A-F3AA71446D57@cisco.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <6FE37361-AEF9-4CD1-89FA-D4600C0C02EF@townsley.net> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 16:09:24 -0000 On Sep 23, 2011, at 3:01 AM, Mark Townsley wrote: > Also, I wonder if the document should be a BCP given that we now have = current practice, and that it is documented in the spec.=20 I would invite comment on that. It makes sense to me to make it BCP; do = we as a group think that?= From wesley.george@twcable.com Fri Sep 23 11:26:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AA21F8C9C for ; Fri, 23 Sep 2011 11:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGr-4KLfA9wy for ; Fri, 23 Sep 2011 11:26:14 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0D21F8C99 for ; Fri, 23 Sep 2011 11:26:12 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,577,1309752000"; d="scan'208";a="262676818" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 23 Sep 2011 14:26:40 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 23 Sep 2011 14:28:46 -0400 From: "George, Wes" To: Fred Baker , "v6ops@ietf.org" Date: Fri, 23 Sep 2011 14:28:44 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC Thread-Index: Acx5sE7IigN8x2ZzQbaMd6BqmvRorAAT+bUw Message-ID: <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> In-Reply-To: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 18:26:14 -0000 I've reviewed the draft. Generally I'm pretty happy with it, but I have two= main comments. First for the Abstract/Introduction: I'd rather this didn't focus exclusively on the v4 working/v6 broken permut= ation. Most of what I can see shows HE working in either direction, and as = we move into a situation where IPv4 may be the more "broken" connectivity d= ue to multiple layers of NAT, attempts to do on-demand IPv4 provisioning, e= tc, it may be that HE can be used to reduce the potential for IPv4 brokenne= ss's impact on users. I realize that generally most OSes prefer IPv6 if giv= en a AAAA today, but if we're implementing an algorithm to take some action= based on information gathered about performance on which stack to use, som= etimes maybe it's worth talking in more generic terms. I'd recommend rewording to discuss in slightly more agnostic terms - eg "i= n order to use applications in a dual-stack environment, it is necessary to= enjoy proper technical performance (roughly equivalent to or better than t= oday's IPv4 experience) on whichever address-family is used to reach the de= sired content and services. A combination of... and IPv4 extension techniqu= es such as CGN, etc. all cause the user experience to suffer... Instead, ap= plications can improve the user experience themselves, by more aggressively= making connections on IPv6 or IPv4 depending on which provides the better = service..." You cover this in 4.1 and 4.2 but I don't see a need to be quite so version= -specific in the intro/abstract. You also probably don't need to mention IP= v6 in the title of 4.2. This algorithm can easily be stateful to remember t= hat IPv4 is not working well and to prefer IPv6 if at all possible if there= are scenarios where IPv6 is not actually the preferred address family. Secondly: I think that it probably makes some sense to discuss the fact that this is = now implemented in several locations, perhaps along with a reference to the= specifics, at least somewhere other than the acknowledgements section. I d= on't have a problem with it being changed to a BCP if everyone thinks that'= s the best course of action, but I think I'd rather see it remain a standar= ds-track document with some implementation examples. Standards with multipl= e implementations are the goal, right? Thanks, Wes George -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Friday, September 23, 2011 1:19 AM To: v6ops@ietf.org Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC This is to initiate a two week working group last call of draft-ietf-v6ops-= happy-eyeballs. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Fri Sep 23 12:31:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C821F8D25 for ; Fri, 23 Sep 2011 12:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAI-W6cjJKfS for ; Fri, 23 Sep 2011 12:31:38 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E4BC721F8D1E for ; Fri, 23 Sep 2011 12:31:37 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,578,1309752000"; d="scan'208";a="277566152" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 23 Sep 2011 15:31:23 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 23 Sep 2011 15:34:11 -0400 From: "George, Wes" To: "v6ops@ietf.org" Date: Fri, 23 Sep 2011 15:34:11 -0400 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt Thread-Index: Acx44+IX48I6K+8iTOy3CwJ2vtlj9QBQLN0Q Message-ID: <34E4F50CAFA10349A41E0756550084FB0FA69187@PRVPEXVS04.corp.twcable.com> References: <20110922045230.24152.82232.idtracker@ietfa.amsl.com> In-Reply-To: <20110922045230.24152.82232.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 19:31:38 -0000 One question about this draft. In section 5 covering address management, th= e draft is unclear as to whether 3GPP EPS supports IPv6-only operation, and= whether there are any special implementation considerations around this. Since in many cases, it is possible to provision IPv4 addresses on demand b= ased on whether the data connection on the device is active or idle, one wo= uld think that it would make a lot of sense to extend this so that you coul= d provision IPv4 and IPv6 addresses independently based on which is needed = to complete the requested service. There are references in earlier sections to "IPv4 and/or IPv6 addresses" bu= t 5.1 says "ipv4 address configuration is always performed during PDP...set= up". 6.1 and 8.4 seems to imply that IVP6 only is supported, but is unclear= about whether once an IPv6-only session is established, if an IPv4 session= can also be established (on-demand) at a later point, and if the two can b= e torn down independently. There is also text in section 7 that says that i= n dual-stack scenarios, the number of IPv4 addresses in use is not lessened= by an increase in the amount of active IPv6 devices. So I'm looking for clarity on a specific scenario - A device which supports dual-stack is configured as IPv6-only by default. I= t has active traffic moving over IPv6, and then it tries to connect to some= thing that is only available via IPv4. Is it possible for the device to tri= gger the setup of an IPv4 session? Does it have to tear down the existing I= Pv6-only session to move to a dual-stack? When it is done using IPv4 and th= at goes idle, can it tear down the IPv4 session if IPv6 is still active? I = think that 8.7 is covering this case, but it's unclear to me. Also, if this= is supported, what is the expected setup time? That is, could you actually= stand up an IPv4 session before the connection attempt times out, or would= the device have to have some intelligence to defer/retry the connection at= tempt while it sets up its IPv4 address? Is the behavior in the above scenario dictated by the 3GPP spec, or by this= draft? Thanks, Wes -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Thursday, September 22, 2011 12:53 AM To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-07.txt Pages : 35 Date : 2011-09-21 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Fri Sep 23 12:35:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9321F8D1E for ; Fri, 23 Sep 2011 12:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThnPPl5BvkRF for ; Fri, 23 Sep 2011 12:35:31 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4D221F8B0C for ; Fri, 23 Sep 2011 12:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4672; q=dns/txt; s=iport; t=1316806686; x=1318016286; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=2xIA1czCBd/dDtENxhDkVtnYj732+N1H9nj23lQzg4E=; b=SLXPQDuEIDLHEEFJosy3uI9b8S6DLi5OEbRGnCQCkxV6axGMc0leYnMw lf5L/dxIvBGj56z+WHcic0Vs3wNKVy1htL3tTn5J5L2U3qsmyHWWvqrU8 PnuugEIdcZYwLE8NFvxAGsmJgCJeTJ1CEkbWMpvgMMzHkZ3J1foehCh0Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFbffE6rRDoH/2dsb2JhbABCFqgAeIFTAQEBAwESAWEFBQsLRlcGHBmHVgaYegGeLoYhYASHcotghSCMMQ X-IronPort-AV: E=Sophos;i="4.68,432,1312156800"; d="scan'208";a="3953716" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 23 Sep 2011 19:38:04 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8NJc4D7028957; Fri, 23 Sep 2011 19:38:04 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 23 Sep 2011 12:38:04 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 23 Sep 2011 12:38:04 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> Date: Fri, 23 Sep 2011 12:37:54 -0700 Message-Id: <3668FEA0-1EFB-403E-8C68-F3A01AB86996@cisco.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 19:35:33 -0000 On Sep 23, 2011, at 11:28 AM, George, Wes wrote: > I think that it probably makes some sense to discuss the fact that = this is now implemented in several locations, perhaps along with a = reference to the specifics, at least somewhere other than the = acknowledgements section. I don't have a problem with it being changed = to a BCP if everyone thinks that's the best course of action, but I = think I'd rather see it remain a standards-track document with some = implementation examples. Standards with multiple implementations are the = goal, right? A BCP (http://tools.ietf.org/html/rfc2026#section-5) is a standard, but = a standard for a practice as opposed to an algorithm or protocol. The = PS/DS/FS standards track = (http://tools.ietf.org/html/rfc2026#section-4.1) is for "Internet = specifications [that] go through stages of development, testing, and = acceptance."=20 BCP 38 (http://tools.ietf.org/html/bcp38), for example, is a recommended = configuration of filters in routers. Although it specifically recommends = the use of access lists (which it calls "filters" or "filtering rules"), = it turns out that there is more than one way to implement it - we can = discuss access lists or any of several variations on unicast reverse = path forwarding. The important thing turns out to not be "how it is = done" as much as "that it is done". SNMP, on the other hand, has gone through three major revisions and = PS/DS/FS in each revision. In each revision, the original specification = came out at PS and only after wide testing, and then was taken to DS = after wide interoperability testing. In this case, the implementations that are out there are not all done = the same way, but all have the intended effect with differences = resulting from their algorithmic differences. There is no question of = interoperability; if they don't successfully open TCP sessions, they = don't work and are non-starters, and if they do open TCP sessions, the = question is how long it takes for them to succeed in a given network = scenario. We only implement happy eyeballs in the system that initiates = a connection; in client/server applications (example HTTP), that's the = client, and in peer-to-peer applications (example SMTP), the party that = initiates the connection. In either case, the party accepting the = connection - the server or the other peer - remains unchanged. If I understand things correctly, one implementation is pretty similar = to present behavior (which tries addresses serially to completion) = except that it implements that for the set of IPv4 addresses, and in = parallel implements it again for the set of IPv6 addresses. If the issue = is between IPv4 and IPv6, this ensures that both are being tried early = in the game. If I understand correctly, another implementation opens a = single socket and opens connections using it in parallel (using the = non-blocking mode of the socket), running down the getaddrinfo() list at = some cadence, accepting the first that responds and discarding the rest. = One implementation that I find as API code but don't know of an = application that uses (http://www.v6address.com/node/16) opens them all = at the same time. The latter two have the intended effect in any = multihoming scenario including IPv4-only with multiple IPv4 addresses = and IPv6-only with multiple IPv6 addresses. One concern: if the cadence = is too quick (especially if the interval is zero), it can also have = negative consequences on servers. I believe that there is at least one = other implementation.=20 If we were to recommend an algorithm, and therefore go = Proposed/Draft/Full Standard or the currently-proposed two step = procedure, I think we're getting into the specifics of the socket API on = various operating systems. The idea of having multiple connections in = the process of being attempted on the same socket (which I rather like, = personally, for relative simplicity and generality) is specific to an OS = that implements the =93Liberal Behavior=94 of the connect() call; many = OS's implement only the "rigid" behavior, which doesn't permit multiple = connects in parallel on the same socket. (cf = http://www.madore.org/~david/computers/connect-intr.html, = http://www.v6address.com/node/16). Also, lacking an interoperability component, I'm not sure what procedure = I would use to go from PS to DS... So I think we're better off taking the route that BCP 38 took, of saying = *what* should be done without saying *how* to do it. That's the = neighborhood of a BCP, not PS. Obviously open to opinions.= From gilbert_kim@vanguard.com Fri Sep 23 13:06:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3510821F8CFA for ; Fri, 23 Sep 2011 13:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQdwx7-d5I2s for ; Fri, 23 Sep 2011 13:05:57 -0700 (PDT) Received: from pslva865.vanguard.com (pslva865.vanguard.com [192.175.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id 81EF121F8C91 for ; Fri, 23 Sep 2011 13:05:57 -0700 (PDT) Received: from pslva831.vanguard.com (pslva831.vanguard.com [10.17.37.6]) by pslva865.vanguard.com (Sentrion-MTA-4.1.1/Sentrion-MTA-4.1.1) with ESMTP id p8NK8O9l027404 for ; Fri, 23 Sep 2011 16:08:26 -0400 X-DKIM: OpenDKIM Filter v2.1.3 pslva865.vanguard.com p8NK8O9l027404 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=vanguard.com; s=vanguard; t=1316808506; bh=1HKiNzpixfFb5f2pmM8aq7YhzkY=; l=823; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-type; b=ZNn31JOXJhnU/wiwXjBzxlOYPjWy2w9RsbkcbyRIPLkARDgddIM1GKwWUZVZN1CHU 3j1gVc3IcLYasrQofoehA== Received: from pslva867.vanguard.com (pslva867.vanguard.com [10.17.9.44]) by pslva831.vanguard.com (8.14.4/8.14.4) with ESMTP id p8NK8OmE012802 for ; Fri, 23 Sep 2011 16:08:24 -0400 Received: from vgi4mail.vanguard.com (pvnva784.vanguard.com [10.17.128.144]) by pslva867.vanguard.com (Sentrion-MTA-4.1.1/Sentrion-MTA-4.1.1) with ESMTP id p8NK8NGd024700 for ; Fri, 23 Sep 2011 16:08:24 -0400 Auto-Submitted: auto-generated From: gilbert_kim@vanguard.com To: v6ops@ietf.org Message-ID: Date: Fri, 23 Sep 2011 16:08:22 -0400 X-MIMETrack: Serialize by Router on VGI4Mail/VGI(Release 8.5.2FP2|March 22, 2011) at 09/23/2011 04:08:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [v6ops] Gilbert Kim is out of office. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:06:10 -0000 I will be out of the office starting 09/23/2011 and will not return until 09/26/2011. I am currently out of the country with limited access to email. If you need immediate assistance please contact Scott Yarosh. ---------------------------------------------------------------------- CONFIDENTIALITY STATEMENT. The information contained in this e-mail message, including attachments, is the confidential information of, and/or is the property of, Vanguard. The information is intended for use solely by the individual or entity named in the message. If you are not an intended recipient or you received this in error, then any review, printing, copying, or distribution of any such information is prohibited, and please notify the sender immediately by reply e-mail and then delete this e-mail from your system. From achatz@forthnet.gr Fri Sep 23 13:26:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD22621F8CE6 for ; Fri, 23 Sep 2011 13:26:10 -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=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGvJa2J9BjiM for ; Fri, 23 Sep 2011 13:26:10 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id D6B3921F8CE5 for ; Fri, 23 Sep 2011 13:26:09 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8NKShTO020574 for ; Fri, 23 Sep 2011 23:28:43 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id p8NKSgYE024330 for ; Fri, 23 Sep 2011 23:28:42 +0300 Received: from [192.168.1.3] (46.12.59.55.dsl.dyn.forthnet.gr [46.12.59.55]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8NKSXUO032605; Fri, 23 Sep 2011 23:28:33 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnet.gr; auth=pass (PLAIN) Message-ID: <4E7CEBE9.9090900@forthnet.gr> Date: Fri, 23 Sep 2011 23:28:25 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] comments on draft-ietf-v6ops-happy-eyeballs-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:26:10 -0000 Hi, Regarding the http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-04 draft, i wanted to make some comments. This is my first try, so please try to be gentle with the answers :-[ 4 > The basic idea is depicted in the following diagram: > > DNS Server Client Server > | | | > 1. |<--www.example.com A?-----| | > 2. |<--www.example.com AAAA?--| | > 3. |---192.0.2.1------------->| | > 4. |---2001:db8::1----------->| | > 5. | | | > 6. | |==TCP SYN, IPv6===>X | > 7. | |--TCP SYN, IPv4------->| > 8. | |<-TCP SYN+ACK, IPv4----| > 9. | |--TCP ACK, IPv4------->| > 10. | |==TCP SYN, IPv6===>X | > > Figure 2: Happy Eyeballs flow 1, IPv6 broken > > In the diagram above, the client sends two TCP SYNs at the same time > over IPv6 (6) and IPv4 (7). In the diagram, the IPv6 path is broken > but has little impact to the user because there is no long delay > before using IPv4. The IPv6 path is retried until the application > gives up (10). Regarding the last sentence, why keep on trying the IPv6 when IPv4 has already been successful? 4.1 > If a Happy Eyeballs implementation treats IPv6 and IPv4 > equally by connecting to whichever address family is fastest, it will > contribute to load on IPv4. The above assumes IPv4 is faster than IPv6. Although this is not always true (i tend to be optimistic, although i know it's difficult to find such examples), i believe a note should be added somewhere, explaining the assumption. > This usually means giving > preferring IPv6 over IPv4, although that preference can be over- > ridden by user configuration or by network configuration This should probably be written as: This usually means giving*preference to* IPv6 over IPv4, although that preference can be over- ridden by user configuration or by network configuration Also, in various parts of 4.1 the phrase "can only utilize IPv4" can be re-written as "can utilize only IPv4", in order to move the focus of "only" from "utilize" to "IPv4". 4.2 > After making a connection attempt on the preferred address family > (e.g., IPv6), and failing to establish a connection within a certain > time period (seeSection 5.7 ), a Happy Eyeballs implementation will > decide to initiate a second connection attempt using the same address > family or the other address family. If i understand correctly, the same address family will be retried only if the other other address family hasn't responded too. If that is the case, maybe it should be clarified. On the other hand, if the other address family has responded, what is the reason of immediately retrying the address family that failed? > Such an implementation MAY make subsequent connection attempts (to > the same host or to other hosts) on the successful address family > (e.g., IPv4). Such an implementation MUST occasionally make > connection attempts using the host's preferred address family, as it > may have become functional again, and is RECOMMENDED to do so every > 10 minutes. Implementation note: this can be achieved by attempting > to connect to both address families at the same time every 10 > minutes, which does not significantly harm the application's > connection setup time. If connections using the preferred address > family are again successful, the preferred address family SHOULD be > used for subsequent connections. The above paragraph is a little bit confusing to me. First there is a MUST in order to use the host's preferred address family for connections (occasionally) Then there is a SHOULD in order to use the host's preferred address family for (subsequent) connections If MUST is there due to RFC3484, shouldn't it also be there in the second case? > Because this implementation is > stateful, it MAY track connection success (or failure) based on IPv6 > or IPv4 prefix (e.g., connections to the same prefix assigned to the > interface are successful whereas connections to other prefixes are > failing). The above is not very clear to me. Especially the part into the parentheses. Where does the term "same prefix assign to the interface" refer to? "assign to the interface" makes me think it's the source prefix, while "connections to" makes me think it's the destination prefix that needs to be tracked. 5.5 > It is possible that an DNS query for an A or AAAA resource record > will return more than one A or AAAA address. Replace "an DNS query" with "a DNS query"? > When this occurs, it is > RECOMMENDED that a Happy Eyeballs implementation order the responses > following the host's address preference policy and then try the first > address. If that fails after a certain time (seeSection 5.7 ), the > next address SHOULD be the IPv4 address. I guess the IPv4 address SHOULD be the*first*IPv4 address. -- Tassos From pch-b29AA871B@u-1.phicoh.com Fri Sep 23 23:20:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B361921F8B5A for ; Fri, 23 Sep 2011 23:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5NH5Wivjzig for ; Fri, 23 Sep 2011 23:20:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D2CD021F8B59 for ; Fri, 23 Sep 2011 23:20:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R7LdS-0001tCC; Sat, 24 Sep 2011 08:22:50 +0200 Message-Id: To: "George, Wes" From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> In-reply-to: Your message of "Fri, 23 Sep 2011 14:28:44 -0400 ." <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> Date: Sat, 24 Sep 2011 08:22:47 +0200 X-Mailman-Approved-At: Sat, 24 Sep 2011 07:45:33 -0700 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 06:20:18 -0000 In your letter dated Fri, 23 Sep 2011 14:28:44 -0400 you wrote: >First for the Abstract/Introduction: >I'd rather this didn't focus exclusively on the v4 working/v6 broken permutati >on. Most of what I can see shows HE working in either direction, and as we mov >e into a situation where IPv4 may be the more "broken" connectivity due to mul >tiple layers of NAT, attempts to do on-demand IPv4 provisioning, etc, it may b >e that HE can be used to reduce the potential for IPv4 brokenness's impact on >users. I realize that generally most OSes prefer IPv6 if given a AAAA today, b >ut if we're implementing an algorithm to take some action based on information > gathered about performance on which stack to use, sometimes maybe it's worth >talking in more generic terms. When I first started playing HE I had the same idea. Make it more symmetric. But later I realized that we want to transition to IPv6. So it is inherently asymmetric. We would like to use IPv6 as much as possible. Also, keeping the document focused on IPv6 versus IPv4 keeps it simple. And we want something now, not a fully general solution in 10 years time. So I would prefer to keep it the way it is. From denghui02@gmail.com Sat Sep 24 17:26:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AF121F84D4 for ; Sat, 24 Sep 2011 17:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDNvz9uFvdn2 for ; Sat, 24 Sep 2011 17:26:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37DD621F84D3 for ; Sat, 24 Sep 2011 17:26:49 -0700 (PDT) Received: by wyh21 with SMTP id 21so3024687wyh.31 for ; Sat, 24 Sep 2011 17:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fl7UqE9IqBTqPlPSFnMECTa9JRsrDTegqSM8hsv/TsE=; b=LG7wImC5I3cuwhpBmTwH19eMQ087TdFKtWvNQL3+7QKaiQfQzd1adc4ynfoornpRX/ NehyMoRtam7d0MagVdoNlIfrEI5xI30kW4QWEb0Z+IJuLvTZWkjA+AdLl4EwhQyVHnzX ZGipzXFKhIgurLmJxyqirJ+/rWh/x0hTvo9Mg= MIME-Version: 1.0 Received: by 10.216.221.132 with SMTP id r4mr1331033wep.64.1316910565555; Sat, 24 Sep 2011 17:29:25 -0700 (PDT) Received: by 10.216.186.13 with HTTP; Sat, 24 Sep 2011 17:29:25 -0700 (PDT) In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0FA69187@PRVPEXVS04.corp.twcable.com> References: <20110922045230.24152.82232.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB0FA69187@PRVPEXVS04.corp.twcable.com> Date: Sun, 25 Sep 2011 08:29:25 +0800 Message-ID: From: Hui Deng To: "George, Wes" Content-Type: multipart/alternative; boundary=0016e64c1bba75fd8504adb922b5 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 00:26:50 -0000 --0016e64c1bba75fd8504adb922b5 Content-Type: text/plain; charset=ISO-8859-1 I believe that there is possibility about IPv6 only PDP, if this draft isn't clear about this, I would recommend it need to be udpated. Regards, -Hui 2011/9/24 George, Wes > One question about this draft. In section 5 covering address management, > the draft is unclear as to whether 3GPP EPS supports IPv6-only operation, > and whether there are any special implementation considerations around this. > Since in many cases, it is possible to provision IPv4 addresses on demand > based on whether the data connection on the device is active or idle, one > would think that it would make a lot of sense to extend this so that you > could provision IPv4 and IPv6 addresses independently based on which is > needed to complete the requested service. > There are references in earlier sections to "IPv4 and/or IPv6 addresses" > but 5.1 says "ipv4 address configuration is always performed during > PDP...setup". 6.1 and 8.4 seems to imply that IVP6 only is supported, but is > unclear about whether once an IPv6-only session is established, if an IPv4 > session can also be established (on-demand) at a later point, and if the two > can be torn down independently. There is also text in section 7 that says > that in dual-stack scenarios, the number of IPv4 addresses in use is not > lessened by an increase in the amount of active IPv6 devices. > > So I'm looking for clarity on a specific scenario - > A device which supports dual-stack is configured as IPv6-only by default. > It has active traffic moving over IPv6, and then it tries to connect to > something that is only available via IPv4. Is it possible for the device to > trigger the setup of an IPv4 session? Does it have to tear down the existing > IPv6-only session to move to a dual-stack? When it is done using IPv4 and > that goes idle, can it tear down the IPv4 session if IPv6 is still active? I > think that 8.7 is covering this case, but it's unclear to me. Also, if this > is supported, what is the expected setup time? That is, could you actually > stand up an IPv4 session before the connection attempt times out, or would > the device have to have some intelligence to defer/retry the connection > attempt while it sets up its IPv4 address? > > Is the behavior in the above scenario dictated by the 3GPP spec, or by this > draft? > > Thanks, > > Wes > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, September 22, 2011 12:53 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the IPv6 Operations Working Group > of the IETF. > > Title : IPv6 in 3GPP Evolved Packet System > Author(s) : Jouni Korhonen > Jonne Soininen > Basavaraj Patil > Teemu Savolainen > Gabor Bajko > Kaisu Iisakkila > Filename : draft-ietf-v6ops-3gpp-eps-07.txt > Pages : 35 > Date : 2011-09-21 > > Use of data services in smart phones and broadband services via HSPA > and HSPA+, in particular Internet services, has increased rapidly and > operators that have deployed networks based on 3GPP network > architectures are facing IPv4 address shortages at the Internet > registries and are feeling a pressure to migrate to IPv6. This > document describes the support for IPv6 in 3GPP network > architectures. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of this > E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0016e64c1bba75fd8504adb922b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I believe that there is possibility about IPv6 only PDP,
if this draft isn't clear about this, I would recommend it need to= be udpated.
=A0
Regards,
=A0
-Hui

2011/9/24 George, Wes <wesley.george@twcable.com><= /span>
One question about this draft. I= n section 5 covering address management, the draft is unclear as to whether= 3GPP EPS supports IPv6-only operation, and whether there are any special i= mplementation considerations around this.
Since in many cases, it is possible to provision IPv4 addresses on demand b= ased on whether the data connection on the device is active or idle, one wo= uld think that it would make a lot of sense to extend this so that you coul= d provision IPv4 and IPv6 addresses independently based on which is needed = to complete the requested service.
There are references in earlier sections to "IPv4 and/or IPv6 addresse= s" but 5.1 says "ipv4 address configuration is always performed d= uring PDP...setup". 6.1 and 8.4 seems to imply that IVP6 only is suppo= rted, but is unclear about whether once an IPv6-only session is established= , if an IPv4 session can also be established (on-demand) at a later point, = and if the two can be torn down independently. There is also text in sectio= n 7 that says that in dual-stack scenarios, the number of IPv4 addresses in= use is not lessened by an increase in the amount of active IPv6 devices.
So I'm looking for clarity on a specific scenario -
A device whi= ch supports dual-stack is configured as IPv6-only by default. It has active= traffic moving over IPv6, and then it tries to connect to something that i= s only available via IPv4. Is it possible for the device to trigger the set= up of an IPv4 session? Does it have to tear down the existing IPv6-only ses= sion to move to a dual-stack? When it is done using IPv4 and that goes idle= , can it tear down the IPv4 session if IPv6 is still active? I think that 8= .7 is covering this case, but it's unclear to me. Also, if this is supp= orted, what is the expected setup time? That is, could you actually stand u= p an IPv4 session before the connection attempt times out, or would the dev= ice have to have some intelligence to defer/retry the connection attempt wh= ile it sets up its IPv4 address?

Is the behavior in the above scenario dictated by the 3GPP spec, or by = this draft?

Thanks,

Wes

-----Original Message-----
= From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts= @ietf.org
Sent: Thursday, September 22, 2011 12:53 AM
To: i-d-announce@ietf.org
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6op= s-3gpp-eps-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations Working Group of = the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv6 in 3GPP Ev= olved Packet System
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Jouni Korhonen
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jonne Soininen
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Basavaraj Patil
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Teemu Savolainen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0Gabor Bajko
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0Kaisu Iisakkila
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-3gpp-eps-07.txt=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 35
=A0 =A0 =A0 =A0Date =A0 = =A0 =A0 =A0 =A0 =A0: 2011-09-21

=A0 Use of data services in smart ph= ones and broadband services via HSPA
=A0 and HSPA+, in particular Intern= et services, has increased rapidly and
=A0 operators that have deployed networks based on 3GPP network
=A0 arch= itectures are facing IPv4 address shortages at the Internet
=A0 registri= es and are feeling a pressure to migrate to IPv6. =A0This
=A0 document d= escribes the support for IPv6 in 3GPP network
=A0 architectures.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-= eps-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/in= ternet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-= eps-07.txt
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/m= ailman/listinfo/v6ops

This E-mail and any of its attachments may contain Time Warner Cable pr= oprietary information, which is privileged, confidential, or subject to cop= yright belonging to Time Warner Cable. This E-mail is intended solely for t= he use of the individual or entity to which it is addressed. If you are not= the intended recipient of this E-mail, you are hereby notified that any di= ssemination, distribution, copying, or action taken in relation to the cont= ents of and attachments to this E-mail is strictly prohibited and may be un= lawful. If you have received this E-mail in error, please notify the sender= immediately and permanently delete the original and any copy of this E-mai= l and any printout.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/m= ailman/listinfo/v6ops

--0016e64c1bba75fd8504adb922b5-- From jouni.nospam@gmail.com Sun Sep 25 08:36:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9868C21F8C18 for ; Sun, 25 Sep 2011 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN7tKvH0LamW for ; Sun, 25 Sep 2011 08:36:22 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20E3221F8BB5 for ; Sun, 25 Sep 2011 08:36:21 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5474739bka.31 for ; Sun, 25 Sep 2011 08:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=y9YjUusDFhw0H06rtOy37wHTYwTX4UvFoyTMRlY7Sp8=; b=KfyPEc/r8eR8BtWZ8oHHGEiXl1H4ha/O+o3fngdpjRlxJ9wuo3ngL3chfb0x64+aND 1eDVEErVU4UOKHbBBVu+j6IiZHW/glO2angsKyIJdj4nvDKheYqNzMttFo21Ua1Pu0j/ WBZ6sRnearvZfdcs7hrdS2IM4kXlH1D26UBzA= Received: by 10.204.145.208 with SMTP id e16mr3816344bkv.176.1316965137703; Sun, 25 Sep 2011 08:38:57 -0700 (PDT) Received: from [62.237.209.66] ([62.237.209.66]) by mx.google.com with ESMTPS id v16sm17718450bkd.6.2011.09.25.08.38.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Sep 2011 08:38:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0FA69187@PRVPEXVS04.corp.twcable.com> Date: Sun, 25 Sep 2011 18:38:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <35A0BF62-D25E-4488-8BED-E5CFE25606BF@gmail.com> References: <20110922045230.24152.82232.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB0FA69187@PRVPEXVS04.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 15:36:23 -0000 Wes, On Sep 23, 2011, at 10:34 PM, George, Wes wrote: > One question about this draft. In section 5 covering address = management, the draft is unclear as to whether 3GPP EPS supports = IPv6-only operation, and whether there are any special implementation = considerations around this. Section 6.2 says: 3. For 2G/3G access to EPC core (PDN-GW via S4-SGSN) from Release-8 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 which gets mapped to PDN Connection type. Minimum one PDP Context is needed to get dual stack connectivity. 4. For LTE (E-UTRAN) access to EPC core from Release-8 there are three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN Connection is needed to get dual stack connectivity. This could probably be explicitly stated earlier. Nothing specific about PDP/PDN Type IPv6.. apart it being IPv6 only. > Since in many cases, it is possible to provision IPv4 addresses on = demand based on whether the data connection on the device is active or = idle, one would think that it would make a lot of sense to extend this = so that you could provision IPv4 and IPv6 addresses independently based = on which is needed to complete the requested service. There is so called "deferred address allocation" for IPv4 in case of = Dual-Stack. It is not actually described in the draft due being IPv4 = specific stuff and rather ugly as a DHCPv4-based solution. (i.e. the UE = opens Dual-Stack connection which is provisioned as supporting deferred = IPv4 address allocation. Then somehow defers DHCPv4 operation until it = needs IPv4 address.. this can be somewhat hard to get deterministically = working on the UE side). > There are references in earlier sections to "IPv4 and/or IPv6 = addresses" but 5.1 says "ipv4 address configuration is always performed = during PDP...setup". 6.1 and 8.4 seems to imply that IVP6 only is = supported, but is unclear about whether once an IPv6-only session is = established, if an IPv4 session can also be established (on-demand) at a = later point, and if the two can be torn down independently. There is = also text in section 7 that says that in dual-stack scenarios, the = number of IPv4 addresses in use is not lessened by an increase in the = amount of active IPv6 devices. Nothing prevents (if allowed by the subscription) the UE opening another = PDP Context/PDN Connection of type IPv4 later on.. but that then implies = two bearers, which for most operators seems to no-go. You cannot, = though, upgrade an existing PDP/PDN Type on fly e.g. from IPv6 to = IPv4v6. > So I'm looking for clarity on a specific scenario - > A device which supports dual-stack is configured as IPv6-only by = default. It has active traffic moving over IPv6, and then it tries to = connect to something that is only available via IPv4. Is it possible for = the device to trigger the setup of an IPv4 session? Does it have to tear = down the existing IPv6-only session to move to a dual-stack? When it is=20= Sure. This is UE implementation specific issue. Network side only cares = about subscription provisioning in this case i.e. both IPv4 and IPv6 = must be provisioned to the UE > done using IPv4 and that goes idle, can it tear down the IPv4 session = if IPv6 is still active? I think that 8.7 is=20 Sure. AGain up to the UE implementation. > covering this case, but it's unclear to me. Also, if this is = supported, what is the expected setup time? That is, could PDP Context/PDN Connection setup time (in case of default bearer) is not = the fastest operation and depends on various things. Bringing up the = radio alone takes several seconds (quickly did few test and they were = around 5sec on 3G). > you actually stand up an IPv4 session before the connection attempt = times out, or would the device have to have some intelligence to = defer/retry the connection attempt while it sets up its IPv4 address? >=20 > Is the behavior in the above scenario dictated by the 3GPP spec, or by = this draft? An UE vendor can implement such.. if they so wish.=20 - JOuni >=20 > Thanks, >=20 > Wes >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Thursday, September 22, 2011 12:53 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Operations Working = Group of the IETF. >=20 > Title : IPv6 in 3GPP Evolved Packet System > Author(s) : Jouni Korhonen > Jonne Soininen > Basavaraj Patil > Teemu Savolainen > Gabor Bajko > Kaisu Iisakkila > Filename : draft-ietf-v6ops-3gpp-eps-07.txt > Pages : 35 > Date : 2011-09-21 >=20 > Use of data services in smart phones and broadband services via HSPA > and HSPA+, in particular Internet services, has increased rapidly = and > operators that have deployed networks based on 3GPP network > architectures are facing IPv4 address shortages at the Internet > registries and are feeling a pressure to migrate to IPv6. This > document describes the support for IPv6 in 3GPP network > architectures. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wesley.george@twcable.com Mon Sep 26 06:17:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D7C21F8C58 for ; Mon, 26 Sep 2011 06:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=1.257, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhiyd6USHqOD for ; Mon, 26 Sep 2011 06:17:48 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6CC21F862F for ; Mon, 26 Sep 2011 06:17:48 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,591,1309752000"; d="scan'208";a="263335126" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Sep 2011 09:18:15 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 26 Sep 2011 09:20:30 -0400 From: "George, Wes" To: Philip Homburg Date: Mon, 26 Sep 2011 09:20:29 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC Thread-Index: Acx6gmjw3VBsbCf0T1SSAIDXaXmLZABy0PYg Message-ID: <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:17:49 -0000 I believe you missed my point and we're actually in agreement for the most = part. Currently the section I mentioned discusses HE as a solution for *IPv6* bro= kenness (mainly by either falling back to IPv4 more quickly or by tracking = state to determine which stack should be used for which destinations). I ho= pe that IPv6 brokenness is a short-term problem and that as more people mov= e to IPv6, *IPv4* may be the more broken item, and therefore we need a mech= anism to ensure that IPv6 is preferred when it will provide the better user= experience, even if there are some set of configurations or rules that wou= ld otherwise have the host prefer IPv4. I don't think that this moves away = from the idea that preferring IPv6 whenever possible is the goal. However, as important as I think IPv6 is, I should note that this isn't abo= ut preferring IPv6 as much as it is preferring the stack that works - hence= "happy eyeballs." The assumption is that once IPv6's initial deployment te= ething problems are resolved in each network, and CGN becomes more prevalen= t in IPv4, IPv6 will be that "stack that works" more often than IPv4, rathe= r than the other way around as it's currently presented. Thanks, Wes -----Original Message----- From: pch-b29AA871B@u-1.phicoh.com [mailto:pch-b29AA871B@u-1.phicoh.com] On= Behalf Of Philip Homburg Sent: Saturday, September 24, 2011 2:23 AM To: George, Wes Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC In your letter dated Fri, 23 Sep 2011 14:28:44 -0400 you wrote: >First for the Abstract/Introduction: >I'd rather this didn't focus exclusively on the v4 working/v6 broken permu= tati >on. Most of what I can see shows HE working in either direction, and as we= mov >e into a situation where IPv4 may be the more "broken" connectivity due to= mul >tiple layers of NAT, attempts to do on-demand IPv4 provisioning, etc, it m= ay b >e that HE can be used to reduce the potential for IPv4 brokenness's impact= on >users. I realize that generally most OSes prefer IPv6 if given a AAAA toda= y, b >ut if we're implementing an algorithm to take some action based on informa= tion > gathered about performance on which stack to use, sometimes maybe it's wo= rth >talking in more generic terms. When I first started playing HE I had the same idea. Make it more symmetric= . But later I realized that we want to transition to IPv6. So it is inherentl= y asymmetric. We would like to use IPv6 as much as possible. Also, keeping the document focused on IPv6 versus IPv4 keeps it simple. And we want something now, not a fully general solution in 10 years time. So I would prefer to keep it the way it is. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Mon Sep 26 06:24:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4922A21F85B1 for ; Mon, 26 Sep 2011 06:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAoSbLuugyIT for ; Mon, 26 Sep 2011 06:24:14 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 42CFF21F8487 for ; Mon, 26 Sep 2011 06:24:14 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,591,1309752000"; d="scan'208";a="263339103" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Sep 2011 09:24:41 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 26 Sep 2011 09:26:56 -0400 From: "George, Wes" To: jouni korhonen Date: Mon, 26 Sep 2011 09:26:55 -0400 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt Thread-Index: Acx7mUEGSxI1W+8OT6OzuoFJ9C4TKgAtfN0g Message-ID: <34E4F50CAFA10349A41E0756550084FB0FA69494@PRVPEXVS04.corp.twcable.com> References: <20110922045230.24152.82232.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB0FA69187@PRVPEXVS04.corp.twcable.com> <35A0BF62-D25E-4488-8BED-E5CFE25606BF@gmail.com> In-Reply-To: <35A0BF62-D25E-4488-8BED-E5CFE25606BF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:24:15 -0000 Thank you, much clearer now. This is all helpful explanation that I believe= should be added to the draft. I realize that some of it is specific to IPv= 4, but when considering a dual-stack network + IPv4 exhaustion (which is di= scussed in the draft) I think that it makes some sense to discuss this as a= potential IPv4 address-conservation mechanism that doesn't necessarily req= uire NAT. Regarding setup times - assuming that the radio is already active= , we're talking about a variant of the DHCPv4 response times for a device w= ith an active IPv6 connection to stand up IPv4, not the time necessary to s= tand up the radio connection, right? Also, I think that you'll see carriers re-evaluating their stance on single= vs dual PDP contexts as IPv4 addressing constraints become a concern and I= Pv6-capable UEs become more common and widely deployed, so while I would ci= te that as a current limiting factor, I certainly wouldn't use that as a re= ason to exclude that use case and its operational/deployment considerations= from the draft.=20 Thanks, Wes -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Sunday, September 25, 2011 11:39 AM To: George, Wes Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt Wes, On Sep 23, 2011, at 10:34 PM, George, Wes wrote: > Since in many cases, it is possible to provision IPv4 addresses on demand= based on whether the data connection on the device is active or idle, one = would think that it would make a lot of sense to extend this so that you co= uld provision IPv4 and IPv6 addresses independently based on which is neede= d to complete the requested service. There is so called "deferred address allocation" for IPv4 in case of Dual-S= tack. It is not actually described in the draft due being IPv4 specific stu= ff and rather ugly as a DHCPv4-based solution. (i.e. the UE opens Dual-Stac= k connection which is provisioned as supporting deferred IPv4 address alloc= ation. Then somehow defers DHCPv4 operation until it needs IPv4 address.. t= his can be somewhat hard to get deterministically working on the UE side). > There are references in earlier sections to "IPv4 and/or IPv6 addresses" = but 5.1 says "ipv4 address configuration is always performed during PDP...s= etup". 6.1 and 8.4 seems to imply that IVP6 only is supported, but is uncle= ar about whether once an IPv6-only session is established, if an IPv4 sessi= on can also be established (on-demand) at a later point, and if the two can= be torn down independently. There is also text in section 7 that says that= in dual-stack scenarios, the number of IPv4 addresses in use is not lessen= ed by an increase in the amount of active IPv6 devices. Nothing prevents (if allowed by the subscription) the UE opening another PD= P Context/PDN Connection of type IPv4 later on.. but that then implies two = bearers, which for most operators seems to no-go. You cannot, though, upgra= de an existing PDP/PDN Type on fly e.g. from IPv6 to IPv4v6. > So I'm looking for clarity on a specific scenario - > A device which supports dual-stack is configured as IPv6-only by default.= It has active traffic moving over IPv6, and then it tries to connect to so= mething that is only available via IPv4. Is it possible for the device to t= rigger the setup of an IPv4 session? Does it have to tear down the existing= IPv6-only session to move to a dual-stack? When it is=20 Sure. This is UE implementation specific issue. Network side only cares abo= ut subscription provisioning in this case i.e. both IPv4 and IPv6 must be p= rovisioned to the UE > done using IPv4 and that goes idle, can it tear down the IPv4 session if = IPv6 is still active? I think that 8.7 is=20 Sure. AGain up to the UE implementation. > covering this case, but it's unclear to me. Also, if this is supported, w= hat is the expected setup time? That is, could PDP Context/PDN Connection setup time (in case of default bearer) is not th= e fastest operation and depends on various things. Bringing up the radio al= one takes several seconds (quickly did few test and they were around 5sec o= n 3G). > you actually stand up an IPv4 session before the connection attempt time= s out, or would the device have to have some intelligence to defer/retry th= e connection attempt while it sets up its IPv4 address? >=20 > Is the behavior in the above scenario dictated by the 3GPP spec, or by th= is draft? An UE vendor can implement such.. if they so wish.=20 - JOuni >=20 > Thanks, >=20 > Wes >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org > Sent: Thursday, September 22, 2011 12:53 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-07.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the IPv6 Operations Working Group of th= e IETF. >=20 > Title : IPv6 in 3GPP Evolved Packet System > Author(s) : Jouni Korhonen > Jonne Soininen > Basavaraj Patil > Teemu Savolainen > Gabor Bajko > Kaisu Iisakkila > Filename : draft-ietf-v6ops-3gpp-eps-07.txt > Pages : 35 > Date : 2011-09-21 >=20 > Use of data services in smart phones and broadband services via HSPA > and HSPA+, in particular Internet services, has increased rapidly and > operators that have deployed networks based on 3GPP network > architectures are facing IPv4 address shortages at the Internet > registries and are feeling a pressure to migrate to IPv6. This > document describes the support for IPv6 in 3GPP network > architectures. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-07.txt > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From pch-b29AA871B@u-1.phicoh.com Mon Sep 26 07:13:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15E121F8C12 for ; Mon, 26 Sep 2011 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVWygTIH9Nca for ; Mon, 26 Sep 2011 07:13:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E5FD021F8C71 for ; Mon, 26 Sep 2011 07:13:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8ByP-0001ivC; Mon, 26 Sep 2011 16:15:57 +0200 Message-Id: To: "George, Wes" From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> In-reply-to: Your message of "Mon, 26 Sep 2011 09:20:29 -0400 ." <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> Date: Mon, 26 Sep 2011 16:15:53 +0200 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:13:18 -0000 In your letter dated Mon, 26 Sep 2011 09:20:29 -0400 you wrote: >even >if there are some set of configurations or rules that would otherwise have the > host prefer IPv4. I think that's the important part. I think the way forward is to make IPv6 preferred. The HE can switch to IPv4 if IPv6 doesn't work well enough. The problem with making IPv4 preferred is that HE will mostly avoid using IPv6 except when IPv4 is bad enough that IPv6 is really better. I can imagine some sites having to prefer IPv4. And HE does work for that. But I hope that is going to be a niche that we can hide somewhere in a corner. >However, as important as I think IPv6 is, I should note that this isn't about >preferring IPv6 as much as it is preferring the stack that works - hence "happ >y eyeballs." The assumption is that once IPv6's initial deployment teething pr >oblems are resolved in each network, and CGN becomes more prevalent in IPv4, I >Pv6 will be that "stack that works" more often than IPv4, rather than the othe >r way around as it's currently presented. The problem with preferring the stack that works is what do you do when IPv4 and IPv6 have parity? CGNs have to be good enough that from a performance point of view, a host cannot easily tell that they are there. Otherwise, IPv4 would break too much. What will happens in that case? Will the traffic be evenly distributed over IPv4 and IPv6? So, IMHO, the only way forward is to prefer IPv6 and then let HE fall back to IPv4. From marc.blanchet@viagenie.ca Mon Sep 26 07:17:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0228821F8C45 for ; Mon, 26 Sep 2011 07:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.3 X-Spam-Level: X-Spam-Status: No, score=-103.3 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9K667EHKltd for ; Mon, 26 Sep 2011 07:17:00 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 73B1321F8C3F for ; Mon, 26 Sep 2011 07:17:00 -0700 (PDT) Received: from [IPv6:2607:fa48:6e6b:c280:3cbe:25fe:e30e:bedd] (unknown [IPv6:2607:fa48:6e6b:c280:3cbe:25fe:e30e:bedd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9BAAE21C52; Mon, 26 Sep 2011 10:19:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Mon, 26 Sep 2011 10:19:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> To: Philip Homburg X-Mailer: Apple Mail (2.1244.3) Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:17:01 -0000 Le 2011-09-26 =E0 10:15, Philip Homburg a =E9crit : > In your letter dated Mon, 26 Sep 2011 09:20:29 -0400 you wrote: >> even=20 >> if there are some set of configurations or rules that would otherwise = have the >> host prefer IPv4.=20 >=20 > I think that's the important part. >=20 > I think the way forward is to make IPv6 preferred. The HE can switch = to IPv4 > if IPv6 doesn't work well enough. >=20 > The problem with making IPv4 preferred is that HE will mostly avoid = using > IPv6 except when IPv4 is bad enough that IPv6 is really better. >=20 > I can imagine some sites having to prefer IPv4. And HE does work for = that. > But I hope that is going to be a niche that we can hide somewhere in a = corner. >=20 >> However, as important as I think IPv6 is, I should note that this = isn't about=20 >> preferring IPv6 as much as it is preferring the stack that works - = hence "happ >> y eyeballs." The assumption is that once IPv6's initial deployment = teething pr >> oblems are resolved in each network, and CGN becomes more prevalent = in IPv4, I >> Pv6 will be that "stack that works" more often than IPv4, rather than = the othe >> r way around as it's currently presented. >=20 > The problem with preferring the stack that works is what do you do = when IPv4 > and IPv6 have parity?=20 >=20 > CGNs have to be good enough that from a performance point of view, a = host > cannot easily tell that they are there. Otherwise, IPv4 would break = too much. >=20 > What will happens in that case? Will the traffic be evenly distributed = over > IPv4 and IPv6? >=20 > So, IMHO, the only way forward is to prefer IPv6 and then let HE fall = back to > IPv4.=20 I agree. My experience with one OS implementation that does similar to = HE is that my computer no longer uses IPv6, because IPv4 almost always = win, no matter what. Because IPv4 is where the money is currently. = Therefore, if there is no pref for IPv6, then IPv6 will never happen, = since no trafic, no eyeballs, ... Marc. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From prvs=1250bc7008=jordi.palet@consulintel.es Mon Sep 26 07:20:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5F21F8D34 for ; Mon, 26 Sep 2011 07:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=1.512, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC2S6lk28r2F for ; Mon, 26 Sep 2011 07:20:42 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9C80521F8D31 for ; Mon, 26 Sep 2011 07:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1317046985; x=1317651785; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=hQyW/sxER6q72+mfKZl7qKbIjEFTIpX8ZSTvGIeuNL8=; b=Yab xV+SIhKy7DkFv0lAww2cQ/k6XkKRR+jJIyfUTFerI3+u3Z+2YcIXiidxfWwSw2N7 oYoW/HX7GI61JK+yxL1LPeg7CJDMs7ipRY3XBCHlfqIbWhvVurmg4fz7RQUY8DkI +jSuZCA2KQPEkfkkjeCVbYSWz6ekbHi0TKozaRIU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=TVbOyLZGs30TTcYsU66lF46lbzP9NjV5cnduXh6jQYdJoFSGnfI3fnJ+bI5F G967J0mBbNrjv5f8p3+BQFxjwkxFRu1ai/yYXO/ZJgqgJ0X2RpFU1eCla 5yVzUuGdViuSRE+XLt4hVoWi+runOJjDHJxAleLiLU1+WTjlpBn4D4=; X-MDAV-Processed: consulintel.es, Mon, 26 Sep 2011 16:23:05 +0200 Received: from [10.10.10.119] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003994843.msg for ; Mon, 26 Sep 2011 16:23:05 +0200 X-Spam-Processed: consulintel.es, Mon, 26 Sep 2011 16:23:05 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110926:md50003994843::a9bQkXUDQTKOEUla:000027VA X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1250bc7008=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 26 Sep 2011 16:23:15 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:20:43 -0000 Same for me =8A the way is being implemented is not good at all. I was very happy using IPv6 all the time, now is a problem even when there is native IPv6 (because it may be slower than IPv4 some times) ! Regards, Jordi -----Mensaje original----- De: Marc Blanchet Responder a: Fecha: Mon, 26 Sep 2011 10:19:29 -0400 Para: Philip Homburg CC: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Asunto: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC > >Le 2011-09-26 =E0 10:15, Philip Homburg a =E9crit : > >> In your letter dated Mon, 26 Sep 2011 09:20:29 -0400 you wrote: >>> even=20 >>> if there are some set of configurations or rules that would otherwise >>>have the >>> host prefer IPv4. >>=20 >> I think that's the important part. >>=20 >> I think the way forward is to make IPv6 preferred. The HE can switch to >>IPv4 >> if IPv6 doesn't work well enough. >>=20 >> The problem with making IPv4 preferred is that HE will mostly avoid >>using >> IPv6 except when IPv4 is bad enough that IPv6 is really better. >>=20 >> I can imagine some sites having to prefer IPv4. And HE does work for >>that. >> But I hope that is going to be a niche that we can hide somewhere in a >>corner. >>=20 >>> However, as important as I think IPv6 is, I should note that this >>>isn't about=20 >>> preferring IPv6 as much as it is preferring the stack that works - >>>hence "happ >>> y eyeballs." The assumption is that once IPv6's initial deployment >>>teething pr >>> oblems are resolved in each network, and CGN becomes more prevalent in >>>IPv4, I >>> Pv6 will be that "stack that works" more often than IPv4, rather than >>>the othe >>> r way around as it's currently presented. >>=20 >> The problem with preferring the stack that works is what do you do when >>IPv4 >> and IPv6 have parity? >>=20 >> CGNs have to be good enough that from a performance point of view, a >>host >> cannot easily tell that they are there. Otherwise, IPv4 would break too >>much. >>=20 >> What will happens in that case? Will the traffic be evenly distributed >>over >> IPv4 and IPv6? >>=20 >> So, IMHO, the only way forward is to prefer IPv6 and then let HE fall >>back to >> IPv4.=20 > >I agree. My experience with one OS implementation that does similar to HE >is that my computer no longer uses IPv6, because IPv4 almost always win, >no matter what. Because IPv4 is where the money is currently. Therefore, >if there is no pref for IPv6, then IPv6 will never happen, since no >trafic, no eyeballs, ... > >Marc. > >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From cb.list6@gmail.com Mon Sep 26 07:37:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B5721F8D44 for ; Mon, 26 Sep 2011 07:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.172 X-Spam-Level: X-Spam-Status: No, score=-4.172 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dokvr-ybpp9T for ; Mon, 26 Sep 2011 07:37:19 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9571221F8C59 for ; Mon, 26 Sep 2011 07:37:19 -0700 (PDT) Received: by yic13 with SMTP id 13so5097037yic.31 for ; Mon, 26 Sep 2011 07:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K1m34f15qUArR9MCL9uVS9vqvT8izWf6i7aAqBegJ9Q=; b=B8E1aSkiUZnq14VE/uxleS4kKZ8bMpc63/jGaNUS8W5rqUMuxxoe50v5ef1vS1aWY+ UN2Q0aDNuQtD5VJTHIlEZKyiyNubu041R8bDsQS6ACtzLsAFbgNssCKJjaCOCcLGGdLN ftA+c7MdmoQgBqcSYGJ9ujTPoFrN1Mhcglkkc= MIME-Version: 1.0 Received: by 10.68.15.194 with SMTP id z2mr29854365pbc.47.1317048001984; Mon, 26 Sep 2011 07:40:01 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 07:40:01 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 07:40:01 -0700 (PDT) In-Reply-To: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> Date: Mon, 26 Sep 2011 07:40:01 -0700 Message-ID: From: Cameron Byrne To: Marc Blanchet Content-Type: multipart/alternative; boundary=bcaec51f995f4f784004add92205 Cc: Philip Homburg , "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:37:20 -0000 --bcaec51f995f4f784004add92205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sep 26, 2011 7:19 AM, "Marc Blanchet" wrote: > > > Le 2011-09-26 =E0 10:15, Philip Homburg a =E9crit : > > > In your letter dated Mon, 26 Sep 2011 09:20:29 -0400 you wrote: > >> even > >> if there are some set of configurations or rules that would otherwise have the > >> host prefer IPv4. > > > > I think that's the important part. > > > > I think the way forward is to make IPv6 preferred. The HE can switch to IPv4 > > if IPv6 doesn't work well enough. > > > > The problem with making IPv4 preferred is that HE will mostly avoid using > > IPv6 except when IPv4 is bad enough that IPv6 is really better. > > > > I can imagine some sites having to prefer IPv4. And HE does work for that. > > But I hope that is going to be a niche that we can hide somewhere in a corner. > > > >> However, as important as I think IPv6 is, I should note that this isn'= t about > >> preferring IPv6 as much as it is preferring the stack that works - hence "happ > >> y eyeballs." The assumption is that once IPv6's initial deployment teething pr > >> oblems are resolved in each network, and CGN becomes more prevalent in IPv4, I > >> Pv6 will be that "stack that works" more often than IPv4, rather than the othe > >> r way around as it's currently presented. > > > > The problem with preferring the stack that works is what do you do when IPv4 > > and IPv6 have parity? > > > > CGNs have to be good enough that from a performance point of view, a host > > cannot easily tell that they are there. Otherwise, IPv4 would break too much. > > > > What will happens in that case? Will the traffic be evenly distributed over > > IPv4 and IPv6? > > > > So, IMHO, the only way forward is to prefer IPv6 and then let HE fall back to > > IPv4. > > I agree. My experience with one OS implementation that does similar to HE is that my computer no longer uses IPv6, because IPv4 almost always win, no matter what. Because IPv4 is where the money is currently. Therefore, if there is no pref for IPv6, then IPv6 will never happen, since no trafic, no eyeballs, ... > +1 Cb > Marc. > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --bcaec51f995f4f784004add92205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 26, 2011 7:19 AM, "Marc Blanchet" <marc.blanchet@viagenie.ca> wrote:
>
>
> Le 2011-09-26 =E0 10:15, Philip Homburg a =E9crit :
>
> > In your letter dated Mon, 26 Sep 2011 09:20:29 -0400 you wrote: > >> even
> >> if there are some set of configurations or rules that would o= therwise have the
> >> host prefer IPv4.
> >
> > I think that's the important part.
> >
> > I think the way forward is to make IPv6 preferred. The HE can swi= tch to IPv4
> > if IPv6 doesn't work well enough.
> >
> > The problem with making IPv4 preferred is that HE will mostly avo= id using
> > IPv6 except when IPv4 is bad enough that IPv6 is really better. > >
> > I can imagine some sites having to prefer IPv4. And HE does work = for that.
> > But I hope that is going to be a niche that we can hide somewhere= in a corner.
> >
> >> However, as important as I think IPv6 is, I should note that = this isn't about
> >> preferring IPv6 as much as it is preferring the stack that wo= rks - hence "happ
> >> y eyeballs." The assumption is that once IPv6's init= ial deployment teething pr
> >> oblems are resolved in each network, and CGN becomes more pre= valent in IPv4, I
> >> Pv6 will be that "stack that works" more often than= IPv4, rather than the othe
> >> r way around as it's currently presented.
> >
> > The problem with preferring the stack that works is what do you d= o when IPv4
> > and IPv6 have parity?
> >
> > CGNs have to be good enough that from a performance point of view= , a host
> > cannot easily tell that they are there. Otherwise, IPv4 would bre= ak too much.
> >
> > What will happens in that case? Will the traffic be evenly distri= buted over
> > IPv4 and IPv6?
> >
> > So, IMHO, the only way forward is to prefer IPv6 and then let HE = fall back to
> > IPv4.
>
> I agree. My experience with one OS implementation that does similar to= HE is that my computer no longer uses IPv6, because IPv4 almost always win= , no matter what. Because IPv4 is where the money is currently. Therefore, = if there is no pref for IPv6, then IPv6 will never happen, since no trafic,= no eyeballs, ...
>

+1

Cb

> Marc.
>
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--bcaec51f995f4f784004add92205-- From rajiva@cisco.com Mon Sep 26 08:50:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9FF11E80AB for ; Mon, 26 Sep 2011 08:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v7wxunAStPl for ; Mon, 26 Sep 2011 08:50:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A24A811E80A4 for ; Mon, 26 Sep 2011 08:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4566; q=dns/txt; s=iport; t=1317052387; x=1318261987; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=JWGV+aVuW7MKY3kSB9B0wctSbb3k5jCVvtHxORa7K04=; b=kGltqcTEuf4ZQzM1P2WIrMKaneHilXCwVZP103mmDBFzOJ3Q8I/+bg3w yeeoniM4HDTEHbvreufIJEG8fC0/8TSCO2nSAKKVl6iTT1n3ySOzGoacY K4Jxx31n2CvxC6iqxuOFFOe+5BTmTV84KAtpxCuLfSbFKVsGSnJ/AZJ9P U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAB+fgE6tJXG//2dsb2JhbABBmQqPB3iBUwEBAQECAQEBAQ8BHQo0BAcFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggTB4dWBpw2AZ4QhitgBIdykQuMJg X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="24072667" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2011 15:53:06 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8QFr6iK015566; Mon, 26 Sep 2011 15:53:06 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 10:53:06 -0500 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: Mon, 26 Sep 2011 10:53:04 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC Thread-Index: Acx6gmjw3VBsbCf0T1SSAIDXaXmLZABy0PYgAAWrVYA= References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> From: "Rajiv Asati (rajiva)" To: "George, Wes" , "Philip Homburg" X-OriginalArrivalTime: 26 Sep 2011 15:53:06.0063 (UTC) FILETIME=[617679F0:01CC7C64] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 15:50:24 -0000 > However, as important as I think IPv6 is, I should note that this isn't about > preferring IPv6 as much as it is preferring the stack that works - hence > "happy eyeballs." The assumption is that once IPv6's initial deployment > teething problems are resolved in each network, and CGN becomes more prevalent > in IPv4, IPv6 will be that "stack that works" more often than IPv4, rather > than the other way around as it's currently presented. +1. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > George, Wes > Sent: Monday, September 26, 2011 9:20 AM > To: Philip Homburg > Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC >=20 > I believe you missed my point and we're actually in agreement for the most > part. >=20 > Currently the section I mentioned discusses HE as a solution for *IPv6* > brokenness (mainly by either falling back to IPv4 more quickly or by tracking > state to determine which stack should be used for which destinations). I hope > that IPv6 brokenness is a short-term problem and that as more people move to > IPv6, *IPv4* may be the more broken item, and therefore we need a mechanism to > ensure that IPv6 is preferred when it will provide the better user experience, > even if there are some set of configurations or rules that would otherwise > have the host prefer IPv4. I don't think that this moves away from the idea > that preferring IPv6 whenever possible is the goal. >=20 > However, as important as I think IPv6 is, I should note that this isn't about > preferring IPv6 as much as it is preferring the stack that works - hence > "happy eyeballs." The assumption is that once IPv6's initial deployment > teething problems are resolved in each network, and CGN becomes more prevalent > in IPv4, IPv6 will be that "stack that works" more often than IPv4, rather > than the other way around as it's currently presented. >=20 > Thanks, >=20 > Wes >=20 >=20 > -----Original Message----- > From: pch-b29AA871B@u-1.phicoh.com [mailto:pch-b29AA871B@u-1.phicoh.com] On > Behalf Of Philip Homburg > Sent: Saturday, September 24, 2011 2:23 AM > To: George, Wes > Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC >=20 > In your letter dated Fri, 23 Sep 2011 14:28:44 -0400 you wrote: > >First for the Abstract/Introduction: > >I'd rather this didn't focus exclusively on the v4 working/v6 broken > permutati > >on. Most of what I can see shows HE working in either direction, and as we > mov > >e into a situation where IPv4 may be the more "broken" connectivity due to > mul > >tiple layers of NAT, attempts to do on-demand IPv4 provisioning, etc, it may > b > >e that HE can be used to reduce the potential for IPv4 brokenness's impact on > >users. I realize that generally most OSes prefer IPv6 if given a AAAA today, > b > >ut if we're implementing an algorithm to take some action based on > information > > gathered about performance on which stack to use, sometimes maybe it's worth > >talking in more generic terms. >=20 > When I first started playing HE I had the same idea. Make it more symmetric. > But later I realized that we want to transition to IPv6. So it is inherently > asymmetric. We would like to use IPv6 as much as possible. >=20 > Also, keeping the document focused on IPv6 versus IPv4 keeps it simple. And > we want something now, not a fully general solution in 10 years time. >=20 > So I would prefer to keep it the way it is. >=20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marc.blanchet@viagenie.ca Mon Sep 26 09:07:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D90621F8D42 for ; Mon, 26 Sep 2011 09:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shYVlHvARmEI for ; Mon, 26 Sep 2011 09:07:49 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE721F8C34 for ; Mon, 26 Sep 2011 09:07:49 -0700 (PDT) Received: from [IPv6:2607:fa48:6e6b:c280:3cbe:25fe:e30e:bedd] (unknown [IPv6:2607:fa48:6e6b:c280:3cbe:25fe:e30e:bedd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 89B2B21C52; Mon, 26 Sep 2011 12:10:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> Date: Mon, 26 Sep 2011 12:10:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1244.3) Cc: Philip Homburg , v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 16:07:50 -0000 Le 2011-09-26 =E0 11:53, Rajiv Asati (rajiva) a =E9crit : >> However, as important as I think IPv6 is, I should note that this > isn't about >> preferring IPv6 as much as it is preferring the stack that works - > hence >> "happy eyeballs." The assumption is that once IPv6's initial > deployment >> teething problems are resolved in each network, and CGN becomes more > prevalent >> in IPv4, IPv6 will be that "stack that works" more often than IPv4, > rather >> than the other way around as it's currently presented. >=20 > +1. disagree. that assumption is wrong. providers are pushing vendors as = much as possible to provide CGN as transparent as possible as a router. = There will always be a push to make CGN as good as routers. The possible = limitation on the number of ports may or may not be detected by HE. = Therefore, IPv4 will almost always win, because IPv4 is where the money = is. So I think the assumption that IPv6 will win using HE is not correct. Marc. >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf > Of >> George, Wes >> Sent: Monday, September 26, 2011 9:20 AM >> To: Philip Homburg >> Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org >> Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC >>=20 >> I believe you missed my point and we're actually in agreement for the > most >> part. >>=20 >> Currently the section I mentioned discusses HE as a solution for > *IPv6* >> brokenness (mainly by either falling back to IPv4 more quickly or by > tracking >> state to determine which stack should be used for which = destinations). > I hope >> that IPv6 brokenness is a short-term problem and that as more people > move to >> IPv6, *IPv4* may be the more broken item, and therefore we need a > mechanism to >> ensure that IPv6 is preferred when it will provide the better user > experience, >> even if there are some set of configurations or rules that would > otherwise >> have the host prefer IPv4. I don't think that this moves away from = the > idea >> that preferring IPv6 whenever possible is the goal. >>=20 >> However, as important as I think IPv6 is, I should note that this > isn't about >> preferring IPv6 as much as it is preferring the stack that works - > hence >> "happy eyeballs." The assumption is that once IPv6's initial > deployment >> teething problems are resolved in each network, and CGN becomes more > prevalent >> in IPv4, IPv6 will be that "stack that works" more often than IPv4, > rather >> than the other way around as it's currently presented. >>=20 >> Thanks, >>=20 >> Wes >>=20 >>=20 >> -----Original Message----- >> From: pch-b29AA871B@u-1.phicoh.com > [mailto:pch-b29AA871B@u-1.phicoh.com] On >> Behalf Of Philip Homburg >> Sent: Saturday, September 24, 2011 2:23 AM >> To: George, Wes >> Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org >> Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC >>=20 >> In your letter dated Fri, 23 Sep 2011 14:28:44 -0400 you wrote: >>> First for the Abstract/Introduction: >>> I'd rather this didn't focus exclusively on the v4 working/v6 broken >> permutati >>> on. Most of what I can see shows HE working in either direction, and > as we >> mov >>> e into a situation where IPv4 may be the more "broken" connectivity > due to >> mul >>> tiple layers of NAT, attempts to do on-demand IPv4 provisioning, = etc, > it may >> b >>> e that HE can be used to reduce the potential for IPv4 brokenness's > impact on >>> users. I realize that generally most OSes prefer IPv6 if given a = AAAA > today, >> b >>> ut if we're implementing an algorithm to take some action based on >> information >>> gathered about performance on which stack to use, sometimes maybe > it's worth >>> talking in more generic terms. >>=20 >> When I first started playing HE I had the same idea. Make it more > symmetric. >> But later I realized that we want to transition to IPv6. So it is > inherently >> asymmetric. We would like to use IPv6 as much as possible. >>=20 >> Also, keeping the document focused on IPv6 versus IPv4 keeps it > simple. And >> we want something now, not a fully general solution in 10 years time. >>=20 >> So I would prefer to keep it the way it is. >>=20 >>=20 >>=20 >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or = subject > to >> copyright belonging to Time Warner Cable. This E-mail is intended > solely for >> the use of the individual or entity to which it is addressed. If you > are not >> the intended recipient of this E-mail, you are hereby notified that > any >> dissemination, distribution, copying, or action taken in relation to > the >> contents of and attachments to this E-mail is strictly prohibited and > may be >> unlawful. If you have received this E-mail in error, please notify = the > sender >> immediately and permanently delete the original and any copy of this > E-mail >> and any printout. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Mon Sep 26 09:24:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EB521F8DA2 for ; Mon, 26 Sep 2011 09:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk0obqsr4xbn for ; Mon, 26 Sep 2011 09:24:29 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AEBAC21F8D94 for ; Mon, 26 Sep 2011 09:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6784; q=dns/txt; s=iport; t=1317054432; x=1318264032; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4Yb2my1Rr3Bta8cnyndJYbvTWNkSBLnrfVZnUyD7rFo=; b=Wn+QjplaCmTyTSk+ZiU4g1YY363PlObtJNauBTLXBw8HU9KyJ7TX9a16 C8MOcYBR/fbxkUb829fI32OClNnj7KgwKQbG9w2RuCOD/6o1KijLh+kAN tz3KxUjHZRoYdiXu6Lh1IYjmUc5/yEuqhVHKAE6ATTUIH8VKabEhhUWfz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAJ2mgE6tJXHA/2dsb2JhbABCmQqPB3iBUwEBAQECAQEBAQ8BHT4EBwUHBAIBCBEEAQEBCgYXAQYBJh8JCAEBBBMIEwMEh1YGnFkBnhmGK2AEh0IwkQuMJg X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="24086988" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2011 16:27:11 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p8QGRBdY009893; Mon, 26 Sep 2011 16:27:11 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 11:27:10 -0500 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, 26 Sep 2011 11:27:10 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC Thread-Index: Acx8ZtI1U4xBeV64TpqSJpR2zXYbJwAAZ36g References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Marc Blanchet" X-OriginalArrivalTime: 26 Sep 2011 16:27:10.0879 (UTC) FILETIME=[2444A2F0:01CC7C69] Cc: Philip Homburg , v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 16:24:30 -0000 Marc, > So I think the assumption that IPv6 will win using HE is not correct. Where do you see us making that assumption?=20 In fact, we are all shying away from making that assumption, as much as = we would wish for IPv6 to win. > always be a push to make CGN as good as routers. The possible = limitation on > the number of ports may or may not be detected by HE. Therefore, IPv4 = will > almost always win, because IPv4 is where the money is. Hmmm....if any sort of NAT(44) exhausts its (NAT) sessions capacity, = then IPv4 connectivity would be broken for any new IP sessions relating = to the hosts. Period. This should get detected by HE and declare IPv4 to = loose.=20 Cheers, Rajiv > -----Original Message----- > From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] > Sent: Monday, September 26, 2011 12:10 PM > To: Rajiv Asati (rajiva) > Cc: George, Wes; Philip Homburg; v6ops@ietf.org; = v6ops-chairs@tools.ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC >=20 >=20 > Le 2011-09-26 =E0 11:53, Rajiv Asati (rajiva) a =E9crit : >=20 > >> However, as important as I think IPv6 is, I should note that this > > isn't about > >> preferring IPv6 as much as it is preferring the stack that works - > > hence > >> "happy eyeballs." The assumption is that once IPv6's initial > > deployment > >> teething problems are resolved in each network, and CGN becomes = more > > prevalent > >> in IPv4, IPv6 will be that "stack that works" more often than IPv4, > > rather > >> than the other way around as it's currently presented. > > > > +1. >=20 >=20 > disagree. that assumption is wrong. providers are pushing vendors as = much as > possible to provide CGN as transparent as possible as a router. There = will > always be a push to make CGN as good as routers. The possible = limitation on > the number of ports may or may not be detected by HE. Therefore, IPv4 = will > almost always win, because IPv4 is where the money is. >=20 > So I think the assumption that IPv6 will win using HE is not correct. >=20 > Marc. >=20 > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf > > Of > >> George, Wes > >> Sent: Monday, September 26, 2011 9:20 AM > >> To: Philip Homburg > >> Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org > >> Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC > >> > >> I believe you missed my point and we're actually in agreement for = the > > most > >> part. > >> > >> Currently the section I mentioned discusses HE as a solution for > > *IPv6* > >> brokenness (mainly by either falling back to IPv4 more quickly or = by > > tracking > >> state to determine which stack should be used for which = destinations). > > I hope > >> that IPv6 brokenness is a short-term problem and that as more = people > > move to > >> IPv6, *IPv4* may be the more broken item, and therefore we need a > > mechanism to > >> ensure that IPv6 is preferred when it will provide the better user > > experience, > >> even if there are some set of configurations or rules that would > > otherwise > >> have the host prefer IPv4. I don't think that this moves away from = the > > idea > >> that preferring IPv6 whenever possible is the goal. > >> > >> However, as important as I think IPv6 is, I should note that this > > isn't about > >> preferring IPv6 as much as it is preferring the stack that works - > > hence > >> "happy eyeballs." The assumption is that once IPv6's initial > > deployment > >> teething problems are resolved in each network, and CGN becomes = more > > prevalent > >> in IPv4, IPv6 will be that "stack that works" more often than IPv4, > > rather > >> than the other way around as it's currently presented. > >> > >> Thanks, > >> > >> Wes > >> > >> > >> -----Original Message----- > >> From: pch-b29AA871B@u-1.phicoh.com > > [mailto:pch-b29AA871B@u-1.phicoh.com] On > >> Behalf Of Philip Homburg > >> Sent: Saturday, September 24, 2011 2:23 AM > >> To: George, Wes > >> Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org > >> Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC > >> > >> In your letter dated Fri, 23 Sep 2011 14:28:44 -0400 you wrote: > >>> First for the Abstract/Introduction: > >>> I'd rather this didn't focus exclusively on the v4 working/v6 = broken > >> permutati > >>> on. Most of what I can see shows HE working in either direction, = and > > as we > >> mov > >>> e into a situation where IPv4 may be the more "broken" = connectivity > > due to > >> mul > >>> tiple layers of NAT, attempts to do on-demand IPv4 provisioning, = etc, > > it may > >> b > >>> e that HE can be used to reduce the potential for IPv4 = brokenness's > > impact on > >>> users. I realize that generally most OSes prefer IPv6 if given a = AAAA > > today, > >> b > >>> ut if we're implementing an algorithm to take some action based on > >> information > >>> gathered about performance on which stack to use, sometimes maybe > > it's worth > >>> talking in more generic terms. > >> > >> When I first started playing HE I had the same idea. Make it more > > symmetric. > >> But later I realized that we want to transition to IPv6. So it is > > inherently > >> asymmetric. We would like to use IPv6 as much as possible. > >> > >> Also, keeping the document focused on IPv6 versus IPv4 keeps it > > simple. And > >> we want something now, not a fully general solution in 10 years = time. > >> > >> So I would prefer to keep it the way it is. > >> > >> > >> > >> This E-mail and any of its attachments may contain Time Warner = Cable > >> proprietary information, which is privileged, confidential, or = subject > > to > >> copyright belonging to Time Warner Cable. This E-mail is intended > > solely for > >> the use of the individual or entity to which it is addressed. If = you > > are not > >> the intended recipient of this E-mail, you are hereby notified that > > any > >> dissemination, distribution, copying, or action taken in relation = to > > the > >> contents of and attachments to this E-mail is strictly prohibited = and > > may be > >> unlawful. If you have received this E-mail in error, please notify = the > > sender > >> immediately and permanently delete the original and any copy of = this > > E-mail > >> and any printout. > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Mon Sep 26 10:27:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3CF21F8C4A for ; Mon, 26 Sep 2011 10:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.621 X-Spam-Level: X-Spam-Status: No, score=-106.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBh8xkdN0bUO for ; Mon, 26 Sep 2011 10:27:12 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35D21F8C36 for ; Mon, 26 Sep 2011 10:27:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LS5006R74KX2R81@mail-out.apple.com> for v6ops@ietf.org; Mon, 26 Sep 2011 10:29:55 -0700 (PDT) X-AuditID: 11807134-b7cedae000007447-78-4e80b424ef15 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 6C.9C.29767.424B08E4; Mon, 26 Sep 2011 10:19:32 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LS500LDR4LUJG30@koseret.apple.com> for v6ops@ietf.org; Mon, 26 Sep 2011 10:29:54 -0700 (PDT) From: james woodyatt In-reply-to: Date: Mon, 26 Sep 2011 10:29:54 -0700 Message-id: <06145DC0-931F-485E-8447-BB844C52E2F3@apple.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1248) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUiON1OXVdlS4OfwfwLChanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsmDF5kKVjFVbNi/ha2B8TFjFyMnh4SAicTRpsNMELaYxIV7 69m6GLk4hAQ6mSR2taxjB0nwCghK/Jh8j6WLkYODWUBe4uB5WZAws4CWxPdHrSwQ9VOYJF5d aWIBSQgLWEq8XdwM1ssmoCLx7fJdsAWcAvYSaw60sYLMYRFQlWjbGgsx3kbi4cq5rBBz3jNJ HN2yFKxeBKh3ypn7bBDHyUqsnDaZdQIj/ywkJ81COGkWkpMWMDKvYhQsSs1JrDQ00UssKMhJ 1UvOz93ECAqwhkKTHYwHf/IfYhTgYFTi4c1cXe8nxJpYVlyZe4hRgoNZSYR37coGPyHelMTK qtSi/Pii0pzU4kOM0hwsSuK8fv61fkIC6YklqdmpqQWpRTBZJg5OqQbG1f9uHdPQqy4/J7Qq 8cz3Kf9577dYZLr0JC7g83OR8kwwvqOfXFKcOCEsNny6k3Xj2WQ11fpP8d5HxO1ORr59IvnF Pv+Z3TbLe5dlrL4ptB+ZFaZkoXzeV55f60WlxfHDj0Usq/QqjizMlA/uWNj39IqV2+te1bAP 0/6z/NLI9KybN+Vgwj8lluKMREMt5qLiRAAjGU3aLAIAAA== Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 17:27:13 -0000 On Sep 26, 2011, at 09:10 , Marc Blanchet wrote: > > So I think the assumption that IPv6 will win using HE is not correct. Absolutely correct. That assumption is based on a myth that needs to die. -- james woodyatt member of technical staff, core os networking From wesley.george@twcable.com Mon Sep 26 11:33:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BF51F0C4F for ; Mon, 26 Sep 2011 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYxDw-mOxEY4 for ; Mon, 26 Sep 2011 11:33:47 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 051A11F0C4D for ; Mon, 26 Sep 2011 11:33:46 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,592,1309752000"; d="scan'208";a="278399111" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 26 Sep 2011 14:33:35 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 26 Sep 2011 14:36:30 -0400 From: "George, Wes" To: Marc Blanchet , "Rajiv Asati (rajiva)" Date: Mon, 26 Sep 2011 14:36:28 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC Thread-Index: Acx8ZtIZ2emf8lmsTxqT4TynU9h8qgAEf/RQ Message-ID: <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Philip Homburg , "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 18:33:47 -0000 -----Original Message----- From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] Sent: Monday, September 26, 2011 12:10 PM Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC >The assumption is that once IPv6's initial > deployment >> teething problems are resolved in each network, and CGN becomes more > prevalent >> in IPv4, IPv6 will be that "stack that works" more often than IPv4, > rather >> than the other way around as it's currently presented. disagree. that assumption is wrong. providers are pushing vendors as much a= s possible to provide CGN as transparent as possible as a router. There wil= l always be a push to make CGN as good as routers. The possible limitation = on the number of ports may or may not be detected by HE. Therefore, IPv4 wi= ll almost always win, because IPv4 is where the money is. So I think the assumption that IPv6 will win using HE is not correct. Marc. WEG] This seems to go the other direction - assuming that IPv6 will always = be broken, which is also a faulty assumption. Second, history shows that no= matter what providers push vendors to do, they'll be disappointed by what'= s actually delivered. I have no doubt that CGNs will continue to fix some o= f the things that are broken, but I do not for a second believe that they w= ill get to the point where they are transparent (especially as transparent = as a router) to all forms of user traffic, nor should we expend the effort = to get them there. That amounts to defining and building an ALG for anythin= g that doesn't behave like bog-standard traffic. At some point, we need to = stop trying to "fix" IPv4, and I expect that point to happen long before we= reach a "perfect" CGN, if it hasn't already occurred. Lastly, whether or not each type of CGN failing is detected by HE and it ma= kes the right decision really depends on the way that HE is implemented, bu= t I'm not sure that's completely relevant to the point I was making origina= lly about the way that the intro and abstract are currently worded to focus= exclusively on IPv6 brokenness, when later in the document it becomes more= agnostic. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From pch-b29AA871B@u-1.phicoh.com Mon Sep 26 11:49:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A121F8E4C for ; Mon, 26 Sep 2011 11:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ83P-zuljbh for ; Mon, 26 Sep 2011 11:49:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7571A21F8E4A for ; Mon, 26 Sep 2011 11:49:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8GHz-0001iSC; Mon, 26 Sep 2011 20:52:27 +0200 Message-Id: To: "George, Wes" From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> In-reply-to: Your message of "Mon, 26 Sep 2011 14:36:28 -0400 ." <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> Date: Mon, 26 Sep 2011 20:52:17 +0200 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 18:49:46 -0000 In your letter dated Mon, 26 Sep 2011 14:36:28 -0400 you wrote: >WEG] This seems to go the other direction - assuming that IPv6 will always = >be broken, which is also a faulty assumption. Second, history shows that no= > matter what providers push vendors to do, they'll be disappointed by what'= >s actually delivered. I have no doubt that CGNs will continue to fix some o= >f the things that are broken, but I do not for a second believe that they w= >ill get to the point where they are transparent (especially as transparent = >as a router) to all forms of user traffic, nor should we expend the effort = >to get them there. That amounts to defining and building an ALG for anythin= >g that doesn't behave like bog-standard traffic. At some point, we need to = >stop trying to "fix" IPv4, and I expect that point to happen long before we= > reach a "perfect" CGN, if it hasn't already occurred. >Lastly, whether or not each type of CGN failing is detected by HE and it ma= >kes the right decision really depends on the way that HE is implemented, bu= >t I'm not sure that's completely relevant to the point I was making origina= >lly about the way that the intro and abstract are currently worded to focus= > exclusively on IPv6 brokenness, when later in the document it becomes more= > agnostic. I'm not quite sure about the point you are trying to make. If IPv6 is better than IPv4, then just prefer IPv6 and be done with it. If IPv6 sometimes or regularly performs worse than IPv4 then HE should be able to switch back to IPv4 when that happens. The other way around, preferring IPv4 when IPv6 actually performs better doesn't seem to make much sense to me (with some exceptions). So, yes, HE is for the time when IPv6 is worse than IPv4. By the time IPv6 becomes the norm, and IPv4 becomes legacy, the role of HE as described in this document is essentially over. The same techniques may be used for a more general address selection algorithm. But let's do that we have plenty of experience with HE. From wesley.george@twcable.com Mon Sep 26 12:03:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CD51F0C6B for ; Mon, 26 Sep 2011 12:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.233 X-Spam-Level: X-Spam-Status: No, score=-0.233 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FJUCdrp8Vu6 for ; Mon, 26 Sep 2011 12:03:00 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7541F0C61 for ; Mon, 26 Sep 2011 12:02:58 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,592,1309752000"; d="scan'208";a="278415097" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 26 Sep 2011 15:02:46 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 26 Sep 2011 15:05:41 -0400 From: "George, Wes" To: Philip Homburg Date: Mon, 26 Sep 2011 15:05:39 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC Thread-Index: Acx8fXX8WUiiAYpFTDOLBIsDyqfZWwAADnnw Message-ID: <34E4F50CAFA10349A41E0756550084FB0FA698B1@PRVPEXVS04.corp.twcable.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:03:00 -0000 I'm not quite sure about the point you are trying to make. WEG] ok, I'll try again.... If IPv6 is better than IPv4, then just prefer IPv6 and be done with it. WEG] yes If IPv6 sometimes or regularly performs worse than IPv4 then HE should be able to switch back to IPv4 when that happens. WEG] yes The other way around, preferring IPv4 when IPv6 actually performs better doesn't seem to make much sense to me (with some exceptions). WEG] I never suggested this, and I agree that's a bad idea. What I was saying was- if *local address policy* (not HE) says "prefer IPv4= ", then there are circumstances where the user experience might suffer. HE = can easily be extended to support those cases, override the local policy us= e IPv6 at least when it performs better. This results in a better user expe= rience. I'm simply saying that the draft does not need to be written such t= hat it eliminates the option of using HE in this fashion. It is an address-= family selection algorithm, it's just that the primary use right now is to = help with short-term IPv6 brokenness. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From pch-b29AA871B@u-1.phicoh.com Mon Sep 26 12:21:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB4F1F0C74 for ; Mon, 26 Sep 2011 12:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXN5XoE9hElc for ; Mon, 26 Sep 2011 12:21:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA721F0C62 for ; Mon, 26 Sep 2011 12:21:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8Gmf-0001j4C; Mon, 26 Sep 2011 21:24:09 +0200 Message-Id: To: "George, Wes" From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA698B1@PRVPEXVS04.corp.twcable.com> In-reply-to: Your message of "Mon, 26 Sep 2011 15:05:39 -0400 ." <34E4F50CAFA10349A41E0756550084FB0FA698B1@PRVPEXVS04.corp.twcable.com> Date: Mon, 26 Sep 2011 21:24:01 +0200 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:21:29 -0000 In your letter dated Mon, 26 Sep 2011 15:05:39 -0400 you wrote: >The other way around, preferring IPv4 when IPv6 actually performs better >doesn't seem to make much sense to me (with some exceptions). >WEG] I never suggested this, and I agree that's a bad idea. >What I was saying was- if *local address policy* (not HE) says "prefer IPv4= >", then there are circumstances where the user experience might suffer. HE = >can easily be extended to support those cases, override the local policy us= >e IPv6 at least when it performs better. This results in a better user expe= >rience. I'm simply saying that the draft does not need to be written such t= >hat it eliminates the option of using HE in this fashion. It is an address-= >family selection algorithm, it's just that the primary use right now is to = >help with short-term IPv6 brokenness. So we are talking about the, hopefully exceptional, case where some admin sets the address selection policy for a host to prefer IPv4. I would have to check the details, but I think for my own HE implementation, it would require changes to fully support this case. It will work to some extent, but not as well as the the way around. The main reason it doesn't work, is that the part of the kernel that implements HE isn't aware of the address policy table. It doesn't have to, it only has to probe IPv6 every once in a while. Making a switch to make it probe IPv4 instead is of course possible, but I would have to see a very good use case before I would consider doing that. My impression is that you are making things needlessly complicated. Thinking of HE as preferring IPv6 and then falling back to IPv4 is the right frame of mind. It is easy to explain. Making it more symmetric leads to complications. You have to figure out from the address policy table what protocol is preferred and then tell the HE module to probe that protocol. In the other case, you can just hardcode probing IPv6. And, most operators don't want admins to configure systems to prefer IPv4 because that just needlessly prolongs the life of IPv4. From marc.blanchet@viagenie.ca Mon Sep 26 12:33:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4AB11E80D5 for ; Mon, 26 Sep 2011 12:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.833 X-Spam-Level: X-Spam-Status: No, score=-102.833 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFDBF--gYh7H for ; Mon, 26 Sep 2011 12:33:59 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 47E5511E808D for ; Mon, 26 Sep 2011 12:33:59 -0700 (PDT) Received: from [IPv6:2607:fa48:6e6b:c280:c057:ddd4:10b0:6027] (unknown [IPv6:2607:fa48:6e6b:c280:c057:ddd4:10b0:6027]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DCFC121F46; Mon, 26 Sep 2011 15:36:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> Date: Mon, 26 Sep 2011 15:36:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1244.3) Cc: Philip Homburg , "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:34:00 -0000 Le 2011-09-26 =E0 14:36, George, Wes a =E9crit : > -----Original Message----- > From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] > Sent: Monday, September 26, 2011 12:10 PM > Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC >=20 >> The assumption is that once IPv6's initial >> deployment >>> teething problems are resolved in each network, and CGN becomes more >> prevalent >>> in IPv4, IPv6 will be that "stack that works" more often than IPv4, >> rather >>> than the other way around as it's currently presented. >=20 > disagree. that assumption is wrong. providers are pushing vendors as = much as possible to provide CGN as transparent as possible as a router. = There will always be a push to make CGN as good as routers. The possible = limitation on the number of ports may or may not be detected by HE. = Therefore, IPv4 will almost always win, because IPv4 is where the money = is. >=20 > So I think the assumption that IPv6 will win using HE is not correct. >=20 > Marc. >=20 > WEG] This seems to go the other direction - assuming that IPv6 will = always be broken, which is also a faulty assumption. I'm not saying that IPv6 will always be broken. I'm just saying that = IPv4 will be always better than IPv6 for quite a long time, since it is = still IPv4 that brings money.=20 So if HE does not give a pref to IPv6, then IPv4 will always win, and = therefore does not help IPv6 deployment. Marc. > Second, history shows that no matter what providers push vendors to = do, they'll be disappointed by what's actually delivered. I have no = doubt that CGNs will continue to fix some of the things that are broken, = but I do not for a second believe that they will get to the point where = they are transparent (especially as transparent as a router) to all = forms of user traffic, nor should we expend the effort to get them = there. That amounts to defining and building an ALG for anything that = doesn't behave like bog-standard traffic. At some point, we need to stop = trying to "fix" IPv4, and I expect that point to happen long before we = reach a "perfect" CGN, if it hasn't already occurred. > Lastly, whether or not each type of CGN failing is detected by HE and = it makes the right decision really depends on the way that HE is = implemented, but I'm not sure that's completely relevant to the point I = was making originally about the way that the intro and abstract are = currently worded to focus exclusively on IPv6 brokenness, when later in = the document it becomes more agnostic. >=20 > Wes George >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From jhw@apple.com Mon Sep 26 13:21:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E371F0CE4 for ; Mon, 26 Sep 2011 13:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.62 X-Spam-Level: X-Spam-Status: No, score=-106.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeytFSdGxXL6 for ; Mon, 26 Sep 2011 13:21:53 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id BAD9A1F0CCA for ; Mon, 26 Sep 2011 13:21:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LS500621CNW2RW1@mail-out.apple.com> for v6ops@ietf.org; Mon, 26 Sep 2011 13:24:23 -0700 (PDT) X-AuditID: 11807137-b7bddae0000031a0-bb-4e80e120d029 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 92.E4.12704.021E08E4; Mon, 26 Sep 2011 13:31:28 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LS5009TWCOMTK00@koseret.apple.com> for v6ops@ietf.org; Mon, 26 Sep 2011 13:24:22 -0700 (PDT) From: james woodyatt In-reply-to: Date: Mon, 26 Sep 2011 13:24:22 -0700 Message-id: <450C66D5-136E-4E20-A963-0DF6A30A34B8@apple.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1248) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUiON1OXVfhYYOfQdNqQYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro29hB3vBEZaKE9/XMTUwnmXuYuTkkBAwkXi34ioThC0mceHe erYuRi4OIYFOJokFO/azgiR4BQQlfky+x9LFyMHBLCAvcfC8LEiYWUBL4vujVhaI+ilMEt2b 7rKDJIQFLCXeLm4Gs9kEVCS+Xb7LBNLLKWAvcbVZDiTMIqAqcWTeY6jxNhJbzz1hgpjzllni 0b4vjCAJEaDeKWfus0EcJyuxctpk1gmM/LOQnDQL4aRZSE5awMi8ilGwKDUnsdLQTC+xoCAn VS85P3cTIyjAGgrNdzBu/yt3iFGAg1GJh3flkQY/IdbEsuLK3EOMEhzMSiK8a1cChXhTEiur Uovy44tKc1KLDzFKc7AoifP6BNf6CQmkJ5akZqemFqQWwWSZODilGhhjJpzeYfb9mt2Bj+dy fbz5Ux4brtvwjf1PQNF9oUW9Mqva5fm2XXy1uWQ/4/x/rdtPu6u5FXDd3ZfZdlJloxmvQ5n/ NBXGLe/mHJ3pOE1T7EVvw0nlT9a7vi9lrFJqUd14y1E94XeJi/FvxdxlDtP7jn20ankpGMn9 0WdPo9FkzznSSRLnF7YosRRnJBpqMRcVJwIAl4FP0CwCAAA= Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:21:54 -0000 On Sep 26, 2011, at 12:36 , Marc Blanchet wrote: > > So if HE does not give a pref to IPv6, then IPv4 will always win, and therefore does not help IPv6 deployment. Well, that's not true either. At this point, anything that permits IPv6 deployment without damaging coexistence with IPv4 would be a big help to the furtherance of IPv6. HappyEyeballs, even if it does not give any preference to IPv6, would greatly improve coexistence with IPv4, and would therefore be a big help. -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Mon Sep 26 13:32:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EBB21F8BB0 for ; Mon, 26 Sep 2011 13:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNM3ztXBizQB for ; Mon, 26 Sep 2011 13:32:14 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 799A721F8B9C for ; Mon, 26 Sep 2011 13:32:14 -0700 (PDT) Received: by yic13 with SMTP id 13so5451794yic.31 for ; Mon, 26 Sep 2011 13:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m9jZ+0IG0byHh5ffT8ZQrzBYPp8zWo2O5vhLaDYACYA=; b=vnrgGqqkUGm2ZwfWKJzkftVJuM1WCeZUwo5+G1vVV9sJR5tYQxPr8mjnGILe6dlM/5 FwMTOvTFxYVX/rsLfJSfBFchjj6rkHSJEVQM3lmxR46odkZbqtXfR/zQCfMvGsu5wnvz E11Viggjvun7BLASvb9uTYK9fIYD9zWHQogyY= Received: by 10.236.184.10 with SMTP id r10mr43068849yhm.81.1317069297888; Mon, 26 Sep 2011 13:34:57 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id s20sm11088957ank.11.2011.09.26.13.34.55 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 13:34:57 -0700 (PDT) Message-ID: <4E80E1ED.5060209@gmail.com> Date: Tue, 27 Sep 2011 09:34:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:32:15 -0000 On 2011-09-27 03:40, Cameron Byrne wrote: > On Sep 26, 2011 7:19 AM, "Marc Blanchet" wrote: >> >> ... >> I agree. My experience with one OS implementation that does similar to HE >> is that my computer no longer uses IPv6, because IPv4 almost always win, no >> matter what. Because IPv4 is where the money is currently. Therefore, if >> there is no pref for IPv6, then IPv6 will never happen, since no trafic, no >> eyeballs, ... > > +1 > > Cb Thus, IMHO there SHOULD be a tuning parameter of some kind, whose default setting would be something like "prefer IPv6 unless it is 25% slower than IPv4". On 2011-09-27 05:27, Rajiv Asati (rajiva) wrote: ... > Hmmm....if any sort of NAT(44) exhausts its (NAT) sessions capacity, then IPv4 connectivity would be broken for any new IP sessions relating to the hosts. Period. This should get detected by HE and declare IPv4 to loose. That seems a bit like magic. In any case it would need to be predictive: "The NAPT44 is going to run out of port numbers in 5 minutes, so prefer IPv6 even though it's slower". Good luck with implementing that. Brian From joelja@bogus.com Mon Sep 26 13:38:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB111F0CF3 for ; Mon, 26 Sep 2011 13:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMbQ+JhyM5O1 for ; Mon, 26 Sep 2011 13:38:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 80D511F0CE6 for ; Mon, 26 Sep 2011 13:38:28 -0700 (PDT) Received: from Zorch.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p8QKf82M006614 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 26 Sep 2011 20:41:10 GMT (envelope-from joelja@bogus.com) Message-ID: <4E80E35F.5090003@bogus.com> Date: Mon, 26 Sep 2011 13:41:03 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: james woodyatt References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> <450C66D5-136E-4E20-A963-0DF6A30A34B8@apple.com> In-Reply-To: <450C66D5-136E-4E20-A963-0DF6A30A34B8@apple.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 26 Sep 2011 20:41:10 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:38:29 -0000 On 9/26/11 13:24 , james woodyatt wrote: > On Sep 26, 2011, at 12:36 , Marc Blanchet wrote: >> >> So if HE does not give a pref to IPv6, then IPv4 will always win, >> and therefore does not help IPv6 deployment. > > Well, that's not true either. At this point, anything that permits > IPv6 deployment without damaging coexistence with IPv4 would be a big > help to the furtherance of IPv6. HappyEyeballs, even if it does not > give any preference to IPv6, would greatly improve coexistence with > IPv4, and would therefore be a big help. HE much like the reduction in use of 6to4, and to some extent AAAA whitelisting (which I don't currently use) provide cover under which people like me can convince our manangement that we can safely deploy AAAA records for public facing services without impacting end-users. Latency is a discussion point in virtually every public facing service change here. > > -- james woodyatt member of technical staff, core os > networking > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Mon Sep 26 13:40:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E911F0CF8 for ; Mon, 26 Sep 2011 13:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AfvItJBBPEj for ; Mon, 26 Sep 2011 13:40:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A098E1F0CF9 for ; Mon, 26 Sep 2011 13:40:35 -0700 (PDT) Received: by ywa6 with SMTP id 6so5804525ywa.31 for ; Mon, 26 Sep 2011 13:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j97H8pShfwKTVqv+GFPqA6T0o44NDvtil6JuJK1zkhU=; b=G7kNpas/wBCwJ0lyO63fRe3SWg3PUEbghqbLIiKXsxY7UQnQMdNTOuvYqKSspk+t5y Ttrb8LBJ7ksFHOWTAbABmQZX9gwytffdah+ID9tSg1jcWHVm1L1maWbTeAs+NpUmminI msyu8xAGEobnrcC1TqMtXhPQ7ujhU1bdSEnM0= Received: by 10.236.77.233 with SMTP id d69mr42447162yhe.84.1317069799170; Mon, 26 Sep 2011 13:43:19 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id x12sm30594012yhi.10.2011.09.26.13.43.17 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 13:43:18 -0700 (PDT) Message-ID: <4E80E3DE.1010306@gmail.com> Date: Tue, 27 Sep 2011 09:43:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:40:36 -0000 Unless I've missed it, the draft doesn't require that an HE implementation MUST have a user-settable option to disable it (and revert to the default prefer-IPv6 behaviour). I think this needs to be added. Regards Brian Carpenter From jeroen@unfix.org Mon Sep 26 13:46:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA57B11E8106 for ; Mon, 26 Sep 2011 13:46:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRw0H5IViJID for ; Mon, 26 Sep 2011 13:46:08 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9411E80FE for ; Mon, 26 Sep 2011 13:46:08 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2a02:2528:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id C5899801A365; Mon, 26 Sep 2011 22:48:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317070129; bh=lDd0emcI42p/23RpBMzdHhBF+LzCtGuqqEek/YpbukY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xlV0+P2k5hqol4Nbl+/4IZ28dNSoklPwIfaS2akZzuhlP+R/K4x+ck+lUeHjCubDz eGLFCYCAdYxosX0blOO3bTVLAI9ytOhQiufSoxBDsACP3RSjEGw4yxeIaow+pNzbrK VClQje5wjblxam1JWWAm6YQluRo7/mBhMafaw3wjXGrnx0Qh657PaNxlt2UOwlCRu4 GfFBjmVbsg/Qc9rLpSzTICpM/TKQPc7qAh50MXH+WmQAQznu10M+kDl/aGTYx02ZG1 4sLLk+AFF+7U70QaNggxZAgv7GNNiAyg+UILrJVvHR34ARRx5QsX3TcY2kJD9LIWkN +k+UVrfj8ythA== Message-ID: <4E80E527.1020005@unfix.org> Date: Mon, 26 Sep 2011 22:48:39 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> In-Reply-To: <4E80E3DE.1010306@gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:46:10 -0000 On 2011-09-26 22:43 , Brian E Carpenter wrote: > Unless I've missed it, the draft doesn't require that > an HE implementation MUST have a user-settable option to > disable it (and revert to the default prefer-IPv6 behaviour). > > I think this needs to be added. Strong voice for this from my side. And it does not have to be a UI element (though that makes some people happy), just a sysctl knob or a registry switch is just fine, as it is a setting that is likely only needed by ops folks anyway. Greets, Jeroen -- jeroen@yomi:~$ cat .ssh/config AddressFamily inet6 and on the verge of fakely inserting a few ms of extra latency into IPv4 to compensate for the minor but not really noticeable detour the tunneled IPv6 packets take... From achatz@forthnet.gr Mon Sep 26 14:46:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62AA21F8E7B for ; Mon, 26 Sep 2011 14:46:50 -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=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUtWnot9no0p for ; Mon, 26 Sep 2011 14:46:50 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 12EEF21F8E7A for ; Mon, 26 Sep 2011 14:46:49 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8QLnVg2023301; Tue, 27 Sep 2011 00:49:31 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8QLnVm6001627; Tue, 27 Sep 2011 00:49:31 +0300 Received: from [192.168.1.3] (46.12.57.94.dsl.dyn.forthnet.gr [46.12.57.94]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8QLnT2A016661; Tue, 27 Sep 2011 00:49:30 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnet.gr; auth=pass (PLAIN) Message-ID: <4E80F366.6080507@forthnet.gr> Date: Tue, 27 Sep 2011 00:49:26 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 MIME-Version: 1.0 To: Jeroen Massar References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> In-Reply-To: <4E80E527.1020005@unfix.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 21:46:50 -0000 There is a MAY under 5.3 > To assist in that regard, the implementations MAY also provide > a mechanism to disable their Happy Eyeballs behavior via a user setting. although changes through sysctl should probably go under 5.9. -- Tassos Jeroen Massar wrote on 26/9/2011 23:48: > On 2011-09-26 22:43 , Brian E Carpenter wrote: >> Unless I've missed it, the draft doesn't require that >> an HE implementation MUST have a user-settable option to >> disable it (and revert to the default prefer-IPv6 behaviour). >> >> I think this needs to be added. > Strong voice for this from my side. And it does not have to be a UI > element (though that makes some people happy), just a sysctl knob or a > registry switch is just fine, as it is a setting that is likely only > needed by ops folks anyway. > > Greets, > Jeroen > > -- > jeroen@yomi:~$ cat .ssh/config > AddressFamily inet6 > > and on the verge of fakely inserting a few ms of extra latency into IPv4 > to compensate for the minor but not really noticeable detour the > tunneled IPv6 packets take... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Mon Sep 26 14:56:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321A211E80EC for ; Mon, 26 Sep 2011 14:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.278 X-Spam-Level: X-Spam-Status: No, score=-103.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVzuIz+6TWOj for ; Mon, 26 Sep 2011 14:56:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F34411E80C9 for ; Mon, 26 Sep 2011 14:56:55 -0700 (PDT) Received: by ywa6 with SMTP id 6so5878419ywa.31 for ; Mon, 26 Sep 2011 14:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=azwM6Z9hjLYM1lCkGO/Q3e+3w+maHJUmuhat7vdHBjU=; b=xKuu1+SNViYAdD70Q2et7b65kdY5eOYEBz/Mxe/ouQ3ct6ZTfY1/8SNtqnsX/qoV2r ZgvMBJHM5rHon0jurBsL8CyUqNC8an8AlYUVuLnrwgV4Kd0Ugk5U6A+1edfCGa01n4bA tNBqME574od65NQkDBfe5U1PzYC/W9sN9YW0A= Received: by 10.236.201.234 with SMTP id b70mr26531055yho.122.1317074378818; Mon, 26 Sep 2011 14:59:38 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id p68sm30829268yhj.16.2011.09.26.14.59.36 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 14:59:37 -0700 (PDT) Message-ID: <4E80F5C5.30202@gmail.com> Date: Tue, 27 Sep 2011 10:59:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tassos Chatzithomaoglou References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E80F366.6080507@forthnet.gr> In-Reply-To: <4E80F366.6080507@forthnet.gr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 21:56:56 -0000 MAY isn't strong enough IMHO. Regards Brian Carpenter On 2011-09-27 10:49, Tassos Chatzithomaoglou wrote: > There is a MAY under 5.3 > >> To assist in that regard, the implementations MAY also provide >> a mechanism to disable their Happy Eyeballs behavior via a user setting. > > although changes through sysctl should probably go under 5.9. > > -- > Tassos > > > Jeroen Massar wrote on 26/9/2011 23:48: >> On 2011-09-26 22:43 , Brian E Carpenter wrote: >>> Unless I've missed it, the draft doesn't require that >>> an HE implementation MUST have a user-settable option to >>> disable it (and revert to the default prefer-IPv6 behaviour). >>> >>> I think this needs to be added. >> Strong voice for this from my side. And it does not have to be a UI >> element (though that makes some people happy), just a sysctl knob or a >> registry switch is just fine, as it is a setting that is likely only >> needed by ops folks anyway. >> >> Greets, >> Jeroen >> >> -- >> jeroen@yomi:~$ cat .ssh/config >> AddressFamily inet6 >> >> and on the verge of fakely inserting a few ms of extra latency into IPv4 >> to compensate for the minor but not really noticeable detour the >> tunneled IPv6 packets take... >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From jhw@apple.com Mon Sep 26 15:02:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE15B11E80C9 for ; Mon, 26 Sep 2011 15:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.62 X-Spam-Level: X-Spam-Status: No, score=-106.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whjl9+UICtKA for ; Mon, 26 Sep 2011 15:02:24 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 412F711E8087 for ; Mon, 26 Sep 2011 15:02:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LS500672H8O2R62@mail-out.apple.com> for v6ops@ietf.org; Mon, 26 Sep 2011 15:05:07 -0700 (PDT) X-AuditID: 1180711d-b7cc6ae000006836-15-4e80f657fcee Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id F1.AC.26678.856F08E4; Mon, 26 Sep 2011 15:02:00 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LS50096GHCITK40@koseret.apple.com> for v6ops@ietf.org; Mon, 26 Sep 2011 15:05:06 -0700 (PDT) From: james woodyatt In-reply-to: <4E80E1ED.5060209@gmail.com> Date: Mon, 26 Sep 2011 15:05:06 -0700 Message-id: <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1248) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUiON1OXTfiW4OfwZYPrBanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRs+OZsaCTr6KvVe+MDcw7uLuYuTgkBAwkejsqOxi5AQyxSQu 3FvP1sXIxSEk0MkkcePQLFaQBK+AoMSPyfdYQOqZBeQlDp6XBQkzC2hJfH/UygJRP4VJ4vaG iewgCWEBS4m3i5vBbDYBFYlvl+8ygdicApoSix88ZAKZwyKgKvFjTxHEeBuJKdN/MkLM2c0s MfXILbBeEaDeKWfus0EcJyuxctpk1gmM/LOQnDQL4aRZSE5awMi8ilGwKDUnsdLQWC+xoCAn VS85P3cTIyi8GgpldzDu/8l/iFGAg1GJh1fpcYOfEGtiWXFl7iFGCQ5mJRFe09dAId6UxMqq 1KL8+KLSnNTiQ4zSHCxK4rzd74BSAumJJanZqakFqUUwWSYOTqkGRt1rE94fXrjg7ReNx0yF J7+0rHpauLPpzhdp0Sr1lYdesm1VnfU36Mfhu9er5q+cmP770q2ZyW5aJpHRE3YEqfq7rc+v Ypym87D1V/4l/tz8ykuLzgXuvG9j2hB8hEdU++XahVuK1i4zddSJbPu6pnrnob1yno98cp8W vC+ZeUBgfrX6ua7sxUZKLMUZiYZazEXFiQB7sBeTKwIAAA== Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 22:02:24 -0000 On Sep 26, 2011, at 13:34 , Brian E Carpenter wrote: > > Thus, IMHO there SHOULD be a tuning parameter of some kind, whose default setting would be something like "prefer IPv6 unless it is 25% slower than IPv4". I feel pretty comfortable making a prediction about how that would work out. Pretty soon after such behavior were introduced in a forthcoming operating system release, it would be noticed by various commentators and contributors to user discussion forums on the web and elsewhere, who would complain loudly that this default parameter was poorly chosen, often in a pithy rant explaining in arrogant detail why it seems to its author to be such a bad idea. In response to anyone posting a question to the effect of "why is my Internet download going so slow?" the reflexive answer given in response would be a citation for one of these rants along with instructions on how to set that tuning parameter to prefer IPv4 over IPv6. A parade of follow-ups would appear overnight from people claiming that they did this and magically everything got better. (Note: it's irrelevant to the discussion whether these claims could withstand any scientific examination.) In short order, the complaints about the default setting and the advice to change it to something reasonable would reach a fever pitch, and whoever had the bright idea of following the recommendation from the IETF that such a preference for IPv6 be applied over IPv4 would be sent to a reeducation camp on the Moon. A software update would be rushed out soon thereafter to ignore the preference setting and it would disappear in a future release. The engineer sent to the Moon would likely never be heard from again. -- james woodyatt member of technical staff, core os networking From joelja@bogus.com Mon Sep 26 15:08:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD4A21F8D6F for ; Mon, 26 Sep 2011 15:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.09 X-Spam-Level: X-Spam-Status: No, score=-102.09 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k06fuOKfqju for ; Mon, 26 Sep 2011 15:08:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3221F8D6D for ; Mon, 26 Sep 2011 15:08:47 -0700 (PDT) Received: from Zorch.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p8QMBPQN012751 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 26 Sep 2011 22:11:26 GMT (envelope-from joelja@bogus.com) Message-ID: <4E80F887.2040701@bogus.com> Date: Mon, 26 Sep 2011 15:11:19 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tassos Chatzithomaoglou References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E80F366.6080507@forthnet.gr> In-Reply-To: <4E80F366.6080507@forthnet.gr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 26 Sep 2011 22:11:26 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 22:08:48 -0000 On 9/26/11 14:49 , Tassos Chatzithomaoglou wrote: > There is a MAY under 5.3 > >> To assist in that regard, the implementations MAY also provide >> a mechanism to disable their Happy Eyeballs behavior via a user setting. > > although changes through sysctl should probably go under 5.9. bearing in mind that some implementations are buried in applications and not in kernels. > -- > Tassos > > > Jeroen Massar wrote on 26/9/2011 23:48: >> On 2011-09-26 22:43 , Brian E Carpenter wrote: >>> Unless I've missed it, the draft doesn't require that >>> an HE implementation MUST have a user-settable option to >>> disable it (and revert to the default prefer-IPv6 behaviour). >>> >>> I think this needs to be added. >> Strong voice for this from my side. And it does not have to be a UI >> element (though that makes some people happy), just a sysctl knob or a >> registry switch is just fine, as it is a setting that is likely only >> needed by ops folks anyway. >> >> Greets, >> Jeroen >> >> -- >> jeroen@yomi:~$ cat .ssh/config >> AddressFamily inet6 >> >> and on the verge of fakely inserting a few ms of extra latency into IPv4 >> to compensate for the minor but not really noticeable detour the >> tunneled IPv6 packets take... >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From john.mann@monash.edu Mon Sep 26 15:32:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A5D1F0D1B for ; Mon, 26 Sep 2011 15:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.576 X-Spam-Level: X-Spam-Status: No, score=-5.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHu84jfkobOC for ; Mon, 26 Sep 2011 15:32:58 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF9F1F0D19 for ; Mon, 26 Sep 2011 15:32:58 -0700 (PDT) Received: from mail-qy0-f180.google.com ([209.85.216.180]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKToD+N5chQqfpTuSjCPt+Hh0UJnB4Li3A@postini.com; Mon, 26 Sep 2011 15:35:42 PDT Received: by mail-qy0-f180.google.com with SMTP id 1so6611548qyc.4 for ; Mon, 26 Sep 2011 15:35:35 -0700 (PDT) Received: by 10.224.35.68 with SMTP id o4mr5654210qad.287.1317076535208; Mon, 26 Sep 2011 15:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.1.104 with HTTP; Mon, 26 Sep 2011 15:35:15 -0700 (PDT) In-Reply-To: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69862@PRVPEXVS04.corp.twcable.com> From: John Mann Date: Tue, 27 Sep 2011 08:35:15 +1000 Message-ID: To: Marc Blanchet Content-Type: multipart/alternative; boundary=20cf306f77f205eb5604addfc796 Cc: Philip Homburg , "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 22:32:59 -0000 --20cf306f77f205eb5604addfc796 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 27 September 2011 05:36, Marc Blanchet wrote: > ... > I'm not saying that IPv6 will always be broken. I'm just saying that IPv4 > will be always better than IPv6 for quite a long time, since it is still > IPv4 that brings money. > > ... > Marc. IPv4 will not always be better. For many sites IPv6 is already better. For example http://ipv6monitor.comcast.net:8080/monitor/index.html For sites that do provide identical content over IPv4 and IPv6 Figure-4.1 shows on 11-09-24, 45% of sites loaded faster over IPv6 than over IPv4. Figure-4.2 shows "average of IPv4 download time minus IPv6 download time" is +ve (i.e. IPv6 is faster) since June for "Top 1K" "Top 10K" and "Top 100K" sites Sure, IPv4 is faster for 55% of sites, and sites not in "Top 100K" list on average load 20msec slower, but this is a long way from IPv4 will _always_ be better. [ http://mnlab-ipv6.seas.upenn.edu/monitor isn't accessible to me at the moment. ] Also, http://labs.ripe.net/Members/emileaben/measuring-world-ipv6-day-comparing-ipv4-and-ipv6-performance "Figure 1 shows a histogram of all relative IPv4/IPv6 performance data points we collected during World IPv6 Day. ... On a dual-stack client that unconditionally prefers IPv6 over IPv4, IPv4is more often the faster protocol, but this is far from a universal truth. There is also a significant chance that IPv6 is faster, since the "IPv6-is-faster" part of the histogram also has a significant volume. ... Note that we measured ICMP/ICMPv6, not HTTP performance." Thanks, John --20cf306f77f205eb5604addfc796 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 27 September 2011 05:36, Marc Bla= nchet <ma= rc.blanchet@viagenie.ca> wrote:
...
I'm not saying that IPv6 will always be broken. I'm just sayi= ng that IPv4 will be always better than IPv6 for quite a long time, since i= t is still IPv4 that brings money.

...
Marc.

IPv4 will not always be better= . =A0For many sites IPv6 is already better.

=A0 For sites that do provide identical content over IPv4 and IPv6
=A0 Figure-4.1 shows on 11-09-24,=A045% of sites loaded faster over = IPv6 than over IPv4.
=A0 Figure-4.2 shows "average of IPv4 d= ownload time minus IPv6 download time" is +ve (i.e. IPv6 is faster)
=A0 since June for "Top 1K" "Top 10K" and "To= p 100K" sites

Sure, IPv4 is faster for 55% of= sites, and sites not in "Top 100K" list on average load 20msec s= lower,
but this is a long way from IPv4 will _always_ be better.
[=A0http:= //mnlab-ipv6.seas.upenn.edu/monitor isn't accessible to me at the m= oment. ]


Also,
=A0"Figure 1 shows a histog= ram of all relative IPv4/IPv6 performance data points we collected during World IPv6 Day.
=A0 ...
=A0=A0On a dual-stack client that unconditionally pr= efers IPv6 over IPv4, = IPv4 is more often the = faster protocol, but this is far from a universal truth.
=A0 There is also a significant chance that IPv6 is faster, since the "IPv6-is-faster" part of the histogram also has a significant volume.
=A0 ...
=A0 Note that we measured ICMP/ICMPv6, not HTTP perf= ormance."


Thanks,
= =A0 =A0 John
--20cf306f77f205eb5604addfc796-- From jeroen@unfix.org Tue Sep 27 02:11:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0030C21F85B9 for ; Tue, 27 Sep 2011 02:11:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYSQmhLRJj07 for ; Tue, 27 Sep 2011 02:11:56 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 3D49B21F85B5 for ; Tue, 27 Sep 2011 02:11:55 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2a02:2528:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 18B0A8018662; Tue, 27 Sep 2011 11:14:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317114877; bh=MtBrmQ37vs0QnmUHS/UgaLQ22T68gfgV7YeWG34BynY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gg4oF3hPzNwwjJegM0IW3m4C7FwkK1g8HR8COy97Y4PcWv9dDjnq+LIus9lmmyKwY KEENquepKjUqNY9LEsc339xJr+yTdWdSuFlPdRkofHj3tFCTEPnzfhmYMZ3eidRcXA +33UjW+i7GMJjawlCNPiAYyCRdlJMPfIbEUKBT89iGznkI7+SrNQazjLt92+a4aet3 otaR6pxQi8zl9zhSQ7fraxYCsSlTGfwusu6CvmSuOStlIGqSHaX8WFjpbf2q++z7JV Vcto5GkFJpUovLkVYwQNbuyYBqasNdVgdY34xHagydU+psiG4pd5C+AGCMryOeDe0m BStg+JNz7funQ== Message-ID: <4E8193F3.50801@unfix.org> Date: Tue, 27 Sep 2011 11:14:27 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: james woodyatt References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> In-Reply-To: <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 09:11:57 -0000 On 2011-09-27 00:05 , james woodyatt wrote: [..] > In response to anyone posting a question to the effect of "why is my > Internet download going so slow?" the reflexive answer given in > response would be a citation for one of these rants along with > instructions on how to set that tuning parameter to prefer IPv4 over > IPv6. That was not what was being asked for. What was being asked for is a switch to turn off Happy Eyeballs. Then the implementation follows the RFC3484 rules which causes a predictable IPv6 first then IPv4 behavior. That 'predictable' part is btw the biggest issue I have with the Happy Eyeballs implementation Yes, it is AWESOME for normal endusers who really can't care less as long as it works (thus many thanks for solving that problem!), but for people like most of the folks here on the IETF list and other such ops/protocol people it is really annoying to not be able to know what protocol is going to be selected. Greets, Jeroen From pch-b29AA871B@u-1.phicoh.com Tue Sep 27 02:41:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8E921F8DF9 for ; Tue, 27 Sep 2011 02:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNyP5N4HD5EE for ; Tue, 27 Sep 2011 02:41:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A8A1F21F8DF6 for ; Tue, 27 Sep 2011 02:41:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8UCm-0001jCC; Tue, 27 Sep 2011 11:44:00 +0200 Message-Id: To: Jeroen Massar From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> In-reply-to: Your message of "Tue, 27 Sep 2011 11:14:27 +0200 ." <4E8193F3.50801@unfix.org> Date: Tue, 27 Sep 2011 11:43:59 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 09:41:18 -0000 In your letter dated Tue, 27 Sep 2011 11:14:27 +0200 you wrote: >Then the implementation follows the RFC3484 rules which causes a >predictable IPv6 first then IPv4 behavior. > >That 'predictable' part is btw the biggest issue I have with the Happy >Eyeballs implementation > >Yes, it is AWESOME for normal endusers who really can't care less as >long as it works (thus many thanks for solving that problem!), but for >people like most of the folks here on the IETF list and other such >ops/protocol people it is really annoying to not be able to know what >protocol is going to be selected. With round-robin DNS you never know which IPv4 address is going to be used. That's just part of life. If you look closer at root DNS servers, you never know which one is going to be used, even if you know the IP address. Yes, network debugging tools have to deal with that. Can't we just leave this to application writers? Section 5.3 seems more than enough. From jeroen@unfix.org Tue Sep 27 02:49:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8E121F863E for ; Tue, 27 Sep 2011 02:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRUt4c9kCyez for ; Tue, 27 Sep 2011 02:49:56 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id E11CF21F8591 for ; Tue, 27 Sep 2011 02:49:55 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 846388018662; Tue, 27 Sep 2011 11:52:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317117158; bh=IstTMB4VQSGXzpJUKZoFurJBnlab+bk//aVnDYeD7GE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0C2dZhBs/9lcGwhJRBeJxuFgX0zAwy94YVCE5ZyVeYpHp/kvxZymXBsIMSM39Oybd zs5hZmpZ0Z1tJ/iGNurhmQ+5Yph7KEmBBNT0OqPixx7xBdC265H3ot21lAOpSqQCbd Neh/eB2hsJWU+fUAh4wZcjjUIh7oCyJZB1jgxqrRKlw9byQEW14n+7soeYHgbjLcw6 gVFzZogP5VAudw+KCieTKjasWdgkv9lsHr6o2zOVB0UwIlrGnONARSOGFeyu97bfFA ReC4QQOtWzuQZwVQK57aJCBLC0FHwLqj4/RpQGbghV5z7kWDKpxK5S+5jgsbCqTZQ3 CeHsSGB1dvfVA== Message-ID: <4E819CDD.8090602@unfix.org> Date: Tue, 27 Sep 2011 11:52:29 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Philip Homburg References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 09:49:56 -0000 On 2011-09-27 11:43 , Philip Homburg wrote: > In your letter dated Tue, 27 Sep 2011 11:14:27 +0200 you wrote: >> Then the implementation follows the RFC3484 rules which causes a >> predictable IPv6 first then IPv4 behavior. >> >> That 'predictable' part is btw the biggest issue I have with the Happy >> Eyeballs implementation >> >> Yes, it is AWESOME for normal endusers who really can't care less as >> long as it works (thus many thanks for solving that problem!), but for >> people like most of the folks here on the IETF list and other such >> ops/protocol people it is really annoying to not be able to know what >> protocol is going to be selected. > > With round-robin DNS you never know which IPv4 address is going to be used. But you do know if IPv4 or IPv6 is being used. Note also that due to the rules the "longest prefix matching" RFC3484 rule, actually DNS round-robin does not exist any more as it then picks the shorted prefix match, not the ordering in DNS. > If you look closer at root DNS servers, you never know which one is going > to be used, even if you know the IP address. It also does not matter which is used. But you do know that IPv6 goes first and then IPv4. > Yes, network debugging tools have to deal with that. Having a consistent selection of a remote address is important. Ignoring the fact that some hosts have multiple IPv4/IPv6 addresses and just considering hosts that have 1x IPv4 and 1x IPv6 always using the same protocol is a big plus already. > Can't we just leave this to application writers? Section 5.3 seems more than > enough. Application writers are exactly the ones that should not have to care about Address Families or ordering or anything else. The OS libraries should be taking care of this, or do you want a different implementation per not only OS but per application (which is what is mostly happening for web browsers anyway). Greets, Jeroen From pch-b29AA871B@u-1.phicoh.com Tue Sep 27 02:59:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3B621F8C97 for ; Tue, 27 Sep 2011 02:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv7sXs38rsmR for ; Tue, 27 Sep 2011 02:59:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83E21F8D51 for ; Tue, 27 Sep 2011 02:59:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8UUn-0001igC; Tue, 27 Sep 2011 12:02:37 +0200 Message-Id: To: Jeroen Massar From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> In-reply-to: Your message of "Tue, 27 Sep 2011 11:52:29 +0200 ." <4E819CDD.8090602@unfix.org> Date: Tue, 27 Sep 2011 12:02:37 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 09:59:58 -0000 In your letter dated Tue, 27 Sep 2011 11:52:29 +0200 you wrote: >> With round-robin DNS you never know which IPv4 address is going to be used. > >But you do know if IPv4 or IPv6 is being used. Who cares? You care because you provide an IPv6 service. I don't really care. Most of the problems I have to debug are not related to IPv4 or IPv6. >Note also that due to the rules the "longest prefix matching" RFC3484 >rule, actually DNS round-robin does not exist any more as it then picks >the shorted prefix match, not the ordering in DNS. That's not my experience. There are many cases where you get multiple addresses in a single /24. Logest prefix matching doesn't do anything for that. >> If you look closer at root DNS servers, you never know which one is going >> to be used, even if you know the IP address. > >It also does not matter which is used. But you do know that IPv6 goes >first and then IPv4. Because you only care about IPv6 versus IPv4. There is a lot more variation than just that bit. >> Yes, network debugging tools have to deal with that. > >Having a consistent selection of a remote address is important. Most of the time, it isn't to me. >Ignoring the fact that some hosts have multiple IPv4/IPv6 addresses and >just considering hosts that have 1x IPv4 and 1x IPv6 always using the >same protocol is a big plus already. Again, only if you are debugging network level problems. >> Can't we just leave this to application writers? Section 5.3 seems more than >> enough. > >Application writers are exactly the ones that should not have to care >about Address Families or ordering or anything else. They have to. Because the application has to provide a debugging interface. There is (as far as I know) no fine grained control over DNS and related services. And I'm not going to screw up and entire host by globally disabling HE or something like that. >The OS libraries should be taking care of this, or do you want a >different implementation per not only OS but per application (which is >what is mostly happening for web browsers anyway). Well, talk to your OS vendor then. No point in putting that in an RFC. You never know where HE functionality is actually implemented. Yes, HE should be part of OS libraries, but that may take a while. So for the near future I expect it to be in application. From mohacsi@niif.hu Tue Sep 27 03:04:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5178D21F8D8D for ; Tue, 27 Sep 2011 03:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WsfGCsnCni6 for ; Tue, 27 Sep 2011 03:04:52 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 72E2F21F8D84 for ; Tue, 27 Sep 2011 03:04:52 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 89D59877A2; Tue, 27 Sep 2011 12:07:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id NWtBl0yaUzDn; Tue, 27 Sep 2011 12:07:30 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 6C8FE877AF; Tue, 27 Sep 2011 12:07:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6A6E2877A4; Tue, 27 Sep 2011 12:07:30 +0200 (CEST) Date: Tue, 27 Sep 2011 12:07:29 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Jeroen Massar In-Reply-To: <4E819CDD.8090602@unfix.org> Message-ID: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Philip Homburg , IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:04:53 -0000 On Tue, 27 Sep 2011, Jeroen Massar wrote: > On 2011-09-27 11:43 , Philip Homburg wrote: >> In your letter dated Tue, 27 Sep 2011 11:14:27 +0200 you wrote: >>> Then the implementation follows the RFC3484 rules which causes a >>> predictable IPv6 first then IPv4 behavior. >>> >>> That 'predictable' part is btw the biggest issue I have with the Happy >>> Eyeballs implementation >>> >>> Yes, it is AWESOME for normal endusers who really can't care less as >>> long as it works (thus many thanks for solving that problem!), but for >>> people like most of the folks here on the IETF list and other such >>> ops/protocol people it is really annoying to not be able to know what >>> protocol is going to be selected. >> >> With round-robin DNS you never know which IPv4 address is going to be used. > > But you do know if IPv4 or IPv6 is being used. > > Note also that due to the rules the "longest prefix matching" RFC3484 > rule, actually DNS round-robin does not exist any more as it then picks > the shorted prefix match, not the ordering in DNS. Can you explain it more wtih example why DNS round-robin is not working? > >> If you look closer at root DNS servers, you never know which one is going >> to be used, even if you know the IP address. > > It also does not matter which is used. But you do know that IPv6 goes > first and then IPv4. > >> Yes, network debugging tools have to deal with that. > > Having a consistent selection of a remote address is important. > > Ignoring the fact that some hosts have multiple IPv4/IPv6 addresses and > just considering hosts that have 1x IPv4 and 1x IPv6 always using the > same protocol is a big plus already. > >> Can't we just leave this to application writers? Section 5.3 seems more than >> enough. > > Application writers are exactly the ones that should not have to care > about Address Families or ordering or anything else. > > The OS libraries should be taking care of this, or do you want a > different implementation per not only OS but per application (which is > what is mostly happening for web browsers anyway). Actually the standardised API (RFC 3493) is not dealing with multiple connections. It is dealing with getaddrinfo(). The actual applications are just trying to connect sequentially the addresses what getaddrinfo() returned. > > Greets, > Jeroen > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jeroen@unfix.org Tue Sep 27 03:58:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6285521F8677 for ; Tue, 27 Sep 2011 03:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.6 X-Spam-Level: X-Spam-Status: No, score=-103.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WrLoxvK20zt for ; Tue, 27 Sep 2011 03:58:29 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3B721F8669 for ; Tue, 27 Sep 2011 03:58:29 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2a02:2528:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 2AB09801A365; Tue, 27 Sep 2011 13:01:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317121272; bh=4xwASx/n1VeNyZyoCvSwuECLnjeWOyg1D59nj5B+5Y4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YafuIBobPVuL53kXLQntjH3Lgcxc6GL3ZlOa0JdNxKsPkwLIukuR8SVI6Qp+qQsmf 1r80AJi1EiAD+duAjVLniNgOqv3TcZIe6wKD1CCDOsoSjdDYxkcJTKGunlVKKylcHf PC+ZKt2Nf9MmCFOad8LZUCs5vt9JeDs/GSzDMXlnnIAEzoohAsEQtenVa958WubY4w M90weOwjUAeCPNP0KK4VK/ZUooNsoyQc1CrM51pysQ9v4r4kjiKz1RMi3EAqGWY5l6 Viu6gPb14laC5ojaCm9AcBYgMzlgmXbrakZMcwBrkpbwvE/8JHvBhvYyLwks+ElYZT uuj9tUGbpR39w== Message-ID: <4E81ACED.8000207@unfix.org> Date: Tue, 27 Sep 2011 13:01:01 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Philip Homburg References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:58:30 -0000 On 2011-09-27 12:02 , Philip Homburg wrote: > In your letter dated Tue, 27 Sep 2011 11:52:29 +0200 you wrote: >>> With round-robin DNS you never know which IPv4 address is going to be used. >> >> But you do know if IPv4 or IPv6 is being used. > > Who cares? You care because you provide an IPv6 service. Odd, I am participating in the IETF as me, not as any role or hat I accidentally might have. I care because of the consistency of address family selection which makes debugging harder for hosts that only have a single IPv4 and IPv6 address (like general hosts have). The ability to disable HE and thus make the results consistent is a major pro for debugging and other general usage. I wonder how you will like the confusion that about every other request, because of minuscule changes, either IPv4 or IPv6 is selected. Yes, quite a few tools have -4/-6 and -v alike options, but a lot of GUI based tools unfortunately do not and will not retrofit this. > I don't really care. If you don't care then why are you involving yourself in this thread? :) > Most of the problems I have to debug are not related to IPv4 or IPv6. Ever considered that not everybody uses the Internet in the same way or for the same purposes? >> Note also that due to the rules the "longest prefix matching" RFC3484 >> rule, actually DNS round-robin does not exist any more as it then picks >> the shorted prefix match, not the ordering in DNS. > > That's not my experience. There are many cases where you get multiple addresses > in a single /24. Logest prefix matching doesn't do anything for that. While that is quite true, if you do not stuff all your eggs in the same basket (read: same prefix) then you will nicely always get a consistent address order back from Note also that various authoritative DNS servers like nsd don't do address re-ordering and thus unless a intermediary cache is doing the re-ordering for you, they will always be the same. >>> If you look closer at root DNS servers, you never know which one is going >>> to be used, even if you know the IP address. >> >> It also does not matter which is used. But you do know that IPv6 goes >> first and then IPv4. > > Because you only care about IPv6 versus IPv4. There is a lot more variation > than just that bit. As this is the IPv6 list, what is the problem with caring about IPv6? Also, if there is more variation, what would these be that we need to consider? >>> Yes, network debugging tools have to deal with that. >> >> Having a consistent selection of a remote address is important. > > Most of the time, it isn't to me. The whole idea behind this knob is that the default behavior is HE, as this serves all the end-users who do not care about what is used the best. (and using latency and other stats like Mac OS X does is a really cool trick for this) The knob thus allows people who do not want this behavior to turn it off. >> Ignoring the fact that some hosts have multiple IPv4/IPv6 addresses and >> just considering hosts that have 1x IPv4 and 1x IPv6 always using the >> same protocol is a big plus already. > > Again, only if you are debugging network level problems. Which is why the knob is default set to 'use HE'. What is the problem with this? >>> Can't we just leave this to application writers? Section 5.3 seems more than >>> enough. >> >> Application writers are exactly the ones that should not have to care >> about Address Families or ordering or anything else. > > They have to. Because the application has to provide a debugging interface. What kind of debugging interface would that be? Chrome has pretty neat internals under chrome:net-internals but even that does not show any of the decisions made on the DNS or address ordering level. > There is (as far as I know) no fine grained control over DNS and related > services. And I'm not going to screw up and entire host by globally disabling > HE or something like that. You don't need to, just don't touch the knob. For the people who want to, as you say 'screw up HE', let them. Be Pro Choice! Freedom to the People (and other such slogans ;) >> The OS libraries should be taking care of this, or do you want a >> different implementation per not only OS but per application (which is >> what is mostly happening for web browsers anyway). > > Well, talk to your OS vendor then. No point in putting that in an RFC. You > never know where HE functionality is actually implemented. The "SHOULD" is already in the document, there are several people who would like that to be a MUST. It does not break or change anything, it only expects the ability to disable it. > Yes, HE should be part of OS libraries, but that may take a while. So for the > near future I expect it to be in application. Mac OS X has had (a variation of) HE support since Lion. A lot of applications (read browsers that are scared to be 'slow' versus the competition) bypass OS libraries completely though. Those applications tend to have a proper disable switch too. Greets, Jeroen From jeroen@unfix.org Tue Sep 27 04:11:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DFF21F8CE8 for ; Tue, 27 Sep 2011 04:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72eB6vLiqx8r for ; Tue, 27 Sep 2011 04:11:18 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3B221F8CE7 for ; Tue, 27 Sep 2011 04:11:18 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 75ACD801A365; Tue, 27 Sep 2011 13:13:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317122041; bh=8g6unQsjSvXEbY+0RZKr+fAptRkBV8W5/Td6ISFfoAA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QsdO5pj02q1UgwvT/0aFKoP/wZAg9fSobc1iqiXiZQ2pVwDISEHaDvGUZWD+yiGw9 YmWioRsc2MuLjJaFHAS2HM1mSrMP3p79/KHUrrO06ENfDmhUU6Mqy6zunmgBTF6h1R bRxuaDtAypQxP/xupbALS8OWT7xRLb63qolyE2ozR9JZM/3fiF2TGCXXQjeqIEeX9/ t7WsIEqPbzp/D/I0gNoNE7OBOt5XkhJ+e9f0EnJKvYXolv0oRH4SVoRTMA/BjxL8lM rVsjEJNj3sRGb67OGl022UutNOM2WsBNTjzuy2mdjKhvC9pasRtRJpk4fvRjgOrQBL scH870Kjyq5kg== Message-ID: <4E81AFF0.9030608@unfix.org> Date: Tue, 27 Sep 2011 13:13:52 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Mohacsi Janos References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: [v6ops] Longest prefix matching tends to end up at the same host (Was: draft-ietf-v6ops-happy-eyeballs WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 11:11:19 -0000 On 2011-09-27 12:07 , Mohacsi Janos wrote: [..] >> Note also that due to the rules the "longest prefix matching" RFC3484 >> rule, actually DNS round-robin does not exist any more as it then picks >> the shorted prefix match, not the ordering in DNS. > > Can you explain it more wtih example why DNS round-robin is not working? There are two parts in this: 1) some DNS authoritive servers (eg nsd) don't do DNS round-robin 2) longest prefix matching The first can be made even odder to determine if a DNS resolver in the chain is a BIND, as that one will re-order for you, but if you have unbound as caching/recursor, there won't be re-ordering at all. The latter is simple, if I take: $ dig +short www.sixxs.net aaaa nginx.sixxs.net. 2001:838:2:1::30:67 2001:838:2:1:2a0:24ff:feab:3b53 2001:960:800::2 2001:1af8:4050::2 2620:0:6b0:a:250:56ff:fe99:78f7 (interestingly the results are hex-ordered) Thus where the addresses are not at all in the same prefix, depending on your source address you will pick, per the rule, the closest one. We have noticed that for the www.sixxs.net that the majority of IPv6 clients are hitting the first address (2001:838:2:1::30:67), these tend to be clients coming from source addresses from the APNIC region, as there is a lot of 2001:2xx'ish address space there, thus the 'closest' address space is the first one in that list. The 2001:1af8:xxx host in the above list is getting the rest of the 'upper' traffic, while the 2620:xx host is getting everything close to that. The two hosts in the 'middle' are not getting a lot of traffic in comparison though, as the others are 'closer'. To put it in a simpler example, if we have the following addresses: 2001:db8:1000::1 2001:db8:8000::2 2001:db8:a000::3 2001:db8:ffff::4 The first and last host will catch all the traffic, you have to be lucky if the '2' and '3' get anything at all.... The 'good' thing about this though is that even though you have multiple IP addresses at possibly completely separate hosts, they always end up consistently at the same location. In one of the setups I use this to my advantage as I am always hitting the same host, I can edit stuff there and see it appear at a reload (as the connection always end up on the same host), and then when done sync it to the other ;) Greets, Jeroen From jeroen@unfix.org Tue Sep 27 04:17:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6578A21F8BBD for ; Tue, 27 Sep 2011 04:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0NCwTzGBdds for ; Tue, 27 Sep 2011 04:17:50 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id A2AD621F8BB7 for ; Tue, 27 Sep 2011 04:17:50 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id D86DF801A365; Tue, 27 Sep 2011 13:20:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317122434; bh=XJYfc5dAmzTymCxV1cFYPvTB04nxK4WQ9w8V3Ovpclc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OH5z5KeXuU3flGIexa6mjUfywBXPUaVG0N3TuyDqPh4jJc5kBtIn6FfrLlFe3CFds ghyad5vQ/vMrpBpB1DCDzvwdenJLZJA+dvZ5bfaBuOQsIeryWZ2wbUjkVl3c2D6M3E lq4PKFjKUqjX9X+JDV7BFLiDySd+YL6yH8ROjtTd5OJ9l2qmw1oGoMjxl3TFpQk2ok mpXYxSYz5h0h5qanERupnVYiZxktsS9GHD4f4OGbsK1zz7ijPcIVYM23bJrnCkRtA6 KCQZe2GtIsOP2M0OM1NsR4zFkTwgPFMVBQJ7Y9A849SsgFarlj6QN0SZ0AiJ73IfJb 1u0aBkwqtS6bg== Message-ID: <4E81B179.7000801@unfix.org> Date: Tue, 27 Sep 2011 13:20:25 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Mohacsi Janos References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 11:17:51 -0000 On 2011-09-27 12:07 , Mohacsi Janos wrote: [other comment answered in split-off message as I expect there to be follow-ups to it that are not entirely related to this thread] > On Tue, 27 Sep 2011, Jeroen Massar wrote: > >> On 2011-09-27 11:43 , Philip Homburg wrote: [..] >>> Can't we just leave this to application writers? Section 5.3 seems >>> more than >>> enough. >> >> Application writers are exactly the ones that should not have to care >> about Address Families or ordering or anything else. >> >> The OS libraries should be taking care of this, or do you want a >> different implementation per not only OS but per application (which is >> what is mostly happening for web browsers anyway). > > > Actually the standardised API (RFC 3493) is not dealing with multiple > connections. It is dealing with getaddrinfo(). The actual applications > are just trying to connect sequentially the addresses what getaddrinfo() > returned. Indeed, but getaddrinfo() can already return addresses in an order that it deems they should be tried at based on metrics (like the OSX Lion implementation). But this might just lead to a requirement for the IETF to finally create a new set of APIs that support HE so that the application programmer can ignore all of this, and just call a "connectit(, )" alike function which does everything most users need? Of course, quite a few frameworks have already implemented similar functionality on their own, and their are myriads of locations where that code exists, thus getting enough code to actually replace their code would be a very long process. Greets, Jeroen From pch-b29AA871B@u-1.phicoh.com Tue Sep 27 04:20:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72CD21F8D20 for ; Tue, 27 Sep 2011 04:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccs2EVEYwVQo for ; Tue, 27 Sep 2011 04:20:51 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AE31721F8D1C for ; Tue, 27 Sep 2011 04:20:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8Vl8-0001ijC; Tue, 27 Sep 2011 13:23:34 +0200 Message-Id: To: Jeroen Massar From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> <4E81ACED.8000207@unfix.org> In-reply-to: Your message of "Tue, 27 Sep 2011 13:01:01 +0200 ." <4E81ACED.8000207@unfix.org> Date: Tue, 27 Sep 2011 13:23:29 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 11:20:52 -0000 In your letter dated Tue, 27 Sep 2011 13:01:01 +0200 you wrote: >> Who cares? You care because you provide an IPv6 service. > >Odd, I am participating in the IETF as me, not as any role or hat I >accidentally might have. True, but what you do with a particular technology tends to shape how you see it. >I care because of the consistency of address family selection which >makes debugging harder for hosts that only have a single IPv4 and IPv6 >address (like general hosts have). Yes, running dual stack makes things harder. There is no way around it. >The ability to disable HE and thus make the results consistent is a >major pro for debugging and other general usage. Again, that's not my experience. >I wonder how you will like the confusion that about every other request, >because of minuscule changes, either IPv4 or IPv6 is selected. I would shop for a better HE implementation then. This sounds like what Apple is doing. There is no reason for HE to be that unstable. >Yes, quite a few tools have -4/-6 and -v alike options, but a lot of GUI >based tools unfortunately do not and will not retrofit this. Well, talk to those people. >> Most of the problems I have to debug are not related to IPv4 or IPv6. > >Ever considered that not everybody uses the Internet in the same way or >for the same purposes? Yes, so why make the exception the rule? >While that is quite true, if you do not stuff all your eggs in the same >basket (read: same prefix) then you will nicely always get a consistent >address order back from Only upto the first bit that is different. The thing is, putting all the eggs in a single /24 is very common. >Note also that various authoritative DNS servers like nsd don't do >address re-ordering and thus unless a intermediary cache is doing the >re-ordering for you, they will always be the same. Still, quite a bit of reordering is going on. >> Because you only care about IPv6 versus IPv4. There is a lot more variation >> than just that bit. > >As this is the IPv6 list, what is the problem with caring about IPv6? Nothing. It works. My problem is more RFCs setting requirements for what kind of debugging options have to be offered by applications and operating systems. >Also, if there is more variation, what would these be that we need to >consider? Root DNS Servers are anycast. And every instance can be different (due to various kinds of problems). >The knob thus allows people who do not want this behavior to turn it off. So, talk to your OS/applications vendor. >Which is why the knob is default set to 'use HE'. > >What is the problem with this? The problem is an RFC requiring such a knob. >> They have to. Because the application has to provide a debugging interface. > >What kind of debugging interface would that be? Could be a simple as '-v'. Firefox has a very extensive control interface to change all kinds of paramers. Asterisk has a CLI debugging/control interface. Some library code can be controlled by setting environment variables. Just a few examples. >Chrome has pretty neat internals under chrome:net-internals but even >that does not show any of the decisions made on the DNS or address >ordering level. Well, talk to the Crome people to add a debug console with debug output. >You don't need to, just don't touch the knob. For the people who want >to, as you say 'screw up HE', let them. > >Be Pro Choice! Freedom to the People (and other such slogans ;) Well, my choice is to make such a knob optional :-) >The "SHOULD" is already in the document, there are several people who >would like that to be a MUST. I found a MAY, there is also a SHOULD? By the time the IETF is telling application vendors what kind of debug interface they have to provide, it is time to just ignore the RFCs. From pch-b29AA871B@u-1.phicoh.com Tue Sep 27 04:22:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E544A21F8906 for ; Tue, 27 Sep 2011 04:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZV0d1k6sGxx for ; Tue, 27 Sep 2011 04:22:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 32EBE21F888A for ; Tue, 27 Sep 2011 04:22:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8Vmg-0001jvC; Tue, 27 Sep 2011 13:25:10 +0200 Message-Id: To: Mohacsi Janos From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> In-reply-to: Your message of "Tue, 27 Sep 2011 12:07:29 +0200 (CEST) ." Date: Tue, 27 Sep 2011 13:25:10 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 11:22:28 -0000 In your letter dated Tue, 27 Sep 2011 12:07:29 +0200 (CEST) you wrote: >Actually the standardised API (RFC 3493) is not dealing with multiple >connections. It is dealing with getaddrinfo(). The actual applications are >just trying to connect sequentially the addresses what getaddrinfo() >returned. There is a bit more to that. A good HE implementation has to know when to start connecting to the next address. You can't just wait for the OS to time out. That takes too long. From jeroen@unfix.org Tue Sep 27 04:44:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E888F21F8C8A for ; Tue, 27 Sep 2011 04:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02LcKmkVPkTk for ; Tue, 27 Sep 2011 04:44:22 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 629ED21F8C88 for ; Tue, 27 Sep 2011 04:44:22 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id C3156801A365; Tue, 27 Sep 2011 13:46:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317124025; bh=H7iEBFGjC9YTyNGXDKsj5pVhKL20XYeU+ofVVW35QzE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=r9NKDPzeyIoh+O0LkNzf41qmZSkUGAfWHcyAQCUUwxgnZjNqxxqIWLRByuB0xq+fM 7b+jOxe8Qk9cQmlrIj5acUj9wVfVyY6nW3agxvq8YAYoXBXqjnGcBxw0nkl3AdQ+4k 8nJTFDhbrcrwN10zivlfFWS26A0DJ1wGw/0cxeccBtVu8UG5ZTDipw0eX0UIJFtEId DksWP+MRBfPa4tZLTX+GUPNcE0L/DWd/mTloJdMqujDFAXI/ZVY1IWD7hAsCxYD6Nm BhFfjB7RyfcuQvSPmv6GIWQMrI2MbaMfX/vnSa5ZmW30PZdbQX47vzUhinbuqPR6s7 hJbPxjmYOfAyQ== Message-ID: <4E81B7AF.5000906@unfix.org> Date: Tue, 27 Sep 2011 13:46:55 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Philip Homburg References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> <4E81ACED.8000207@unfix.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 11:44:23 -0000 On 2011-09-27 13:23 , Philip Homburg wrote: [..] >> You don't need to, just don't touch the knob. For the people who want >> to, as you say 'screw up HE', let them. >> >> Be Pro Choice! Freedom to the People (and other such slogans ;) > > Well, my choice is to make such a knob optional :-) Good to read that you are not raising any arguments AGAINST this kind of knob. Greets, Jeroen From pch-b29AA871B@u-1.phicoh.com Tue Sep 27 05:01:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D758521F8BCB for ; Tue, 27 Sep 2011 05:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmfRc75U7OTN for ; Tue, 27 Sep 2011 05:01:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 14CAC21F8BE8 for ; Tue, 27 Sep 2011 05:01:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1R8WOd-0001jMC; Tue, 27 Sep 2011 14:04:23 +0200 Message-Id: To: Jeroen Massar From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> <4E81ACED.8000207@unfix.org> <4E81B7AF.5000906@unfix.org> In-reply-to: Your message of "Tue, 27 Sep 2011 13:46:55 +0200 ." <4E81B7AF.5000906@unfix.org> Date: Tue, 27 Sep 2011 14:04:21 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 12:01:41 -0000 In your letter dated Tue, 27 Sep 2011 13:46:55 +0200 you wrote: >On 2011-09-27 13:23 , Philip Homburg wrote: >[..] >>> You don't need to, just don't touch the knob. For the people who want >>> to, as you say 'screw up HE', let them. >>> >>> Be Pro Choice! Freedom to the People (and other such slogans ;) >> >> Well, my choice is to make such a knob optional :-) > >Good to read that you are not raising any arguments AGAINST this kind of >knob. I fully support the current text in the draft: "To assist in that regard, the implementations MAY also provide a mechanism to disable their Happy Eyeballs behavior via a user setting." An optional knob is fine with me. From Olaf.Bonness@telekom.de Tue Sep 27 06:17:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A9C21F85D1 for ; Tue, 27 Sep 2011 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ui0QBXTkWDR for ; Tue, 27 Sep 2011 06:17:11 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 88BB421F85CE for ; Tue, 27 Sep 2011 06:17:10 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 27 Sep 2011 10:13:37 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.24]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Tue, 27 Sep 2011 10:13:36 +0200 From: To: , Date: Tue, 27 Sep 2011 10:13:36 +0200 Thread-Topic: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] Thread-Index: Acx8uLxrFjWDJw4bRjKpGq+QtSMmyQANF13g Message-ID: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> In-Reply-To: <4E80E527.1020005@unfix.org> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:17:12 -0000 > Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] > Im Auftrag von Jeroen Massar > Gesendet: Montag, 26. September 2011 22:49 > An: Brian E Carpenter > Cc: IPv6 Operations > Betreff: Re: [v6ops] On/off switch > [draft-ietf-v6ops-happy-eyeballs WGLC] > > On 2011-09-26 22:43 , Brian E Carpenter wrote: > > Unless I've missed it, the draft doesn't require that > > an HE implementation MUST have a user-settable option to > > disable it (and revert to the default prefer-IPv6 behaviour). > > > > I think this needs to be added. > > Strong voice for this from my side. And it does not have to be a UI > element (though that makes some people happy), just a sysctl knob or a > registry switch is just fine, as it is a setting that is likely only > needed by ops folks anyway. I would also prefer to have a more configurable / dynamic approach here and= not just a simply "hard coded" one. Cu Olaf > > Greets, > Jeroen > > -- > jeroen@yomi:~$ cat .ssh/config > AddressFamily inet6 > > and on the verge of fakely inserting a few ms of extra > latency into IPv4 > to compensate for the minor but not really noticeable detour the > tunneled IPv6 packets take... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From marc.blanchet@viagenie.ca Tue Sep 27 06:25:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810ED21F8CF6 for ; Tue, 27 Sep 2011 06:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvekdy3Z+UDu for ; Tue, 27 Sep 2011 06:25:00 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1254121F8CDF for ; Tue, 27 Sep 2011 06:25:00 -0700 (PDT) Received: from [IPv6:2620::230:c000:b89e:e6a0:f8bd:df44] (unknown [IPv6:2620:0:230:c000:b89e:e6a0:f8bd:df44]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D56C921E3F for ; Tue, 27 Sep 2011 09:27:44 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Marc Blanchet In-Reply-To: Date: Tue, 27 Sep 2011 09:27:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:25:00 -0000 Le 2011-09-27 =E0 04:13, a =E9crit : >> Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] >> Im Auftrag von Jeroen Massar >> Gesendet: Montag, 26. September 2011 22:49 >> An: Brian E Carpenter >> Cc: IPv6 Operations >> Betreff: Re: [v6ops] On/off switch >> [draft-ietf-v6ops-happy-eyeballs WGLC] >>=20 >> On 2011-09-26 22:43 , Brian E Carpenter wrote: >>> Unless I've missed it, the draft doesn't require that >>> an HE implementation MUST have a user-settable option to >>> disable it (and revert to the default prefer-IPv6 behaviour). >>>=20 >>> I think this needs to be added. >>=20 >> Strong voice for this from my side. And it does not have to be a UI >> element (though that makes some people happy), just a sysctl knob or = a >> registry switch is just fine, as it is a setting that is likely only >> needed by ops folks anyway. >=20 > I would also prefer to have a more configurable / dynamic approach = here and not just a simply "hard coded" one. me too. this is a minimum. Especially for "controlled deployments" (eg: = enterprise, managed services, geeks, ...), where one knows and = understand the consequences of running with or without HE. =20 I would like to see a knob that would have the possible values as: - default (HE no pref between v4 or v6) - v6 (HE does pref v6 by some minimal increment) - off (disable HE) The way to implement this might be: - off: value =3D 65535 - default: value =3D 0 - v6: value =3D number of ms "advantage for ipv6" or any other variation thereof. Marc. > Cu > Olaf >>=20 >> Greets, >> Jeroen >>=20 >> -- >> jeroen@yomi:~$ cat .ssh/config >> AddressFamily inet6 >>=20 >> and on the verge of fakely inserting a few ms of extra >> latency into IPv4 >> to compensate for the minor but not really noticeable detour the >> tunneled IPv6 packets take... >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From achatz@forthnet.gr Tue Sep 27 06:43:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F7121F888A for ; Tue, 27 Sep 2011 06:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9LuZC1hc2rA for ; Tue, 27 Sep 2011 06:43:12 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4707421F8A62 for ; Tue, 27 Sep 2011 06:43:12 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8RDjttg018468; Tue, 27 Sep 2011 16:45:55 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8RDjtra022773; Tue, 27 Sep 2011 16:45:55 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id p8RDjiGY008786; Tue, 27 Sep 2011 16:45:54 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnet.gr; auth=pass (PLAIN) Message-ID: <4E81D386.6040402@forthnet.gr> Date: Tue, 27 Sep 2011 16:45:42 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet S.A. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 MIME-Version: 1.0 To: Marc Blanchet References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:43:13 -0000 Marc Blanchet wrote on 27/09/2011 16:27: > Le 2011-09-27 à 04:13, a écrit : > >>> Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] >>> Im Auftrag von Jeroen Massar >>> Gesendet: Montag, 26. September 2011 22:49 >>> An: Brian E Carpenter >>> Cc: IPv6 Operations >>> Betreff: Re: [v6ops] On/off switch >>> [draft-ietf-v6ops-happy-eyeballs WGLC] >>> >>> On 2011-09-26 22:43 , Brian E Carpenter wrote: >>>> Unless I've missed it, the draft doesn't require that >>>> an HE implementation MUST have a user-settable option to >>>> disable it (and revert to the default prefer-IPv6 behaviour). >>>> >>>> I think this needs to be added. >>> Strong voice for this from my side. And it does not have to be a UI >>> element (though that makes some people happy), just a sysctl knob or a >>> registry switch is just fine, as it is a setting that is likely only >>> needed by ops folks anyway. >> I would also prefer to have a more configurable / dynamic approach here and not just a simply "hard coded" one. > me too. this is a minimum. Especially for "controlled deployments" (eg: enterprise, managed services, geeks, ...), where one knows and understand the consequences of running with or without HE. > > I would like to see a knob that would have the possible values as: > - default (HE no pref between v4 or v6) > - v6 (HE does pref v6 by some minimal increment) > - off (disable HE) > > The way to implement this might be: > - off: value = 65535 > - default: value = 0 > - v6: value = number of ms "advantage for ipv6" > > or any other variation thereof. > > Marc. What is the difference between "off" and "default"? -- Tassos >> Cu >> Olaf >>> Greets, >>> Jeroen >>> >>> -- >>> jeroen@yomi:~$ cat .ssh/config >>> AddressFamily inet6 >>> >>> and on the verge of fakely inserting a few ms of extra >>> latency into IPv4 >>> to compensate for the minor but not really noticeable detour the >>> tunneled IPv6 packets take... >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From marc.blanchet@viagenie.ca Tue Sep 27 06:45:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8C521F8C63 for ; Tue, 27 Sep 2011 06:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvqp3LoWEpBK for ; Tue, 27 Sep 2011 06:45:05 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 466F021F8C5E for ; Tue, 27 Sep 2011 06:45:05 -0700 (PDT) Received: from [IPv6:2620::230:c000:b89e:e6a0:f8bd:df44] (unknown [IPv6:2620:0:230:c000:b89e:e6a0:f8bd:df44]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7E7FA21E3F; Tue, 27 Sep 2011 09:47:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <4E81D386.6040402@forthnet.gr> Date: Tue, 27 Sep 2011 09:47:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E81D386.6040402@forthnet.gr> To: Tassos Chatzithomaoglou X-Mailer: Apple Mail (2.1244.3) Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:45:05 -0000 Le 2011-09-27 =E0 09:45, Tassos Chatzithomaoglou a =E9crit : >=20 > Marc Blanchet wrote on 27/09/2011 16:27: >> Le 2011-09-27 =E0 04:13, a =E9crit : >>=20 >>>> Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] >>>> Im Auftrag von Jeroen Massar >>>> Gesendet: Montag, 26. September 2011 22:49 >>>> An: Brian E Carpenter >>>> Cc: IPv6 Operations >>>> Betreff: Re: [v6ops] On/off switch >>>> [draft-ietf-v6ops-happy-eyeballs WGLC] >>>>=20 >>>> On 2011-09-26 22:43 , Brian E Carpenter wrote: >>>>> Unless I've missed it, the draft doesn't require that >>>>> an HE implementation MUST have a user-settable option to >>>>> disable it (and revert to the default prefer-IPv6 behaviour). >>>>>=20 >>>>> I think this needs to be added. >>>> Strong voice for this from my side. And it does not have to be a UI >>>> element (though that makes some people happy), just a sysctl knob = or a >>>> registry switch is just fine, as it is a setting that is likely = only >>>> needed by ops folks anyway. >>> I would also prefer to have a more configurable / dynamic approach = here and not just a simply "hard coded" one. >> me too. this is a minimum. Especially for "controlled deployments" = (eg: enterprise, managed services, geeks, ...), where one knows and = understand the consequences of running with or without HE. >>=20 >> I would like to see a knob that would have the possible values as: >> - default (HE no pref between v4 or v6) >> - v6 (HE does pref v6 by some minimal increment) >> - off (disable HE) >>=20 >> The way to implement this might be: >> - off: value =3D 65535 >> - default: value =3D 0 >> - v6: value =3D number of ms "advantage for ipv6" >>=20 >> or any other variation thereof. >>=20 >> Marc. >=20 > What is the difference between "off" and "default"? (see above for the semantics) default =3D HE enabled off =3D HE disabled.=20 Marc. >=20 > -- > Tassos >>> Cu >>> Olaf >>>> Greets, >>>> Jeroen >>>>=20 >>>> -- >>>> jeroen@yomi:~$ cat .ssh/config >>>> AddressFamily inet6 >>>>=20 >>>> and on the verge of fakely inserting a few ms of extra >>>> latency into IPv4 >>>> to compensate for the minor but not really noticeable detour the >>>> tunneled IPv6 packets take... >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 From marc.blanchet@viagenie.ca Tue Sep 27 06:50:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2193621F8CDF for ; Tue, 27 Sep 2011 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.689 X-Spam-Level: X-Spam-Status: No, score=-102.689 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dahc7pOPWjOh for ; Tue, 27 Sep 2011 06:50:36 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0225421F8CE1 for ; Tue, 27 Sep 2011 06:50:36 -0700 (PDT) Received: from [IPv6:2620::230:c000:b89e:e6a0:f8bd:df44] (unknown [IPv6:2620:0:230:c000:b89e:e6a0:f8bd:df44]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4D40C21E3F for ; Tue, 27 Sep 2011 09:53:21 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Marc Blanchet In-Reply-To: Date: Tue, 27 Sep 2011 09:53:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <114BD2A1-B362-4F13-AB56-F95DB1FEDFFC@viagenie.ca> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E81D386.6040402@forthnet.gr> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:50:37 -0000 Le 2011-09-27 =E0 09:47, Marc Blanchet a =E9crit : >>>=20 >>> I would like to see a knob that would have the possible values as: >>> - default (HE no pref between v4 or v6) >>> - v6 (HE does pref v6 by some minimal increment) >>> - off (disable HE) >>>=20 >>> The way to implement this might be: >>> - off: value =3D 65535 >>> - default: value =3D 0 >>> - v6: value =3D number of ms "advantage for ipv6" >>>=20 >>> or any other variation thereof. >>>=20 >>> Marc. >>=20 >> What is the difference between "off" and "default"? >=20 > (see above for the semantics) >=20 > default =3D HE enabled > off =3D HE disabled.=20 >=20 > Marc. btw, I can provide text if there is support in wg for this idea. Marc. From jeroen@unfix.org Tue Sep 27 06:55:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8504621F8CDB for ; Tue, 27 Sep 2011 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ0R1gX34gJq for ; Tue, 27 Sep 2011 06:55:22 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id CCD9521F8CC6 for ; Tue, 27 Sep 2011 06:55:21 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 50107801A365; Tue, 27 Sep 2011 15:57:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1317131885; bh=heEDFHnjeQdbpEWL/Q/K4tyeuMcaNL8Abu/GhtZ4cCc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=h1p4tW5VpT4J2xq5q98gqW/FS81CgOwrqkM5eSlgEYEMbsYT1EUvjqocCcA6+Jmq1 1kBaL0TIFVYiM/R0ZAVFaAXDEo2t0p7iT78jFyjmFAhkO22g00P43BnHNnLBxeD+kI 0BstotYQm9SvJOv1DpH/RGZu9kqplZW7mGuPrBrBgDCvkGZPhMjrwrwoXx4kCxGEjF AR3+XXu1MeatJXv1cRmQwHbuxooip/h/2kl8JZlM+czP0FWteJoLDTiXXVGk+zPUp1 IUkPhmaoWtXAuK5fFjeauot96wP8lHJAdgtCYPlRA5+Riebq1J7oHYwE/acpsNN6J5 Lma/PS4vxMybQ== Message-ID: <4E81D664.4030002@unfix.org> Date: Tue, 27 Sep 2011 15:57:56 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Marc Blanchet References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E81D386.6040402@forthnet.gr> <114BD2A1-B362-4F13-AB56-F95DB1FEDFFC@viagenie.ca> In-Reply-To: <114BD2A1-B362-4F13-AB56-F95DB1FEDFFC@viagenie.ca> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:55:22 -0000 On 2011-09-27 15:53 , Marc Blanchet wrote: > Le 2011-09-27 à 09:47, Marc Blanchet a écrit : > >>>> >>>> I would like to see a knob that would have the possible values as: >>>> - default (HE no pref between v4 or v6) >>>> - v6 (HE does pref v6 by some minimal increment) >>>> - off (disable HE) >>>> >>>> The way to implement this might be: >>>> - off: value = 65535 >>>> - default: value = 0 >>>> - v6: value = number of ms "advantage for ipv6" [..] > btw, I can provide text if there is support in wg for this idea. I would say that it is a great thing to add, but just an on/off is already good enough from my POV. The above proposal would give the advantage to be able to easily distribute a site-wide (given that one control all the hosts involved) bonus for IPv6 in case a site is connected over a tunnel or other mechanism which causes a bit more latency on the IPv6 side. The other way to counter that disadvantage is just delaying IPv4 packets at the moment, but that is far from a proper solution. Greets, Jeroen From mohacsi@niif.hu Tue Sep 27 07:05:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC81021F8CAF for ; Tue, 27 Sep 2011 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.029 X-Spam-Level: X-Spam-Status: No, score=-1.029 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzWT1ew5DF5r for ; Tue, 27 Sep 2011 07:05:44 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 37A5721F8CAD for ; Tue, 27 Sep 2011 07:05:44 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 6E646877BA; Tue, 27 Sep 2011 16:08:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id tYcEQ9CZzwGG; Tue, 27 Sep 2011 16:08:23 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 66B1F877B9; Tue, 27 Sep 2011 16:08:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6440C877A7; Tue, 27 Sep 2011 16:08:23 +0200 (CEST) Date: Tue, 27 Sep 2011 16:08:23 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Philip Homburg In-Reply-To: Message-ID: References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <4E80E1ED.5060209@gmail.com> <4EC85369-B137-4430-90BE-3398E832FB6C@apple.com> <4E8193F3.50801@unfix.org> <4E819CDD.8090602@unfix.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 14:05:44 -0000 On Tue, 27 Sep 2011, Philip Homburg wrote: > In your letter dated Tue, 27 Sep 2011 12:07:29 +0200 (CEST) you wrote: >> Actually the standardised API (RFC 3493) is not dealing with multiple >> connections. It is dealing with getaddrinfo(). The actual applications are >> just trying to connect sequentially the addresses what getaddrinfo() >> returned. > > There is a bit more to that. A good HE implementation has to know when to > start connecting to the next address. You can't just wait for the OS to > time out. That takes too long. We are speaking about the same problem. I was referring the current non HE applications - sequential try until success methods. The HE aware applications should use new API which is hiding the parallel connection attempts.... Or applications should be rewriten to use SCTP ;-) (and in the same time at the server side also) Best Regards, Janos Mohacsi From brian.e.carpenter@gmail.com Tue Sep 27 17:13:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBE921F8F70 for ; Tue, 27 Sep 2011 17:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.274 X-Spam-Level: X-Spam-Status: No, score=-103.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S00JYLz9KuFV for ; Tue, 27 Sep 2011 17:13:25 -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 3665321F8F81 for ; Tue, 27 Sep 2011 17:13:23 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5944916vcb.31 for ; Tue, 27 Sep 2011 17:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YJKN36aDJweC2hyyVJb5v1aP0B95l17pH3wo4BhPj0g=; b=n3Uy/WCqL4g1sbl/rpUQnakBtbKJB8auRgwqikWBACk5G8/Z1d7uGH5xLwy0OuJ6Rk IY68uxP/M4PIRTV1/HTU98LJJYY8kIiwBIw+AV6iMvcjyUtkrQNaayt9CxszNt5PHQ/z vzH83KCbgTwnhz8m6gRhxdjGCPsVI6DYu0bVE= Received: by 10.220.9.195 with SMTP id m3mr2399563vcm.20.1317168969691; Tue, 27 Sep 2011 17:16:09 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id gb4sm21621739vdc.16.2011.09.27.17.16.06 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 17:16:08 -0700 (PDT) Message-ID: <4E82674E.3020107@gmail.com> Date: Wed, 28 Sep 2011 13:16:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com><34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E81D386.6040402@forthnet.gr> <114BD2A1-B362-4F13-AB56-F95DB1FEDFFC@viagenie.ca> <4E81D664.4030002@unfix.org> In-Reply-To: <4E81D664.4030002@unfix.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 00:13:26 -0000 Marc, On 2011-09-28 02:57, Jeroen Massar wrote: > On 2011-09-27 15:53 , Marc Blanchet wrote: >> Le 2011-09-27 =C3=A0 09:47, Marc Blanchet a =C3=A9crit : >> >>>>> I would like to see a knob that would have the possible values as: >>>>> - default (HE no pref between v4 or v6) >>>>> - v6 (HE does pref v6 by some minimal increment) >>>>> - off (disable HE) >>>>> >>>>> The way to implement this might be: >>>>> - off: value =3D 65535 >>>>> - default: value =3D 0 >>>>> - v6: value =3D number of ms "advantage for ipv6" > [..] >=20 >> btw, I can provide text if there is support in wg for this idea. >=20 > I would say that it is a great thing to add, but just an on/off is > already good enough from my POV. I agree; maybe on/off as a MUST and the ms of bias as a MAY? I don't see anybody opposing the general idea, anyway. Brian >=20 > The above proposal would give the advantage to be able to easily > distribute a site-wide (given that one control all the hosts involved) > bonus for IPv6 in case a site is connected over a tunnel or other > mechanism which causes a bit more latency on the IPv6 side. >=20 > The other way to counter that disadvantage is just delaying IPv4 packet= s > at the moment, but that is far from a proper solution. >=20 > Greets, > Jeroen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From brian.e.carpenter@gmail.com Tue Sep 27 20:33:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279F921F8C81 for ; Tue, 27 Sep 2011 20:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2AAq+S8UxAs for ; Tue, 27 Sep 2011 20:33:27 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71FC221F8C79 for ; Tue, 27 Sep 2011 20:33:27 -0700 (PDT) Received: by vws5 with SMTP id 5so9000837vws.31 for ; Tue, 27 Sep 2011 20:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DgrqGmtLPaJVP0P9gXIvsuSCb6Zzrk9AuQjz5cNqRfs=; b=FwerT4ZEzF55i3VFfaCgjAD18z4c16+ahvA3zCBYjnrvvsEV4sZlL/sOCxlSJ25tcy Nrc74nZam1AF82rCU5p3D29r9/vE/5uBIOgz/c4l73Fyvd1YpbAJw51Nqng+rYxQL4G1 Y8ToJWCDHLXMweM0uQkZbP2vc94VZDRufi5gw= Received: by 10.52.181.165 with SMTP id dx5mr8576749vdc.279.1317180974468; Tue, 27 Sep 2011 20:36:14 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id x19sm22021430vdf.10.2011.09.27.20.36.07 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 20:36:13 -0700 (PDT) Message-ID: <4E82962F.50107@gmail.com> Date: Wed, 28 Sep 2011 16:36:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <20110901062337.13131.28709.idtracker@ietfa.amsl.com> In-Reply-To: <20110901062337.13131.28709.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 03:33:28 -0000 A few comments on this version: Firstly a general remark, which I am trying to phrase neutrally: Reading through this and the solutions it proposes, it seems that DHCPv6 would be mandatory for multihomed multi-prefix hosts. If that is so, we should say so clearly and be done with it. Otherwise there will be calls for RA-based solutions for each aspect. Now some more specific comments: > 1. Introduction > > IPv6 provides enough globally unique addresses to permit every > conceivable host on the Internet to be uniquely addressed without the > requirement for Network Address Port Translation (NAPT [RFC3022]), > offering a renaissance in end-to-end transparent connectivity. > > Unfortunately, this may not be possible due to the necessity of NAT > even in IPv6, because of multihoming. This is a bit scary as written. It would be much nicer if it read: Unfortunately, this may not be possible in every case, due to the possible necessity of NAT even in IPv6, because of multihoming. Also, can you introduce NPTv6 right here in the text and use "NPTv6" everywhere that you use "NAT(66)" in the rest of the document? We don't want people to associate "NAT" and "IPv6". Then, update the "Terminology" section accordingly. ... > A possible consequence of assigning a host > multiple identically-scoped addresses is severely impaired IP > connectivity. This seems a bit alarmist. If the host only had one of those addresses, its connectivity might be impaired too. I would buy "sub-optimal IP connectivity." > 3.2. Multihomed network environment ... > Multihomed networks in IPv4 have been commonly implemented through > the use of a gateway router with NAPT function (scenario 2 with > NAPT). To me "commonly" implies that it is the normal case, and I'm not sure you can justify that. How about "in many cases"? > 5.1. Source address selection ... > [I-D.ietf-6man-addr-select-considerations] describes the use of the > policy table [RFC3484] to resolve this problem, Firstly, draft-ietf-6man-addr-select-considerations is expired. Is it going to be progressed? Secondly, shouldn't we consider draft-ietf-6man-rfc3484-revise as the basis now? I'v got a more basic concern about this section: the real problem is not source address selection, it's address pair selection. [See the happy-eyeballs discussion.] I think you at least need to discuss the fact that with present tools, the host has to select the destination address and the source address independently (assuming the destination is *also* multihomed), and that this is a problem that this draft does not attempt to solve. > 8. Security Considerations ... > Policy collision can happen. I can see why you list this as a possible security issue, but it's more general than that and probably needs its own subsection in Section 7 (or possibly in 3484-revise). It's a problem for every policy distribution scenario, I think, and the usual approach is to define a precedence rule and a tie-breaker rule. Brian From internet-drafts@ietf.org Fri Sep 30 05:29:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986621F8B5D; Fri, 30 Sep 2011 05:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emq66KUAc0ac; Fri, 30 Sep 2011 05:29:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1717121F8B20; Fri, 30 Sep 2011 05:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110930122903.19148.56080.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2011 05:29:03 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 12:29:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-08.txt Pages : 35 Date : 2011-09-30 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-08.txt From lorenzo@google.com Fri Sep 30 13:55:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C7A21F8ABB for ; Fri, 30 Sep 2011 13:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.762 X-Spam-Level: X-Spam-Status: No, score=-104.762 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGHnn2Po+67t for ; Fri, 30 Sep 2011 13:55:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBDF21F8AAC for ; Fri, 30 Sep 2011 13:55:02 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p8UKvpp5029620 for ; Fri, 30 Sep 2011 13:57:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317416273; bh=cIAV7wfbK+Sz4eyQBOLglm3vtRw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=d23acmL3TXW6I+gbtPFPkTgtEstR38vcoSGPebpYc7D1cJysEu1lm+Oio/3BWQ+0n VzIJ4+4bIVF/7u6IFaz/w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=RmR7NOIkfAwQh7YZLHTD7a+ja6mHMvMr7zckW+7m7lGmVY5xfFBEe2BqOBhkpTDeK qmhyl5xjLSGjxBtey0HZg== Received: from yxj19 (yxj19.prod.google.com [10.190.3.83]) by wpaz33.hot.corp.google.com with ESMTP id p8UKvILL021172 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 30 Sep 2011 13:57:50 -0700 Received: by yxj19 with SMTP id 19so2290833yxj.37 for ; Fri, 30 Sep 2011 13:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n9Itcssn+YjOYdmOgC6LZjx4gqUV6U8thDBFz5XkEBM=; b=veN4JLoRg1gX3TT+vYSimRpJPKB0CimJ4K5Jn1Isss4ZBgULD7PErIvDqB/VDxyUT7 hgt53dDkMsf2E3r/6Jkg== Received: by 10.150.215.1 with SMTP id n1mr1112939ybg.399.1317416268172; Fri, 30 Sep 2011 13:57:48 -0700 (PDT) Received: by 10.150.215.1 with SMTP id n1mr1112918ybg.399.1317416267150; Fri, 30 Sep 2011 13:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Fri, 30 Sep 2011 13:57:26 -0700 (PDT) In-Reply-To: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> From: Lorenzo Colitti Date: Fri, 30 Sep 2011 13:57:26 -0700 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=000e0cd59d1e9ff48904ae2ee0b5 X-System-Of-Record: true Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:55:03 -0000 --000e0cd59d1e9ff48904ae2ee0b5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 22, 2011 at 22:18, Fred Baker wrote: > We are looking specifically for comments on the importance of the document > as well as its content. If you have read the document and believe it to be > of operational utility, that is also an important comment to make. > I support the publication of this document. A few comments: 1. The algorithm focuses on slow TCP connections. This is not the only cause of slow performance of IPv6, DNS plays a part too. IPv6 responses may not be cached or have low negative lifetimes; a broken DNS forwarder may be timing out AAAA queries, or even returning them as A records with the first 32 bits of the IPv6 address [1]; and so on. Some of this is documented in RFC 4074, so you might want to cite it, even if only to claim that overcoming slowness due to DNS queries is out of scope for this document. 2. You say that the recommended timeout is 150 to 250ms. FYI, Chrome uses 300ms. This is so much better than the default timeouts of 21s or 75s, and the number of users with this problem is so low (approximately 0.1% in today's Internet) that it seems to be a good compromise, especially since only the first connection is really affected. It also provides power users who would notice with a small (300ms) incentive to get IPv6 working or disable it when it's broken. Finally, it reduces the server load caused by stateless algorithms: in some regions of the world, an RTT of over 150ms is very common. 3. Mozilla Firefox has disabled their happy eyeballs implementation because it doesn't work. So I would avoid citing them here. To those who say that the algorithm shouldn't prefer IPv6, I disagree. I think we all agree that IPv6 is the right way forward in the long term. Our problem now is that enabling IPv6 causes lots of pain to a small amount of users, and we can't move forward. However, if the maximum impact is 300ms additional latency on the first TCP connection to 0.1% of users, then a case can be made that it's worth it. As the draft correctly observes, it's hard to make IPv6 faster than IPv4 if everything is running on the same infrastructure (which is the only sane way to transition); if you do everything right, you'll get parity. So algorithms that try to pick the fastest connection every time will just end up choosing one or the other non-deterministically, or - worse - in the arbitrary order that they end up doing DNS lookups. Cheers, Lorenzo [1]. http://www.getipv6.info/index.php/Customer_problems_that_could_occur#D-Link --000e0cd59d1e9ff48904ae2ee0b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 22, 2011 at 22:18, Fred Baker <fred@cisco.com> wrote:
We are looking specifically for comments on the importance of the document = as well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to make.

I support the publication of this document. A few comme= nts:

1. The algorithm focuses on slow TCP connecti= ons. This is not the only cause of slow performance of IPv6, DNS plays a pa= rt too. IPv6 responses may not be cached or have low negative lifetimes; a = broken DNS forwarder may be timing out AAAA queries, or even returning them= as A records with the first 32 bits of the IPv6 address [1]; and so on. So= me of this is documented=A0in RFC 4074, so you might want to cite it, even = if only to claim that overcoming slowness due to DNS queries is out of scop= e for this document.

2. You say that the recommended timeout is 150 to 250ms= . FYI, Chrome uses 300ms. This is so much better than the default timeouts = of 21s or 75s, and the number of users with this problem is so low (approxi= mately 0.1% in today's Internet) that it seems to be a good compromise,= especially since only the first connection is really affected.

It also provides power users who would notice with= a small (300ms) incentive to get IPv6 working or disable it when it's = broken. Finally, it=A0reduces the server load caused by stateless algorithm= s: in some regions of the world, an RTT of over 150ms is very common.

3. Mozilla Firefox has disabled their happy eyeba= lls implementation because it doesn't work. So I would avoid citing the= m here.

To those who say that the algorithm should= n't prefer IPv6, I disagree. I think we all agree that IPv6 is the righ= t way forward in the long term. Our problem now is that enabling IPv6 cause= s lots of pain to a small amount of users, and we can't move forward. H= owever, if the maximum impact is 300ms additional latency on the first TCP = connection to 0.1% of users, then a case can be made that it's worth it= .

As the draft correctly observes, it's hard to make = IPv6 faster than IPv4 if everything is running on the same infrastructure (= which is the only sane way to transition); if you do everything right, you&= #39;ll get parity. So algorithms that try to pick the fastest connection ev= ery time will just end up choosing one or the other non-deterministically, = or - worse - in the arbitrary order that they end up doing DNS lookups.

Cheers,
Lorenzo

--000e0cd59d1e9ff48904ae2ee0b5-- From lorenzo@google.com Fri Sep 30 19:22:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0D11E8082 for ; Fri, 30 Sep 2011 19:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.839 X-Spam-Level: X-Spam-Status: No, score=-105.839 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfF3K6nVQFcj for ; Fri, 30 Sep 2011 19:22:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 54AC011E8073 for ; Fri, 30 Sep 2011 19:22:37 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p912PToA004373 for ; Fri, 30 Sep 2011 19:25:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317435930; bh=VBuULXDJUVYVdbw6Hfg3KGybZnw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ApmNqy0ppNhRNSIpFd9tr39oOktpKpFeD1kCB2ggdShIPeqh8ObF9nN9TnFxHRT02 rS9qv8ig3YoMNTdt2llWw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=txblEsUOulDvSWUhzAn0PS/by4LHtaKS2kD4eBmdRNNMGJG6iov68ettMGpr3O7YX FodaLso0FD/LH+qfwD0QQ== Received: from gyg10 (gyg10.prod.google.com [10.243.50.138]) by hpaq7.eem.corp.google.com with ESMTP id p912PRq5009038 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 30 Sep 2011 19:25:28 -0700 Received: by gyg10 with SMTP id 10so2607119gyg.33 for ; Fri, 30 Sep 2011 19:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NUsHpNFlusTXUaTQSWvqaz6WNULJNIuaiNhr77+R920=; b=thaDjVFPBVP8oSpEtrd4Gwa6DDW/d6zPNWtSg5s3jLdP+MvmZ6CARN6eDkez27RiSB w2OHuyJs2ODVfswxs0Tw== Received: by 10.150.141.21 with SMTP id o21mr8364685ybd.57.1317435927341; Fri, 30 Sep 2011 19:25:27 -0700 (PDT) Received: by 10.150.141.21 with SMTP id o21mr8364678ybd.57.1317435927119; Fri, 30 Sep 2011 19:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Fri, 30 Sep 2011 19:25:07 -0700 (PDT) In-Reply-To: <4E82674E.3020107@gmail.com> References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E81D386.6040402@forthnet.gr> <114BD2A1-B362-4F13-AB56-F95DB1FEDFFC@viagenie.ca> <4E81D664.4030002@unfix.org> <4E82674E.3020107@gmail.com> From: Lorenzo Colitti Date: Fri, 30 Sep 2011 19:25:07 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=000e0cd75f907349a904ae33748a X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 02:22:38 -0000 --000e0cd75f907349a904ae33748a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 17:16, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I agree; maybe on/off as a MUST and the ms of bias as a MAY? > > I don't see anybody opposing the general idea, anyway. I don't think it's useful. What would you need such a feature for? If IPv6 is as fast as IPv4, then the implementation should just use IPv6 all the time. If IPv6 is broken, wouldn't you as a user want to use IPv4 instead of using something that's broken? Personally, I think that if you want to find out if IPv6 is working, you should use network monitoring. It's much more reliable than users with browsers. Also: I don't think that apps will pay much attention to what the IETF says in regard to what settings they provide and expose to the user. Putting MUST here could cause applications to be in violation of the RFC even if they're perfectly in compliance with the actual technical requirements that matter. --000e0cd75f907349a904ae33748a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 27, 2011 at 17:16, Brian E Carpenter= <brian= .e.carpenter@gmail.com> wrote:
I agree; maybe on/off as a MUST and the ms of bias as a MAY?

I don't see anybody opposing the general idea, anyway.

I don't think it's useful.

What would you need such a feature for? If IPv6 is as fast as IPv4, then t= he implementation should just use IPv6 all the time. If IPv6 is broken, wou= ldn't you as a user want to use IPv4 instead of using something that= 9;s broken?

Personally, I think that if you want to find out if IPv= 6 is working, you should use network monitoring. It's much more reliabl= e than users with browsers.

Also: I don't think that = apps will pay much attention to what the IETF says in regard to what settin= gs they provide and expose to the user. Putting MUST here could cause appli= cations to be in violation of the RFC even if they're perfectly in comp= liance with the actual technical requirements that matter.
--000e0cd75f907349a904ae33748a-- From brian.e.carpenter@gmail.com Fri Sep 30 20:29:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DC821F8A64 for ; Fri, 30 Sep 2011 20:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.108 X-Spam-Level: X-Spam-Status: No, score=-103.108 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB22=0.948, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtZ13jfxIte8 for ; Fri, 30 Sep 2011 20:29:11 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C52921F8A4E for ; Fri, 30 Sep 2011 20:29:11 -0700 (PDT) Received: by bkaq10 with SMTP id q10so2682820bka.31 for ; Fri, 30 Sep 2011 20:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r0LItgWp0dQ7Wg+p7ebehqGn2oHAmS+i6JqVzcbB8I0=; b=we9Mnlm00OZ4F922Akh/97eAguibAaYD2SMiIDF9W/pYzB09bmzdIBJzORwQFNa0Z/ rAqTvbb1wnw+6teqmr8+h17TeVDuKDGEaVTn32i3dg6z+DdQRCWJpAV8IcXdcEXTfggp fM0mQO4kfLC2nRQ2gfEPXS2EVnBZm6NqyF3ng= Received: by 10.223.95.139 with SMTP id d11mr8906878fan.117.1317439925195; Fri, 30 Sep 2011 20:32:05 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x22sm9509300faa.5.2011.09.30.20.32.02 (version=SSLv3 cipher=OTHER); Fri, 30 Sep 2011 20:32:04 -0700 (PDT) Message-ID: <4E8689AC.2020302@gmail.com> Date: Sat, 01 Oct 2011 16:31:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <069E0C70-1D6F-4B19-AA4B-FF1C9CF198CF@cisco.com> <34E4F50CAFA10349A41E0756550084FB0FA69093@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0FA69483@PRVPEXVS04.corp.twcable.com> <067E6CE33034954AAC05C9EC85E2577C060633BD@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060633FC@XMB-RCD-111.cisco.com> <4E80E3DE.1010306@gmail.com> <4E80E527.1020005@unfix.org> <4E81D386.6040402@forthnet.gr> <114BD2A1-B362-4F13-AB56-F95DB1FEDFFC@viagenie.ca> <4E81D664.4030002@unfix.org> <4E82674E.3020107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 03:29:12 -0000 On 2011-10-01 15:25, Lorenzo Colitti wrote: > On Tue, Sep 27, 2011 at 17:16, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> I agree; maybe on/off as a MUST and the ms of bias as a MAY? >> >> I don't see anybody opposing the general idea, anyway. > > > I don't think it's useful. > > What would you need such a feature for? If IPv6 is as fast as IPv4, then the > implementation should just use IPv6 all the time. If IPv6 is broken, > wouldn't you as a user want to use IPv4 instead of using something that's > broken? That's not for you to say. I might want to stand on my head all day, too. Really - as someone else said, it might well be a useful tool for certains types of diagnosis (e.g. a user who complains about poor browsing response - let's switch off HE to see if that's relevant). Or there might be other reasons that I'm not smart enough to think of until the day comes. It seems to me that making such a complex algorithm switch-offable is just normal engineering. > Personally, I think that if you want to find out if IPv6 is working, you > should use network monitoring. It's much more reliable than users with > browsers. That depends entirely on the problem you're faced with. > Also: I don't think that apps will pay much attention to what the IETF says > in regard to what settings they provide and expose to the user. Putting MUST > here could cause applications to be in violation of the RFC even if they're > perfectly in compliance with the actual technical requirements that matter. And why would that be a problem for the IETF? It would be a problem for the user, perhaps, but then they can switch to a browser that does provide the switch. Brian From tsavo.stds@gmail.com Fri Sep 30 22:22:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B167921F8513 for ; Fri, 30 Sep 2011 22:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBGpEw0k+7Tw for ; Fri, 30 Sep 2011 22:22:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33F21F84D7 for ; Fri, 30 Sep 2011 22:22:28 -0700 (PDT) Received: by ywa6 with SMTP id 6so2588622ywa.31 for ; Fri, 30 Sep 2011 22:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=6L0E1ZiTRJaiuPh9knwJLqJqdQFWpvw32GVocJ/o0yQ=; b=qFt0/RsnANUP/IlG0hYpIQxYnOvjRTNBoOVnnlG/iDfTbkcWF2I3hjdU7sUUGhDiI1 aERB6bHnG+JajtKr+/UnQ1eDi1WVcM1rsUBHBSA7fS56SSpi9cQIGvH0wR1SFMRrKgs8 e1L9iXRemLw4tQxEolrjRqGnyQSTigjamVp7A= Received: by 10.150.186.14 with SMTP id j14mr7859246ybf.171.1317446723740; Fri, 30 Sep 2011 22:25:23 -0700 (PDT) MIME-Version: 1.0 From: Teemu Savolainen Date: Fri, 30 Sep 2011 22:25:23 -0700 Message-ID: <1162752405889281096@unknownmsgid> To: Brian E Carpenter , Jeroen Massar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 05:22:28 -0000 I object MUST for configuration option, as for some class of hosts, like embedded systems, it is not always feasible to have such settings supported. Teemu Sent from my Windows Phone From: Brian E Carpenter Sent: 28.9.2011 3:16 To: Jeroen Massar Cc: v6ops@ietf.org Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] Marc, On 2011-09-28 02:57, Jeroen Massar wrote: > On 2011-09-27 15:53 , Marc Blanchet wrote: >> Le 2011-09-27 =E0 09:47, Marc Blanchet a =E9crit : >> >>>>> I would like to see a knob that would have the possible values as: >>>>> - default (HE no pref between v4 or v6) >>>>> - v6 (HE does pref v6 by some minimal increment) >>>>> - off (disable HE) >>>>> >>>>> The way to implement this might be: >>>>> - off: value =3D 65535 >>>>> - default: value =3D 0 >>>>> - v6: value =3D number of ms "advantage for ipv6" > [..] > >> btw, I can provide text if there is support in wg for this idea. > > I would say that it is a great thing to add, but just an on/off is > already good enough from my POV. I agree; maybe on/off as a MUST and the ms of bias as a MAY? I don't see anybody opposing the general idea, anyway. Brian > > The above proposal would give the advantage to be able to easily > distribute a site-wide (given that one control all the hosts involved) > bonus for IPv6 in case a site is connected over a tunnel or other > mechanism which causes a bit more latency on the IPv6 side. > > The other way to counter that disadvantage is just delaying IPv4 packets > at the moment, but that is far from a proper solution. > > Greets, > Jeroen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From dougb@dougbarton.us Fri Sep 30 23:28:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA42521F8B6E for ; Fri, 30 Sep 2011 23:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAjqWnTML0Qs for ; Fri, 30 Sep 2011 23:28:25 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id DCBFD21F8B5E for ; Fri, 30 Sep 2011 23:28:24 -0700 (PDT) Received: (qmail 10087 invoked by uid 399); 1 Oct 2011 06:31:14 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 1 Oct 2011 06:31:14 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4E86B3B0.3050407@dougbarton.us> Date: Fri, 30 Sep 2011 23:31:12 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110928 Thunderbird/7.0 MIME-Version: 1.0 To: Teemu Savolainen References: <1162752405889281096@unknownmsgid> In-Reply-To: <1162752405889281096@unknownmsgid> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 06:28:25 -0000 A qualification there would be reasonable. "For systems where user configuration is possible ..." or something more elegant. :) That said I tend to agree with James Woodyatt that providing a knob to turn it off is likely to lead to the results that he predicted. In principle I really don't like the idea of "forcing it down the user's throats," but I think that the only way it will actually be successful is if they can't turn it off. OTOH, there is (obviously) no way to prevent vendors from providing one, so perhaps what is really needed is a discussion of the merits of both options. Doug On 09/30/2011 22:25, Teemu Savolainen wrote: > I object MUST for configuration option, as for some class of hosts, > like embedded systems, it is not always feasible to have such settings > supported. > > Teemu > > Sent from my Windows Phone > From: Brian E Carpenter > Sent: 28.9.2011 3:16 > To: Jeroen Massar > Cc: v6ops@ietf.org > Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs > WGLC] > Marc, > > On 2011-09-28 02:57, Jeroen Massar wrote: >> On 2011-09-27 15:53 , Marc Blanchet wrote: >>> Le 2011-09-27 à 09:47, Marc Blanchet a écrit : >>> >>>>>> I would like to see a knob that would have the possible values as: >>>>>> - default (HE no pref between v4 or v6) >>>>>> - v6 (HE does pref v6 by some minimal increment) >>>>>> - off (disable HE) >>>>>> >>>>>> The way to implement this might be: >>>>>> - off: value = 65535 >>>>>> - default: value = 0 >>>>>> - v6: value = number of ms "advantage for ipv6" >> [..] >> >>> btw, I can provide text if there is support in wg for this idea. >> >> I would say that it is a great thing to add, but just an on/off is >> already good enough from my POV. > > I agree; maybe on/off as a MUST and the ms of bias as a MAY? > > I don't see anybody opposing the general idea, anyway. > > Brian > >> >> The above proposal would give the advantage to be able to easily >> distribute a site-wide (given that one control all the hosts involved) >> bonus for IPv6 in case a site is connected over a tunnel or other >> mechanism which causes a bit more latency on the IPv6 side. >> >> The other way to counter that disadvantage is just delaying IPv4 packets >> at the moment, but that is far from a proper solution. >> >> Greets, >> Jeroen -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/