From nobody Mon Oct 1 00:38:23 2018 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 BBC9E130DEB for ; Mon, 1 Oct 2018 00:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_MONEY_PERCENT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4cv4y7GrSXn for ; Mon, 1 Oct 2018 00:38:19 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC2912F1AB for ; Mon, 1 Oct 2018 00:38:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w917cHk6025923 for ; Mon, 1 Oct 2018 09:38:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0AA71203227 for ; Mon, 1 Oct 2018 09:38:17 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 00094201403 for ; Mon, 1 Oct 2018 09:38:16 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w917cGSB000304 for ; Mon, 1 Oct 2018 09:38:16 +0200 To: v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> From: Alexandre Petrescu Message-ID: Date: Mon, 1 Oct 2018 09:38:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 07:38:23 -0000 Le 28/09/2018 à 19:47, Lee Howard a écrit : > > > On 09/28/2018 01:01 PM, Alexandre Petrescu wrote: >> For me it looks quite challenging to develop a meaningful vision in >> this space. >> >> On one hand, this Internet witnesses fast digital evolutions, and >> disruptions, every other day. On another hand IPv6 overcoming IPv4 >> seems to advance very slowly. On a same timescale Windows leaped >> from 95 to 10, while IP still steps from 4 to 6. > Windows 95 was a significant rebuild over Windows 3.11. Each of the > next several versions were incremental upgrades, and all were both > forward and backward compatible. > > Meanwhile, lots of work had to go into making IPv6 deployable, and it > didn't really start until 2011. In that time, Windows has evolved > from Windows 7 to Windows 10 (skipping 9, so only two desktop > upgrades). > >> >> In that sense, I think IPv6 and IPv4 side by side as a double stack >> is still a viable evolution in the next decades, although not very >> fancy. The translation from one to another seems like an artificial >> path that keeps reinventing itself but with no clear advantage of >> one translation mechanism over another. These IPv4-IPv6 translation >> mechanisms are like satisfaction for our needs of getting there >> faster. > > How does a network run dual-stack when it's out of IPv4 addresses? If > it buys addresses, why does it run dual-stack? Because it wants to run both versions: one for the near term and one to be future proof. > I guess you consider IPv6-only plus translation to be dual-stack? No. I consider simultaneous IPv6-only and IPv4-only (as far as 'simultaneous' and 'only' can be in a same phrase), i.e. 'double stack', to be a perfect migration mechanism. In other words, I do not consider any form of translation or tunnelling or source routing to be good enough for long term migration from IPv4 to IPv6. > Agreed, for now different people are choosing different mechanisms, > and there isn't yet a clear winner. > > >> >> (but I also speculated at a time that Twitter would disappear in >> its infancy because finger existed - the reverse happened; I also >> speculated that iPhone 4 would do _only_ IPv4 and iPhone 6 _only_ >> IPv6 - it did not happen). > > I haven't seen finger enabled on a system since 1992. Right, :-), IIRC it was disabled because of security risks of fingerd. Maybe the comparison is too far-fetched. >>> In other words, the development of the technologies implied by >>> IPv6 took almost as long to develop as the technologies required >>> to use IPv4 (and involved a few mis-steps). However, the impetus >>> to use them was much lower - whenever a technology was >>> unavailable to make IPv6 work, "well, you can always use IPv4". >>> IPv6 didn't become "important" until "always" became untrue. That >>> started in 2011, when the IPv4 address space available from the >>> IANA (and eventually the RIRs) was depleted; it is becoming >>> increasingly untrue as the cost of purchasing an IPv4 address >>> spirals upward. >> >> I would like to react to this. >> >> We should reckon frankly what happened with this depletion. It has >> been hugely advertised. It is a few years now. >> >> It depleted. But it is still possible to get IPv4 as long as the >> unused space gets back. > > At about US$20 each. 20 american dollars an IPv4 address, hm. Informatively, apnic.net seems to be an order of magnitude lower: 2 australian dollars for an IPv4 address in a Class C, with membership. Their formula, as expressed in the URL below: IPv4: AUD 1,050 x 1.308 ^ (log2(2^(32 - requested_plen))) - 8) IPv6: AUD 1,050 x 1.308 ^ (log2(2^(57 - requested_plen)) - 22) http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=%2F24&ipv6=&action=Calculate >> We can talk about refuelling IPv4. >> >> Maybe we need to wait for several cycles of depletion-refuelling in >> order to sense a stronger need of IPv6. > > > Right now, the cloud and CDN companies are essentially all of the > IPv4 demand. In terms of number of addresses and dollars spent, they > are more than 90% of the market. The CDNs are mostly okay in IPv6 > support, even if they ingest over IPv4. The cloud providers are in a > pile of trouble. AWS is way ahead of anyone else for IPv6 support, > and last I heard they're still buying IPv4 addresses to make sure > they have enough cushion. Azure can do a VM or a Load Balancer, but > not both, which is more than Google Cloud can do (only LB). It's good to know. Last time I checked Azure had IPv6 access with API ok, but login was mandatory through IPv4. > Oracle will allow you to open a ticket requesting IPv6, but unless > it's a Service Cloud, they'll close the ticket with no action. > Alibaba promises an IPv6-only cloud by 2025, but so far has nothing > but dreams. It's good to know. > Something like seven years ago I predicted 500M IPv4 addresses in the > market. About half have moved, but the market didn't really get > moving until about 2015. It's important to note that large net blocks > are valued by large companies: nobody wants to manage hundreds of > /18s. Unless the US government/Department of Defense releases several > /8s, the high end of the market is all but gone. Yes, there may be > thousands of /16s still available, for over a million USD each and > rising. > > 2018 has seen an inflection in pricing. But of course, nobody knows > what happens next. My concern is that instead of "permissionless > innovation" the IPv4 Internet will require significant capital just > to get connected. Could be. Could be too something about the point you mention about difficulty in managing hundreds of IPv4 /18s. In new network management tools Fragmentation could be programmed, like in disk 'defrag' tools, or like in software managing the Fragmentation headers of IPv6. > We're also on track for 50% of the world to reach Google over IPv6 in > two years. Several mobile networks are already IPv6-only internally, > and several large landline ISPs are either there or on their way. YEs. I am also happy to report that from my lab's perspective the IPv6 RTT to google is - now for the first time in months - lower than on IPv4 than on IPv6. (it's not a huge difference, but it is lower: 10ms vs 11ms) That could be an incentive. > So, what do you advocate we wait and see? For my part, it is a little bit to wait: wait that users ask for it, rather than enforcing it on users. > How long should we wait, and what are we looking for? More > importantly, once we see it, how much time will we have to do > something about it, and will it be enough time? YEs, I trust there will be enough time to react when a massive need for IPv6 arises. I base that on the experience on seeing people routinely fixing huge security problems in matters of days, the Y2K fixing was a matter of months, turning on IPv6 on some large datacenters done quickly, and more. But yes, preparedness is very good. Alex > > Lee > >> >> Alex >> >>> >>> "Pick something else" - I have to wonder what "something else" >>> might be in view. We have a number of research projects on the >>> table, such as ICN/CCN/NBN, and they likely have their uses. But >>> I don't see the architectural or business implications following >>> through; if they were rationally available, they would have >>> started a decade back, I suspect. So I see IPv6 deployment as the >>> only rational option on the table. >>> >>> >>> What I am increasingly hearing from ISPs and other networks is >>> that it is less expensive to deploy an IPv6-only network with (or >>> without) an IPv4 overlay than to deploy a dual stack network. >>> There are a few networks that have drawn that conclusion; as more >>> and more do, IPv4 will become less of a requirement. >>> >>> I'm not sure what to expect next, and maybe people can inform me. >>> One option would be two networks that implement IPv6 natively and >>> IPv4 as an overlay service connect, meaning that the address of a >>> 464XLAT PLAT (or whatever) from one carrier is an address in a >>> different carrier for some part of one of their networks. Or, >>> maybe, a network simply stops providing an IPv4 PLAT or other >>> support for IPv4 as an overlay. Maybe they are running lw4o6 and >>> it becomes necessary to do IPv4 routing inside that overlay, so >>> that they want to charge for it as a service. The obviously >>> implied next question is "when" - I'm guessing early 2020s or >>> something like that. >>> >>> >>> So, what do I expect the next few years to look like? I see >>> three broad classes of ISPs, IXPs, and networks at the edge: >>> those that see IPv6 as the least expensive endpoint and drive to >>> that end, those that have enough IPv4 for the moment and aren't >>> thinking any further ahead than that, and those that are balanced >>> on a knife's edge in between. We have those now. I expect to see >>> a shifting balance, with different markets adopting different >>> perspectives and changing over time. I see a slow but definitely >>> discernible motion from "IPv4 works" to >>> "https://www.youtube.com/watch?v=_y36fG2Oba0" "I suppose we ought >>> to give it a try". One at a time, I hear operators say "I don't >>> want to buy any more IPv4 addresses". The networks that are fixed >>> in the "IPv4 laggard" camp tend to be networks that aren't faced >>> with IPv4 address purchases and ask for a business justification >>> that doesn't involve a monetary outlay. >>> >>> Ron, Lee, and I asked for a change to the v6ops charter to >>> discuss IPv6-only networking with that in view. What I want to >>> see in v6ops is more of that - lets move IPv4 to an overlay >>> service, and watch it become less relevant over time. >>> >>> So I personally expect transition technologies of various kinds >>> - lw4o6, 464xlat, MAP-E, MAP-T, and so on - to remain important, >>> but I expect that they will become the aftermarket more than the >>> market. If cloud services are accessible by IPv6, I expect >>> residential access to become IPv6 service to become larger and >>> IPv4 to become smaller. If you want a picture of that, look at >>> Trinidad and Tobago. As I understand it, there are some services >>> (Google, Facebook, etc) that only offer IPv6 access there, so the >>> "IPv6" picture is a picture of their market dominance. >>> https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=TT >>> >>> I expect service providers to do as little with IPv4 as they can >>> get away with, and for IPv4 to increasingly become ragged around >>> the edges. There are still a variety of places where I would get >>> tarred and feathered and sent home wearing a barrel for saying >>> that, but the SNA people were of that opinion too - until APPN >>> made SNA networks irrelevant and people started deploying >>> IP-native applications. >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >> Victorious warriors win first and then go to war, >>> Defeated warriors go to war first and then seek to win. Sun Tzu >>> >>> >>> >>> _______________________________________________ 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 nobody Mon Oct 1 01:22:27 2018 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 DE23D130E0F for ; Mon, 1 Oct 2018 01:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp2ncKwHEmgr for ; Mon, 1 Oct 2018 01:22:22 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626F6130DF9 for ; Mon, 1 Oct 2018 01:22:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 75997AF; Mon, 1 Oct 2018 10:22:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1538382138; bh=ijKsmPi3MPOoLI3vtjk1LIJYTi6Km4hGx1axr7sFJz4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=e1zCj+DRirICb2p++6xF3s+dIq+PiqXkLIj1If/Lm+sAyvdZZnCP2c6pO/TTtlWv4 yfMcJDTqFIDke/qoE1pAi76j+fR4cn/Ge7+Q1oYZfiGYi7xPUxVlh5Byl2l4ZFlZ/X BaiU4asQ+Sh8Bcr5a0NWCTsvRU6DVsOVhrKtkfXI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 72BA59F; Mon, 1 Oct 2018 10:22:18 +0200 (CEST) Date: Mon, 1 Oct 2018 10:22:18 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker cc: "" In-Reply-To: Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 08:22:25 -0000 On Wed, 26 Sep 2018, Fred Baker wrote: > I expect service providers to do as little with IPv4 as they can get > away with, and for IPv4 to increasingly become ragged around the edges. > There are still a variety of places where I would get tarred and > feathered and sent home wearing a barrel for saying that, but the SNA > people were of that opinion too - until APPN made SNA networks > irrelevant and people started deploying IP-native applications. My take on this is that different things will happen in different markets, and I think you're expectations are correct. We'll see highly standardised sectors choose their access protocols/mechanisms between them and customer device (NAT64 and 464XLAT (or other mapping) for mobile, ds.lite for DOCSIS) and go with that. We'll see markets (differs per country and ISP) where the ISP provides the residential gateway, and they choose some mechanisms (MAP/LW4o6 or similar) for IPv6 only as they see fit when it fits their deployment plans. Other markets will stay in dual stack WAN, probably because they need to support electronics-store purchased generic devices, and they don't control what the customer does with their device. It's not uncommon already with NAT444 (or more 4:s), and this will continue to be common. ISPs will need to provide IPv4 Internet reachability for decades to come, and we'll need multiple ways to do it because of the different sector choices. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 1 10:07:27 2018 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 B6ECA130E77 for ; Mon, 1 Oct 2018 10:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBBxZJJ_MKFO for ; Mon, 1 Oct 2018 10:07:23 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DEF130E74 for ; Mon, 1 Oct 2018 10:07:21 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w91H4xZ7030786 for ; Mon, 1 Oct 2018 10:07:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=gnkGY8CV62oP9VpLeKv2bwy1LAZ6QaiehpZitUmv5RI=; b=qF29MRROekkBEAdsTRw00WDdwHwlTdQefswgrY5tCHnLBKkIA4I2KqEV//NvsnxTy8Bn oziHg1f1kgniej4jS1WJqomRlVUrjzeyFgRsq2jvrqBLMwDn6notmlz9zoZjq+rGVmix d1K5aD4qdlcmIOSoYv4B5IOeLwWP6dCEL1Gvqv3x6gpVUr2gkXY7nhhhm9+lByUYziUf A1bacF1z8MzuhXZRbr2tPYb4R+PFO6Vxk9OHEVCab6i4AmJbrDvIUriEVmBF8LjtTPtA iLLw7gbiMrnnk3ubc8ZHYsg0Q3d4k3mPDuHJcbIT0fvNfEkvTLEpfRPCZK5CV9AcLWet lA== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0083.outbound.protection.outlook.com [207.46.163.83]) by mx0b-00273201.pphosted.com with ESMTP id 2munanraje-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 01 Oct 2018 10:07:20 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4136.namprd05.prod.outlook.com (52.135.199.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Mon, 1 Oct 2018 17:07:18 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::75fa:69d:40a3:e580]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::75fa:69d:40a3:e580%3]) with mapi id 15.20.1207.014; Mon, 1 Oct 2018 17:07:18 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-patterson-intarea-ipoe-health Thread-Index: AdRZqSI4+oRob7goSR+GjzJzdIm+Fg== Date: Mon, 1 Oct 2018 17:07:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.58 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4136; 6:oJpOdRdn/bJmfYGocY+cJJhYvir+SGDL7/kB/3LZYl44pSGa+7YKBqLazRW8zKVItRgeaOTpg1KaNycH0GUOo9LIvaHbPB5yCqAshBmD3rOUIqo4bNcnaFFgRqkqqJ/zHW/edwxMRcz7kqlh9IwC6kRFBuo61mGsZ8ISMcvG7G7EVjiJZ7zJ1r/arScuWbUPshOfuYlJGUGS7KPMYesU6SYEz7GpFtNL+DpAqNznoMxXisZ8tRsEurxpU5EN/TzX6jZoGrv2ONE6TjIqWTemJTrT4sN3Iq2mLZTmsNQrPheJvezVrR7IE5PIIhThNT5vrdY/OgvVNhqtHtQN1m+PoMJIbBjIoRlGHXBMuvWk0G3faJiZThn/NyAFIrqT6rv257wURuXNX/WON2rD/hqsWys6T6S4p0m9wlk2yMihvVhAwcszNagagrX4WLabOBk+EPQ7mNeTLkCEjzG+YVQRrg==; 5:Te7lQcyrs8SoJwY9mc05DbI3UFsaA46uE9fzefy/CHf0H4EAsnR9ckSGSI8gW96PHhLdy+d2P+zQtRTXI24sTibwzowqPUdF7pS6eQwDKj5eyFUQ+cxWym5yCTAXCob+c76sh3ZmAZgIQtpyzv6QYYL//Rs5usVzYiTwfcMn7l4=; 7:uQ03i35fCPDGvKJzTsSwLVEs8gFBzMa0Nps7hnGUpDTooGRoufGgYcNdiX+OQSxBeLGHJQ5Srxh8W0g1HrxeSIhOEC6K4iFCQhSAP0lcqqHtgay8z8iIVdB5CaXmEmoVQFy7mMWqUNTXsNXv20CSo/61syglCCfY1NyUSne0VOU/GGaKNcI6zEEAV4crnJ6rOkPyGHYTOsRk3iODPHR3P3Qijy0KxTDbvnZ7Xfpk0Q9PzBO/WaarRQhAlJpPgc0G x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 44834173-c601-4106-a3ae-08d627c05816 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4136; x-ms-traffictypediagnostic: BYAPR05MB4136: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231355)(944501410)(52105095)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699051); SRVR:BYAPR05MB4136; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4136; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(39860400002)(376002)(396003)(199004)(189003)(53936002)(55016002)(478600001)(256004)(86362001)(34290500001)(99286004)(6916009)(25786009)(33656002)(7696005)(105586002)(8676002)(5250100002)(97736004)(106356001)(6506007)(2351001)(26005)(81156014)(2900100001)(81166006)(102836004)(68736007)(186003)(486006)(8936002)(2501003)(558084003)(66066001)(7736002)(14454004)(71200400001)(305945005)(3846002)(6116002)(5640700003)(9686003)(6436002)(476003)(74316002)(5660300001)(2906002)(316002)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4136; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: w2ip1zrQoyGqY0wICpK/q8toHTmExS3GDj1kRozXL82HanQAMWHQoGOXZgo4fKwzhm7gzz+55IVl4++dz30+F3pBpTnA6PyNMy0r7zKlaCCHFsapOpKwltmXwToM1gUioxmQqPxtzotmw3y9AT1/tlmafuw95DtxbFNVDznNAsYFWXbt3mx36OxcYUHgMfg7f4JSfca1t+KQqV5M0WYW3SGBhuNLulJY1KuhoRQnr9nFSOcV5FRBE5idOqBM7qnYL7Fg0BBP+hnimXgAF6oM/t8qKffZsfaXY2dn2tB4B5P537v2JQCoFVAQ/YaWBHA8x1ZvaaKfOKhBT91cxtdwpXhRcu/j/F/gUFSeP5oe2Ys= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 44834173-c601-4106-a3ae-08d627c05816 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 17:07:18.3045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=513 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810010163 Archived-At: Subject: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 17:07:26 -0000 Folks, Each week between now and IETF 103, we will review and discuss one draft. This week, please review and comment on draft-patterson-intarea-ipoe-health= . Fred and Ron From nobody Mon Oct 1 10:34:54 2018 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 DF5C5130DC7 for ; Mon, 1 Oct 2018 10:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zULd56MnuJj9 for ; Mon, 1 Oct 2018 10:34:48 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DA1124D68 for ; Mon, 1 Oct 2018 10:34:48 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id h6-v6so6803999ith.0 for ; Mon, 01 Oct 2018 10:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IYQ5kWg9xKs4nhWhMVV4Ujs25XREmUKpzRLMVrjLFxs=; b=VN9SuQKdtT8maoA08JHkn9VQRS+9LjWlKeWMx1MCfrVDAB2nVsecySi3NphUIqQO/0 aA56DMvx6q24evtwv08BQxzk4N3wpgM9WchOfRKHVBAq80i5Gq1R918FTNSj3uqp7SS9 tJtHWUCDeBIu/4GWbOHhEzdLWfnx7UJjvB9ka1s69I03CbpglkPphfm2WUEXJzqkLS8o /MQxS5LpZmM8gbxSoW2sRAEtaLDhtGMvmKyFGNP5UOc0X0ko5gL8J1VBsC2J7HMkHL0/ 6SeZe2U/fo8BvpCcP1o8R4sIzcsKWDwyEoq8WHSTyrqMsT7pfAaKXLXyV1Jq3p9iCZ2G 8dIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IYQ5kWg9xKs4nhWhMVV4Ujs25XREmUKpzRLMVrjLFxs=; b=Ry4ZZ984BSuYFBDE7nm6Ep9mxGk3xZyNlr4Fbi9weBI+cRRa7e/zToitbLgWcJStvX AVziZlUb5PM7N5VTkaU2Is0DaGzXZbdKwlZhkOcZvFGcEI5+HFRmRttoY/8yFEKBeIGm 34yVRRYlpXm1UbU+044qNo8QbM6D7c8PCPBhZSr9gls2ts8Ys4SnXgPeF6x9U46Q9PoW TFdgIt8NPFLkT18wb1IGCToyHLPLjYYDr44WSjkSCmKyAFcWgyd/+tKpamDg+jXKiaWS bseSFTnOpFH8SbSfWV27U8H8E8d7XP4y92b7TJKitSda8Ba7PYuenPDhrHcQ+dE8qjZz b90g== X-Gm-Message-State: ABuFfogx0FAAj4mO10aq6OK+Wv5y5HTtGImkPDr0gIWs17gOEL+xrJfK EJR9meJwtAQ3OPy7u+7wz3/ab8N9+pk= X-Google-Smtp-Source: ACcGV63hxJUMrizcaRKi3UUFleNIAtKla0Ku8+b/RNd6sxOGUOu5hr067szCftEiQEEMQUppoYhhFw== X-Received: by 2002:a24:d30d:: with SMTP id n13-v6mr11308321itg.97.1538415287620; Mon, 01 Oct 2018 10:34:47 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id 77-v6sm5865782itl.10.2018.10.01.10.34.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 10:34:46 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id z16-v6so4467038iol.6 for ; Mon, 01 Oct 2018 10:34:46 -0700 (PDT) X-Received: by 2002:a6b:9b42:: with SMTP id d63-v6mr7378461ioe.183.1538415285882; Mon, 01 Oct 2018 10:34:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Patterson Date: Mon, 1 Oct 2018 18:34:34 +0100 X-Gmail-Original-Message-ID: Message-ID: To: rbonica@juniper.net Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 17:34:52 -0000 Hi Ron et al. I've actually been sitting on a new version that attempts to simplify things somewhat, after the feedback from IETF102. Revision -05 is up now: https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 Changes include: - Consolidated the multiple behaviours down to one. - Added a Release flag instead of a distinct behaviour. - Added custom IPoE Health Check Probe definition. - Removed ARP/ND and Passive checks. - Removed alternative target address parameter. - Removed IANA registry request for Behaviour values. -Richard On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > > Folks, > > Each week between now and IETF 103, we will review and discuss one draft. > > This week, please review and comment on draft-patterson-intarea-ipoe-health. > > Fred and Ron > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Oct 1 11:00:03 2018 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 30DA9130E74 for ; Mon, 1 Oct 2018 11:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU7P5z_s3T92 for ; Mon, 1 Oct 2018 10:59:58 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EE7128C65 for ; Mon, 1 Oct 2018 10:59:58 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id A809CFECBF82; Mon, 1 Oct 2018 17:59:57 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 9762C6C6887; Mon, 1 Oct 2018 19:59:55 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 1 Oct 2018 19:59:55 +0200 Cc: Ron Bonica , "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <1FA16FCC-0A87-4805-88F6-E84591729309@employees.org> References: To: Richard Patterson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:00:01 -0000 Richard, Nice work. Thanks for writing this up! A couple of comments. Not being particularly clued up on BFD, does BFD echo require a session? Regardless you could just point to section 4 in RFC5881 for the sending = rules. And perhaps emphasize the BCP 38 considerations. Also, how much would you really lose if you left out the DHCP options. = Does this mechanism really have to be configured? Best regards, Ole > On 1 Oct 2018, at 19:34, Richard Patterson = wrote: >=20 > Hi Ron et al. >=20 > I've actually been sitting on a new version that attempts to simplify > things somewhat, after the feedback from IETF102. > Revision -05 is up now: > https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 >=20 > Changes include: >=20 > - Consolidated the multiple behaviours down to one. > - Added a Release flag instead of a distinct behaviour. > - Added custom IPoE Health Check Probe definition. > - Removed ARP/ND and Passive checks. > - Removed alternative target address parameter. > - Removed IANA registry request for Behaviour values. >=20 >=20 > -Richard > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: >>=20 >> Folks, >>=20 >> Each week between now and IETF 103, we will review and discuss one = draft. >>=20 >> This week, please review and comment on = draft-patterson-intarea-ipoe-health. >>=20 >> Fred and Ron >>=20 >> _______________________________________________ >> 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 nobody Mon Oct 1 12:37:02 2018 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 A337B130E19 for ; Mon, 1 Oct 2018 12:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fm3zysJqGaM for ; Mon, 1 Oct 2018 12:36:58 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F22C1252B7 for ; Mon, 1 Oct 2018 12:36:58 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id k21-v6so9959167pff.11 for ; Mon, 01 Oct 2018 12:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fZLIiQycKCu8MqxLIOLUzqewy4obqqyZ1PAxfT4xV0o=; b=q7xSriWWXzCP7texUr9AQFx63ZkH7ZAuAYntm7/3Z55DzTb6pIruHe92yIZmBwMD8P Jg+7utBLxgmz4J2z5Iixx05cz68OSMAGiNiAJzEqHELwrgXWBoiXvEIP5t5ySvXTZFBl gzvIiUhz/J/WjIy+t8I92ffNYhk9KMyFNegM/mnq2VIuEesLhEbCHK+S4TUwRr+0rL2u C4Y3LnjovzvyQyN4IKAOsAq4eKf+62VYjgXh/4EFg0/4EhAbRWlS80IMuyijfYXJNLC+ Nrq+HjA5THs1K3SYC7XavigNo7252vSfQ6eUT2aHQXHcGoOYonR54Ff4+lweKap5522w uNdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fZLIiQycKCu8MqxLIOLUzqewy4obqqyZ1PAxfT4xV0o=; b=A4tVlBOVhp0Hi5DH2nKTdHrCTGG+iha3X7dS9au+fUNxwdwprc5eZ06MAdT/U4prIV T/gjux5zcwFskqTGdm5mrNYOyx4uY7on97i4a2SVuuuR5Yg+aPb5nhUe+3N8iB6Psb4t p6mFsJ/a64cwviyTcqUMSrhv8SssMvSDAddhx+fgPrTAhU58+fMo6UdiUexk4FrOGZrc 97GFwzmsb/YoMAvhyw9btrZawk1pRSQquMGPirZtwJhjT0DIYNawv6N1AVc2whiyFJtf WSHLfUKnLJ5da2L0AP+tw2fdJPy+Hx/0n2x2NtjyWcXi5QOS+d+uSCg+4TaAstmk4u/a KRDg== X-Gm-Message-State: ABuFfogdY2eoxwx1dDYldVHMeb545Ru2dtAHYQiHy5CLrhAUtjlWEfLr vZhkRFXDna8AEhi7cVUm/6TEdWoK X-Google-Smtp-Source: ACcGV62rZU62PlOZZyuXe1CX1hpmhUrCTeiijQlbHam6HSXzMHnos7Kl9anll95oAOFRzzi8jPaKHg== X-Received: by 2002:a17:902:6b47:: with SMTP id g7-v6mr13470349plt.128.1538422617258; Mon, 01 Oct 2018 12:36:57 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id t22-v6sm24627784pfk.141.2018.10.01.12.36.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 12:36:56 -0700 (PDT) To: Fernando Gont , Ole Troan , George Michaelson Cc: "" References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <4645850B-9496-49F0-A284-09E01C0ED820@employees.org> <68a76cb2-911f-186d-dc78-7d6116dcb790@si6networks.com> <21e9805c-7c2e-3261-4bf6-04fb21f60f41@gmail.com> <7cb18f27-159a-ae2e-1ddf-0edbd8e40a4c@si6networks.com> From: Brian E Carpenter Message-ID: <43976396-087e-90f4-119d-b15d05444729@gmail.com> Date: Tue, 2 Oct 2018 08:35:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7cb18f27-159a-ae2e-1ddf-0edbd8e40a4c@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 19:37:01 -0000 Hi Fernando, On 2018-09-29 21:11, Fernando Gont wrote: > Hello, Brian, > > On 09/04/2018 04:03 AM, Brian E Carpenter wrote: > [...] >>> >>>> Any node that emits IPv4 traffic when the bit >>>> is set is either a legacy host or a dual stack host that's not entered >>>> a v6-only mode. So that means it's a host worth checking as part of >>>> the v6-only test. >>>> >>>> **"Dual stack hosts that have a good reason to use IPv4, for example for >>>> a specific IPv4 link-local service, can continue to do so. This is >>>> consistent with the SHOULD language in this document." >>> >>> But... is that IPv6 only? At the end of the day, it would seem that for >>> most home and enterprise networks, you will always have a reason for >>> doing some IPv4.. so I wonder when one would see this bit have practical >>> effect. -- most enterprise and home networks will normally do DNS-SD or >> >> DNS-SD works for IPv6 too afaik > > Appolgies if my comment was misleading/sloppy -- I meant, in general: > they do deal with devices that are IPv4-only. > > > >>> LLMNR, and associated sevices. Also, think about e.g. printers that are >>> likely going to remain IPv4-only till they eventually beak and get replaced. >> >> Indeed. This is a long-term play; I would expect that if the IPv6only bit is >> approved and deployed, it will become increasingly relevant as the legacy >> nodes slowly vanish. And at the end it will become irrelevant again. > > Apologies if this has already been discussed, and I just missed it: > > I envision two alternatives: > > 1) "the network/router knows better", and then reaction to the IPv6-only > flag is more of a MUST (well, could be a "SHOULD", but certainly not > with a clause that is expected to be common.. otherwise it's not an > "exception", but rather a rule :-) ). That way, the flag could > indeed disable IPv4 on the network. > > 2) "end hosts know better", and reaction to the flag becomes kind of a > "MAY". And I'm not sure to what extent the flag will have much of a > practical effect on networks. -- particularly when the hosts don't > really "know better" -- the best they can do is "keep trying"... whether > for actually getting an IPv4 address and/or for things like DNS-SD. Both are correct! That is exactly why draft-ietf-6man-ipv6only-flag-02 uses SHOULD but notes that exceptions to the SHOULD apply in cases where the end host knows better ;-). In fact that's quite precisely what SHOULD means in RFC2119: do this unless you know better. Brian From nobody Mon Oct 1 13:10:17 2018 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 539DC1293FB for ; Mon, 1 Oct 2018 13:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx_5aagpF84D for ; Mon, 1 Oct 2018 13:10:14 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404B21252B7 for ; Mon, 1 Oct 2018 13:10:14 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id v69-v6so4986039oif.1 for ; Mon, 01 Oct 2018 13:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y81H0xz2oYsXLWrERtoLQXz2F8kjm1IJV6cQhx94aVY=; b=UPx2tP+0RLh4byaY4ZthheeltDdWsGBWZyS0VnDHblbiSTkZPFUT6vRJq/z2EHHzEb FaVPrhKANh3fYt77Z27y8N8Voei/M0IcusjB54n/oZWBJzSmTBA4NAMAahy3tnfeNMzu 8GNL84iedpH/8zV03Ap9SNluy9lctUDJzGWOaba54TWV2Gs2txDosLy64SwbQi+ImcJv mqH0aqG/+AqOzxuEldiRoiT7xZQExgkaFIrDGhmShJmnHuoEnuqHC/wEkyRIEADVW6tt XJP7gZtQ/Qx78ONKDhyXiqkqf/2Do6LT+/n8HG+4yIel8uMPmxlDb8p7uAR8Iv+1oX/8 FSww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y81H0xz2oYsXLWrERtoLQXz2F8kjm1IJV6cQhx94aVY=; b=kzmhN1HOWET62Cuqg4Od1wZWe+ulaFjUuBb+F9aw8gobRHtRVOcUYjIt6cdHJep3a/ 2ZNQ9khJ1p/ZtQOiYpCoQ8iaSLrw4a6S6PaiOJAG7vTbl0U/h3jy4Jmff34o6eldNMP2 haeJUizbq69u+7kFTmy38lNd2sz3zlJ/vE4HQD7scJdXchGGKBsG7qMnSN54hTL9CnPE HD0nsbLwwjbxyhIkxL0eeyOLUWRsxO+y4bHkRtkaM859NkE2KUO89N76B/JmGp2ri0Ko jVXXxSwsbrqulJjTK1JKbSF8wqkUZwPlQsgYZ2Ef8T07kZl/U3xcjOeRCoJOTILBtCoW dQVQ== X-Gm-Message-State: ABuFfogrZFdgD/x/Id+mPKFZ5i/ly+Vr53gyUbmKm60VRWmIJhV6YD4S K4611yUVCr3AeBbDebEhARhQY+ShzKLYzOrY99k= X-Google-Smtp-Source: ACcGV628HSbROVBVdoF7fgxqJpbqEGcwukLh910ZCpegFIIdxxuu9tyXPMzNl8q4WQifqBmzNZqs9nEok0/7u+q8kh0= X-Received: by 2002:aca:5356:: with SMTP id h83-v6mr5813389oib.175.1538424613528; Mon, 01 Oct 2018 13:10:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Tue, 2 Oct 2018 06:09:46 +1000 Message-ID: To: richard@helix.net.nz Cc: Ron Bonica , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:10:16 -0000 Hi, I may be missing something, but why can't Neighbor Unreachability Detection be used for this? CE's, because they're IPv6 nodes, would have NUD already built in and being performed because they perform RFC4861 Neighbor Discovery. The Reachable Time and Retrans Timer parameters, measured in milliseconds and set in RAs sent to the CEs, can be used to specify the CE's ND/NUD parameters. Regards, Mark. On Tue, 2 Oct 2018 at 03:35, Richard Patterson wrote: > > Hi Ron et al. > > I've actually been sitting on a new version that attempts to simplify > things somewhat, after the feedback from IETF102. > Revision -05 is up now: > https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 > > Changes include: > > - Consolidated the multiple behaviours down to one. > - Added a Release flag instead of a distinct behaviour. > - Added custom IPoE Health Check Probe definition. > - Removed ARP/ND and Passive checks. > - Removed alternative target address parameter. > - Removed IANA registry request for Behaviour values. > > > -Richard > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > > > > Folks, > > > > Each week between now and IETF 103, we will review and discuss one draft. > > > > This week, please review and comment on draft-patterson-intarea-ipoe-health. > > > > Fred and Ron > > > > _______________________________________________ > > 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 nobody Mon Oct 1 13:14:32 2018 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 58F80130E19 for ; Mon, 1 Oct 2018 13:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta5DbL6Jgdow for ; Mon, 1 Oct 2018 13:14:28 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBA01252B7 for ; Mon, 1 Oct 2018 13:14:28 -0700 (PDT) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 1C8F5FECBF4D; Mon, 1 Oct 2018 20:14:27 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16A366) In-Reply-To: Date: Mon, 1 Oct 2018 22:14:24 +0200 Cc: richard@helix.net.nz, v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:14:30 -0000 Mark, No, NUD doesn=E2=80=99t prove that the first hop router can forward to the d= elegated prefix.=20 Ole > On 1 Oct 2018, at 22:09, Mark Smith wrote: >=20 > Hi, >=20 > I may be missing something, but why can't Neighbor Unreachability > Detection be used for this? >=20 > CE's, because they're IPv6 nodes, would have NUD already built in and > being performed because they perform RFC4861 Neighbor Discovery. >=20 > The Reachable Time and Retrans Timer parameters, measured in > milliseconds and set in RAs sent to the CEs, can be used to specify > the CE's ND/NUD parameters. >=20 > Regards, > Mark. >=20 >> On Tue, 2 Oct 2018 at 03:35, Richard Patterson wro= te: >>=20 >> Hi Ron et al. >>=20 >> I've actually been sitting on a new version that attempts to simplify >> things somewhat, after the feedback from IETF102. >> Revision -05 is up now: >> https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 >>=20 >> Changes include: >>=20 >> - Consolidated the multiple behaviours down to one. >> - Added a Release flag instead of a distinct behaviour. >> - Added custom IPoE Health Check Probe definition. >> - Removed ARP/ND and Passive checks. >> - Removed alternative target address parameter. >> - Removed IANA registry request for Behaviour values. >>=20 >>=20 >> -Richard >>> On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: >>>=20 >>> Folks, >>>=20 >>> Each week between now and IETF 103, we will review and discuss one draft= . >>>=20 >>> This week, please review and comment on draft-patterson-intarea-ipoe-hea= lth. >>>=20 >>> Fred and Ron >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Oct 1 13:17:45 2018 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 46860128D0C for ; Mon, 1 Oct 2018 13:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qx5JRBnc385 for ; Mon, 1 Oct 2018 13:17:40 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B711252B7 for ; Mon, 1 Oct 2018 13:17:40 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id n18-v6so10521638ioa.9 for ; Mon, 01 Oct 2018 13:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lCbi1Z37e7ckoronfCXVcFjiAY+NqxyF+sEcodV2fp0=; b=W/7OaYfUVgAObj6LQH2yEQfGtdttPevi0V1XvsnEpDyudssop1R2dy1SMSMHR1VStX bDGRmtIR2M59yPzDhaquZ3PI0ctjt9DJUuv0VBCObdEKSZ3yO0Fiqpsz3eRbVPkxXDIF B4ubmTIwUgUG/oUopuvUiiUCcWFboeYLM2sgt6/kPeH8vApxqHhFWDdn/bMzCMhq6QAF DhcBEC6OxyTDeRNL1WiDVug8BuhDy0ZjdkPACNIrmwQgQ5i3ZAc6IbIV46RO7Ke8qW2S iUFos4Z7VeN9WCMCclDR0IepWhH3CYPYTWhwhwMXob3uUK81ikvRmw9UBD5qVkGLCS1l 8ppA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lCbi1Z37e7ckoronfCXVcFjiAY+NqxyF+sEcodV2fp0=; b=C+cKTvG++2ZCNMpMYVymaoVsu2wzvCDA1zarY4wDu3HhdBYjkZow7qNTOAKfIvVvqH 8jDPk3tkNjQRjLLmKJlVwcNQkkjJWrHf5Z+BUuK6sojjIjL/Unrk7AsN5hFniBwG7flR xYn07AZ4jw+VasNNt6uYz9Ue6EjEt1c9QMjbErpuFUS7rGR2dlPHiKCk4pVcE7Kz81Ai MEPPx2nY2DJIXV1Lh66Cvky1WpYs97PA6upRpNEW5ecnovgFjeJ2AYSKx0MTOSNzCYmS nyWWrMCmgj529YtBOj2grNyGPW3X7x6rkvEa80on9VLLelXzB2a2y7S7qKBh9MyoYkci l91g== X-Gm-Message-State: ABuFfoiCYDHQ9SW250QQ4IAXQnSoIhW3DuvuMKqTxzbOBIVcJbKWF5k8 HkAmE3xfKpIiTFyXzCn8CgsupEFWTCM= X-Google-Smtp-Source: ACcGV62s6NLw6HUYOxyYEL/xzf2ufn0vE63rFReCaGUbZ+HoP09tiyA81zdhxSi+0yavNNUo1Znx/A== X-Received: by 2002:a5e:8809:: with SMTP id l9-v6mr7789298ioj.272.1538425059696; Mon, 01 Oct 2018 13:17:39 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id b14-v6sm4785800ioh.47.2018.10.01.13.17.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 13:17:39 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id l25-v6so10581413ioj.0 for ; Mon, 01 Oct 2018 13:17:39 -0700 (PDT) X-Received: by 2002:a6b:8e14:: with SMTP id q20-v6mr8373855iod.169.1538425058919; Mon, 01 Oct 2018 13:17:38 -0700 (PDT) MIME-Version: 1.0 References: <1FA16FCC-0A87-4805-88F6-E84591729309@employees.org> In-Reply-To: <1FA16FCC-0A87-4805-88F6-E84591729309@employees.org> From: Richard Patterson Date: Mon, 1 Oct 2018 21:17:27 +0100 X-Gmail-Original-Message-ID: Message-ID: To: otroan@employees.org Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:17:43 -0000 Hi Ole, Actually your two questions are related. The use of BFD echo does indeed require a BFD session to be established between peers. Even though the BFD echo mechanism itself is relatively lightweight, it is for this reason that we don't see widespread use of BFD echo on residential broadband with consumer CPEs. The use of a DHCP option to communicate parameters to the client, also assists in signalling intent to the client. I.e., that health checks can be expected to pass on this network. This is one of the reasons why BFD requires the session establishment. We expect our "IPoE Health Check Probe" to look identical to that specified in Section 4 of RFC5881, save for the destination port. Perhaps it can be an informative reference? Or did you mean we should reference 5881 in our =C2=A73.3 BFD Echo? Good call on the BCP 38 consideration, I was meaning to include something about that and networks with strict uRPF that may impede the use of these "loopback"-style packets after Barbara mentioned it previously. I'll add a section for that. -Richard On Mon, 1 Oct 2018 at 19:00, Ole Troan wrote: > > Richard, > > > Nice work. Thanks for writing this up! > > A couple of comments. > > Not being particularly clued up on BFD, does BFD echo require a session? > Regardless you could just point to section 4 in RFC5881 for the sending r= ules. > And perhaps emphasize the BCP 38 considerations. > > Also, how much would you really lose if you left out the DHCP options. Do= es this mechanism really have to be configured? > > Best regards, > Ole > > > > On 1 Oct 2018, at 19:34, Richard Patterson wrote= : > > > > Hi Ron et al. > > > > I've actually been sitting on a new version that attempts to simplify > > things somewhat, after the feedback from IETF102. > > Revision -05 is up now: > > https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 > > > > Changes include: > > > > - Consolidated the multiple behaviours down to one. > > - Added a Release flag instead of a distinct behaviour. > > - Added custom IPoE Health Check Probe definition. > > - Removed ARP/ND and Passive checks. > > - Removed alternative target address parameter. > > - Removed IANA registry request for Behaviour values. > > > > > > -Richard > > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > >> > >> Folks, > >> > >> Each week between now and IETF 103, we will review and discuss one dra= ft. > >> > >> This week, please review and comment on draft-patterson-intarea-ipoe-h= ealth. > >> > >> Fred and Ron > >> > >> _______________________________________________ > >> 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 nobody Mon Oct 1 13:37:03 2018 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 DFD4A1252B7 for ; Mon, 1 Oct 2018 13:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCevMviZdjMt for ; Mon, 1 Oct 2018 13:36:58 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C93130E19 for ; Mon, 1 Oct 2018 13:36:58 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id n18-v6so10567994ioa.9 for ; Mon, 01 Oct 2018 13:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uvpQyHIz4hf0zvc5ZMMS1wE8oepjkKNmAoXHZXb9mF4=; b=t1KHZTIZ6oLB8QYpktG9m5fAv1WpuMfGWKXPn2yfmwjZIEj4GBERzG6JBNQiFudBC7 dvejg7gaRazMtYaOdl572xNFLiihiRh4dHFNIcjTqjwD0nisTeqAEZX/fcy722te+Yxj N8idZryFrRbMIbKHQ99/ExHRlh5DMScUWEvsELqA7LjAKEdi1BBsoBmid5iV/WrPWJq/ O6T0AEyPG/dooBAV+dgIyDzjVhzhpV/4kgvoHG+zFBIBb9pXnZEc/A/X3X5L1tV2XhVq 9qWUdkKgN7Z6D7szgQtiC/nJMU/vZGSD2jyXdu17N2VpJcl85lJAr8RD3kGPQ2jPrO7Z 9/Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uvpQyHIz4hf0zvc5ZMMS1wE8oepjkKNmAoXHZXb9mF4=; b=HPXVlDflAJOacehzTuWBJbvDcx0AzgMO3zPQ3nutSY1bDFwBf8wqg5IzzbQMMj/js+ HfEm7FyK3sIATsRbN3LwWVLbK5ovJisKd++N3xMUm8+GQ4EO0O1JJzjZESp/7qpGu9We PKgiPIiEaASChUUbeb0gcvn/IH1Rws/RrSXiaUiPZbyWqsjst0cbA8ZBkY3reADneZgt VT2Reh2tEoxIuUvaPwCu0vq5X3MCTLaYyUTPqBmxsQF9LckBaAoMZ1O/tN952mYRPUy8 RF0vOZJ78KBPUT26YCUgGtaxZdRA1A/eqr1HWFHvU1JLjMWmeD4aH6Rh/KZCPJbydYqo bX9w== X-Gm-Message-State: ABuFfohPc0q2NKKv+8lESAn7xp5FMdIjOFBX4CuLDOOyhZaRXNH+DhTS n0cZC2aE9MsJRwvXAsnEtE4TJgQwx2A= X-Google-Smtp-Source: ACcGV61UB13wkMEXaYRObnl1L2CY5cq/TbK19/n3oQ3PnIlXT3ASXgf7VY8GC5yZJtSuMihOQ0hUCA== X-Received: by 2002:a6b:b74d:: with SMTP id h74-v6mr8318878iof.248.1538426217431; Mon, 01 Oct 2018 13:36:57 -0700 (PDT) Received: from mail-it1-f181.google.com (mail-it1-f181.google.com. [209.85.166.181]) by smtp.gmail.com with ESMTPSA id b26-v6sm4804520iod.38.2018.10.01.13.36.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 13:36:56 -0700 (PDT) Received: by mail-it1-f181.google.com with SMTP id c23-v6so169498itd.5 for ; Mon, 01 Oct 2018 13:36:56 -0700 (PDT) X-Received: by 2002:a02:9b46:: with SMTP id g6-v6mr9779140jal.136.1538426216573; Mon, 01 Oct 2018 13:36:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Patterson Date: Mon, 1 Oct 2018 21:36:45 +0100 X-Gmail-Original-Message-ID: Message-ID: To: markzzzsmith@gmail.com Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:37:01 -0000 Hi Mark, We removed both the passive and active NUD checks from this revision to hopefully simplify the draft and make it more adoptable. NUD doesn't give us visibility of the DHCP lease validity or necessarily the subscriber session state. ND packets also tend to have to be processed by the remote peer/BNG, where as a UDP/IP loopback packet can simply be forwarded back to the CPE in hardware, allowing for the more aggressive tuning of timers. Whilst I envision this to be adopted by the individual DHCP clients, it'd be nice if it was the same process for both DHCPv4 and DHCPv6. -Richard On Mon, 1 Oct 2018 at 21:10, Mark Smith wrote: > > Hi, > > I may be missing something, but why can't Neighbor Unreachability > Detection be used for this? > > CE's, because they're IPv6 nodes, would have NUD already built in and > being performed because they perform RFC4861 Neighbor Discovery. > > The Reachable Time and Retrans Timer parameters, measured in > milliseconds and set in RAs sent to the CEs, can be used to specify > the CE's ND/NUD parameters. > > Regards, > Mark. > > On Tue, 2 Oct 2018 at 03:35, Richard Patterson wrote: > > > > Hi Ron et al. > > > > I've actually been sitting on a new version that attempts to simplify > > things somewhat, after the feedback from IETF102. > > Revision -05 is up now: > > https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 > > > > Changes include: > > > > - Consolidated the multiple behaviours down to one. > > - Added a Release flag instead of a distinct behaviour. > > - Added custom IPoE Health Check Probe definition. > > - Removed ARP/ND and Passive checks. > > - Removed alternative target address parameter. > > - Removed IANA registry request for Behaviour values. > > > > > > -Richard > > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > > > > > > Folks, > > > > > > Each week between now and IETF 103, we will review and discuss one draft. > > > > > > This week, please review and comment on draft-patterson-intarea-ipoe-health. > > > > > > Fred and Ron > > > > > > _______________________________________________ > > > 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 nobody Mon Oct 1 13:52:28 2018 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 0FE82130E29 for ; Mon, 1 Oct 2018 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hIh7rK12TdF for ; Mon, 1 Oct 2018 13:52:22 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81818130E26 for ; Mon, 1 Oct 2018 13:52:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EDAACCiLJb/yYyC4dbGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAQGBUYE6KipmbRIoCot/jBmCDXiVYhSBKzsLJQcChD4ChBEhNBg?= =?us-ascii?q?BAwEBAQEBAQICAmkcDIJoLwEBBAcDDC8KAgMBAQEBAQEBJgEBAQEBASMCDzUSA?= =?us-ascii?q?QEYAQEBAQMSKDQLDAQCAQgNBAQBAQEKFBAyHQgBAQQBDQUIGoI0TIIBAQ6cFYs?= =?us-ascii?q?dGgKJdQWLAheBQj6BEkaCFzWDGwEBAgEXgS8CGIMwgiYCnSkJAoZDigaBR4Rbg?= =?us-ascii?q?ncDhjOMDIklgUI5gVVwFTuCbIYChRSFPm8BAYEUikgBgR4BAQ?= X-IPAS-Result: =?us-ascii?q?A2EDAACCiLJb/yYyC4dbGQEBAQEBAQEBAQEBAQcBAQEBAQG?= =?us-ascii?q?BUYE6KipmbRIoCot/jBmCDXiVYhSBKzsLJQcChD4ChBEhNBgBAwEBAQEBAQICA?= =?us-ascii?q?mkcDIJoLwEBBAcDDC8KAgMBAQEBAQEBJgEBAQEBASMCDzUSAQEYAQEBAQMSKDQ?= =?us-ascii?q?LDAQCAQgNBAQBAQEKFBAyHQgBAQQBDQUIGoI0TIIBAQ6cFYsdGgKJdQWLAheBQ?= =?us-ascii?q?j6BEkaCFzWDGwEBAgEXgS8CGIMwgiYCnSkJAoZDigaBR4RbgncDhjOMDIklgUI?= =?us-ascii?q?5gVVwFTuCbIYChRSFPm8BAYEUikgBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,328,1534824000"; d="scan'208";a="299237055" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Oct 2018 16:52:19 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 16:52:19 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0382.000; Mon, 1 Oct 2018 16:52:18 -0400 From: "Mudric, Dusan (Dusan)" To: Richard Patterson , "rbonica@juniper.net" CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] draft-patterson-intarea-ipoe-health Thread-Index: AdRZqSI4+oRob7goSR+GjzJzdIm+FgAJWlUAAALUR/A= Date: Mon, 1 Oct 2018 20:52:18 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:52:26 -0000 Hi Richard, " any indirect upstream network changes are not visible to the IPoE client." "The destination MAC address MUST be address of the upstream router." The scope is only to the first hop router. Can you add an extension for han= dling the uplink failures to ISPs (https://tools.ietf.org/html/draft-ietf-r= tgwg-enterprise-pa-multihoming-07#section-5.3.2)? "If a particular prefix should not be used as a source for any destinations, then the router needs to send RA with Preferred Lifetime field for that prefix set to 0." This event can also trigger the recovery to alternate DHCP server. Please p= rovide the topology where another DHCP server would be. Thanks, Dusan. > -----Original Message----- > From: v6ops On Behalf Of Richard Patterson > Sent: Monday, October 01, 2018 1:35 PM > To: rbonica@juniper.net > Cc: v6ops@ietf.org list > Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health >=20 > Hi Ron et al. >=20 > I've actually been sitting on a new version that attempts to simplify > things somewhat, after the feedback from IETF102. > Revision -05 is up now: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dpatterson-2Dintarea-2Dipoe-2Dhealth- > 2D05&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > UWB8YLZU23029sMQGQ2kY&m=3DpIhtq5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > dBQQX0&s=3DDl_OzZQQbBP_tJdv9RwheV4B4H_MQwxT0kR5Hz9UhXs&e=3D >=20 > Changes include: >=20 > - Consolidated the multiple behaviours down to one. > - Added a Release flag instead of a distinct behaviour. > - Added custom IPoE Health Check Probe definition. > - Removed ARP/ND and Passive checks. > - Removed alternative target address parameter. > - Removed IANA registry request for Behaviour values. >=20 >=20 > -Richard > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > > > > Folks, > > > > Each week between now and IETF 103, we will review and discuss one > draft. > > > > This week, please review and comment on draft-patterson-intarea-ipoe- > health. > > > > Fred and Ron > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DpIht > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > dBQQX0&s=3DXUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DpIht > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > dBQQX0&s=3DXUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=3D From nobody Mon Oct 1 14:15:12 2018 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 AAFF9130EAF for ; Mon, 1 Oct 2018 14:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqE1hLbG-2TL for ; Mon, 1 Oct 2018 14:15:09 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54399130DE9 for ; Mon, 1 Oct 2018 14:15:09 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id m23-v6so14702530otf.0 for ; Mon, 01 Oct 2018 14:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5eFgwxRQjH1iapv1+m+vJPzgC35VEPje5xv69FKWZRA=; b=IRf/vyqWaCvd8Y2Me94Yk4bvmPSU14tiGqx4sTn8F+vUXG3FUxO8yNQt1D2Gv1QZr5 blPJIatZIlH5HaH0bcrnL9OPAmI9nCC6y5CUb4i1Hom1zi9C/Gfkt4pBsLv6m5HbP72z 1J13/EmEoIm87bFH32l9/9A1kC9t/9Edql5FmRnM/Iw58k1d1rlv/C9K42DtQzGkgw2t kUT0abhmzNRbd8rKpyWQItQyBu3jykzcKNz2N1yuC0QghzKu7emgREDmUE57XV3QGp/S ZokDvxSG3yL8fv8waXtPRYC4R9r2dhW30ojcQNpoeSccXwC/CmKJfSKqlYp5YvbKST79 EQkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5eFgwxRQjH1iapv1+m+vJPzgC35VEPje5xv69FKWZRA=; b=hX4NmUPIe+yUuIAAjaYmsDmf6snzIQ2cdOLVRDg0+K74HWkVqhSwYvtWTdsRZu5T52 /hiW+t1xBUfjDYJwnDVcnQ5D2JBZKOOmPqQqLpWJHnZaVXbJiqnlpT3wykK+U7gEtFEd WWiZYjYe3b05RolEJNFK3nAQlw23FPVLZ0ZkjjbIVki6yj/KkuaOOXscyGyVcPYyH1Yk +XnmaQ27uHL7PoAf90gJlQFyCXEOMLXFHhi5XG+y2H6g0yCNBsz9k46r+l25AmuyTJaH xJc3DlnYDsyBkPBQofYbmQ9xT8ouiw9hznBaI6Gn4Wu2KxijPvLLSYvvGH0KMV0Z7JA6 rwBQ== X-Gm-Message-State: ABuFfogD/14xt9VjmU84mCx+n8nrsTP3594cVVB/2R5iTZjcQ9urfn3/ 3g/qOGxKABL/TPhj8MQ3jeSTmZjUyTgIwpvrrOU= X-Google-Smtp-Source: ACcGV60NuhmSYAHU/tLr8rLVqJLJ6rQRRD3kxFqgoCePYW+VONTddLhyhd2zIxFy1fUnkoAsR3+qOtgt/sfBx8VXUzM= X-Received: by 2002:a9d:550d:: with SMTP id l13-v6mr6937022oth.83.1538428508452; Mon, 01 Oct 2018 14:15:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Tue, 2 Oct 2018 07:14:41 +1000 Message-ID: To: Ole Troan Cc: richard@helix.net.nz, v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 21:15:12 -0000 Hi Ole, On Tue, 2 Oct 2018 at 06:14, Ole Troan wrote: > > Mark, > > No, NUD doesn=E2=80=99t prove that the first hop router can forward to th= e delegated prefix. > The ID's Abstract and Introduction is saying that the problem it is solving is the lack of a PPP keepalives equivalent in an IPoE environment, and PPP keepalives don't solve that problem either*. I'd expect if delegated prefix forwarding validation that was the focus of the ID, a simple text search for "delegated" or "PD" across the whole draft should find something, but neither do. If that's the problem being solved, then it isn't very clear from the current text. It seems to be more focusing on direct CE to BNG liveness testing. Regards, Mark. *Technically there is, the Ethernet II spec. specified an Ethernet Configuration Testing Protocol, which all Ethernet nodes were supposed to implement (and traditional Cisco IOS does - type 9000 frames). > Ole > > > On 1 Oct 2018, at 22:09, Mark Smith wrote: > > > > Hi, > > > > I may be missing something, but why can't Neighbor Unreachability > > Detection be used for this? > > > > CE's, because they're IPv6 nodes, would have NUD already built in and > > being performed because they perform RFC4861 Neighbor Discovery. > > > > The Reachable Time and Retrans Timer parameters, measured in > > milliseconds and set in RAs sent to the CEs, can be used to specify > > the CE's ND/NUD parameters. > > > > Regards, > > Mark. > > > >> On Tue, 2 Oct 2018 at 03:35, Richard Patterson = wrote: > >> > >> Hi Ron et al. > >> > >> I've actually been sitting on a new version that attempts to simplify > >> things somewhat, after the feedback from IETF102. > >> Revision -05 is up now: > >> https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 > >> > >> Changes include: > >> > >> - Consolidated the multiple behaviours down to one. > >> - Added a Release flag instead of a distinct behaviour. > >> - Added custom IPoE Health Check Probe definition. > >> - Removed ARP/ND and Passive checks. > >> - Removed alternative target address parameter. > >> - Removed IANA registry request for Behaviour values. > >> > >> > >> -Richard > >>> On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > >>> > >>> Folks, > >>> > >>> Each week between now and IETF 103, we will review and discuss one dr= aft. > >>> > >>> This week, please review and comment on draft-patterson-intarea-ipoe-= health. > >>> > >>> Fred and Ron > >>> > >>> _______________________________________________ > >>> 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 nobody Mon Oct 1 20:13:19 2018 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 706DA129AB8 for ; Mon, 1 Oct 2018 20:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKmpcISJW-Hd for ; Mon, 1 Oct 2018 20:13:16 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A70127B92 for ; Mon, 1 Oct 2018 20:13:16 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id 63-v6so406976ljs.4 for ; Mon, 01 Oct 2018 20:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IeUSCyjm4N3KvDNHm66xUEAOb7Im5u4CS5uYqx0Lzdw=; b=gH+OE28uqa7bgrFW5S4BBkxOGi4bRKVRxgkMy7fdpD34vCCFA1T4iaz1tPZoREgH7B 6TW+24p/Ld5Bs9asxZ5bWIWmHI4tZuL8k97l+o8uFY4Cw9S12mv+DjJ3NpLF2l/f2QtT slywsFHk5imD1Qi6cVKCpVvr4/sTmSMKEG6DMEHFqeC6TxPrdlQ49KkjgfsJFYTamWBJ Xl+/rGpvrlU7CrEKyJNiXb7J1/lRvpF8HU7kwwYH0RK90DTSYaoADmDvWupU2Brtihlt BC8MV3HOwllEQJkhqLN8pRZrdfYMJ9/3Gk3r7MAvktImu2gKsmaMDxWNARnvRMw7xSde RMlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IeUSCyjm4N3KvDNHm66xUEAOb7Im5u4CS5uYqx0Lzdw=; b=WWXPunV9sTDy7LiNELAx5pJ120mb3eaa27NJan50p7l5W7zo188pxrwXY4HzDb8+eD NDq0K5Ccxvdkkazd+FUchgRsx4y8M7Ug+mAK0EEe/Jt4ZzEracDs2jzzy0pN/o/9KSxu zHXUEvFotmto/t/Z08dzY0EGDZztkudvG+Nrelp/q02NZ89Shb3H5HEBAF7IdabntjfW F4GbIE4p450OXrf6nESUBnGmcWaLRF2YW4FBkTFzCyyCwfVkAb+YVkg64hrN0vjyu7mO NFHuLE3T0k9ZLfRfaWBbTv8SFI28FFrktaCOmPD809T4l6xnn+7dyN1E2br0IdMd/xFm CUaA== X-Gm-Message-State: ABuFfoht1Ur6Ofa5XjuDpixXouooL0oXoopPqMjfmd2laLxQIRavzAjo dGgTubpZj3mRBnpHcs2ZTFk6fbk/Zf7nk8OHOjk= X-Google-Smtp-Source: ACcGV63Lw23w6pl2pnqrXPq9EQOrxLjQtvEvdeop3Kn0gnwbV2CUwfxujPS6ocdg6CDKlUMe+EugG3cbwBq9rXl1RlI= X-Received: by 2002:a2e:2f1b:: with SMTP id v27-v6mr2355173ljv.31.1538449994506; Mon, 01 Oct 2018 20:13:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Tue, 2 Oct 2018 13:13:02 +1000 Message-ID: To: nick.heatley@bt.com Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 03:13:18 -0000 Hi Nick, Thanks a lot for your comments - sorry for delayed response.. On Fri, Jul 27, 2018 at 7:15 PM wrote: > This is valuable, thank you. > Where is it best to capture "Implementation considerations"; something like section 6 of https://tools.ietf.org/html/rfc8106 To be honest I'm not sure it should be in this draft. I might be wrong but as long as the document describes the host behavior, we shouldn't be prescribing how exactly such behavior is implemented. > IMHO it would be beneficial to capture these aspects: > -Pref64 "Repository management" See my comment above. > -Handling multiple pref64 from different sources > -Handling RA updates on multiple interfaces > > There are security implications of having multiple pref64 sources, would that be in this paper? > Multihoming needs some consideration. Regarding the CLAT or other user function of the pref64, will the function be of global scope or would multiple functions be in play e.g. per interface. Good point. We've just submitted -02 version https://datatracker.ietf.org/doc/draft-pref64folks-6man-ra-pref64/ which has a section discussing multiple prefixes from same or different sources as well as multihoming. > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova > Sent: 20 July 2018 16:26 > To: V6 Ops List ; Mohamed Boucadair > Subject: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded > > Hello, > > As it's been mentioned at the mic, the -01 version of > draft-pref64folks-6man-ra-pref64 > > https://datatracker.ietf.org/doc/html/draft-pref64folks-6man-ra-pref64 > > Feedback is appreciated. > > In particular, Mohamed, may I ask you to review the new text and let us know if it addresses your concerns? Thanks! > > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- SY, Jen Linkova aka Furry From nobody Mon Oct 1 20:31:08 2018 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 3D60012872C for ; Mon, 1 Oct 2018 20:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGff87HANyYN for ; Mon, 1 Oct 2018 20:31:05 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F678127B92 for ; Mon, 1 Oct 2018 20:31:05 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id c85-v6so1677580itd.1 for ; Mon, 01 Oct 2018 20:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i43qzCx9cb0taDGkq7Z1M39PrW/wSthMJmI8wvtsx14=; b=QK3BaeWotzG2iii5fT5ZK0DeoN1e8GqiyVcenuGRqWs9mDrHXtQKQYc5QRR8PUryCj doPE1D5jMb+Mh9vqApzYi8l6Pofv96z7IJC+q2OPMCL6QmaDv7fqGq6UPT9bFLRB2MXf hD4H827E6mOi++RZeWxElW0Zf3SW9dbOfqp3v1rkqeQdAL/hkGES+InEt5FOo3RQKMEu hUDdGauS1fyhg7utBKYjBR6IP+iZLE+pWXu0KDyV3InjJr/wS18JeB3A4/tDgLW/EwUT /qzquNx86H/UO5Fp0a+HlUhOtZMRlRVUamuL0nUdu37JiG8AmhLkTAL1Kn0sj4eHKUX8 L+OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i43qzCx9cb0taDGkq7Z1M39PrW/wSthMJmI8wvtsx14=; b=qxHivOdBUQ5mT43y/wuM97OCiHctoc53QhcLrm1PfC43wPg5VxcKAG7ZNj9Ydv0Mu7 i5Soa2bpHuNWmDCeteQQJHPg+Yh/EK/yWpvSVWaYTV/uCpTR84C2711OUhX/FDh1rDWm Eqs1yyB465kbZGFVzzRvAXNcsRxWKZJ+234JuKP3/PwzduMb5tJuoXOYMtk+4WT+dnIo Hvxb/SWptpreTJV37CbWR5iO8AajPAmRRh/n0Md+cC6pvVB+NtU/JEhk0ylONh1zDm5T SUjPJsXonBxYkgWb19tEKD+szUJ0buYzvsZobmvDjHkVG9nTA8mI4XHkKsLwWfGIbHJF Uwmg== X-Gm-Message-State: ABuFfojDf1ChZmym9A4CWa4iY92oP6gut2Ma3SxUit7VI7odxr2kUBc6 YX82ztfiZoHhQ9W4Rsv9Wn2Yt35fasDi172Zk5iKyg== X-Google-Smtp-Source: ACcGV61Sf1rmbQSCKtvZr4d6KDUfVp+k97EmUH01DZQ7NUPtiIEGqmR2n78oSslj3JlAQeCKLBw09d3e/nPdpya0D9E= X-Received: by 2002:a24:5248:: with SMTP id d69-v6mr679062itb.57.1538451064473; Mon, 01 Oct 2018 20:31:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 2 Oct 2018 12:30:53 +0900 Message-ID: To: Jen Linkova Cc: "Heatley, N, Nick, TQB R" , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000034492c0577368d7b" Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 03:31:07 -0000 --00000000000034492c0577368d7b Content-Type: text/plain; charset="UTF-8" On Tue, Oct 2, 2018 at 12:13 PM Jen Linkova wrote: > > This is valuable, thank you. > > Where is it best to capture "Implementation considerations"; something > like section 6 of https://tools.ietf.org/html/rfc8106 > > To be honest I'm not sure it should be in this draft. > I might be wrong but as long as the document describes the host > behavior, we shouldn't be prescribing how exactly such behavior is > implemented. > As a host implementer and an author, I think it's actually not a good idea to specify the implementation in the RFC that defines an option. There are many cases in the IPv6 specifications where the lack of implementation experience meant that some of the details of the protocols were overspecified and required an RFC update to fix. The one that happens to come to mind at the moment is RFC 7048, which was required only because NUD probing strategy was too strictly specified in RFC 4861. But RFC 8106 itself is another example: because it doesn't allow for any sort of multi-PVD operation, its guidance on a multi-PVD host (like pretty much any mobile OS today) is at best confusing and at worst incorrect. RFC 8106 regularly refers to "the resolver repository" as if there were only one of them, but a multi-PVD host cannot have only one resolver repository. So I'd expect that the popular implementations of RFC 8106 (at least the ones on mobile nodes) all actually violate the letter of the implementation considerations. Instead of writing implementation considerations, we should focus on observed behaviour. The version we just uploaded contains some text on that already; please look at it and see if you think there are things that it should clarify or further specify. --00000000000034492c0577368d7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 2,= 2018 at 12:13 PM Jen Linkova <furr= y13@gmail.com> wrote:
> T= his is valuable, thank you.
> Where is it best to capture "Implementation considerations";= something like section 6 of https://tools.ietf.org/html/rfc8106<= /a>

To be honest I'm not sure it should be in this draft.
I might be wrong but as long as the document describes the host
behavior, we shouldn't be prescribing how exactly such behavior is
implemented.



--00000000000034492c0577368d7b-- From nobody Tue Oct 2 00:05:18 2018 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 35129130DC6 for ; Tue, 2 Oct 2018 00:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k25HGxyFZeTT for ; Tue, 2 Oct 2018 00:05:07 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852AD130D7A for ; Tue, 2 Oct 2018 00:05:06 -0700 (PDT) Received: from tpw09926dag17h.domain1.systemhost.net (10.9.212.41) by RDW083A011ED67.bt.com (10.187.98.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 2 Oct 2018 08:05:33 +0100 Received: from tpw09926dag11f.domain1.systemhost.net (10.9.212.19) by tpw09926dag17h.domain1.systemhost.net (10.9.212.41) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 2 Oct 2018 08:05:03 +0100 Received: from RDW083A010ED66.bt.com (10.187.98.36) by tpw09926dag11f.domain1.systemhost.net (10.9.212.19) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Tue, 2 Oct 2018 08:05:03 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (23.103.134.180) by smtpe1.intersmtp.com (62.239.224.237) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 2 Oct 2018 08:04:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ImKF/sQtjlNxm+P8ES9Y/oW47L4nNKrIxO4GXSaOgbg=; b=0+lFJ2DPLid9goWNwbduNsUXGQbCNyF6kam3ZxC/T9SFjjO0tmjcNYeCAKnvxZZuXFBMUrtHEuW151mZstWWOUwSzZkYg36heaZf2841+NqrlNpjbCWwTIrnHC+L62hnbanFRq3t8Zwexz2qD0PuPFkTMXk7q/5UaCiI816vJ8I= Received: from LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM (10.166.252.7) by LOXP123MB1029.GBRP123.PROD.OUTLOOK.COM (10.166.251.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.22; Tue, 2 Oct 2018 07:04:58 +0000 Received: from LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM ([fe80::51b2:16e1:e779:560d]) by LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM ([fe80::51b2:16e1:e779:560d%4]) with mapi id 15.20.1185.024; Tue, 2 Oct 2018 07:04:58 +0000 From: To: , CC: Thread-Topic: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded Thread-Index: AQHUID4n4GMbm7jjV0OZq9EzR5Srd6SYRW+ggHN1vACAAAT9gIAAO9Cu Date: Tue, 2 Oct 2018 07:04:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [40.119.148.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LOXP123MB1029; 6:1H/VgPA1upBCwOZxNICJ3C/7Ta8FwE6uFHE4Hl3o3LgM/a/inbi5/nZSdDYcu+Kd9CH/1Pez/JQFWp4IkQCgBFEj7EVjXU3aRs7fMKzdHk1a/2cxR7wgnGbzfxd43hkjsex6hf6mv7t7A2kmozHs3xT/qRUA2FXvOLwnLDQOW3x91fX+M8bL7sKXIy7x8xCTtd9h+KMa2jfpw1LlrmDJ6PlVZsSK1dkbf9rMPxsjmjgIL5qk0JpNMCC9MKJn0AQKuaKUmk2sFGFMYn1iy8OHTXdL5wA4Xeo3ufBITPtcjRwdyTJgC18LfmfYqDwRs7jiaJpn8kJcJ4Twu+EXllZtwL7csxlNOg99oT2AmjVXh0CxncHeDIbttCA3C8m5qf2IepU66KCrIKVAHqe8GMSMZlEvtW5XUABW+4/obnBoLWJVObg74uJkL2RCPWyOHrQaGVYYNNzk6/DS/AB7iCzY4w==; 5:YJO1XKrztHL+ZcXcjXLUaV4DmDShSL6qc+xWcrW9HnD+wfRF3NBpOGMA/bX95kWhHZpsosgZ5afmVy+YRw6RLTcNvHdTim0trog4ppOiMuBopFU+njbICJMhPX+RtzLxyrTE5bcjNCrOZk2vErLa/myF3/WeHNDpqxrn4cJ0XSg=; 7:q6CuUPx8+QKTuv5K3D9/20AhB+s73/LkI0JWo2Qm2iCO5yWrQ5VNFvmCNeWRB4dlOOxb2DGlh6xdwb7wolRuBbeo169XGX71DPC0s6hnZokqGeaoo8j9a+UpJBV2VU9dur5dhBYpInVpGojgJJnuRWB+nCJbK6IPIvX6I9QV8EhACTZ94hIGPEACtbW2RtFE459rnbYxPK1OCOnn9MQOwW0clEzY2nNdgi10fEWLxA/UEWeWaYJ6GLCuC9OJ9XSQ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 99b07604-0690-4f41-a1a0-08d628355d23 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:LOXP123MB1029; x-ms-traffictypediagnostic: LOXP123MB1029: x-antispam-2: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132)(85827821059158)(265313219721884); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201708071742011)(7699051); SRVR:LOXP123MB1029; BCL:0; PCL:0; RULEID:; SRVR:LOXP123MB1029; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(136003)(396003)(346002)(51444003)(199004)(189003)(236005)(102836004)(54896002)(53546011)(256004)(14444005)(55016002)(6306002)(6436002)(6506007)(39060400002)(45080400002)(3846002)(6116002)(66066001)(606006)(9686003)(966005)(81156014)(6246003)(4326008)(229853002)(81166006)(8936002)(97736004)(554214002)(7736002)(8676002)(25786009)(105586002)(110136005)(74316002)(476003)(93886005)(486006)(7696005)(478600001)(71190400001)(5250100002)(33656002)(316002)(71200400001)(2906002)(86362001)(53936002)(186003)(26005)(99286004)(106356001)(446003)(11346002)(76176011)(68736007)(14454004)(5660300001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:LOXP123MB1029; H:LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4khib1N4m+nGLnPotp/Po6dpsV0uOigtP1CUkst9PIeSe4vsvjZN8lU3O9nufQrGxbbBTdSwi4EAmC95y1dy/nunwMdGLkPnczEP97w2KQ3yO8nLi72eAwru9B0MLepPtgyjsNlA//RHHY+Pol87x4CcSLqcP19i5yhXe/dan0op2qBW2/BWxmNGRC6PKn/itotOtS+M4o1eDCLOrqaqdacKm0aKMkWsJ1bCzlWpfnqXK8QGgVDJL7o4IH8qjpywOsBlLyiAWgzIRNJN1CTpbRzbxfmZfJ4JF9hQhX8q5LRgFfXUUGLnZD7Q+/v3yqCwKDz+29hz5Sqg/zdHWC/BHv6yQPdOZznfFIMwvwP2qJw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LOXP123MB1063637567F1432789D0BAF3EAE80LOXP123MB1063GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 99b07604-0690-4f41-a1a0-08d628355d23 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2018 07:04:57.9136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOXP123MB1029 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 07:05:11 -0000 --_000_LOXP123MB1063637567F1432789D0BAF3EAE80LOXP123MB1063GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will take a look thanks, and i agree with you; When you call out 'observe= d behavior' i think that better describes what i am looking for in general = on the points i made. Get Outlook for Android ________________________________ From: Lorenzo Colitti Sent: Tuesday, October 2, 2018 4:30:53 AM To: Jen Linkova Cc: Heatley,N,Nick,TQB R; v6ops@ietf.org WG Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded On Tue, Oct 2, 2018 at 12:13 PM Jen Linkova > wrote: > This is valuable, thank you. > Where is it best to capture "Implementation considerations"; something li= ke section 6 of https://tools.ietf.org/html/rfc8106 To be honest I'm not sure it should be in this draft. I might be wrong but as long as the document describes the host behavior, we shouldn't be prescribing how exactly such behavior is implemented. As a host implementer and an author, I think it's actually not a good idea = to specify the implementation in the RFC that defines an option. There are = many cases in the IPv6 specifications where the lack of implementation expe= rience meant that some of the details of the protocols were overspecified a= nd required an RFC update to fix. The one that happens to come to mind at the moment is RFC 7048, which was r= equired only because NUD probing strategy was too strictly specified in RFC= 4861. But RFC 8106 itself is another example: because it doesn't allow for= any sort of multi-PVD operation, its guidance on a multi-PVD host (like pr= etty much any mobile OS today) is at best confusing and at worst incorrect.= RFC 8106 regularly refers to "the resolver repository" as if there were on= ly one of them, but a multi-PVD host cannot have only one resolver reposito= ry. So I'd expect that the popular implementations of RFC 8106 (at least th= e ones on mobile nodes) all actually violate the letter of the implementati= on considerations. Instead of writing implementation considerations, we should focus on observ= ed behaviour. The version we just uploaded contains some text on that alrea= dy; please look at it and see if you think there are things that it should = clarify or further specify. --_000_LOXP123MB1063637567F1432789D0BAF3EAE80LOXP123MB1063GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I will take a look thanks, and i agree with you; When you call out 'observe= d behavior' i think that better describes what i am looking for in general = on the points i made.
From: Lorenzo Colitti <l= orenzo@google.com>
Sent: Tuesday, October 2, 2018 4:30:53 AM
To: Jen Linkova
Cc: Heatley,N,Nick,TQB R; v6ops@ietf.org WG
Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded
 
On Tue, Oct 2, 2018 at 12:13 PM Jen Linkova <furry13@gmail.com> wrote:
> This is valuable, thank you.
> Where is it best to capture "Implementation considerations";= something like section 6 of https://tools.ietf.org/html/rfc8106

To be honest I'm not sure it should be in this draft.
I might be wrong but as long as the document describes the host
behavior, we shouldn't be prescribing how exactly such behavior is
implemented.

As a host implementer and an author, I think it's actually not a good = idea to specify the implementation in the RFC that defines an option. = There are many cases in the IPv6 specifications where the lack of implement= ation experience meant that some of the details of the protocols were overspecified and required an RFC update to = fix.

The one that happens to come to mind at the moment is RFC 7048, which = was required only because NUD probing strategy was too strictly specified i= n RFC 4861. But RFC 8106 itself is another example: because it doesn't allo= w for any sort of multi-PVD operation, its guidance on a multi-PVD host (like pretty much any mobile OS today) is= at best confusing and at worst incorrect. RFC 8106 regularly refers to &qu= ot;the resolver repository" as if there were only one of them, but a m= ulti-PVD host cannot have only one resolver repository. So I'd expect that the popular implementations of RFC 8106 (at= least the ones on mobile nodes) all actually violate the letter of the imp= lementation considerations.

Instead of writing implementation considerations, we should focus on o= bserved behaviour. The version we just uploaded contains some text on that = already; please look at it and see if you think there are things that it sh= ould clarify or further specify.
--_000_LOXP123MB1063637567F1432789D0BAF3EAE80LOXP123MB1063GBRP_-- From nobody Tue Oct 2 06:36:03 2018 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 7E4CE1292F1 for ; Tue, 2 Oct 2018 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifrngQ5LtCZ6 for ; Tue, 2 Oct 2018 06:35:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E837A126DBF for ; Tue, 2 Oct 2018 06:35:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EFAABVc7Nb/yYyC4daGgEBAQEBAgEBA?= =?us-ascii?q?QEHAgEBAQGBUYE6KipmbRIWEgqLf44oeJVkFIErOwsjCQKEPgKEDyE0GAEDAQE?= =?us-ascii?q?BAQEBAgICaRwMgmgvAQEEBwMMLwoCAwEBAQEBAQFPAg9HAQEYAQEBAQMSKDQLD?= =?us-ascii?q?AQCAQgNBAQBAQEKFBAyHQgBAQQBDQUIGoI0TIIBAQ6bNosdGgKJfAWLAxeBQj6?= =?us-ascii?q?BEkaCFzWDGwQYgS8CGIMwgiYCiEaHBI1yCQKGRooHgUmEX4J5A4Y2jBCJMIFCO?= =?us-ascii?q?YFVcBU7gmyGAopSb4EWjBsBgR4BAQ?= X-IPAS-Result: =?us-ascii?q?A2EFAABVc7Nb/yYyC4daGgEBAQEBAgEBAQEHAgEBAQGBUYE?= =?us-ascii?q?6KipmbRIWEgqLf44oeJVkFIErOwsjCQKEPgKEDyE0GAEDAQEBAQEBAgICaRwMg?= =?us-ascii?q?mgvAQEEBwMMLwoCAwEBAQEBAQFPAg9HAQEYAQEBAQMSKDQLDAQCAQgNBAQBAQE?= =?us-ascii?q?KFBAyHQgBAQQBDQUIGoI0TIIBAQ6bNosdGgKJfAWLAxeBQj6BEkaCFzWDGwQYg?= =?us-ascii?q?S8CGIMwgiYCiEaHBI1yCQKGRooHgUmEX4J5A4Y2jBCJMIFCOYFVcBU7gmyGAop?= =?us-ascii?q?Sb4EWjBsBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,332,1534824000"; d="scan'208";a="299313095" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Oct 2018 09:35:57 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 09:35:57 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0382.000; Tue, 2 Oct 2018 09:35:56 -0400 From: "Mudric, Dusan (Dusan)" To: "Mudric, Dusan (Dusan)" , Richard Patterson , "rbonica@juniper.net" CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] draft-patterson-intarea-ipoe-health Thread-Index: AdRZqSI4+oRob7goSR+GjzJzdIm+FgAJWlUAAALUR/AAHkh0QA== Date: Tue, 2 Oct 2018 13:35:56 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB858F1@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 13:36:02 -0000 Hi Richard, "=20 Similar in format to a BFD Echo packet, the IPoE Health Check probe is a simple UDP/IP packet with a destination IP address from the lease being checked, and a destination MAC address of the upstream router. " DHCP lease assigns IP to DHCP client. Is the probe's destination IP, the IP= of the client? What is the path that is tested for the health check? Can i= t be explicitly defined in the draft, to make it clear where packets are fl= owing? Is it a path between DHCP client and a first hop router? Is it a pat= h between DHCP client and DHCP server? Is it something else?=20 How will detection of the failure on that path (between the DHCP client and= X?) help finding out the connectivity to DHCP server failed, and that a cl= ient needs to find another DHCP server to get a new lease? If the client is doing the connectivity health check to the DHCP server, an= d the connectivity is lost, there is no need to first RENEW the lease with = the original server. Thanks, Dusan. > -----Original Message----- > From: v6ops On Behalf Of Mudric, Dusan (Dusan) > Sent: Monday, October 01, 2018 4:52 PM > To: Richard Patterson ; rbonica@juniper.net > Cc: v6ops@ietf.org list > Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health >=20 > Hi Richard, >=20 > " any indirect upstream network changes are > not visible to the IPoE client." >=20 > "The destination MAC address MUST be address of the upstream router." >=20 > The scope is only to the first hop router. Can you add an extension for > handling the uplink failures to ISPs > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dietf-2Drtgwg-2Denterprise-2Dpa- > 2Dmultihoming-2D07-23section-2D5.3.2-29- > 3F&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoU > WB8YLZU23029sMQGQ2kY&m=3DI4vSdejJKILLCcpAkcoiBWR7SlBOUfqtOJy6BD > Mtk2A&s=3Dzsgu8ktOzHLwsq9IdTBx1KsxkZNbQ1wM6JfDEYuc7ys&e=3D >=20 > "If a particular prefix should not be used as a source for > any destinations, then the router needs to send RA with Preferred > Lifetime field for that prefix set to 0." >=20 > This event can also trigger the recovery to alternate DHCP server. Please > provide the topology where another DHCP server would be. >=20 > Thanks, > Dusan. >=20 > > -----Original Message----- > > From: v6ops On Behalf Of Richard Patterson > > Sent: Monday, October 01, 2018 1:35 PM > > To: rbonica@juniper.net > > Cc: v6ops@ietf.org list > > Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health > > > > Hi Ron et al. > > > > I've actually been sitting on a new version that attempts to simplify > > things somewhat, after the feedback from IETF102. > > Revision -05 is up now: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__tools.ietf.org_html_draft-2Dpatterson-2Dintarea-2Dipoe-2Dhealth- > > > 2D05&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > > UWB8YLZU23029sMQGQ2kY&m=3DpIhtq5PQ_R8j4fKL9D0Jwdd- > _ZBzYdJEx_3b- > > dBQQX0&s=3DDl_OzZQQbBP_tJdv9RwheV4B4H_MQwxT0kR5Hz9UhXs&e=3D > > > > Changes include: > > > > - Consolidated the multiple behaviours down to one. > > - Added a Release flag instead of a distinct behaviour. > > - Added custom IPoE Health Check Probe definition. > > - Removed ARP/ND and Passive checks. > > - Removed alternative target address parameter. > > - Removed IANA registry request for Behaviour values. > > > > > > -Richard > > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > > > > > > Folks, > > > > > > Each week between now and IETF 103, we will review and discuss one > > draft. > > > > > > This week, please review and comment on draft-patterson-intarea-ipoe- > > health. > > > > > > Fred and Ron > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > > > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DpIht > > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > > dBQQX0&s=3DXUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > > > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DpIht > > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > > dBQQX0&s=3DXUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DI4vS > dejJKILLCcpAkcoiBWR7SlBOUfqtOJy6BDMtk2A&s=3DJYKQ1twmrDppoJk72XJBTL > AVEy9X-EezcH9c6_vsQGY&e=3D From nobody Tue Oct 2 07:18:49 2018 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 EB1D0130E59 for ; Tue, 2 Oct 2018 07:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElwCIg-aK1BR for ; Tue, 2 Oct 2018 07:18:45 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDB1130E89 for ; Tue, 2 Oct 2018 07:18:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EVAADgfbNb/wUHmMZaGwEBAQEDAQEBB?= =?us-ascii?q?wMBAQGBUYE6VGZtEigKi3+lBIF6CyUHAoQ+AoQPITQYAQMBAQEBAQECAgJpHAy?= =?us-ascii?q?CaEtrAQEBAQEBIwJELwEVKD8SARUBFBRCJgEEAQ0NGoMAggEBDptxix0aAol7B?= =?us-ascii?q?YsDF4FCPoERR4VnAQECAYFggzCCJgKdPAkChkaKB4E6AYdmA4Y2jBCJMIFCOYF?= =?us-ascii?q?VcBWDKIsVhT5vAQGBFIwbAYEeAQE?= X-IPAS-Result: =?us-ascii?q?A2EVAADgfbNb/wUHmMZaGwEBAQEDAQEBBwMBAQGBUYE6VGZ?= =?us-ascii?q?tEigKi3+lBIF6CyUHAoQ+AoQPITQYAQMBAQEBAQECAgJpHAyCaEtrAQEBAQEBI?= =?us-ascii?q?wJELwEVKD8SARUBFBRCJgEEAQ0NGoMAggEBDptxix0aAol7BYsDF4FCPoERR4V?= =?us-ascii?q?nAQECAYFggzCCJgKdPAkChkaKB4E6AYdmA4Y2jBCJMIFCOYFVcBWDKIsVhT5vA?= =?us-ascii?q?QGBFIwbAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.54,332,1534824000"; d="scan'208";a="299320065" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Oct 2018 10:18:40 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 10:18:40 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0382.000; Tue, 2 Oct 2018 10:18:39 -0400 From: "Mudric, Dusan (Dusan)" To: Jen Linkova , "nick.heatley@bt.com" CC: V6 Ops List Thread-Topic: [v6ops] draft-ietf-rtgwg-enterprise-pa-multihoming-07 Thread-Index: AdRaWs9+2V69G6VTTmuBzZPEA5vZMw== Date: Tue, 2 Oct 2018 14:18:39 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB8595A@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] draft-ietf-rtgwg-enterprise-pa-multihoming-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 14:18:48 -0000 https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-07#s= ection-5.3.2 " another one from LLA_B with PIO for 2001:db8:0:a020::/64, default router preference set to 01 (high)" Should it be 'b020', like "2001:db8:0:b020::/64"? Dusan From nobody Tue Oct 2 17:13:54 2018 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 711FB131161; Tue, 2 Oct 2018 17:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKwTmjBUoDWw; Tue, 2 Oct 2018 17:13:39 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925B11310A7; Tue, 2 Oct 2018 17:13:39 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9305LeD025183; Tue, 2 Oct 2018 20:13:38 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2mvh91jc8g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Oct 2018 20:13:37 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w930Dbut006297; Tue, 2 Oct 2018 20:13:37 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w930DTCc006177; Tue, 2 Oct 2018 20:13:30 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 820F74014057; Wed, 3 Oct 2018 00:13:29 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 6AA5A4014055; Wed, 3 Oct 2018 00:13:29 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.98]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0415.000; Tue, 2 Oct 2018 20:13:29 -0400 From: "STARK, BARBARA H" To: "'Richard Patterson'" , "int-area@ietf.org" , "v6ops@ietf.org list" , "dhcwg@ietf.org" Thread-Topic: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00 Thread-Index: AQHT/QhWmLS02fjqwUCl+TDdYKUMVKUNT1tQ Date: Wed, 3 Oct 2018 00:13:28 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.243.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-02_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030000 Archived-At: Subject: Re: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 00:13:42 -0000 I've gone through the document, but not in extreme detail. Here are some co= mments based on my quick reading. Name: IPoE Health Check sounds more like a marketing name than a name that = gives me some sense of what the capability actually does. I think it might = be easier for people to get a sense of what this does if its name better ev= oked its function, like "IPoE Connectivity Check". The "oE" is relevant sin= ce the function does place requirements on which MAC addresses to use. If i= t weren't for that, I would have said it could be used for IP over anything= . "Health" is too vague a term.=20 Abstract/Introduction: Starting with discussion of PPPoE and BFD Echo is ve= ry confusing. I much prefer documents to start by telling me what they're a= bout. This document seems to be primarily about defining this IP connectivi= ty check function. Info about PPPoE and BFD Echo is really just background = info. I would recommend leading with something like "This document defines = a mechanism for CE routers with IP over Ethernet WAN interface to period= ically test IP connectivity between it and the first hop router. This mecha= nism is intended to be used by CE routers that do not implement the BFD Ech= o mechanism for testing IP connectivity." I don't think PPPoE needs to be m= entioned in the abstract, at all. In the Intro, PPPoE background should pro= bably be the last paragraph, instead of the first. On a related note... "This document describes a mechanism for IP over Ethernet clients to achieve connectivity validation, similar to that of PPP over Ethernet, by using BFD Echo, or an alternative health check mechanism." ... isn't an accurate description of this document. This document defines a= connectivity check mechanism that can be used by CE routers that don't sup= port BFD Echo. CE is "Customer Edge" and not "Customer Equipment". It's not synonymous wit= h "CPE". "CE Router" is a "Customer Edge Router". It's called this because = it's at the edge of the customer premises network, as opposed to a router i= n the interior of the customer premises network or a router in an access ne= twork. "CPE" is properly a word that can be applied to any service-provider= -supplied "Customer Premises Equipment", including set-top boxes, VoIP ATAs= , ISP-supplied CE routers, etc. A CE router is not necessarily supplied by = the ISP. IPoE Client: I don't see a need to create yet another term for a CE router = with an IPoE WAN interface. I find the term "client" in this case a little = odd, since there isn't really a client/server relationship in the context o= f either IP or Ethernet or IP over Ethernet. "Non-default static parameters SHOULD override any signalled via a dynamic means (e.g, DHCP or TR-69)." TR-069, like SNMP and netconf, is not considered a dynamic means of configu= ring devices. It's generally considered a means of supplying "static" confi= guration. The relationship with BFD Echo is very confusing. I would suggest a relatio= nship along the lines of: If BFD Echo and are both= supported, the CE router MUST attempt to use both mechanisms to test IP co= nnectivity upon receiving a DHCP-assigned IP address or prefix. If BFD Echo= is successful, the CE router MUST cease using and= continue only with BFD Echo. If succeeds and BFD = Echo does not, the CE router MUST cease using BFD Echo and continue only wi= th . I'm not sure DHCP configuration is really needed. It seems like overkill. Recovery behavior for BFD Echo (per TR-124i5) is "Unless overridden by con= figuration, by default after a failure of 3 successive BFD echo intervals, = the RG MUST issue a DHCP renew message following a random jitter interval b= etween 1 and 30 seconds." I think it would be good if we had consistent beh= avior, independent of mechanism. Or is there a good reason to have differen= t behaviors for different connectivity checks? The version of TR-124 referenced in the references section doesn't actually= include BFD echo requirements. The most recent version is TR-124i5, which = is available at https://www.broadband-forum.org/technical/download/TR-124_I= ssue-5.pdf. "If all DHCPv6 leases have expired, either naturally or proactively with IPoE health checks, an IPoE client acting as a router, SHOULD withdraw itself as a default router on the LAN, following requirement G-5 of [RFC7084], Section 4.1." Since the referenced RFC7084 requirement is a "MUST", I would make it a MUS= T here, too. Barbara > -----Original Message----- > From: v6ops On Behalf Of Richard Patterson > Sent: Tuesday, June 05, 2018 4:03 PM > To: int-area@ietf.org; v6ops@ietf.org list ; dhcwg@ietf.o= rg > Subject: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00 >=20 > Hi All, >=20 > The above new draft has been posted to address an operational problem > that exists with current IPoE (non-PPPoE) fixed line broadband services. > It can be found here: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dpatterson-2Dintarea-2Dipoe- > 2Dhealth_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DFsoSwjTvxj08keS6f_DYpmlby-FM9C5m-G- > VTwchGJI&s=3DPlUBOvZt82phRMfoJpQQ--BeqgUeIP_QKKl6uSOdXA4&e=3D >=20 > Hopefully the draft covers the problem statement sufficiently, but in > summary, PPPoE makes use of LCP echo/replies to detect WAN failures, > DHCPv4/6 currently has no such mechanism. > After backhaul migrations or BNG maintenance/failure, an IPoE client can = be > left with a stale DHCP lease for up to the Valid Lifetime. >=20 > This draft proposes the use of regular ARP and ND for link monitoring, to > proactively expire DHCP leases early, and to trigger renewals or getting = a new > lease from scratch. >=20 > The intarea WG was chosen as it doesn't neatly fit within the charters of > either v6ops or dhc, and because it proposes new DHCPv4 and DHCPv6 > Options. Although we expect discussions in both of these WGs as well. >=20 > Thanks for comments already received from Ian, and Bernie, that helped > shape this -00. >=20 > -Richard >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DFsoSwjTvxj08keS6f_DYpmlby-FM9C5m-G- > VTwchGJI&s=3DPQDjf2K7lKp7HxtDXAqe1ce3u8xCq8vLbnHcTQjgRlw&e=3D From nobody Wed Oct 3 02:08:50 2018 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 1E150131211 for ; Wed, 3 Oct 2018 02:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNcGnXUvgmVq for ; Wed, 3 Oct 2018 02:08:46 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5975313118E for ; Wed, 3 Oct 2018 02:08:46 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id c23-v6so7338303itd.5 for ; Wed, 03 Oct 2018 02:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tsn1atnp0fl8zvs12LK1dkPK1+KwGNeKRpUbY9VzEew=; b=1wsteWntonD2YPiAxRaUMvQH0kMf2OId3dGgkPt60wMgiAcl3VH4TQAjcqaftfWrAe bYdOwSUHnXVrw7hKZrnhbj0WzxHC0KzmnQdtq25dfND3zeBU/XMTaaf3EQ1NweqPJDIR u5pEvBIq7BPsqIG5eemLV6X2g7Du0lbLOd6wWle81KcFi6m7KLqscTwrY8GHog0TcBsC egRAWCYBIITawE1ngmMxlsvDc/lqw3R2yTn2oGlS2HycYkkGm9T9W7gVLRKwsBcLbcEp SWa6kk90r95DMSrU8Po7yTVRTOoCyw5bbk5w0FSN8pKoxURXeMMnQfquYQYvcKHU/Qcj aZdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tsn1atnp0fl8zvs12LK1dkPK1+KwGNeKRpUbY9VzEew=; b=jrvEZoz54eLuuI5bGrmLCeg3fi5oncpOI5vlncLO18KGHuqIZeshEfBSOXsE3o26qu CTxd6cdw8BJQyTUexTDgD3AxuNHOxd7fZ/bHFojiF+Qctr5BDPQ0b7FvvmKzp09tiMzw 6gwfr9A7VX7n3WLoYMCy+3AGTPP35c3VUp9KJkdHKHKYdgncMNYlDMD4bZ0d1PAoCTz0 0xiNMuXUc/dpjCsj2ZhqQf3NDQb9rBIZyhRKUY38lrL8c2T61PLirkKwL+O1mw6fkUP7 3G9KLlAT42iriZ1BpNLHkWozQLDf/vDm4igXlmhBNMlrEQ7FfjFZWlp/x4s9zLA50u3w MAzg== X-Gm-Message-State: ABuFfog5Jyx4t6K2hV0hVAD8QID4cnDU8wXu2dKBhMkHCPeE7zF9tf9N s5/WwRk3hmyUc7pfXpX53BkcmeVCbjA= X-Google-Smtp-Source: ACcGV606qNvsZBofne9O0W13ZPeKPduC44c2fx9YBpSlo2bKe0V7mHCqX5HTKmgN9yxU4/HRxUfHlw== X-Received: by 2002:a24:5e50:: with SMTP id h77-v6mr649785itb.58.1538557725452; Wed, 03 Oct 2018 02:08:45 -0700 (PDT) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com. [209.85.166.176]) by smtp.gmail.com with ESMTPSA id i194-v6sm377636itf.26.2018.10.03.02.08.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 02:08:45 -0700 (PDT) Received: by mail-it1-f176.google.com with SMTP id q70-v6so7351730itb.3 for ; Wed, 03 Oct 2018 02:08:44 -0700 (PDT) X-Received: by 2002:a24:db05:: with SMTP id c5-v6mr657570itg.44.1538557724566; Wed, 03 Oct 2018 02:08:44 -0700 (PDT) MIME-Version: 1.0 References: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> From: Richard Patterson Date: Wed, 3 Oct 2018 10:08:33 +0100 X-Gmail-Original-Message-ID: Message-ID: To: dmudric@avaya.com Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 09:08:49 -0000 Hi Dusan, Not sure if I understand this correctly, however I believe it should already be covered? The upstream router in your example is the delegating router downstream, instead of multi-hop health checks, each router would be responsible for checking the validity of their own lease. In the case where the DHCP server is not colocated on the upstream router, is it safe to assume the upstream router would be performing some form of DHCP snooping and access restriction? Also, if the original DHCP server dies, it doesn't necessarily follow that the L2/L3 path has failed. In that example, regular DHCP lease timers will be sufficient to hit an alternate DHCP server. -Rich On Mon, 1 Oct 2018 at 21:52, Mudric, Dusan (Dusan) wrote: > > Hi Richard, > > " any indirect upstream network changes are > not visible to the IPoE client." > > "The destination MAC address MUST be address of the upstream router." > > The scope is only to the first hop router. Can you add an extension for handling the uplink failures to ISPs (https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-07#section-5.3.2)? > > "If a particular prefix should not be used as a source for > any destinations, then the router needs to send RA with Preferred > Lifetime field for that prefix set to 0." > > This event can also trigger the recovery to alternate DHCP server. Please provide the topology where another DHCP server would be. > > Thanks, > Dusan. > > > -----Original Message----- > > From: v6ops On Behalf Of Richard Patterson > > Sent: Monday, October 01, 2018 1:35 PM > > To: rbonica@juniper.net > > Cc: v6ops@ietf.org list > > Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health > > > > Hi Ron et al. > > > > I've actually been sitting on a new version that attempts to simplify > > things somewhat, after the feedback from IETF102. > > Revision -05 is up now: > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__tools.ietf.org_html_draft-2Dpatterson-2Dintarea-2Dipoe-2Dhealth- > > 2D05&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo > > UWB8YLZU23029sMQGQ2kY&m=pIhtq5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > > dBQQX0&s=Dl_OzZQQbBP_tJdv9RwheV4B4H_MQwxT0kR5Hz9UhXs&e= > > > > Changes include: > > > > - Consolidated the multiple behaviours down to one. > > - Added a Release flag instead of a distinct behaviour. > > - Added custom IPoE Health Check Probe definition. > > - Removed ARP/ND and Passive checks. > > - Removed alternative target address parameter. > > - Removed IANA registry request for Behaviour values. > > > > > > -Richard > > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > > > > > > Folks, > > > > > > Each week between now and IETF 103, we will review and discuss one > > draft. > > > > > > This week, please review and comment on draft-patterson-intarea-ipoe- > > health. > > > > > > Fred and Ron > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl > > 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=pIht > > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > > dBQQX0&s=XUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e= > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl > > 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=pIht > > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > > dBQQX0&s=XUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e= From nobody Wed Oct 3 02:20:34 2018 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 C235D13121B for ; Wed, 3 Oct 2018 02:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upqrKxdZ1VNV for ; Wed, 3 Oct 2018 02:20:31 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E21813118E for ; Wed, 3 Oct 2018 02:20:31 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id p64-v6so7844549itp.0 for ; Wed, 03 Oct 2018 02:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jUQeyC4BtGyk/n5HsVz22wOEdoxV1L7d2jl0v0EyEzI=; b=DBaA/uas9OsiRQF/+0uYGENVi4nm+jQMufpjH49vhxO6OaBLmJ0iJMoGmqHbF2CsTG WsJi6m9HC6QwU8eLyyMT/e3DlkBwwGdxSnhP9TWKEsGkCugS+gR1L/XTyjjgugVfbLxQ bTh8eMOAB4zDVL9fPcxeKr+WOvrAYieU5FHDvhPjqpBuHXOCml6hohbjH2wVoeVYYY5+ UP5Qyl34WatD+sKpxcV3I+m3o6C31u1kNoGuyqBhF12YNxOSvmHJAmSuUTb4hVwPQ111 eHi4UTJwH0+OxDIMVZoask1Os9VqwCI5yRiR/wmyqpQHgoDu587Ci1A5TrDr7nbGacT7 lDUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jUQeyC4BtGyk/n5HsVz22wOEdoxV1L7d2jl0v0EyEzI=; b=gNYnTFHIKLG/ad//ZVFB4L6M6KXF6jFr9Yd/1P0YNlRHjhKXLTlWXm7J/Z95ni+5U4 HwpC7Ajggcoe4JQkaD1BvgvdZcOWLQZ+xeWZ4a1MGVYYMX/KHdqxpmTdtdD5+3xNHara yiJX6I4r0QXUDEQOJP7wxFGAPBMsarSf9e4jOLO3VMRnRMNDE6adWBZQrD8IB5c2zk1f yGOasLTCO7/+ZLfcAxv2cETqJXAfTJJSxslrjJksVn3u3sC403wEprYo0R80rXT1T4vV qSfiGRu1Hf/78H0Ce5MpgFWgvoZDF5ZdcPCS2x0ONrhPIaac9KVTI5lJDcOVZjwwGfjl PGbw== X-Gm-Message-State: ABuFfoghxS30PcoZ5dOnRunYQ0OFV5pGeDdMZCkwTKXmjqiKPpMqF1yy yKkbnnoOhdJQvJf3A3loTjXUAvFgoIQ= X-Google-Smtp-Source: ACcGV61OvjVkneMUHL28mkf1MQrMGEfj1i2aEZLKA4o/pV+Pn7ZhUZehOZqIQ//Y7Aurb1Mc179gIw== X-Received: by 2002:a02:b476:: with SMTP id w51-v6mr360952jaj.140.1538558430373; Wed, 03 Oct 2018 02:20:30 -0700 (PDT) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id d134-v6sm163140iog.84.2018.10.03.02.20.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 02:20:29 -0700 (PDT) Received: by mail-it1-f169.google.com with SMTP id c23-v6so7374763itd.5 for ; Wed, 03 Oct 2018 02:20:29 -0700 (PDT) X-Received: by 2002:a24:db05:: with SMTP id c5-v6mr682426itg.44.1538558429630; Wed, 03 Oct 2018 02:20:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Patterson Date: Wed, 3 Oct 2018 10:20:18 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Mark Smith Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 09:20:33 -0000 On Mon, 1 Oct 2018 at 22:15, Mark Smith wrote: > The ID's Abstract and Introduction is saying that the problem it is > solving is the lack of a PPP keepalives equivalent in an IPoE > environment, and PPP keepalives don't solve that problem either*. > > I'd expect if delegated prefix forwarding validation that was the > focus of the ID, a simple text search for "delegated" or "PD" across > the whole draft should find something, but neither do. > > If that's the problem being solved, then it isn't very clear from the > current text. It seems to be more focusing on direct CE to BNG > liveness testing. You're right, CE to BNG liveness was the primary objective, simultaneously validating the lease was a secondary benefit. This is why the original revisions of the draft had multiple health check methods, and multiple behaviour options. We've attempted to consolidate things down in to a more unified approach. -Rich From nobody Wed Oct 3 03:03:55 2018 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 92C2C13118E for ; Wed, 3 Oct 2018 03:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X94etTTRaGTJ for ; Wed, 3 Oct 2018 03:03:51 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF68130F89 for ; Wed, 3 Oct 2018 03:03:50 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id z16-v6so4523410iol.6 for ; Wed, 03 Oct 2018 03:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FFEVoDALoQFUx8VenHVkIU6tu1Tr1ymIfoppr6wurXM=; b=XCTw1XUlR5MMyq3XZo4IVXr4iEMYXAedquB3PYgCyRaYR0xbaTS7lX0YwUyz7QMAru /hfwdPNOYRKpyf3vK7e9KTm6nmFrtMpvt4nzzI1xe+KjvQfsH4+myuSFSr8AhZCSvAR+ 5Jyyx/Kz1rF7/TOma04H1EvTIti2K2H/J9uR91qkaJQz8R2uFUFvsJ50XztZq9L+qEsn sohVkW8MD2YDb/d8tGq3TFlR8FNndw6q/mn/c71cIgGwdM2UHscYrkkGuF7gSQpFHgwy AzJUWkdOCKBiwUPNYRCZG9BZGemZ67C4jdF+NxNWYO04bpAJy2yz1Z98IlHWMmC2DEUq VHuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FFEVoDALoQFUx8VenHVkIU6tu1Tr1ymIfoppr6wurXM=; b=aPNdF8Bix+uHhy12Zn8/aV92OwTRDJuBPf3w6NfMQJ2yNEg06WSzFvpC7Z3uCQGVtP o9aLggiVeD/NGPsQ+CtzVSBF3QCGxGnESqQkwF0JQe/W4UbHj4XAgGyGdrt1KhH0+IPJ FFkwUVuCJRfWvyLJIP5mb8nyhV2gELgZcODWWNA76JtXJEjIN2jd+H3eT3bu3j724Zw+ bG7O5DqX8gVhs8OndjhdmPAP0yAQHfSrXgF95k3HScu7Zw5wBpxTXpwcNgPP2r6cVx5B j5jT33FPweHXAuZAehjCeTX2SuL1vhMEGLG2VHCQrgDbpUzO0Un7G3vlY8lG5tt1k3LE 9a5g== X-Gm-Message-State: ABuFfojvZyR7hkm8gn77Fd9wrSLPw8W+juomLA8lHUR3CBDj51gsYnC/ vp4ZNKt7M5pv7OLxe0MwhbpkHomz5SY= X-Google-Smtp-Source: ACcGV60hlbmpFPp+/5nB1DVSE2NJXMfr2MJoQfFX0hGdbrR9i7boRF5anZDOmYTNzirgHGKVeKRb2w== X-Received: by 2002:a6b:99c2:: with SMTP id b185-v6mr411338ioe.29.1538561029897; Wed, 03 Oct 2018 03:03:49 -0700 (PDT) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id f9-v6sm203574iok.25.2018.10.03.03.03.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 03:03:49 -0700 (PDT) Received: by mail-it1-f179.google.com with SMTP id h6-v6so11372742ith.0 for ; Wed, 03 Oct 2018 03:03:49 -0700 (PDT) X-Received: by 2002:a05:660c:68c:: with SMTP id n12mr782571itk.106.1538561029039; Wed, 03 Oct 2018 03:03:49 -0700 (PDT) MIME-Version: 1.0 References: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB858F1@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB858F1@AZ-US1EXMB03.global.avaya.com> From: Richard Patterson Date: Wed, 3 Oct 2018 11:03:37 +0100 X-Gmail-Original-Message-ID: Message-ID: To: dmudric@avaya.com Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 10:03:54 -0000 Hi Dusan, There're a lot of questions all packed in there, I'll try to answer them al= l. The probe's destination IP should be the IP from within the lease. When testing a PD lease, it could be any address from within that prefix. When testing an NA lease, it should be of that specific address, however sending packets destined to a locally bound address may have issues on certain operating systems as Barbara mentioned. Agreed this needs more detail written in to the draft after some more investigation. Packets should flow between the client and the first layer 3 hop, not the DHCP server, although the first layer 3 hop may or may not have the DHCP server colocated with it. Agreed, this behaviour could be described better in the draft. As mentioned to Mark, the primary purpose of this draft is to test the layer 2 & 3 path, and in fact I'll expand on that a bit to say that the primary object is actually to check subscriber session state. The problem is that we're trying to infer subscriber session state with a combination of L2/3/DHCP lease checks. L2 checks alone are not sufficient to prove subscriber session state, nor are L3 checks to the delegating DHCP server. -Rich On Tue, 2 Oct 2018 at 14:36, Mudric, Dusan (Dusan) wrot= e: > > Hi Richard, > > " > Similar in format to a BFD Echo packet, the IPoE Health Check probe > is a simple UDP/IP packet with a destination IP address from the > lease being checked, and a destination MAC address of the upstream > router. " > > DHCP lease assigns IP to DHCP client. Is the probe's destination IP, the = IP of the client? What is the path that is tested for the health check? Can= it be explicitly defined in the draft, to make it clear where packets are = flowing? Is it a path between DHCP client and a first hop router? Is it a p= ath between DHCP client and DHCP server? Is it something else? > > How will detection of the failure on that path (between the DHCP client a= nd X?) help finding out the connectivity to DHCP server failed, and that a = client needs to find another DHCP server to get a new lease? > > If the client is doing the connectivity health check to the DHCP server, = and the connectivity is lost, there is no need to first RENEW the lease wit= h the original server. > > Thanks, > Dusan. > > > -----Original Message----- > > From: v6ops On Behalf Of Mudric, Dusan (Dusan) > > Sent: Monday, October 01, 2018 4:52 PM > > To: Richard Patterson ; rbonica@juniper.net > > Cc: v6ops@ietf.org list > > Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health > > > > Hi Richard, > > > > " any indirect upstream network changes are > > not visible to the IPoE client." > > > > "The destination MAC address MUST be address of the upstream router.= " > > > > The scope is only to the first hop router. Can you add an extension for > > handling the uplink failures to ISPs > > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__tools.ietf.org_html_draft-2Dietf-2Drtgwg-2Denterprise-2Dpa- > > 2Dmultihoming-2D07-23section-2D5.3.2-29- > > 3F&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoU > > WB8YLZU23029sMQGQ2kY&m=3DI4vSdejJKILLCcpAkcoiBWR7SlBOUfqtOJy6BD > > Mtk2A&s=3Dzsgu8ktOzHLwsq9IdTBx1KsxkZNbQ1wM6JfDEYuc7ys&e=3D > > > > "If a particular prefix should not be used as a source for > > any destinations, then the router needs to send RA with Preferred > > Lifetime field for that prefix set to 0." > > > > This event can also trigger the recovery to alternate DHCP server. Plea= se > > provide the topology where another DHCP server would be. > > > > Thanks, > > Dusan. > > > > > -----Original Message----- > > > From: v6ops On Behalf Of Richard Patterson > > > Sent: Monday, October 01, 2018 1:35 PM > > > To: rbonica@juniper.net > > > Cc: v6ops@ietf.org list > > > Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health > > > > > > Hi Ron et al. > > > > > > I've actually been sitting on a new version that attempts to simplify > > > things somewhat, after the feedback from IETF102. > > > Revision -05 is up now: > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__tools.ietf.org_html_draft-2Dpatterson-2Dintarea-2Dipoe-2Dhealth- > > > > > 2D05&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > > > UWB8YLZU23029sMQGQ2kY&m=3DpIhtq5PQ_R8j4fKL9D0Jwdd- > > _ZBzYdJEx_3b- > > > dBQQX0&s=3DDl_OzZQQbBP_tJdv9RwheV4B4H_MQwxT0kR5Hz9UhXs&e=3D > > > > > > Changes include: > > > > > > - Consolidated the multiple behaviours down to one. > > > - Added a Release flag instead of a distinct behaviour. > > > - Added custom IPoE Health Check Probe definition. > > > - Removed ARP/ND and Passive checks. > > > - Removed alternative target address parameter. > > > - Removed IANA registry request for Behaviour values. > > > > > > > > > -Richard > > > On Mon, 1 Oct 2018 at 18:08, Ron Bonica wrote: > > > > > > > > Folks, > > > > > > > > Each week between now and IETF 103, we will review and discuss one > > > draft. > > > > > > > > This week, please review and comment on draft-patterson-intarea-ipo= e- > > > health. > > > > > > > > Fred and Ron > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > v6ops@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > > > > > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DpIht > > > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > > > dBQQX0&s=3DXUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=3D > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > > > > > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DpIht > > > q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b- > > > dBQQX0&s=3DXUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DI4vS > > dejJKILLCcpAkcoiBWR7SlBOUfqtOJy6BDMtk2A&s=3DJYKQ1twmrDppoJk72XJBTL > > AVEy9X-EezcH9c6_vsQGY&e=3D From nobody Wed Oct 3 03:52:42 2018 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 2B2CF1310AE for ; Wed, 3 Oct 2018 03:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh8eAccgbJQu for ; Wed, 3 Oct 2018 03:52:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9368F131047 for ; Wed, 3 Oct 2018 03:52:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 620D0AF; Wed, 3 Oct 2018 12:52:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1538563954; bh=JJvHTm8SncJlMeyR+eFiixt5/s+FoY1332usmlDLT1U=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Jk0JJNWYsLZZsYTIKeb3yxDaQHFPiEd0nvTgwTr9ST+gHMxDBLVGsWuPu/1zgZkKH K+QUys5PdjyvnZqb8jiBHny6Kp1HHclGVfjZYejK+mrJ3KYitAUfdqpVAKjI9YG91B LH5sYs8P5bG34U6QFIqmmGDhP6ZETe/ZojGHGjqw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 600D89F; Wed, 3 Oct 2018 12:52:34 +0200 (CEST) Date: Wed, 3 Oct 2018 12:52:34 +0200 (CEST) From: Mikael Abrahamsson To: Richard Patterson cc: dmudric@avaya.com, "v6ops@ietf.org list" In-Reply-To: Message-ID: References: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB858F1@AZ-US1EXMB03.global.avaya.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 10:52:41 -0000 On Wed, 3 Oct 2018, Richard Patterson wrote: > As mentioned to Mark, the primary purpose of this draft is to test the > layer 2 & 3 path, and in fact I'll expand on that a bit to say that the > primary object is actually to check subscriber session state. The > problem is that we're trying to infer subscriber session state with a > combination of L2/3/DHCP lease checks. L2 checks alone are not > sufficient to prove subscriber session state, nor are L3 checks to the > delegating DHCP server. Let me provide a concrete example: BNG <-L2-> BNG somehow delegates a PD /56 to CE, which allocates this (for example) as ::1/64 out of that PD onto its LAN. Now, on CE WAN, I can run scapy: sendp(Ether(src="CE-WAN-ETH",dst="BNG-WAN-ETH")/IPv6(src="LAN::2",dst="LAN::1")/UDP(sport=10000,dport=10000)/Raw(load="test\n"),iface="WAN") This will yield the following packet send towards the BNG: 12:44:23.416601 CE-WAN-ETH > BNG-WAN-ETH, ethertype IPv6 (0x86dd), length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5 Now, because the BNG has a /56 routed towards the CE, the following packet will come back: 12:44:23.417526 BNG-WAN-ETH > CE-WAN-ETH, ethertype IPv6 (0x86dd), length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5 (only difference is the swap between SRC/DST MAC addresses and TTL decrease after the packet was run through the forwarding engine of the BNG) If I use the LAN::1 address as source of the packet, the Linux kernel will drop the packet and it's not delivered to the application on CE, so we're going to have to use a non-interface address as source. This is fine as long as it's within the PD. If the PD isn't valid, the BNG will not have that /56 route and we won't see the packet coming back to us and delivered to the userspace application, which in my example above was "ncat -u -l LAN::1 10000" running on CE. That's when we want to kick the DHCPv6 machinery to do all the DHCPv6 things that it normally does, to try to renew the lease or expire it and ask for a new one. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Oct 3 09:23:48 2018 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 E413E13130E for ; Wed, 3 Oct 2018 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6Er8P4VIXFh for ; Wed, 3 Oct 2018 09:23:45 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AD3131307 for ; Wed, 3 Oct 2018 09:23:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EGAADq67Rb/yYyC4dcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAQGBUYE6JS+BUxIoCot/jiiWXBSBZgsshEAChCEhNBgBAwEBAQE?= =?us-ascii?q?BAQICAmkohTkBAQEBAgESFRM/DAQCAQgNAQMEAQEBChQQMh0IAQEEAQ0FCBqEe?= =?us-ascii?q?QgBm0qKajMaAol2iyEXgUI+gRJGgkyESwESAQkYBYMrgiYClASIeVAJAolWhn2?= =?us-ascii?q?BSoRignkDhjqVUYFCOWRxcBU7gmyQVG+BFopBgR8BgR4BAQ?= X-IPAS-Result: =?us-ascii?q?A2EGAADq67Rb/yYyC4dcGQEBAQEBAQEBAQEBAQcBAQEBAQG?= =?us-ascii?q?BUYE6JS+BUxIoCot/jiiWXBSBZgsshEAChCEhNBgBAwEBAQEBAQICAmkohTkBA?= =?us-ascii?q?QEBAgESFRM/DAQCAQgNAQMEAQEBChQQMh0IAQEEAQ0FCBqEeQgBm0qKajMaAol?= =?us-ascii?q?2iyEXgUI+gRJGgkyESwESAQkYBYMrgiYClASIeVAJAolWhn2BSoRignkDhjqVU?= =?us-ascii?q?YFCOWRxcBU7gmyQVG+BFopBgR8BgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,336,1534824000"; d="scan'208";a="299465876" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Oct 2018 12:23:43 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 12:23:43 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0382.000; Wed, 3 Oct 2018 12:23:43 -0400 From: "Mudric, Dusan (Dusan)" To: Mikael Abrahamsson , Richard Patterson CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] draft-patterson-intarea-ipoe-health Thread-Index: AdRZqSI4+oRob7goSR+GjzJzdIm+FgBV02UjAAoR/AAAAdKPwA== Date: Wed, 3 Oct 2018 16:23:43 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB85F4F@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB858F1@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:23:48 -0000 Hi Mikael, Please see inlined. Thanks, Dusan. > -----Original Message----- > From: Mikael Abrahamsson > Sent: Wednesday, October 03, 2018 6:53 AM > To: Richard Patterson > Cc: Mudric, Dusan (Dusan) ; v6ops@ietf.org list > > Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health >=20 > On Wed, 3 Oct 2018, Richard Patterson wrote: >=20 > > As mentioned to Mark, the primary purpose of this draft is to test the > > layer 2 & 3 path, and in fact I'll expand on that a bit to say that the > > primary object is actually to check subscriber session state. The > > problem is that we're trying to infer subscriber session state with a > > combination of L2/3/DHCP lease checks. L2 checks alone are not > > sufficient to prove subscriber session state, nor are L3 checks to the > > delegating DHCP server. >=20 > Let me provide a concrete example: >=20 > BNG <-L2-> >=20 > BNG somehow delegates a PD /56 to CE, which allocates this (for example) > as ::1/64 out of that PD onto its LAN. >=20 > Now, on CE WAN, I can run scapy: >=20 > sendp(Ether(src=3D"CE-WAN-ETH",dst=3D"BNG-WAN- > ETH")/IPv6(src=3D"LAN::2",dst=3D"LAN::1")/UDP(sport=3D10000,dport=3D10000= )/Raw > (load=3D"test\n"),iface=3D"WAN") [[Dusan]]=20 Thanks. This kind of description should be in the problem statement. >From the comments and the draft, we have several definitions the destinatio= n IP. I think dest. IP needs to be more clearly defined. The problem statem= ent like this will help the definition. " a destination IP address from the lease being checked" " The probe's destination IP should be the IP from within the lease. When testing a PD lease, it could be any address from within that prefix. When testing an NA lease, it should be of that specific address, however sending packets destined to a locally bound address may have issues on certain operating systems as Barbara mentioned." "The destination MAC address MUST be address of the upstream router." My understanding is that this kind of check needs to be done to determine t= hat DHCP server is not reachable from CE and to start a lease renewal or a = new solicitation. Please correct as needed. 1) The CE probe needs to be delivered to an application (which one?) on BNG= , in order to check there is IP connectivity between CE and DHCP server (on= or behind BNG) delegating the lease (i.e. PD). Need to position DHCP serve= r in the figure to show that if this connectivity check (between CE and BNG= ) fails, there is no DHCP connection between CE and DHCP server. That trigg= ers the lease renewal or DHCP server discovery on CE. 2) The destination, and the first hop, is BNG. The probe reaches the destin= ation using BNG MAC address . =20 3) Should the destination IP be on BNG? Saying that the destination IP can = be any address from PD /56 can get the IP from some of PD /64 destinations = on the LAN side. Can you double check this definition and make it more clea= r please? >=20 > This will yield the following packet send towards the BNG: >=20 > 12:44:23.416601 CE-WAN-ETH > BNG-WAN-ETH, ethertype IPv6 (0x86dd), > length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5 >=20 > Now, because the BNG has a /56 routed towards the CE, the following packe= t > will come back: >=20 > 12:44:23.417526 BNG-WAN-ETH > CE-WAN-ETH, ethertype IPv6 (0x86dd), > length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5 >=20 > (only difference is the swap between SRC/DST MAC addresses and TTL > decrease after the packet was run through the forwarding engine of the > BNG) >=20 > If I use the LAN::1 address as source of the packet, the Linux kernel wil= l > drop the packet and it's not delivered to the application on CE, so we're > going to have to use a non-interface address as source. This is fine as > long as it's within the PD. >=20 > If the PD isn't valid, the BNG will not have that /56 route and we won't > see the packet coming back to us and delivered to the userspace > application, which in my example above was "ncat -u -l LAN::1 10000" > running on CE. That's when we want to kick the DHCPv6 machinery to do all > the DHCPv6 things that it normally does, to try to renew the lease or > expire it and ask for a new one. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Oct 3 13:52:11 2018 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 6413F12F295 for ; Wed, 3 Oct 2018 13:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj_uB7ldOC3p for ; Wed, 3 Oct 2018 13:52:07 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22F4129619 for ; Wed, 3 Oct 2018 13:52:06 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id ADD8CAF; Wed, 3 Oct 2018 22:52:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1538599924; bh=2EtbwpifYq/3V3Spa1pW5cCk+o60HlLd6vbTKHrVU+w=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hMOy5/++FEa/4ebwAjlAu29rP8hxTi8JLQjmxZZ/amqi5f/UKCPN7gUAUKGsV44oO StKS6tJTyO3KHccDz5fdbBDIG4q0c/n3FX2XlWoq0VtHKvitR6uHc7x5cnwM0OV8U3 VBp/pbFMEac0sV5IA/i/BY2+F1JZNEMqNLF8P1PY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AA6569F; Wed, 3 Oct 2018 22:52:04 +0200 (CEST) Date: Wed, 3 Oct 2018 22:52:04 +0200 (CEST) From: Mikael Abrahamsson To: "Mudric, Dusan (Dusan)" cc: Richard Patterson , "v6ops@ietf.org list" In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB85F4F@AZ-US1EXMB03.global.avaya.com> Message-ID: References: <9142206A0C5BF24CB22755C8EC422E459CB8564A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB858F1@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB85F4F@AZ-US1EXMB03.global.avaya.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 20:52:10 -0000 On Wed, 3 Oct 2018, Mudric, Dusan (Dusan) wrote: > My understanding is that this kind of check needs to be done to > determine that DHCP server is not reachable from CE and to start a lease > renewal or a new solicitation. Please correct as needed. The check doesn't do anything with the DHCP server. It checks the forwarding state of the BNG (routing table). This L3 forwarding table is populated based on DHCPv6 state. If this state is deemed to not exist (there is no /56 PD route pointed towards the CE), then we kick in the DHCP "machinery" to try to "fix" this state. > 1) The CE probe needs to be delivered to an application (which one?) on > BNG, in order to check there is IP connectivity between CE and DHCP > server (on or behind BNG) delegating the lease (i.e. PD). Need to > position DHCP server in the figure to show that if this connectivity > check (between CE and BNG) fails, there is no DHCP connection between CE > and DHCP server. That triggers the lease renewal or DHCP server > discovery on CE. The probe is just the CE sending a packet to itself via the BNG. It just uses the forwarding plane of the BNG, nothing else. No "application" on the BNG. Just standard L3 routing. If this send-packet-to-myself-via-BNG fails, then we just do the normal DHCP renew/solicit that we would do in case WAN port on CE actually went down and came back up again. This should then restore the BNG to the correct state. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 4 03:15:24 2018 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 EA19E130E1A for ; Thu, 4 Oct 2018 03:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2T-KV127Qvk for ; Thu, 4 Oct 2018 03:15:09 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B39C130DFB for ; Thu, 4 Oct 2018 03:15:05 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id i76-v6so13220113ita.3 for ; Thu, 04 Oct 2018 03:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vp6KGI5Zm/3WZVSY0w6raiMH4oTnOmiDhP/1gLWF27c=; b=Kg9l310xHjyuMJMGr6BBofsoTNPIG0nDBafZL8+4q53dSSIr2wPiPgxPBaflu1oHLM j0Tu1qAqPqDPiipp+k375p5GBupc09CBo0hP3kdmckaxGFd0xV712dWSZwNbnCRxCutk cGF/m5TOWUz+wCUt6f7VGMNlflQVsOne/p9HNbkWc66QT5s7RHzSpAzFKKQ6dIj9UuK0 aSOywZDFOKNp2UIzNg1fkb8ufxvx8L6isoFiIk3hMQi7U74rcR77zRMzgt4/AkKck/jK JUXduZIVJg84bZct2iUiYS61bzTrtN27gCzj+PXW8HjbgPhTkwDuKCUrzUdZGPYlCibw nwhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vp6KGI5Zm/3WZVSY0w6raiMH4oTnOmiDhP/1gLWF27c=; b=qGt75KCEx4ymutdlFmnJzPlnvb8RXBTmJTbU6r1vAxXbwx2CZDyDfT2Ql1XL2joAVO Yijwn2/GFO5rHUZoBZB+nuQQ2D7ilxqCJ+xczvAOD5p3s+F4tLsXlPl/J8anEFxARVKK ngPb5SQCRqwTLCGNBmI+NPbDmnoQxGMB82dziEVT2HBE2uG005f/yVAmyUtzekgfQPR/ wmkbiPhF0jEjz5MySkA7JmYl85ZLMtowRXG1eKYrNvj8sgDl+DjyMbneBw94AfUJv3j2 GcTqwM77psP9y8kHlH3yqTtDBuLHezLRTecgDgmsnXxVh53OLdHHVygDstO3DI/Vqhdj 06XA== X-Gm-Message-State: ABuFfohpGGuu+batRiU+1ngKzOx8F+2grA2zE1zNvm4LsymSRMMRse2Y ZGPARkg48R091U4ClslMh1glf474mvugkg== X-Google-Smtp-Source: ACcGV63WwYsofL+AZj8IJtI3sA88zbeKPWSfa0ATQwRTC65Z3yxiQwW8zXz7BVWYayMmM7bkler1fw== X-Received: by 2002:a02:8c48:: with SMTP id j8-v6mr4488400jal.100.1538648104922; Thu, 04 Oct 2018 03:15:04 -0700 (PDT) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com. [209.85.166.42]) by smtp.gmail.com with ESMTPSA id e16-v6sm1323118iob.64.2018.10.04.03.15.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 03:15:04 -0700 (PDT) Received: by mail-io1-f42.google.com with SMTP id w16-v6so7422411iom.7; Thu, 04 Oct 2018 03:15:04 -0700 (PDT) X-Received: by 2002:a6b:9b42:: with SMTP id d63-v6mr3588084ioe.183.1538648103779; Thu, 04 Oct 2018 03:15:03 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Richard Patterson Date: Thu, 4 Oct 2018 11:14:52 +0100 X-Gmail-Original-Message-ID: Message-ID: To: bs7652@att.com Cc: int-area@ietf.org, "v6ops@ietf.org list" , dhcwg@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 10:15:14 -0000 Hi Barbara, Thanks for your review once again. Responses in-line: On Wed, 3 Oct 2018 at 01:13, STARK, BARBARA H wrote: > Name: IPoE Health Check sounds more like a marketing name than a name tha= t gives me some sense of what the capability actually does. I think it migh= t be easier for people to get a sense of what this does if its name better = evoked its function, like "IPoE Connectivity Check". The "oE" is relevant s= ince the function does place requirements on which MAC addresses to use. If= it weren't for that, I would have said it could be used for IP over anythi= ng. "Health" is too vague a term. OK, we can work on the name. > Abstract/Introduction: Starting with discussion of PPPoE and BFD Echo is = very confusing. I much prefer documents to start by telling me what they're= about. This document seems to be primarily about defining this IP connecti= vity check function. Info about PPPoE and BFD Echo is really just backgroun= d info. I would recommend leading with something like "This document define= s a mechanism for CE routers with IP over Ethernet WAN interface to peri= odically test IP connectivity between it and the first hop router. This mec= hanism is intended to be used by CE routers that do not implement the BFD E= cho mechanism for testing IP connectivity." I don't think PPPoE needs to be= mentioned in the abstract, at all. In the Intro, PPPoE background should p= robably be the last paragraph, instead of the first. Totally agree with regards to the abstract. Are you OK with the existing introduction section referencing PPPoE and BFD Echo to provide the background, if we reword the abstract to focus on this document? > > On a related note... > "This document describes a mechanism for IP over Ethernet clients to > achieve connectivity validation, similar to that of PPP over > Ethernet, by using BFD Echo, or an alternative health check > mechanism." > ... isn't an accurate description of this document. This document defines= a connectivity check mechanism that can be used by CE routers that don't s= upport BFD Echo. > > CE is "Customer Edge" and not "Customer Equipment". It's not synonymous w= ith "CPE". "CE Router" is a "Customer Edge Router". It's called this becaus= e it's at the edge of the customer premises network, as opposed to a router= in the interior of the customer premises network or a router in an access = network. "CPE" is properly a word that can be applied to any service-provid= er-supplied "Customer Premises Equipment", including set-top boxes, VoIP AT= As, ISP-supplied CE routers, etc. A CE router is not necessarily supplied b= y the ISP. OK, we can standardise on using "CE router". > > IPoE Client: I don't see a need to create yet another term for a CE route= r with an IPoE WAN interface. I find the term "client" in this case a littl= e odd, since there isn't really a client/server relationship in the context= of either IP or Ethernet or IP over Ethernet. Understand from the literal sense, but in context "IPoE" is generally synonymous with DHCP, in which there is a client/server relationship. We can, however, avoid this term if it's deemed confusing. > > "Non-default static parameters SHOULD override any signalled via a > dynamic means (e.g, DHCP or TR-69)." > TR-069, like SNMP and netconf, is not considered a dynamic means of confi= guring devices. It's generally considered a means of supplying "static" con= figuration. > > The relationship with BFD Echo is very confusing. I would suggest a relat= ionship along the lines of: If BFD Echo and are bo= th supported, the CE router MUST attempt to use both mechanisms to test IP = connectivity upon receiving a DHCP-assigned IP address or prefix. If BFD Ec= ho is successful, the CE router MUST cease using a= nd continue only with BFD Echo. If succeeds and BF= D Echo does not, the CE router MUST cease using BFD Echo and continue only = with . OK, will try to clarify this. > > I'm not sure DHCP configuration is really needed. It seems like overkill. Other reviewers/commenters previously felt that this was a useful addition. This would allow Network Operators to trigger or influence the connectivity check on CE routers that they are not in TR.069/etc. control of. > > Recovery behavior for BFD Echo (per TR-124i5) is "Unless overridden by c= onfiguration, by default after a failure of 3 successive BFD echo intervals= , the RG MUST issue a DHCP renew message following a random jitter interval= between 1 and 30 seconds." I think it would be good if we had consistent b= ehavior, independent of mechanism. Or is there a good reason to have differ= ent behaviors for different connectivity checks? Our current defaults were simply chosen based on an existing implementation of similar functionality. I agree, consistent defaults would be good, I'll review the default values in TR124i5 and adjust accordingly. > > The version of TR-124 referenced in the references section doesn't actual= ly include BFD echo requirements. The most recent version is TR-124i5, whic= h is available at https://www.broadband-forum.org/technical/download/TR-124= _Issue-5.pdf. Will update the reference. > > "If all DHCPv6 leases have expired, either naturally or proactively > with IPoE health checks, an IPoE client acting as a router, SHOULD > withdraw itself as a default router on the LAN, following requirement > G-5 of [RFC7084], Section 4.1." > Since the referenced RFC7084 requirement is a "MUST", I would make it a M= UST here, too. Good catch, will update. Thanks again for taking time to review the document. -Richard > > > > -----Original Message----- > > From: v6ops On Behalf Of Richard Patterson > > Sent: Tuesday, June 05, 2018 4:03 PM > > To: int-area@ietf.org; v6ops@ietf.org list ; dhcwg@ietf= .org > > Subject: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00 > > > > Hi All, > > > > The above new draft has been posted to address an operational problem > > that exists with current IPoE (non-PPPoE) fixed line broadband services= . > > It can be found here: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__datatracker.ietf.org_doc_draft-2Dpatterson-2Dintarea-2Dipoe- > > 2Dhealth_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3DFsoSwjTvxj08keS6f_DYpmlby-FM9C5m-G- > > VTwchGJI&s=3DPlUBOvZt82phRMfoJpQQ--BeqgUeIP_QKKl6uSOdXA4&e=3D > > > > Hopefully the draft covers the problem statement sufficiently, but in > > summary, PPPoE makes use of LCP echo/replies to detect WAN failures, > > DHCPv4/6 currently has no such mechanism. > > After backhaul migrations or BNG maintenance/failure, an IPoE client ca= n be > > left with a stale DHCP lease for up to the Valid Lifetime. > > > > This draft proposes the use of regular ARP and ND for link monitoring, = to > > proactively expire DHCP leases early, and to trigger renewals or gettin= g a new > > lease from scratch. > > > > The intarea WG was chosen as it doesn't neatly fit within the charters = of > > either v6ops or dhc, and because it proposes new DHCPv4 and DHCPv6 > > Options. Although we expect discussions in both of these WGs as well. > > > > Thanks for comments already received from Ian, and Bernie, that helped > > shape this -00. > > > > -Richard > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3DFsoSwjTvxj08keS6f_DYpmlby-FM9C5m-G- > > VTwchGJI&s=3DPQDjf2K7lKp7HxtDXAqe1ce3u8xCq8vLbnHcTQjgRlw&e=3D From nobody Thu Oct 4 03:34:01 2018 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 46431130E10; Thu, 4 Oct 2018 03:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5duS9zWelV2; Thu, 4 Oct 2018 03:33:45 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7977130DFB; Thu, 4 Oct 2018 03:33:45 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id B121DFECBC5C; Thu, 4 Oct 2018 10:33:44 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 6F4756E71B2; Thu, 4 Oct 2018 12:33:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Thu, 4 Oct 2018 12:33:42 +0200 Cc: Barbara H Stark , dhcwg@ietf.org, "v6ops@ietf.org list" , int-area@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <56B2584A-CD70-4EA9-A7B1-06447B0F1667@employees.org> References: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Richard Patterson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] [dhcwg] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 10:33:47 -0000 >> I'm not sure DHCP configuration is really needed. It seems like = overkill. >=20 > Other reviewers/commenters previously felt that this was a useful > addition. This would allow Network Operators to trigger or influence > the connectivity check on CE routers that they are not in TR.069/etc. > control of. Requiring the DHCP option makes a big difference in deployability. Without it, I can implement this feature today. With it, I have to wait = until the DHCP option is standardised. And we would presumably get into = a big debate about what CE routers should do in the cases where they = don=E2=80=99t get a DHCP option. Should they try this mechanism anyway? We have not requied explicit configuration in the other cases where we = have recommended this mechanism. Ref. RFC5969. While the echo mechanism requires some special provisioning on the local = system (ensure that ingress filtering isn=E2=80=99t blocking packets = with yourself as source) I am not aware of anything on the PE that woukd = block this. If there is consensus on that, I think it=E2=80=99s = perfectly fine to require this mechanism on by default in CE routers. Although we might add some specifics to deal with a case where DHCP was = successful, state in PE was correct, but health check still failed. Cheers, Ole= From nobody Thu Oct 4 03:48:33 2018 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 D3B7C130DFB for ; Thu, 4 Oct 2018 03:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6xPECGMX0y5 for ; Thu, 4 Oct 2018 03:48:24 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D564130E09 for ; Thu, 4 Oct 2018 03:48:24 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id p4-v6so7512665iom.3 for ; Thu, 04 Oct 2018 03:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3peoQ84tuA0S4WlhLcVpgLuQ9/ujrpNicrmApFSNebE=; b=uia6bdFWpGFgonSRqiVtLgIIcyKmP095IaPE425OCeRo3SuxdbBMn3wWFyXZm0F/dF PAP6cwR8SIlHuk+h3Stu3FKIklujo5hhHmnZEpAaUDCJ9kU8wVZZUZpG4SEP133lGUUE aNYjsAxigtvMhSq2NsOVZJ7pMP95xnE837pAriN8ORYE+/qr3khq9cDJFDv3I9N+B6sc DqwJdbotZlQiefEq/9C0zMXU2O0UkGcsqNQ6jDP9GB+hsjNHjX2zvCIl5sxa1Yqe30NM TbdTceVYecCb8X4h3zmJ+KoBzWqfA+4dXL5Zqf62yW7ERdR5Dn/71jDi08O+8fO6ZTvV SCow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3peoQ84tuA0S4WlhLcVpgLuQ9/ujrpNicrmApFSNebE=; b=RWnvjxxFmmyMLaNgcepkLlVRs+niACndAK1DOf9VnQe4RkTZB4fGIIJ6RyR1nBQ4zp 4uy1s0fHDiJzaS/sGzXxczyW4Ko7OmjANeeBu04WFymN0UPjsl1dISIK9hl6SPxR9Hq6 NWVRwmAqpyRH77PgCD85hj26Pn6MiH1CnbQOBhTSI2m6HOlAToD+yqBhUDtUMwxtgwzh Y1/auQUiTgTZ6WF7nRi7TqIUts9f8jSJinvmcbshaNauGJyiht8TlgbfWzl6ItYypolG DXhmnIXhYhci2sg0BrBfXatO6kZVzUbpIufq2fwl1XoyzwmLE08pkKTkqRsHrVxdGoqj H0zA== X-Gm-Message-State: ABuFfoi0wbJ28lsuiJp4YMAJ0U5B8/MTSYJDt6cSEMqiFFe0SEy98aby juAq0afoweUQrLNU+Z9tqmbwHw== X-Google-Smtp-Source: ACcGV62bvrSxVvtAApe7eHRvkjBnSGZesOpXh0bUdqi3qyrkm4AxPxMAlM9pKE/sE5yqfEJoM/cr3Q== X-Received: by 2002:a6b:f815:: with SMTP id o21-v6mr4155560ioh.203.1538650103624; Thu, 04 Oct 2018 03:48:23 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id q123-v6sm1344395iod.23.2018.10.04.03.48.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 03:48:23 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id q4-v6so7492654iob.8; Thu, 04 Oct 2018 03:48:22 -0700 (PDT) X-Received: by 2002:a6b:9b42:: with SMTP id d63-v6mr3652347ioe.183.1538650102782; Thu, 04 Oct 2018 03:48:22 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> <56B2584A-CD70-4EA9-A7B1-06447B0F1667@employees.org> In-Reply-To: <56B2584A-CD70-4EA9-A7B1-06447B0F1667@employees.org> From: Richard Patterson Date: Thu, 4 Oct 2018 11:48:11 +0100 X-Gmail-Original-Message-ID: Message-ID: To: otroan@employees.org Cc: dhcwg@ietf.org, "v6ops@ietf.org list" , int-area@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 10:48:27 -0000 On Thu, 4 Oct 2018 at 11:33, Ole Troan wrote: > Requiring the DHCP option makes a big difference in deployability. > Without it, I can implement this feature today. With it, I have to wait u= ntil the DHCP option is standardised. And we would presumably get into a bi= g debate about what CE routers should do in the cases where they don=E2=80= =99t get a DHCP option. Should they try this mechanism anyway? > > We have not requied explicit configuration in the other cases where we ha= ve recommended this mechanism. Ref. RFC5969. > > While the echo mechanism requires some special provisioning on the local = system (ensure that ingress filtering isn=E2=80=99t blocking packets with y= ourself as source) I am not aware of anything on the PE that woukd block th= is. If there is consensus on that, I think it=E2=80=99s perfectly fine to r= equire this mechanism on by default in CE routers. > Although we might add some specifics to deal with a case where DHCP was s= uccessful, state in PE was correct, but health check still failed. Perfectly valid reasoning. Personally I'm not too hung up on requiring the DHCP option, but thought it was useful. If we think it's going to be a large barrier to implementation, I'm happy to remove it and then emphasise the warmup period concerns within the Startup section. As a side-note, is it really that challenging or slow to get a new DHCP option assigned? Perhaps I'm showing my naivety here. -Rich From nobody Thu Oct 4 05:08:20 2018 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 39B59130E9A; Thu, 4 Oct 2018 05:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb8bukfSefUK; Thu, 4 Oct 2018 05:08:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7467130E9D; Thu, 4 Oct 2018 05:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2776; q=dns/txt; s=iport; t=1538654879; x=1539864479; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vXNSJLiW26XD3kMaqKs7vL43C2Z7NNKoptg3wseWUsM=; b=IZgOUxDxKa1fLvP4T0EaaWjf3yHeW7jW9BsHWZVw1jAcRuD0koIg+s1P o3RoweAiUlVhNZ5yrC1SA8pSPaUkgAlgYEUByZhSQFyG6e8sKCXser382 PUWGsAKK87DjR8+R/RiDEfGqHtwipsvy/ncs4eb410tLBLPYZONwrLgea 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAABwAbZb/4MNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBggVmfyiDdJQygWglmFgLAQEYC4RJAhe?= =?us-ascii?q?EDiE3Cg0BAwEBAgEBAm0cDIU5AQEBAQIBAQEhEToLBQsCAQgYAgImAgICJQs?= =?us-ascii?q?VEAIEDgWDIQGBeQgPo0yBLoQrAYVlBYELihkXggCBEicME4JMgxsBAYRiMYI?= =?us-ascii?q?mAohLNoZUjgEJApA+F4FMjh2JAYw2AhEUgSUzIoFVcBU7KgGCQYsWhT5vjRc?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.54,338,1534809600"; d="scan'208";a="464594269" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2018 12:07:58 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w94C7v0a004440 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Oct 2018 12:07:57 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 4 Oct 2018 07:07:57 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1395.000; Thu, 4 Oct 2018 07:07:57 -0500 From: "Bernie Volz (volz)" To: Richard Patterson CC: "otroan@employees.org" , "dhcwg@ietf.org" , "v6ops@ietf.org list" , "int-area@ietf.org" Thread-Topic: [v6ops] [dhcwg] Intro to draft-patterson-intarea-ipoe-health-00 Thread-Index: AQHUW8/e+NFOHuhxRkuDDpmQI2YBw6UO/iaR Date: Thu, 4 Oct 2018 12:07:57 +0000 Message-ID: <3F33CA22-0537-47E9-8AF2-863B9F1B6FB8@cisco.com> References: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> <56B2584A-CD70-4EA9-A7B1-06447B0F1667@employees.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 12:08:08 -0000 WW91ciBkcmFmdCwgaWYgYWR2YW5jZWQsIHdpbGwgZ2V0IHlvdSB0aGUgb3B0aW9ucyBkZWZpbmVk Lg0KDQpZb3Ugc2hvdWxkIHVwZGF0ZSB5b3VyIGRyYWZ0IHRvIGluY2x1ZGUgdGhlIG5ldyBpdGVt cyB0aGF0IGFyZSBiZWluZyBhZGRlZCB0byB0aGUgREhDUHY2IG9wdGlvbnMgdGFibGUgbWFpbnRh aW5lZCBieSBJQU5BOiB3aGV0aGVyIG9wdGlvbiBuZWVkcyB0byBiZSBpbiBPUk8gYW5kIHdoZXRo ZXIgaXQgaXMgc2luZ2xldG9uIG9wdGlvbiAoSSBiZWxpZXZlIHllcyB0byBib3RoIGlzIGFwcGxp Y2FibGUpLg0KDQotIEJlcm5pZQ0KDQo+IE9uIE9jdCA0LCAyMDE4LCBhdCA2OjQ5IEFNLCBSaWNo YXJkIFBhdHRlcnNvbiA8cmljaGFyZEBoZWxpeC5uZXQubno+IHdyb3RlOg0KPiANCj4+IE9uIFRo dSwgNCBPY3QgMjAxOCBhdCAxMTozMywgT2xlIFRyb2FuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4g d3JvdGU6DQo+PiBSZXF1aXJpbmcgdGhlIERIQ1Agb3B0aW9uIG1ha2VzIGEgYmlnIGRpZmZlcmVu Y2UgaW4gZGVwbG95YWJpbGl0eS4NCj4+IFdpdGhvdXQgaXQsIEkgY2FuIGltcGxlbWVudCB0aGlz IGZlYXR1cmUgdG9kYXkuIFdpdGggaXQsIEkgaGF2ZSB0byB3YWl0IHVudGlsIHRoZSBESENQIG9w dGlvbiBpcyBzdGFuZGFyZGlzZWQuIEFuZCB3ZSB3b3VsZCBwcmVzdW1hYmx5IGdldCBpbnRvIGEg YmlnIGRlYmF0ZSBhYm91dCB3aGF0IENFIHJvdXRlcnMgc2hvdWxkIGRvIGluIHRoZSBjYXNlcyB3 aGVyZSB0aGV5IGRvbuKAmXQgZ2V0IGEgREhDUCBvcHRpb24uIFNob3VsZCB0aGV5IHRyeSB0aGlz IG1lY2hhbmlzbSBhbnl3YXk/DQo+PiANCj4+IFdlIGhhdmUgbm90IHJlcXVpZWQgZXhwbGljaXQg Y29uZmlndXJhdGlvbiBpbiB0aGUgb3RoZXIgY2FzZXMgd2hlcmUgd2UgaGF2ZSByZWNvbW1lbmRl ZCB0aGlzIG1lY2hhbmlzbS4gUmVmLiBSRkM1OTY5Lg0KPj4gDQo+PiBXaGlsZSB0aGUgZWNobyBt ZWNoYW5pc20gcmVxdWlyZXMgc29tZSBzcGVjaWFsIHByb3Zpc2lvbmluZyBvbiB0aGUgbG9jYWwg c3lzdGVtIChlbnN1cmUgdGhhdCBpbmdyZXNzIGZpbHRlcmluZyBpc27igJl0IGJsb2NraW5nIHBh Y2tldHMgd2l0aCB5b3Vyc2VsZiBhcyBzb3VyY2UpIEkgYW0gbm90IGF3YXJlIG9mIGFueXRoaW5n IG9uIHRoZSBQRSB0aGF0IHdvdWtkIGJsb2NrIHRoaXMuIElmIHRoZXJlIGlzIGNvbnNlbnN1cyBv biB0aGF0LCBJIHRoaW5rIGl04oCZcyBwZXJmZWN0bHkgZmluZSB0byByZXF1aXJlIHRoaXMgbWVj aGFuaXNtIG9uIGJ5IGRlZmF1bHQgaW4gQ0Ugcm91dGVycy4NCj4+IEFsdGhvdWdoIHdlIG1pZ2h0 IGFkZCBzb21lIHNwZWNpZmljcyB0byBkZWFsIHdpdGggYSBjYXNlIHdoZXJlIERIQ1Agd2FzIHN1 Y2Nlc3NmdWwsIHN0YXRlIGluIFBFIHdhcyBjb3JyZWN0LCBidXQgaGVhbHRoIGNoZWNrIHN0aWxs IGZhaWxlZC4NCj4gDQo+IA0KPiBQZXJmZWN0bHkgdmFsaWQgcmVhc29uaW5nLiAgIFBlcnNvbmFs bHkgSSdtIG5vdCB0b28gaHVuZyB1cCBvbg0KPiByZXF1aXJpbmcgdGhlIERIQ1Agb3B0aW9uLCBi dXQgdGhvdWdodCBpdCB3YXMgdXNlZnVsLiBJZiB3ZSB0aGluayBpdCdzDQo+IGdvaW5nIHRvIGJl IGEgbGFyZ2UgYmFycmllciB0byBpbXBsZW1lbnRhdGlvbiwgSSdtIGhhcHB5IHRvIHJlbW92ZSBp dA0KPiBhbmQgdGhlbiBlbXBoYXNpc2UgdGhlIHdhcm11cCBwZXJpb2QgY29uY2VybnMgd2l0aGlu IHRoZSBTdGFydHVwDQo+IHNlY3Rpb24uDQo+IA0KPiBBcyBhIHNpZGUtbm90ZSwgaXMgaXQgcmVh bGx5IHRoYXQgY2hhbGxlbmdpbmcgb3Igc2xvdyB0byBnZXQgYSBuZXcNCj4gREhDUCBvcHRpb24g YXNzaWduZWQ/ICBQZXJoYXBzIEknbSBzaG93aW5nIG15IG5haXZldHkgaGVyZS4NCj4gDQo+IC1S aWNoDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Thu Oct 4 06:33:39 2018 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 75032130E0C; Thu, 4 Oct 2018 06:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmxo-nwVdcPw; Thu, 4 Oct 2018 06:33:20 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F155128CE4; Thu, 4 Oct 2018 06:33:20 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id B8600FECBE92; Thu, 4 Oct 2018 13:33:19 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id A414B6EAFC9; Thu, 4 Oct 2018 15:33:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Thu, 4 Oct 2018 15:33:16 +0200 Cc: dhcwg@ietf.org, "v6ops@ietf.org list" , int-area@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> <56B2584A-CD70-4EA9-A7B1-06447B0F1667@employees.org> To: Richard Patterson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] [dhcwg] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 13:33:23 -0000 Richard, > As a side-note, is it really that challenging or slow to get a new > DHCP option assigned? Perhaps I'm showing my naivety here. Getting the DHCP option itself isn=E2=80=99t hard. But then you need to = get it deployed in DHCP servers, you need to get it deployed in DHCP = clients. And you need to add linkage between the health checker and DHCP. Harder from implementors perspectiv and harder from deployers = perspective. Does the extra work add value? It is certainly going to add significant = amount of time. Cheers, Ole= From nobody Thu Oct 4 08:29:22 2018 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 50572130E48 for ; Thu, 4 Oct 2018 08:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSRXoITOOCOh for ; Thu, 4 Oct 2018 08:29:16 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A1B130E65 for ; Thu, 4 Oct 2018 08:29:14 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id p4-v6so8242719iom.3 for ; Thu, 04 Oct 2018 08:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iojHcArObX6ADJ445/7fANB1oj3JW0asrYIUH318jH4=; b=BreMY6mC+IIQpsg1M9OFdBXTZwkA6/37LhXixsD6WxxYm7mpeNJwHXu/Mpt56OjX7v AmRWHqXytRkYvCPVA5lSuB4RD7LMqUodA0olboQcC0h9hBiybAm6AfDuHOXktUZcOWLU Cl/8BIGswCyq1Euu3VrocOeyJxO9yjqH7v5j61MZKk5eXsCgz2HYQClmX2WxTqmPpAU8 QSbKBHMuNbVRjWGx0Vh2qxJLpl/f5SLiJlzvglVyldax+g5s9EReclWT5UYHmQtrmZwu kVvG4fBTTW0tHSIZk9xAhqUhaQnzPBMdim4jVqgYZVqyxIu8ZTu63iHOog4lSUEJPb4l sDoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iojHcArObX6ADJ445/7fANB1oj3JW0asrYIUH318jH4=; b=qk74jzKyobh+iHXvaSDTBc8mlAYAZLZeDbCNzrgBU61hMCESZZyEBU3MuKbF0uxcXu g2xs9wLhGB6NXzfqXpPsi6THFyqp3OpKsrmMVBSGP3nHgVZkQJ2yVF29Geoecfvg6rYV spIftZiGOBDANFex66Ba5YGPRJpP7gbYR/x/SaNlTaYtfrZ9vyHuUvgA7k1FscwXcLyh gjDHVCx2AWxtxxu+uZHbfqTi5zvaZgr4GSUxQcfohXbbzd3e6FJLojxSlaa7LN11Ct0k GbLg2Ry8c0tJisL78mu32n3RE7Reety9GRv0YIj+5g1f7L6j9mIhUu2mo/3e4HYse1OJ O5UQ== X-Gm-Message-State: ABuFfoh72nQDkAscoKwpeDCdfC7IB1JieTVIh9ixmx/99lZXD55TDwKX mtEw80r/ieVLmnQc5Ka2TyxN2w== X-Google-Smtp-Source: ACcGV630YWtOI70aMvGsyZk9WyvCvG6Rlx8Yzyqd6A5HxGyowIVgO01Se6VbljYjxfGWV2OnPXZoKA== X-Received: by 2002:a6b:144b:: with SMTP id 72-v6mr4746498iou.218.1538666954047; Thu, 04 Oct 2018 08:29:14 -0700 (PDT) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id 68-v6sm1400992iou.88.2018.10.04.08.29.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 08:29:13 -0700 (PDT) Received: by mail-it1-f171.google.com with SMTP id c23-v6so13652613itd.5; Thu, 04 Oct 2018 08:29:13 -0700 (PDT) X-Received: by 2002:a24:db05:: with SMTP id c5-v6mr5849794itg.44.1538666953142; Thu, 04 Oct 2018 08:29:13 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> <56B2584A-CD70-4EA9-A7B1-06447B0F1667@employees.org> In-Reply-To: From: Richard Patterson Date: Thu, 4 Oct 2018 16:29:01 +0100 X-Gmail-Original-Message-ID: Message-ID: To: otroan@employees.org Cc: dhcwg@ietf.org, "v6ops@ietf.org list" , int-area@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:29:21 -0000 Thanks Ole, understood. On Thu, 4 Oct 2018 at 14:33, Ole Troan wrote: > > Richard, > > > As a side-note, is it really that challenging or slow to get a new > > DHCP option assigned? Perhaps I'm showing my naivety here. > > Getting the DHCP option itself isn=E2=80=99t hard. But then you need to g= et it deployed in DHCP servers, you need to get it deployed in DHCP clients= . > And you need to add linkage between the health checker and DHCP. > > Harder from implementors perspectiv and harder from deployers perspective= . > > Does the extra work add value? It is certainly going to add significant a= mount of time. > > Cheers, > Ole From nobody Fri Oct 5 01:44:53 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8D7130DE1; Fri, 5 Oct 2018 01:44:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153872908765.1036.7578807869432966990@ietfa.amsl.com> Date: Fri, 05 Oct 2018 01:44:47 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 08:44:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-09.txt Pages : 22 Date : 2018-10-05 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is required in a world where public IPv4 addresses are no longer available for every possible customer. However, devices or applications in the customer LANs may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-09 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 5 01:50:45 2018 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 2F3C6130DE6 for ; Fri, 5 Oct 2018 01:50:44 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cADVtcMD3L-q for ; Fri, 5 Oct 2018 01:50:39 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA54130DD8 for ; Fri, 5 Oct 2018 01:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1538729437; x=1539334237; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=6MtCWfjy e4oKI1vFCsIL/Au+mMKjdwGfhPfgvIEA9lg=; b=Bj89siegWJJLyFjzZSDhRv2k 3ivEptQ+lZLd3Wf1lkVwvYVnnhvJ78DmuR9DFKocxdh5+tAMCKMxdOKp3w7HcQCG B6V95EjY5bUHIXE2B1SabuWb0YseDzv2b9tSmVESGBs2FUun7QcNa0ZcJB6HMKBT nMFqr3P/Cn/gf8rwl3w= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 05 Oct 2018 10:50:37 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 05 Oct 2018 10:50:36 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005897146.msg for ; Fri, 05 Oct 2018 10:50:35 +0200 X-MDRemoteIP: 2001:470:1f09:495:f1f2:ea:7bc9:ce4e X-MDHelo: [10.10.10.129] X-MDArrival-Date: Fri, 05 Oct 2018 10:50:35 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1816aa4bb3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Fri, 05 Oct 2018 10:50:34 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <2BB1B5F0-761E-4228-A83F-4C6488866198@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-09.txt References: <153872908765.1036.7578807869432966990@ietfa.amsl.com> In-Reply-To: <153872908765.1036.7578807869432966990@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 08:50:44 -0000 Hi all, In discussions with the AD and co-chairs, we decided to post a new version = with mainly editorial changes in order to clarify some text. https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Main change, not affecting the scope neither the intent of the document, wa= s to break down between transition requirements and config steps in section= 3.2.: General transition requirements: =20 TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026] (Unified IPv4-in- IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism). =20 TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or API option to manually enable/disable each of the supported transition mechanisms. =20 TRANS-3: If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv6 Transition CE Router MUST allow appropriate subnetting and configuring the address space (which may depend on each transition mechanism) among the several interfaces. In some transition mechanisms, this may require differentiating mappings/translations per interfaces. =20 In order to allow the service provider to disable all the transition mechanisms and/or choose the most convenient one, the IPv6 Transition CE Router MUST follow the following configuration steps: =20 CONFIG-1: Request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step. =20 CONFIG-2: Following Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which allows enabling/ disabling a transition mechanism. =20 CONFIG-3: Keep disabled all the transition mechanisms if no match is found between the priority list and the candidate list. =20 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: viernes, 5 de octubre de 2018, 10:46 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-09.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-09.txt Pages : 22 Date : 2018-10-05 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is required in a world where public IPv4 addresses are no longer available for every possible customer. However, devices or applications in the customer LANs may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-09 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-09 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -09 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sat Oct 6 06:07:30 2018 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 6DC2B130DEC for ; Sat, 6 Oct 2018 06:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18J7Voz2Lkfz for ; Sat, 6 Oct 2018 06:07:25 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29D7130DE1 for ; Sat, 6 Oct 2018 06:07:24 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-44-121.kabelnet.hu [79.121.44.121]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w96D7EAU092074 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 6 Oct 2018 15:07:20 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-44-121.kabelnet.hu [79.121.44.121] claimed to be [192.168.1.119] References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org list" From: =?UTF-8?Q?Lencse_G=c3=a1bor?= X-Forwarded-Message-Id: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> Message-ID: <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> Date: Sat, 6 Oct 2018 15:07:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------E50C5B2219A72F3EDB97B291" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.44.121; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 13:07:29 -0000 This is a multi-part message in MIME format. --------------E50C5B2219A72F3EDB97B291 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear v6ops Members, We have prepared the "-00" version of our I-D "Pros and Cons of IPv6 Transition Technologies for IPv4aaS". Thank you very much for everyone, who have given us input through the previous discussion on this list or through the Google spreadsheet, which is still available at: https://docs.google.com/spreadsheets/d/1W3Px8I_RyLA_tnmmNkJj6qJS0tvg93oCU0XfZzlljto/edit#gid=0 Could you give us further feedback? Thank you very much for your help in advance! Best regards, Gábor Lencse -------- Továbbított üzenet -------- Tárgy: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt Dátum: Sat, 06 Oct 2018 05:52:11 -0700 Feladó: internet-drafts@ietf.org Címzett: Lee Howard , Jordi Palet , Jordi Palet Martinez , Gabor Lencse , Richard Patterson A new version of I-D, draft-lmhp-v6ops-transition-comparison-00.txt has been successfully submitted by Gabor Lencse and posted to the IETF repository. Name: draft-lmhp-v6ops-transition-comparison Revision: 00 Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS Document date: 2018-10-06 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-00.txt Status: https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ Htmlized: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison Abstract: Several IPv6 transition technologies can be used to provide IPv4-as- a-service (IPv4aaS) to the customers, while the ISPs have only IPv6 in their access and or core network. All these technologies have their advantages and disadvantages. Depending on several various conditions and preferences, different technologies may prove to be the most appropriate solution. This document examines the five most prominent IPv4aaS technologies considering several different aspects in order to provide network operators with an easy to use guideline for selecting the technology that suit their needs the best. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------E50C5B2219A72F3EDB97B291 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear v6ops Members,
 
We have prepared the "-00" version of our I-D "Pros and Cons of IPv6 Transition Technologies for IPv4aaS".

Thank you very much for everyone, who have given us input through the previous discussion on this list or through the Google spreadsheet, which is still available at: https://docs.google.com/spreadsheets/d/1W3Px8I_RyLA_tnmmNkJj6qJS0tvg93oCU0XfZzlljto/edit#gid=0

Could you give us further feedback?

Thank you very much for your help in advance!

Best regards,

Gábor Lencse

-------- Továbbított üzenet --------
Tárgy: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt
Dátum: Sat, 06 Oct 2018 05:52:11 -0700
Feladó: internet-drafts@ietf.org
Címzett: Lee Howard <lee@asgard.org>, Jordi Palet <jordi.palet@theipv6company.com>, Jordi Palet Martinez <jordi.palet@theipv6company.com>, Gabor Lencse <lencse@hit.bme.hu>, Richard Patterson <richard.patterson@sky.uk> 


A new version of I-D, draft-lmhp-v6ops-transition-comparison-00.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

Name:		draft-lmhp-v6ops-transition-comparison
Revision:	00
Title:		Pros and Cons of IPv6 Transition Technologies for IPv4aaS
Document date:	2018-10-06
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
Htmlized:       https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison


Abstract:
   Several IPv6 transition technologies can be used to provide IPv4-as-
   a-service (IPv4aaS) to the customers, while the ISPs have only IPv6
   in their access and or core network. All these technologies have
   their advantages and disadvantages. Depending on several various
   conditions and preferences, different technologies may prove to be
   the most appropriate solution. This document examines the five most
   prominent IPv4aaS technologies considering several different aspects
   in order to provide network operators with an easy to use guideline
   for selecting the technology that suit their needs the best.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------E50C5B2219A72F3EDB97B291-- From nobody Sat Oct 6 08:24:07 2018 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 9391B127333 for ; Sat, 6 Oct 2018 08:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGBgGej0jOq3 for ; Sat, 6 Oct 2018 08:24:03 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1720912426A for ; Sat, 6 Oct 2018 08:24:02 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id CD69FC1632 for ; Sat, 6 Oct 2018 10:24:01 -0500 (CDT) Received: from imsva1.bcbsm.com (inetmta03.bcbsm.com [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6B729C1626; Sat, 6 Oct 2018 10:24:00 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 291E092057; Sat, 6 Oct 2018 11:24:00 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 95F3592053; Sat, 6 Oct 2018 11:23:59 -0400 (EDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (unknown [216.32.180.184]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sat, 6 Oct 2018 11:23:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Itbh9LQfzyA/vU/oe1SK3C497IoJn7IsvtUQ7wc72Y0=; b=kzxzfIXuzaoCZKlOM0jyrzpHS4r6PxbUFs6Yf1ysqx5ArJ0tBHoPT/FG5gZh/hyq0agPEWt8vJlrzogMSIZyFQAa5ozp2OA6Q/I2c76nOfcSwhX1mxDeDRwgANs33bnsuVnN1EDr55OK6XyFohFSMVTui0GRn57kRyrE2d6VQLU= Received: from CY1PR14MB0842.namprd14.prod.outlook.com (10.169.21.22) by CY1PR14MB0552.namprd14.prod.outlook.com (10.164.71.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.27; Sat, 6 Oct 2018 15:23:57 +0000 Received: from CY1PR14MB0842.namprd14.prod.outlook.com ([fe80::9ef:37e:d8e5:6dc]) by CY1PR14MB0842.namprd14.prod.outlook.com ([fe80::9ef:37e:d8e5:6dc%4]) with mapi id 15.20.1207.024; Sat, 6 Oct 2018 15:23:57 +0000 From: "Ackermann, Michael" To: Fred Baker , Alexandre Petrescu CC: "v6ops@ietf.org" , nalini elkins Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group Thread-Index: AQHUVfmCZKe6z17P9kiGHqU7nh5Qq6UF7ccAgAAXzYCADF7lcA== Date: Sat, 6 Oct 2018 15:23:57 +0000 Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; x-originating-ip: [165.225.0.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR14MB0552; 20:Z1yMuLnuiqjMe+Dwmzs2jB4ZQ75wXQ3hv3PTsx6o+ga19QNXtA3LJSMMFkjyHEoPoEpaqKC6neM90nRfl19MQG/WMMDiAo8Sggt/3i+LevFRWQn4v7jRsvxSfSitcRhWqibn8XRHsYiPMz3pxQUh0PzKx23cdmeI9gjH6RRkJE0= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 48195b95-6b3c-46f9-087b-08d62b9fbc4e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7167020)(7153060)(7193020); SRVR:CY1PR14MB0552; x-ms-traffictypediagnostic: CY1PR14MB0552: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991055); SRVR:CY1PR14MB0552; BCL:0; PCL:0; RULEID:; SRVR:CY1PR14MB0552; x-forefront-prvs: 0817737FD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(39860400002)(376002)(346002)(13464003)(189003)(199004)(486006)(9686003)(8676002)(110136005)(68736007)(2900100001)(53936002)(3846002)(6116002)(476003)(81166006)(6246003)(446003)(66066001)(102836004)(54906003)(11346002)(25786009)(81156014)(256004)(316002)(4326008)(93886005)(86362001)(7696005)(186003)(39060400002)(72206003)(6506007)(14454004)(5660300001)(8936002)(76176011)(99286004)(2906002)(53546011)(80792005)(5250100002)(33656002)(105586002)(7736002)(55016002)(6436002)(229853002)(74316002)(478600001)(97736004)(26005)(55236004)(71190400001)(71200400001)(305945005)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR14MB0552; H:CY1PR14MB0842.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VUxkuvKP4GMcVrDx6CiqEHQooB+apv+TeWeSPEvravd28rtqpe/nRpV8sotLyUDsJjyntOIzdedD9oSlKFGmJv096HqBhnxbE5krxZcd0/hG5FqQlHtdGgbJbmf5+iXwruMwiYdbhl9aQvQG7N7p34dPqamqlAwZ2EPL++YS0CjqAPaaOrLrRedB0kyOO8mdrp5vAXFJww7IO4ahCxikD/kzWXvAs+mzJg8kNTNrI59wPTlcqE9ZaVSQQgSDeH5Xj3bdzDgr97DMHEkin/i92ud3XsPhbs16aQmEuTUD4c9kPGV+r9Php/KCmgmLrygMowrtRHUYwfcLI7Z9u0pO6s3CYlaMrMsvc8Wr9QKYqdU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48195b95-6b3c-46f9-087b-08d62b9fbc4e X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2018 15:23:57.7488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR14MB0552 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 14b6b7e4-08c9-4947-a50b-8dbffe90cf6d X-VPM-MSG-ID: 3e94f839-d493-4c15-8f12-08e42850bb7f X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 15:24:06 -0000 Fred A big +1 on your great comments below.=20 I especially like your last sentence, which is a keeper for me=21 = The itemized charging for separate protocols and required services is = probably the =231 thing that will finally get the attention of us = Enterprises Ostriches, that currently have our heads in the ground on = these issues.=20 Thanks again=21 Mike -----Original Message----- From: v6ops On Behalf Of Fred Baker Sent: Friday, September 28, 2018 2:26 PM To: Alexandre Petrescu Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D Trajectory for =22transition=22 mechanisms in our = working group On Sep 28, 2018, at 10:01 AM, Alexandre Petrescu = wrote: > In that sense, I think IPv6 and IPv4 side by side as a double stack is=20 > still a viable evolution in the next decades, although not very fancy. As I theorized the other day, I suspect that the IPv4 Internet becomes = something strictly at the edge. It might very well be dual stack within = the edge network, but it will come to a NAT of some kind before it leaves = the premises. The ISPs run IPv6-only, and they serve residential and = mobile customers/services using it. CLAT-PLAT translation means that the = ISP doesn't have to think about it too much; lw4o6 tunnels become a = network of their own that someone has to manage. As much as I dislike = LISP, LISP might be a rational tunneling technology; it allows for the = dynamic creation of tunnels whenever and wherever needed, which would be = useful for enterprise connection to its hosting sites and business partners. Also, I suspect that said aftermarket business becomes a PITA that people = charge to support. Given the choice of a bill for one protocol or a bill = for two separate protocols with some sort of PLAT or tunnel endpoint = support built in, expect customers to stop asking about a business case = and start asking about reducing their costs. ---------------------------------------------------------------------------= ----- Victorious warriors win first and then go to war, Defeated warriors go to = war first and then seek to win. Sun Tzu The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Sat Oct 6 23:34:12 2018 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 7D6B9129C6A for ; Sat, 6 Oct 2018 23:34:11 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l670v8mMxsF1 for ; Sat, 6 Oct 2018 23:34:09 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DAF128D0C for ; Sat, 6 Oct 2018 23:34:09 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id o14so1115705oth.4 for ; Sat, 06 Oct 2018 23:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=OI2GdX9N8Z2DzlZOXFAM/Q3P032WWln24+CIebPz308=; b=iFkAWiBpxUNjcCz4pZyKlxJu00+yoo4cjBKIflpFmTK9IP6Xvr4uV7sUwyGRBO5nQO L02XCGvs+6HUippw+l21VIomHVvp1r+kJBTnOmq5jU4+Aof58qHQ7azd/B4xOXvUL+eT VFQpIrP9nJE3ptyoop1vNofVB93uVkzvbW5XADz2vMy0kjnJ6syhzrio8D4fwYKyTaqN scXhvy9Ofv+vvp5bYy/UZqJzppkQ+UhtRuUAausyR9wa5DqMkEudAuW+1JQ1qpazcc8N UaleTg9ZLWLnhKtS/fsIkkCzbh16TwfBg+2HNQ37rG5PfV6Y1phDboT8cxw0aZarWhzy HI5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=OI2GdX9N8Z2DzlZOXFAM/Q3P032WWln24+CIebPz308=; b=k3TzI70lsHwv3Q/B0NK8Jy2RZ/uhEOlmWs1YlZBHmA8GXIlTiXlgkSbwn/HAWR4JFt qQVz/3ida7odoewjxFDDdb3nXhFYOhAisf+b5zwb92b85so8b6KgGZPqBpWWvA+qE5cW JIGwxZ3rnIh6p3N5+IOXJL/hJuvqBsIWVzjbfRQZyHfndm64pT1kROw9sClyrDP1NiXJ iM0fFY2EqkG3YfVvvJIrYflNSN5rnzzmFgLk15aDi+4gzOL9h7/4nYHHWRc91f2Bt+JY OOvmcCZnwxAonuvwSJFpQXGlj+nzAn4bsNa8HsKYmCXTLS6ORvsnGOBpTWY4lxYWAsIi Ok+A== X-Gm-Message-State: ABuFfoj1a01bAGoXw1HJQmKulish+8WP35iqu8y6GDku88u4bAznwqHi nIVn4S4FkmDxOJJZ6nXmv+J/Ybuj X-Google-Smtp-Source: ACcGV60gAquDS0lmxQAkzlaEoZDPiB9V+dZcXT1r3qtWBwiG+n85dmEQeas+uc9tzoVOH4vzfS6Fsg== X-Received: by 2002:a9d:86b:: with SMTP id 98mr6636454oty.275.1538894047794; Sat, 06 Oct 2018 23:34:07 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::100e? ([2600:8802:5600:1546::100e]) by smtp.gmail.com with ESMTPSA id u11sm3093772otc.14.2018.10.06.23.34.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Oct 2018 23:34:06 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_2CD648AD-C8BA-44C6-A14B-B038EAC53AD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 6 Oct 2018 23:34:05 -0700 References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> To: "v6ops@ietf.org list" In-Reply-To: <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> Message-Id: <90B53DE9-8F0B-46E8-A1C9-3FDA47F21501@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 06:34:12 -0000 --Apple-Mail=_2CD648AD-C8BA-44C6-A14B-B038EAC53AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What may not be clear from Lencse's email (I managed to miss it at first = glance) is that he not only has a google sheet up, but a posted draft. = We'd be interested in folks' comments on the draft as well. > On Oct 6, 2018, at 6:07 AM, Lencse G=C3=A1bor = wrote: >=20 > Dear v6ops Members, >=20 > We have prepared the "-00" version of our I-D "Pros and Cons of IPv6 = Transition Technologies for IPv4aaS". >=20 > Thank you very much for everyone, who have given us input through the = previous discussion on this list or through the Google spreadsheet, = which is still available at: = https://docs.google.com/spreadsheets/d/1W3Px8I_RyLA_tnmmNkJj6qJS0tvg93oCU0= XfZzlljto/edit#gid=3D0 >=20 > Could you give us further feedback? >=20 > Thank you very much for your help in advance! >=20 > Best regards, >=20 > G=C3=A1bor Lencse >=20 > -------- Tov=C3=A1bb=C3=ADtott =C3=BCzenet -------- > T=C3=A1rgy: New Version Notification for = draft-lmhp-v6ops-transition-comparison-00.txt > D=C3=A1tum: Sat, 06 Oct 2018 05:52:11 -0700 > Felad=C3=B3: internet-drafts@ietf.org > C=C3=ADmzett: Lee Howard , Jordi Palet = , Jordi Palet Martinez = , Gabor Lencse , = Richard Patterson >=20 > A new version of I-D, draft-lmhp-v6ops-transition-comparison-00.txt > has been successfully submitted by Gabor Lencse and posted to the > IETF repository. >=20 > Name: draft-lmhp-v6ops-transition-comparison > Revision: 00 > Title: Pros and Cons of IPv6 Transition Technologies = for IPv4aaS > Document date: 2018-10-06 > Group: Individual Submission > Pages: 11 > URL: > = https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-compariso= n-00.txt >=20 > Status: > = https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ >=20 > Htmlized: > https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00 >=20 > Htmlized: > = https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparis= on >=20 >=20 >=20 > Abstract: > Several IPv6 transition technologies can be used to provide = IPv4-as- > a-service (IPv4aaS) to the customers, while the ISPs have only IPv6 > in their access and or core network. All these technologies have > their advantages and disadvantages. Depending on several various > conditions and preferences, different technologies may prove to be > the most appropriate solution. This document examines the five most > prominent IPv4aaS technologies considering several different = aspects > in order to provide network operators with an easy to use guideline > for selecting the technology that suit their needs the best. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_2CD648AD-C8BA-44C6-A14B-B038EAC53AD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlu5qN0ACgkQEhdRnd2G P+AC7RAApUzE53/7+jMN//8DQm+1LLEv0sJ8AT3rmHski/BACjhMhHM7nsTISh/K DW22yVyecKSXAHzp6pxt9PNctK53qMTR1vQ62x3XESFwz9xIRrh0VQ9n75BF9iWy s+ip34rXmz87ggf3ExBWE9PTjVl8b4EnT2qpy3wtcz0qXSRBWlu27mzMisNzFk+W hc0ut4e1737s8st9JWdfC9EwW0CtxTgRg8P/lN3/LiU8SQeRZThJQKHKGC3M1XLJ 0WfgL1gsMb8P5rgfzBsb/GqLcqBbdjDDs/rjxYQvHzkzy5vDXjqv0IG7b5D5+hwx dsiNy8FC3SZG6w/FsfjvHLfAFAPAP8tgpAbRUvObeGRzYtIx9MC0vA3yKPE0ib7L U+lCrMqwOWF2jn1oE7IRO5lXB0RcxOou2VZCv8HaOPvVF/x4qyrriw9pqVNuH8oy uFC67JPetDAFsD9t3KTDBiYLPPIBUtmFrJWusTGqNFCtXd0E0wrhJxqpWmimgo5J hSvCHDWNBwYsO4x4yJM7jBeDuGPYgymJhdmD8kIeU1AdLN86k9CP/ob9H0KIdu7x rpu6GPYYqmAD6B6BbU8IjqPSMATnnZXaobs/jMS9FLoBVap/lvxXV2+ko/OqPZ4j y4ALYWZ7SPE31wKTGdhr52LhCFPZqok9v8Q0v1kjYL0NT3ES7Ak= =rweA -----END PGP SIGNATURE----- --Apple-Mail=_2CD648AD-C8BA-44C6-A14B-B038EAC53AD2-- From nobody Mon Oct 8 01:35:34 2018 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 EDFBD12F295 for ; Mon, 8 Oct 2018 01:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksS7toWry-_K for ; Mon, 8 Oct 2018 01:35:28 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8BD12F1A6 for ; Mon, 8 Oct 2018 01:35:28 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id DB444FECBFF9; Mon, 8 Oct 2018 08:35:23 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 595A370DEE9; Mon, 8 Oct 2018 10:35:16 +0200 (CEST) From: Ole Troan Message-Id: <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF73F264-9AA5-4F9B-9C3D-59332BEBF17A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 8 Oct 2018 10:35:15 +0200 In-Reply-To: <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> Cc: "v6ops@ietf.org list" To: =?utf-8?Q?Lencse_G=C3=A1bor?= References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 08:35:33 -0000 --Apple-Mail=_BF73F264-9AA5-4F9B-9C3D-59332BEBF17A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Comments inline. Look for @@OT. Ole IPv6 Operations Working Group G. Lencse Internet Draft BUTE Intended status: Informational J. Palet Martinez Expires: April 2018 The IPv6 Company L. Howard Retevia R. Patterson Sky UK October 6, 2018 Pros and Cons of IPv6 Transition Technologies for IPv4aaS draft-lmhp-v6ops-transition-comparison-00.txt Abstract Several IPv6 transition technologies can be used to provide IPv4-as- a-service (IPv4aaS) to the customers, while the ISPs have only IPv6 in their access and or core network. All these technologies have their advantages and disadvantages. Depending on several various conditions and preferences, different technologies may prove to be the most appropriate solution. This document examines the five most prominent IPv4aaS technologies considering several different aspects in order to provide network operators with an easy to use guideline for selecting the technology that suit their needs the best. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Lencse et al. Expires April 6, 2019 [Page 1] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 This Internet-Draft will expire on April 6, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 3 2. High-level Architectures and their Consequences ............. 3 2.1. Service Provider Network Traversal ..................... 3 2.2. IPv4 Address Sharing ................................... 4 3. More Detailed Analysis ...................................... 4 3.1. Details of Architectural Differences ................... 4 3.1.1. 464XLAT ........................................... 4 3.1.2. DS-Lite ........................................... 4 3.1.3. Lw4o6 ............................................. 4 3.1.4. MAP-E ............................................. 5 3.1.5. MAP-T ............................................. 5 3.2. Tradeoff between Port Number Efficiency and Stateless Operation .............................................. 5 3.3. Support for Server Operation ........................... 6 3.4. Support and Implementations ............................ 6 3.4.1. OS Support......................................... 6 3.4.2. Support in Cellular and Broadband Networks......... 6 3.4.3. Implementation Code Sizes ......................... 6 4. Performance Comparison ...................................... 7 5. Security Considerations ..................................... 7 6. IANA Considerations ........................................ 8 7. Conclusions ................................................. 8 8. References .................................................. 8 8.1. Normative References ................................... 8 8.2. Informative References ................................. 9 9. Acknowledgments ............................................ 10 Lencse et al. Expires April 6, 2019 [Page 2] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 1. Introduction IETF has standardized a high number of IPv6 transition technologies [Len2017] and occupied a neutral position trusting the selection to the market. In the upcoming years, several network operators would like to get rid of the burden of maintaining IPv4 in their access and/or core networks. This document deals with five different solutions, each of which can be used to provide an IPv4 service using an IPv6-only access/core network. The following IPv6 transition technologies are covered: 464XLAT [RFC6877], DS-Lite (Dual Stack Lite) [RFC6333], lw4o6 (Lightweight 4over6) [RFC7596], MAP-E [RFC7597] and MAP-T [RFC7599]. 2. High-level Architectures and their Consequences 2.1. Service Provider Network Traversal As for the high-level solution of the IPv6 service provider network traversal, MAP-T use double translation (first at the CE from IPv4 to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service provider network), 464XLAT may use single (NAT64, IPv6 to IPv4) or double translation (as MAP-T), depending on different factors, such as the use of DNS by the applications and the availability of a DNS64. DS-Lite, lw4o6 and MAP-E encapsulate the IPv4 packets into IPv6 packets. Each solution has its own advantages and drawbacks. Double translation results in only 20 bytes overhead (the difference in the minimum header size between IPv4 and IPv6), whereas the overhead of the encapsulation is 40 bytes (because both, the IPv4 and IPv6 headers are needed, compared with only the IPv4 one). The difference may be significant in the case of small packet sizes or when the larger one results in fragmentation. @@OT: Both MAP-T and 464XLAT uses double translation. Traditionally NAT64 hasn=E2=80=99t been considered an IPv4aaS solution. If you want to include it, treat it as a separate solution. The NAT64 in both solution can be =E2=80=9Creused" in a IPv6 = host/application scenario. s/compared with only the IPv4 one/compared with only the IPv6 one On the one hand, the first step of the double translation case is a stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP Translation Algorithm) [RFC7915], which does not translate IPv4 options and/or multicast IP/ICMP packets, whereas with encapsulation-based technologies these remain intact. @@OT None of the sharing solutions would =E2=80=9Cnatively=E2=80=9D do = multicast. On the other hand, single and double translation results in "normal" IPv6 traffic which can be inspected, e.g., by hashing algorithms, and firewalls, whereas encapsulation results in IPv4-embedded IPv6 packets and their interpretation requires special software/hardware for DPI (deep-packet-inspection). @@OT Replace =E2=80=9CDPI" with, looking further into the packet. This isn=E2=80=99t what we tradtionally think of as DPI. Note that this argument goes both ways. Because these middleboxes might want to =E2=80=9Ctreat=E2=80=9D the packet as an IPv4 one, and = have to reverse-engineer the IPv4 header. The worst case is DS-Lite, which is also doing double stateful translation (NAT44 at the CE, NAT44 at the AFTR). @@OT Actually the worst case is typical deployments of 464XLAT which does 3 = stateful translations. NAT44, NAT46 and NAT64. Lencse et al. Expires April 6, 2019 [Page 3] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 Another consequence is that the solutions using double translation can carry only TCP, UDP or ICMP over IP, when they are used with IPv4 address sharing (please refer to section 3.3 for more details), whereas the solutions using encapsulation can carry any other protocols over IP, too. @@OT That=E2=80=99s incorrect. There is nothing in the = translation/encapsulation difference=20 that affects carrying other IP protocols. IP address sharing is the one = that=20 breaks that (since you must forward based on L4 information). 2.2. IPv4 Address Sharing All five technologies support IPv4 address sharing, which has severe consequences described in [RFC6269]. The efficiency of the address sharing of the five technologies is significantly different, it is discussed in section 3.2. We note that lw4o6, MAP-E and MAP-T may not necessarily be configured to do IPv4 address sharing, see the details in Section 3.3, however in that case there is no advantage in terms of public IPv4 addresses saving. @@OT Correct, but there is an advantage in that you can deliver a complete = IPv4 address (or prefix) to customers who require use of other protocols than TCP or UDP. 3. More Detailed Analysis 3.1. Details of Architectural Differences 3.1.1. 464XLAT CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915]. It uses IPv4-embedded IPv6 addresses [RFC6052] for both source address and destination address. PLAT performs stateful NAT64 [RFC6146]. @@OT Or in the case of the use of a single IPv6 address it uses stateful = translation. So in the case of a 464XLAT router, it has stateful NAT44, stateful = NAT46 and stateful NAT64. Note that we generally don=E2=80=99t see state close to the end-user as = equally problematic as state in the middle of the network. 3.1.2. DS-Lite The B4 (Basic Bridging BroadBand) element encapsulates the IPv4 packets into IPv6 packets. The AFTR (Address Family Transition Router) de-encapsulates the IPv4 packets from the IPv6 packets and performs stateful NAPT (Network Address and Port Translation). 3.1.3. Lw4o6 Lightweight 4over6 is a variant of DS-Lite. The difference is, that the stateful NAPT is moved from the AFTR to the B4 element. It uses a provisioning mechanism to determine the size of the limited port set per user. @@OT Or you can say that LW46 is a subset of MAP, as it uses the same = provisioning, the same port mapping algorithm, and is indistinguishable from MAP-E in = 1:1 mode. Lencse et al. Expires April 6, 2019 [Page 4] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 3.1.4. MAP-E The CE (Customer-Edge) router first encapsulates IPv4-in-IPv6. Packets must traverse a MAP BR to be [de-]encapsulated. @OT All MAP based solutions also support mesh, i.e. direct communication = between CEs, so this statement is not strictly speaking correct. 3.1.5. MAP-T The CE (Customer Edge) router first performs a NAT44 to transform the source addresses and source port numbers of the IPv4 packets into a predefined range, the size of which is a design parameter. The CE router then performs stateless translation from IPv4 to IPv6 [RFC7915], which translates the IPv4 address and the port numbers into the IPv6 address space. The transformations may be fine-tuned by the mapping rules. The MAP BR (Border Relay) performs stateless translation from IPv4 to IPv6 [RFC7915]. @@OT You might qualify this with =E2=80=9CWhen doing IPv4 address sharing=E2=80= =9D. Also note that the same NAT44 process happens with MAP-E, and LW46. 3.2. Tradeoff between Port Number Efficiency and Stateless Operation 464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices, respectively. This may cause scalability issues. Lw4o6, MAP-E and MAP-T avoid using NAPT in the service provider network. Its cost is that they have to limit the port numbers available for a user, which is also the case for DS-Lite. Determining the optimal size of the @@OT Incorrect with regards to DS-lite. Note, that all CGN solutions will limie the port numbers available. The difference is that in A+P solutions then the port range is fixed. But customers can get a full IPv4 address if required. While in the CGN solutions the limit is more dynamic / centrally = adjustable. port set is not an easy task. On the one hand, the lack of port situation may cause serious problems in the operation of certain programs (e.g. the consequences of the session number limitation due to port number shortage were impressively demonstrated using Google Map in [Miy2010]). The port number consumption of different applications is highly varying and e.g. in the case of web browsing it depends on several factors [Rep2014]. And there may be several users behind a CPE, especially in the wired case (e.g. Internet is used by different members of a family simultaneously), thus sometimes even a few thousands ports may not be enough. @@OT This sounds a little opinionated. Adding some numbers/references to this section might help. In an endpoint-dependent NAT, you only need enough ports to cover the = number of sessions to the same destination address / port. So with 16 ports, you are restricted to 16 sessions to destination A = port P, but you can reuse those 16 ports to destination A port P+1, and = destination B, port P. However, on the other hand, assigning too many ports per user will result in waste of public IPv4 addresses, which is a scarce and expensive resource. Therefore, 464XLAT is much more efficient in terms of port number and thus public IP address saving. The price is the stateful operation in the service provider network, which is allegedly does not scale up well. XXX MEASUREMENTS ARE PLANNED TO DECIDE IF IT IS TRUE. XXX @@OT Replace 464XLAT with CGN or centralized NAT, cause this applies to=20 all the solutions that use CGN. NAT444, DS-lite, NAT64. With regards to the =E2=80=9Callegedly scale=E2=80=9D=E2=80=A6 I would = think that obvious, but apparently not. Let me give you a challenge then. Let=E2=80=99s say you have a device that can do 500Gbps ofg IPv4aaS = traffic. The total amount of IPv4 traffic the site must handle is 5Tbps. How do you scale this? With A+P solutions you simply stack 10 of these = devices and run ECMP to load-balance across them. If you want to take one out of = service you simply pull that one out of the ECMP bundle. Now for stateful NAT, tell me how you want to do it. We also note that NAT64 does not pre-allocate ports for customers but allocates them "on the fly" (which means that even the same customer is using ports from different addresses, and most of the time, different customers get ports from any given addresses), and in fact this creates many application/service providers (Sony @@OT That=E2=80=99s dependent on the NAT64 setup. We can very well do = deterministic stateful NAT too. And you could reserve a fixed set of ports for each customer, just like = A+P. There is nothing inherit in the mechanism in NAT64. The downside of not pre-allocated ports / indeterministic NAT, is = logging requirements are much higher. You should add logging as a separate section, if you = don=E2=80=99t have it. Lencse et al. Expires April 6, 2019 [Page 5] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 PlayStation Network, OpenDNS, etc.) to permanently black-list the IPv4 ranges once they are detected to be used for address sharing. 3.3. Support for Server Operation Lw4o6, MAP-E and MAP-T may be configured without IPv4 address sharing, allowing exclusive use of all ports, and non-port-based layer 4 protocols. Thus, they may also be used to support server operation, when public IPv4 addresses are assigned to the subscribers, however, then there is no advantage in terms of IPv4 public addresses saving. It is also possible to configure specific ports mapping in 464XLAT/NAT64 using EAMT [RFC7757], which means that only those ports are "lost" from the pool of addresses, so there is a higher maximization of the total usage of IPv4/port resources. @@OT That is also possible in A+P. E.g. you can route port 80 to a particular = CPE. In both cases that complicates provisioning. Which is another section you should probably add. 3.4. Support and Implementations 3.4.1. OS Support As for 464XLAT, client support exists in Windows 10, Linux (including Android), Windows Mobile, and Chrome OS, but it is missing from iOS and MacOS. For the other four solutions, we are not aware of any OS support. @@OT IPv4aaS is typically thought of as something running on an CE router. You may run it on a host, and in the 464XLAT that is a mobile phone, acting as a NAT/router. At least I=E2=80=99m not aware of very much of a use case for IPv4aaS = host support, so I=E2=80=99m not sure this section adds very much. 3.4.2. Support in Cellular and Broadband Networks Several cellular networks use 464XLAT, whereas we are not aware of any deployment of the four other technologies in cellular networks, as they are not supported. In broadband networks, there are some deployments of 464XLAT, MAP-E and MAP-T. Both, lw4o6 and DS-Lite have more deployments, having been up now DS-Lite the most used one, but lw4o6 taking over in the last years. @@OT This seems like speculation. I think the best you can do is to say there are large deployments of all mechanism. Proving that letting the market decide is a terrible strategy. ;-) 3.4.3. Implementation Code Sizes As for complexity hint, the code size reported from OpenWRT implementation is 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, DS-Lite, MAP-E, MAP-T, and lw4o6, respectively (https://openwrt.org/packages/start). We note that the support for all five technologies requires much less code size than the total sum of the above quantities, because Lencse et al. Expires April 6, 2019 [Page 6] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 they contain a lot of common functions (data plane is shared among several of them). 4. Performance Comparison We plan to compare the performances of the most prominent free software implementations of the five IPv6 transition technologies using the methodology described in "Benchmarking Methodology for IPv6 Transition Technologies" [RFC8219]. On the one hand, the Dual DUT Setup of RFC8219 makes it possible to use the existing "Benchmarking Methodology for Network Interconnect Devices" [RFC2544] compliant measurement devices, however, this setup has the drawback that the performances of the CE and of the ISP side device (e.g. the CLAT and the PLAT of 464XLAT) are measured together. In order to measure the performance of only one of them, we need to ensure that the desired one is the bottleneck. On the other hand, the Single DUT Setup of [RFC8219] makes it possible to benchmark the selected device separately, however, no [RFC8219] compliant testers available yet. A DPDK-based software Tester for stateless NAT64 is currently under development and it is expected to be available this autumn as a free software. XXX FROM WHERE XXX Any volunteers for developing [RFC8219] compliant measurement software? @OT For any IPv4aaS mechanism it looks exactly like an IPv4 link and you can = test it as such. The only exception is NAT64, which would have IPv6 on one side and IPv4 = on the other, but from the document I am unsure if you consider NAT64 in or out of = scope. 5. Security Considerations According to the simplest model, the number of bugs is proportional to the number of code lines. Please refer to section 3.4.3 for code sizes of CE implementations. For all five technologies, the CE device should contain a DNS proxy. @@OT Why? And why is that in the security considerations? However, the user may change DNS settings. If it happens and lw4o6, MAP-E and MAP-T are used with significantly restricted port set, which is required for an efficient public IPv4 address sharing, the entropy of the source ports is significantly lowered (e.g. from 16 bits to 10 bits, when 1024 port numbers are assigned to each subscriber) and thus these technologies are theoretically less resilient against cache poisoning, see [RFC5452]. However, an efficient cache poisoning attack requires that the subscriber operates an own caching DNS server and the attack is performed in the service provider network. Thus, we consider the chance of the successful exploitation of this vulnerability as low. @@OT For MAP-E, -T and LW46 it is strongly recommended that IPv6 is used for = DNS transport. You might want to add that. Lencse et al. Expires April 6, 2019 [Page 7] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 An in-depth security analysis of all five IPv6 transition technologies and their most prominent free software implementations according to the methodology defined in [Len2018] is planned. 6. IANA Considerations TBD. 7. Conclusions TBD. 8. References 8.1. Normative References [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . Lencse et al. Expires April 6, 2019 [Page 8] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, . [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, . [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, . [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP translation algorithm", RFC 7915, DOI: 10.17487/RFC7915, June 2016, . [RFC7757] Anderson, T., and A. Leiva Popper "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, . [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking Methodology for IPv6 Transition Technologies", IETF RFC 8219, DOI: 10.17487/RFC8219, Aug. 2017, . 8.2. Informative References [Len2017] Lencse, G., and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017- survey.pdf Lencse et al. Expires April 6, 2019 [Page 9] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 [Len2018] Lencse, G., and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012, http://www.hit.bme.hu/~lencse/publications/ECS-2018- Methodology-revised.pdf [Miy2010] Miyakawa, S., "IPv4 to IPv6 transformation schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp.1078-1084, May 2010. DOI:10.1587/transcom.E93.B.1078 [Rep2014] Repas, S., Hajas, T., and G. Lencse, "Port number consumption of the NAT64 IPv6 transition technology", Proc. 37th Internat. Conf. on Telecommunications and Signal Processing (TSP 2014), Berlin, Germany, pp.66-72, Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411 9. Acknowledgments The authors would like to acknowledge the inputs of Ole Troan, Mark Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, and TBD. This document was prepared using 2-Word-v2.0.template.dot. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Lencse et al. Expires April 6, 2019 [Page 10] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 Authors' Addresses Gabor Lencse Budapest University of Technology and Economics Magyar Tudosok korutja 2. H-1117 Budapest, Hungary Email: lencse@hit.bme.hu Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid - 28420 Spain Email: jordi.palet@theipv6company.com Lee Howard Retevia 9940 Main St., Suite 200 Fairfax Virginia 22031, USA Email: lee@asgard.org Richard Patterson Sky UK 1 Brick Lane London, E1 6PU United Kingdom Email: richard.patterson@sky.uk Lencse et al. Expires April 6, 2019 [Page 11] --Apple-Mail=_BF73F264-9AA5-4F9B-9C3D-59332BEBF17A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Comments inline. Look for = @@OT.

Ole


IPv6 Operations Working Group         =                     =    G. Lencse
Internet Draft             =                     =                   =  BUTE
Intended status: Informational         =               J. Palet = Martinez
Expires: April 2018             =                     =   The IPv6 Company
                =                     =                     =      L. Howard
          =                     =                     =              Retevia
      =                     =                     =             R. Patterson
      =                     =                     =                   Sky = UK
                =                     =                   =  October 6, 2018



         Pros and Cons of IPv6 = Transition Technologies for IPv4aaS
          =     =  draft-lmhp-v6ops-transition-comparison-00.txt


Abstract

   Several = IPv6 transition technologies can be used to provide = IPv4-as-
   a-service (IPv4aaS) to the customers, while the = ISPs have only IPv6
   in their access and or core network. All = these technologies have
   their advantages and disadvantages. = Depending on several various
   conditions and preferences, = different technologies may prove to be
   the most appropriate = solution. This document examines the five most
   prominent = IPv4aaS technologies considering several different = aspects
   in order to provide network operators with an = easy to use guideline
   for selecting the technology that suit = their needs the best.

Status of this Memo

   This Internet-Draft is submitted in full = conformance with the
   provisions of BCP 78 and BCP = 79.

   Internet-Drafts are working documents of the = Internet Engineering
   Task Force (IETF), its areas, and its = working groups.  Note that
   other groups may also = distribute working documents as Internet-
  =  Drafts.

   Internet-Drafts are draft = documents valid for a maximum of six
   months and may be updated, = replaced, or obsoleted by other documents
   at any = time.  It is inappropriate to use Internet-Drafts = as
   reference material or to cite them other than as = "work in progress."

   The list of current = Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories = can be accessed at
   http://www.ietf.org/shadow.html



Lencse et al.   =         Expires April 6, 2019       =           [Page 1]
=0C=
Internet-Draft=  Pros and Cons of IPv4aaS Technologies      October = 2018

   This Internet-Draft will = expire on April 6, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons = identified as the
   document authors. All rights = reserved.

   This document is subject to = BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF = Documents
   (http://trustee.ietf.org/license-info) in effect on the = date of
   publication of this document. Please review = these documents
   carefully, as they describe your rights and = restrictions with
   respect to this document. Code Components = extracted from this
   document must include Simplified BSD = License text as described in
   Section 4.e of the Trust = Legal Provisions and are provided without
   warranty = as described in the Simplified BSD License.

Table of Contents

   1. = Introduction ................................................ = 3
 =  2. High-level Architectures and their Consequences ............. = 3
 =     2.1. Service Provider Network Traversal = ..................... 3
      2.2. IPv4 Address Sharing = ................................... 4
   3. More Detailed Analysis = ...................................... 4
      3.1. Details of = Architectural Differences ................... 4
      =    3.1.1. 464XLAT ........................................... = 4
 =        3.1.2. DS-Lite = ........................................... 4
      =    3.1.3. Lw4o6 ............................................. = 4
 =        3.1.4. MAP-E = ............................................. 5
      =    3.1.5. MAP-T ............................................. = 5
 =     3.2. Tradeoff between Port Number Efficiency and = Stateless
           Operation = .............................................. 5
      = 3.3. Support for Server Operation ........................... = 6
 =     3.4. Support and Implementations = ............................ 6
         3.4.1. = OS Support......................................... 6
      =    3.4.2. Support in Cellular and Broadband Networks......... = 6
 =        3.4.3. Implementation Code Sizes = ......................... 6
   4. Performance Comparison = ...................................... 7
   5. Security Considerations = ..................................... 7
   6. IANA Considerations =  ........................................ 8
   7. = Conclusions ................................................. = 8
 =  8. References .................................................. = 8
 =     8.1. Normative References = ................................... 8
      8.2. Informative = References ................................. 9
   9. = Acknowledgments ............................................ = 10




Lencse et al.           Expires = April 6, 2019                 = [Page 2]
=0C
Internet-Draft  Pros and Cons of = IPv4aaS Technologies      October 2018


1. Introduction

   IETF has standardized a high number of IPv6 = transition technologies
   [Len2017] and occupied a neutral position = trusting the selection to
   the market. In the upcoming = years, several network operators would
   like to get rid of the = burden of maintaining IPv4 in their access
   and/or = core networks. This document deals with five different
   solutions, = each of which can be used to provide an IPv4 service
   using an = IPv6-only access/core network. The following IPv6
   transition = technologies are covered: 464XLAT [RFC6877], DS-Lite
   (Dual = Stack Lite) [RFC6333], lw4o6 (Lightweight 4over6) = [RFC7596],
   MAP-E [RFC7597] and MAP-T = [RFC7599].

2. High-level Architectures and their = Consequences

2.1. Service Provider Network = Traversal

   As for the high-level = solution of the IPv6 service provider network
   traversal, = MAP-T use double translation (first at the CE from IPv4
   to IPv6, = NAT46, and then from IPv6 to IPv4, NAT64, at the = service
   provider network), 464XLAT may use single = (NAT64, IPv6 to IPv4) or
   double translation (as MAP-T), depending = on different factors, such
   as the use of DNS by the = applications and the availability of a
   DNS64. DS-Lite, lw4o6 and = MAP-E encapsulate the IPv4 packets into
   IPv6 packets. Each solution = has its own advantages and drawbacks.
   Double translation results = in only 20 bytes overhead (the difference
   in the = minimum header size between IPv4 and IPv6), whereas the
   overhead = of the encapsulation is 40 bytes (because both, the = IPv4
   and IPv6 headers are needed, compared with only = the IPv4 one). The
   difference may be significant in the case = of small packet sizes or
   when the larger one results in = fragmentation.

@@OT:
Both MAP-T and 464XLAT uses double = translation.
Traditionally NAT64 hasn=E2=80=99t been considered an IPv4aaS = solution.
If you want to include it, treat it as a separate = solution.
The NAT64 in both solution can be =E2=80=9Creused" in a = IPv6 host/application scenario.
s/compared with only the IPv4 = one/compared with only the IPv6 one



   On the one hand, the first = step of the double translation case is a
   stateless NAT from IPv4 to = IPv6 implemented as SIIT (Stateless
   IP/ICMP Translation = Algorithm) [RFC7915], which does not translate
   IPv4 = options and/or multicast IP/ICMP packets, whereas with
  =  encapsulation-based technologies these remain = intact.

@@OT
None of the sharing solutions = would =E2=80=9Cnatively=E2=80=9D do multicast.

   On the other hand, single and double translation = results in "normal"
   IPv6 traffic which can be inspected, e.g., = by hashing algorithms,
   and firewalls, whereas encapsulation = results in IPv4-embedded IPv6
   packets and their = interpretation requires special software/hardware
   for DPI = (deep-packet-inspection).

@@OT
Replace =E2=80=9CDPI= " with, looking further into the packet.
This isn=E2=80=99t what we tradtionally = think of as DPI.
Note that this argument goes both ways. Because these = middleboxes
might want to =E2=80=9Ctreat=E2=80=9D the packet as an = IPv4 one, and have to reverse-engineer
the IPv4 header.

   The worst case is DS-Lite, which is also doing = double stateful
   translation (NAT44 at the CE, NAT44 at the = AFTR).

@@OT
Actually the worst case is typical = deployments of 464XLAT which does 3 stateful = translations.
NAT44, NAT46 and NAT64.


Lencse et al.       =     Expires April 6, 2019           =       [Page 3]
=0C
Internet-Draft =  Pros and Cons of IPv4aaS Technologies      October = 2018

   Another consequence is that = the solutions using double translation
   can carry only TCP, UDP or = ICMP over IP, when they are used with
   IPv4 address sharing = (please refer to section 3.3 for more details),
   whereas = the solutions using encapsulation can carry any other
   protocols = over IP, too.

@@OT
That=E2=80=99s incorrect. There is = nothing in the translation/encapsulation = difference 
that affects carrying other IP protocols. IP address sharing = is the one that 
breaks that (since you must forward based on L4 = information).

2.2. IPv4 Address = Sharing

   All five technologies = support IPv4 address sharing, which has severe
  =  consequences described in [RFC6269].

   The efficiency of the address sharing of the = five technologies is
   significantly different, it is discussed in = section 3.2.

   We note that lw4o6, MAP-E = and MAP-T may not necessarily be
   configured to do IPv4 = address sharing, see the details in Section
   3.3, = however in that case there is no advantage in terms of = public
   IPv4 addresses saving.

@@OT
Correct, but there is an advantage in that you can deliver a = complete IPv4
address (or prefix) to customers who require use of other = protocols than
TCP or UDP.


3. More Detailed = Analysis

3.1. Details of Architectural = Differences

3.1.1. 464XLAT

   CLAT performs a stateless translation from IPv4 = to IPv6 [RFC7915].
   It uses IPv4-embedded IPv6 addresses = [RFC6052] for both source
   address and destination = address. PLAT performs stateful NAT64
   [RFC6146].

@@OT
Or in the case of the use of a single IPv6 address it uses = stateful translation.
So in the case of a 464XLAT router, it has stateful = NAT44, stateful NAT46 and stateful NAT64.
Note that we generally = don=E2=80=99t see state close to the end-user as equally = problematic
as state in the middle of the network.

3.1.2. DS-Lite

   The B4 = (Basic Bridging BroadBand) element encapsulates the = IPv4
   packets into IPv6 packets. The AFTR (Address = Family Transition
   Router) de-encapsulates the IPv4 packets from = the IPv6 packets and
   performs stateful NAPT (Network Address and = Port Translation).

3.1.3. Lw4o6

   Lightweight 4over6 is a variant of DS-Lite. The = difference is, that
   the stateful NAPT is moved from the AFTR to = the B4 element. It uses
   a provisioning mechanism to determine the = size of the limited port
   set per user.


@@OT
Or you can say that LW46 is a subset of = MAP, as it uses the same provisioning,
the same port mapping algorithm, and is = indistinguishable from MAP-E in 1:1 mode.



Lencse et al.   =         Expires April 6, 2019       =           [Page 4]
=0C=
Internet-Draft=  Pros and Cons of IPv4aaS Technologies      October = 2018

3.1.4. MAP-E

   The CE (Customer-Edge) router first encapsulates = IPv4-in-IPv6.
   Packets must traverse a MAP BR to be = [de-]encapsulated.

@OT
All MAP based solutions also support = mesh, i.e. direct communication between CEs,
so this statement is = not strictly speaking correct.

3.1.5. = MAP-T

   The CE (Customer Edge) = router first performs a NAT44 to transform
   the source = addresses and source port numbers of the IPv4 packets
   into a = predefined range, the size of which is a design = parameter.
   The CE router then performs stateless = translation from IPv4 to IPv6
   [RFC7915], which translates = the IPv4 address and the port numbers
   into the IPv6 address = space. The transformations may be fine-tuned
   by the = mapping rules. The MAP BR (Border Relay) performs = stateless
   translation from IPv4 to IPv6 = [RFC7915].

@@OT
You might qualify this with =E2=80=9C= When doing IPv4 address sharing=E2=80=9D.
Also note that the same = NAT44 process happens with MAP-E, and LW46.

3.2. Tradeoff between Port Number Efficiency and Stateless = Operation

   464XLAT and DS-Lite use = stateful NAPT at the PLAT and AFTR devices,
  =  respectively. This may cause scalability issues. Lw4o6, MAP-E = and
   MAP-T avoid using NAPT in the service provider = network. Its cost is
   that they have to limit the port numbers = available for a user, which
   is also the case for = DS-Lite. Determining the optimal size of the

@@OT
Incorrect with regards to DS-lite.
Note, that all CGN = solutions will limie the port numbers available.
The difference is that = in A+P solutions then the port range is fixed.
But customers can get a = full IPv4 address if required.
While in the CGN solutions the limit is = more dynamic / centrally adjustable.


   port set is not an easy task. On the one = hand, the lack of port
   situation may cause serious problems in the = operation of certain
   programs (e.g. the consequences of the = session number limitation due
   to port number shortage = were impressively demonstrated using Google
   Map in = [Miy2010]). The port number consumption of different
  =  applications is highly varying and e.g. in the case of web = browsing
   it depends on several factors [Rep2014]. And = there may be several
   users behind a CPE, especially in the wired = case (e.g. Internet is
   used by different members of a family = simultaneously), thus
   sometimes even a few thousands ports may = not be enough.

@@OT
This sounds a little = opinionated.
Adding some numbers/references to this section might = help.
In= an endpoint-dependent NAT, you only need enough ports to cover the = number
of sessions to the same destination address / = port.
So= with 16 ports, you are restricted to 16 sessions to destination A port = P,
but = you can reuse those 16 ports to destination A port P+1, and destination = B, port P.

 However, on
   the other = hand, assigning too many ports per user will result in
   waste of = public IPv4 addresses, which is a scarce and expensive
   resource. = Therefore, 464XLAT is much more efficient in terms of = port
   number and thus public IP address saving. The = price is the stateful
   operation in the service provider network, = which is allegedly does
   not scale up well. XXX MEASUREMENTS ARE = PLANNED TO DECIDE IF IT IS
   TRUE. XXX

@@OT
Replace 464XLAT with CGN or centralized NAT, cause this = applies to 
all the solutions that use CGN. NAT444, DS-lite, = NAT64.
With regards to the =E2=80=9Callegedly scale=E2=80=9D=E2=80= =A6 I would think that obvious,
but apparently not. Let me give you a = challenge then.
Let=E2=80=99s say you have a device that can do 500Gbps ofg = IPv4aaS traffic.
The total amount of IPv4 traffic the site must handle is = 5Tbps.
How do you scale this? With A+P solutions you simply stack 10 = of these devices
and run ECMP to load-balance across them. If you want to take = one out of service
you simply pull that one out of the ECMP = bundle.
Now for stateful NAT, tell me how you want to do = it.

   We also note that NAT64 does not pre-allocate = ports for customers
   but allocates them "on the fly" (which = means that even the same
   customer is using ports from different = addresses, and most of the
   time, different customers = get ports from any given addresses), and
   in fact this creates many = application/service providers (Sony

@@OT
That=E2=80=99s = dependent on the NAT64 setup. We can very well do deterministic stateful = NAT too.
And you could reserve a fixed set of ports for each customer, = just like A+P. There
is nothing inherit in the mechanism in = NAT64.
The downside of not pre-allocated ports / indeterministic = NAT, is logging requirements
are much higher. You should add logging = as a separate section, if you don=E2=80=99t have it.


Lencse et al.       =     Expires April 6, 2019           =       [Page 5]
=0C
Internet-Draft =  Pros and Cons of IPv4aaS Technologies      October = 2018

   PlayStation Network, = OpenDNS, etc.) to permanently black-list the
   IPv4 = ranges once they are detected to be used for address = sharing.

3.3. Support for Server = Operation

   Lw4o6, MAP-E and MAP-T may = be configured without IPv4 address
   sharing, allowing exclusive = use of all ports, and non-port-based
   layer 4 protocols. Thus, = they may also be used to support server
   operation, when public IPv4 = addresses are assigned to the
   subscribers, however, then = there is no advantage in terms of IPv4
   public addresses = saving.

   It is also possible to = configure specific ports mapping in
   464XLAT/NAT64 using EAMT = [RFC7757], which means that only those
   ports are "lost" from the = pool of addresses, so there is a higher
   maximization of the total = usage of IPv4/port resources.

@@OT
That is also possible = in A+P. E.g. you can route port 80 to a particular CPE.
In both cases that = complicates provisioning.
Which is another section you should = probably add.

3.4. Support and = Implementations

3.4.1. OS Support

   As for 464XLAT, client support exists in Windows = 10, Linux
   (including Android), Windows Mobile, and Chrome = OS, but it is
   missing from iOS and MacOS. For the other four = solutions, we are not
   aware of any OS support.

@@OT
IPv4aaS is typically thought of as something running on an CE = router.
You may run it on a host, and in the 464XLAT that is a mobile = phone,
acting as a NAT/router.
At least I=E2=80=99m not aware of very = much of a use case for IPv4aaS host support,
so I=E2=80=99m not sure = this section adds very much.


3.4.2. Support in Cellular and Broadband = Networks

   Several cellular networks = use 464XLAT, whereas we are not aware of
   any deployment of the four = other technologies in cellular networks,
   as they are not = supported.

   In broadband networks, = there are some deployments of 464XLAT, MAP-E
   and MAP-T. = Both, lw4o6 and DS-Lite have more deployments, having
   been up = now DS-Lite the most used one, but lw4o6 taking over in = the
   last years.

@@OT
This seems like = speculation. I think the best you can do is to say = there
are large deployments of all mechanism. Proving that letting = the market
decide is a terrible strategy. ;-)


3.4.3. Implementation Code = Sizes

   As for complexity hint, the = code size reported from OpenWRT
   implementation is 17kB, = 35kB, 15kB, 35kB, and 48kB for 464XLAT,
   lw4o6, DS-Lite, MAP-E, = MAP-T, and lw4o6, respectively
   (https://openwrt.org/packages/start).

   We note that the support for all five = technologies requires much
   less code size than the = total sum of the above quantities, because



Lencse et al.   =         Expires April 6, 2019       =           [Page 6]
=0C=
Internet-Draft=  Pros and Cons of IPv4aaS Technologies      October = 2018

   they contain a lot of = common functions (data plane is shared among
   several of = them).

4. Performance = Comparison

   We plan to compare the = performances of the most prominent free
   software implementations of = the five IPv6 transition technologies
   using the methodology = described in "Benchmarking Methodology for
   IPv6 = Transition Technologies" [RFC8219].

   On the one = hand, the Dual DUT Setup of RFC8219 makes it possible = to
   use the existing "Benchmarking Methodology for = Network Interconnect
   Devices" [RFC2544] compliant measurement = devices, however, this
   setup has the drawback that the = performances of the CE and of the
   ISP side device (e.g. the = CLAT and the PLAT of 464XLAT) are measured
   together. = In order to measure the performance of only one of = them,
   we need to ensure that the desired one is the = bottleneck.

   On the other hand, the = Single DUT Setup of [RFC8219] makes it
   possible to benchmark the = selected device separately, however, no
   [RFC8219] compliant testers = available yet. A DPDK-based software
   Tester for stateless NAT64 = is currently under development and it is
   expected to be available = this autumn as a free software. XXX FROM
   WHERE XXX

   Any volunteers for developing [RFC8219] = compliant measurement
   software?

@OT
For any IPv4aaS = mechanism it looks exactly like an IPv4 link and you can = test
it = as such.
The only exception is NAT64, which would have IPv6 on one = side and IPv4 on the other,
but from the document I am unsure if you = consider NAT64 in or out of scope.

5. Security = Considerations

   According to the simplest = model, the number of bugs is proportional
   to the = number of code lines. Please refer to section 3.4.3 for = code
   sizes of CE implementations.

   For all five technologies, the CE device should = contain a DNS proxy.

@@OT
Why?
And why is that in the security = considerations?

   However, the user may = change DNS settings. If it happens and lw4o6,
   MAP-E and = MAP-T are used with significantly restricted port set,
   which is = required for an efficient public IPv4 address sharing, = the
   entropy of the source ports is significantly = lowered (e.g. from 16
   bits to 10 bits, when 1024 port numbers are = assigned to each
   subscriber) and thus these technologies are = theoretically less
   resilient against cache poisoning, see = [RFC5452]. However, an
   efficient cache poisoning attack requires = that the subscriber
   operates an own caching DNS server and the = attack is performed in
   the service provider network. Thus, we = consider the chance of the
   successful exploitation of = this vulnerability as low.


@@OT
For MAP-E, -T and LW46 it is strongly recommended that IPv6 = is used for DNS transport.
You might want to add = that.

Lencse et al.       =     Expires April 6, 2019           =       [Page 7]
=0C
Internet-Draft =  Pros and Cons of IPv4aaS Technologies      October = 2018

   An in-depth security = analysis of all five IPv6 transition
   technologies and their most = prominent free software implementations
   according to the = methodology defined in [Len2018] is planned.

6. IANA Considerations

  =  TBD.

7. Conclusions

   TBD.

8. = References

8.1. Normative = References

   [RFC2544] Bradner, S. and = J. McQuaid, "Benchmarking Methodology for
      =        Network Interconnect Devices", RFC 2544, = DOI
            =  10.17487/RFC2544, March 1999, <http://www.rfc-
          =    editor.org/info/rfc2544>.

   [RFC6052] Bao, C., Huitema, C., Bagnulo, M., = Boucadair, M., and X.
             Li, = "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
      =        DOI 10.17487/RFC6052, October 2010, <http://www.rfc-
      =        editor.org/info/rfc6052>.

   [RFC6146] Bagnulo, M., Matthews, P., and I. van = Beijnum, "Stateful
             NAT64: = Network Address and Protocol Translation from IPv6
      =        Clients to IPv4 Servers", RFC 6146, DOI = 10.17487/RFC6146,
             April 2011, = <http://www.rfc-editor.org/info/rfc6146.

   [RFC6269] Ford, M., Boucadair, M., Durand, A., = Levis, P., and P.
             Roberts, = "Issues with IP Address Sharing", RFC 6269, DOI
      =        10.17487/RFC6269, June 2011, <http://www.rfc-
      =        editor.org/info/rfc6269.

    [RFC6333] = Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
      =        Stack Lite Broadband Deployments Following = IPv4
             Exhaustion", = RFC 6333, DOI 10.17487/RFC6333, August 2011,
      =        <http://www.rfc-editor.org/info/rfc6333>.

   [RFC6877] Mawatari, M., Kawashima, M., and C. = Byrne, "464XLAT:
             Combination = of Stateful and Stateless Translation", RFC
      =        6877, DOI 10.17487/RFC6877, April 2013, = <http://www.rfc-
          =    editor.org/info/rfc6877>.




Lencse et al.           Expires = April 6, 2019                 = [Page 8]
=0C
Internet-Draft  Pros and Cons of = IPv4aaS Technologies      October 2018


   [RFC7596] Cui, Y., Sun, Q., = Boucadair, M., Tsou, T., Lee, Y., and I.
          =    Farrer, "Lightweight 4over6: An Extension to the = Dual-
             Stack Lite = Architecture", RFC 7596, DOI 10.17487/RFC7596,
      =        July 2015, <http://www.rfc-editor.org/info/rfc7596>.

   [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, = C., Matsushima, S.,
            =  Murakami, T., and T. Taylor, Ed., "Mapping of Address = and
             Port with = Encapsulation (MAP-E)", RFC 7597, DOI
          =    10.17487/RFC7597, July 2015, <http://www.rfc-
          =    editor.org/info/rfc7597>.

   [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, = O., Matsushima, S.,
             and T. = Murakami, "Mapping of Address and Port using
      =        Translation (MAP-T)", RFC 7599, DOI = 10.17487/RFC7599, July
             2015, = <http://www.rfc-editor.org/info/rfc7599>.

   [RFC7915] Bao, C., Li, X., Baker, F., Anderson, = T., and F. Gont,
             "IP/ICMP = translation algorithm", RFC 7915, DOI:
          =    10.17487/RFC7915, June 2016, <http://www.rfc-
          =    editor.org/info/rfc7915>.

   [RFC7757] Anderson, T., and A. Leiva Popper = "Explicit Address
             Mappings for = Stateless IP/ICMP Translation", RFC 7757, DOI
      =        10.17487/RFC7757, February 2016, <http://www.rfc-
      =        editor.org/info/rfc77757>.

   [RFC8219] Georgescu, M., Pislaru, L., and G. = Lencse, "Benchmarking
            =  Methodology for IPv6 Transition Technologies", IETF = RFC
             8219, DOI: = 10.17487/RFC8219, Aug. 2017, <http://www.rfc-
          =    editor.org/info/rfc8219>.

8.2. Informative References

   [Len2017] = Lencse, G., and Y. Kadobayashi, "Survey of IPv6 = Transition
             Technologies = for Security Analysis", IEICE Communications
      =        Society Internet Architecture Workshop, = Tokyo, Japan, Aug.
             28, = 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24.
      =        http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-
  =            survey.pdf









Lencse et al.   =         Expires April 6, 2019       =           [Page 9]
=0C=
Internet-Draft=  Pros and Cons of IPv4aaS Technologies      October = 2018

   [Len2018] Lencse, G., and = Y. Kadobayashi, "Methodology for the
          =    identification of potential security issues of = different
             IPv6 = transition technologies: Threat analysis of DNS64 and
      =        stateful NAT64", Computers & Security = (Elsevier), vol. 77,
             no. 1, = pp. 397-411, August 1, 2018, DOI:
          =    10.1016/j.cose.2018.04.012,
          =    http://www.hit.bme.hu/~lencse/publications/ECS-2018-=
  =           =  Methodology-revised.pdf

   [Miy2010] = Miyakawa, S., "IPv4 to IPv6 transformation schemes", = IEICE
             Trans. = Commun., vol.E93-B, no.5, pp.1078-1084, May 2010.
      =       =  DOI:10.1587/transcom.E93.B.1078

   [Rep2014] = Repas, S., Hajas, T., and G. Lencse, "Port number
      =        consumption of the NAT64 IPv6 transition = technology",
             Proc. 37th = Internat. Conf. on Telecommunications and
      =        Signal Processing (TSP 2014), Berlin, = Germany, pp.66-72,
             Jul. = 1-3, 2014. DOI: 10.1109/TSP.2015.7296411

9. = Acknowledgments

   The authors would like to = acknowledge the inputs of Ole Troan, Mark
   Andrews, = Edwin Cordeiro, Fred Baker, Alexandre Petrescu, and = TBD.
   This document was prepared using = 2-Word-v2.0.template.dot.



   Copyright (c) 2018 IETF = Trust and the persons identified as authors
   of the = code. All rights reserved.

  =  Redistribution and use in source and binary forms, with or = without
   modification, is permitted pursuant to, and = subject to the license
   terms contained in, the Simplified BSD = License set forth in Section
   4.c of the IETF Trust's = Legal Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info).












Lencse et al.   =         Expires April 6, 2019       =          [Page 10]
=0C=
Internet-Draft=  Pros and Cons of IPv4aaS Technologies      October = 2018

Authors' Addresses

   Gabor Lencse
   Budapest University of = Technology and Economics
   Magyar Tudosok korutja 2.
   H-1117 = Budapest, Hungary

   Email: = lencse@hit.bme.hu


   Jordi = Palet Martinez
   The IPv6 Company
   Molino de la Navata, = 75
   La Navata - Galapagar, Madrid - = 28420
   Spain

   Email: = jordi.palet@theipv6company.com


   Lee Howard
   Retevia
   9940 Main = St., Suite 200
   Fairfax
   Virginia
   22031, = USA
   Email: lee@asgard.org


   Richard Patterson
   Sky = UK
   1 Brick Lane
   London, E1 = 6PU
   United Kingdom

   Email: = richard.patterson@sky.uk













Lencse et al.   =         Expires April 6, 2019       =          [Page 11]
= --Apple-Mail=_BF73F264-9AA5-4F9B-9C3D-59332BEBF17A-- From nobody Mon Oct 8 04:53:54 2018 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 0AAE4130DC8 for ; Mon, 8 Oct 2018 04:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn9R2lgr8PuU for ; Mon, 8 Oct 2018 04:53:46 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3498A130DC5 for ; Mon, 8 Oct 2018 04:53:45 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-44-121.kabelnet.hu [79.121.44.121]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w98BrG7o044339 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Oct 2018 13:53:21 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-44-121.kabelnet.hu [79.121.44.121] claimed to be [192.168.1.119] To: Ole Troan Cc: "v6ops@ietf.org list" References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Mon, 8 Oct 2018 13:53:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> Content-Type: multipart/alternative; boundary="------------E52B82F4F9454E7290AD0C20" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.44.121; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 11:53:52 -0000 This is a multi-part message in MIME format. --------------E52B82F4F9454E7290AD0C20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Ole, Thank you very much for your detailed review! I try to answer your questions. I keep only the relevant parts to reduce the length of the text below. 10/8/2018 10:35 AM keltezéssel, Ole Troan írta: > Comments inline. Look for @@OT. > > Ole > [...] > > 2. High-level Architectures and their Consequences > > 2.1. Service Provider Network Traversal > >    As for the high-level solution of the IPv6 service provider network >    traversal, MAP-T use double translation (first at the CE from IPv4 >    to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service >    provider network), 464XLAT may use single (NAT64, IPv6 to IPv4) or >    double translation (as MAP-T), depending on different factors, such >    as the use of DNS by the applications and the availability of a >    DNS64. DS-Lite, lw4o6 and MAP-E encapsulate the IPv4 packets into >    IPv6 packets. Each solution has its own advantages and drawbacks. >    Double translation results in only 20 bytes overhead (the difference >    in the minimum header size between IPv4 and IPv6), whereas the >    overhead of the encapsulation is 40 bytes (because both, the IPv4 >    and IPv6 headers are needed, compared with only the IPv4 one). The >    difference may be significant in the case of small packet sizes or >    when the larger one results in fragmentation. > > @@OT: > Both MAP-T and 464XLAT uses double translation. Yes, you are completely right! (Sometimes 464XLAT is used together with NAT64, but I agree with you that they are two separate solutions, even if the PLAT of 464XLAT is the same device as the NAT64 gateway.) > Traditionally NAT64 hasn’t been considered an IPv4aaS solution. > If you want to include it, treat it as a separate solution. Yes, I agree that we should move it into a separate paragraph. Perhaps the following text would do: "As for the high-level solution of the IPv6 service provider network    traversal, both 464XLAT and MAP-T use double translation (first at the CE from IPv4    to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service    provider network)." And later in a separate paragraph: "We note that 464XLAT is often used together with stateful NAT64 [RFC6146], which allows IPv6 only host to communicate with IPv4 only servers. In this case, the stateful NAT64 gateway is the same device as the PLAT device of 464XLAT." > The NAT64 in both solution can be “reused" in a IPv6 host/application > scenario. > s/compared with only the IPv4 one/compared with only the IPv6 one > The size of the IPv4 header is 20 bytes, whereas the size of the IPv6 header is 20 bytes. If we say that "overhead of the encapsulation is 40 bytes" then it is compared with the IPv4. (The outer IPv6 header gives the extra 40 bytes.) > > >    On the one hand, the first step of the double translation case is a >    stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless >    IP/ICMP Translation Algorithm) [RFC7915], which does not translate >    IPv4 options and/or multicast IP/ICMP packets, whereas with >  encapsulation-based technologies these remain intact. > > @@OT > None of the sharing solutions would “natively†do multicast. Thank you for thinking of it.  We should include it. > >    On the other hand, single and double translation results in "normal" >    IPv6 traffic which can be inspected, e.g., by hashing algorithms, >    and firewalls, whereas encapsulation results in IPv4-embedded IPv6 >    packets and their interpretation requires special software/hardware >    for DPI (deep-packet-inspection). > > @@OT > Replace “DPI" with, looking further into the packet. > This isn’t what we tradtionally think of as DPI. OK. > Note that this argument goes both ways. Because these middleboxes > might want to “treat†the packet as an IPv4 one, and have to > reverse-engineer > the IPv4 header. I am not sure I completely understand what you mean. I would argue that in the case of 464XLAT one can simply use an IPv6 firewall instead of an IPv4 firewall. Can it be done also in the case of MAP-T? I do not know. But it is definitely a problem with the encapsulation solutions, they require reverse engineering. > >    The worst case is DS-Lite, which is also doing double stateful >    translation (NAT44 at the CE, NAT44 at the AFTR). > > @@OT > Actually the worst case is typical deployments of 464XLAT which does 3 > stateful translations. > NAT44, NAT46 and NAT64. Is it really typical? Why would someone do that? There are a lot of IPv6 addresses. Why cannot they assign a dedicated /64 for translation? > > > Lencse et al.       Expires April 6, 2019                 [Page 3] > > Internet-Draft  Pros and Cons of IPv4aaS Technologies      October 2018 > > >    Another consequence is that the solutions using double translation >    can carry only TCP, UDP or ICMP over IP, when they are used with >    IPv4 address sharing (please refer to section 3.3 for more details), >    whereas the solutions using encapsulation can carry any other >    protocols over IP, too. > > @@OT > That’s incorrect. There is nothing in the translation/encapsulation > difference > that affects carrying other IP protocols. IP address sharing is the > one that > breaks that (since you must forward based on L4 information). > Yes, this is what I meant. Please see the text above: "when they are used withIPv4 address sharing". > 2.2. IPv4 Address Sharing > >    All five technologies support IPv4 address sharing, which has severe >    consequences described in [RFC6269]. > >    The efficiency of the address sharing of the five technologies is >    significantly different, it is discussed in section 3.2. > >    We note that lw4o6, MAP-E and MAP-T may not necessarily be >    configured to do IPv4 address sharing, see the details in Section >    3.3, however in that case there is no advantage in terms of public >    IPv4 addresses saving. > > @@OT > Correct, but there is an advantage in that you can deliver a complete IPv4 > address (or prefix) to customers who require use of other protocols than > TCP or UDP. > It is discussed in Section 3.3. Should we add something over there? > > 3. More Detailed Analysis > > 3.1. Details of Architectural Differences > > 3.1.1. 464XLAT > >    CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915]. >    It uses IPv4-embedded IPv6 addresses [RFC6052] for both source >    address and destination address. PLAT performs stateful NAT64 >    [RFC6146]. > > @@OT > Or in the case of the use of a single IPv6 address it uses stateful > translation. > So in the case of a 464XLAT router, it has stateful NAT44, stateful > NAT46 and stateful NAT64. > Note that we generally don’t see state close to the end-user as > equally problematic > as state in the middle of the network. Correct. Perhaps the following text would do:   In the simplest case, CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915].    It uses IPv4-embedded IPv6 addresses [RFC6052] for both source    address and destination address. PLAT performs stateful NAT64    [RFC6146]. Alternatively, when a dedicated /64 is not available for translation, the CLAT device uses a stateful NAT44 translation before the stateful NAT46 translation. Note that we generally don’t see state close to the end-user as equally problematic as state in the middle of the network. (The last sentence is taken verbatim from you.) What do you think of this text? > 3.1.2. DS-Lite > >    The B4 (Basic Bridging BroadBand) element encapsulates the IPv4 >    packets into IPv6 packets. The AFTR (Address Family Transition >    Router) de-encapsulates the IPv4 packets from the IPv6 packets and >    performs stateful NAPT (Network Address and Port Translation). > > 3.1.3. Lw4o6 > >    Lightweight 4over6 is a variant of DS-Lite. The difference is, that >    the stateful NAPT is moved from the AFTR to the B4 element. It uses >    a provisioning mechanism to determine the size of the limited port >    set per user. > > > @@OT > Or you can say that LW46 is a subset of MAP, as it uses the same > provisioning, > the same port mapping algorithm, and is indistinguishable from MAP-E > in 1:1 mode. > What do you think of keeping the original text and adding the following one: Alternatively, one can say that lw4o6 is a subset of MAP, as it uses the same provisioning, the same port mapping algorithm, and is indistinguishable from MAP-E in 1:1 mode. > > > Lencse et al.       Expires April 6, 2019                 [Page 4] > > Internet-Draft  Pros and Cons of IPv4aaS Technologies      October 2018 > > > 3.1.4. MAP-E > >    The CE (Customer-Edge) router first encapsulates IPv4-in-IPv6. >    Packets must traverse a MAP BR to be [de-]encapsulated. > > @OT > All MAP based solutions also support mesh, i.e. direct communication > between CEs, > so this statement is not strictly speaking correct. Yes, we shall include it. And please see my answer below. > > 3.1.5. MAP-T > >    The CE (Customer Edge) router first performs a NAT44 to transform >    the source addresses and source port numbers of the IPv4 packets >    into a predefined range, the size of which is a design parameter. >    The CE router then performs stateless translation from IPv4 to IPv6 >    [RFC7915], which translates the IPv4 address and the port numbers >    into the IPv6 address space. The transformations may be fine-tuned >    by the mapping rules. The MAP BR (Border Relay) performs stateless >    translation from IPv4 to IPv6 [RFC7915]. > > @@OT > You might qualify this with “When doing IPv4 address sharingâ€. > Also note that the same NAT44 process happens with MAP-E, and LW46. Yes, it is a kind of editing mistake. (Originally, the five technologies were in the same order as they appeared in the Google spreadsheet. Then they were put into alphabetical order, but the "long" text describing the operation remained with MAP-T, only the short reference disappeared from MAP-E, which said that it worked similarly to MAP-T) We shall put it right. > 3.2. Tradeoff between Port Number Efficiency and Stateless Operation > >    464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices, >    respectively. This may cause scalability issues. Lw4o6, MAP-E and >    MAP-T avoid using NAPT in the service provider network. Its cost is >    that they have to limit the port numbers available for a user, which >    is also the case for DS-Lite. Determining the optimal size of the > > @@OT > Incorrect with regards to DS-lite. > Note, that all CGN solutions will limie the port numbers available. Can you mention typical limits? > The difference is that in A+P solutions then the port range is fixed. > But customers can get a full IPv4 address if required. > While in the CGN solutions the limit is more dynamic / centrally > adjustable. > > >    port set is not an easy task. On the one hand, the lack of port >    situation may cause serious problems in the operation of certain >    programs (e.g. the consequences of the session number limitation due >    to port number shortage were impressively demonstrated using Google >    Map in [Miy2010]). The port number consumption of different >    applications is highly varying and e.g. in the case of web browsing >    it depends on several factors [Miy2010]. And there may be several >    users behind a CPE, especially in the wired case (e.g. Internet is >    used by different members of a family simultaneously), thus >    sometimes even a few thousands ports may not be enough. > > @@OT > This sounds a little opinionated. > Adding some numbers/references to this section might help. OK, I will elaborate the problem and add some numbers from the above mentioned [Miy2010] and [Miy2010]. > In an endpoint-dependent NAT, you only need enough ports to cover the > number > of sessions to the same destination address / port. > So with 16 ports, you are restricted to 16 sessions to destination A > port P, > but you can reuse those 16 ports to destination A port P+1, and > destination B, port P. > Yes, they can be reused, but E.g. 16 is very low for several applications or web pages. Miyakawa [Miy2010] has demonstrated what happens with a Google map, when the number of sessions limited to 15. (Several block were missing, and the map was unusable.) He also provided several examples for the session numbers of different applications (the highest one was iTunes: 230-270). Unfortunately his paper is not open access (and perhaps very few of the v6ops list members are also IEICE members to be able to access the paper; if you are interested, I can send a private copy to you) but the paper written by Sándor Répás has a green open access copy here: http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf Please see Fig. 3 and Fig. 5. The number of ports used is between 100 and 150. Therefore, when dimensioning a system with MAP-T/E, one should assign several hundreds os source ports per subscriber to make sure that no quality of experience issue will occur. BTW: When I was doing measurements for my paper below, I have considered only NAT64 and therefore, I was dealing with the weighted average of the port numbers required by different web pages. G. Lencse, "Estimation of the Port Number Consumption of Web Browsing", /IEICE Transactions on Communications/, Vol. E98-B, No. 8. pp. 1580-1588. DOI: 10.1587/transcom.E98.B.1580, http://www.hit.bme.hu/~lencse/publications/e98-b_8_1580.pdf However, it would be interesting: - to find the maximum port numbers used by the most popular sites - to test what happens, if the port numbers are limited to significantly lower values. Do you think that the results would be useful for dimensioning systems using MAP-T/E? >  However, on >    the other hand, assigning too many ports per user will result in >    waste of public IPv4 addresses, which is a scarce and expensive >    resource. Therefore, 464XLAT is much more efficient in terms of port >    number and thus public IP address saving. The price is the stateful >    operation in the service provider network, which is allegedly does >    not scale up well. XXX MEASUREMENTS ARE PLANNED TO DECIDE IF IT IS >    TRUE. XXX > > @@OT > Replace 464XLAT with CGN or centralized NAT, cause this applies to > all the solutions that use CGN. NAT444, DS-lite, NAT64. I agree. > With regards to the “allegedly scaleâ€â€¦ I would think that obvious, > but apparently not. Let me give you a challenge then. > Let’s say you have a device that can do 500Gbps ofg IPv4aaS traffic. > The total amount of IPv4 traffic the site must handle is 5Tbps. > How do you scale this? With A+P solutions you simply stack 10 of these > devices > and run ECMP to load-balance across them. If you want to take one out > of service > you simply pull that one out of the ECMP bundle. > Now for stateful NAT, tell me how you want to do it. I would do some hashing on the basis of IP addresses to distribute the traffic among the 10 devices. Is there any reason, why it would not working? > >    We also note that NAT64 does not pre-allocate ports for customers >    but allocates them "on the fly" (which means that even the same >    customer is using ports from different addresses, and most of the >    time, different customers get ports from any given addresses), and >    in fact this creates many application/service providers (Sony > > @@OT > That’s dependent on the NAT64 setup. We can very well do deterministic > stateful NAT too. > And you could reserve a fixed set of ports for each customer, just > like A+P. There > is nothing inherit in the mechanism in NAT64. Thank you for mentioning it. > The downside of not pre-allocated ports / indeterministic NAT, is > logging requirements > are much higher. You should add logging as a separate section, if you > don’t have it. You are completely right. Logging was included in the table, but we have unfortunately left if out from the draft. (We had very limited time and wanted to give a chance to v6ops members to review it and we plan to publish a "-01" version before the cut-off date.) We shall definitely add logging! > > > Lencse et al.       Expires April 6, 2019                 [Page 5] > > Internet-Draft  Pros and Cons of IPv4aaS Technologies      October 2018 > > >    PlayStation Network, OpenDNS, etc.) to permanently black-list the >    IPv4 ranges once they are detected to be used for address sharing. > > 3.3. Support for Server Operation > >    Lw4o6, MAP-E and MAP-T may be configured without IPv4 address >    sharing, allowing exclusive use of all ports, and non-port-based >    layer 4 protocols. Thus, they may also be used to support server >    operation, when public IPv4 addresses are assigned to the >    subscribers, however, then there is no advantage in terms of IPv4 >    public addresses saving. > >    It is also possible to configure specific ports mapping in >    464XLAT/NAT64 using EAMT [RFC7757], which means that only those >    ports are "lost" from the pool of addresses, so there is a higher >    maximization of the total usage of IPv4/port resources. > > @@OT > That is also possible in A+P. E.g. you can route port 80 to a > particular CPE. > In both cases that complicates provisioning. > Which is another section you should probably add. > TBD. > 3.4. Support and Implementations > > 3.4.1. OS Support > >    As for 464XLAT, client support exists in Windows 10, Linux >    (including Android), Windows Mobile, and Chrome OS, but it is >    missing from iOS and MacOS. For the other four solutions, we are not >    aware of any OS support. > > @@OT > IPv4aaS is typically thought of as something running on an CE router. > You may run it on a host, and in the 464XLAT that is a mobile phone, > acting as a NAT/router. > At least I’m not aware of very much of a use case for IPv4aaS host > support, > so I’m not sure this section adds very much. I am also aware of only the CLAT of 464XLAT is running on a mobile phone. Perhaps my co-authors know about other solutions. > > > 3.4.2. Support in Cellular and Broadband Networks > >    Several cellular networks use 464XLAT, whereas we are not aware of >    any deployment of the four other technologies in cellular networks, >    as they are not supported. > >    In broadband networks, there are some deployments of 464XLAT, MAP-E >    and MAP-T. Both, lw4o6 and DS-Lite have more deployments, having >    been up now DS-Lite the most used one, but lw4o6 taking over in the >    last years. > > @@OT > This seems like speculation. I think the best you can do is to say there > are large deployments of all mechanism. Proving that letting the market > decide is a terrible strategy. ;-) > :-) [...] > 4. Performance Comparison > >    We plan to compare the performances of the most prominent free >    software implementations of the five IPv6 transition technologies >    using the methodology described in "Benchmarking Methodology for >    IPv6 Transition Technologies" [RFC8219]. > >    On the one hand, the Dual DUT Setup of RFC8219 makes it possible to >    use the existing "Benchmarking Methodology for Network Interconnect >    Devices" [RFC2544] compliant measurement devices, however, this >    setup has the drawback that the performances of the CE and of the >    ISP side device (e.g. the CLAT and the PLAT of 464XLAT) are measured >    together. In order to measure the performance of only one of them, >    we need to ensure that the desired one is the bottleneck. > >    On the other hand, the Single DUT Setup of [RFC8219] makes it >    possible to benchmark the selected device separately, however, no >    [RFC8219] compliant testers available yet. A DPDK-based software >    Tester for stateless NAT64 is currently under development and it is >    expected to be available this autumn as a free software. XXX FROM >    WHERE XXX > >    Any volunteers for developing [RFC8219] compliant measurement >    software? > > @OT > For any IPv4aaS mechanism it looks exactly like an IPv4 link and you > can test > it as such. This solution is called as "Dual DUT Setup" in RFC 8219. However, is has a significant drawback, that the two devices (e.g. CLAT and PLAT) are benchmarked together, which hides any possible asymmetric behavior. E.g. CLAT is stateless NAT46, PLAT is stateful NAT64. Besides that, the CE devices (like CLAT, B4) are normally tiny devices (both in size and performance), whereas the ISP side devices (PLAT, AFTR, MAP BR) are huge ones. IMHO, they should be tested separately, which requires special testers. I think that relatively good software testers can be implemented in DPDK. One of my PhD students is currently working on an RFC 8219 compliant stateless NAT46/NAT64 tester. We are planning to publish his code as a free software under GPL license, within a few months. Based on his code, similar testers may be implemented for other technologies, too. > The only exception is NAT64, which would have IPv6 on one side and > IPv4 on the other, > but from the document I am unsure if you consider NAT64 in or out of > scope. > > 5. Security Considerations > >    According to the simplest model, the number of bugs is proportional >    to the number of code lines. Please refer to section 3.4.3 for code >    sizes of CE implementations. > >    For all five technologies, the CE device should contain a DNS proxy. > > @@OT > Why? As I remember, all five RFC-s mention that. I will check. (As for 464XLAT, a DNS64 proxy save the double translation for DNS traffic.) > And why is that in the security considerations? > It is here because of what follows. >    However, the user may change DNS settings. If it happens and lw4o6, >    MAP-E and MAP-T are used with significantly restricted port set, >    which is required for an efficient public IPv4 address sharing, the >    entropy of the source ports is significantly lowered (e.g. from 16 >    bits to 10 bits, when 1024 port numbers are assigned to each >    subscriber) and thus these technologies are theoretically less >    resilient against cache poisoning, see [RFC5452]. However, an >    efficient cache poisoning attack requires that the subscriber >    operates an own caching DNS server and the attack is performed in >    the service provider network. Thus, we consider the chance of the >    successful exploitation of this vulnerability as low. > > > @@OT > For MAP-E, -T and LW46 it is strongly recommended that IPv6 is used > for DNS transport. > You might want to add that. How can it be done if you have an IPv4 only device or an IPv4 only application? I really appreciate your going thorough the draft and commenting it. I am sure that your contributions make it much better. Best regards, Gábor Lencse --------------E52B82F4F9454E7290AD0C20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Ole,

Thank you very much for your detailed review!

I try to answer your questions. I keep only the relevant parts to reduce the length of the text below.

10/8/2018 10:35 AM keltezéssel, Ole Troan írta:
Comments inline. Look for @@OT.

Ole

[...]

2. High-level Architectures and their Consequences

2.1. Service Provider Network Traversal

   As for the high-level solution of the IPv6 service provider network
   traversal, MAP-T use double translation (first at the CE from IPv4
   to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service
   provider network), 464XLAT may use single (NAT64, IPv6 to IPv4) or
   double translation (as MAP-T), depending on different factors, such
   as the use of DNS by the applications and the availability of a
   DNS64. DS-Lite, lw4o6 and MAP-E encapsulate the IPv4 packets into
   IPv6 packets. Each solution has its own advantages and drawbacks.
   Double translation results in only 20 bytes overhead (the difference
   in the minimum header size between IPv4 and IPv6), whereas the
   overhead of the encapsulation is 40 bytes (because both, the IPv4
   and IPv6 headers are needed, compared with only the IPv4 one). The
   difference may be significant in the case of small packet sizes or
   when the larger one results in fragmentation.

@@OT:
Both MAP-T and 464XLAT uses double translation.

Yes, you are completely right! (Sometimes 464XLAT is used together with NAT64, but I agree with you that they are two separate solutions, even if the PLAT of 464XLAT is the same device as the NAT64 gateway.)
Traditionally NAT64 hasn’t been considered an IPv4aaS solution.
If you want to include it, treat it as a separate solution.

Yes, I agree that we should move it into a separate paragraph. Perhaps the following text would do:


"As for the high-level solution of the IPv6 service provider network
   traversal, both 464XLAT and MAP-T use double translation (first at the CE from IPv4
   to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service
   provider network)."

And later in a separate paragraph:

"We note that 464XLAT is often used together with stateful NAT64 [RFC6146], which allows IPv6 only host to communicate with IPv4 only servers. In this case, the stateful NAT64 gateway is the same device as the PLAT device of 464XLAT."

The NAT64 in both solution can be “reused" in a IPv6 host/application scenario.
s/compared with only the IPv4 one/compared with only the IPv6 one


The size of the IPv4 header is 20 bytes, whereas the size of the IPv6 header is 20 bytes. If we say that "overhead of the encapsulation is 40 bytes" then it is compared with the IPv4. (The outer IPv6 header gives the extra 40 bytes.)



   On the one hand, the first step of the double translation case is a
   stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless
   IP/ICMP Translation Algorithm) [RFC7915], which does not translate
   IPv4 options and/or multicast IP/ICMP packets, whereas with
   encapsulation-based technologies these remain intact.

@@OT
None of the sharing solutions would “natively†do multicast.

Thank you for thinking of it.  We should include it.

   On the other hand, single and double translation results in "normal"
   IPv6 traffic which can be inspected, e.g., by hashing algorithms,
   and firewalls, whereas encapsulation results in IPv4-embedded IPv6
   packets and their interpretation requires special software/hardware
   for DPI (deep-packet-inspection).

@@OT
Replace “DPI" with, looking further into the packet.
This isn’t what we tradtionally think of as DPI.

OK.
Note that this argument goes both ways. Because these middleboxes
might want to “treat†the packet as an IPv4 one, and have to reverse-engineer
the IPv4 header.

I am not sure I completely understand what you mean. I would argue that in the case of 464XLAT one can simply use an IPv6 firewall instead of an IPv4 firewall. Can it be done also in the case of MAP-T? I do not know. But it is definitely a problem with the encapsulation solutions, they require reverse engineering.

   The worst case is DS-Lite, which is also doing double stateful
   translation (NAT44 at the CE, NAT44 at the AFTR).

@@OT
Actually the worst case is typical deployments of 464XLAT which does 3 stateful translations.
NAT44, NAT46 and NAT64.

Is it really typical? Why would someone do that? There are a lot of IPv6 addresses. Why cannot they assign a dedicated /64 for translation?



Lencse et al.           Expires April 6, 2019                 [Page 3]
Internet-Draft  Pros and Cons of IPv4aaS Technologies      October 2018


   Another consequence is that the solutions using double translation
   can carry only TCP, UDP or ICMP over IP, when they are used with
   IPv4 address sharing (please refer to section 3.3 for more details),
   whereas the solutions using encapsulation can carry any other
   protocols over IP, too.

@@OT
That’s incorrect. There is nothing in the translation/encapsulation difference 
that affects carrying other IP protocols. IP address sharing is the one that 
breaks that (since you must forward based on L4 information).


Yes, this is what I meant. Please see the text above: "when they are used with IPv4 address sharing".


2.2. IPv4 Address Sharing

   All five technologies support IPv4 address sharing, which has severe
   consequences described in [RFC6269].

   The efficiency of the address sharing of the five technologies is
   significantly different, it is discussed in section 3.2.

   We note that lw4o6, MAP-E and MAP-T may not necessarily be
   configured to do IPv4 address sharing, see the details in Section
   3.3, however in that case there is no advantage in terms of public
   IPv4 addresses saving.

@@OT
Correct, but there is an advantage in that you can deliver a complete IPv4
address (or prefix) to customers who require use of other protocols than
TCP or UDP.


It is discussed in Section 3.3. Should we add something over there?

3. More Detailed Analysis

3.1. Details of Architectural Differences

3.1.1. 464XLAT

   CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915].
   It uses IPv4-embedded IPv6 addresses [RFC6052] for both source
   address and destination address. PLAT performs stateful NAT64
   [RFC6146].

@@OT
Or in the case of the use of a single IPv6 address it uses stateful translation.
So in the case of a 464XLAT router, it has stateful NAT44, stateful NAT46 and stateful NAT64.
Note that we generally don’t see state close to the end-user as equally problematic
as state in the middle of the network.

Correct. Perhaps the following text would do:


  In the simplest case, CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915].
   It uses IPv4-embedded IPv6 addresses [RFC6052] for both source
   address and destination address. PLAT performs stateful NAT64
   [RFC6146].

Alternatively, when a dedicated /64 is not available for translation, the CLAT device uses a stateful NAT44 translation before the stateful NAT46 translation.

Note that we generally don’t see state close to the end-user as equally problematic
as state in the middle of the network.

(The last sentence is taken verbatim from you.)

What do you think of this text?


3.1.2. DS-Lite

   The B4 (Basic Bridging BroadBand) element encapsulates the IPv4
   packets into IPv6 packets. The AFTR (Address Family Transition
   Router) de-encapsulates the IPv4 packets from the IPv6 packets and
   performs stateful NAPT (Network Address and Port Translation).

3.1.3. Lw4o6

   Lightweight 4over6 is a variant of DS-Lite. The difference is, that
   the stateful NAPT is moved from the AFTR to the B4 element. It uses
   a provisioning mechanism to determine the size of the limited port
   set per user.


@@OT
Or you can say that LW46 is a subset of MAP, as it uses the same provisioning,
the same port mapping algorithm, and is indistinguishable from MAP-E in 1:1 mode.


What do you think of keeping the original text and adding the following one:

Alternatively, one can say that lw4o6 is a subset of MAP, as it uses the same provisioning,
the same port mapping algorithm, and is indistinguishable from MAP-E in 1:1 mode.


Lencse et al.           Expires April 6, 2019                 [Page 4]
Internet-Draft  Pros and Cons of IPv4aaS Technologies      October 2018


3.1.4. MAP-E

   The CE (Customer-Edge) router first encapsulates IPv4-in-IPv6.
   Packets must traverse a MAP BR to be [de-]encapsulated.

@OT
All MAP based solutions also support mesh, i.e. direct communication between CEs,
so this statement is not strictly speaking correct.

Yes, we shall include it. And please see my answer below.

3.1.5. MAP-T

   The CE (Customer Edge) router first performs a NAT44 to transform
   the source addresses and source port numbers of the IPv4 packets
   into a predefined range, the size of which is a design parameter.
   The CE router then performs stateless translation from IPv4 to IPv6
   [RFC7915], which translates the IPv4 address and the port numbers
   into the IPv6 address space. The transformations may be fine-tuned
   by the mapping rules. The MAP BR (Border Relay) performs stateless
   translation from IPv4 to IPv6 [RFC7915].

@@OT
You might qualify this with “When doing IPv4 address sharingâ€.
Also note that the same NAT44 process happens with MAP-E, and LW46.

Yes, it is a kind of editing mistake. (Originally, the five technologies were in the same order as they appeared in the Google spreadsheet. Then they were put into alphabetical order, but the "long" text describing the operation remained with MAP-T, only the short reference disappeared from MAP-E, which said that it worked similarly to MAP-T)

We shall put it right.

3.2. Tradeoff between Port Number Efficiency and Stateless Operation

   464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices,
   respectively. This may cause scalability issues. Lw4o6, MAP-E and
   MAP-T avoid using NAPT in the service provider network. Its cost is
   that they have to limit the port numbers available for a user, which
   is also the case for DS-Lite. Determining the optimal size of the

@@OT
Incorrect with regards to DS-lite.
Note, that all CGN solutions will limie the port numbers available.

Can you mention typical limits?
The difference is that in A+P solutions then the port range is fixed.
But customers can get a full IPv4 address if required.
While in the CGN solutions the limit is more dynamic / centrally adjustable.


   port set is not an easy task. On the one hand, the lack of port
   situation may cause serious problems in the operation of certain
   programs (e.g. the consequences of the session number limitation due
   to port number shortage were impressively demonstrated using Google
   Map in [Miy2010]). The port number consumption of different
   applications is highly varying and e.g. in the case of web browsing
   it depends on several factors [Miy2010]. And there may be several
   users behind a CPE, especially in the wired case (e.g. Internet is
   used by different members of a family simultaneously), thus
   sometimes even a few thousands ports may not be enough.

@@OT
This sounds a little opinionated.
Adding some numbers/references to this section might help.

OK, I will elaborate the problem and add some numbers from the above mentioned [Miy2010] and [Miy2010].
In an endpoint-dependent NAT, you only need enough ports to cover the number
of sessions to the same destination address / port.
So with 16 ports, you are restricted to 16 sessions to destination A port P,
but you can reuse those 16 ports to destination A port P+1, and destination B, port P.


Yes, they can be reused, but E.g. 16 is very low for several applications or web pages. Miyakawa [Miy2010] has demonstrated what happens with a Google map, when the number of sessions limited to 15. (Several block were missing, and the map was unusable.) He also provided several examples for the session numbers of different applications (the highest one was iTunes: 230-270). Unfortunately his paper is not open access (and perhaps very few of the v6ops list members are also IEICE members to be able to access the paper; if you are interested, I can send a private copy to you) but the paper written by Sándor Répás has a green open access copy here: http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf Please see Fig. 3 and Fig. 5. The number of ports used is between 100 and 150. Therefore, when dimensioning a system with MAP-T/E, one should assign several hundreds os source ports per subscriber to make sure that no quality of experience issue will occur.

BTW: When I was doing measurements for my paper below, I have considered only NAT64 and therefore, I was dealing with the weighted average of the port numbers required by different web pages.

G. Lencse, "Estimation of the Port Number Consumption of Web Browsing", IEICE Transactions on Communications, Vol. E98-B, No. 8. pp. 1580-1588. DOI: 10.1587/transcom.E98.B.1580, http://www.hit.bme.hu/~lencse/publications/e98-b_8_1580.pdf

However, it would be interesting:
- to find the maximum port numbers used by the most popular sites
- to test what happens, if the port numbers are limited to significantly lower values.

Do you think that the results would be useful for dimensioning systems using MAP-T/E?
 However, on
   the other hand, assigning too many ports per user will result in
   waste of public IPv4 addresses, which is a scarce and expensive
   resource. Therefore, 464XLAT is much more efficient in terms of port
   number and thus public IP address saving. The price is the stateful
   operation in the service provider network, which is allegedly does
   not scale up well. XXX MEASUREMENTS ARE PLANNED TO DECIDE IF IT IS
   TRUE. XXX

@@OT
Replace 464XLAT with CGN or centralized NAT, cause this applies to 
all the solutions that use CGN. NAT444, DS-lite, NAT64.

I agree.
With regards to the “allegedly scaleâ€â€¦ I would think that obvious,
but apparently not. Let me give you a challenge then.
Let’s say you have a device that can do 500Gbps ofg IPv4aaS traffic.
The total amount of IPv4 traffic the site must handle is 5Tbps.
How do you scale this? With A+P solutions you simply stack 10 of these devices
and run ECMP to load-balance across them. If you want to take one out of service
you simply pull that one out of the ECMP bundle.
Now for stateful NAT, tell me how you want to do it.

I would do some hashing on the basis of IP addresses to distribute the traffic among the 10 devices.

Is there any reason, why it would not working?
 

   We also note that NAT64 does not pre-allocate ports for customers
   but allocates them "on the fly" (which means that even the same
   customer is using ports from different addresses, and most of the
   time, different customers get ports from any given addresses), and
   in fact this creates many application/service providers (Sony

@@OT
That’s dependent on the NAT64 setup. We can very well do deterministic stateful NAT too.
And you could reserve a fixed set of ports for each customer, just like A+P. There
is nothing inherit in the mechanism in NAT64.

Thank you for mentioning it.

The downside of not pre-allocated ports / indeterministic NAT, is logging requirements
are much higher. You should add logging as a separate section, if you don’t have it.

You are completely right. Logging was included in the table, but we have unfortunately left if out from the draft. (We had very limited time and wanted to give a chance to v6ops members to review it and we plan to publish a "-01" version before the cut-off date.) We shall definitely add logging!



Lencse et al.           Expires April 6, 2019                 [Page 5]
Internet-Draft  Pros and Cons of IPv4aaS Technologies      October 2018


   PlayStation Network, OpenDNS, etc.) to permanently black-list the
   IPv4 ranges once they are detected to be used for address sharing.

3.3. Support for Server Operation

   Lw4o6, MAP-E and MAP-T may be configured without IPv4 address
   sharing, allowing exclusive use of all ports, and non-port-based
   layer 4 protocols. Thus, they may also be used to support server
   operation, when public IPv4 addresses are assigned to the
   subscribers, however, then there is no advantage in terms of IPv4
   public addresses saving.

   It is also possible to configure specific ports mapping in
   464XLAT/NAT64 using EAMT [RFC7757], which means that only those
   ports are "lost" from the pool of addresses, so there is a higher
   maximization of the total usage of IPv4/port resources.

@@OT
That is also possible in A+P. E.g. you can route port 80 to a particular CPE.
In both cases that complicates provisioning.
Which is another section you should probably add.


TBD.

3.4. Support and Implementations

3.4.1. OS Support

   As for 464XLAT, client support exists in Windows 10, Linux
   (including Android), Windows Mobile, and Chrome OS, but it is
   missing from iOS and MacOS. For the other four solutions, we are not
   aware of any OS support.

@@OT
IPv4aaS is typically thought of as something running on an CE router.
You may run it on a host, and in the 464XLAT that is a mobile phone,
acting as a NAT/router.
At least I’m not aware of very much of a use case for IPv4aaS host support,
so I’m not sure this section adds very much.

I am also aware of only the CLAT of 464XLAT is running on a mobile phone. Perhaps my co-authors know about other solutions.



3.4.2. Support in Cellular and Broadband Networks

   Several cellular networks use 464XLAT, whereas we are not aware of
   any deployment of the four other technologies in cellular networks,
   as they are not supported.

   In broadband networks, there are some deployments of 464XLAT, MAP-E
   and MAP-T. Both, lw4o6 and DS-Lite have more deployments, having
   been up now DS-Lite the most used one, but lw4o6 taking over in the
   last years.

@@OT
This seems like speculation. I think the best you can do is to say there
are large deployments of all mechanism. Proving that letting the market
decide is a terrible strategy. ;-)


:-)


[...]

4. Performance Comparison

   We plan to compare the performances of the most prominent free
   software implementations of the five IPv6 transition technologies
   using the methodology described in "Benchmarking Methodology for
   IPv6 Transition Technologies" [RFC8219].

   On the one hand, the Dual DUT Setup of RFC8219 makes it possible to
   use the existing "Benchmarking Methodology for Network Interconnect
   Devices" [RFC2544] compliant measurement devices, however, this
   setup has the drawback that the performances of the CE and of the
   ISP side device (e.g. the CLAT and the PLAT of 464XLAT) are measured
   together. In order to measure the performance of only one of them,
   we need to ensure that the desired one is the bottleneck.

   On the other hand, the Single DUT Setup of [RFC8219] makes it
   possible to benchmark the selected device separately, however, no
   [RFC8219] compliant testers available yet. A DPDK-based software
   Tester for stateless NAT64 is currently under development and it is
   expected to be available this autumn as a free software. XXX FROM
   WHERE XXX

   Any volunteers for developing [RFC8219] compliant measurement
   software?

@OT
For any IPv4aaS mechanism it looks exactly like an IPv4 link and you can test
it as such.

This solution is called as "Dual DUT Setup" in RFC 8219. However, is has a significant drawback, that the two devices (e.g. CLAT and PLAT) are benchmarked together, which hides any possible asymmetric behavior. E.g. CLAT is stateless NAT46, PLAT is stateful NAT64. Besides that, the CE devices (like CLAT, B4) are normally tiny devices (both in size and performance), whereas the ISP side devices (PLAT, AFTR, MAP BR) are huge ones. IMHO, they should be tested separately, which requires special testers.

I think that relatively good software testers can be implemented in DPDK. One of my PhD students is currently working on an RFC 8219 compliant stateless NAT46/NAT64 tester. We are planning to publish his code as a free software under GPL license, within a few months. Based on his code, similar testers may be implemented for other technologies, too.

The only exception is NAT64, which would have IPv6 on one side and IPv4 on the other,
but from the document I am unsure if you consider NAT64 in or out of scope.

5. Security Considerations

   According to the simplest model, the number of bugs is proportional
   to the number of code lines. Please refer to section 3.4.3 for code
   sizes of CE implementations.

   For all five technologies, the CE device should contain a DNS proxy.

@@OT
Why?

As I remember, all five RFC-s mention that. I will check. (As for 464XLAT, a DNS64 proxy save the double translation for DNS traffic.)

And why is that in the security considerations?


It is here because of what follows.
   However, the user may change DNS settings. If it happens and lw4o6,
   MAP-E and MAP-T are used with significantly restricted port set,
   which is required for an efficient public IPv4 address sharing, the
   entropy of the source ports is significantly lowered (e.g. from 16
   bits to 10 bits, when 1024 port numbers are assigned to each
   subscriber) and thus these technologies are theoretically less
   resilient against cache poisoning, see [RFC5452]. However, an
   efficient cache poisoning attack requires that the subscriber
   operates an own caching DNS server and the attack is performed in
   the service provider network. Thus, we consider the chance of the
   successful exploitation of this vulnerability as low.


@@OT
For MAP-E, -T and LW46 it is strongly recommended that IPv6 is used for DNS transport.
You might want to add that.

How can it be done if you have an IPv4 only device or an IPv4 only application?


I really appreciate your going thorough the draft and commenting it. I am sure that your contributions make it much better.

Best regards,

Gábor Lencse
 --------------E52B82F4F9454E7290AD0C20-- From nobody Mon Oct 8 05:19:12 2018 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 A253612F1A5 for ; Mon, 8 Oct 2018 05:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIlRP-J_eWuT for ; Mon, 8 Oct 2018 05:19:08 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31D0126DBF for ; Mon, 8 Oct 2018 05:19:08 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id EDF95FECBFF9; Mon, 8 Oct 2018 12:19:07 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5BA9471327D; Mon, 8 Oct 2018 14:19:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 14:19:05 +0200 Cc: "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <5F096E26-E48A-491C-8600-05F12B84CBB6@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> To: =?utf-8?Q?Lencse_G=C3=A1bor?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Testing of transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" --] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:19:11 -0000 Lencse, >> Any volunteers for developing [RFC8219] compliant measurement >> software? >>=20 >> @OT >> For any IPv4aaS mechanism it looks exactly like an IPv4 link and you = can test >> it as such. >=20 > This solution is called as "Dual DUT Setup" in RFC 8219. However, is = has a significant drawback, that the two devices (e.g. CLAT and PLAT) = are benchmarked together, which hides any possible asymmetric behavior. = E.g. CLAT is stateless NAT46, PLAT is stateful NAT64. Besides that, the = CE devices (like CLAT, B4) are normally tiny devices (both in size and = performance), whereas the ISP side devices (PLAT, AFTR, MAP BR) are huge = ones. IMHO, they should be tested separately, which requires special = testers. Sure, but can=E2=80=99t all testers do that? Just send an IPv4 in IPv6 stream one way, receive IPv4 the other = direction. > I think that relatively good software testers can be implemented in = DPDK. One of my PhD students is currently working on an RFC 8219 = compliant stateless NAT46/NAT64 tester. We are planning to publish his = code as a free software under GPL license, within a few months. Based on = his code, similar testers may be implemented for other technologies, = too.=20 For software based testers I mostly use: https://trex-tgn.cisco.com/ Moongen is also good, and there are few other open source ones too. Cheers, Ole From nobody Mon Oct 8 05:27:03 2018 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 015FE130DC5 for ; Mon, 8 Oct 2018 05:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45QYvPvQtXiu for ; Mon, 8 Oct 2018 05:26:59 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D626D126DBF for ; Mon, 8 Oct 2018 05:26:59 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id D8108FECBEF3; Mon, 8 Oct 2018 12:26:58 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B3242713545; Mon, 8 Oct 2018 14:26:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 14:26:56 +0200 Cc: "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <85813345-C8F6-419F-AC42-572EFDDE30D4@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> To: =?utf-8?Q?Lencse_G=C3=A1bor?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Scaling stateful transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS"] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:27:02 -0000 Lencse, splitting up threads a bit. > On 8 Oct 2018, at 13:53, Lencse G=C3=A1bor wrote: >=20 >>=20 >> With regards to the =E2=80=9Callegedly scale=E2=80=9D=E2=80=A6 I = would think that obvious, >> but apparently not. Let me give you a challenge then. >> Let=E2=80=99s say you have a device that can do 500Gbps ofg IPv4aaS = traffic. >> The total amount of IPv4 traffic the site must handle is 5Tbps. >> How do you scale this? With A+P solutions you simply stack 10 of = these devices >> and run ECMP to load-balance across them. If you want to take one out = of service >> you simply pull that one out of the ECMP bundle. >> Now for stateful NAT, tell me how you want to do it. >=20 > I would do some hashing on the basis of IP addresses to distribute the = traffic among the 10 devices. >=20 > Is there any reason, why it would not working? What do you do when you need to add one more node to the =E2=80=9Ccluster=E2= =80=9D? Remove a node? You also need to ensure traffic is symmetric. So if you are hashing you = need some sort of hash that is bidirectional. You _can_ make that work, by allocting ports / addresses cleverly = enough, but it=E2=80=99s far from trivial. And don=E2=80=99t expect your NICs RSS to handle that. Nor your hardware = router. You typically are forced into some flavour of: https://www.jool.mx/en/session-synchronization.html Cheers, Ole= From nobody Mon Oct 8 05:44:44 2018 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 17E6F130E73 for ; Mon, 8 Oct 2018 05:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCIMOkhWkwL0 for ; Mon, 8 Oct 2018 05:44:40 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C18130E62 for ; Mon, 8 Oct 2018 05:44:40 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 1FA84FECBEF3; Mon, 8 Oct 2018 12:44:40 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 16DEA713BBD; Mon, 8 Oct 2018 14:44:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 14:44:37 +0200 Cc: "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <03539ACF-37B6-48D2-81DF-79267A71DC56@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> To: =?utf-8?Q?Lencse_G=C3=A1bor?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:44:42 -0000 Lencse, >> On the other hand, single and double translation results in = "normal" >> IPv6 traffic which can be inspected, e.g., by hashing algorithms, >> and firewalls, whereas encapsulation results in IPv4-embedded IPv6 >> packets and their interpretation requires special = software/hardware >> for DPI (deep-packet-inspection). >>=20 >> @@OT >> Replace =E2=80=9CDPI" with, looking further into the packet. >> This isn=E2=80=99t what we tradtionally think of as DPI. >=20 > OK. >=20 >> Note that this argument goes both ways. Because these middleboxes >> might want to =E2=80=9Ctreat=E2=80=9D the packet as an IPv4 one, and = have to reverse-engineer >> the IPv4 header. >=20 > I am not sure I completely understand what you mean. I would argue = that in the case of 464XLAT one can simply use an IPv6 firewall instead = of an IPv4 firewall. Can it be done also in the case of MAP-T? I do not = know. But it is definitely a problem with the encapsulation solutions, = they require reverse engineering. _Iff_ the middlebox feature required the IPv4 address for some reason. = e.g. to apply an IPv4 ACL, then the translation solutions would require = =E2=80=9Creverse engineering=E2=80=9D the IPV4 header. That=E2=80=99s of course not required for the encapsulation solution. = Which only requires =E2=80=9Ctunnel vision (thanks Mark T for that = one)=E2=80=9D. So it depends, in some cases a middlebox could treat it as any other = IPv6 traffic, in some cases it might not. And it might also in some = cases force injection of IPv4 routing into IPv6. So short answer is, is that a good or bad thing? It depends. Cheers, Ole= From nobody Mon Oct 8 05:47:11 2018 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 B6D69130E73 for ; Mon, 8 Oct 2018 05:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-OL0J2mKmxd for ; Mon, 8 Oct 2018 05:47:08 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D5F130E62 for ; Mon, 8 Oct 2018 05:47:08 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 3BD7DFECBEF3; Mon, 8 Oct 2018 12:47:08 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 75B2E713C7C; Mon, 8 Oct 2018 14:47:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 14:47:06 +0200 Cc: "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <14CD2048-79BD-4654-BF26-0881457347A0@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> To: =?utf-8?Q?Lencse_G=C3=A1bor?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:47:10 -0000 >> The worst case is DS-Lite, which is also doing double stateful >> translation (NAT44 at the CE, NAT44 at the AFTR). >>=20 >> @@OT >> Actually the worst case is typical deployments of 464XLAT which does = 3 stateful translations. >> NAT44, NAT46 and NAT64. >=20 > Is it really typical? Why would someone do that? There are a lot of = IPv6 addresses. Why cannot they assign a dedicated /64 for translation? Yes, I believe this is the by far largest 464XLAT deployment. I=E2=80=99m sure others on the list can confirm. Cheers, Ole= From nobody Mon Oct 8 05:50:27 2018 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 AE345130E93 for ; Mon, 8 Oct 2018 05:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKldI9nklZ8X for ; Mon, 8 Oct 2018 05:50:23 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6AE4130E7C for ; Mon, 8 Oct 2018 05:50:22 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 92925FECBFF9; Mon, 8 Oct 2018 12:50:21 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id AB6EE713D34; Mon, 8 Oct 2018 14:50:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 14:50:19 +0200 Cc: "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <61411AEC-9CA1-4115-BD97-1BA82944D1D7@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> To: =?utf-8?Q?Lencse_G=C3=A1bor?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:50:26 -0000 Lencse, > Yes, they can be reused, but E.g. 16 is very low for several = applications or web pages. Miyakawa [Miy2010] has demonstrated what = happens with a Google map, when the number of sessions limited to 15. = (Several block were missing, and the map was unusable.) He also provided = several examples for the session numbers of different applications (the = highest one was iTunes: 230-270). Unfortunately his paper is not open = access (and perhaps very few of the v6ops list members are also IEICE = members to be able to access the paper; if you are interested, I can = send a private copy to you) but the paper written by S=C3=A1ndor R=C3=A9p=C3= =A1s has a green open access copy = here:http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf Please = see Fig. 3 and Fig. 5. The number of ports used is between 100 and 150. = Therefore, when dimensioning a system with MAP-T/E, one should assign = several hundreds os source ports per subscriber to make sure that no = quality of experience issue will occur. >=20 > BTW: When I was doing measurements for my paper below, I have = considered only NAT64 and therefore, I was dealing with the weighted = average of the port numbers required by different web pages.=20 >=20 > G. Lencse, "Estimation of the Port Number Consumption of Web = Browsing", IEICE Transactions on Communications, Vol. E98-B, No. 8. pp. = 1580-1588. DOI: 10.1587/transcom.E98.B.1580, = http://www.hit.bme.hu/~lencse/publications/e98-b_8_1580.pdf >=20 > However, it would be interesting: > - to find the maximum port numbers used by the most popular sites > - to test what happens, if the port numbers are limited to = significantly lower values. >=20 > Do you think that the results would be useful for dimensioning systems = using MAP-T/E? Well, equally dimensioning sharing ratios of CGNs. You also need to take new transports into consideration. E.g. QUIC. I=E2=80=99m quite convinced I could run a big network behind 16 ports, = with a clever enough NAT. I guess I should try. ;-) Cheers, Ole= From nobody Mon Oct 8 05:59:55 2018 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 D85D4130DDC for ; Mon, 8 Oct 2018 05:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOan7jNUVSEA for ; Mon, 8 Oct 2018 05:59:52 -0700 (PDT) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219BA130DDB for ; Mon, 8 Oct 2018 05:59:52 -0700 (PDT) Received: by mail-yw1-xc30.google.com with SMTP id s73-v6so7988698ywg.11 for ; Mon, 08 Oct 2018 05:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E5JLdqrBsyYBeBG0jFwJoQykji9RuFCTWa+RjMiyjgg=; b=NZx3kM+00W2pME6T/7rZiXU+GZ2WCN7Iaa2fTVY9be/v72Dzps516rja+zF8bEpkkI szYHha9RVoVGMWjMqjvTglEr/KEq9HTN1XgOaEzTY63Argt0d+jvhl2G+zbBKMQU7Omy HN6dcyTjRvdH1XktNE1ziwPb1Kszmuo+vNgN/OcA6lw85K89EwYQxTBlwoseR7bxOpDE 1xYnCh7qFoiunqWg1sytCWOD2X0XbxuFJw36jTzB4wQxYeQGx7hoDrmfz+cB+cJwlseh H2CfefTj06r2MtxXB96sF2fGTsvMzhy3yJXTK9pTJZn0q9nN8iXg5rh9o+fQzrx7j0R5 6enA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E5JLdqrBsyYBeBG0jFwJoQykji9RuFCTWa+RjMiyjgg=; b=t1ASyqmxXbrP05J73BR7dyJ5H5f9jfv1BFOC5c1qmYvhRGsGEqxi1PKqCR6OG6klFp lrUn3Ye/Fi1GbvwoVT+iEtyyhHVfCHvYkB6bHbcj5fjkH7o15DuuJb++hfBAIFmwUpd5 layQKWhYpdIeQnHJ0wdH6m8zOwe6v9yUyuoj1jpg6wLTXkrJVFjRJCQIJZkfNvnyB18e Zy94eOVWS8RSz6UCUYJQ4VCLksygnz3AOfgE57zldJRGloj6/Mjg57roZEsC6++fyP/J t72CbUs6XnHfqH2diL5Yqe9vJzc9J/GkjkksJuT4Sq/v2ILezKkQPrkBiiGqrt+iYsFU XOpg== X-Gm-Message-State: ABuFfoinCq0qObOve/mpaiJ0bwykAff4xU0e4ueva/ZtkOzeEl5PKo7G MB9GU0+rqcWTlIOjAqlag+RnitLRDFXksm0mZekbjA== X-Google-Smtp-Source: ACcGV60nYwZ3p6y+3RpIWxGicDIZO0FzhmFVrbkeN3VtKVR+lAUQKPoNTpgeOo9pxnvxJhcFbot3ZuOHx5VNhkKzT4I= X-Received: by 2002:a81:c806:: with SMTP id n6-v6mr12317410ywi.205.1539003591201; Mon, 08 Oct 2018 05:59:51 -0700 (PDT) MIME-Version: 1.0 References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <14CD2048-79BD-4654-BF26-0881457347A0@employees.org> In-Reply-To: <14CD2048-79BD-4654-BF26-0881457347A0@employees.org> From: Ca By Date: Mon, 8 Oct 2018 05:59:40 -0700 Message-ID: To: Ole Troan Cc: =?UTF-8?Q?Lencse_G=C3=A1bor?= , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000005c973a0577b7322b" Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:59:54 -0000 --0000000000005c973a0577b7322b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2018 at 5:47 AM Ole Troan wrote: > >> The worst case is DS-Lite, which is also doing double stateful > >> translation (NAT44 at the CE, NAT44 at the AFTR). > >> > >> @@OT > >> Actually the worst case is typical deployments of 464XLAT which does 3 > stateful translations. > >> NAT44, NAT46 and NAT64. > > > > Is it really typical? Why would someone do that? There are a lot of IPv= 6 > addresses. Why cannot they assign a dedicated /64 for translation? > > Yes, I believe this is the by far largest 464XLAT deployment. > I=E2=80=99m sure others on the list can confirm. > > Cheers, > Ole I would say: not quite Using round numbers on a mobile network, one can expect in HEv2 and 464xlat= : 75+% of traffic to be ipv6 e2e (no translation) 24% to use dns64/nat64 (1 translation) And less than 1% having a nat46 and nat64 (double translation due to ipv4 socket and / or literal) In this effort, you may want to call out specifically 464xlat and HEv2. They are similar but seperately specified. Both have tens of millions of units deployed. https://tools.ietf.org/html/rfc8305 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000005c973a0577b7322b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon,= Oct 8, 2018 at 5:47 AM Ole Troan <otroan@employees.org> wrote:
>>=C2=A0 =C2=A0 The worst case is DS-Lite, which is also doing do= uble stateful
>>=C2=A0 =C2=A0 translation (NAT44 at the CE, NAT44 at the AFTR).
>>
>> @@OT
>> Actually the worst case is typical deployments of 464XLAT which do= es 3 stateful translations.
>> NAT44, NAT46 and NAT64.
>
> Is it really typical? Why would someone do that? There are a lot of IP= v6 addresses. Why cannot they assign a dedicated /64 for translation?

Yes, I believe this is the by far largest 464XLAT deployment.
I=E2=80=99m sure others on the list can confirm.

Cheers,
Ole

I would say: = not quite

Using round nu= mbers on a mobile network, one can expect in HEv2 and 464xlat:

75+% of traffic to be ipv6 e2e (no t= ranslation)
24% to use dns64/nat64 (1 translation)
And less than 1% having a nat46 and nat64 (double tra= nslation due to ipv4 socket and / or literal)

In this effort, you may want to call out specifically= 464xlat and HEv2. They are similar but seperately specified. Both have ten= s of millions of units deployed.=C2=A0





_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000005c973a0577b7322b-- From nobody Mon Oct 8 06:06:08 2018 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 D23EE130DE6 for ; Mon, 8 Oct 2018 06:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI_nQ9JTaji1 for ; Mon, 8 Oct 2018 06:06:05 -0700 (PDT) Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A475130DDC for ; Mon, 8 Oct 2018 06:06:05 -0700 (PDT) Received: by mail-yw1-xc2f.google.com with SMTP id l79-v6so8001868ywc.7 for ; Mon, 08 Oct 2018 06:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TFJdfo3cf5KvKOldfAhnOi4HGPKtIqtv0YRwbHVqN9c=; b=Ia2/EiTv79wYZbt03gvgAUHmkrZj5YGPnKQaoxi0jsXgzgRg4m/TDQdV/hMc0pHp0e 1xP6vFSa2LgOL1MG0XOu10frDU+bVge0cXckx+/7WGg3MaB1Qln8TCcwFTbnlFAAmpe0 kjFZHQgXHzqo/lQO+sO/bAp1oRkJwmOxZW69PHJvkxnfhQ42fplaLVG02Cb9YcR6kTzB aqGBpD0ZBJlYukJF08KZwbCabfql4Li9t+oe3sIZWfkIuD2m1HP3Ql/Cbbfle1srHU9X nYmdtdCkxKMuBIB76NA320Ac/rtWgybBXRY4afSNjjvEtmTY8NzuiOw1CjwnfQdPrZxt Q14w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TFJdfo3cf5KvKOldfAhnOi4HGPKtIqtv0YRwbHVqN9c=; b=YIRaIht0VmcTIkkRSnovQiQx8Wo9v/LqVZZd50/lmrk7Ibd0DfizKNlsgNbOXNwLHd dI1N8hZ/w8hKS1HbgtQzTm0NngoMlVec1gu+hzisQsEEryxoIQ55LscmZo3qrsti5bTF EkVlJbbgWa3qd40PcCGqC1LfMdebdkGqDt5EjvRRzYUqsEjCBjbovynjHKe+na5FK6lQ C9Qkvun6E9ze3CB29s6pdfmDfmRyH1mW2ymWS7mZk03PMOD0nZ1morFR8awPOgRxVosW xj8XSYeFY+Sjy1zAE+E98joZyzViXOaPIDztd50ixR6MSPMzRx3pEWHblxmlqEC2oqOq n7uQ== X-Gm-Message-State: ABuFfoj0EDtHyXpGKyJ4ZV+sJbztzynEVyqd+eFduYz2qbidmybDijI7 wholbabf+nMENiEKb4iXlbthj07d+30mdOrqB76FRA== X-Google-Smtp-Source: ACcGV610GiLNFOG7yDAV27yPU3tH3QKU2HjqU97RSbx7nAVOr15NmZtAHkGeXmZbPqo8V7iY6RD8Nk/pEz5H6izHa4s= X-Received: by 2002:a81:af5a:: with SMTP id x26-v6mr12551287ywj.31.1539003964197; Mon, 08 Oct 2018 06:06:04 -0700 (PDT) MIME-Version: 1.0 References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <85813345-C8F6-419F-AC42-572EFDDE30D4@employees.org> In-Reply-To: <85813345-C8F6-419F-AC42-572EFDDE30D4@employees.org> From: Ca By Date: Mon, 8 Oct 2018 06:05:53 -0700 Message-ID: To: Ole Troan Cc: =?UTF-8?Q?Lencse_G=C3=A1bor?= , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000009810f10577b748aa" Archived-At: Subject: Re: [v6ops] Scaling stateful transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS"] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:06:07 -0000 --0000000000009810f10577b748aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2018 at 5:27 AM Ole Troan wrote: > Lencse, > > splitting up threads a bit. > > > On 8 Oct 2018, at 13:53, Lencse G=C3=A1bor wrote: > > > >> > >> With regards to the =E2=80=9Callegedly scale=E2=80=9D=E2=80=A6 I would= think that obvious, > >> but apparently not. Let me give you a challenge then. > >> Let=E2=80=99s say you have a device that can do 500Gbps ofg IPv4aaS tr= affic. > >> The total amount of IPv4 traffic the site must handle is 5Tbps. > >> How do you scale this? With A+P solutions you simply stack 10 of these > devices > >> and run ECMP to load-balance across them. If you want to take one out > of service > >> you simply pull that one out of the ECMP bundle. > >> Now for stateful NAT, tell me how you want to do it. > > > > I would do some hashing on the basis of IP addresses to distribute the > traffic among the 10 devices. > > > > Is there any reason, why it would not working? > > What do you do when you need to add one more node to the =E2=80=9Ccluster= =E2=80=9D? > Remove a node? > > You also need to ensure traffic is symmetric. So if you are hashing you > need some sort of hash that is bidirectional. > You _can_ make that work, by allocting ports / addresses cleverly enough, > but it=E2=80=99s far from trivial. > And don=E2=80=99t expect your NICs RSS to handle that. Nor your hardware = router. > > You typically are forced into some flavour of: > https://www.jool.mx/en/session-synchronization.html > > Cheers, > Ole I know a large deployment where the pref64 is load shared with ECMP. Works well IRL. Another approach that i am fond of: Allow the dns64 to offer different pref64 to target load against different nat64 units of capacity, think dns views In both cases, scaling is linear. Just add another box to ecmp or dns64. CB > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000009810f10577b748aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon,= Oct 8, 2018 at 5:27 AM Ole Troan <otroan@employees.org> wrote:
Lencse,

splitting up threads a bit.

> On 8 Oct 2018, at 13:53, Lencse G=C3=A1bor <lencse@hit.bme.hu> wrote:
>
>>
>> With regards to the =E2=80=9Callegedly scale=E2=80=9D=E2=80=A6 I w= ould think that obvious,
>> but apparently not. Let me give you a challenge then.
>> Let=E2=80=99s say you have a device that can do 500Gbps ofg IPv4aa= S traffic.
>> The total amount of IPv4 traffic the site must handle is 5Tbps. >> How do you scale this? With A+P solutions you simply stack 10 of t= hese devices
>> and run ECMP to load-balance across them. If you want to take one = out of service
>> you simply pull that one out of the ECMP bundle.
>> Now for stateful NAT, tell me how you want to do it.
>
> I would do some hashing on the basis of IP addresses to distribute the= traffic among the 10 devices.
>
> Is there any reason, why it would not working?

What do you do when you need to add one more node to the =E2=80=9Ccluster= =E2=80=9D?
Remove a node?

You also need to ensure traffic is symmetric. So if you are hashing you nee= d some sort of hash that is bidirectional.
You _can_ make that work, by allocting ports / addresses cleverly enough, b= ut it=E2=80=99s far from trivial.
And don=E2=80=99t expect your NICs RSS to handle that. Nor your hardware ro= uter.

You typically are forced into some flavour of:
https://www.jool.mx/en/session-synchronization.ht= ml

Cheers,
Ole

I know a larg= e deployment where the pref64 is load shared with ECMP. Works well IRL.=C2= =A0

Another approach tha= t i am fond of: Allow the dns64 to offer different pref64 to target load ag= ainst different nat64 units of capacity, think dns views

In both cases, scaling is linear. Just add= another box to ecmp or dns64.=C2=A0

CB

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000009810f10577b748aa-- From nobody Mon Oct 8 06:09:51 2018 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 4218D130DDC for ; Mon, 8 Oct 2018 06:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpnKiq5vgdNF for ; Mon, 8 Oct 2018 06:09:48 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4EBB130E02 for ; Mon, 8 Oct 2018 06:09:48 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 13666FECBFF9; Mon, 8 Oct 2018 13:09:48 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id A3E3A714232; Mon, 8 Oct 2018 15:09:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 15:09:45 +0200 Cc: =?utf-8?Q?Lencse_G=C3=A1bor?= , "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <651C2D5E-83EC-4B67-8D8D-39F1A036EED7@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <14CD2048-79BD-4654-BF26-0881457347A0@employees.org> To: Ca By X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:09:50 -0000 Cameron, > I would say: not quite >=20 > Using round numbers on a mobile network, one can expect in HEv2 and = 464xlat: >=20 > 75+% of traffic to be ipv6 e2e (no translation) Sure, but those numbers aren=E2=80=99t relevant here. > 24% to use dns64/nat64 (1 translation) And probably not these either, since we=E2=80=99re talking about IPv4aaS = mechanisms. > And less than 1% having a nat46 and nat64 (double translation due to = ipv4 socket and / or literal) Right. And how many of those are triple translation. I don=E2=80=99t know know if host implementation of the IPv4aaS should = be called out speciifcally in comparison with CE router implementation. > In this effort, you may want to call out specifically 464xlat and = HEv2. They are similar but seperately specified. Both have tens of = millions of units deployed.=20 >=20 > https://tools.ietf.org/html/rfc8305 I=E2=80=99m not sure how HE is relevant either? Cheers, Ole From nobody Mon Oct 8 06:12:45 2018 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 C400C130E1B for ; Mon, 8 Oct 2018 06:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmJP0vxMcXzb for ; Mon, 8 Oct 2018 06:12:42 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514F3130E02 for ; Mon, 8 Oct 2018 06:12:42 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id CB7BBFECBEF3; Mon, 8 Oct 2018 13:12:41 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C17D571431E; Mon, 8 Oct 2018 15:12:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 15:12:39 +0200 Cc: =?utf-8?Q?Lencse_G=C3=A1bor?= , "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <7D79B895-F952-4FB4-9961-DD663BF858E3@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <85813345-C8F6-419F-AC42-572EFDDE30D4@employees.org> To: Ca By X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Scaling stateful transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS"] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:12:44 -0000 Cameron, > I know a large deployment where the pref64 is load shared with ECMP. = Works well IRL.=20 Only if you can ensure ECMP give you the same hash in both directions, = right? > Another approach that i am fond of: Allow the dns64 to offer different = pref64 to target load against different nat64 units of capacity, think = dns views Only if this draft considers NAT64 in scope. ;-) > In both cases, scaling is linear. Just add another box to ecmp or = dns64.=20 Well, adding another box to ECMP, isn=E2=80=99t that simple. You want to = be able to add another box without affecting existing sessions. Normally adding to an ECMP would change the hash. Ole= From nobody Mon Oct 8 06:21:27 2018 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 4D387130DE0 for ; Mon, 8 Oct 2018 06:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfxSAsTEOR-z for ; Mon, 8 Oct 2018 06:21:19 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182B1130E1B for ; Mon, 8 Oct 2018 06:21:19 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=54314 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1g9VTI-0007oO-Qf; Mon, 08 Oct 2018 15:21:16 +0200 To: Ole Troan , Ca By Cc: "v6ops@ietf.org list" References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <85813345-C8F6-419F-AC42-572EFDDE30D4@employees.org> <7D79B895-F952-4FB4-9961-DD663BF858E3@employees.org> From: Tore Anderson Message-ID: Date: Mon, 8 Oct 2018 15:21:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <7D79B895-F952-4FB4-9961-DD663BF858E3@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Scaling stateful transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS"] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:21:25 -0000 * Ole Troan > Cameron, > >> I know a large deployment where the pref64 is load shared with ECMP. Works well IRL. > > Only if you can ensure ECMP give you the same hash in both directions, right? Not necessary if each NAT64 node has its own unique IPv4 pool. (This precludes use of RFC 6384 unless you're hashing on the 3-tuple.) > Well, adding another box to ECMP, isn’t that simple. You want to be able to add another box without affecting existing sessions. Sessions breaking when the cluster changes size is not ideal, but it is an acceptable trade-off (speaking only for myself). Tore From nobody Mon Oct 8 06:30:11 2018 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 623C2130E18 for ; Mon, 8 Oct 2018 06:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbLf7PK8DCY0 for ; Mon, 8 Oct 2018 06:30:09 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83333130DE3 for ; Mon, 8 Oct 2018 06:30:09 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id j202-v6so8025596ywa.13 for ; Mon, 08 Oct 2018 06:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oXX58Npcy0s++4Vl5u64Zp3XXMvEVEcCeXgsNEIpXCo=; b=ZnqR9VhniHPUvJ7fjUA8j2fU28XkLhdMY7dkT/dANrMs5+8bCgZSWfX9MWrooflAWF 89j5MQHArPoLwfDrUe3RRTgPbhbrx2XowWJa1NBqLtLgKwk/4qOdUEA4JgHO+kmEDfZv UmYG3lrLPC1jTakA4lFgFa0oWXZ65yDiOSfqJJBYBnUh69oUy4CZBJO7erRD+IW0tAkS fiKiIorv1odSprAmOHpPv4mPkzFuVZ9D/IxGKbjYaqxLF31YD08Gsw3SVsdm2sNeQzt3 h3kgIhb6Aq4TuEAjAbfCX2cSlZsDw2V7uxuJttOFp3rRoBBlSPe0dGzhs5qlWCsztSLN 6oRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oXX58Npcy0s++4Vl5u64Zp3XXMvEVEcCeXgsNEIpXCo=; b=iNE1HUOLSUS0T4vJWH6dxgkkJdi6BeGkPwwU5ExEwJqvz9GfCWr/xQj2NsqPuDVP30 wQ41MYVF0VQTL5V0tu9y7QP6+A+YTFhCxK163XD2t45RYmLUYARap83PWh3z/BzBxrAI j+cSqUZ8b0hPHTtujBEMr0AFuyEZgE3z2q7Qp3muBjhVJ+mB5ESGqmJYLZrjU8VKxZI3 51qbfRQ7ch9HdhWEOJO5F2rltR0N04RS7hN5edau7vKNctBk9LUF2KlBbdE0EnGI0k9k nc8HQYeQSKqboGzdTjiBDlvHHLyURDS8sSk90LAQIgd/3Hyt5vthfN7kRX2S69u7isbp uQDw== X-Gm-Message-State: ABuFfoh6GJObUZLO4UCUXA4Q7uig6ky93xpCjz0sJUXdZJQZSytQWyht zNmHH+Z8CafQ80KxkMJe8c6PtWlwDVUjlJz2ukpaMA== X-Google-Smtp-Source: ACcGV60NOWu661VbWFIkmeYL/liTepOgWZw5To5efCzJ/dZZi3N91TUczibE6A/qBRj/Did2+cZ4h3CFAE2JeezZYeE= X-Received: by 2002:a81:59d5:: with SMTP id n204-v6mr13340484ywb.54.1539005408577; Mon, 08 Oct 2018 06:30:08 -0700 (PDT) MIME-Version: 1.0 References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <85813345-C8F6-419F-AC42-572EFDDE30D4@employees.org> <7D79B895-F952-4FB4-9961-DD663BF858E3@employees.org> In-Reply-To: From: Ca By Date: Mon, 8 Oct 2018 06:29:57 -0700 Message-ID: To: Tore Anderson Cc: Ole Troan , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000af8f610577b79e9c" Archived-At: Subject: Re: [v6ops] Scaling stateful transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS"] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:30:11 -0000 --000000000000af8f610577b79e9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2018 at 6:21 AM Tore Anderson wrote: > * Ole Troan > > > Cameron, > > > >> I know a large deployment where the pref64 is load shared with ECMP. > Works well IRL. > > > > Only if you can ensure ECMP give you the same hash in both directions, > right? > > Not necessary if each NAT64 node has its own unique IPv4 pool. > > (This precludes use of RFC 6384 unless you're hashing on the 3-tuple.) > > > Well, adding another box to ECMP, isn=E2=80=99t that simple. You want t= o be able > to add another box without affecting existing sessions. > > Sessions breaking when the cluster changes size is not ideal, but it is > an acceptable trade-off (speaking only for myself). > > Tore Yes, in real life, this all works. Your straw man results may vary. CB > > --000000000000af8f610577b79e9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon,= Oct 8, 2018 at 6:21 AM Tore Anderson <to= re@fud.no> wrote:
* Ole Tr= oan

> Cameron,
>
>> I know a large deployment where the pref64 is load shared with ECM= P. Works well IRL.
>
> Only if you can ensure ECMP give you the same hash in both directions,= right?

Not necessary if each NAT64 node has its own unique IPv4 pool.

(This precludes use of RFC 6384 unless you're hashing on the 3-tuple.)<= br>
> Well, adding another box to ECMP, isn=E2=80=99t that simple. You want = to be able to add another box without affecting existing sessions.

Sessions breaking when the cluster changes size is not ideal, but it is
an acceptable trade-off (speaking only for myself).

Tore

Yes, in real= life, this all works. Your straw man results may vary.=C2=A0

CB
Content-Transfer-Encoding: quoted-printable Message-Id: <9C35A23C-5718-4D51-A8AA-BD401F1272E7@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <85813345-C8F6-419F-AC42-572EFDDE30D4@employees.org> <7D79B895-F952-4FB4-9961-DD663BF858E3@employees.org> To: Ca By X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Scaling stateful transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS"] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:41:43 -0000 >=20 > Yes, in real life, this all works. Your straw man results may vary.=20 For some definition of works indeed. I consider my point proven that scaling a stateless service is not only = much easier but much more robust. Ole= From nobody Mon Oct 8 07:00:58 2018 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 12AED130E2B for ; Mon, 8 Oct 2018 07:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVTTNt69b8dt for ; Mon, 8 Oct 2018 07:00:44 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CC4130EEC for ; Mon, 8 Oct 2018 07:00:41 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w98E0HBP004403 for ; Mon, 8 Oct 2018 07:00:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=8JQILPXMwJHSKl8nlFHUM4yo3hsTK1V0BBhd3fMe7mI=; b=l9MZWb+QxE8pHaJk0yxstBJ0JiOtIhdYr3qjgfjp2aSkNTPs2a8x2FpTcSyfWMzrZV2w 4zRNMEomBD8M1mVxR8LTWR2GaFmzdnxHR26IAd9UJldTid5WRxO85gyi0jHCX8fQtlLC IHPq15Lh+eZswNa0HxeY4DSUdvYfo4QKvkT64dTIYb18luwRNH/JqipI7kCN9qnFjQg/ 04+t9oRmsW3o0jhfqLWGm2HguQVB5fz1fjQIJERGmnlKGFC4u9jS3eYOkNiFV3kecu6n n6kddx5Y9guctD/WoGXkQ7KNMkXTcE5O+EqZC4LFVYZAYmR+a33rMJzPhLmYcuL9WDv2 vQ== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0051.outbound.protection.outlook.com [207.46.163.51]) by mx0a-00273201.pphosted.com with ESMTP id 2n040ygewv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 08 Oct 2018 07:00:40 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5301.namprd05.prod.outlook.com (20.177.127.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.17; Mon, 8 Oct 2018 14:00:24 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772%4]) with mapi id 15.20.1228.020; Mon, 8 Oct 2018 14:00:24 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-ietf-intarea-provisioning-domains Thread-Index: AdRfDyB8wKoJwuwYQdui5U62bt0EDQ== Date: Mon, 8 Oct 2018 14:00:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.58 dlp-reaction: no-action x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5301; 6:rh2ukKpeyDSrXKCj/3r7YL90Y42qHYZp9mTMvfWGsAiwYu+LWf/el8jaQRo7Nu2HgEDPd2TBaKt5qTe/vzHYCFWfRd/0yOH3sH3wPEuiAuJ1j3uWO+BqtGz5hYzz3a+gXzB+QTac0RZf72CfGCaODm+Ibtq47PBuS35C8RLamtDmb7LVMBmPFiY2zYdbHd6ewAem7nFs2KPc9TrtZY/7Zo70dfLOTfLcD/VPnc4dG3mL+VJM0k9FvOH8ypFBg0zWy8zZXx74QxG444ZhW5PhCNO+M+pF912S3caF4AhLNZMDAVmyYvX+GPBQRHimXB5XuhiB4O9IKRdSCu6YteAou/eJByj1yAwT0q3Q28Kx5ttnWdfhVcu5Kk73Hj8sdw9YhyOx2eUUAuAMXx8MRxgH5youDTw5UvofoEQKdFXHMoJtrBss04qT6stiRtWLWDrBtz1yGt0V20HHcUtEAbuNwA==; 5:r+PiP1EtmuLridE+2GC9DEC6sDWnEh6t8Ipvgy5p0qatgwDav2sE2H6qwRIPNVE4EYE/7UXaXYqZPjbrf+XnKfzb3esZ320AXMT/IBxY8l+i86VQo0LIXC4Z5GlZMp1rMF+3ndtEfau1pmRYpb0CbgRCMOW0EIIMxjTzll2dipQ=; 7:ywBC62kT+W0HrCXQQV7qjqdMJFF2XkMZzzdlGtTRHIq5lYKpe/Kb3lSa9B7QlcsMOkChTmyqIjv+EUlrddmDjY6Nenj+QmAQUtUGVVMMO/GXiAuUzHjoL7DGAU07Jfc7e1sKocHjKD7oaICivhZ95p7+mIph4WH1H2MRxNAs69NiJont+Muml9TBNyc+95yPRqacuqBPlhZOOxxDNdeeU0HF0uOhp8j2CqLYU10sfuusZsUQWvTR7F7F8pErRPEe x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1bdb5be8-500d-409e-739d-08d62d2664df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5301; x-ms-traffictypediagnostic: BYAPR05MB5301: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991055); SRVR:BYAPR05MB5301; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5301; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(346002)(136003)(39860400002)(189003)(199004)(186003)(8676002)(25786009)(26005)(66066001)(486006)(6116002)(316002)(476003)(81156014)(81166006)(3846002)(86362001)(2900100001)(256004)(71200400001)(71190400001)(102836004)(478600001)(2501003)(6436002)(105586002)(53936002)(5250100002)(7736002)(305945005)(14454004)(7696005)(33656002)(6506007)(99286004)(97736004)(8936002)(5660300001)(2351001)(106356001)(2906002)(5640700003)(74316002)(9686003)(68736007)(558084003)(6916009)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5301; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: m5xSmM2QJTcU3ungW8TmieGxVA1ICuu7Ts+h0LIGDKenpcuqyGDTQvfKdDiriDXWGVq1iySPjro+NJD+twUw1dK3dJSKvhzD27MjQTYkTjTRbMvUzcE53tF7esgkH1Pw7mGe+1zJ/uBl906GBUF72Cqcxg4sD1GoXyPwHzLdCVCHzeeLM54Y5Vs/YYauD2351f6bGiqJAu6nRNRH4Un8GuK/1QAkNsT3DEnadf7HwnqRAax/aiGFHtHdaza/ULM21nG4Fwqzmej3cp0Hb0QxFzPsdeuLGVpaqiBDwjaSVRKjG3LoHn18eb6WVqp5xqKsERR4+BSa0TDO/bIoTIdN4E27tllyeZFdH1hKzhnjnVQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1bdb5be8-500d-409e-739d-08d62d2664df X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 14:00:24.2626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5301 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-08_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=635 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810080136 Archived-At: Subject: [v6ops] draft-ietf-intarea-provisioning-domains X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:00:56 -0000 Folks, Each week between now and IETF 103, we will review and discuss one draft. This week, please review and comment on draft-ietf-intarea-provisioning-dom= ains. Fred and Ron From nobody Mon Oct 8 07:22:21 2018 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 00B3A130E96 for ; Mon, 8 Oct 2018 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9b-bVx1q8op for ; Mon, 8 Oct 2018 07:22:15 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97044130E86 for ; Mon, 8 Oct 2018 07:22:15 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-43-189.kabelnet.hu [79.121.43.189]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w98EM3dL048951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Oct 2018 16:22:08 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-43-189.kabelnet.hu [79.121.43.189] claimed to be [192.168.1.119] To: Ole Troan Cc: "v6ops@ietf.org list" , Marius Georgescu References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <5F096E26-E48A-491C-8600-05F12B84CBB6@employees.org> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Mon, 8 Oct 2018 16:21:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5F096E26-E48A-491C-8600-05F12B84CBB6@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.43.189; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] Testing of transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" --] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:22:19 -0000 Dear Ole, I send a copy of my reply to Marius Georgescu, who has written RFC 8219 (except the DNS64 benchmarking part). 10/8/2018 2:19 PM keltezéssel, Ole Troan írta: > Lencse, > >>> Any volunteers for developing [RFC8219] compliant measurement >>> software? >>> >>> @OT >>> For any IPv4aaS mechanism it looks exactly like an IPv4 link and you can test >>> it as such. >> This solution is called as "Dual DUT Setup" in RFC 8219. However, is has a significant drawback, that the two devices (e.g. CLAT and PLAT) are benchmarked together, which hides any possible asymmetric behavior. E.g. CLAT is stateless NAT46, PLAT is stateful NAT64. Besides that, the CE devices (like CLAT, B4) are normally tiny devices (both in size and performance), whereas the ISP side devices (PLAT, AFTR, MAP BR) are huge ones. IMHO, they should be tested separately, which requires special testers. > Sure, but can’t all testers do that? I think you can buy testers, which comply with RFC 2544 and the newer ones also comply with RFC 5180, which addresses IPv6 specific issues. However, RFC 5180 explicitly states that: "IPv6 transition mechanisms are outside the scope of this document." RFC 8219, which defines benchmarking methodology for IPv6 transition technologies, was published in 2017. Thus, I do not expect that any commercially available testers would support its measurement procedures. > Just send an IPv4 in IPv6 stream one way, receive IPv4 the other direction. It will not work. Let us see an example. If you want to test MAP-E BR using the single DUT setup, then you need to send special IPv6 packets, which contain IPv4 packets. The RFC 5180 compliant testers send either IPv4 or IPv6 packets, but not these kinds of packets. Besides the fact, that the traditional testers cannot create these special packets, they also lack other functionalities: although some of the measurement procedures of RFC 8219 are from RFC 2544, but there were also further ones defined. Please refer to RFC 8219 for more details. Best regards, Gábor > >> I think that relatively good software testers can be implemented in DPDK. One of my PhD students is currently working on an RFC 8219 compliant stateless NAT46/NAT64 tester. We are planning to publish his code as a free software under GPL license, within a few months. Based on his code, similar testers may be implemented for other technologies, too. > For software based testers I mostly use: > https://trex-tgn.cisco.com/ > > Moongen is also good, and there are few other open source ones too. > > Cheers, > Ole > > From nobody Mon Oct 8 07:45:46 2018 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 8B039130E0C for ; Mon, 8 Oct 2018 07:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQL-sl0k-Cw7 for ; Mon, 8 Oct 2018 07:45:42 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D62A130E27 for ; Mon, 8 Oct 2018 07:45:42 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-43-189.kabelnet.hu [79.121.43.189]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w98EjUH8049478 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Oct 2018 16:45:36 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-43-189.kabelnet.hu [79.121.43.189] claimed to be [192.168.1.119] To: Ca By Cc: Ole Troan , "v6ops@ietf.org list" References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <14CD2048-79BD-4654-BF26-0881457347A0@employees.org> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <54b0e5b3-4224-3b3e-ca0b-d3b711383251@hit.bme.hu> Date: Mon, 8 Oct 2018 16:45:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F61D220C883AD65C71F8305F" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.43.189; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] source of traffic share information -- Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:45:44 -0000 This is a multi-part message in MIME format. --------------F61D220C883AD65C71F8305F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Cameron, 10/8/2018 2:59 PM keltezéssel, Ca By írta: > Using round numbers on a mobile network, one can expect in HEv2 and > 464xlat: > > 75+% of traffic to be ipv6 e2e (no translation) > 24% to use dns64/nat64 (1 translation) > And less than 1% having a nat46 and nat64 (double translation due to > ipv4 socket and / or literal) > Could you mention some citable sources, which support your numbers? I would like to include these numbers not only in this draft, but in some other publications, thus some citable source would be of a great help. Thank you very much in advance, Gábor > In this effort, you may want to call out specifically 464xlat and > HEv2. They are similar but seperately specified. Both have tens of > millions of units deployed. > > https://tools.ietf.org/html/rfc8305 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------F61D220C883AD65C71F8305F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Cameron,

10/8/2018 2:59 PM keltezéssel, Ca By írta:
Using round numbers on a mobile network, one can expect in HEv2 and 464xlat:

75+% of traffic to be ipv6 e2e (no translation)
24% to use dns64/nat64 (1 translation)
And less than 1% having a nat46 and nat64 (double translation due to ipv4 socket and / or literal)


Could you mention some citable sources, which support your numbers?

I would like to include these numbers not only in this draft, but in some other publications, thus some citable source would be of a great help.

Thank you very much in advance,

Gábor

In this effort, you may want to call out specifically 464xlat and HEv2. They are similar but seperately specified. Both have tens of millions of units deployed. 




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------F61D220C883AD65C71F8305F-- From nobody Mon Oct 8 09:10:17 2018 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 336B8130E28 for ; Mon, 8 Oct 2018 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CeX1q4W-n64 for ; Mon, 8 Oct 2018 09:10:14 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84230130E93 for ; Mon, 8 Oct 2018 09:10:14 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 01B00FECBEF3; Mon, 8 Oct 2018 16:10:14 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 2E7607163C8; Mon, 8 Oct 2018 18:10:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Mon, 8 Oct 2018 18:10:12 +0200 Cc: "v6ops@ietf.org list" , Marius Georgescu Content-Transfer-Encoding: quoted-printable Message-Id: <4234E889-EB28-4CA8-8788-B100C3914DA4@employees.org> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <5F096E26-E48A-491C-8600-05F12B84CBB6@employees.org> To: =?utf-8?Q?Lencse_G=C3=A1bor?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Testing of transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" --] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:10:16 -0000 Lencse, >> Just send an IPv4 in IPv6 stream one way, receive IPv4 the other = direction. >=20 > It will not work. Let us see an example. If you want to test MAP-E BR = using the single DUT setup, then you need to send special IPv6 packets, = which contain IPv4 packets. The RFC 5180 compliant testers send either = IPv4 or IPv6 packets, but not these kinds of packets. >=20 > Besides the fact, that the traditional testers cannot create these = special packets, they also lack other functionalities: although some of = the measurement procedures of RFC 8219 are from RFC 2544, but there were = also further ones defined. Please refer to RFC 8219 for more details. Most testers allow you to configure packets to look like whatever you = like. I=E2=80=99ve tested MAP-E and MAP-T with both proprietary IXIA and open = source TREX. Sure, you might need to do a little bit of work to set it = all up. Cheers, Ole= From nobody Mon Oct 8 09:45:23 2018 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 17A01130DC0 for ; Mon, 8 Oct 2018 09:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG68SdFMfdT6 for ; Mon, 8 Oct 2018 09:45:17 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF5B129BBF for ; Mon, 8 Oct 2018 09:45:17 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id z144-v6so5901328lff.13 for ; Mon, 08 Oct 2018 09:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=Z2OD5SlxJrwjR/jUNDwNygINTbfXW+BrbdV5Ro7D3eg=; b=N+UTiB+UlL1BvKcTHxA0ipQq6JUzLxEqWzTaIt2mbB+LEH27rwRmVo8MdGdRony9zV +hwRqVh44V/61ruo0/m02so3AQ6Kj4YMcksMBoiSwjzJ3Me/Nq2Su7bywF/ZPpGxj7qP vo4tvHRghO2Nhtip/HKWe7FnOOiPMsnlPNuFBrMrCuzcp9UTdwtM/uy/BFI9KTbHnsS6 o8n12/6CkvTHzZDa9urKzyJoeI2BX4p3xHIfz31t2LsdQnjTp4dy5rYFciNGsj3+5U3P QGvo2hbyql9fbrX1mSoz0yS4x0qTDQR6yESoUwnEXuTgmyyQQCkfqFRdymlUFjd0+18I KmMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Z2OD5SlxJrwjR/jUNDwNygINTbfXW+BrbdV5Ro7D3eg=; b=dAoN/A192+4O8pxbbsg3QAq3mCFrWzMMw0SfU20aIO7CzEhHTQ9iOPry7hKLeqUW/4 RNe9oneX0wbzXlIuN55T6iL6qvv7EHu4HnVa476Ddba39ewdtTB29Kt9X/5MBQ8NIpsF zUH1NCGdJhko5NHZRjBYUQaqUsrxkqOuSPY4GNyrO2fmqeSPOi/KBFMlqRT+nFTyvsJp 4EW8o2wRq8EjYgfd1aN2v8ZYayfNgyfZeyqbktnRt+BOPWMJaVvIxKQRCoXOtb/jT9rd 1b+HLp/xvCS3k1/IgPrLJCD4B4Ynpf99RTECHeqL9AKzkaOTvx10KiLDq3WbCihcb/6b chIg== X-Gm-Message-State: ABuFfoh7Jh8dwnUxaT9T/V7b8hiti1Ul5CwcqEijNISRkrDqWm9Ckp8I dMDotlv4RgPi7+QVR43P9hC1gdxN0fGolmelZ1qLHOz62lM= X-Google-Smtp-Source: ACcGV63Ek51IHwgOm7T2+04a4ee/d5Oat1LEfgtjZdYT59DLoSVYE+kDsQWRrcViqLU6389DcpXX+zdz1ZF/JeeZE2w= X-Received: by 2002:a19:c951:: with SMTP id z78-v6mr12854727lff.150.1539017114846; Mon, 08 Oct 2018 09:45:14 -0700 (PDT) MIME-Version: 1.0 From: nalini elkins Date: Mon, 8 Oct 2018 09:45:02 -0700 Message-ID: To: v6ops list Cc: Lee Howard , "Ackermann, Michael" , Fred Baker Content-Type: multipart/alternative; boundary="0000000000006f1ac90577ba583d" Archived-At: Subject: [v6ops] Enterprises and IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:45:21 -0000 --0000000000006f1ac90577ba583d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable v6ops, "Brick and mortar" enterprises have lagged in their use and knowledge of IPv6. Lee Howard, Mike Ackermann and I have been working on how we might change that. We are making some progress. First, a big shout-out to Fred Baker for all his help and support in this effort. We have had conference calls every 2 weeks for about a year now & Fred has been on many of them. ARIN and NIST have also been extremely supportive and have participated regularly. What we are doing is starting with a free 2-hour class and lab. We have 99 people signed up. This is the breakdown: Insurance: Unique companies: 18 / Total attendees: 29 Outsourcers: Unique companies: 5 / Total attendees: 16 Financials: Unique companies: 4 / Total attendees: 10 Independent Software Vendors: Unique companies: 12 / Total attendees: 14 The rest are a mix of government, manufacturing, education and others. Nearly all are large, "brick and mortar" enterprises or sell / work with them. I think this is pretty good since often we have gotten less than 20 people (sometimes less than 10) from enterprises wanting to learn even when you set up free training. I could be wrong but I attribute it to the addition of the lab. NIST has some statistics about enterprise usage which you can see here. https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com Other people have statistics, any way you cut it, enterprise deployment has not been good. Our goal is to offer more training in 2019 and then get them to have as their first goal setting up their web server to be IPv6 enabled. We are working with a major university to set up a lab and to support people who have questions. We would like to get the v6ops community involved with enterprises. I think it could be beneficial for both parties. Getting people starting to get trained up does NOT mean they will inevitably take the next step to IPv6 enabling their network. Also, there are likely to be problems. I have no idea what they will be, but I am sure there will be problems. So the ask for v6ops is: 1. We would like to have 3-5 people working with us from the ground up to listen in on the classes and the kind of concerns that enterprises have. 2. I suspect it will take a minimum of 2 years before we "move the needle" on IPv6 deployment. 3. If you are interested, please contact me unicast. (You do not have to make a 2-year commitment! But, please, at least 6 months.) --------------------------------------------------- Here is the outline of the first class. We are starting at the VERY beginning and assuming NO knowledge. We are also tailoring the class and approach to the needs of large enterprises. 1. Initial training: 1 hour =E2=80=A2 Public and private addresses =E2=80=A2 IPv6 Prefixes =E2=80=A2 IPv6 Address Structure =E2=80=A2 IPv6 Interface ID =E2=80=A2 IPv6 Addressing and Address Allocation Methods (stateless, statef= ull) =E2=80=A2 Address types, unicast, multicast, anycast =E2=80=A2 Address categories: global, site local, link local =E2=80=A2 Unique Local Unicast addresses =E2=80=A2 Zero compression =E2=80=A2 Special addresses (loopback, unspecified, IPv4 mapped IPv6) =E2=80=A2 Broadcast address elimination 2. Guided lab: 1 hour =E2=80=A2 Connection from client and server =E2=80=A2 Ping / traceroute =E2=80=A2 Reading a trace =E2=80=A2 Simple FTP / web access A tentative list of the topics we will offer in 2019 is: - IPv6 Header - IPv6 Extension Headers - Neighbor Discovery Protocol (NDP) - Stateless Auto Discovery (SLAAC) - IPv6 Security - Routing: BGP, OSPFv3, EIGRP, MPLS - Dual-stack and Transition mechanisms - Hands-on dual stack lab for a web site/3-tier app - Cloud - Extension Headers applications (M-)-PDM, SRv6 --=20 Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --0000000000006f1ac90577ba583d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
v6ops,

&quo= t;Brick and mortar" enterprises have lagged in their use and knowledge= of IPv6.=C2=A0 =C2=A0Lee Howard, Mike Ackermann and=C2=A0
I have= been working on how we might change that.=C2=A0 We are making some progres= s.=C2=A0=C2=A0

First, a big shout-out to Fred Bake= r for all his help and support in this effort.=C2=A0 =C2=A0We have had conf= erence calls every 2
weeks for about a year now & Fred has be= en on many of them.=C2=A0 =C2=A0ARIN and NIST have also been extremely supp= ortive
and have participated regularly.

= What we are doing is starting with a free 2-hour class and lab.=C2=A0 We ha= ve 99 people signed up.=C2=A0=C2=A0

This is the br= eakdown:

Insurance: Unique companies: 18 / Total a= ttendees: 29
Outsourcers: Unique companies: 5 / Total attendees: = 16
Financials: Unique companies: 4 / Total attendees: 10
Independent Software Vendors: Unique companies: 12 / Total attendees: 14<= /div>

The rest are a mix of government, manufacturing, e= ducation and others.

Nearly all are large, "b= rick and mortar" enterprises or sell / work with them.

<= /div>
I think this is pretty good since often we have gotten less than = 20 people (sometimes less than 10) from enterprises
wanting to le= arn even when you set up free training.=C2=A0 I could be wrong but I attrib= ute it to the addition of the lab.

NIST has some s= tatistics about enterprise usage which you can see here.
Other people have statistics, any way you cut it, enterpr= ise deployment has not been good.=C2=A0=C2=A0

Our = goal is to offer more training in 2019 and then get them to have as their f= irst goal setting up their web server to
be IPv6 enabled.

We are working with a major university to set up a lab an= d to support people who have questions.

We would l= ike to get the v6ops community involved with enterprises.=C2=A0 I think it = could be beneficial for both parties.

Getting peop= le starting to get trained up does NOT mean they will inevitably take the n= ext step to IPv6 enabling their network.=C2=A0=C2=A0
Also, there = are likely to be problems.=C2=A0 I have no idea what they will be, but I am= sure there will be problems.

So the ask for v6ops= is:

1.=C2=A0 We would like to have 3-5 people wor= king with us from the ground up to listen in on the classes and the kind of= concerns
=C2=A0 =C2=A0 =C2=A0that enterprises have.
2.=C2=A0 I suspect it will take a minimum of 2 years before we= "move the needle" on IPv6 deployment.

3= .=C2=A0 If you are interested, please contact me unicast.=C2=A0 (You do not= have to make a 2-year commitment!=C2=A0 But, please, at least 6=C2=A0
=C2=A0 =C2=A0 months.)


------= ---------------------------------------------
=C2=A0
Here is the outline of the first class.=C2=A0 We are starting = at the VERY beginning and assuming NO knowledge.=C2=A0 We are also tailorin= g=C2=A0
the class and approach to the needs of large enterprises.=


1. Initial training: 1 hour=C2=A0<= /div>

=E2=80=A2 Public and private addresses
= =E2=80=A2 IPv6 Prefixes
=E2=80=A2 IPv6 Address Structure
=E2=80=A2 IPv6 Interface ID
=E2=80=A2 IPv6 Addressing and Addre= ss Allocation Methods (stateless, statefull)
=E2=80=A2 Address ty= pes, unicast, multicast, anycast
=E2=80=A2 Address categories: gl= obal, site local, link local
=E2=80=A2 Unique Local Unicast addre= sses
=E2=80=A2 Zero compression
=E2=80=A2 Special addre= sses (loopback, unspecified, IPv4 mapped IPv6)
=E2=80=A2 Broadcas= t address elimination=C2=A0

2. Guided lab: 1 hour<= /div>

=E2=80=A2 Connection from client and server
<= div>=E2=80=A2 Ping / traceroute
=E2=80=A2 Reading a trace
=E2=80=A2 Simple FTP / web access=C2=A0


A tentative list of the topics we will offer in 2019 is:
=
  • IPv6 Header
  • IPv6 Extension Headers
  • Neighbor Discovery Protocol (NDP)
  • Stateless Auto Discove= ry (SLAAC)
  • IPv6 Security
  • Routing: BGP, OSPFv3, EIGR= P, MPLS
  • Dual-stack and Transition mechanisms
  • Hands-= on dual stack lab for a web site/3-tier app
  • Cloud=C2=A0
  • Extension Headers applications (M-)-PDM, SRv6=C2=A0=C2=A0

--
Thanks,
Nalini Elkins
President
Enterprise Data Ce= nter Operators

--0000000000006f1ac90577ba583d-- From nobody Mon Oct 8 10:50:15 2018 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 4B9EA129C6A for ; Mon, 8 Oct 2018 10:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JfmfqTcqmuD for ; Mon, 8 Oct 2018 10:50:07 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7E9130E96 for ; Mon, 8 Oct 2018 10:49:44 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-43-189.kabelnet.hu [79.121.43.189]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w98HnWrV053651 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Oct 2018 19:49:37 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-43-189.kabelnet.hu [79.121.43.189] claimed to be [192.168.1.119] To: Ole Troan Cc: "v6ops@ietf.org list" , Marius Georgescu References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <5F096E26-E48A-491C-8600-05F12B84CBB6@employees.org> <4234E889-EB28-4CA8-8788-B100C3914DA4@employees.org> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Mon, 8 Oct 2018 19:49:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4234E889-EB28-4CA8-8788-B100C3914DA4@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.43.189; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] Testing of transition mechanisms [Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" --] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:50:10 -0000 Hi Ole, Thank you very much for mentioning TRex: https://trex-tgn.cisco.com/ It seems to be much easier to put together benchmarking tests using high level programming in Scapy for TRex than using bare DPDK programming in C. I have found some documentation here: https://trex-tgn.cisco.com/trex/doc/trex_stateless.html I think we will definitely give it a try. Best regards, Gábor 10/8/2018 6:10 PM keltezéssel, Ole Troan írta: > Lencse, > >>> Just send an IPv4 in IPv6 stream one way, receive IPv4 the other direction. >> It will not work. Let us see an example. If you want to test MAP-E BR using the single DUT setup, then you need to send special IPv6 packets, which contain IPv4 packets. The RFC 5180 compliant testers send either IPv4 or IPv6 packets, but not these kinds of packets. >> >> Besides the fact, that the traditional testers cannot create these special packets, they also lack other functionalities: although some of the measurement procedures of RFC 8219 are from RFC 2544, but there were also further ones defined. Please refer to RFC 8219 for more details. > Most testers allow you to configure packets to look like whatever you like. > I’ve tested MAP-E and MAP-T with both proprietary IXIA and open source TREX. Sure, you might need to do a little bit of work to set it all up. > > Cheers, > Ole From nobody Mon Oct 8 11:47:32 2018 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 D48FE130F49 for ; Mon, 8 Oct 2018 11:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylIe_ncsSJUt for ; Mon, 8 Oct 2018 11:47:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E8D130F2D for ; Mon, 8 Oct 2018 11:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539024445; x=1539629245; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=OfunjzGC VZDQAsVZ8A0MmQ+bgh75fxiCWJibxqutUx8=; b=anst0mpuxnXs1eSac3PSD2D+ NXlNFcJN+V3dhv0uRoBmgjpR1kXuhV4ovYahcFovtg9hDfJCo/Ghk5m0m2MVlgmW A9AL7bLjpMt5I0NuaGXz3F6VdWHfGlDlUVWGdO9Qylz7kuOWwowqZha1nb76slfH nNgRn6MlMcchWdcbpF4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 08 Oct 2018 20:47:25 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 08 Oct 2018 20:47:24 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005900579.msg for ; Mon, 08 Oct 2018 20:47:24 +0200 X-MDRemoteIP: 2001:470:1f09:495:c492:622:6739:49c6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 08 Oct 2018 20:47:24 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=18196384e0=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Mon, 08 Oct 2018 20:47:22 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E6114DE872CA@GAALPA1MSGUSRBF.ITServices.sbc.com> <2825C26D-3AF8-430C-90A8-C33ABF036C10@delong.com> <75b9afb7-f0f1-bf2b-1957-428bebe24108@gmail.com> In-Reply-To: <75b9afb7-f0f1-bf2b-1957-428bebe24108@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:47:31 -0000 Hi all, I've not responded before to all those comments, but I think in general the= discussion was very useful and we are about to finish a new version, which= we will publish in a few hours. Thanks to all the contributors! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Fecha: jueves, 30 de agosto de 2018, 22:31 Para: Owen DeLong CC: IPv6 Operations , "draft-palet-v6ops-rfc6177-bis@ietf.o= rg" , JORDI PALET MARTINEZ Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt Owen, On 2018-08-31 06:34, Owen DeLong wrote: >=20 >=20 >> On Aug 29, 2018, at 15:29 , Brian E Carpenter wrote: >> >> Barbara, >> On 2018-08-30 00:11, STARK, BARBARA H wrote: >>>> My understanding, no hats and potentially incorrect, is that any I= SP I know of >>>> will respond to a DHCPv6 IA_PD with a prefix at least as large as = requested, >>>> up to /48. >>> >>> I don't think this is correct. Of course, any provider using 6rd wo= n't respond to DHCPv6 at all. I'm aware of a lot of 6rd out there. >>> Wireless LTE providers don't tend to support DHCPv6, either. The /6= 4 advertised by the RA in an LTE environment is all the LTE UE will get. Th= at includes the case where the LTE UE is supporting a fixed wireless instal= lation. >>> For ISPs that support DHCPv6, it may or may not be the case. I've h= eard several say they do, but I'm not aware of a survey of all ISPs that wo= uld tell me how prevalent it is. >=20 > I can guarantee you that it=E2=80=99s false in a big way (unfortunate= ly). Comcast=E2=80=99s victims (or customers, depending on your perspective= ), for example, cannot get a /48 no matter what. >=20 > IIRC, they will allow a business customer to get up to a /56 and resi= dential customers are limited to a /60. >=20 > I believe they have or are in the process of resolving issues they pr= eviously had where if you requested larger than they would allow, they simp= ly didn=E2=80=99t give you anything at all=E2=80=A6 Not even a DENIED respo= nse. >=20 > I wish they would fix this. When I discussed the matter last with JJM= B, his response was =E2=80=9Cwe don=E2=80=99t feel that=E2=80=99s reasonabl= e=E2=80=A6 If we were to do that, we=E2=80=99d have to ask ARIN for a /12.= =E2=80=9D >=20 > My response was =E2=80=9Cduh!! You guys probably should have a /12. I= t=E2=80=99s permitted under existing policy. So what=E2=80=99s the issue?= =E2=80=9D He simply shook his head and walked away. >=20 > I=E2=80=99m guessing this will eventually be like Verizon=E2=80=99s r= esistance to routing /48s. The v4think will eventually get sorted out, but = likely persist for some time first. >=20 >>> BTW, I disagree with the abstract's statement that the "policy shou= ld reflect that assignment of a single subnet is never appropriate." I do n= ot believe this takes into consideration the fact that it would be tremendo= usly expensive for some ISPs to replace their current equipment when those = current equipment vendors are being slow about supporting certain features.= Cost is always an appropriate consideration.=20 >> >> I disagree. Yes, of course cost is always a consideration, but that = doesn't >> make a lower case "should" inappropriate. >=20 > I feel that there are actually cases where single-subnet assignment i= s perfectly reasonable. They are limited and should be determined by the cu= stomer, not the service provider, IMHO, but I also believe that all of thes= e decisions really are outside the purview of the IETF. The IETF should be = mandating that the standards for the equipment and the protocol enable the = service provider and the customer to handle multiple subnets. Specifying op= erational behavior beyond that which is necessary to enable the needed func= tionality is scope creep that we should try to avoid. >=20 >>> It also does not take into account CE routers that only request a s= ingle /64.=20 >> >> That's irrelevant. The customer might have bought such a router, but= the >> next customer along might have bought a full homenet-supporting CE. >=20 > That=E2=80=99s irrelevant. The protocol should enable the service pro= vider and customer to support either environment. =20 That's what I meant. If some customers only request a /64, and others r= equest a /48 (because they happened to buy different CE boxes), either should = work. =20 > We can make operational best practice recommendations to offer more t= han one subnet, but beyond that, we=E2=80=99re looking at the IETF putting = its nose where it doesn=E2=80=99t belong, IMHO. =20 I think the IETF can say "/56 is inadequate for some customers. /48 is = adequate for most customers." Of course, we can't dictate terms to ISPs, and nei= ther can the RIRs. =20 >>> I think it's inappropriate for IETF to be trying to dictate what is= and isn't "appropriate". Recommending a best current practice is fine. But= that's not the same as saying something is "never appropriate". >> >> Let's say "never recommended" then. >=20 > Meh=E2=80=A6 I could live with that. =20 OK then ;-) =20 Regards Brian =20 >=20 > Owen >=20 >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Oct 8 20:46:57 2018 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 277ED13110B for ; Mon, 8 Oct 2018 20:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZvhi7vHEI2X for ; Mon, 8 Oct 2018 20:46:53 -0700 (PDT) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C58131119 for ; Mon, 8 Oct 2018 20:46:53 -0700 (PDT) Received: by mail-yw1-xc2a.google.com with SMTP id m127-v6so87923ywb.0 for ; Mon, 08 Oct 2018 20:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=URJJsIw6aXFsYN2ddLSUpXB0hrRCpPk4fqriNJ8Q1G8=; b=KMgrybYmY5YeRkt2W7joy++EyxfpDV6Wtuybua+moZQFuYLrA1tQ5DkiVQF7N7jSmE MkrQLpJkKII5++NZU7D9U09nG6uGnj9NxKIIbzFzg/muu22O75ptq2t9eBv+c6jU4hZH UAjqpKthBid2D+8XzrbC9/MNdTNLNBwTCV6/aa5vxIsBhtu3za+xHL7zM/DZyB+HpIBh gLIs72wQbqQY9DEGm/W7oZ3TjkewTj76iYciM+RkE+jzexYvzHCBOgh/HEKeGjc73Zjy uON/CO5wcKmc5VEOlIK8To/MV7QMX1DKAU1WR4w5u1uYbTZ1IsT+nX1Be+0A6HPS5voS Be7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=URJJsIw6aXFsYN2ddLSUpXB0hrRCpPk4fqriNJ8Q1G8=; b=FlUq/OnvfAJFQQuZi9hZ574jcea017I09Iqk2suabiIxwN6L0dz8clrmDYQvBOykg6 JyR0saG/dPzwuzIOZsP+W+Cq+h9UJkTT558V4Q0I8rtn5kQL1ckev3YckPBkrtti1EGV eCme79/SUk5/7dIW6jZy8RmQQvT6Au/tCc1nSwEoRaKOR8qIHPP32e+MED10oius8YI0 Ik+vYs7wDuP72/xJuZQnSy11Vj3ZYA01xHvlAu3RrW1b4/np39iK5czYTRUMDheaZsix fIVzuGLXfrGF5soXjlTxyS8UGj91ji/u7HuOz3nWvxhhxHmtd/wNAOtnC3FJb2sc52xV YQGQ== X-Gm-Message-State: ABuFfojpFpMfwhIiBvL9zLfnwVHHEpp5Qq0oDUyNIor/jxv8yx1HV+hS 4+nzC33nSGV1pEZhD8cl0iM6WWDWRmXOx7Gf6h/tFA== X-Google-Smtp-Source: ACcGV616sj0165hLscIFiIkatul1YnTit8v5a4YqUsRzVOJcKHsp0d9TU/r+qMcqVinbE8kEM3ZlZ181H4X2lYIt/ec= X-Received: by 2002:a81:c806:: with SMTP id n6-v6mr14064676ywi.205.1539056812890; Mon, 08 Oct 2018 20:46:52 -0700 (PDT) MIME-Version: 1.0 References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org> <14CD2048-79BD-4654-BF26-0881457347A0@employees.org> <54b0e5b3-4224-3b3e-ca0b-d3b711383251@hit.bme.hu> In-Reply-To: <54b0e5b3-4224-3b3e-ca0b-d3b711383251@hit.bme.hu> From: Ca By Date: Mon, 8 Oct 2018 20:46:41 -0700 Message-ID: To: =?UTF-8?Q?Lencse_G=C3=A1bor?= Cc: Ole Troan , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000009f20400577c396aa" Archived-At: Subject: Re: [v6ops] source of traffic share information -- Re: New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 03:46:55 -0000 --0000000000009f20400577c396aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2018 at 7:45 AM Lencse G=C3=A1bor wrote: > Dear Cameron, > > 10/8/2018 2:59 PM keltez=C3=A9ssel, Ca By =C3=ADrta: > > Using round numbers on a mobile network, one can expect in HEv2 and > 464xlat: > > 75+% of traffic to be ipv6 e2e (no translation) > 24% to use dns64/nat64 (1 translation) > And less than 1% having a nat46 and nat64 (double translation due to ipv4 > socket and / or literal) > > > Could you mention some citable sources, which support your numbers? > > I would like to include these numbers not only in this draft, but in some > other publications, thus some citable source would be of a great help. > > Thank you very much in advance, > > G=C3=A1bor > If you can estimate how much traffic major ipv6 sources like Google / YT, facebook, Apple, and netflix are then you sprinkle in some Ipv6 from Spotify, pandora, Akamai and Amazon, you are probably pretty close to 75% of content > In this effort, you may want to call out specifically 464xlat and HEv2. > They are similar but seperately specified. Both have tens of millions of > units deployed. > > https://tools.ietf.org/html/rfc8305 > > > > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > --0000000000009f20400577c396aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon,= Oct 8, 2018 at 7:45 AM Lencse G=C3=A1bor <lencse@hit.bme.hu> wrote:
=20 =20 =20
Dear Cameron,

10/8/2018 2:59 PM keltez=C3=A9ssel, Ca By =C3=ADrta:
=20 Using round numbers on a mobile network, one can expect in HEv2 and 464xlat:

75+% of traffic to be ipv6 e2e (no translation)
24% to use dns64/nat64 (1 translation)
And less than 1% having a nat46 and nat64 (double translation due to ipv4 socket and / or literal)


Could you mention some citable sources, which support your numbers?

I would like to include these numbers not only in this draft, but in some other publications, thus some citable source would be of a great help.

Thank you very much in advance,

G=C3=A1bor

If you= can estimate how much traffic major ipv6 sources like Google / YT, faceboo= k, Apple, and netflix are then you sprinkle in some Ipv6 from
Spotify, pandora, Akamai and Amazon, you are probably pretty clos= e to 75% of content


In this effort, you may want to call out specifically 464xlat and HEv2. They are similar but seperately specified. Both have tens of millions of units deployed.=C2=A0




_______________________________________________
v6ops mailing list
v6ops@ietf.= org
https://www.ietf.org/mailman/listinfo/v6ops

--0000000000009f20400577c396aa-- From nobody Tue Oct 9 01:36:30 2018 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 CAD0A13121A for ; Tue, 9 Oct 2018 01:36:28 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXSMmpIfrRqC for ; Tue, 9 Oct 2018 01:36:26 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6818B131202 for ; Tue, 9 Oct 2018 01:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539074183; x=1539678983; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=IhEfovO1 wRIjI42IcAjkfr/d9DWBXqIWVuBzR1ZQ4TU=; b=HfOaSfsWd+1CSOLG4STWSSaE vMt+bQkXVODZvEi17Muyj2R/Wy18V0UdduyyPu/JSWTvQo4f57y1s0YL3pxqA+5v IzGqEYh9lGJBqeTE1PXtISHURuLHYAu4p1nofPHJprR/wzZMlcv/tI2o8VmiX9h3 2NdMzOJsOHUbWZt56aw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 09 Oct 2018 10:36:23 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 09 Oct 2018 10:36:22 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005901342.msg for ; Tue, 09 Oct 2018 10:36:22 +0200 X-MDRemoteIP: 2001:470:1f09:495:c492:622:6739:49c6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 09 Oct 2018 10:36:22 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=182065922b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Tue, 09 Oct 2018 10:36:22 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <923C9D3B-84AC-4993-8BA6-24B403F5F3D7@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-rfc6177-bis References: <80ec965c-4a6c-3cc8-b92f-ad03603f9223@gmail.com> <16634B7C-B8B0-49B5-B98E-D889F77571F5@cisco.com> In-Reply-To: <16634B7C-B8B0-49B5-B98E-D889F77571F5@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-rfc6177-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 08:36:29 -0000 Hi Rajiv, I've discussed this with my co-author, and we believe that this document sh= ould not define an end-site. This should be (and I guess it is), defined ge= nerically for many IETF documents, not just this one. Similarly, the cellular aspect, it has been already defined in several othe= r documents, even in the latest 3GPP releases. We have some text already ab= out that at the end of section 4, and we have also the case for a cellular = device (even a smartphone) acting as a router, which connects an end-site, = and in that case, falls also within the scope of this document. Of course, if the WG believes we should do that, we will do it in a new ver= sion. Regarsd, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "Rajiv Asati (rajiva)" Fecha: mi=C3=A9rcoles, 29 de agosto de 2018, 0:03 Para: Brian E Carpenter CC: "v6ops@ietf.org" Asunto: Re: [v6ops] draft-palet-v6ops-rfc6177-bis =20 This draft should provide a definition for the end-site. Is it a connec= tivity device such as a home GW/router or consumption device such as a mobi= le tablet or ...? Answer is all of the above.=20 =20 This draft should also explicitly cover cellular/mobile devices that cu= rrently get limited to /64, since they could also qualify as end-site.=20 =20 Cheers, Rajiv Asati =20 =20 =20 > On Aug 28, 2018, at 1:11 AM, Brian E Carpenter wrote: >=20 > Hi, >=20 > I fully support this draft. Here are a few (minor) wording issues > and some nits. >=20 > Issues: > ------- >> [RFC3177] called for a default end-site IPv6 assignment size of /4= 8. >> Subsequently, the Regional Internet Registries (RIRs) developed an= d >> adopted IPv6 address assignment and allocation policies consistent >> with those recommendations, and it triggered the development of >> [RFC6177]. However, some of the RIRs, have later on updated those >> policies, which still allow using /48, but leave the decision in t= he >> hands of the ISP, or even, in some cases, encourage the assignment= of >> smaller (e.g., /56) blocks to residential end-sites, while keeping >> /48 for business. >=20 > I don't think that is accurate. Actually there was push-back *from* > the RIRs against the wording of 3177, because some ISPs did not wish > to be consistent with it. Here's another version: >=20 > [RFC3177] called for a default end-site IPv6 assignment size of /48= . > Subsequently, the Regional Internet Registries (RIRs) developed and > adopted IPv6 address assignment and allocation policies consistent > with ISP practices, and this triggered the development of [RFC6177]= . > Current RIR policies still allow using /48, but leave the decision = in the > hands of the ISP, or even, in some cases, endorse the assignment of > smaller (e.g., /56) blocks to residential end-sites, while keeping > /48 for business. >=20 >> This raises the question of a possible misinterpretation of [RFC61= 77] >> by at least 1/3rd of the operational community and consequently, t= he >> need to revisit it. >=20 > No, I don't think there's any misinterpretation. I think it's quite > clear (as in my previous comment) that this is exactly why the ISP > community pushed for RFC6177. I think we should phrase this a bit > differently. >=20 > This raises the question of over-zealous interpretation of [RFC6177= ] > by at least one third of the ISP community and consequently, the > need to revisit it. >=20 >> It might be tempting to give home sites a single /64, since that i= s >> already significantly more address space compared with today's IPv= 4 >> practice. However, this precludes the certainty that even home si= tes >> will grow to support multiple subnets going forward. Hence, it is >> strongly intended that even home sites be given a big number of >> subnets worth of space, by default. Hence, this document still >> recommends giving home sites significantly many more than a single >> /64. >=20 > I think a reference to RFC7368 and RFC7788 would be useful here, to m= ake > it clear that this is not guesswork. (Note that HNCP is mentioned lat= er, > so there is a little repetition in the argument.) >=20 > Nits: > ----- >=20 >> Abstract >>=20 >> The Regional Internet Registries (RIRs) policies, have different > Delete the comma >=20 >> requires an ever-increasing availability of subnets at the end-site >> and so, policy should reflect that assignment of a single subnet is >=20 > NEW > requires an ever-increasing availability of subnets at the end-site= , > so policy should reflect that the assignment of a single subnet is >=20 > I see a number of other minor syntax and punctuation nits in the > text, but I'm afraid I'm going to leave those for the copy-editor. >=20 > Regards, > Brian >=20 > _______________________________________________ > 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 =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Oct 9 01:58:50 2018 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 89B5E13122B for ; Tue, 9 Oct 2018 01:58:49 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlE3ikNHJeoL for ; Tue, 9 Oct 2018 01:58:47 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCF71311AA for ; Tue, 9 Oct 2018 01:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539075524; x=1539680324; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=G0h1c0KO 9mKgeLJAqFMlVLWZnnzFAa+Iogh9T4h8NPw=; b=hX/r6RVlZhCih/HOrhZZBIvH +tkw/UoR44PElRA7Uk/8KWPHbg6s7NwoHb1BFSnM9801WxwK/HAPF1ucvqPOLpON mDZXkQBtxOSope+CzFplSA8wUXQzFNlnOvJnBtwGmWmml+3tM7VkkYnYYFM1fwXZ nGq3wcorKswynKaLV/c= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 09 Oct 2018 10:58:44 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 09 Oct 2018 10:58:44 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005901370.msg for ; Tue, 09 Oct 2018 10:58:43 +0200 X-MDRemoteIP: 2001:470:1f09:495:c492:622:6739:49c6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 09 Oct 2018 10:58:43 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=182065922b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Tue, 09 Oct 2018 10:58:40 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <086BD63D-4250-4C21-9CD9-D7D2D0A61E7E@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-rfc6177-bis-02.txt References: <153907543798.12125.17503649438121166440.idtracker@ietfa.amsl.com> In-Reply-To: <153907543798.12125.17503649438121166440.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc6177-bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 08:58:50 -0000 Hi all, We have a new version of this document: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6177-bis/?include_tex= t=3D1 Inputs welcome! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: martes, 9 de octubre de 2018, 10:57 Para: Jordi Palet , Jordi Palet Martinez , Rosalea G Roberts , Rosalea Roberts Asunto: New Version Notification for draft-palet-v6ops-rfc6177-bis-02.txt =20 A new version of I-D, draft-palet-v6ops-rfc6177-bis-02.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-rfc6177-bis Revision: 02 Title: IPv6 Address Assignment to End-Sites Document date: 2018-10-09 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= rfc6177-bis-02.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6= 177-bis/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-b= is-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -rfc6177-bis Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-r= fc6177-bis-02 =20 Abstract: The Regional Internet Registries (RIRs) policies have different view= s regarding the recommendation of the prefix to be assigned to end- sites. However, all them allow up to a /48 without further justification and clearly state that the exact choice of how much address space should be assigned to end-sites is a decision of each operator. =20 This document reviews the architectural and operational considerations of end-site assignments, and reiterates that assignment policy and guidelines belong to the RIR community. This revision is being made to emphasize that IPv6 protocol evolution requires an ever-increasing availability of subnets at the end-site, so policy should reflect that assignment of a single subnet is never recommended. =20 This document obsoletes RFC6177 (IPv6 Address Assignment to End Sites). =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Oct 9 03:52:09 2018 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 B8A02131270 for ; Tue, 9 Oct 2018 03:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4EFjgMw1dmn for ; Tue, 9 Oct 2018 03:52:04 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E5113126E for ; Tue, 9 Oct 2018 03:52:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w99Aq2v7015117 for ; Tue, 9 Oct 2018 12:52:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1F20320362C for ; Tue, 9 Oct 2018 12:52:02 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 15CA220164C for ; Tue, 9 Oct 2018 12:52:02 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w99Aq1wD032147 for ; Tue, 9 Oct 2018 12:52:02 +0200 To: v6ops@ietf.org References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> From: Alexandre Petrescu Message-ID: <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> Date: Tue, 9 Oct 2018 12:52:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:52:07 -0000 Thank you for this draft. For my clarification: draft says: > [...] while the ISPs have only IPv6 > in their access and or core network. [...] Is it common to have IPv6 only in the access network? As far as I remember, cellular ISPs carry GTP on IPv4 at the lowest layer. Alex Le 06/10/2018 à 15:07, Lencse Gábor a écrit : > Dear v6ops Members, > > We have prepared the "-00" version of our I-D "Pros and Cons of IPv6 > Transition Technologies for IPv4aaS". > > Thank you very much for everyone, who have given us input through the > previous discussion on this list or through the Google spreadsheet, > which is still available at: > https://docs.google.com/spreadsheets/d/1W3Px8I_RyLA_tnmmNkJj6qJS0tvg93oCU0XfZzlljto/edit#gid=0 > > Could you give us further feedback? > > Thank you very much for your help in advance! > > Best regards, > > Gábor Lencse > > -------- Továbbított üzenet -------- > Tárgy: New Version Notification for > draft-lmhp-v6ops-transition-comparison-00.txt > Dátum: Sat, 06 Oct 2018 05:52:11 -0700 > Feladó: internet-drafts@ietf.org > Címzett: Lee Howard , Jordi Palet > , Jordi Palet Martinez > , Gabor Lencse , > Richard Patterson > > > > A new version of I-D, draft-lmhp-v6ops-transition-comparison-00.txt > has been successfully submitted by Gabor Lencse and posted to the > IETF repository. > > Name: draft-lmhp-v6ops-transition-comparison > Revision: 00 > Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS > Document date: 2018-10-06 > Group: Individual Submission > Pages: 11 > URL:https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-00.txt > Status:https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ > Htmlized:https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00 > Htmlized:https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison > > > Abstract: > Several IPv6 transition technologies can be used to provide IPv4-as- > a-service (IPv4aaS) to the customers, while the ISPs have only IPv6 > in their access and or core network. All these technologies have > their advantages and disadvantages. Depending on several various > conditions and preferences, different technologies may prove to be > the most appropriate solution. This document examines the five most > prominent IPv4aaS technologies considering several different aspects > in order to provide network operators with an easy to use guideline > for selecting the technology that suit their needs the best. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Oct 9 04:02:16 2018 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 1DADE131287 for ; Tue, 9 Oct 2018 04:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmWJ__vPdsUk for ; Tue, 9 Oct 2018 04:02:13 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA4413127F for ; Tue, 9 Oct 2018 04:02:13 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id c85-v6so1965772itd.1 for ; Tue, 09 Oct 2018 04:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IatiPnIDvMoG1ii6kSjBDF6yK5r/dN8HWxiA/am+32w=; b=aQWSz/FKqyMkux25bW8CsfmikExrLQ8r8CNEa+AiCd2KvBCrDuk3xOX9iq8SpwZRn1 xlKstf0Mt/GWBABwnM56mwDIggmOVbWwQVKOWGwqMse36swLcPJ2kRPMDmTiyH4t7E4d yP9IreSUA9YTjNLUt7aTI5J5Eo+gzCor64Wn8MXlFlLajTMgEamnxOiJvcfP15CKU8mP tTTBO5i5VfJmxBCJJmaaAUcD0cZYvwBVu+ZUELqMec2uLdATcqm2ZaRYFf0Csxe4PHd9 bXpeKhfN2WCNTjCl1/fz4qRFcGdQtQq48Dl5TfDW1uk1dEXltPd9CL5xxIMaRlcxN2Cl 8FYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IatiPnIDvMoG1ii6kSjBDF6yK5r/dN8HWxiA/am+32w=; b=SJGeF3fSxV5z4tkkPw6/NXL+a6cY4KtvuAn7WTDzl6o/0o8lGH9l2qLyLOKVRqqz7W vYaEuSbQvw39s1o122ElqNVeeiik7BH0DrZDcVYeKje3g68P6KsVN0I5my5s/U8MBqIC Gf/WcL8my35uP8sYhZeOew9V2blYRiCMhj5s9hd77aiarwjiM6PP0iTh2z76N3vpxxk/ ky8v5j0+0/KSbvZ59GBk+ejru2rapLjSIfR+9/VEB0jTU/1BN419h/L4rbMlOwTmi/EF bRCHecUZelFF2EWQirKxqKezcUbp1KouqZeP9F1WgklFS5Bn0t0PFY2UHr7SdGZ/Y6U6 LRtg== X-Gm-Message-State: ABuFfoh6vYl7OVE1A23zewom/rnh097TRV1eDNVnBcanoUqYZn5Ki0o7 S61dMvH+FQhG8ypLqFi6dvVQUYOC7Lo= X-Google-Smtp-Source: ACcGV62OLHASXtTTbRnuyKQu7bHf9rZau+1D0a9fLhEyCxaPudNYsSItewBfGTHd7W5qpL6zfRVB+g== X-Received: by 2002:a02:8907:: with SMTP id o7-v6mr22739240jaj.7.1539082932273; Tue, 09 Oct 2018 04:02:12 -0700 (PDT) Received: from mail-it1-f180.google.com (mail-it1-f180.google.com. [209.85.166.180]) by smtp.gmail.com with ESMTPSA id y11-v6sm5498285ioa.24.2018.10.09.04.02.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Oct 2018 04:02:11 -0700 (PDT) Received: by mail-it1-f180.google.com with SMTP id c85-v6so1965680itd.1 for ; Tue, 09 Oct 2018 04:02:11 -0700 (PDT) X-Received: by 2002:a24:414:: with SMTP id 20-v6mr1478664itb.158.1539082931465; Tue, 09 Oct 2018 04:02:11 -0700 (PDT) MIME-Version: 1.0 References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> In-Reply-To: <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> From: Richard Patterson Date: Tue, 9 Oct 2018 12:02:00 +0100 X-Gmail-Original-Message-ID: Message-ID: To: alexandre.petrescu@gmail.com Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 11:02:15 -0000 On Tue, 9 Oct 2018 at 11:52, Alexandre Petrescu wrote: > Is it common to have IPv6 only in the access network? Perhaps not "common" yet, but for those that are building greenfield networks, it's very appealing. From nobody Tue Oct 9 04:16:48 2018 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 0ACA51312CD for ; Tue, 9 Oct 2018 04:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7ie9pmvNes5 for ; Tue, 9 Oct 2018 04:16:45 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABF21312C6 for ; Tue, 9 Oct 2018 04:16:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 083F4B1; Tue, 9 Oct 2018 13:16:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539083802; bh=zvaMgQvFptxEiyKOQ768QkqgxLLSqfHedx0cWllDyKY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sId99NpHVTuQNtfdmCuYUDm+RPTKealaPGSA/30q2JuikAYhpuik7b2TQ1v9zgsI/ CRdBcOD0IkpW+Rerh8cstlz6DXcxr+Kw8j38WS6dW5Old0ytnS85x60luhH7sElZcg TYqiYuw8vfvIfGs/DmmDz0MZLEfLk6HZyw8PXVR8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 05F69B0; Tue, 9 Oct 2018 13:16:42 +0200 (CEST) Date: Tue, 9 Oct 2018 13:16:41 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> Message-ID: References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 11:16:47 -0000 On Tue, 9 Oct 2018, Alexandre Petrescu wrote: > Is it common to have IPv6 only in the access network? DOCSIS and ds.lite has millions of customers deployed, so yes. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Oct 9 04:26:01 2018 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 538AC1312F9 for ; Tue, 9 Oct 2018 04:25:55 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wry4iBydIjiJ for ; Tue, 9 Oct 2018 04:25:53 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1392131301 for ; Tue, 9 Oct 2018 04:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539084350; x=1539689150; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=R/Wcfj46WfeIva+5Erfs+9OKuyZ2KEVmqqIrzY9pt60=; b=lz+7p8cl1vKZ6 rqy6B6jiEur4B/Myd3DJQzPq9TB+PUmARXEUT+p2LugUEZAv9cQMgc66yEGc78wo NghcQc/8TB3juJjTcVs003HUMiF8qzJgb6yQAvl2cKEt4257yqtzymTWpZZ9bGHQ mqjGjGyuEH4//TYIXyjbykRiXVt6T8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 09 Oct 2018 13:25:50 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 09 Oct 2018 13:25:50 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005901546.msg for ; Tue, 09 Oct 2018 13:25:49 +0200 X-MDRemoteIP: 2001:470:1f09:495:c492:622:6739:49c6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 09 Oct 2018 13:25:49 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=182065922b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Tue, 09 Oct 2018 13:25:44 +0200 From: JORDI PALET MARTINEZ To: Mikael Abrahamsson , Alexandre Petrescu CC: Message-ID: <0B314164-D3A7-4C22-A648-B3332EFA8F3E@consulintel.es> Thread-Topic: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 11:26:00 -0000 Add to that some lw4o6 deployments, a few MAP-E/T and many 464XLAT ones (wh= ich are actually the bigger ones if we include the cellular networks). Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Fecha: martes, 9 de octubre de 2018, 13:17 Para: Alexandre Petrescu CC: Asunto: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies= for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transit= ion-comparison-00.txt On Tue, 9 Oct 2018, Alexandre Petrescu wrote: =20 > Is it common to have IPv6 only in the access network? =20 DOCSIS and ds.lite has millions of customers deployed, so yes. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Oct 9 05:21:27 2018 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 56840131307 for ; Tue, 9 Oct 2018 05:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaM7NCP65rwp for ; Tue, 9 Oct 2018 05:21:24 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A15D1312F4 for ; Tue, 9 Oct 2018 05:21:23 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 70F4841CDD for ; Tue, 9 Oct 2018 14:21:20 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 64C5541CDC; Tue, 9 Oct 2018 14:21:20 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 55DC337836; Tue, 9 Oct 2018 14:21:20 +0200 (CEST) Date: Tue, 9 Oct 2018 14:21:20 +0200 From: Gert Doering To: Alexandre Petrescu Cc: v6ops@ietf.org Message-ID: <20181009122120.GH11393@Space.Net> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 12:21:26 -0000 Hi, On Tue, Oct 09, 2018 at 12:52:01PM +0200, Alexandre Petrescu wrote: > Thank you for this draft. > > For my clarification: > > draft says: > > [...] while the ISPs have only IPv6 > > in their access and or core network. [...] > > Is it common to have IPv6 only in the access network? It's one possible deployment of "IP to the mobile clients". > As far as I remember, cellular ISPs carry GTP on IPv4 at the lowest layer. What they do in the underlay has no relevance. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Oct 9 05:50:39 2018 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 3441F1312FC for ; Tue, 9 Oct 2018 05:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5jPEJ-HU28t for ; Tue, 9 Oct 2018 05:50:37 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75273131314 for ; Tue, 9 Oct 2018 05:50:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w99CoYns017539; Tue, 9 Oct 2018 14:50:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 48882206110; Tue, 9 Oct 2018 14:50:34 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3A24C205F13; Tue, 9 Oct 2018 14:50:34 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w99CoXXA003081; Tue, 9 Oct 2018 14:50:34 +0200 To: Gert Doering Cc: v6ops@ietf.org References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> <20181009122120.GH11393@Space.Net> From: Alexandre Petrescu Message-ID: <8bfa93d3-c097-abe9-5c6c-41c64d036cbf@gmail.com> Date: Tue, 9 Oct 2018 14:50:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181009122120.GH11393@Space.Net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 12:50:38 -0000 Le 09/10/2018 à 14:21, Gert Doering a écrit : > Hi, > > On Tue, Oct 09, 2018 at 12:52:01PM +0200, Alexandre Petrescu wrote: >> Thank you for this draft. >> >> For my clarification: >> >> draft says: >>> [...] while the ISPs have only IPv6 >>> in their access and or core network. [...] >> >> Is it common to have IPv6 only in the access network? > > It's one possible deployment of "IP to the mobile clients". > >> As far as I remember, cellular ISPs carry GTP on IPv4 at the lowest layer. > > What they do in the underlay has no relevance. It does have relevance to me, thank you. Alex > > Gert Doering > -- NetMaster > From nobody Wed Oct 10 04:20:06 2018 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 B77FD130ED6; Wed, 10 Oct 2018 04:20:04 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cSsmohSneyS; Wed, 10 Oct 2018 04:20:02 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A74130ED3; Wed, 10 Oct 2018 04:20:02 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id e22-v6so5140784qto.6; Wed, 10 Oct 2018 04:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tra/yfxyndbM2GGOc4Sh1wn8I2NIfKr75sg5+ZG5VGg=; b=DORJjUBMo8bRbYyRnQA8ePzcaQfJCgEeI6kxoqrug9bTEY0RwKRxEy4fW0w4uXUTRk vCe0LwDHiFOFu0n2EuQL0GC8FUfZHhUy9uRwwScRxfCjIn6ea6tASnWDpnUQbUzgOINv hocyLoU9/cSXea9S+ZiEKtYQfxqOSWpGrJPPIGSlISYjbOF1CDHCmx8hLtp0Uv93hcwg lBZ0zRT1HAxs97grUbdFn19C0Net9FIBL7YhQVX/cqzwZST7PyIM162Q5XMO5skQWqw+ LbHHMhmfRWE2tYndsMXZBNGE8NM024Jhkq1G37o1bY9sou/LRTCUufqsLTJkngWxTAGM czZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tra/yfxyndbM2GGOc4Sh1wn8I2NIfKr75sg5+ZG5VGg=; b=qzYjSqfaa+371urXj3TCNxrTy2fAVU+mC+syzy4tKk6OQAzRnbbtObFKgfyRe2ke9g pQ5y6KVSmhcyRD6cG8Dd4ly+ioNqz5GUOtO8g3jaLv/N4QqaN1DTbLpEAltUtLO62MRZ kIuhORFyGoXeBenCh71iJk/cxacLgvgjCJURL3Vw/Plh1LuT7oqCTe+b1/+TGsXk05Py D7ULp/X3t4wY7Cl9S3Yyx3tuj8BnzJ6gkCbQbzBMDQVGGFH6+iIRoo0FrNuKqtnnsQkY P5/NCpAPnHPZibAer++HYzlWrZbbfMeQmp2wmPiZp0AG43poY8FXlyWBW2NlowLybFVk 1MhQ== X-Gm-Message-State: ABuFfojYEk8LTCruDffzRFXfvzw9RkuanwVD08YzvYvLSmteet9W88XA ORTZ22iWWjLELLz//caC/fbfTVbtDamWWmJn/Cb1wyc3GTtg3w== X-Google-Smtp-Source: ACcGV603vraavSXKVWWj61rfVaG0yB5fb1YiGHzOZEdhmllb57qbxT49xD6J1g8xDFlx4MsuILfHCwfnPq7dkizwon4= X-Received: by 2002:a0c:c172:: with SMTP id i47-v6mr27093959qvh.213.1539170401305; Wed, 10 Oct 2018 04:20:01 -0700 (PDT) MIME-Version: 1.0 From: Davey Song Date: Wed, 10 Oct 2018 19:20:03 +0800 Message-ID: To: dnsop , v6ops@ietf.org Cc: weijianliao@tencent.com Content-Type: multipart/alternative; boundary="00000000000004cd9a0577de0953" Archived-At: Subject: [v6ops] Taking IPv4 GeoIP into account for IPv6 GeoIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 11:20:05 -0000 --00000000000004cd9a0577de0953 Content-Type: text/plain; charset="UTF-8" Hi all, Recently I'm engaged in a project on the issue of IPv6 GeoIP for a large Internet company. IPv6 GeoIP is identified as an notable chanllge to mitigate their Geolocation-based application to IPv6. I come up with a idea to summarize the existing practice and propsed technologies into a information draft. I'm hoping relevant people can help to review it and share your insight on this issue. I put it into my Github repo : https://github.com/songlinjian/dualstack-geoip/blob/master/dualstack-geoip.md . Short abstract of this document : During IPv6 adoption, IPv6 GeoIP is identified as a challenge and speed bump for content and application operator. Some studies and operational experiences show that the accuracy of IPv6 GeoIP is relatively poor in comparison to their IPv4 counterparts. This memo introduces use cases and approaches to provide better IPv6 GeoIP based on an intuitive idea: if IPv6 GeoIP is not as good as IPv4 GeoIP, why not use dual-stack host's IPv4 GeoIP for IPv6 GeoIP purpose? I would like to ask : 1) Do you like it or not? Is this document valuable to be published in IETF? 2) If yes , which WG should it belong to? v6ops or dnsop 3) Is there any similar and relevant practice do you observe or operate now? What's the major challenges. Best regards, Davey --00000000000004cd9a0577de0953 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0
=

Recently I'm engaged in a project on the issue of I= Pv6 GeoIP for a large Internet company. IPv6 GeoIP is identified as an nota= ble chanllge to mitigate their Geolocation-based application to IPv6. I com= e up with a idea to summarize the existing practice and propsed technologie= s into a information draft. I'm hoping relevant people can help to revi= ew it and share your insight on this issue.


Short abstract of this document :

<= div>During IPv6 adoption, IPv6 GeoIP is identified as a challenge and speed= bump for content and application operator. Some studies and operational ex= periences show that the accuracy of IPv6 GeoIP is relatively poor in compar= ison to their IPv4 counterparts. This memo introduces use cases and approac= hes to provide better IPv6 GeoIP based on an intuitive idea: if IPv6 GeoIP = is not as good as IPv4 GeoIP, why not use dual-stack host's IPv4 GeoIP = for IPv6 GeoIP purpose?

I would like to ask :

1) Do you like it or not? Is this document valuable to= be published in IETF?
2) If yes , which WG should it belong to? = v6ops or dnsop
3) Is there any similar and relevant practice do y= ou observe or operate now?=C2=A0 What's the major challenges.=C2=A0
=

Best regards,
Davey
--00000000000004cd9a0577de0953-- From nobody Wed Oct 10 09:23:56 2018 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 55128130F65 for ; Wed, 10 Oct 2018 09:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnkmc7wDzSlE for ; Wed, 10 Oct 2018 09:23:53 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4CD130E9D for ; Wed, 10 Oct 2018 09:23:52 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2701041CDB for ; Wed, 10 Oct 2018 18:23:49 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 184AC418E5; Wed, 10 Oct 2018 18:23:49 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 143C537470; Wed, 10 Oct 2018 18:23:49 +0200 (CEST) Date: Wed, 10 Oct 2018 18:23:48 +0200 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20181010162348.GZ11393@Space.Net> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> <20181009122120.GH11393@Space.Net> <8bfa93d3-c097-abe9-5c6c-41c64d036cbf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BxzNiyccsRNpDIZo" Content-Disposition: inline In-Reply-To: <8bfa93d3-c097-abe9-5c6c-41c64d036cbf@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 16:23:55 -0000 --BxzNiyccsRNpDIZo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Oct 09, 2018 at 02:50:33PM +0200, Alexandre Petrescu wrote: > >> As far as I remember, cellular ISPs carry GTP on IPv4 at the lowest la= yer. > > What they do in the underlay has no relevance. > It does have relevance to me, thank you. That might be, but this is not of relevance to us. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --BxzNiyccsRNpDIZo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlu+J5QACgkQ31bAZeTO f8WIAxAApPGdI8U7ELe5xwbs8D6bbP3wM14H4pl1QVI6bM5xZC3b9s51Y86XN3gc QqAn+1tcA6MtbUFMHImhqmlLMQjfTRKhOcEzVSjW0/1oKBvtPokoBNkBA19CMT7C A40zVMq9NZi5QMcSvsnkV1eKIBvpGxzSMXNdiJRv6ffIYxf3AnzZ2mwtqY/IFu8q 8ba7Y/3dsoMDSWSlvSCW5p+uMnx+xpG1aZUll0GT96/EGE2mLjHcATTrJafQZ49n OVJVVNC89N/DBVJfRh+3KGdd2PxqFqLlX7mpqUgBiuzvwW7g+ZxoXxnH8hxQ+Hu2 O46mAKkJvcGYoMzRkWdupb+XrLsdkG2sKY/OsW8gW4RZQH23tci6QJsSsw4DPKPt n1FPi6YQcdpa4eaoGvHBra2rDHSn0gaMJPnJUJmaNvU5QekkvKtK9LRinjT0+Zq/ 1sifN9NlahSZPLZNYXOzuJmBRYGwep/EI0i0IUEDD2jIKLJoKZIWUUZwulE6jYc2 jY+6+/4s8pcChG6sKyiwhbPJgbNVhpl2Wp6DCQBsJGxeq5eEmn8FS27/hMxcbCsf LF+t/gFhsdyl3W6gozn7azs+IhbATPkQvCHjcwzbaamnS1nQ74qrZglfC5QypvG8 MOtapO6HLXYB1ios5ISkkRLNNYMRaP1qN4gMek/pkAlkjVSOjq0= =CUCO -----END PGP SIGNATURE----- --BxzNiyccsRNpDIZo-- From nobody Wed Oct 10 11:33:03 2018 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 818BF130FAC for ; Wed, 10 Oct 2018 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcvLlOcLi3Pl for ; Wed, 10 Oct 2018 11:32:51 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17E112D7EA for ; Wed, 10 Oct 2018 11:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539196369; x=1539801169; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=fu0gwrQC CEXMh7OiIdQRdYwgWHPWlV7GYEMOm23kMu0=; b=RoOSnFXke5SK9z4DlQD/H23k cVsheje0VTcbjFrlm6raH4D2qymHTKjkNhpzHS6+nNImXHOFXX3MAyDFnDTntAuZ yGsJNb81wadDc08u8yVPUHZZFOCAgkE6BOi5Qqnm3nf54ClQUjpb6LmqSGp4WhmW 8TxjhVrff8VHH4jE5r4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 10 Oct 2018 20:32:49 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 10 Oct 2018 20:32:48 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005903508.msg for ; Wed, 10 Oct 2018 20:32:47 +0200 X-MDRemoteIP: 2001:470:1f09:495:cca4:18ed:69ee:7fb7 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 10 Oct 2018 20:32:47 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=182158bea4=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Wed, 10 Oct 2018 20:32:43 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> Thread-Topic: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt References: <153919621638.5900.18199747860735930931.idtracker@ietfa.amsl.com> In-Reply-To: <153919621638.5900.18199747860735930931.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:33:01 -0000 Hi all, We have worked in an integrated version of two documents: draft-v6ops-byrne-dnssecaaaa draft-palet-sunset4-ipv6-ready-dns-00 The new document is now: https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?incl= ude_text=3D1 Inputs welcome! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: mi=C3=A9rcoles, 10 de octubre de 2018, 20:30 Para: Jordi Palet , Jordi Palet Martinez , Cameron Byrne ,= Cameron Byrne Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-0= 0.txt =20 A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-bp-v6ops-ipv6-ready-dns-dnssec Revision: 00 Title: IPv6-Ready DNS/DNSSSEC Infrastructure Document date: 2018-10-10 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv= 6-ready-dns-dnssec-00.txt Status: https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-re= ady-dns-dnssec/ Htmlized: https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-d= ns-dnssec-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ip= v6-ready-dns-dnssec =20 =20 Abstract: This document defines the timing for implementing a worldwide IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the global IPv6-only deployment. =20 A key issue for this, is the need for a global support of DNSSEC and DNS64, which in some scenarios do not work well together. This document states that any DNSSEC signed resources records should include a native IPv6 resource record as the most complete and expedient path to solve any deployment conflict with DNS64 and DNSSE= C =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Oct 10 12:22:46 2018 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 E90A5124C04 for ; Wed, 10 Oct 2018 12:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYWUbKIDJnH6 for ; Wed, 10 Oct 2018 12:22:41 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7013124BE5 for ; Wed, 10 Oct 2018 12:22:40 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-42-18.kabelnet.hu [79.121.42.18]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w9AJMRLj023513 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 10 Oct 2018 21:22:34 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-18.kabelnet.hu [79.121.42.18] claimed to be [192.168.1.119] To: v6ops@ietf.org References: <153919621638.5900.18199747860735930931.idtracker@ietfa.amsl.com> <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <8964a130-8af7-f367-a951-37354cd6360b@hit.bme.hu> Date: Wed, 10 Oct 2018 21:22:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> Content-Type: multipart/alternative; boundary="------------C25DC0879C7CFF77DB4294D0" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.18; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 19:22:45 -0000 This is a multi-part message in MIME format. --------------C25DC0879C7CFF77DB4294D0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Jordi and Cameron, I have read the draft and I agree with the solution (to provide also a AAAA record if the zone is DNSSEC signed) as a "recommendation". However, I do not think that the timing described in Section 7 would be feasible. What do you mean under "MUST be suspended" in the following sentence? [...] If there is a failure at the deadline in complying with those requirements, the relevant NS, MUST be temporarily suspended until there is a subsequent successful verification. Who would suspend what? In my (admittedly incomplete) understanding  of the role of informational RFCs of the v6ops WG, they should provide guidance, and they may not command other bodies to do something. Please correct me if I am mistaken. Best regards, Gábor 10/10/2018 8:32 PM keltezéssel, JORDI PALET MARTINEZ írta: > Hi all, > > We have worked in an integrated version of two documents: > > draft-v6ops-byrne-dnssecaaaa > draft-palet-sunset4-ipv6-ready-dns-00 > > The new document is now: > > https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?include_text=1 > > Inputs welcome! > > Regards, > Jordi > > > > > -----Mensaje original----- > De: > Fecha: miércoles, 10 de octubre de 2018, 20:30 > Para: Jordi Palet , Jordi Palet Martinez , Cameron Byrne , Cameron Byrne > Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt > > > A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt > has been successfully submitted by Jordi Palet Martinez and posted to the > IETF repository. > > Name: draft-bp-v6ops-ipv6-ready-dns-dnssec > Revision: 00 > Title: IPv6-Ready DNS/DNSSSEC Infrastructure > Document date: 2018-10-10 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt > Status: https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/ > Htmlized: https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec > > > Abstract: > This document defines the timing for implementing a worldwide > IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the > global IPv6-only deployment. > > A key issue for this, is the need for a global support of DNSSEC and > DNS64, which in some scenarios do not work well together. This > document states that any DNSSEC signed resources records should > include a native IPv6 resource record as the most complete and > expedient path to solve any deployment conflict with DNS64 and DNSSEC > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > ********************************************** > 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 confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------C25DC0879C7CFF77DB4294D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Jordi and Cameron,

I have read the draft and I agree with the solution (to provide also a AAAA record if the zone is DNSSEC signed) as a "recommendation".

However, I do not think that the timing described in Section 7 would be feasible. What do you mean under "MUST be suspended" in the following sentence?

	[...] If there is a failure at the
   deadline in complying with those requirements, the relevant NS, MUST
   be temporarily suspended until there is a subsequent successful
   verification.

Who would suspend what?

In my (admittedly incomplete) understanding  of the role of informational RFCs of the v6ops WG, they should provide guidance, and they may not command other bodies to do something.

Please correct me if I am mistaken.

Best regards,

Gábor

10/10/2018 8:32 PM keltezéssel, JORDI PALET MARTINEZ írta:
Hi all,

We have worked in an integrated version of two documents:

draft-v6ops-byrne-dnssecaaaa
draft-palet-sunset4-ipv6-ready-dns-00

The new document is now:

https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?include_text=1

Inputs welcome!

Regards,
Jordi
 
 


-----Mensaje original-----
De: <internet-drafts@ietf.org>
Fecha: miércoles, 10 de octubre de 2018, 20:30
Para: Jordi Palet <jordi.palet@theipv6company.com>, Jordi Palet Martinez <jordi.palet@theipv6company.com>, Cameron Byrne <cameron.byrne@t-mobile.com>, Cameron Byrne <Cameron.Byrne@T-Mobile.com>
Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

    
    A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
    has been successfully submitted by Jordi Palet Martinez and posted to the
    IETF repository.
    
    Name:		draft-bp-v6ops-ipv6-ready-dns-dnssec
    Revision:	00
    Title:		IPv6-Ready DNS/DNSSSEC Infrastructure
    Document date:	2018-10-10
    Group:		Individual Submission
    Pages:		6
    URL:            https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/
    Htmlized:       https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec
    
    
    Abstract:
       This document defines the timing for implementing a worldwide
       IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
       global IPv6-only deployment.
    
       A key issue for this, is the need for a global support of DNSSEC and
       DNS64, which in some scenarios do not work well together.  This
       document states that any DNSSEC signed resources records should
       include a native IPv6 resource record as the most complete and
       expedient path to solve any deployment conflict with DNS64 and DNSSEC
    
                                                                                      
    
    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat
    
    



**********************************************
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 confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------C25DC0879C7CFF77DB4294D0-- From nobody Wed Oct 10 13:00:42 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2836C12777C; Wed, 10 Oct 2018 13:00:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153920164110.5875.2717329328092455687@ietfa.amsl.com> Date: Wed, 10 Oct 2018 13:00:41 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 20:00:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-03.txt Pages : 36 Date : 2018-10-10 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 10 13:04:45 2018 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 D17A0126BED for ; Wed, 10 Oct 2018 13:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1-93pnK1OPf for ; Wed, 10 Oct 2018 13:04:41 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E0E12777C for ; Wed, 10 Oct 2018 13:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539201879; x=1539806679; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=9UcdC1ez jRuywPlptlOOGuzT5zCjtJYeO5kmWc9gSpg=; b=k+raFTt/A9LZW16RF7IZj2Ph xVVZ9J5GwsjUYcL2Njd8geZEovYv74CgurGrcE6zYDm9v7Tcyu0v6Ll3K7DSOlNA mB0EAAalpnRGPFMjJYqF/zr0oT6XQ0m3TNsvttCbPAHl2kQl4HRyftnf1t56gLU/ cyT5YYECazKwMy0oN7w= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 10 Oct 2018 22:04:39 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 10 Oct 2018 22:04:39 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005903590.msg for ; Wed, 10 Oct 2018 22:04:38 +0200 X-MDRemoteIP: 2001:470:1f09:495:cca4:18ed:69ee:7fb7 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 10 Oct 2018 22:04:38 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=182158bea4=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Wed, 10 Oct 2018 22:04:33 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <8B700C39-39AA-4CFD-857D-628A68940A32@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-03.txt References: <153920164110.5875.2717329328092455687@ietfa.amsl.com> In-Reply-To: <153920164110.5875.2717329328092455687@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 20:04:44 -0000 Hi all, I just posted a new version of this document: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/?include= _text=3D1 As usual, inputs welcome ! Regads, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: mi=C3=A9rcoles, 10 de octubre de 2018, 22:01 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-03.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-03.txt Pages : 36 Date : 2018-10-10 =20 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv= 4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment= -03 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-deployment-0= 3 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Oct 10 21:20:42 2018 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 00833130E1A for ; Wed, 10 Oct 2018 21:20:41 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfeSBRScsrJV for ; Wed, 10 Oct 2018 21:20:39 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFCD130E18 for ; Wed, 10 Oct 2018 21:20:39 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id j23-v6so3710299pfi.4 for ; Wed, 10 Oct 2018 21:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IWruZrr80w7+xQth767e6VALAjRmF/LRHNN5UF0Rjcg=; b=TnfDV+7T2UzXQgXNpJlWmjmxBAlvblqbTI8NzCFbBoDvaXLElTixTOdH+aF+kpcE7d n066qKSXyCYSf1U7lzeHluJgTGXi7Vzt2VAJU1ANvf4K7u6h49HdkV2Sv9c1p33Bw+/H 9hBZU3Kc60wt3xDYzlVyN1v4qd/8t7DNgcd9XxO/BSh6whMu6cIacadwhTB4runm59F4 59boMADYpTQqaR4fy+OjwfTa3YF0U4R7xK4QsvJ4Iz/xj3CRR1dlH4gExTv+GQ1edNc6 HwsRITGec3JYEHNGfqNztHqSL5YMFstyNHo+RBe5Bo7ndec6SMaDAkPVJCfUKRUxG9gn 3GyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IWruZrr80w7+xQth767e6VALAjRmF/LRHNN5UF0Rjcg=; b=mcZBjnmHtr45nkb1+WInCCc9ZDBL462e2tlIflyRzN4pQSu6XTTxT1jlUXvKpUzlOj FksFV5nGAWADWvL74/ZuqwtT6a0jB7R2U1me+ogNzOoOFiEel7Jt5dayfG0hnaWLnZ+m 3i/frqIcAqeaZta/Y4q54SC7EsyVUogjiu+vLFcIfbcVUKaWmXPS4PKPGO1WrglBKF90 b8QT9bsRgY+A9lC3uRbPoyECSw9IaCv2627qA366HSrk6MW5EojtkzySLVaN8RBKhj/n jAClkp0vzmkWWmx6DMINYP34pWG5Ay1BMDm5l/UW0u+4VKDTlczYobBEqJf5lUNjXrSJ 0aww== X-Gm-Message-State: ABuFfoilj3t889qM3kBbKvUcsEi3p+zZdttncb0uBGiY0yhVa8eoZ8/F LHdPxX/g8ZZf8Aphn8HhmLQ= X-Google-Smtp-Source: ACcGV61zIa57VdlxtuCVCk6OcV7EnOwOf7ELkdLipFzQu+I/1O0T2Ln0ajGKw7fU4AYC3fRqVMwqQQ== X-Received: by 2002:a63:b04f:: with SMTP id z15-v6mr30605213pgo.442.1539231638392; Wed, 10 Oct 2018 21:20:38 -0700 (PDT) Received: from [172.20.10.4] (pw126233131189.20.panda-world.ne.jp. [126.233.131.189]) by smtp.gmail.com with ESMTPSA id l16-v6sm38819322pfb.75.2018.10.10.21.20.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 21:20:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Satoru Matsushima In-Reply-To: <0B314164-D3A7-4C22-A648-B3332EFA8F3E@consulintel.es> Date: Thu, 11 Oct 2018 13:20:31 +0900 Cc: Mikael Abrahamsson , Alexandre Petrescu , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2CB9F19E-DF4D-435A-B7DA-16778F6597A2@gmail.com> References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> <0B314164-D3A7-4C22-A648-B3332EFA8F3E@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 04:20:41 -0000 Hmm=E2=80=A6 I don=E2=80=99t know if it is a hidden fact but millions of MAP-E CPEs = are deployed and in operation here in our country while no 464xlat = deployment even in the cellular operators who adopt v4v6 PDN with NAT44 = CGN afaik. What a diversity in earth. Cheers, --satoru > 2018/10/09 20:25=E3=80=81JORDI PALET MARTINEZ = =E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB: >=20 > Add to that some lw4o6 deployments, a few MAP-E/T and many 464XLAT = ones (which are actually the bigger ones if we include the cellular = networks). >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Mikael Abrahamsson = > Organizaci=C3=B3n: People's Front Against WWW > Fecha: martes, 9 de octubre de 2018, 13:17 > Para: Alexandre Petrescu > CC: > Asunto: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition = Technologies for IPv4aaS" -- Fwd: New Version Notification for = draft-lmhp-v6ops-transition-comparison-00.txt >=20 > On Tue, 9 Oct 2018, Alexandre Petrescu wrote: >=20 >> Is it common to have IPv6 only in the access network? >=20 > DOCSIS and ds.lite has millions of customers deployed, so yes. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 11 05:12:44 2018 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 B7245130E58 for ; Thu, 11 Oct 2018 05:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mraopQrG9R3l for ; Thu, 11 Oct 2018 05:12:40 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C91130E5A for ; Thu, 11 Oct 2018 05:12:39 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id 189-v6so8754275wmw.2 for ; Thu, 11 Oct 2018 05:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5JIOdZCjgGOHVPEerpt1YSXFYVLGVcWMCqNFKyXAW4Y=; b=j4fHRVGnok56Qm88QTZwLSrfrbpl9BeCU+L+vC+KDE3cOthCqK9Ua/aRrRM4CiytUU Z7mN35lhJn4DO/q1ElSuKYrnrg1Yh/jz1ds1bBoM92VX272tudA9b6MlNJof0CY/xRvP Vjs7PcTHUxzadWccxKAsHRkp/KVB0FSlOC6fv+8GrCrr/Pqd9PwyNwTuyg8RpHfN2JTn ecnnd7ofHvEk8iKblezdvXzVDBP4ouIc0RJOK09wpoky9WkMXdH35kIojTWxZsLmqySz YU4jmIEr+dPn+gWJEIcILHviSbgj57pqkYcmShyCR+L/WajL5B3BoAPl9ZTbAQGt8EOz m3mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5JIOdZCjgGOHVPEerpt1YSXFYVLGVcWMCqNFKyXAW4Y=; b=gRvPb5wttEHM/jYouDGkOiLCnMSPZiwEJkbrCedDFJSMUGArkjpCfHunDHasShH+TL k3M3DIgbzlRpGJTPJC4CfyR0b83tlaLOCSSX9HeNAAnff4Qoe032rmI+Uq5ofonJ01E4 iNpdU2a0TKUJPfnEGuS/mWAmdCY1kIJ2NLaQLJd6zTCqcijbrHT4l2tHcEZ6U2ypHb7a BFc3EGbwRtdlv/WZ6wqCdT5PCRX3q+VAkiLP/8gyr+3kdiini7kutHxa1y8IE2smnrli 5nDNA2r+eK5nCby8RBlpUiV21wmmzRrwzXudtWlT7nNeJXJbE3xcLZAuqi/ka2rV8bik o1bg== X-Gm-Message-State: ABuFfoivT1h25jcJs0xz/iJn2FKJTRhoMYyXQYONVDtz6KEAOrNW7LQP DS5mUTN7SSeYCziGGyq1jrLInv84lTC2cRz29/4= X-Google-Smtp-Source: ACcGV62BbttW68Cfog96KBZFaGchieMmpIAhxSo7UfN7Zuf2CV3GVg07jQpo9EEee2Mxzci9l6PY+bbEFDS4AwJuj4w= X-Received: by 2002:a1c:d4b:: with SMTP id 72-v6mr1603570wmn.102.1539259957704; Thu, 11 Oct 2018 05:12:37 -0700 (PDT) MIME-Version: 1.0 References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> <0B314164-D3A7-4C22-A648-B3332EFA8F3E@consulintel.es> <2CB9F19E-DF4D-435A-B7DA-16778F6597A2@gmail.com> In-Reply-To: <2CB9F19E-DF4D-435A-B7DA-16778F6597A2@gmail.com> From: Ca By Date: Thu, 11 Oct 2018 05:12:26 -0700 Message-ID: To: Satoru Matsushima Cc: JORDI PALET MARTINEZ , v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000fefba00577f2e254" Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 12:12:42 -0000 --000000000000fefba00577f2e254 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 10, 2018 at 9:21 PM Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hmm=E2=80=A6 > > I don=E2=80=99t know if it is a hidden fact but millions of MAP-E CPEs ar= e > deployed and in operation here in our country while no 464xlat deployment > even in the cellular operators who adopt v4v6 PDN with NAT44 CGN afaik. > What a diversity in earth. > Can you please help us understand? Which network deployed map-e? Is it rfc compliant? When and at what scale ? How many customers, roughly , are on mape? Any lessons learned from deployment? Thanks, CB > > Cheers, > --satoru > > > 2018/10/09 20:25=E3=80=81JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > > > Add to that some lw4o6 deployments, a few MAP-E/T and many 464XLAT ones > (which are actually the bigger ones if we include the cellular networks). > > > > Regards, > > Jordi > > > > > > > > =EF=BB=BF-----Mensaje original----- > > De: v6ops en nombre de Mikael Abrahamsson < > swmike@swm.pp.se> > > Organizaci=C3=B3n: People's Front Against WWW > > Fecha: martes, 9 de octubre de 2018, 13:17 > > Para: Alexandre Petrescu > > CC: > > Asunto: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition > Technologies for IPv4aaS" -- Fwd: New Version Notification for > draft-lmhp-v6ops-transition-comparison-00.txt > > > > On Tue, 9 Oct 2018, Alexandre Petrescu wrote: > > > >> Is it common to have IPv6 only in the access network? > > > > DOCSIS and ds.lite has millions of customers deployed, so yes. > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > 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 > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > > > _______________________________________________ > > 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 > --000000000000fefba00577f2e254 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed,= Oct 10, 2018 at 9:21 PM Satoru Matsushima <satoru.matsushima@gmail.com> wrote:
Hmm=E2=80=A6

I don=E2=80=99t know if it is a hidden fact but millions of MAP-E CPEs are = deployed and in operation here in our country while no 464xlat deployment e= ven in the cellular operators who adopt v4v6 PDN with NAT44 CGN afaik. What= a diversity in earth.


Can you please help us understand?

<= /div>
Which network deployed map-e? Is it rfc compliant?= =C2=A0 When and at what scale ? How many customers, roughly , are on mape?= =C2=A0 Any lessons learned from deployment?


Thanks,
CB

Cheers,
--satoru

> 2018/10/09 20:25=E3=80=81JORDI PALET MARTINEZ <jordi.palet=3D40consulinte= l.es@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
>
> Add to that some lw4o6 deployments, a few MAP-E/T and many 464XLAT one= s (which are actually the bigger ones if we include the cellular networks).=
>
> Regards,
> Jordi
>
>
>
> =EF=BB=BF-----Mensaje original-----
> De: v6ops <v6ops-bounces@ietf.org> en nombre de Mikael Abrahamsson <swmike@swm.pp.se><= br> > Organizaci=C3=B3n: People's Front Against WWW
> Fecha: martes, 9 de octubre de 2018, 13:17
> Para: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> CC: <v6ops@ietf= .org>
> Asunto: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Te= chnologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmh= p-v6ops-transition-comparison-00.txt
>
>=C2=A0 =C2=A0 On Tue, 9 Oct 2018, Alexandre Petrescu wrote:
>
>> Is it common to have IPv6 only in the access network?
>
>=C2=A0 =C2=A0 DOCSIS and ds.lite has millions of customers deployed, so= yes.
>
>=C2=A0 =C2=A0 --
>=C2=A0 =C2=A0 Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
>
>=C2=A0 =C2=A0 _______________________________________________
>=C2=A0 =C2=A0 v6ops mailing list
>=C2=A0 =C2=A0 v6ops= @ietf.org
>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v= 6ops
>
>
>
>
> **********************************************
> 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 o= r confidential. The information is intended to be for the exclusive use of = the individual(s) named above and further non-explicilty authorized disclos= ure, copying, distribution or use of the contents of this information, even= if partially, including attached files, is strictly prohibited and will be= considered a criminal offense. If you are not the intended recipient be aw= are that any disclosure, copying, distribution or use of the contents of th= is information, even if partially, including attached files, is strictly pr= ohibited, will be considered a criminal offense, so you must reply to the o= riginal sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> 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
--000000000000fefba00577f2e254-- From nobody Thu Oct 11 11:25:10 2018 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 E635E130F0E for ; Thu, 11 Oct 2018 11:25:01 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1mRY8Mb8l-S for ; Thu, 11 Oct 2018 11:24:59 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C4D130F04 for ; Thu, 11 Oct 2018 11:24:59 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id 134-v6so14983686itz.2 for ; Thu, 11 Oct 2018 11:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ifbjz5g3FQq3BYg4+A3sPSxccar/qkeokssFEEDcz/Q=; b=J/oxfi3pCFZTv8FT4IsHRwUbCZByE1Pv2bgZ/PmZ87FE5lflWqP9ouTuK12lHC9IJZ bXBFx/X3XEEhc4Jp4UM//1oiFNvceBcTaNXLjDaohH2EWPYtCvXLPndOSMCx+YZD1QkV G0eTiofCPPYYbWGHt21WgqfOscTUd3uQDozKgVJLX3yMS1yN2ldaEMmDRm6aXJHWJt+R CImGnu1K8ouNOQhewHY0sdaX1+fTmnIPWoNCnMPnN5WQWp6YFgUGM3fhBRNo8wunNgiS CJ6tYyRdDQ+8kXt38B8aacGlfKDNDz6KLj+3akYpxNbFx8OCCB9TW6U1HrU94MeU0hqv oy2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ifbjz5g3FQq3BYg4+A3sPSxccar/qkeokssFEEDcz/Q=; b=hh5GRTHwtc4Thtwg9UkkTePi3r9hXlAoQR2vXy0m3xFZegs+PBeTK4A6kBIPcNw1lM hb3QxOBdxeA8jZuY2FNj98Zfey5l/vJTf38mEDy/2fI7GhMQXN1M/xjat3eiFCvSZDpQ evU+dw0Dt2PMyVqFPnNc1m2cKjCvSWxHzoxyM3ad3yrpnkwN3LXkhJX2wtUp19NARFQe eZekx0vJ9L0+WZJwb2nBY6xHAbS0l0XcffYi3cr5lXtpf6vxWj4e0DGV6a4mChABbTa8 tGJBsbjc37ywnHBV76jD6NuelGKSaBAdLVLzwJiZbAIgyiMvsTr62CDBFEG/3lptkAOg z/Yw== X-Gm-Message-State: ABuFfojY0C0gy9P6/ZNmvRUTeuNzEVe0ThmDeVk9Jc05J5EGfU8Gt2pG iUrDs8+S7SV9Nu5KqNe9g35LAxx0 X-Google-Smtp-Source: ACcGV60chiytQquHz+DI4Zl7fS/xuMduSRPb+1FA3Jtb8lHLZeu4uIqYR5csxh3yX4Ayy0tRfypp2A== X-Received: by 2002:a05:660c:b03:: with SMTP id f3mr2284110itk.60.1539282298283; Thu, 11 Oct 2018 11:24:58 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::100e? ([2600:8802:5600:1546::100e]) by smtp.gmail.com with ESMTPSA id x21-v6sm10548185ita.6.2018.10.11.11.24.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 11:24:57 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_781D6273-17CC-49A4-9312-7E8B8531A6F7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 11:24:53 -0700 In-Reply-To: Cc: Satoru Matsushima , "v6ops@ietf.org list" , JORDI PALET MARTINEZ To: Ca By References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu> <344c4981-0164-8a77-bb83-c35d7d665f2e@gmail.com> <0B314164-D3A7-4C22-A648-B3332EFA8F3E@consulintel.es> <2CB9F19E-DF4D-435A-B7DA-16778F6597A2@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 18:25:08 -0000 --Apple-Mail=_781D6273-17CC-49A4-9312-7E8B8531A6F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 11, 2018, at 5:12 AM, Ca By wrote: >=20 > Which network deployed map-e? Is it rfc compliant? When and at what = scale ? How many customers, roughly , are on mape? Any lessons learned = from deployment? For the record, Akira Kato told v6ops about this a while back: https://tools.ietf.org/html/draft-akira-v6ops-mape-experience https://www.ietf.org/proceedings/92/slides/slides-92-v6ops-2.pdf = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_781D6273-17CC-49A4-9312-7E8B8531A6F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlu/lXYACgkQEhdRnd2G P+AoXg//WFO4ozNyJJYbrfEP8+j3jMT3AZxATkJFGM5edZuL61VmnBS8TADD1zUN A/lSxkDnabllGbZfFrZUzetMdLatekSQPXe/LyJNcXIqXF32dCZg3yU3rS3mhYoy cQoIi6HTfm1R0NtMNbhnKtFInsAoJiFNprQuQocX4CnkXpmlaLvaOPexM5B20Zhz 6Uvef5RKxR4fr19R5lt87/oRu+dcZJ6UaWdcM3dyLmU9Bgyb5Azvwr8MM6jzHIpz 90Z25Zejbx44BZRys+VPsdj4YtEmfN5NWou/6T+asL/j/CKEMjnHSbFur+pyI6zd 8FvLo+o0tFce8fiW6DU0O90BxMSVliMCi2O31efdMI6zX+JskctNmzhqNUvmhR+4 EQCsDudOReFbs925wNMTKtxfp68D6w510MwWqc4Rg8QTLRvdO0RuhQAHOvG97+Oe Q/CQx3cSsAuPCf1mWCPn56XkSgFlYq2L9Hyt0LecspIqatnXIaT1nErUtdZxwTtc BpdtyXseJtOiXDE76dHXYfi6Zt8vdIiX3egMb5R5eRt53PQhAm2NhAITYyEm1mov UDh8JzFGd4ZNq7+jbkbroiq500qGU6cHX3ahWzv+I4zCEMDkajKTNCUMuiYuzfxr TZwpE7PxsPEx0qDIYsWfToUMu8GrMfubRT8TxSLdG61MEQa2vq4= =k3W2 -----END PGP SIGNATURE----- --Apple-Mail=_781D6273-17CC-49A4-9312-7E8B8531A6F7-- From nobody Thu Oct 11 12:35:57 2018 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 71609130DE7 for ; Thu, 11 Oct 2018 12:35:55 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRo2xA-pjy-g for ; Thu, 11 Oct 2018 12:35:53 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC66124D68 for ; Thu, 11 Oct 2018 12:35:53 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id n18-v6so7499884ioa.9 for ; Thu, 11 Oct 2018 12:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=A+XGKtqk75oE8T+o/ayrarCF62rZ/GblRha8WN+9zK0=; b=mJNiv9CLf6UdbwLVbAX22RpzkNro8aXIXR07RVpApeevp3cAeOj+0qJAB82Zx6SYO9 22KycY5L4Brfpi/G4NP0dDWXgTMD86+25MSjnShtIYIsnnhP4wfWFBYOoGg0MB60e8xQ bOdBNs5ICdUjD2CLMq0RL9xyFY0VWUIRxwNwaN1grqyXkk12gTYOcpjN284tDCwYn5Mm EnJ7r7wHTgWZ9o1T1gHJaKOIFKpJaBjb2wrGsnlzX77PmI5DNvozN80l7rQw2zmt20O1 IP//jrDZ4a3E4FQJJ8ByDt1RNm9/F1i4dov4qnI8peooVj67QX5hJZAMjp0+o0jwJ9l1 WVEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=A+XGKtqk75oE8T+o/ayrarCF62rZ/GblRha8WN+9zK0=; b=hILJcMywl+9rJ6NKjjZA68t/OC1l1CxG24IqpIewJm4ohhgd2MimnKZ7IoK7T4D+ys fBQbr+vtSZr21YxGGa18+UAsRarhfYafp7RcqvbqXZK20R9M18Vh2AEomwTFKedp6fH0 tKQuTYIEebte1kzv5P8ny4gqIVLzYmeDq4TvnQebEgAS9xQcObiK1LR1ZTjjr+PKahqD jUHTBS6zr4MU/ANKVkuvLMm1iJG4Nleg3OSsX2CWrCmaEraVFONi0rKrV0TI05QCNVOA WEPVVHzYm32GNOno45T0gRpfdO9pL6bQIYxrPXPyPaQhvjRfm5HG/DI5WXE6DLVYxduX HgGA== X-Gm-Message-State: ABuFfogPURuSYShJSOsgTpvUbzPw+cHQjOvCKgLXEZLrg86sj7LKTP5Q KRQ836gGyfw61TCQv9FWfi3BmE8C X-Google-Smtp-Source: ACcGV60gH1QIZ4shNkBtwCf9QNoBLsFnbVzRMi7FlAv5EpI4ofq4kkEU7ObiAAKce/dutsB7u0d+UA== X-Received: by 2002:a6b:1b08:: with SMTP id b8-v6mr1020540iob.199.1539286552256; Thu, 11 Oct 2018 12:35:52 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::100e? ([2600:8802:5600:1546::100e]) by smtp.gmail.com with ESMTPSA id h7-v6sm7784340iop.65.2018.10.11.12.35.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 12:35:51 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_7B4AE2B7-6B70-435B-B716-016175EC3D04"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <09BE3517-E67F-415F-960C-1C0B37B11558@gmail.com> Date: Thu, 11 Oct 2018 12:35:49 -0700 To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] IPv6 Operations at IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 19:35:56 -0000 --Apple-Mail=_7B4AE2B7-6B70-435B-B716-016175EC3D04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have posted a preliminary agenda at = https://datatracker.ietf.org/meeting/103/materials/agenda-103-v6ops-00.htm= l. Per https://datatracker.ietf.org/meeting/important-dates/, the draft = cutoff is 10/22, and the preliminary agenda deadline is 10/24. It is = possible that drafts will be posted that have traction on the mailing = list and the agenda will need to be updated. However, as things stand, = this represents what Ron and I think we need to discuss f2f. Very interested to see drafts posted and discussion of them over the = next two weeks. --Apple-Mail=_7B4AE2B7-6B70-435B-B716-016175EC3D04 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlu/phYACgkQEhdRnd2G P+CnpRAAwxL/Sfw6V84C0ER+yQeXi/YG4q26VYzOXXB2elJm1mvOoQt5wlsp85Nc 6S2ktCkFWnGlZs+3iE0Y8nRM6q+ojdFXQSkX1THu2+vR+D13Z+PRSeJD3RNtsUoK 2G2h9aC3Qm/E7/arLJ3MFiOZyVcDNM5ggZT+kfab54Z5R1hj3wOXwEQ7OVLibByo 7oyO71ir2dnIoYxgSajZ98nkIxUGbCsP2xm6fYP4R6Ou7f5HIthZpuGT1I/VJ2ei Tn3x9TWxdZgdCmSqcXyFPJI7GfLE3DQlFZ9orKY+USwJVBouz/jvCjzbD6F6von+ /mNC9wsEQExf1XhugowjAtyE1tGUElOq0Exx8egm1QUYcju4Zn7opQ2PeMnHD68Y 4mOd6iwo3C3/J3Np9wBXjfnjt1TUCMMiqR/EYPHS15Y58oZ6+TlvyblKnBskb803 SnrRvmX4AxHtTF9v6Efo1Jss8bEin1kEotMIkwF4fUNIbylfE3e/6pjmBytkBANp GErh5mGBAaMf9P8htRnajdxUbgI0tgvgUNvzSQhck6iryddxIWldKOAlRhdZ1HU9 HJcIwxKImw/jp6Mp93J5iG1qj17OYg6Nr+TyetzDUp6ny6fJDAzHFEa2zyALbVCF 2gH2JiMAZ/X3P95y6GZPpu3AHL32ZjLhqwiZiN9hdjAyixNSGrI= =39Yp -----END PGP SIGNATURE----- --Apple-Mail=_7B4AE2B7-6B70-435B-B716-016175EC3D04-- From nobody Thu Oct 11 13:27:48 2018 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 206811277CC for ; Thu, 11 Oct 2018 13:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8mIbs826s4n for ; Thu, 11 Oct 2018 13:27:42 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5A012785F for ; Thu, 11 Oct 2018 13:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539289659; x=1539894459; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=WTROX6dNSHQ94DtCobO1y7isEV1dbMt8he jsiivj9W8=; b=Pak7SBx5yF9+NQ1XwcRTcjF8Fk01ZWY0Q9YKCusTbwfm67uRFv i6rR4TxuBYyMD3A95J6Cb1Z3mdod+42z7wXHlD68v1cAwZk61YeEjcL0h/eZ9aNB lO6zf2qnNluCIHqgDQshS5/AwLnw8uU5UcCzYazOKN1s8OScYw0wdpg80= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 11 Oct 2018 22:27:39 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 11 Oct 2018 22:27:38 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005905012.msg for ; Thu, 11 Oct 2018 22:27:36 +0200 X-MDRemoteIP: 2001:470:1f09:495:6c49:5255:2f56:6044 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 11 Oct 2018 22:27:36 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=18221238b2=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Thu, 11 Oct 2018 22:27:34 +0200 From: JORDI PALET MARTINEZ To: Lencse =?UTF-8?B?R8OhYm9y?= , Message-ID: <2FD71D40-8D94-40A4-9206-1FE3692C65EA@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt References: <153919621638.5900.18199747860735930931.idtracker@ietfa.amsl.com> <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> <8964a130-8af7-f367-a951-37354cd6360b@hit.bme.hu> In-Reply-To: <8964a130-8af7-f367-a951-37354cd6360b@hit.bme.hu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3622141654_1906975318" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 20:27:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3622141654_1906975318 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Gabor, =20 I see this draft more than a recommendation (despite the wording and the ty= pe of document), which can be changed along the progress in this WG or even= other levels, as a call for one more IANA/ICANN action. =20 They mandate the support of IPv6 in the contracts with the gTLDs, etc., but= is not always being followed. =20 In addition to ensure that that is followed sometime soon, why not make sur= e that the same conditions are in place for any NS and so on for any kind o= f RRs ? =20 I see the IETF as responsible for taking actions, as we are the =E2=80=9Cpr= otocol owners=E2=80=9D and that means something. We have liaisons also with= all the related organizations, to make this work and have a shorter period= of =E2=80=9Cpain=E2=80=9D (yes transition is not perfect, so will be bette= r to speed it up now that is feasible, just look at the success of IPv6 in = cellular networks and other big broadband networks) for the complete world = population. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: mi=C3=A9rcoles, 10 de octubre de 2018, 21:23 Para: Asunto: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-= dns-dnssec-00.txt =20 Dear Jordi and Cameron, I have read the draft and I agree with the solution (to provide also a AAAA= record if the zone is DNSSEC signed) as a "recommendation".=20 However, I do not think that the timing described in Section 7 would be fea= sible. What do you mean under "MUST be suspended" in the following sentence= ? =C2=A0 [...] If there is a failure at the =C2=A0=C2=A0 deadline in complying with those requirements, the relevant NS= , MUST =C2=A0=C2=A0 be temporarily suspended until there is a subsequent successfu= l =C2=A0=C2=A0 verification. Who would suspend what? In my (admittedly incomplete) understanding of the role of informational R= FCs of the v6ops WG, they should provide guidance, and they may not command= other bodies to do something. Please correct me if I am mistaken. Best regards, G=C3=A1bor 10/10/2018 8:32 PM keltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta: Hi all, =20 We have worked in an integrated version of two documents: =20 draft-v6ops-byrne-dnssecaaaa draft-palet-sunset4-ipv6-ready-dns-00 =20 The new document is now: =20 https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?incl= ude_text=3D1 =20 Inputs welcome! =20 Regards, Jordi =20 =C2=A0 =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: mi=C3=A9rcoles, 10 de octubre de 2018, 20:30 Para: Jordi Palet , Jordi Palet Martinez , Cameron Byrne ,= Cameron Byrne Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-0= 0.txt =20 =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0A new version of I-D, draft-bp-v6ops-ipv6-ready-dns= -dnssec-00.txt =C2=A0=C2=A0=C2=A0 has been successfully submitted by Jordi Palet Martinez = and posted to the =C2=A0=C2=A0=C2=A0 IETF repository. =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 draft-bp-v6ops-ipv6-ready-dns-dnssec =C2=A0=C2=A0=C2=A0 Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00 =C2=A0=C2=A0=C2=A0 Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= Pv6-Ready DNS/DNSSSEC Infrastructure =C2=A0=C2=A0=C2=A0 Document date: 2018-10-10 =C2=A0=C2=A0=C2=A0 Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= ndividual Submission =C2=A0=C2=A0=C2=A0 Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6 =C2=A0=C2=A0=C2=A0 URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv6-re= ady-dns-dnssec-00.txt =C2=A0=C2=A0=C2=A0 Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/ =C2=A0=C2=A0=C2=A0 Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://to= ols.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00 =C2=A0=C2=A0=C2=A0 Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://da= tatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Abstract: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document defines the timing for i= mplementing a worldwide =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IPv6-Ready DNS and DNSSEC infrastructu= re, in order to facilitate the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 global IPv6-only deployment. =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A key issue for this, is the need= for a global support of DNSSEC and =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DNS64, which in some scenarios do not = work well together.=C2=A0 This =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document states that any DNSSEC signed= resources records should =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 include a native IPv6 resource record = as the most complete and =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expedient path to solve any deployment= conflict with DNS64 and DNSSEC =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Please note that it may take a couple of minutes fr= om the time of submission =C2=A0=C2=A0=C2=A0 until the htmlized version and diff are available at too= ls.ietf.org. =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0The IETF Secretariat =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3622141654_1906975318 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Gabor,

 

=

I see this draft more than a recommendation (despite the wording and the = type of document), which can be changed along the progress in this WG or ev= en other levels, as a call for one more IANA/ICANN action.

 

They mandate the support of IPv6 in th= e contracts with the gTLDs, etc., but is not always being followed.

 

In addition to ensure that th= at is followed sometime soon, why not make sure that the same conditions ar= e in place for any NS and so on for any kind of RRs ?

=

 

I see the IETF as responsible for taking ac= tions, as we are the =E2=80=9Cprotocol owners=E2=80=9D and that means somet= hing. We have liaisons also with all the related organizations, to make thi= s work and have a shorter period of =E2=80=9Cpain=E2=80=9D (yes transition = is not perfect, so will be better to speed it up now that is feasible, just= look at the success of IPv6 in cellular networks and other big broadband n= etworks) for the complete world population.

<= br>Regar= ds,

Jordi

 

&n= bsp;

 

De: v6ops= <v6ops-bounces@ietf.org> en nombre de Lencse G=C3=A1bor <lencse@h= it.bme.hu>
Fecha: mi=C3=A9rcoles, 10 de octubre de 2018, 21:23=
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] New V= ersion Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

=  

Dear Jordi a= nd Cameron,

I have read the draft and I agree with the solution (to = provide also a AAAA record if the zone is DNSSEC signed) as a "recomme= ndation".

However, I do not think that the timing described in= Section 7 would be feasible. What do you mean under "MUST be suspende= d" in the following sentence?

=C2=A0 [...] If there is a failure at the
=C2=A0=C2=A0 deadline in complying with those requ=
irements, the relevant NS, MUST
=C2=A0=C2=A0 be temporarily suspended until there is a subsequent su=
ccessful
=C2=A0=C2=A0 ver=
ification.


Who would susp= end what?

In my (admittedly incomplete) understanding  of the r= ole of informational RFCs of the v6ops WG, they should provide guidance, an= d they may not command other bodies to do something.

Please correct = me if I am mistaken.

Best regards,

G=C3=A1bor

<= div>

10/10/2018 8:32 PM ke= ltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta:

Hi all,
&=
nbsp;
We have worked in an int=
egrated version of two documents:
 
draft-v6o=
ps-byrne-dnssecaaaa
draft=
-palet-sunset4-ipv6-ready-dns-00
 
The new do=
cument is now:
 =
;
htt=
ps://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?include=
_text=3D1
 =

Inputs welcome!
 
Regards,
Jordi
 
=C2=A0
 
=
 
=EF=BB=BF-----Mens=
aje original-----
De: <internet-drafts@ietf.org>
Fecha: mi=C3=A9rcoles,=
 10 de octubre de 2018, 20:30
Para: Jordi Palet &l=
t;jordi.palet@theipv6company.com>, Jordi Palet Martinez <jordi.palet@theipv6company.com>=
;, Cameron Byrne <came=
ron.byrne@t-mobile.com>, Cameron Byrne <Cameron.Byrne@T-Mobile.com>
Asunto: New Version Notification for draft-b=
p-v6ops-ipv6-ready-dns-dnssec-00.txt
 
=C2=A0=
=C2=A0=C2=A0 
=C2=A0=C2=
=A0=C2=A0=C2=A0A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-0=
0.txt
=C2=A0=C2=A0=C2=A0 =
has been successfully submitted by Jordi Palet Martinez and posted to the
=C2=A0=C2=A0=C2=A0 IETF re=
pository.
=C2=A0=C2=A0=C2=
=A0 
=C2=A0=C2=A0=C2=A0=
=C2=A0Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-bp-=
v6ops-ipv6-ready-dns-dnssec
=C2=A0=C2=A0=C2=A0 Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00=

=C2=A0=C2=A0=C2=A0 Title:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IPv6-Ready DNS/DNSSSEC Infrastructu=
re
=C2=A0=C2=A0=C2=A0 Doc=
ument date: 2018-10-10
=
=C2=A0=C2=A0=C2=A0 Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I=
ndividual Submission
=C2=
=A0=C2=A0=C2=A0 Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6
=C2=A0=C2=A0=C2=A0 URL:=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
=C2=
=A0=C2=A0=C2=A0 Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/=

=C2=A0=C2=A0=C2=A0 H=
tmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/ht=
ml/draft-bp-v6ops-ipv6-ready-dns-dnssec-00
=C2=A0=C2=A0=C2=A0 Htmlized:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/draft-bp-=
v6ops-ipv6-ready-dns-dnssec
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0Abstract:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document defines the t=
iming for implementing a worldwide
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IPv6-Ready DNS and DNSSEC in=
frastructure, in order to facilitate the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 global IPv6-only deplo=
yment.
=C2=A0=C2=A0=C2=A0=
 
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0A key issue for this, is the need for a global support=
 of DNSSEC and
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 DNS64, which in some scenarios do not work well=
 together.=C2=A0 This
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document states that any DNSSEC signed re=
sources records should
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 include a native IPv6 resource record =
as the most complete and
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expedient path to solve any deployment=
 conflict with DNS64 and DNSSEC
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<=
/o:p>
=C2=A0=C2=A0=C2=A0=C2=A0<=
/o:p>
=C2=A0=C2=A0=C2=A0=C2=A0<=
/o:p>
=C2=A0=C2=A0=C2=A0=C2=A0Please=
 note that it may take a couple of minutes from the time of submission=

=C2=A0=C2=A0=C2=A0 until the =
htmlized version and diff are available at tools.ietf.org.
=

=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0The IETF Secretariat
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0
 
 
 
**********=
************************************
IPv4 is over
=
Are you ready for the new Internet ?
http://www.consulintel.es=

The IPv6 Company
 
This electronic message contains information w=
hich may be privileged or confidential. The information is intended to be f=
or the exclusive use of the individual(s) named above and further non-expli=
cilty authorized disclosure, copying, distribution or use of the contents o=
f this information, even if partially, including attached files, is strictl=
y prohibited and will be considered a criminal offense. If you are not the =
intended recipient be aware that any disclosure, copying, distribution or u=
se of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so=
 you must reply to the original sender to inform about this communication a=
nd delete it.
 =

 
 
_______________________________________________
<=
pre style=3D'margin-left:35.4pt'>v6ops mailing list
v6ops@ietf.org=

https://www.ietf.org/mailman/listinfo/v=
6ops
 


_= ______________________________________________ v6ops mailing list v6ops@iet= f.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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3622141654_1906975318-- From nobody Fri Oct 12 12:11:08 2018 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 9B9E4130E82 for ; Fri, 12 Oct 2018 12:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml0GGMgEG0sg for ; Fri, 12 Oct 2018 12:11:01 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD831200D7 for ; Fri, 12 Oct 2018 12:11:01 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id w16-v6so9990446iom.7 for ; Fri, 12 Oct 2018 12:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=86wj0OuAin+kRl/9BNFMIkM5DUmpDbcRoaSWBiDjmrM=; b=AmWnurfJ7xcYzfum7Qv2iGeb9c7FOuUKliYf0rxyTZIWj7TNsMMGWos3QaXAwVVvfZ 9d9YkhDyeKQ7aesDdqm8We0aaJ9Xv1rwji4Urprawu2SSxT4H/bmwiZhMD416fyOOcKL OKPQ8toYpUOGzW9gRmd55L0Gz/Z2sTSO2/5eT+Q8AJSm4JcyXvuokGQlZtRvDRZBlH6I U2aHFKWXLoyQX8RJ58lcip4z3henvCV2KJsVJ27SUwjtX1g3m4FsK/lR7TMjEKAu7geJ T91aKa1BG3v6ikTU1cTqXskdapHudK++fkRcdpnWF2uOAW91m++m32ySnhwoFvql55KX EGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=86wj0OuAin+kRl/9BNFMIkM5DUmpDbcRoaSWBiDjmrM=; b=lnAqOe3ZEpzNFZlk6xVL5sJMrmmDfcITPpY8edgYGuaBPzmvsyaOz7xh9U7ubwi88L 3tpl8mOLP7WKonz5IfU8CDdRJ3ZtPiYwG/BM3e0Wa1NnJGy5zxqDBtr2otrIQdw+wu8W wvbNdFX6pC1q+xekSpUYb0m9QhwWdhhlRbk0afdoOGxbLsPnzf70NEgbciK45DY7z0SV QaJju904vmFSfFmjylpOn5Fef1Nk9phAr8GK8amFcUYwg65EqI6iE8zZPJ7ZJxJD1TyH ES1jZr5MznLivBVol/puv2C5bMiaryden80Y2BLf+U4dYlGOmTtbLbVdCWjpZjIXKBNA OsvQ== X-Gm-Message-State: ABuFfoj5lpn6nttVuSRjZifuVmJ5REqfwr8INm+Xk95hFXjSb985HHCS 7rOt80rQKF2qVaILTcdrYz8zCCuZ X-Google-Smtp-Source: ACcGV61jHlVPysiTfRZ+nt3yvvCV/xM2m7fdjrBtzsuSiIAJ5yszfRCDC3s6A0pTn+qUAKEpNfptEA== X-Received: by 2002:a6b:fb18:: with SMTP id h24-v6mr4593186iog.270.1539371460602; Fri, 12 Oct 2018 12:11:00 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::100e? ([2600:8802:5600:1546::100e]) by smtp.gmail.com with ESMTPSA id l15-v6sm570599iok.78.2018.10.12.12.10.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 12:10:59 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_245829F6-9D48-459B-8D36-68F37BD5D677"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <66EEE83E-7BA9-45B2-A15A-F0D46DD00E02@gmail.com> Date: Fri, 12 Oct 2018 12:10:57 -0700 To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] IETF 103 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:11:06 -0000 --Apple-Mail=_245829F6-9D48-459B-8D36-68F37BD5D677 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The IETF 103 Bangkok agenda has been posted: https://datatracker.ietf.org/meeting/103/agenda.html We're scheduled to meet: Monday, November 5, 2018 (+07) 9:00-11:00 = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_245829F6-9D48-459B-8D36-68F37BD5D677 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvA8cIACgkQEhdRnd2G P+DSjhAApZWo1JeLfEvE/2EqOzW3lzhnE9vc/lLeei0kEQeEaOqA7Nop0tH+muaY NcQMjP2pxa4yrGfUfDhQNkwb6TkWXLLPwbAMCVnui788WVv+4FWEPTohxR+Yh9Kl DetQJABHLiFOaCy11I4xTDzH0mCZrjU7TCo3c8NfrKrL9P5dDhpjnwe32VvyS6X/ D42dEeZkPEZHl6NbAygI1W+hMzyn3cFobNWwiHTOPVB+T898dM9hbA/6yMbfws+m LRCT+5tuI6b5rUNNqZSppk4od04toD3vECq8XtqH81VGEG29jVENxwaiYMuMHhOl KrSPL7Ttb+1o1eERbF2J5ouzf4vH3GuCvfuGmuwiL9yNY4gUr0Ut2nlpoBiLGh3F QtK7cTPGFn9cneb4k9Qe49gHVCMWOuRTT7Z8xuPNiKX/N1U/DS5ZHRgm1vELFI2o HZcK1d59umJVLoDCshCx6c9X5dfI7DssBYTf6WdCJQB5FmtllZvD+YExmHXYWD1q jbf9v5m2UXocxYZjRqsHvbSfYJ2e+3pNRXEUUrhaTBiuBGv1eaMFn17xAqLpjXqT r7/gsvrpvv042QQOiACulUtVvhvPxz9DVlOiwGxg2GY3XcEcAZgdtqOqa0RFTWUM csktZnIkYBWqFXOkx9LlvhX8xnpcNwa+EH9wSo9F6JCmlgx3IYI= =f+mb -----END PGP SIGNATURE----- --Apple-Mail=_245829F6-9D48-459B-8D36-68F37BD5D677-- From nobody Fri Oct 12 17:49:54 2018 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 CDFAA130EEE; Fri, 12 Oct 2018 17:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRl-YKjNpk5F; Fri, 12 Oct 2018 17:49:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966D7130EF6; Fri, 12 Oct 2018 17:49:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67CD6B817C0; Fri, 12 Oct 2018 17:49:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, v6ops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20181013004910.67CD6B817C0@rfc-editor.org> Date: Fri, 12 Oct 2018 17:49:10 -0700 (PDT) Archived-At: Subject: [v6ops] =?utf-8?q?RFC_8475_on_Using_Conditional_Router_Advertise?= =?utf-8?q?ments_for_Enterprise_Multihoming?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 00:49:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8475 Title: Using Conditional Router Advertisements for Enterprise Multihoming Author: J. Linkova, M. Stucchi Status: Informational Stream: IETF Date: October 2018 Mailbox: furry@google.com, mstucchi@ripe.net Pages: 21 Characters: 45127 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-conditional-ras-08.txt URL: https://www.rfc-editor.org/info/rfc8475 DOI: 10.17487/RFC8475 This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Oct 14 23:57:13 2018 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 2DF8A130DF6 for ; Sun, 14 Oct 2018 23:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUYQK9dQ3Z71 for ; Sun, 14 Oct 2018 23:57:08 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5775B12F1AC for ; Sun, 14 Oct 2018 23:57:07 -0700 (PDT) Received: from [212.205.221.32] (loco.otenet.gr [212.205.221.32]) by calypso.otenet.gr (ESMTP) with ESMTPSA id BC5E9138046; Mon, 15 Oct 2018 09:57:05 +0300 (EEST) From: Yannis Nikolopoulos To: Lee Howard , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> Message-ID: <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> Date: Mon, 15 Oct 2018 09:57:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 06:57:11 -0000 On 9/28/18 8:47 PM, Lee Howard wrote: > Agreed, for now different people are choosing different mechanisms, > and there isn't yet a clear winner. I've had this in my mailbox for days/weeks now. I just wanted to write "are they? are they really?" . I don't see people choosing mechanisms, people are not choosing mechanisms.People are deploying CGN en masse, people are buying IPv4 addresses under the table or people are just not touched by the IPv4 exhaustion. That is what people are doing, at least most of them. And I wonder: what went wrong? 3-4 years ago, I was willing to bet that by 2017, fixed ISPs would've switched to MAP or lw4o6. How wrong was I... I feel very disappointed . We switched to dual-stack about 10 years ago. 4 years ago, we started considering our IPv6-only service options and we've been running lw4o6 for the past 2 years. Our lw4o6 deployment is pretty small (40k users out of 1.5M) still because of various issues: CPE is a pain, DHCP is a pain, even lwaftr is a pain (more info can be provided on request). Most importantly, we do not see the economy at scale here. CGN (NAT444) is strangely cheaper and troubles-free. On top of that, we're about to test it with IPv6 support. I'm called to present a case to mgmt and I despise the fact that I've ran out of arguments for supporting an IPv6-only residential service: the only one I have left is the trouble-free native IPv6 path, but that doesn't really hold up since the percentage of complaining users is so small. So, it comes down to that: we're about to have our lw4o6 deployment shut and our CGN is almost consuming half our userbase already. The future is bleak, indeed. I've even considered 464xlat for everyone (since we're also a mobile carrier, where dual-stack and CGN are deployed) thanks for listening, Yannis From nobody Mon Oct 15 00:52:17 2018 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 3F1B9130DCE for ; Mon, 15 Oct 2018 00:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Elqp-2mdH_x4 for ; Mon, 15 Oct 2018 00:52:14 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B089130DBE for ; Mon, 15 Oct 2018 00:52:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9F7qBjO126705 for ; Mon, 15 Oct 2018 09:52:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3886B202FDE for ; Mon, 15 Oct 2018 09:52:11 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 29FF5202BC2 for ; Mon, 15 Oct 2018 09:52:11 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9F7qAsx000319 for ; Mon, 15 Oct 2018 09:52:10 +0200 To: v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> From: Alexandre Petrescu Message-ID: Date: Mon, 15 Oct 2018 09:52:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 07:52:16 -0000 Le 15/10/2018 à 08:57, Yannis Nikolopoulos a écrit : > > On 9/28/18 8:47 PM, Lee Howard wrote: >> Agreed, for now different people are choosing different mechanisms, >> and there isn't yet a clear winner. > > I've had this in my mailbox for days/weeks now. I just wanted to write > "are they? are they really?" . I don't see people choosing mechanisms, > people are not choosing mechanisms.People are deploying CGN en masse, > people are buying IPv4 addresses under the table or people are just not > touched by the IPv4 exhaustion. That is what people are doing, at least > most of them. And I wonder: what went wrong? 3-4 years ago, I was > willing to bet that by 2017, fixed ISPs would've switched to MAP or > lw4o6. How wrong was I... I feel very disappointed . > > We switched to dual-stack about 10 years ago. 4 years ago, we started > considering our IPv6-only service options and we've been running lw4o6 > for the past 2 years. Our lw4o6 deployment is pretty small (40k users > out of 1.5M) still because of various issues: CPE is a pain, DHCP is a > pain, even lwaftr is a pain (more info can be provided on request). Most > importantly, we do not see the economy at scale here. CGN (NAT444) is > strangely cheaper and troubles-free. On top of that, we're about to test > it with IPv6 support. > > I'm called to present a case to mgmt The case is the following: because IPv6 deployment is growing with low speed it is called a migration from IPv4 to IPv6; it is not a total switch like from Windows 97 to Windows 10. The case for operator is just to be ready to listen more and more end users requesting IPv6, but slowly. Is it difficult to just be ready? > and I despise the fact that I've > ran out of arguments for supporting an IPv6-only residential service: > the only one I have left is the trouble-free native IPv6 path, No no, IPv6 native is not trouble free. There are tons of in-house end user devices that prefer IPv4. Just wait for them to ask you, and certainly do not feed them IPv6 by force. Alex but that > doesn't really hold up since the percentage of complaining users is so > small. So, it comes down to that: we're about to have our lw4o6 > deployment shut and our CGN is almost consuming half our userbase > already. The future is bleak, indeed. I've even considered 464xlat for > everyone (since we're also a mobile carrier, where dual-stack and CGN > are deployed) > > thanks for listening, > Yannis > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Oct 15 03:16:30 2018 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 337F5128C65 for ; Mon, 15 Oct 2018 03:16:28 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA-vs3CbOUte for ; Mon, 15 Oct 2018 03:16:25 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E956126BED for ; Mon, 15 Oct 2018 03:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539598583; x=1540203383; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=Y8R1nMKD xpMFPB0Y00/7AdAjFQ1pdxIWarjxR4Xz0zc=; b=oXo9ZGCh4/23RVtVrqX6he+b cG5+0cToD2tGPU2u4XcqGBT+9w1uN++h62+a+HXO4nfLQiz5sOMUYf7yfj0oDHci PO8xBbLwmn83Ykz5xQqT0M6iyYMHn5sbasWZ5Je5ywLByVJVgrF+JaJu9phpORCu ESY6+zakSLh25OVmnRU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 15 Oct 2018 12:16:23 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 15 Oct 2018 12:16:23 +0200 Received: from [10.239.106.63] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005909383.msg for ; Mon, 15 Oct 2018 12:16:22 +0200 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.239.106.63] X-MDArrival-Date: Mon, 15 Oct 2018 12:16:22 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1826ea64a7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Mon, 15 Oct 2018 12:16:18 +0200 From: JORDI PALET MARTINEZ To: Yannis Nikolopoulos , Lee Howard , Message-ID: <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> In-Reply-To: <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 10:16:28 -0000 Hi Yannis, The only think I don't agree is that CGN (NAT444) is not troubles-free! Also, the cost of CGN is much higher than buying IPv4 addresses, and keep d= oing dual-stack, but Sonner or later, you will need to do something when yo= u can't buy anymore IPv4 addresses ... or become too expensive. People investing in CGN, don't realize that it is a very bad decision. Beca= use more and more content/application providers (like Sony Play Station Net= work), black-list your IPv4 CGN ranges, sooner or later you need again to b= uy IPv4 addresses ... And, wait a minute ... have you invested in CGN becau= se this way you don't need to buy IPv4 addresses? Bad decision! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Yannis Nikolopoulos Fecha: lunes, 15 de octubre de 2018, 8:57 Para: Lee Howard , Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup =20 On 9/28/18 8:47 PM, Lee Howard wrote: > Agreed, for now different people are choosing different mechanisms,= =20 > and there isn't yet a clear winner.=20 =20 I've had this in my mailbox for days/weeks now. I just wanted to write= =20 "are they? are they really?" . I don't see people choosing mechanisms,= =20 people are not choosing mechanisms.People are deploying CGN en masse,= =20 people are buying IPv4 addresses under the table or people are just not= =20 touched by the IPv4 exhaustion. That is what people are doing, at least= =20 most of them. And I wonder: what went wrong? 3-4 years ago, I was=20 willing to bet that by 2017, fixed ISPs would've switched to MAP or=20 lw4o6. How wrong was I... I feel very disappointed . =20 We switched to dual-stack about 10 years ago. 4 years ago, we started= =20 considering our IPv6-only service options and we've been running lw4o6= =20 for the past 2 years. Our lw4o6 deployment is pretty small (40k users= =20 out of 1.5M) still because of various issues: CPE is a pain, DHCP is a= =20 pain, even lwaftr is a pain (more info can be provided on request). Mos= t=20 importantly, we do not see the economy at scale here. CGN (NAT444) is= =20 strangely cheaper and troubles-free. On top of that, we're about to tes= t=20 it with IPv6 support. =20 I'm called to present a case to mgmt and I despise the fact that I've= =20 ran out of arguments for supporting an IPv6-only residential service:= =20 the only one I have left is the trouble-free native IPv6 path, but that= =20 doesn't really hold up since the percentage of complaining users is so= =20 small. So, it comes down to that: we're about to have our lw4o6=20 deployment shut and our CGN is almost consuming half our userbase=20 already. The future is bleak, indeed. I've even considered 464xlat for= =20 everyone (since we're also a mobile carrier, where dual-stack and CGN= =20 are deployed) =20 thanks for listening, Yannis =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Oct 15 03:43:20 2018 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 D18F5130E3B for ; Mon, 15 Oct 2018 03:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmnkdUMg_tbt for ; Mon, 15 Oct 2018 03:43:15 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 58C47130DFD for ; Mon, 15 Oct 2018 03:43:14 -0700 (PDT) Received: from [212.205.221.32] (loco.otenet.gr [212.205.221.32]) by calypso.otenet.gr (ESMTP) with ESMTPSA id BD9E31380FA; Mon, 15 Oct 2018 13:43:13 +0300 (EEST) To: Alexandre Petrescu , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> From: Yannis Nikolopoulos Message-ID: Date: Mon, 15 Oct 2018 13:43:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 10:43:18 -0000 HI Alexandre, On 10/15/18 10:52 AM, Alexandre Petrescu wrote: > > > Le 15/10/2018 à 08:57, Yannis Nikolopoulos a écrit : >> >> On 9/28/18 8:47 PM, Lee Howard wrote: >>> Agreed, for now different people are choosing different mechanisms, >>> and there isn't yet a clear winner. >> >> I've had this in my mailbox for days/weeks now. I just wanted to >> write "are they? are they really?" . I don't see people choosing >> mechanisms, people are not choosing mechanisms.People are deploying >> CGN en masse, people are buying IPv4 addresses under the table or >> people are just not touched by the IPv4 exhaustion. That is what >> people are doing, at least most of them. And I wonder: what went >> wrong? 3-4 years ago, I was willing to bet that by 2017, fixed ISPs >> would've switched to MAP or lw4o6. How wrong was I... I feel very >> disappointed . >> >> We switched to dual-stack about 10 years ago. 4 years ago, we started >> considering our IPv6-only service options and we've been running >> lw4o6 for the past 2 years. Our lw4o6 deployment is pretty small (40k >> users out of 1.5M) still because of various issues: CPE is a pain, >> DHCP is a pain, even lwaftr is a pain (more info can be provided on >> request). Most importantly, we do not see the economy at scale here. >> CGN (NAT444) is strangely cheaper and troubles-free. On top of that, >> we're about to test it with IPv6 support. >> >> I'm called to present a case to mgmt > > The case is the following: because IPv6 deployment is growing with low > speed it is called a migration from IPv4 to IPv6; it is not a total > switch like from Windows 97 to Windows 10. > > The case for operator is just to be ready to listen more and more end > users requesting IPv6, but slowly. > > Is it difficult to just be ready? No, we've been ready for almost a decade. Also, the amount of end users (residential or business) requesting IPv6 is really negligible > >> and I despise the fact that I've ran out of arguments for supporting >> an IPv6-only residential service: the only one I have left is the >> trouble-free native IPv6 path, > > No no, IPv6 native is not trouble free.  There are tons of in-house > end user devices that prefer IPv4. correct but our basic residential service is dual-stack regards, Yannis -- Yannis Nikolopoulos OTE S.A e-mail: yanodd@otenet.gr IP Network Planning & Engineering tel: +302106116293 ---------------------------------------------------------------------------- From nobody Mon Oct 15 03:57:18 2018 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 B5D19130E43 for ; Mon, 15 Oct 2018 03:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyJ-dNH5nYpf for ; Mon, 15 Oct 2018 03:57:13 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id DE3B6130E45 for ; Mon, 15 Oct 2018 03:57:10 -0700 (PDT) Received: from [212.205.221.32] (loco.otenet.gr [212.205.221.32]) by calypso.otenet.gr (ESMTP) with ESMTPSA id BEE57138046; Mon, 15 Oct 2018 13:57:09 +0300 (EEST) To: JORDI PALET MARTINEZ , Lee Howard , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> From: Yannis Nikolopoulos Message-ID: <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> Date: Mon, 15 Oct 2018 13:57:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 10:57:17 -0000 Hello Jordi, On 10/15/18 1:16 PM, JORDI PALET MARTINEZ wrote: > Hi Yannis, > > The only think I don't agree is that CGN (NAT444) is not troubles-free! as far as maintaining it, it is trouble-free. Some end users face all the known address sharing issues but as I wrote earlier, the percentage is very small and all those users are just rolled back to the basic dual-stack service. > > Also, the cost of CGN is much higher than buying IPv4 addresses, and keep doing dual-stack, but Sonner or later, you will need to do something when you can't buy anymore IPv4 addresses ... or become too expensive > > People investing in CGN, don't realize that it is a very bad decision. Because more and more content/application providers (like Sony Play Station Network), black-list your IPv4 CGN ranges, sooner or later you need again to buy IPv4 addresses ... And, wait a minute ... have you invested in CGN because this way you don't need to buy IPv4 addresses? Bad decision! In our case, we did not invest in CGN. We invested in preparing for IPv6 early, and so we did. When IPv4 exhaustion hit us, we did not decide to invest in either CGN or buying IPv4 addresses. Again , we invested in IPv6 (lw4o6). In the mean time between deploying lw4o6, we had to mitigate the issue, in a quick n dirty manner... that's when CGNcame into the picture. Some years later, we have a lot of CGN users and not so many in IPv6-only (lw4o6).  It just seems that, IPv6-only technologies (lw4o6 in our case) were not so straighforward to deploy and more importantly, not so cheap (performance-wise) either. Maybe the "stateless card" has been overplayed or exaggerated at the very least. > > Regards, > Jordi > > > > -----Mensaje original----- > De: v6ops en nombre de Yannis Nikolopoulos > Fecha: lunes, 15 de octubre de 2018, 8:57 > Para: Lee Howard , > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working group > > > On 9/28/18 8:47 PM, Lee Howard wrote: > > Agreed, for now different people are choosing different mechanisms, > > and there isn't yet a clear winner. > > I've had this in my mailbox for days/weeks now. I just wanted to write > "are they? are they really?" . I don't see people choosing mechanisms, > people are not choosing mechanisms.People are deploying CGN en masse, > people are buying IPv4 addresses under the table or people are just not > touched by the IPv4 exhaustion. That is what people are doing, at least > most of them. And I wonder: what went wrong? 3-4 years ago, I was > willing to bet that by 2017, fixed ISPs would've switched to MAP or > lw4o6. How wrong was I... I feel very disappointed . > > We switched to dual-stack about 10 years ago. 4 years ago, we started > considering our IPv6-only service options and we've been running lw4o6 > for the past 2 years. Our lw4o6 deployment is pretty small (40k users > out of 1.5M) still because of various issues: CPE is a pain, DHCP is a > pain, even lwaftr is a pain (more info can be provided on request). Most > importantly, we do not see the economy at scale here. CGN (NAT444) is > strangely cheaper and troubles-free. On top of that, we're about to test > it with IPv6 support. > > I'm called to present a case to mgmt and I despise the fact that I've > ran out of arguments for supporting an IPv6-only residential service: > the only one I have left is the trouble-free native IPv6 path, but that > doesn't really hold up since the percentage of complaining users is so > small. So, it comes down to that: we're about to have our lw4o6 > deployment shut and our CGN is almost consuming half our userbase > already. The future is bleak, indeed. I've even considered 464xlat for > everyone (since we're also a mobile carrier, where dual-stack and CGN > are deployed) > > thanks for listening, > Yannis > > _______________________________________________ > 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 confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > -- Yannis Nikolopoulos OTE S.A e-mail: yanodd@otenet.gr IP Network Planning & Engineering tel: +302106116293 ---------------------------------------------------------------------------- From nobody Mon Oct 15 04:09:39 2018 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 589EF130E45 for ; Mon, 15 Oct 2018 04:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_KeXwGxyNeB for ; Mon, 15 Oct 2018 04:09:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C536C130DFD for ; Mon, 15 Oct 2018 04:09:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E0ABB1; Mon, 15 Oct 2018 13:09:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539601772; bh=vRVQpIFCookCF7JBTirijqAveVfiC77ySiu/hY4/s34=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fjmWCM1g8AH+E8RLU+L2g1TEAcHpDRyiCTQqWOd4V8c0BVS42a4QUxuihuqkNy836 SH8qQTajGsAK59Q2gEdBHG93cOpNeene8L/K/S7CfDXRDDkNWO81atJjT4xjO5hW4g SmXSPOp86ZhCyRJ90MbmWrVeJfwOjfsN/SHMjtpE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5B7FEAF; Mon, 15 Oct 2018 13:09:32 +0200 (CEST) Date: Mon, 15 Oct 2018 13:09:32 +0200 (CEST) From: Mikael Abrahamsson To: Yannis Nikolopoulos cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 11:09:37 -0000 On Mon, 15 Oct 2018, Yannis Nikolopoulos wrote: > No, we've been ready for almost a decade. Also, the amount of end users > (residential or business) requesting IPv6 is really negligible Well, I would imagine that the amount of end users requesting IPv4 is also negligible. Users want to access cat pictures ie "working Internet access". In order to grow the Internet, we need IPv6 to work, and it's up to us on the technical part to make sure the Internet continues working. This means over time migrate all of our users to IPv6. Anyone waiting for customers to demand IPv6 access is waiting for the wrong thing, it's like an airline waiting for the customers to demand that their engine fan blades would be made of a special alloy. Most customers do not know, don't want to know, they just want things to work. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 15 04:10:34 2018 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 69FF3130E45 for ; Mon, 15 Oct 2018 04:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NkJ40yHglga for ; Mon, 15 Oct 2018 04:10:30 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0DF130DFD for ; Mon, 15 Oct 2018 04:10:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9FBAR9Q006100; Mon, 15 Oct 2018 13:10:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A523720567B; Mon, 15 Oct 2018 13:10:27 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9698520560C; Mon, 15 Oct 2018 13:10:27 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9FBAR4b010778; Mon, 15 Oct 2018 13:10:27 +0200 To: Yannis Nikolopoulos , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> From: Alexandre Petrescu Message-ID: <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> Date: Mon, 15 Oct 2018 13:10:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 11:10:33 -0000 Le 15/10/2018 à 12:43, Yannis Nikolopoulos a écrit : > HI Alexandre, > > On 10/15/18 10:52 AM, Alexandre Petrescu wrote: >> >> >> Le 15/10/2018 à 08:57, Yannis Nikolopoulos a écrit : >>> >>> On 9/28/18 8:47 PM, Lee Howard wrote: >>>> Agreed, for now different people are choosing different >>>> mechanisms, and there isn't yet a clear winner. >>> >>> I've had this in my mailbox for days/weeks now. I just wanted to >>> write "are they? are they really?" . I don't see people choosing >>> mechanisms, people are not choosing mechanisms.People are >>> deploying CGN en masse, people are buying IPv4 addresses under >>> the table or people are just not touched by the IPv4 exhaustion. >>> That is what people are doing, at least most of them. And I >>> wonder: what went wrong? 3-4 years ago, I was willing to bet that >>> by 2017, fixed ISPs would've switched to MAP or lw4o6. How wrong >>> was I... I feel very disappointed . >>> >>> We switched to dual-stack about 10 years ago. 4 years ago, we >>> started considering our IPv6-only service options and we've been >>> running lw4o6 for the past 2 years. Our lw4o6 deployment is >>> pretty small (40k users out of 1.5M) still because of various >>> issues: CPE is a pain, DHCP is a pain, even lwaftr is a pain >>> (more info can be provided on request). Most importantly, we do >>> not see the economy at scale here. CGN (NAT444) is strangely >>> cheaper and troubles-free. On top of that, we're about to test it >>> with IPv6 support. >>> >>> I'm called to present a case to mgmt >> >> The case is the following: because IPv6 deployment is growing with >> low speed it is called a migration from IPv4 to IPv6; it is not a >> total switch like from Windows 97 to Windows 10. >> >> The case for operator is just to be ready to listen more and more >> end users requesting IPv6, but slowly. >> >> Is it difficult to just be ready? > > No, we've been ready for almost a decade. :-) It sounds as being disappointed that a decade passed and the next generation protocol is still not widespread. But it was the first such decade, and much thrilling we witnessed: 6to4, 6over4, teredo, ... 464xlat. The next decade would slow down, and maybe subsequent decades will again accelerate deployment. For comparison, in AI 6 decades passed since Turing came up with a test and until a computer won at chess; and still today most humans win. > Also, the amount of end users (residential or business) requesting > IPv6 is really negligible True, it is negligible but it is not absent. If one wants to tempt more users into IPv6 then one has to: - tempt hardware and OS manufacturers into upgrading to IPv6 the devices. - tempt the innovators in other fields (IoT, AI, biotech, etc.) to prefer IPv6. Too many new concepts and products come up routinely new in the market that prefer IPv4 instead. The other day I saw these Epson futuristic glasses. - tempt core ISP give more bandwidth to IPv6 links than to IPv4 links. When 100Tbit/s links come up they should ping IPv6 only. >>> and I despise the fact that I've ran out of arguments for >>> supporting an IPv6-only residential service: the only one I have >>> left is the trouble-free native IPv6 path, >> >> No no, IPv6 native is not trouble free. There are tons of in-house >> end user devices that prefer IPv4. > > correct but our basic residential service is dual-stack Which makes me ask you: are your links to residential networks giving more bandwidth to IPv6? Or the same? (in my lab, my ISP gives more slightly more bandwidth to IPv6: ping6 google.com has slightly lower RTT than IPv4; this IPv6 favoring is only recent). Alex > > regards, Yannis > From nobody Mon Oct 15 04:14:34 2018 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 C802F130DFD for ; Mon, 15 Oct 2018 04:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM4NG80Ua_Ns for ; Mon, 15 Oct 2018 04:14:29 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8109A128BAC for ; Mon, 15 Oct 2018 04:14:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9FBER3e028721 for ; Mon, 15 Oct 2018 13:14:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89D93205627 for ; Mon, 15 Oct 2018 13:14:27 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8034C2055E9 for ; Mon, 15 Oct 2018 13:14:27 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9FBER2W012470 for ; Mon, 15 Oct 2018 13:14:27 +0200 To: v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> From: Alexandre Petrescu Message-ID: <9120897a-bf37-9faa-1bbb-e6dbd019df10@gmail.com> Date: Mon, 15 Oct 2018 13:14:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 11:14:32 -0000 Le 15/10/2018 à 13:09, Mikael Abrahamsson a écrit : > On Mon, 15 Oct 2018, Yannis Nikolopoulos wrote: > >> No, we've been ready for almost a decade. Also, the amount of end >> users (residential or business) requesting IPv6 is really negligible > > Well, I would imagine that the amount of end users requesting IPv4 is > also negligible. > > Users want to access cat pictures ie "working Internet access". In order > to grow the Internet, we need IPv6 to work, and it's up to us on the > technical part to make sure the Internet continues working. This means > over time migrate all of our users to IPv6. > > Anyone waiting for customers to demand IPv6 access is waiting for the > wrong thing, it's like an airline waiting for the customers to demand > that their engine fan blades would be made of a special alloy. Most > customers do not know, don't want to know, they just want things to work. I agree with you :-) End users ask for more bandwidth. Make IPv6 give more bandwidth than IPv4. That's how it works with 3G, 4G, 5G. Alex > From nobody Mon Oct 15 04:17:29 2018 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 6B234130E3B for ; Mon, 15 Oct 2018 04:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hovvyoaUUMnJ for ; Mon, 15 Oct 2018 04:17:25 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735DE130DFD for ; Mon, 15 Oct 2018 04:17:25 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-43-96.kabelnet.hu [79.121.43.96]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w9FBHH67044043 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 15 Oct 2018 13:17:22 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-43-96.kabelnet.hu [79.121.43.96] claimed to be [192.168.1.119] To: v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <2cdcf419-2ae7-26da-338a-9a0937dee836@hit.bme.hu> Date: Mon, 15 Oct 2018 13:17:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.43.96; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 11:17:28 -0000 Dear Yannis, 10/15/2018 12:57 PM keltezéssel, Yannis Nikolopoulos írta: [...] > It just seems that, IPv6-only technologies (lw4o6 in our case) were > not so straighforward to deploy and more importantly, not so cheap > (performance-wise) either. Maybe the "stateless card" has been > overplayed or exaggerated at the very least. > If you have some experience, which you would like to share with us, we would be happy to include the lessons you have learnt into our I-D titled "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00 Best regards, Gábor Lencse From nobody Mon Oct 15 07:45:58 2018 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 34A89130E81 for ; Mon, 15 Oct 2018 07:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.351, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4AdPSItttKD for ; Mon, 15 Oct 2018 07:45:54 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D15C130E26 for ; Mon, 15 Oct 2018 07:45:54 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9FEiJoM010195 for ; Mon, 15 Oct 2018 07:45:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=DeR+qKth/ls5qmPRt+L3r2FfjIlMncWPjp8BWvRNlvo=; b=hec2f22GWrPn26x/5UPPWIvlxRFTMSAg9GCKTKEi48NWVliVBuhLXFs/ZK4jfkwQimDP uJD+wtRiYO3PZrthlLiGpCqneZaQseJItWHf2tPq2hT5zZA7imX/A6LkeAepJXWgsMka CvR1ucbsRaC0xkuMg3eHTWHpGAs0gwPx/leW1k+NvlAKZve7F1veiJ8naTIUJTAC8cay LggacyjDB3f2QUzJuEYYtM3D64wJ0mFljoKRGwYGwORtq7qgr6DR7nV/n6LvRFkSY/yL wW5CKMbm5A1/0V59yh1a8X7OP4k19j5xRguiMcQoii4U/yQo9/PvuAuhcUdVoUl/a96B Jw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0016.outbound.protection.outlook.com [207.46.163.16]) by mx0a-00273201.pphosted.com with ESMTP id 2n4sn3ga1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Oct 2018 07:45:54 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5269.namprd05.prod.outlook.com (20.177.231.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.14; Mon, 15 Oct 2018 14:45:52 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772%4]) with mapi id 15.20.1228.020; Mon, 15 Oct 2018 14:45:52 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-pref64folks-6man-ra-pref64 Thread-Index: AdRklblxbgWIfbn2QzSrUhhCCNnfRw== Date: Mon, 15 Oct 2018 14:45:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.58 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5269; 6:F2f49CLUQDK/+k1VQgkSmUtX0ul+HXYkIdzStGk9Z1ZxZz/jIfKMQUbn02sOKqMnlti7W8qHEPp/P0ARkk4C4DrS3w0+0OJqR+ZUUzUfZ32Fw3CYqub/WVBGeEeOwcy6w1tRnHI+v1swSF5kHr14BHvJdB1Di9wiI5W5Dpl8jjRvR3zTakr11fwa0rfOyI6E3hTGrFfbSRjHQVx3M5ubZjQVFn59owI1EPw0B79O9FXH9xAf513oMjZj4PNxfymgv1HXHcNcFC3hbjfvyVnLFAdMkYlmqt3WUqh0Fe5G1kQk/kqtcadE3Qnp4iGEiHYXIpc6rNq5WjI6ELGRKvEzlrIzdynf9mdocdY+qjQxHLCI7HUFIyNW570457kXFHtuK7ru+51F08Irt9J3nvPYbzDvam0e20wPE6YOBSYYVAX5l+7xfA+snCpoWNpd8Od9WJ+ljgtTjv041vwIViYptA==; 5:bRxCxgVU+EjH71lWYcmtdCsxnjquLXfMkFXlcQK8aUsCuCyFjZo672dB3PXFFOgKIYsisbK+puVzdL/3zx0Puxb8tfrOaXo+eflzdyJ4XKsl0ePO6NTvb56YAd0gL+0M8YN4NryEdReD/5zb9rWWyM22cDSNHGGDnS12KV4DMFo=; 7:LJ+slWE85eEY1YH7vkEdX6eUxYQLJuXk2KUdZqbeUKOCWhD6z3oT0gYcyn5WP0v9j8k3KUHdNxWfo0Ltp63f1ZZboWvQifMI/RDu7yMU0no1BJm/R37E6Nvjh6x0WK0gt0w5/SltmDqiSX7X4wGmbx0uJTDtvsU2HLFdsxGysBVGeBky3Osqu5LNcDvqS4KS7ZgsopGZJzJ5GhFlxRtCqGsXbjV5SPCetbGZwCb3nv4Cbnz/NIuHfiMQUEacUKNy x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e17a8abf-c223-4c00-02ad-08d632ace7c5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5269; x-ms-traffictypediagnostic: BYAPR05MB5269: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:BYAPR05MB5269; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5269; x-forefront-prvs: 0826B2F01B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(366004)(136003)(346002)(199004)(189003)(558084003)(4743002)(74316002)(97736004)(86362001)(2900100001)(53936002)(305945005)(7736002)(6436002)(256004)(5640700003)(5660300001)(2906002)(8676002)(486006)(68736007)(476003)(478600001)(316002)(8936002)(81156014)(81166006)(7696005)(3846002)(25786009)(26005)(33656002)(6116002)(66066001)(186003)(99286004)(106356001)(55016002)(105586002)(102836004)(71200400001)(71190400001)(9686003)(2351001)(6506007)(5250100002)(2501003)(14454004)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5269; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: CLJtQEPPe1sTZVz+8ZgHFfsDJaWjOPKf5jMxKpEpLF9/0jHHQT/G53xP5TstT4cfCy1N/TYqdd/4nvry2JReq5QqVU9dt+zvDnoO+ZBNfOrlWiQ2cOkoav0BodVUcuod8kqubnWCrLCB7coKqEFrkxGtUJZb3v1aedmK6ZBshhPqBwV2CCp+wO5QpAgZiBuflu1olhsPbOt5dps4rPcmOELEpHu1dJ4XWbDcKpy0IhkAf0I7PncFpeB9JNFWigRIdOj+pQrGEOUWYUkhRdZpclwkHqiM511r0eJCpWRsGHnERCP6XfFzwP/6wTL4XR7L5IlErK36rt2fHYiN4FazD5y4B5XQs5wYC0nYgwegu40= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: e17a8abf-c223-4c00-02ad-08d632ace7c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2018 14:45:52.2309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5269 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810150135 Archived-At: Subject: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 14:45:57 -0000 Folks, Each week between now and IETF 103, we will review and discuss one draft. This week, please review and comment on draft-pref64folks-6man-ra-pref64 Fred and Ron From nobody Mon Oct 15 11:35:51 2018 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 49366130E08 for ; Mon, 15 Oct 2018 11:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SQ06k0kJcoi for ; Mon, 15 Oct 2018 11:35:48 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7F4124C04 for ; Mon, 15 Oct 2018 11:35:48 -0700 (PDT) Received: from 192.168.1.10 (dusted.otenet.gr [195.167.126.245]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 3523913803D; Mon, 15 Oct 2018 21:35:47 +0300 (EEST) To: Alexandre Petrescu , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> From: Yannis Nikolopoulos Message-ID: Date: Mon, 15 Oct 2018 21:35:46 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 18:35:50 -0000 On 15/10/2018 14:10, Alexandre Petrescu wrote: > If one wants to tempt more users into IPv6 then one has to: that's the point though, we're not looking to tempt more users into IPv6. We're trying to find a viable case against scrapping our IPv6-only efforts From nobody Mon Oct 15 11:38:17 2018 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 E11751292F1 for ; Mon, 15 Oct 2018 11:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu1jCKCe766j for ; Mon, 15 Oct 2018 11:38:13 -0700 (PDT) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8912124C04 for ; Mon, 15 Oct 2018 11:38:12 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id p1-v6so18445715ljg.6 for ; Mon, 15 Oct 2018 11:38:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=upFQd5EQABVSKQdU/Frd1LMO6A3F8xuFh1A5vy6Mdi0=; b=Y22c5ZcubAoC5565T3ShqtOXOTDGhaLf8TtZVnJQRSEVkt19TyCJLZwMNCXbKqmsz8 btjt8x7TsqZK/51jxzB+j/N5Z1mCgS2bI0honnGiezCcQLfeu7PNRtRbGYr7xGIo7zWb mVo199tTX/qlWoW5Uh6IMNKz01vZ+PrqoVWJr70RUnlAUAdzKL16WsdquHWhHNwJWCGa xCHN61V14OCyiOU6OttybrhJk92lIYJYud/d6b3F+Ce4X1Rl2fdVff66r9NB/lQI2eWN TZqRayPWadyBi5Fs3yxXRihzFOAEweA7AuFSsjPQz7f6T7DfyLK56SKEbMap3Zsre5Bn QR6g== X-Gm-Message-State: ABuFfoiqHMDSZi10eUdK5s2A9T1d5kBztLtfY32cXrQ0X7I1qnWTv0Ja chw1TPwXqj7BN9sKhKyqTCDsxitHDj46GlpI0rUusOHn X-Google-Smtp-Source: ACcGV63JP86Vx3kxMXFRxulPMMw93Qq0I35SfflT42BGd6iQZEJrP/VDfONfd1pM7ivUJ3c+30UR9A+UQGvkD23VONI= X-Received: by 2002:a2e:1615:: with SMTP id w21-v6mr11693324ljd.33.1539628690429; Mon, 15 Oct 2018 11:38:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 15 Oct 2018 11:37:58 -0700 Message-ID: To: Ronald Bonica Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000002ddb29057848bd59" Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 18:38:15 -0000 --0000000000002ddb29057848bd59 Content-Type: text/plain; charset="UTF-8" At Mon, 15 Oct 2018 14:45:52 +0000, Ron Bonica wrote: > Each week between now and IETF 103, we will review and discuss one draft. > This week, please review and comment on draft-pref64folks-6man-ra-pref64 I've read draft-pref64folks-6man-ra-pref64-02. I don't have a strong opinion on the proposal itself. I have some minor comments on the draft: - Section 1: it would be more reader friendly if it expands "PvD" on its first use. - In section 2 (or somewhere else like in the introduction) I think it's fair to point out that the RA approach has a drawback of configuring local routers of each end subnet (where ordinary clients reside). It's unlike the advertisement of on-link/addrconf prefix for which the router should inherently know and be configured with anyway, so it looks to me to be a tradeoff between the router configuration overhead and the advantages described in this section. Similarly, we might want to note that this case in Section 5 should be (very?) atypical even if not forbidden: o The pref64 option presents in a single RA more than once; - Section 3 For simplicity, this option only supports a NAT64 prefix length of 96 bits, as this is by the most common configuration used by hosts. I have no problem with this restriction, but just saying "for simplicity" sounds a bit awkward as it also mentions the case of other prefix lengths and suggests other ways for such cases. That's awkward to me since it's not difficult at all to support multiple different prefix lengths: just add another field to the option. I guess one (major?) background rationale is the desire to keep the option length a multiple of 8 octets without padding. I think that's worth mentioning. - Section 3: these two don't read very consistently: This option may appear more than once in a Router Advertisement. [...] This option specifies exactly one NAT64 prefix for all IPv4 destinations. If it intends to specify *exactly one* prefix, what's the point of having more than one options (unless these options include exactly the same prefix, which also makes no sense). I guess this is rather an editorial matter than a protocol problem - perhaps in this context we just don't have to say the "may appear more than once" sentence. -- JINMEI, Tatuya --0000000000002ddb29057848bd59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Mon, 15 Oct 2018 14:45:52 +0000,
Ro= n Bonica <rbonica@juniper.net= > wrote:

> Each week between now and IETF 103, we will review = and discuss one draft.
> This week, please review and comment on draf= t-pref64folks-6man-ra-pref64

I've read draft-pref64folks-6man-ra= -pref64-02.=C2=A0 I don't have a strong
opinion on the proposal itse= lf.=C2=A0 I have some minor comments on the
draft:

- Section 1: i= t would be more reader friendly if it expands "PvD" on
=C2=A0 = its first use.

- In section 2 (or somewhere else like in the introdu= ction) I think
=C2=A0 it's fair to point out that the RA approach ha= s a drawback of
=C2=A0 configuring local routers of each end subnet (whe= re ordinary clients
=C2=A0 reside).=C2=A0 It's unlike the advertisem= ent of on-link/addrconf prefix
=C2=A0 for which the router should inhere= ntly know and be configured with
=C2=A0 anyway, so it looks to me to be = a tradeoff between the router
=C2=A0 configuration overhead and the adva= ntages described in this section.

=C2=A0 Similarly, we might want to= note that this case in Section 5 should
=C2=A0 be (very?) atypical even= if not forbidden:

=C2=A0=C2=A0 o=C2=A0 The pref64 option presents i= n a single RA more than once;

- Section 3

=C2=A0=C2=A0 For si= mplicity, this option only supports a NAT64 prefix length of 96
=C2=A0= =C2=A0 bits, as this is by the most common configuration used by hosts.
=
=C2=A0 I have no problem with this restriction, but just saying "f= or
=C2=A0 simplicity" sounds a bit awkward as it also mentions the = case of
=C2=A0 other prefix lengths and suggests other ways for such cas= es.=C2=A0 That's
=C2=A0 awkward to me since it's not difficult a= t all to support multiple
=C2=A0 different prefix lengths: just add anot= her field to the option.=C2=A0 I
=C2=A0 guess one (major?) background ra= tionale is the desire to keep the
=C2=A0 option length a multiple of 8 o= ctets without padding.=C2=A0 I think
=C2=A0 that's worth mentioning.=

- Section 3: these two don't read very consistently:

=C2= =A0=C2=A0 This option may appear more than once in a Router Advertisement.<= br>[...]
=C2=A0=C2=A0 This option specifies exactly one NAT64 prefix for= all IPv4
=C2=A0=C2=A0 destinations.

=C2=A0 If it intends to spec= ify *exactly one* prefix, what's the point of
=C2=A0 having more tha= n one options (unless these options include exactly
=C2=A0 the same pref= ix, which also makes no sense).=C2=A0 I guess this is rather
=C2=A0 an e= ditorial matter than a protocol problem - perhaps in this
=C2=A0 context= we just don't have to say the "may appear more than once"=C2=A0 sentence.

--
JINMEI, Tatuya
--0000000000002ddb29057848bd59-- From nobody Mon Oct 15 23:47:40 2018 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 52BE812D4E9 for ; Mon, 15 Oct 2018 23:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPIHmh7bRwIZ for ; Mon, 15 Oct 2018 23:47:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332C0126CB6 for ; Mon, 15 Oct 2018 23:47:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 364D2B2; Tue, 16 Oct 2018 08:47:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539672452; bh=sjLXwry+13JdP3IpmX2H7BizeK4vvKcvLPGKNCaRadA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GjmiyHs0GvYfNO0nbBDY+bt76RPl0D2CdkcgCo4LHcjQKRhYLDm+UutOg1lkCIp8Q Iqa4tCVcWXQK5yXw8Q8umWuHdG4wUAxiNX9s5rMecg7pS0HRCfQmrxuHgUlUWNNgrS X48+/9xG5t3iLPU9E7HnVhCVUediQJO3LDzv5sQU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2EDFAB1; Tue, 16 Oct 2018 08:47:32 +0200 (CEST) Date: Tue, 16 Oct 2018 08:47:32 +0200 (CEST) From: Mikael Abrahamsson To: Ron Bonica cc: "v6ops@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 06:47:38 -0000 On Mon, 15 Oct 2018, Ron Bonica wrote: > Folks, > > Each week between now and IETF 103, we will review and discuss one draft. > > This week, please review and comment on draft-pref64folks-6man-ra-pref64 I read through the draft and support this work. My only question is if all the text regarding PvDs etc really is needed? There is nothing special about this option, and the PvD documents already say the same thing as this document? I don't oppose the text to be there, I'm just asking if it's strictly needed. I prefer drafts to be "short and sweet". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Oct 16 01:49:47 2018 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 B66F112F1AC for ; Tue, 16 Oct 2018 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YimjkAsXVvnW for ; Tue, 16 Oct 2018 01:49:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A5B12F1A6 for ; Tue, 16 Oct 2018 01:49:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9G8nflF052752; Tue, 16 Oct 2018 10:49:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BC33C20580D; Tue, 16 Oct 2018 10:49:41 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AF26420339A; Tue, 16 Oct 2018 10:49:41 +0200 (CEST) Received: from [10.8.68.9] ([10.8.68.9]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9G8nfop030600; Tue, 16 Oct 2018 10:49:41 +0200 To: Yannis Nikolopoulos , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> From: Alexandre Petrescu Message-ID: <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> Date: Tue, 16 Oct 2018 10:49:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 08:49:46 -0000 Le 15/10/2018 à 20:35, Yannis Nikolopoulos a écrit : > > > On 15/10/2018 14:10, Alexandre Petrescu wrote: >> If one wants to tempt more users into IPv6 then one has to: > that's the point though, we're not looking to tempt more users into > IPv6. We're trying to find a viable case against scrapping our IPv6-only > efforts That is also a good idea. Alex > From nobody Tue Oct 16 03:05:28 2018 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 AC609130DD2 for ; Tue, 16 Oct 2018 03:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVNdOTROzTYA for ; Tue, 16 Oct 2018 03:05:25 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5A5130DD9 for ; Tue, 16 Oct 2018 03:05:22 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id p6-v6so13729942qkg.1 for ; Tue, 16 Oct 2018 03:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+FZ9mmI7TOYwvqly2yxSAYkorItVMEWFm2aAKUhfqQQ=; b=dMjN2OptDopYN3GUtRaPKF+vLNz6GWH7rh1yV9FN7herbgJ43x1l9Q2LQ5ZquuqteR UW22bsDhxSFLiUgF7DRWh3Aq6MWP84v/KDEPLr6s7XFj6N4kEygUHomLBl3KXKb8YUOY lIMyS3fNKWKHJrjCe3C+0R0IabniI9jHbudoLjHiOi7D3gZZn318Pw2NWQSXQRXcV0pd 3xvCUUAY8Z+EL7e/brQ7xlCqlIH4Br4g0rQvQ8l2mq6tFLPqsH4YY/ARtm4KxOfG/mof nq6ZFSPFB9HzWwm7EJHp9Bg54oufskSjKVqqU7yF9KbjHk2dvG/bYA2l9p7x7lxzlN1N oETA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+FZ9mmI7TOYwvqly2yxSAYkorItVMEWFm2aAKUhfqQQ=; b=BsAozLXuA0/jOYQ7DaosF2Amz3vsmlyXw8P9kMF16fMjhXoOGWzWXuOkCeG28gLIKK X48jrz+JCBruygix32EU7csbUhJ9WyY6C2vqwkebHBYgY6MrnrpCGNo30Xo0tS6UzXPw JTGi+NsWJVrVZj1Gyo8rBW3OIs7rIOSQFvZmG45a+11vYOrQ6pdPdB7hvHCl2xMWSWfq 4j8T0fASeIkHvwYbMnuOJXLjMkpnOK0W59cviXz7onXiQfxclHNWwVJMA/NinZci6zyh OK48uAcKjsBHIdhigt/H56M8KfJO8J0ngIhHwYMgJp5Es/IYABwhmaghNvqafoXTr7cE DMvQ== X-Gm-Message-State: ABuFfohQ03AoJkk13VckqZHjy4avRvmXArqbaSuimfGtyd04gTUNuuTH Rg/g9f2EeIwP8whrAWI/u8I71kqYgzymYFuCSi4= X-Google-Smtp-Source: ACcGV63+vVzczX0JcWrnkf9cT0JHSsfOs+D8x0jXCF1k10Eqawk0pyhWKLThdpFqBbRdNv+8dyoL/AznspA8F/JxcrI= X-Received: by 2002:a37:b10:: with SMTP id 16-v6mr14983402qkl.139.1539684321195; Tue, 16 Oct 2018 03:05:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Tue, 16 Oct 2018 21:05:09 +1100 Message-ID: To: Mikael Abrahamsson Cc: Ronald Bonica , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 10:05:27 -0000 Hi Mikael, On Tue, Oct 16, 2018 at 5:48 PM Mikael Abrahamsson wrote: > > This week, please review and comment on draft-pref64folks-6man-ra-pref64 > I read through the draft and support this work. > My only question is if all the text regarding PvDs etc really is needed? > There is nothing special about this option, and the PvD documents already > say the same thing as this document? That text was added in response to a comment made in 6man@ re: multihomed hosts. You are right, there is nothing special about that option, it's just another PvD-specific configuration option. The reason to mention PvD is be specific in describing corner cases. The multi-homing scenario, when a host might receive multiple Pref64, is one of such corner cases. IMHO it would be desirable to define the host behavior and limitations of the proposed solution. -- SY, Jen Linkova aka Furry From nobody Tue Oct 16 03:28:53 2018 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 BB904130DD2 for ; Tue, 16 Oct 2018 03:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb1dmZyB0g19 for ; Tue, 16 Oct 2018 03:28:50 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C435130DD6 for ; Tue, 16 Oct 2018 03:28:50 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id x8-v6so13745202qka.4 for ; Tue, 16 Oct 2018 03:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NipAnQUuXrWboM9hyGMDHdO5BAIKXts/3IxcGe3omzg=; b=ji+n9fvUGVatQa+SverlHO2e6BmEHRHImWjuqdd1C/Pqor5xQBwaervBLRAnL7a5+1 cHY9sE6vMbBzW7HCWh0I0akYnPjQSJUv+d59o5iCFzGleQzlcoH6GEXtF3PKxQTlyhNx wEaVSGUU2AMbJk9HolSy5XMS5BbvlJuRpqYO8GW1qC6RO9AoIrCO0yJE9X/anOGLHICy YFhKl9UYtZtaKsvYjg6iEo3hWIQdLBtNp97OJljIaRWj6iE62DbIkoYe0KI2VeV7ON7u iUgdQvwOF6rZ0jKph0+OLpn4s1HqkJ9vvLVjFca24G9+zYSbcELHHjOPM7qmJT88ThV0 fTEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NipAnQUuXrWboM9hyGMDHdO5BAIKXts/3IxcGe3omzg=; b=dS/Poy57Tp+iNcq5FtYth/J5ALuDllAjV/L7QXDJe0q40zWfFOh39rNAbQViNOwG1p gqHPTqI678MfcMpxKnHX+tdkarDNuF08aayuEAtgGDaiYBtfof4yP+WUcI1c1X1CJf8l QR/s8IZYVGKbbmVuZrJ1V36Rik09YKeIL0ARzwBdcIcJzmPvI4UsQfCCRY7C/hrYJRY8 R9czVpcH7uTpxqa3PTsPL1eJffAYTOgyyLWz2isBeJTXoZTW4/F9Pg7PI7A3ffnNKpwl VIETdUFc/5RjncOewWekf8xmY6oWIOGL8QB/Xtkn5if3cnqIqwUxvuFPgelpNtLSyCwT lCWA== X-Gm-Message-State: ABuFfoiXgqT13rvr9oiYjeXLgQRZVldGFfW8ENVfBCL8JDJP3qISCtHV N/K3CSSgkCNMcJIksK7qsPGbGk1AKaozLdmIsfjL8bZ01vc= X-Google-Smtp-Source: ACcGV63ohPcRCli3VtYNcyt6F59Gkp5BY2GRp61Fb6CKQJeAgLIDBdnkuQjfIgrM5KOqnIgSJYWRcZEAarRn0ntQgt0= X-Received: by 2002:a37:b4c7:: with SMTP id d190-v6mr18952058qkf.165.1539685729532; Tue, 16 Oct 2018 03:28:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Tue, 16 Oct 2018 21:28:37 +1100 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Ronald Bonica , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 10:28:52 -0000 Jinmei-san, Thanks a lot for your feedback. Comments inline. On Tue, Oct 16, 2018 at 5:38 AM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > - Section 1: it would be more reader friendly if it expands "PvD" on > its first use. Good point. I'll update the Terminology section. > - In section 2 (or somewhere else like in the introduction) I think > it's fair to point out that the RA approach has a drawback of > configuring local routers of each end subnet (where ordinary clients > reside). It's unlike the advertisement of on-link/addrconf prefix > for which the router should inherently know and be configured with > anyway, so it looks to me to be a tradeoff between the router > configuration overhead and the advantages described in this section. Well...Some vendors still require the prefix to be explicitly configured under router-advertisement section to be included in PIOs (just configuring /64 on the interface is not enough) so SLAAC does require some explicit configuration anyway (and RDNSS and timers etc). On the other hand, some vendor allow the configuration to be inherited so in real life it will be one-line config to enable this option on multiple interfaces...So, to be honest, I do not see much difference between this option and any other SLAAC parameter... > Similarly, we might want to note that this case in Section 5 should > be (very?) atypical even if not forbidden: > > o The pref64 option presents in a single RA more than once; It would be necessary for renumbering from one pref64 to another. The old pref64 needs to be advertised with zero Lifetime, while the new pref64 would have non-zero lifetime. > - Section 3 > > For simplicity, this option only supports a NAT64 prefix length of 96 > bits, as this is by the most common configuration used by hosts. > > I have no problem with this restriction, but just saying "for > simplicity" sounds a bit awkward as it also mentions the case of > other prefix lengths and suggests other ways for such cases. That's > awkward to me since it's not difficult at all to support multiple > different prefix lengths: just add another field to the option. I > guess one (major?) background rationale is the desire to keep the > option length a multiple of 8 octets without padding. I think > that's worth mentioning. It's also configuration simplicity. But I see your point. We do try to keep the option length to minimum, to avoid increasing RA size. I'll try to rephrase this sentence to make it more clear. > - Section 3: these two don't read very consistently: > This option may appear more than once in a Router Advertisement. > [...] > This option specifies exactly one NAT64 prefix for all IPv4 > destinations. Sorry, I'm not sure I understand why. For example, a PIO contains exactly one prefix. However Prefix Information Option may appear more than once in a Router Advertisement. The same here. > If it intends to specify *exactly one* prefix, what's the point of > having more than one options (unless these options include exactly > the same prefix, which also makes no sense). I guess this is rather > an editorial matter than a protocol problem - perhaps in this > context we just don't have to say the "may appear more than once" > sentence. See the renumbering example above. -- SY, Jen Linkova aka Furry From nobody Tue Oct 16 04:12:46 2018 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 C79CC130DD7 for ; Tue, 16 Oct 2018 04:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZEtnCyNSlp4 for ; Tue, 16 Oct 2018 04:12:42 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF33130DCC for ; Tue, 16 Oct 2018 04:12:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E51EEB6; Tue, 16 Oct 2018 13:12:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539688359; bh=YY+JYFMksMnhO6jaR1VC/VAD32rs4qhUUl59CQtGNcQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qgCKJE+kxiMSc5U4qsmg4p1pAKDw5mVimB1V67wi5QeG3snMyOqYS/Ak8qYbXy/aa JVucJkx3K6Tf5ZnvJvIcmueratV9MIUu5G/T+SGpRXRuxDsXxvLw1RtoiEB2Otk+VA j7fTnbna+Zh7ap1Bcn5X6cerZ+pFrEy8KPkyBglw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E3026B2; Tue, 16 Oct 2018 13:12:39 +0200 (CEST) Date: Tue, 16 Oct 2018 13:12:39 +0200 (CEST) From: Mikael Abrahamsson To: Jen Linkova cc: Ronald Bonica , V6 Ops List In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 11:12:45 -0000 On Tue, 16 Oct 2018, Jen Linkova wrote: > That text was added in response to a comment made in 6man@ re: multihomed hosts. > You are right, there is nothing special about that option, it's just > another PvD-specific configuration option. > The reason to mention PvD is be specific in describing corner cases. > The multi-homing scenario, when a host might receive multiple Pref64, > is one of such corner cases. IMHO it would be desirable to define the > host behavior and limitations of the proposed solution. Right. Well, since I do want PvDs to work I don't think it hurts to mention it in documents like this. Just as long as we make sure we don't define anything new regarding that in any other document unintentionally. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Oct 16 05:10:01 2018 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 0D6F3130DDE for ; Tue, 16 Oct 2018 05:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA44ZeaNSJLW for ; Tue, 16 Oct 2018 05:09:57 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D6130DDB for ; Tue, 16 Oct 2018 05:09:56 -0700 (PDT) Received: from [212.205.221.32] (loco.otenet.gr [212.205.221.32]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 0BD8013803D; Tue, 16 Oct 2018 15:09:55 +0300 (EEST) To: Alexandre Petrescu , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> From: Yannis Nikolopoulos Message-ID: <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> Date: Tue, 16 Oct 2018 15:09:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 12:09:59 -0000 On 10/16/18 11:49 AM, Alexandre Petrescu wrote: > > > Le 15/10/2018 à 20:35, Yannis Nikolopoulos a écrit : >> >> >> On 15/10/2018 14:10, Alexandre Petrescu wrote: >>> If one wants to tempt more users into IPv6 then one has to: >> that's the point though, we're not looking to tempt more users into >> IPv6. We're trying to find a viable case against scrapping our >> IPv6-only efforts > > That is also a good idea. > what is? Scrapping our IPv6-only efforts? :) > Alex > >> -- Yannis Nikolopoulos OTE S.A e-mail: yanodd@otenet.gr IP Network Planning & Engineering tel: +302106116293 ---------------------------------------------------------------------------- From nobody Tue Oct 16 13:43:16 2018 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 6A73F130E3D for ; Tue, 16 Oct 2018 13:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx788S59PVJH for ; Tue, 16 Oct 2018 13:43:11 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C658130E35 for ; Tue, 16 Oct 2018 13:43:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9GKh8uv136030; Tue, 16 Oct 2018 22:43:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BBB1420338E; Tue, 16 Oct 2018 22:43:08 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AE2BB203389; Tue, 16 Oct 2018 22:43:08 +0200 (CEST) Received: from [10.8.68.146] ([10.8.68.146]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9GKh8JR015388; Tue, 16 Oct 2018 22:43:08 +0200 To: Yannis Nikolopoulos , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> From: Alexandre Petrescu Message-ID: <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> Date: Tue, 16 Oct 2018 22:43:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 20:43:14 -0000 Le 16/10/2018 à 14:09, Yannis Nikolopoulos a écrit : > > > On 10/16/18 11:49 AM, Alexandre Petrescu wrote: >> >> >> Le 15/10/2018 à 20:35, Yannis Nikolopoulos a écrit : >>> >>> >>> On 15/10/2018 14:10, Alexandre Petrescu wrote: >>>> If one wants to tempt more users into IPv6 then one has to: >>> that's the point though, we're not looking to tempt more users into >>> IPv6. We're trying to find a viable case against scrapping our >>> IPv6-only efforts >> >> That is also a good idea. >> > > what is? Scrapping our IPv6-only efforts? :) (I have to understand what 'scrapping' means). But it is a good idea to try to make a viable case for your existing IPv6-only efforts. A thread for the case could be: bind a bandwidth notion to the protocol version notion. Plan for 100Tbit/s links that support IPv6. Promiss more bandwidth, that accidentally involves IPv6. Bind it to Ethernet as well because that is a guaranteed success too compared to ATM. Ethernet to the home. Not pppoe, because that reduces bandwidth. (the number 100Tbit/s is made up, but there must exist an equivalent that is fashionable these days). Alex > >> Alex >> >>> > From nobody Tue Oct 16 14:42:43 2018 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 2E5B8130E50 for ; Tue, 16 Oct 2018 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh77EgDpoetQ for ; Tue, 16 Oct 2018 14:42:41 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C1F130E36 for ; Tue, 16 Oct 2018 14:42:40 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9GLZtIc010204; Tue, 16 Oct 2018 17:42:38 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2n5qwv0en4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Oct 2018 17:42:38 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9GLgbdA031815; Tue, 16 Oct 2018 17:42:37 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9GLgT2m031658; Tue, 16 Oct 2018 17:42:29 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 0E1324047B97; Tue, 16 Oct 2018 21:42:29 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30483.vci.att.com (Service) with ESMTPS id F0AD440002AF; Tue, 16 Oct 2018 21:42:28 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.143]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0415.000; Tue, 16 Oct 2018 17:42:28 -0400 From: "STARK, BARBARA H" To: "'Alexandre Petrescu'" , Yannis Nikolopoulos , "v6ops@ietf.org" Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group Thread-Index: AQHUVfmDCQBPy034qUC0gvmNEwK9ZKUGMNUAgAAM5YCAGgHxgIAAD2QAgAAvyoCAAAecgIAAfGwAgADulICAADfygIAAj2OA///LzFA= Date: Tue, 16 Oct 2018 21:42:27 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DEF25AE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> In-Reply-To: <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.251.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=965 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810160180 Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 21:42:42 -0000 DQo+ID4+Pj4gSWYgb25lIHdhbnRzIHRvIHRlbXB0IG1vcmUgdXNlcnMgaW50byBJUHY2IHRoZW4g b25lIGhhcyB0bzoNCj4gPj4+IHRoYXQncyB0aGUgcG9pbnQgdGhvdWdoLCB3ZSdyZSBub3QgbG9v a2luZyB0byB0ZW1wdCBtb3JlIHVzZXJzIGludG8NCj4gPj4+IElQdjYuIFdlJ3JlIHRyeWluZyB0 byBmaW5kIGEgdmlhYmxlIGNhc2UgYWdhaW5zdCBzY3JhcHBpbmcgb3VyDQo+ID4+PiBJUHY2LW9u bHkgZWZmb3J0cw0KPiA+Pg0KPiA+PiBUaGF0IGlzIGFsc28gYSBnb29kIGlkZWEuDQo+ID4NCj4g PiB3aGF0IGlzPyBTY3JhcHBpbmcgb3VyIElQdjYtb25seSBlZmZvcnRzPyA6KQ0KPiANCj4gKEkg aGF2ZSB0byB1bmRlcnN0YW5kIHdoYXQgJ3NjcmFwcGluZycgbWVhbnMpLg0KDQpzY3JhcHBpbmcg PSB0cmFzaGluZyAoZ2V0IHJpZCBvZikNCg0KPiBCdXQgaXQgaXMgYSBnb29kIGlkZWEgdG8gdHJ5 IHRvIG1ha2UgYSB2aWFibGUgY2FzZSBmb3IgeW91ciBleGlzdGluZyBJUHY2LW9ubHkNCj4gZWZm b3J0cy4NCj4gDQo+IEEgdGhyZWFkIGZvciB0aGUgY2FzZSBjb3VsZCBiZTogYmluZCBhIGJhbmR3 aWR0aCBub3Rpb24gdG8gdGhlIHByb3RvY29sDQo+IHZlcnNpb24gbm90aW9uLiAgUGxhbiBmb3Ig MTAwVGJpdC9zIGxpbmtzIHRoYXQgc3VwcG9ydCBJUHY2LiAgUHJvbWlzcyBtb3JlDQo+IGJhbmR3 aWR0aCwgdGhhdCBhY2NpZGVudGFsbHkgaW52b2x2ZXMgSVB2Ni4NCj4gDQo+IEJpbmQgaXQgdG8g RXRoZXJuZXQgYXMgd2VsbCBiZWNhdXNlIHRoYXQgaXMgYSBndWFyYW50ZWVkIHN1Y2Nlc3MgdG9v DQo+IGNvbXBhcmVkIHRvIEFUTS4gIEV0aGVybmV0IHRvIHRoZSBob21lLiAgTm90IHBwcG9lLCBi ZWNhdXNlIHRoYXQgcmVkdWNlcw0KPiBiYW5kd2lkdGguDQo+IA0KPiAodGhlIG51bWJlciAxMDBU Yml0L3MgaXMgbWFkZSB1cCwgYnV0IHRoZXJlIG11c3QgZXhpc3QgYW4gZXF1aXZhbGVudCB0aGF0 IGlzDQo+IGZhc2hpb25hYmxlIHRoZXNlIGRheXMpLg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgYWRk cmVzc2VzIHRoZSBxdWVzdGlvbiAoYXMgSSB1bmRlcnN0YW5kIGl0KS4NCkdpdmVuIGFuIElTUCB3 aXRoIGV4aXN0aW5nLCByZWFzb25hYmx5IHByb2JsZW0tZnJlZSBkdWFsIHN0YWNrIGRlcGxveW1l bnQsIHdoYXQgaW5jZW50aXZlIGlzIHRoZXJlIHRvIG1vdmUgdGhlIElQdjQgZnJvbSBkdWFsIHN0 YWNrIHRvIGJlaW5nIHR1bm5lbGVkIG92ZXIgSVB2Nj8NCkJhcmJhcmENCiANCj4gQWxleA0KPiAN Cj4gPg0KPiA+PiBBbGV4DQo+ID4+DQo+ID4+Pg0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g djZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1E d0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFRx NHZyZm9nJm09TVpYQ0U4YktzMmswd3ZqQ1g4QTAwT296ZHR1OGlzU1psNjRsWjdMNjd6OCZzPUoN Cj4gcVo1ZW9UMnZXbnpoU1BLZURsOVlSX3BDX2w5VHlIZkF5NkJpSXlsR0V3JmU9DQo= From nobody Tue Oct 16 15:36:45 2018 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 65035130E57 for ; Tue, 16 Oct 2018 15:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8pOAn36JB7S for ; Tue, 16 Oct 2018 15:36:41 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58874130E51 for ; Tue, 16 Oct 2018 15:36:41 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id z21-v6so22950823edb.11 for ; Tue, 16 Oct 2018 15:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iG0mjnKJsl0kmTCKpa8/1X+Zxgj11XRay1vv29rXfa4=; b=djfOEDFKLpONFjWPT05B0oElz9LFS9TJ0Xu8cjoYG5+X7fM6GoRAyKfkAYyBL3+nec V1NLUWVdE4JqdIYEtyE58eb2dDnmFQH8In3sNdm93ZeK8hxrsTn2GyEBKYz7cjEWn517 GH7mlFNJsAP0GjLWVAPBrJo31eOlgc0ANk3CihaVvdBGA0Ne15EVcsdGNb1rdh8RduXr HvwhAc0Zf7N4jFnpWEgli7GYl9Mdar2Z1aqc+PdL50qffecFNGtDs/3HsfRxMIerocQv cgSSNiet5tAa63weQp1ocy6RrytzhRjxpIwJE7GjgcF2PMsIBFXnuIuHjqcipGiG3Ros Gd7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iG0mjnKJsl0kmTCKpa8/1X+Zxgj11XRay1vv29rXfa4=; b=ioprF8gzth74e5YTDljXeG0v/GZqCMNcXFgJML7Acm0tm52T/jBA1qb+6sXnuj5Bsq fgpMzjBYkh/J1GHdzoMmnIVUR2nYcU8AE3rReYcH5Hz38FPHAc7jUJyXfk5Fe/RvQFkv 4ZrGTFxEyqhKxV622TOgaVXpJYKCoHp4OaFSNRslfBV6SXEncT+C+B45WcyTSS7/rGVT aK7p6Jwl37mldaf35khQn4VcEwCj1xT9epE4raYChyoiRwCiGP5mDVbWTWWIg6mm+IQZ ZgM/2SXE/3ts/whXuf5Ufj8c8IC30e63Z5gQrjcKkJfgkOmwG07/PRat4pawtPQARuC+ +www== X-Gm-Message-State: ABuFfohr55+ZrYvYpavbq8Q9kE8yZB3h88UsVdPAU9dEkzFDWKHn5Wt+ cObmNtlJwZbs3JEaKwAujDA= X-Google-Smtp-Source: ACcGV63USqLY7MgGrHsOmeU+lwm9R9myCkslbVPoIt5H5WllpEtHrb7lbd2NjQC78dNK/R0xpj1aVQ== X-Received: by 2002:a50:89f1:: with SMTP id h46-v6mr33245010edh.252.1539729399798; Tue, 16 Oct 2018 15:36:39 -0700 (PDT) Received: from 229.66.20.149.in-addr.arpa (229.66.20.149.in-addr.arpa. [149.20.66.229]) by smtp.gmail.com with ESMTPSA id 25-v6sm6870340edu.57.2018.10.16.15.36.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 15:36:38 -0700 (PDT) From: Fred Baker Message-Id: <03FCA9D5-EA86-41A8-B411-2E0DD5456ED0@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D9F3B2FB-B40B-4ABA-956F-27425D95F2FF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 16 Oct 2018 15:36:35 -0700 In-Reply-To: <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> Cc: Yannis Nikolopoulos , v6ops@ietf.org To: Alexandre Petrescu References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 22:36:43 -0000 --Apple-Mail=_D9F3B2FB-B40B-4ABA-956F-27425D95F2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 16, 2018, at 1:43 PM, Alexandre Petrescu = wrote: >=20 > I have to understand what 'scrapping' means https://dictionary.cambridge.org/dictionary/english/scrap --Apple-Mail=_D9F3B2FB-B40B-4ABA-956F-27425D95F2FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvGZ/MACgkQEhdRnd2G P+AFPw/7BA6wFlCdc7DHxTNOBiC4Y2rC0YKc+UgsYRwIlTXfiXLTmfDwHHnBvei8 xrTVAH639Kpp/P8tetSy9HkH+Mjf9pxpjSaAVc6XpozaFLyuWy5VkBR0infyIPF3 wqGMCMxkF8I9htfdffTTyDHQfqRUg3V4MO85rgnQ/MwF0eRYzOR+kJcH+6WdE42O 6Wc6UYKCa6+v3sgIMhKIsLF/Q3rBAqJ75uvUlpLSrYjVBf4x2R1mXmTiwL9bBF6O JhJHUNdu5PS2j9kG6Z2aCqHzQvnItYxcHP/to3e8B2jFSojTQyz2qnvYLo1j+C7k S7Cg/yauqH2BQOrLZBlkY5HwklIe96jdf4YZjwC5ZAp2a8qQqvus/zzjzmy7elU+ ZPXrnqOzl/04o0IVwhNS88Zu8yY/3MykWjCkfOjXiCQFSQpFCiqGUGUVbx78SafU PWvwNgwDNI1918IkPpMXJPkF0cL87IRgjPxyMJAtoGDxEDvqV2MjwHRGkkZ73IY4 FkC378WG8Fgb9UMWL/Q5ZFVmD+3fyGl5iAWi8XaOd0euWQVMD2xDn8dPWyyy7QP5 iZddu7cok9UOmnRDyGa9YRKw6hLSktVfedjq2ZLSDqHzxrey7c149jrWWxRO/MYs ABVIxtXNMjoowZcUO2f1jM/0Yb02wMT8DwCdbK5ykPowxb7ld2A= =AIjO -----END PGP SIGNATURE----- --Apple-Mail=_D9F3B2FB-B40B-4ABA-956F-27425D95F2FF-- From nobody Tue Oct 16 23:48:35 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 585AC12F1A5; Tue, 16 Oct 2018 23:48:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153975891430.9386.3715237806815038718@ietfa.amsl.com> Date: Tue, 16 Oct 2018 23:48:34 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 06:48:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-10.txt Pages : 22 Date : 2018-10-16 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is required in a world where sufficient IPv4 addresses are no longer available for every possible customer/device. However, devices or applications in the customer LANs may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-10 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 16 23:52:57 2018 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 51D7012F1A5 for ; Tue, 16 Oct 2018 23:52:55 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUlWZyrjQMVM for ; Tue, 16 Oct 2018 23:52:52 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999FD130E78 for ; Tue, 16 Oct 2018 23:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539759170; x=1540363970; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=PR+RCF1k IQE8plpEKwE9bey8ZqXFFZu7CxFQzLwCRK4=; b=aC1p/H5I2//H+geXnDmxx6m6 RTsKGiG7UhNpWaq9dgPRAMJ6Eo1qRKMTKFTe+9wEYLrtsmSf9oVhBTIOdUh2amSH Xq3GRxeoRNvZ+oSvooAX7MzwQAGKbUPQUxDA5fH81SvmTIW6vwnE0xRU5yhLoZcQ RNIDkHKvQl+DUMZL13A= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 17 Oct 2018 08:52:50 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 17 Oct 2018 08:52:49 +0200 Received: from [193.0.24.245] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005912135.msg for ; Wed, 17 Oct 2018 08:52:49 +0200 X-MDRemoteIP: 2001:67c:64:42:784a:501f:98f0:5d50 X-MDHelo: [193.0.24.245] X-MDArrival-Date: Wed, 17 Oct 2018 08:52:49 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=18284dc964=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Wed, 17 Oct 2018 08:52:45 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <76D89AFE-8F56-499E-8420-07F180E33CD5@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-10.txt References: <153975891430.9386.3715237806815038718@ietfa.amsl.com> In-Reply-To: <153975891430.9386.3715237806815038718@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 06:52:56 -0000 Hi all, Just a quick comment about this version. The version -09 incorporated editorial changes according to inputs from the= AD review. In that version, to address one of those comments, I used in the abstract a= nd intro "IPv4 public addresses", and Mohamed Boucadair reported that this = is not just about the lack "public" ones, but also private, because in some= networks private ranges are also a trouble, and thus a reason to move to I= Pv6. So just removing "public" is the only correction in this document. Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: mi=C3=A9rcoles, 17 de octubre de 2018, 8:49 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-10.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-10.txt Pages : 22 Date : 2018-10-16 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is required in a world where sufficient IPv4 addresses are no longer available for every possible customer/device. However, devices or applications in the customer LANs may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-10 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-10 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -10 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Oct 17 00:22:12 2018 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 2A566130E7F for ; Wed, 17 Oct 2018 00:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Hp-kkcxJUjM for ; Wed, 17 Oct 2018 00:22:07 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 10CE2129AB8 for ; Wed, 17 Oct 2018 00:22:07 -0700 (PDT) Received: from [212.205.221.32] (loco.otenet.gr [212.205.221.32]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 06E22138100; Wed, 17 Oct 2018 10:22:04 +0300 (EEST) To: "STARK, BARBARA H" , 'Alexandre Petrescu' , "v6ops@ietf.org" References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DEF25AE@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Yannis Nikolopoulos Message-ID: <96ee2307-8d2c-41eb-e7ad-fb1d369cd71c@otenet.gr> Date: Wed, 17 Oct 2018 10:22:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DEF25AE@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 07:22:11 -0000 Hello Barbara and  thank you for your comment, On 10/17/18 12:42 AM, STARK, BARBARA H wrote: >>>>>> If one wants to tempt more users into IPv6 then one has to: >>>>> that's the point though, we're not looking to tempt more users into >>>>> IPv6. We're trying to find a viable case against scrapping our >>>>> IPv6-only efforts >>>> That is also a good idea. >>> what is? Scrapping our IPv6-only efforts? :) >> (I have to understand what 'scrapping' means). > scrapping = trashing (get rid of) > >> But it is a good idea to try to make a viable case for your existing IPv6-only >> efforts. >> >> A thread for the case could be: bind a bandwidth notion to the protocol >> version notion. Plan for 100Tbit/s links that support IPv6. Promiss more >> bandwidth, that accidentally involves IPv6. >> >> Bind it to Ethernet as well because that is a guaranteed success too >> compared to ATM. Ethernet to the home. Not pppoe, because that reduces >> bandwidth. >> >> (the number 100Tbit/s is made up, but there must exist an equivalent that is >> fashionable these days). > I don't think this addresses the question (as I understand it). > Given an ISP with existing, reasonably problem-free dual stack deployment, what incentive is there to move the IPv4 from dual stack to being tunneled over IPv6? > Barbara pretty simple incentive: public IPv4 address exhaustion We're no longer able to provide our users with public IPv4 addresses, we havrn't been for the past 3 years. That is why we're deploying lw4o6 and that's why we have a NAT444 CGN in place until our lw4o6 deployment is problem-free and ready for carrier grade. Unfortunately, our CGN is not that expensive compared to lw4o6 and lw4o6 does not seem to deliver (performance-wise). And (nearly) nobody seems to be deploying IPv4aaS and we're out of arguments towards management regards, Yannis > >> Alex >> >>>> Alex >>>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=LoGzhC- >> 8sc8SY8Tq4vrfog&m=MZXCE8bKs2k0wvjCX8A00Oozdtu8isSZl64lZ7L67z8&s=J >> qZ5eoT2vWnzhSPKeDl9YR_pC_l9TyHfAy6BiIylGEw&e= -- Yannis Nikolopoulos OTE S.A e-mail: yanodd@otenet.gr IP Network Planning & Engineering tel: +302106116293 ---------------------------------------------------------------------------- From nobody Wed Oct 17 00:54:37 2018 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 6630C130E84 for ; Wed, 17 Oct 2018 00:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8scSnCPvhxi for ; Wed, 17 Oct 2018 00:54:33 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92181130DCD for ; Wed, 17 Oct 2018 00:54:32 -0700 (PDT) Received: from [IPv6:2001:738:2c01:24:482c:981e:36c2:6970] ([IPv6:2001:738:2c01:24:482c:981e:36c2:6970]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w9H7sNHq007479 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 17 Oct 2018 09:54:29 +0200 (CEST) (envelope-from lencse@hit.bme.hu) To: "v6ops@ietf.org" References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DEF25AE@GAALPA1MSGUSRBF.ITServices.sbc.com> <96ee2307-8d2c-41eb-e7ad-fb1d369cd71c@otenet.gr> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <76a246c0-c502-a504-4e1e-8e79c45de3fc@hit.bme.hu> Date: Wed, 17 Oct 2018 09:54:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <96ee2307-8d2c-41eb-e7ad-fb1d369cd71c@otenet.gr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=2001:738:2c01:24:482c:981e:36c2:6970; helo=[IPv6:2001:738:2c01:24:482c:981e:36c2:6970]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 07:54:36 -0000 2018.10.17. 9:22 keltezéssel, Yannis Nikolopoulos írta: > > pretty simple incentive: public IPv4 address exhaustion > > We're no longer able to provide our users with public IPv4 addresses, > we havrn't been for the past 3 years. That is why we're deploying > lw4o6 and that's why we have a NAT444 CGN in place until our lw4o6 > deployment is problem-free and ready for carrier grade. Unfortunately, > our CGN is not that expensive compared to lw4o6 and lw4o6 does not > seem to deliver (performance-wise). And (nearly) nobody seems to be > deploying IPv4aaS and we're out of arguments towards management > What about the costs of maintaining a dual stack network? (E.g. IPv4 routing table will grow due to trading with public IPv4 addresses. Management will have to shell out a huge sum of money for memory update or replacement of the routers.) Gábor > > regards, > Yannis > >>> Alex >>> >>>>> Alex >>>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=LFYZ- >>> o9_HUMeMTSQicvjIg&r=LoGzhC- >>> 8sc8SY8Tq4vrfog&m=MZXCE8bKs2k0wvjCX8A00Oozdtu8isSZl64lZ7L67z8&s=J >>> qZ5eoT2vWnzhSPKeDl9YR_pC_l9TyHfAy6BiIylGEw&e= > From nobody Wed Oct 17 00:55:00 2018 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 DD332130E84 for ; Wed, 17 Oct 2018 00:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NETPl0wu_IuJ for ; Wed, 17 Oct 2018 00:54:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D239130E83 for ; Wed, 17 Oct 2018 00:54:50 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CD057B2; Wed, 17 Oct 2018 09:54:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539762887; bh=Kfkwd3QJXI+cMBci/kXstU9qjSF5xcxu7gYBwNVTss0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=zxOLFAeWQ96lvQgNRExBjT/Ovz8mH2kIZkq3J5WBiEqUaUAQnuoG+xy442svwoH9+ E+VjLainSUG/BKD64vT9Rn6Kfl5NSBJOu5Wb2d7YBHBVjRVSrzuVSZHV7pDIqgzgnZ RwLMWDnE4I/8NClOL/bcGhsNfjmef2IGCkhy00zI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CACA6B1; Wed, 17 Oct 2018 09:54:47 +0200 (CEST) Date: Wed, 17 Oct 2018 09:54:47 +0200 (CEST) From: Mikael Abrahamsson To: Yannis Nikolopoulos cc: "v6ops@ietf.org" In-Reply-To: <96ee2307-8d2c-41eb-e7ad-fb1d369cd71c@otenet.gr> Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DEF25AE@GAALPA1MSGUSRBF.ITServices.sbc.com> <96ee2307-8d2c-41eb-e7ad-fb1d369cd71c@otenet.gr> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 07:54:59 -0000 On Wed, 17 Oct 2018, Yannis Nikolopoulos wrote: > (performance-wise). And (nearly) nobody seems to be deploying IPv4aaS > and we're out of arguments towards management Isn't the single NAT44 (port block allocation) an argument here? Or you have very few complaints about the NAT444 solution? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Oct 17 02:47:10 2018 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 31C2412D4EB for ; Wed, 17 Oct 2018 02:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4D0_sYx6b_2 for ; Wed, 17 Oct 2018 02:47:07 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2DD129AB8 for ; Wed, 17 Oct 2018 02:47:07 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id e22-v6so29204847qto.6 for ; Wed, 17 Oct 2018 02:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i3YuWFOVeDEhmWdsU8Mw+dctevmg/91y4EWcTlWwCIo=; b=LqvIERcl4J5H97+rCg61vlaHquqv940KdRH5duJ7JofGMibgNhtmE1/mP0b6ExFfLn o3RvXP41uCTAzL/Dla/N+VVZVEosQDlZUn7l600FcrFM7rsJoOzUnA0b9QH5X4bUHgJK 9wBshhFzOmyt881KlnpTb/+3tsaPF7lsKoWa0+x8Nb0kuz4X6s+s2VXbcIx841FXlQFJ T/TvBm/QZ5LfiFF6l56zNa3E3qJ1Drung4D5iuRy1cy8UXNCR2oXoOvU2Gv4PmAt0BII 05dKlbj0XF+fgqjNRNwYvmK+QlKK7K1Nsrw2ZLs0SmXnDU4Va7qz+ivyNRDKkJHq0Vy+ 66aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i3YuWFOVeDEhmWdsU8Mw+dctevmg/91y4EWcTlWwCIo=; b=Zwcocf6ftwZ+7U+G9WBIKQi4TFu0Iu/L3/Wbo3eaTVXhFxDjapP6EbiIaF1fJJQILL hOyydKIP4o9NsodVJdWoOfRzWwMJDbs99vXZvXiKPCKf1YQy1F+4JtNHN73Mj87seqN9 RjHYgLI14r+D1BuL8UHmeutcijRWmBJiLOM97j32px6WWdgSCZqdXKJFa1B5QN0SNwVK Hy/vnf48Y8SUgdNuWo7uWAQYBhPVcExF+tc94yJkmC9BIXE3xRKzB3qldt7xKKPGP5Tp hMC2Xya2BFY/Fr4oF0bggAi54IPJh9babEYVyGknHTlgpeP3MJJuTkVOzjHDjdbKDjuO vLeQ== X-Gm-Message-State: ABuFfohGzFAFRwAutYBRZ/AObQtLFkh9tssaRHSZrAOpyYz/Ie4MdFvb MDXumKwSOOty8NGLCVNbV8jrEP1PE96KzyATLy0= X-Google-Smtp-Source: ACcGV61V544VOLZgmWxsrqRNSiuPG0lhtvUvYOZcxfrg8RX1GY9PeJ7yOzCXaRM17e7nKbcEEY8Lp8tS3PgLHdKSzec= X-Received: by 2002:ac8:3173:: with SMTP id h48-v6mr24720452qtb.125.1539769626367; Wed, 17 Oct 2018 02:47:06 -0700 (PDT) MIME-Version: 1.0 References: <153919621638.5900.18199747860735930931.idtracker@ietfa.amsl.com> <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> In-Reply-To: <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> From: Jen Linkova Date: Wed, 17 Oct 2018 20:46:54 +1100 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 09:47:09 -0000 On Thu, Oct 11, 2018 at 5:33 AM JORDI PALET MARTINEZ wrote: > We have worked in an integrated version of two documents: > > draft-v6ops-byrne-dnssecaaaa > draft-palet-sunset4-ipv6-ready-dns-00 > > The new document is now: > > https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?in= clude_text=3D1 The new document starts with: "This document defines the timing for implementing a worldwide IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the global IPv6-only deployment." So you are suggesting that DNS operators have to do some work (in quite short timeframe) to facilitate something they might not even care about...Not sure it would work. Then there is a section 7 (Implementation Timeline) which look a bit unrealistic. (I have to confess I wish we had a magic wand to make it happen...). If I let my imagination run wild...let's say a miracle has happened and steps 1-3 are done. Obviously *just* adding AAAA RR for A-only names has nothing to do with enabling IPv6 for a service. The service needs to have IPv6 connectivity (which might not even be available in the specific location) it needs to be tested etc. Adding AAAA w/o doing all of that would just negatively impact user experience. What would happen if a imaginary website cutekittens.example.net which hosts popular videos of kittens (and koals) suddenly gets AAAA RR in DNS w/o IPv6 being properly enabled for it? Or even worse, the webservice would respond to TCP handshake but would not be able to server users over IPv6? Well, I'm sure 99.9% of level1 techsupport engineers would tell the unhappy customers "disable IPv6 on your device and it would solve your issue". I'm not sure it's want we want. Also, how exactly are you suggesting to enforce the step 4? Last but not least: "If there is a failure at the deadline in complying with those requirements, the relevant NS, MUST be temporarily suspended until there is a subsequent successful verification." So an NS for cutekittens.example.net got suspended (whatever it means). So the server would become unreachable? How could it be fixed/get IPv6 enab= led? "MUST" in RFCs are (usually) for a reason. If you do not follow MUST smth bad would happen. This draft has a lot of MUST which (IMHO) could not be enforced. To sum up, I found draft-v6ops-byrne-dnssecaaaa be more useful and realistic. It explains why if you want to use DNSSEC for your zone, you should consider enable IPv6. > =EF=BB=BF-----Mensaje original----- > De: > Fecha: mi=C3=A9rcoles, 10 de octubre de 2018, 20:30 > Para: Jordi Palet , Jordi Palet Martinez = , Cameron Byrne , Cameron Byrne > Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec= -00.txt > > > A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt > has been successfully submitted by Jordi Palet Martinez and posted to= the > IETF repository. > > Name: draft-bp-v6ops-ipv6-ready-dns-dnssec > Revision: 00 > Title: IPv6-Ready DNS/DNSSSEC Infrastructure > Document date: 2018-10-10 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-bp-v6ops-i= pv6-ready-dns-dnssec-00.txt > Status: https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-= ready-dns-dnssec/ > Htmlized: https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready= -dns-dnssec-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bp-v6ops-= ipv6-ready-dns-dnssec > > > Abstract: > This document defines the timing for implementing a worldwide > IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate t= he > global IPv6-only deployment. > > A key issue for this, is the need for a global support of DNSSEC a= nd > DNS64, which in some scenarios do not work well together. This > document states that any DNSSEC signed resources records should > include a native IPv6 resource record as the most complete and > expedient path to solve any deployment conflict with DNS64 and DNS= SEC > > > > > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > ********************************************** > 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 c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Wed Oct 17 02:57:22 2018 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 2341E130EB2 for ; Wed, 17 Oct 2018 02:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53Hts_lvtUwp for ; Wed, 17 Oct 2018 02:57:13 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1D130EBD for ; Wed, 17 Oct 2018 02:57:13 -0700 (PDT) Received: from [212.205.221.32] (loco.otenet.gr [212.205.221.32]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 678CD13803D; Wed, 17 Oct 2018 12:57:11 +0300 (EEST) To: Mikael Abrahamsson Cc: "v6ops@ietf.org" References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <1004b8cf-fa5e-068d-10a1-ced3f11f60da@gmail.com> <0bdd6fd8-fcda-b5ee-5736-4e70bac4dd15@gmail.com> <3a9e77eb-588f-1a7a-4b39-b409cd0c22f6@otenet.gr> <19938342-2eaf-7bc7-8c27-18ea6f6da2af@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DEF25AE@GAALPA1MSGUSRBF.ITServices.sbc.com> <96ee2307-8d2c-41eb-e7ad-fb1d369cd71c@otenet.gr> From: Yannis Nikolopoulos Message-ID: <7f2fe246-a904-7bd0-0a22-86717ad1fcbd@otenet.gr> Date: Wed, 17 Oct 2018 12:57:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 09:57:21 -0000 Hi, On 10/17/18 10:54 AM, Mikael Abrahamsson wrote: > On Wed, 17 Oct 2018, Yannis Nikolopoulos wrote: > >> (performance-wise). And (nearly) nobody seems to be deploying IPv4aaS >> and we're out of arguments towards management > > Isn't the single NAT44 (port block allocation) an argument here? Or > you have very few complaints about the NAT444 solution? > we have complaints, but the situation is manageable. We just roll them back to the dual-stack service -- Yannis Nikolopoulos OTE S.A e-mail: yanodd@otenet.gr IP Network Planning & Engineering tel: +302106116293 ---------------------------------------------------------------------------- From nobody Wed Oct 17 11:23:01 2018 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 AE595130E01 for ; Wed, 17 Oct 2018 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0cPuXt9QjbT for ; Wed, 17 Oct 2018 11:22:58 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AD5130DC7 for ; Wed, 17 Oct 2018 11:22:57 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id m18-v6so20574166lfl.11 for ; Wed, 17 Oct 2018 11:22:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GcR0QIwBbxDgcj4PCCQV9+fJaesDJIreNIeuZpSX5lk=; b=CL1BDzQNrJxVRSGPWgtkE6ixS07Uw1N+BG2f/SiPjCRirizanogEHoTjk8+SYn/uZJ Urv7UBJS91aCX58STk6E2X9/pwHVmWan8mEifJGohcAM6SdvGdXQl+8sXuw9I1gp+YZS welkpehGZwZmyFAQVowQe9dCUStmnmZlPlSaBgVJN6hE3Rdt8VjdKKPwFykiLeq1LY8X FG2gx3euPUP7aICryKNy7ybNV+qTjeBKO8kcDcu3rdtdev05eFhNAkWgWfGwa4TgJea2 wdkJS2qsSM+AG0KvW3wc88qgqn7zsiFloo5G6khooJbg5jlbBTGlekCUzLHrT0pVwnLs PsWg== X-Gm-Message-State: ABuFfoj1Oini0ZP5yUHafxw04xG1lor5auZr/brLsK7deev8S/UC5uI+ fGsAFUcQ4NPQVQtJIERpFdguKMBJc6PAtAtjGM41tcP3 X-Google-Smtp-Source: ACcGV60KfHImK4+MgKsHEjPMtJ20NtfskTc+0eMI4ZyU2GxppFgdFsmkwHUibG6UiHLMmw9H9RGs7Y52Yj6uKE2Ys4k= X-Received: by 2002:a19:d58b:: with SMTP id m133-v6mr16450861lfg.105.1539800575217; Wed, 17 Oct 2018 11:22:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 17 Oct 2018 11:22:43 -0700 Message-ID: To: Jen Linkova Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f9cb4057870c205" Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 18:23:00 -0000 --0000000000004f9cb4057870c205 Content-Type: text/plain; charset="UTF-8" At Tue, 16 Oct 2018 21:28:37 +1100, Jen Linkova wrote: > > - In section 2 (or somewhere else like in the introduction) I think > > it's fair to point out that the RA approach has a drawback of > > configuring local routers of each end subnet (where ordinary clients > > reside). It's unlike the advertisement of on-link/addrconf prefix > > for which the router should inherently know and be configured with > > anyway, so it looks to me to be a tradeoff between the router > > configuration overhead and the advantages described in this section. > > Well...Some vendors still require the prefix to be explicitly > configured under router-advertisement section to be included in PIOs > (just configuring /64 on the interface is not enough) so SLAAC does > require some explicit configuration anyway (and RDNSS and timers etc). > On the other hand, some vendor allow the configuration to be inherited > so in real life it will be one-line config to enable this option on > multiple interfaces...So, to be honest, I do not see much difference > between this option and any other SLAAC parameter... I'm afraid we're talking about different issues...maybe I wasn't clear enough in the above comment, so let me rephrase it: assume if you have 100 leaf subnets, each of which has an RA-advertising router. If you want to deploy draft-pref64folks-6man-ra-pref64, you'll need to configure those 100 routers separately; if the prefix is changed, you'll need to update the config on these 100 routers. On the other hand, if you use a DNS-based approach (RFC7050) you'll only have to configure/update the DNS(64) server (there may be multiple instances of such server and you may have to configure each of them by hand, but I assume the number of such instances is generally much smaller than the number of leaf subnets). This is different from other SLAAC parameters such as PIO, since the information is different for different subnets and each router needs to be configured separately anyway. To be clear, I'm not making this comment to say that ra-pref64 is inferior to existing ways. I just thought there's some tradeoff between different approaches and it's fair to explain both pros and cons. > > Similarly, we might want to note that this case in Section 5 should > > be (very?) atypical even if not forbidden: > > > > o The pref64 option presents in a single RA more than once; > > It would be necessary for renumbering from one pref64 to another. > The old pref64 needs to be advertised with zero Lifetime, while the > new pref64 would have non-zero lifetime. Ah, okay. Perhaps that was just my bad reading, but the intent wasn't clear to me from the draft's context. In fact, it looks like the other two bullets talk about the case of multiple usable prefixes (right?) Also, if I understand it correctly, "the recommendations given in Section 3 of [RFC7050]" also discusses the case of multiple usable prefixes: When multiple Pref64 were discovered via RA Pref64 Option [...], host behaviour with regards to synthesizing IPv6 addresses from IPv4 addresses SHOULD follow the recommendations given in Section 3 of [RFC7050], limited to the NAT64 prefixes that have non-zero lifetime.. Only the above one bullet should mean the renumbering case since the pref64 option should only support at most one usable prefix. And then the above paragraph still looks awkward: since "this option specifies exactly one NAT64 prefix for all IPv4 destinations" (from Section 3) I'd expect we only have at most one prefix that has non-zero lifetime. And then there's no point of applying the above "recommendation" since it's "limited to the NAT64 prefixes that have non-zero lifetime" (btw there's a redundant period here). Perhaps I'm still misunderstanding something fundamental, but I personally see some need for editorial clarification. > > - Section 3: these two don't read very consistently: > > This option may appear more than once in a Router Advertisement. > > [...] > > This option specifies exactly one NAT64 prefix for all IPv4 > > destinations. > > Sorry, I'm not sure I understand why. For example, a PIO contains > exactly one prefix. However Prefix Information Option may appear more > than once in a Router Advertisement. > The same here. > > > If it intends to specify *exactly one* prefix, what's the point of > > having more than one options (unless these options include exactly > > the same prefix, which also makes no sense). I guess this is rather > > an editorial matter than a protocol problem - perhaps in this > > context we just don't have to say the "may appear more than once" > > sentence. > > See the renumbering example above. See above. Now I see how these two can coexist, but at least to me it's not so obvious for fresh readers just from this text. More explanation to clarify the intent would help. -- JINMEI, Tatuya --0000000000004f9cb4057870c205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Tue, 16 Oct 2018 21:28:37 +1100,
Je= n Linkova <furry13@gmail.com>= ; wrote:

> > - In section 2 (or somewhere else like in the int= roduction) I think
> >=C2=A0=C2=A0 it's fair to point out that= the RA approach has a drawback of
> >=C2=A0=C2=A0 configuring loc= al routers of each end subnet (where ordinary clients
> >=C2=A0=C2= =A0 reside).=C2=A0 It's unlike the advertisement of on-link/addrconf pr= efix
> >=C2=A0=C2=A0 for which the router should inherently know a= nd be configured with
> >=C2=A0=C2=A0 anyway, so it looks to me to= be a tradeoff between the router
> >=C2=A0=C2=A0 configuration ov= erhead and the advantages described in this section.
>
> Well.= ..Some vendors still require the prefix to be explicitly
> configured= under router-advertisement section to be included in PIOs
> (just co= nfiguring /64 on the interface is not enough) so SLAAC does
> require= some explicit configuration anyway (and RDNSS and timers etc).
> On = the other hand, some vendor allow the configuration to be inherited
>= so in real life it will be one-line config to enable this option on
>= ; multiple interfaces...So, to be honest, I do not see much difference
&= gt; between this option and any other SLAAC parameter...

I'm afr= aid we're talking about different issues...maybe I wasn't clear
= enough in the above comment, so let me rephrase it: assume if you have
1= 00 leaf subnets, each of which has an RA-advertising router.=C2=A0 If youwant to deploy draft-pref64folks-6man-ra-pref64, you'll need to
co= nfigure those 100 routers separately; if the prefix is changed,
you'= ll need to update the config on these 100 routers.=C2=A0 On the other
ha= nd, if you use a DNS-based approach (RFC7050) you'll only have to
co= nfigure/update the DNS(64) server (there may be multiple instances
of su= ch server and you may have to configure each of them by hand, but
I assu= me the number of such instances is generally much smaller than
the numbe= r of leaf subnets).

This is different from other SLAAC parameters su= ch as PIO, since the
information is different for different subnets and = each router needs
to be configured separately anyway.

To be clear= , I'm not making this comment to say that ra-pref64 is
inferior to e= xisting ways.=C2=A0 I just thought there's some tradeoff
between dif= ferent approaches and it's fair to explain both pros and
cons.
> >=C2=A0=C2=A0 Similarly, we might want to note that this case in = Section 5 should
> >=C2=A0=C2=A0 be (very?) atypical even if not f= orbidden:
> >
> >=C2=A0=C2=A0=C2=A0 o=C2=A0 The pref64 op= tion presents in a single RA more than once;
>
> It would be n= ecessary for renumbering from one pref64 to another.
> The old pref64= needs to be advertised with zero Lifetime, while the
> new pref64 wo= uld have non-zero lifetime.

Ah, okay.=C2=A0 Perhaps that was just my= bad reading, but the intent wasn't
clear to me from the draft's= context.=C2=A0 In fact, it looks like the
other two bullets talk about = the case of multiple usable prefixes
(right?)=C2=A0 Also, if I understan= d it correctly, "the recommendations
given in Section 3 of [RFC7050= ]" also discusses the case of multiple
usable prefixes:

=C2= =A0=C2=A0 When multiple Pref64 were discovered via RA Pref64 Option [...],<= br>=C2=A0=C2=A0 host behaviour with regards to synthesizing IPv6 addresses = from IPv4
=C2=A0=C2=A0 addresses SHOULD follow the recommendations given= in Section 3 of
=C2=A0=C2=A0 [RFC7050], limited to the NAT64 prefixes t= hat have non-zero
=C2=A0=C2=A0 lifetime..

Only the above one bull= et should mean the renumbering case since the
pref64 option should only = support at most one usable prefix.=C2=A0 And then
the above paragraph st= ill looks awkward: since "this option specifies
exactly one NAT64 p= refix for all IPv4 destinations" (from Section 3)
I'd expect we= only have at most one prefix that has non-zero
lifetime.=C2=A0 And then= there's no point of applying the above
"recommendation" s= ince it's "limited to the NAT64 prefixes that have
non-zero lif= etime" (btw there's a redundant period here).

Perhaps I'= ;m still misunderstanding something fundamental, but I
personally see so= me need for editorial clarification.

> > - Section 3: these tw= o don't read very consistently:
> >=C2=A0=C2=A0=C2=A0 This opt= ion may appear more than once in a Router Advertisement.
> > [...]=
> >=C2=A0=C2=A0=C2=A0 This option specifies exactly one NAT64 pre= fix for all IPv4
> >=C2=A0=C2=A0=C2=A0 destinations.
>
&= gt; Sorry, I'm not sure I understand why. For example, a PIO contains> exactly one prefix. However Prefix Information Option may appear mor= e
> than once in a Router Advertisement.
> The same here.
&g= t;
> >=C2=A0=C2=A0 If it intends to specify *exactly one* prefix,= what's the point of
> >=C2=A0=C2=A0 having more than one opti= ons (unless these options include exactly
> >=C2=A0=C2=A0 the same= prefix, which also makes no sense).=C2=A0 I guess this is rather
> &= gt;=C2=A0=C2=A0 an editorial matter than a protocol problem - perhaps in th= is
> >=C2=A0=C2=A0 context we just don't have to say the "= ;may appear more than once"
> >=C2=A0=C2=A0 sentence.
>=
> See the renumbering example above.

See above.=C2=A0 Now I = see how these two can coexist, but at least to me
it's not so obviou= s for fresh readers just from this text.=C2=A0 More
explanation to clari= fy the intent would help.

--
JINMEI, Tatuya
--0000000000004f9cb4057870c205-- From nobody Wed Oct 17 12:13:29 2018 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 3DE38130DC7 for ; Wed, 17 Oct 2018 12:13:27 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqGkgj-48Oss for ; Wed, 17 Oct 2018 12:13:24 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6104F1286E3 for ; Wed, 17 Oct 2018 12:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539803601; x=1540408401; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=7jINHdgWVTtNMKjOxwYPtKfiHmST6olc8ywMlgcs5dM=; b=ble4rkjNoi3Tv km1NF4ocAZhnxSz5ioWqo1qAuZG/W7fYRaH28bcJ1nmUAPK0KnQLY0q9hI5uryTL d4KCR4pUHDphTvD8I7+P4vlcgt2rLCqIwCD58qOdD3xKN+lWtWbHjruE9PsW0++6 gVhwiI2tqzaGbDhkuk2/AFjVr8abc8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 17 Oct 2018 21:13:21 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 17 Oct 2018 21:13:20 +0200 Received: from [10.239.106.110] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005913011.msg for ; Wed, 17 Oct 2018 21:13:19 +0200 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.239.106.110] X-MDArrival-Date: Wed, 17 Oct 2018 21:13:19 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=18284dc964=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Wed, 17 Oct 2018 21:13:14 +0200 From: JORDI PALET MARTINEZ To: Jen Linkova CC: V6 Ops List Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt References: <153919621638.5900.18199747860735930931.idtracker@ietfa.amsl.com> <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 19:13:27 -0000 Hi Jen, Responding below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Jen Linkova Fecha: mi=C3=A9rcoles, 17 de octubre de 2018, 11:47 Para: CC: V6 Ops List Asunto: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-= dns-dnssec-00.txt On Thu, Oct 11, 2018 at 5:33 AM JORDI PALET MARTINEZ wrote: > We have worked in an integrated version of two documents: > > draft-v6ops-byrne-dnssecaaaa > draft-palet-sunset4-ipv6-ready-dns-00 > > The new document is now: > > https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec= /?include_text=3D1 =20 The new document starts with: "This document defines the timing for implementing a worldwide IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the global IPv6-only deployment." =20 So you are suggesting that DNS operators have to do some work (in quite short timeframe) to facilitate something they might not even care about...Not sure it would work. They should care about providing a good service, right? A good service today is not just IPv4-only. =20 Then there is a section 7 (Implementation Timeline) which look a bit unrealistic. (I have to confess I wish we had a magic wand to make it happen...). If I let my imagination run wild...let's say a miracle has happened and steps 1-3 are done. Obviously *just* adding AAAA RR for A-only names has nothing to do with enabling IPv6 for a service. Clearly, we need to rephrase it. We meant not just the RR part, but of cour= se, having the IPv6 connectivity. The service needs to have IPv6 connectivity (which might not even be available in the specific location) it needs to be tested etc. Adding IPv6 free tunnels are available, in case, I doubt, you can't setup a tunnel= to your upstream provider or alternatively to any of their upstreams. I've= been there, several times, in the most strange and remote locations. AAAA w/o doing all of that would just negatively impact user experience. What would happen if a imaginary website cutekittens.example.net which hosts popular videos of kittens (and koals) suddenly gets AAAA RR in DNS w/o IPv6 being properly enabled for it? Or even worse, the webservice would respond to TCP handshake but would not be able to server users over IPv6? Well, I'm sure 99.9% of level1 techsupport engineers would tell the unhappy customers "disable IPv6 on your device and it would solve your issue". I'm not sure it's want we want. =20 Also, how exactly are you suggesting to enforce the step 4? =20 Last but not least: "If there is a failure at the deadline in complying with those requirements, the relevant NS, MUST be temporarily suspended until there is a subsequent successful verification." So an NS for cutekittens.example.net got suspended (whatever it means). So the server would become unreachable? How could it be fixed/get IPv6 = enabled? We are calling ICANN to take actions and enforce them to the registrars. IC= ANN has something already in TLD contracts. Is time to enforce it. =20 "MUST" in RFCs are (usually) for a reason. If you do not follow MUST smth bad would happen. This draft has a lot of MUST which (IMHO) could not be enforced. I think trying is much better than just complaining and not doing something= . Clearly IETF liaison with ICANN need to take actions here. Believe it or not, there are still many DNS "operators" that have no idea a= bout IPv6, and a call for action should enforce them to do something. =20 To sum up, I found draft-v6ops-byrne-dnssecaaaa be more useful and realistic. It explains why if you want to use DNSSEC for your zone, you should consider enable IPv6. =20 > =EF=BB=BF-----Mensaje original----- > De: > Fecha: mi=C3=A9rcoles, 10 de octubre de 2018, 20:30 > Para: Jordi Palet , Jordi Palet Marti= nez , Cameron Byrne , Cameron Byrne > Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dn= ssec-00.txt > > > A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt > has been successfully submitted by Jordi Palet Martinez and poste= d to the > IETF repository. > > Name: draft-bp-v6ops-ipv6-ready-dns-dnssec > Revision: 00 > Title: IPv6-Ready DNS/DNSSSEC Infrastructure > Document date: 2018-10-10 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-bp-v6o= ps-ipv6-ready-dns-dnssec-00.txt > Status: https://datatracker.ietf.org/doc/draft-bp-v6ops-i= pv6-ready-dns-dnssec/ > Htmlized: https://tools.ietf.org/html/draft-bp-v6ops-ipv6-r= eady-dns-dnssec-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bp-v6= ops-ipv6-ready-dns-dnssec > > > Abstract: > This document defines the timing for implementing a worldwide > IPv6-Ready DNS and DNSSEC infrastructure, in order to facilita= te the > global IPv6-only deployment. > > A key issue for this, is the need for a global support of DNSS= EC and > DNS64, which in some scenarios do not work well together. Thi= s > document states that any DNSSEC signed resources records shoul= d > include a native IPv6 resource record as the most complete and > expedient path to solve any deployment conflict with DNS64 and= DNSSEC > > > > > Please note that it may take a couple of minutes from the time of= submission > until the htmlized version and diff are available at tools.ietf.o= rg. > > The IETF Secretariat > > > > > > ********************************************** > 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 confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 --=20 SY, Jen Linkova aka Furry =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Oct 17 12:29:23 2018 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 6CA0B130D7A for ; Wed, 17 Oct 2018 12:29:22 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpdn5Xg8VA2G for ; Wed, 17 Oct 2018 12:29:18 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53949130EED for ; Wed, 17 Oct 2018 12:29:18 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id l14-v6so17015726edq.0 for ; Wed, 17 Oct 2018 12:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CXUFliJnGrThd8T7cB0/LTDBw0pzi/21/95DEdMriHc=; b=d+zFJByFJR4q2XMhygbR4ph1oz/iX3qJHvJFXuyu4xkFIxUtMIrSg9fKD9a3s96vi/ nhFGIFxa5FuQqpV0VllzS8vdA3p2pjrXjU5hQu8mpYuzg3P8pgg729KvT/Zc2r///Q7P F4KxUIbLnJwOZgPJlorySpqnYoN8t/qt3xg14VNw7qsGqsDZdfzbT1hWhXnyQzwCn+Q2 CHmvHbmxYFdy5dgWqpgYFvjkYAzObHzdgZ8zDha7jeyT9YgWACaCg9d9xwOcEQm4TfQu A3uCUUrQLzdt90nPWNsEQRiPUOqqXN200ZcTkw9Yzj+tk0+YXPvNYKIPOxkDHWuG95dE teIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CXUFliJnGrThd8T7cB0/LTDBw0pzi/21/95DEdMriHc=; b=pO9vB6AvHTChN8lNUiZvSQxSBNkD/vS+CdExcTqB5PQd7DzjklaaPfOPeNf3xpZkgf RQv5wVeMLfwxnzoP0mbme4u0yNy8E7IEzMjnXxa8AWzu9lMuufgKxATMl/38/DhDxJap HbogmGRQ9kRAHFSBM7YJG8MEjp7uKJe3HXHROFXtvFzc57LAkKf/mDfs8MtlmeqYqRse UqT+Gug3Wgq1xmj01mtnw1Gdh2rXAvdCIFI/yBB4OoaLIpcEP0Qdr90KmYSfFYpW+aBI tdUjQZmXyKWEBvNATMhoBlRynyHen7H1OGC3576aQzKX2jCGFnfObdLlhIQGyPdWs1+p 1/lA== X-Gm-Message-State: ABuFfoiGsjVIX4b4X88oe6K18rdymbKdXhAsabcU8MliWpapt+WlsLdS dkCBvWEZDlzcxNBJeQbqLJjqP4pr X-Google-Smtp-Source: ACcGV61EJJbQsjIXnxfpn78uMzcssbjoMQsndPczD5/8s+gnBrCEKfrovqWXB1n3FHeMspGRoz0yww== X-Received: by 2002:a17:906:4e03:: with SMTP id z3-v6mr26677801eju.187.1539804556691; Wed, 17 Oct 2018 12:29:16 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1004? ([2600:8802:5600:1546::1004]) by smtp.gmail.com with ESMTPSA id q12-v6sm8013787edd.35.2018.10.17.12.29.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Oct 2018 12:29:15 -0700 (PDT) From: Fred Baker Message-Id: <735F51BC-5AE4-4C42-8E99-A61CC2D83B31@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_20182D35-C295-4C47-A720-CA456871DCD8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 17 Oct 2018 12:29:11 -0700 In-Reply-To: Cc: Jen Linkova , v6ops@ietf.org To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 19:29:22 -0000 --Apple-Mail=_20182D35-C295-4C47-A720-CA456871DCD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I'm not sure we disagree on your point. However, there is also the issue = of shadowing services. For example, in my home I use an OpenDNS = resolver; it's built into my router and I said "yes". If my ISP were = implementing 464XLAT (they're not to my knowledge, but imagine) and = wanted me to use a prefix of their choosing, OpenDNS could either have = no record or give me something different. So the DNS approach has a = fairly fundamental flaw. What might be interesting on routers that want you to configure it = manually would be a "use RFC 7050" configuration, in which the router = got the record from DNS and advertised it in its RA. > On Oct 17, 2018, at 11:22 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Tue, 16 Oct 2018 21:28:37 +1100, > Jen Linkova wrote: >=20 > > > - In section 2 (or somewhere else like in the introduction) I = think > > > it's fair to point out that the RA approach has a drawback of > > > configuring local routers of each end subnet (where ordinary = clients > > > reside). It's unlike the advertisement of on-link/addrconf = prefix > > > for which the router should inherently know and be configured = with > > > anyway, so it looks to me to be a tradeoff between the router > > > configuration overhead and the advantages described in this = section. > > > > Well....Some vendors still require the prefix to be explicitly > > configured under router-advertisement section to be included in PIOs > > (just configuring /64 on the interface is not enough) so SLAAC does > > require some explicit configuration anyway (and RDNSS and timers = etc). > > On the other hand, some vendor allow the configuration to be = inherited > > so in real life it will be one-line config to enable this option on > > multiple interfaces...So, to be honest, I do not see much difference > > between this option and any other SLAAC parameter... >=20 > I'm afraid we're talking about different issues...maybe I wasn't clear > enough in the above comment, so let me rephrase it: assume if you have > 100 leaf subnets, each of which has an RA-advertising router. If you > want to deploy draft-pref64folks-6man-ra-pref64, you'll need to > configure those 100 routers separately; if the prefix is changed, > you'll need to update the config on these 100 routers. On the other > hand, if you use a DNS-based approach (RFC7050) you'll only have to > configure/update the DNS(64) server (there may be multiple instances > of such server and you may have to configure each of them by hand, but > I assume the number of such instances is generally much smaller than > the number of leaf subnets). >=20 > This is different from other SLAAC parameters such as PIO, since the > information is different for different subnets and each router needs > to be configured separately anyway. >=20 > To be clear, I'm not making this comment to say that ra-pref64 is > inferior to existing ways. I just thought there's some tradeoff > between different approaches and it's fair to explain both pros and > cons. >=20 > > > Similarly, we might want to note that this case in Section 5 = should > > > be (very?) atypical even if not forbidden: > > > > > > o The pref64 option presents in a single RA more than once; > > > > It would be necessary for renumbering from one pref64 to another. > > The old pref64 needs to be advertised with zero Lifetime, while the > > new pref64 would have non-zero lifetime. >=20 > Ah, okay. Perhaps that was just my bad reading, but the intent wasn't > clear to me from the draft's context. In fact, it looks like the > other two bullets talk about the case of multiple usable prefixes > (right?) Also, if I understand it correctly, "the recommendations > given in Section 3 of [RFC7050]" also discusses the case of multiple > usable prefixes: >=20 > When multiple Pref64 were discovered via RA Pref64 Option [...], > host behaviour with regards to synthesizing IPv6 addresses from = IPv4 > addresses SHOULD follow the recommendations given in Section 3 of > [RFC7050], limited to the NAT64 prefixes that have non-zero > lifetime.. >=20 > Only the above one bullet should mean the renumbering case since the > pref64 option should only support at most one usable prefix. And then > the above paragraph still looks awkward: since "this option specifies > exactly one NAT64 prefix for all IPv4 destinations" (from Section 3) > I'd expect we only have at most one prefix that has non-zero > lifetime. And then there's no point of applying the above > "recommendation" since it's "limited to the NAT64 prefixes that have > non-zero lifetime" (btw there's a redundant period here). >=20 > Perhaps I'm still misunderstanding something fundamental, but I > personally see some need for editorial clarification. >=20 > > > - Section 3: these two don't read very consistently: > > > This option may appear more than once in a Router = Advertisement. > > > [...] > > > This option specifies exactly one NAT64 prefix for all IPv4 > > > destinations. > > > > Sorry, I'm not sure I understand why. For example, a PIO contains > > exactly one prefix. However Prefix Information Option may appear = more > > than once in a Router Advertisement. > > The same here. > > > > > If it intends to specify *exactly one* prefix, what's the point = of > > > having more than one options (unless these options include = exactly > > > the same prefix, which also makes no sense). I guess this is = rather > > > an editorial matter than a protocol problem - perhaps in this > > > context we just don't have to say the "may appear more than = once" > > > sentence. > > > > See the renumbering example above. >=20 > See above. Now I see how these two can coexist, but at least to me > it's not so obvious for fresh readers just from this text. More > explanation to clarify the intent would help. >=20 > -- > JINMEI, Tatuya > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_20182D35-C295-4C47-A720-CA456871DCD8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvHjYcACgkQEhdRnd2G P+BB7w//YsMOVNNJp5mEUB8RljLCI4zv1k0nfdueb11hBR25CyLwSGbVEXXGiSC6 i8T7bCg+thS7Bjbpm/R2LXojoiX8jBBlgddKxSzrunzgHcd/2GgJbNjSCLsKLGyr VeKKNCgHYLqKJCOSMLxv7691b9gyA0dDzWktPJus4nDZ3zyGqCDZN0xu28GvmNkY hgMXFo7sYe46ewGCuqF4HqDN2fIIYfss+Ih48VXlI3/8sva04IpKaG0ikt1Z9R+1 68+Az+R1pGdIbCgJm3Q9f+nzIW5dk01MOtY/e2xAyEhKLLwWVkhsJ/nmKg+sWl1K sq+Q6Z7+PX85luSo1I4akS9Q4y0bY1sR5SlTelZnzaaxnrSDGq3E9uQQTa37sSnm KTGERHgJdQRvX7gdABYQvkT0U4OXyf3UldkPp5eVkkj3lntREEFTl6NtgSA94bQI 6ssSFBAxgsJQbr8AydU+b0PtVPZtOzupkj2AjadN5zp5yvKI468KpMWI1TacIFrw y7Jow8TSdBamFWtD0r/s3IWXe3jQnmJmx0ybb6pWCztYMER7sj0ftFZwIiEJl5BT T9oQFY6nbyT4PdEdJL8UtegZ13iZ44lUNcLg9xK9RaRBT71CNGSZJUtG9o2RUy/h mdfzv0jH8KhdtX6xMRd6mqMfp3T9q2ULV3/65+7nNmVPE4OfL2k= =XXSZ -----END PGP SIGNATURE----- --Apple-Mail=_20182D35-C295-4C47-A720-CA456871DCD8-- From nobody Thu Oct 18 00:09:10 2018 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 2F553128766 for ; Thu, 18 Oct 2018 00:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjdJlmCqWrKn for ; Thu, 18 Oct 2018 00:09:05 -0700 (PDT) Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) by ietfa.amsl.com (Postfix) with ESMTP id 95AEF1292F1 for ; Thu, 18 Oct 2018 00:09:05 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id w9I791NO004152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 18 Oct 2018 03:09:01 -0400 Received: (qmail 8760 invoked by uid 0); 18 Oct 2018 07:09:01 -0000 X-TCPREMOTEIP: 213.222.5.218 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.20.21.88?) (lee@asgard.org@213.222.5.218) by 0 with ESMTPA; 18 Oct 2018 07:09:01 -0000 To: Yannis Nikolopoulos , JORDI PALET MARTINEZ , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> From: Lee Howard Message-ID: Date: Thu, 18 Oct 2018 09:08:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 07:09:08 -0000 Chairs, I'd be very interested in a lw4over6 experience report from Yannis. Yannis, I'm interested in hearing more about what isn't working well, either on-line or directly. Lee On 10/15/2018 12:57 PM, Yannis Nikolopoulos wrote: > > In our case, we did not invest in CGN. We invested in preparing for > IPv6 early, and so we did. When IPv4 exhaustion hit us, we did not > decide to invest in either CGN or buying IPv4 addresses. Again , we > invested in IPv6 (lw4o6). In the mean time between deploying lw4o6, we > had to mitigate the issue, in a quick n dirty manner... that's when > CGNcame into the picture. Some years later, we have a lot of CGN users > and not so many in IPv6-only (lw4o6).  It just seems that, IPv6-only > technologies (lw4o6 in our case) were not so straighforward to deploy > and more importantly, not so cheap (performance-wise) either. Maybe > the "stateless card" has been overplayed or exaggerated at the very > least. > >> >> Regards, >> Jordi >> >> -----Mensaje original----- >> De: v6ops en nombre de Yannis Nikolopoulos >> >> Fecha: lunes, 15 de octubre de 2018, 8:57 >> Para: Lee Howard , >> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our >> working group >> >>           On 9/28/18 8:47 PM, Lee Howard wrote: >>      > Agreed, for now different people are choosing different >> mechanisms, >>      > and there isn't yet a clear winner. >>           I've had this in my mailbox for days/weeks now. I just >> wanted to write >>      "are they? are they really?" . I don't see people choosing >> mechanisms, >>      people are not choosing mechanisms.People are deploying CGN en >> masse, >>      people are buying IPv4 addresses under the table or people are >> just not >>      touched by the IPv4 exhaustion. That is what people are doing, >> at least >>      most of them. And I wonder: what went wrong? 3-4 years ago, I was >>      willing to bet that by 2017, fixed ISPs would've switched to MAP or >>      lw4o6. How wrong was I... I feel very disappointed . >>           We switched to dual-stack about 10 years ago. 4 years ago, >> we started >>      considering our IPv6-only service options and we've been running >> lw4o6 >>      for the past 2 years. Our lw4o6 deployment is pretty small (40k >> users >>      out of 1.5M) still because of various issues: CPE is a pain, >> DHCP is a >>      pain, even lwaftr is a pain (more info can be provided on >> request). Most >>      importantly, we do not see the economy at scale here. CGN >> (NAT444) is >>      strangely cheaper and troubles-free. On top of that, we're about >> to test >>      it with IPv6 support. >>           I'm called to present a case to mgmt and I despise the fact >> that I've >>      ran out of arguments for supporting an IPv6-only residential >> service: >>      the only one I have left is the trouble-free native IPv6 path, >> but that >>      doesn't really hold up since the percentage of complaining users >> is so >>      small. So, it comes down to that: we're about to have our lw4o6 >>      deployment shut and our CGN is almost consuming half our userbase >>      already. The future is bleak, indeed. I've even considered >> 464xlat for >>      everyone (since we're also a mobile carrier, where dual-stack >> and CGN >>      are deployed) >>           thanks for listening, >>      Yannis >>           _______________________________________________ >>      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 confidential. The information is intended to be for the exclusive >> use of the individual(s) named above and further non-explicilty >> authorized disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, is >> strictly prohibited and will be considered a criminal offense. If you >> are not the intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, even if >> partially, including attached files, is strictly prohibited, will be >> considered a criminal offense, so you must reply to the original >> sender to inform about this communication and delete it. >> >> >> >> > From nobody Thu Oct 18 00:26:27 2018 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 5FCC7129C6B for ; Thu, 18 Oct 2018 00:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2HuGAEoJGPU for ; Thu, 18 Oct 2018 00:26:24 -0700 (PDT) Received: from atl4mhob15.registeredsite.com (atl4mhob15.registeredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 619F7128766 for ; Thu, 18 Oct 2018 00:26:24 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob15.registeredsite.com (8.14.4/8.14.4) with ESMTP id w9I7QLnq000605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 18 Oct 2018 03:26:21 -0400 Received: (qmail 11867 invoked by uid 0); 18 Oct 2018 07:26:20 -0000 X-TCPREMOTEIP: 213.222.5.218 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.20.21.88?) (lee@asgard.org@213.222.5.218) by 0 with ESMTPA; 18 Oct 2018 07:26:20 -0000 To: Yannis Nikolopoulos , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> From: Lee Howard Message-ID: <8954aacd-6bc9-ee7c-3f50-b6907fc96585@asgard.org> Date: Thu, 18 Oct 2018 09:26:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 07:26:26 -0000 On 10/15/2018 08:57 AM, Yannis Nikolopoulos wrote: > > On 9/28/18 8:47 PM, Lee Howard wrote: >> Agreed, for now different people are choosing different mechanisms, >> and there isn't yet a clear winner. > > I've had this in my mailbox for days/weeks now. I just wanted to write > "are they? are they really?" . I don't see people choosing mechanisms, > people are not choosing mechanisms. I think this has been posted here before. It's crowd-sourced, so it has all the strengths and weaknesses of that. https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 So, yes, people are using transition mechanisms. I know of two other large fixed-line ISPs who are less than a year from deploying. > People are deploying CGN en masse, people are buying IPv4 addresses > under the table or people are just not touched by the IPv4 exhaustion. > That is what people are doing, at least most of them. And I wonder: > what went wrong? 3-4 years ago, I was willing to bet that by 2017, > fixed ISPs would've switched to MAP or lw4o6. How wrong was I... I > feel very disappointed . > > We switched to dual-stack about 10 years ago. 4 years ago, we started > considering our IPv6-only service options and we've been running lw4o6 > for the past 2 years. Our lw4o6 deployment is pretty small (40k users > out of 1.5M) still because of various issues: CPE is a pain, DHCP is a > pain, even lwaftr is a pain (more info can be provided on request). > Most importantly, we do not see the economy at scale here. CGN > (NAT444) is strangely cheaper and troubles-free. On top of that, we're > about to test it with IPv6 support. > > I'm called to present a case to mgmt and I despise the fact that I've > ran out of arguments for supporting an IPv6-only residential service: > the only one I have left is the trouble-free native IPv6 path, but > that doesn't really hold up since the percentage of complaining users > is so small. So, it comes down to that: we're about to have our lw4o6 > deployment shut and our CGN is almost consuming half our userbase > already. The future is bleak, indeed. I've even considered 464xlat for > everyone (since we're also a mobile carrier, where dual-stack and CGN > are deployed) I'd be interested in how many flows and bits use CGN vs. IPv6, and how that's been changing over the years. For management, that will point to how small a box (whether NAT44, lw4over6, or NAT64) is needed for translation. They would surely love to know when they can stop spending money on translators. There's been some promising growth in Greece recently: https://www.vyncke.org/ipv6status/project.php?metric=w&country=gr In my experience, trouble calls are expensive, partly because sometimes instead of a trouble call you get a customer cancellation. That's probably a cost you can present to management. You can also note that in at least one experiment, access to IPv6-enabled websites is 9ms faster than to IPv6-incapable web sites. https://stats.labs.apnic.net/v6perf/GR That might be worth mentioning to the large IPv6-incapable web sites, too. So I wonder if your case to management is partly that you guessed too early (as we all did with IPv4 depletion, and as some of us often do with IPv6 deployment). The question is not how much money has already been spent, it's whether, looking forward 2-5 years, your money is better spent on CGN or IPv4aaS. Lee > > thanks for listening, > Yannis From nobody Thu Oct 18 00:33:44 2018 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 2E283128766 for ; Thu, 18 Oct 2018 00:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3XUs8zSHcSQ for ; Thu, 18 Oct 2018 00:33:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AF01292F1 for ; Thu, 18 Oct 2018 00:33:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 24E98B0; Thu, 18 Oct 2018 09:33:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539848018; bh=OlAYV+MFXwfw4FUx9ByUJEL323pO+aS338DvkIsyviE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=w05/6oqZKjC1u9lw8iL//TGj+k/njoYLIycJGDVxAwvBz22JImv3VYWfT6ZGSrE6w Z4h7Iu8PR0jpSYbpDj+3S/E36LQRZ6OS2dojehqq1V3I5BDz6YU6JTAvtB6/iOOaoa hRAJQFMl8NOdif9yIUR5bOoSeaoojq9ZSxcvprqQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1F4BFAF; Thu, 18 Oct 2018 09:33:38 +0200 (CEST) Date: Thu, 18 Oct 2018 09:33:38 +0200 (CEST) From: Mikael Abrahamsson To: Lee Howard cc: Yannis Nikolopoulos , v6ops@ietf.org In-Reply-To: Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 07:33:43 -0000 On Thu, 18 Oct 2018, Lee Howard wrote: > Yannis, I'm interested in hearing more about what isn't working well, > either on-line or directly. >From my experience, the biggest problem is the same as Yannis is presenting, it's all about HGW support for these things. The major vendors support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's problematic. One of the major SoC vendors had a packet accelerator problem with LW4o6 in that the accelerator "forgot" to NAT44 the packets when it took over the flow. I spent 9 months getting nowhere until finally I managed the use threats to get through to some engineering people and explain my case. They fixed the problem 2 weeks later. They said they didn't first understand what I wanted, and basically had asked the wrong question internally and then probably got a "err, no, not justified by the business case". But now I have a fully working, fully accelerated LW4o6-supporting gigabit ethernet (can actually do that) HGW for LW4o6 use-case on active-ethernet. Someone else might want to do this over PPPoE, so then you might be in trouble again because the accelelator might not support the LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it because in my deployment we don't do PPPoE. So the problems aren't really technical, they're all business related. The vendors are doing pushback on all these different versions of doing pretty much the same thing, that all require development resources. So let me list some of the common use-cases the IETF/ISPs basically is asking them to support. 6to4 ds.lite LW4o6 MAP(-e and -t) 6RD all of the above over: PPPoE over DSL, PON and ethernet PPPoA over DSL Native Ethernet .... plus probably something else I forgot. That's tens of different combinations for doing what looks to be almost the same thing. Some others also expect them to have multiple VLANs on WAN, because that's how the operator likes to deply their IPTV and VoIP service. The linux kernel does all of the above, but the packet accelerators typically in these kinds of devices do not support all of it. There are lots of different platforms, and all customers have whole departments that are penny-pinching price on each device when doing procurement. Things are improving as the business ecosystem is moving to more common operating systems and fewer platforms, but it's still an issue, and it's going to be an issue for a long time. The vendors don't typically jump on whatever new stuff the IETF came up with last month, I've heard some who say "we typically wait 2-3 years until we consider implementing an RFC to see if it actually gets some support". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 18 00:45:34 2018 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 0D31512F1A5 for ; Thu, 18 Oct 2018 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dr_UHQv5XpnE for ; Thu, 18 Oct 2018 00:45:30 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BE9129C6B for ; Thu, 18 Oct 2018 00:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539848725; x=1540453525; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=3u6h5l2wU9AH2FiyXzRIbfHf3urAjyjb2IsEWaxseXo=; b=a8G66NZw8HWBK 8uowIPHtzuu11o7MM4wvTfF5mrOPblsnIvbn2dh5s//NrcJ9ftv0eeb4a/KneL2x 5jeiS14BjqyZKRNphAUbggSe/8WzaZfDIPbejTKOoQ+G6otRTtFGqFUHLeLVg72r WeYYLjD5MXf8vCkwUa5wudljAs61D8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Oct 2018 09:45:25 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Oct 2018 09:45:24 +0200 Received: from [193.0.26.61] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005913553.msg for ; Thu, 18 Oct 2018 09:45:23 +0200 X-MDRemoteIP: 2001:67c:64:42:99a3:da6d:83a4:b624 X-MDHelo: [193.0.26.61] X-MDArrival-Date: Thu, 18 Oct 2018 09:45:23 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1829bff37a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Thu, 18 Oct 2018 09:45:19 +0200 From: JORDI PALET MARTINEZ To: Mikael Abrahamsson , Lee Howard CC: Message-ID: <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 07:45:33 -0000 I guess you're forgetting the CLAT, which is the simpler one to implement a= s part of the packet accelerator. All what you mention is the reason I started the work on draft-palet-v6ops-= transition-ipv4aas, which unfortunately take much longer than expected. We need to point the SoC vendors, not just the CE vendors, to this document= . Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Fecha: jueves, 18 de octubre de 2018, 9:34 Para: Lee Howard CC: Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup On Thu, 18 Oct 2018, Lee Howard wrote: =20 > Yannis, I'm interested in hearing more about what isn't working well,= =20 > either on-line or directly. =20 >From my experience, the biggest problem is the same as Yannis is=20 presenting, it's all about HGW support for these things. The major vend= ors=20 support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's=20 problematic. =20 One of the major SoC vendors had a packet accelerator problem with LW4o= 6=20 in that the accelerator "forgot" to NAT44 the packets when it took over= =20 the flow. I spent 9 months getting nowhere until finally I managed the = use=20 threats to get through to some engineering people and explain my case.= =20 They fixed the problem 2 weeks later. They said they didn't first=20 understand what I wanted, and basically had asked the wrong question=20 internally and then probably got a "err, no, not justified by the busin= ess=20 case". =20 But now I have a fully working, fully accelerated LW4o6-supporting giga= bit=20 ethernet (can actually do that) HGW for LW4o6 use-case on active-ethern= et. =20 Someone else might want to do this over PPPoE, so then you might be in= =20 trouble again because the accelelator might not support the=20 LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it beca= use=20 in my deployment we don't do PPPoE. =20 So the problems aren't really technical, they're all business related. = The=20 vendors are doing pushback on all these different versions of doing pre= tty=20 much the same thing, that all require development resources. =20 So let me list some of the common use-cases the IETF/ISPs basically is= =20 asking them to support. =20 6to4 ds.lite LW4o6 MAP(-e and -t) 6RD =20 all of the above over: =20 PPPoE over DSL, PON and ethernet PPPoA over DSL Native Ethernet =20 ..... plus probably something else I forgot. That's tens of different= =20 combinations for doing what looks to be almost the same thing. Some oth= ers=20 also expect them to have multiple VLANs on WAN, because that's how the= =20 operator likes to deply their IPTV and VoIP service. =20 The linux kernel does all of the above, but the packet accelerators=20 typically in these kinds of devices do not support all of it. There are= =20 lots of different platforms, and all customers have whole departments t= hat=20 are penny-pinching price on each device when doing procurement. =20 Things are improving as the business ecosystem is moving to more common= =20 operating systems and fewer platforms, but it's still an issue, and it'= s=20 going to be an issue for a long time. =20 The vendors don't typically jump on whatever new stuff the IETF came up= =20 with last month, I've heard some who say "we typically wait 2-3 years= =20 until we consider implementing an RFC to see if it actually gets some= =20 support". =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Oct 18 01:10:25 2018 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 19D67130E4D for ; Thu, 18 Oct 2018 01:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnudfggaignm for ; Thu, 18 Oct 2018 01:10:21 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB89812D4E7 for ; Thu, 18 Oct 2018 01:10:21 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 91784FECC063; Thu, 18 Oct 2018 08:10:20 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 1C98676574A; Thu, 18 Oct 2018 10:10:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> Date: Thu, 18 Oct 2018 10:10:16 +0200 Cc: Mikael Abrahamsson , Lee Howard , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 08:10:24 -0000 Jordi, > I guess you're forgetting the CLAT, which is the simpler one to = implement as part of the packet accelerator. Can you substantiate that? By what metric. If you look at number of lines of code, amount of state, or even = provisioning complexity you are wrong. Ole >=20 > All what you mention is the reason I started the work on = draft-palet-v6ops-transition-ipv4aas, which unfortunately take much = longer than expected. >=20 > We need to point the SoC vendors, not just the CE vendors, to this = document. >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Mikael Abrahamsson = > Organizaci=C3=B3n: People's Front Against WWW > Fecha: jueves, 18 de octubre de 2018, 9:34 > Para: Lee Howard > CC: > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >=20 > On Thu, 18 Oct 2018, Lee Howard wrote: >=20 >> Yannis, I'm interested in hearing more about what isn't working well,=20= >> either on-line or directly. >=20 >> =46rom my experience, the biggest problem is the same as Yannis is=20 > presenting, it's all about HGW support for these things. The major = vendors=20 > support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's=20= > problematic. >=20 > One of the major SoC vendors had a packet accelerator problem with = LW4o6=20 > in that the accelerator "forgot" to NAT44 the packets when it took = over=20 > the flow. I spent 9 months getting nowhere until finally I managed = the use=20 > threats to get through to some engineering people and explain my = case.=20 > They fixed the problem 2 weeks later. They said they didn't first=20= > understand what I wanted, and basically had asked the wrong = question=20 > internally and then probably got a "err, no, not justified by the = business=20 > case". >=20 > But now I have a fully working, fully accelerated LW4o6-supporting = gigabit=20 > ethernet (can actually do that) HGW for LW4o6 use-case on = active-ethernet. >=20 > Someone else might want to do this over PPPoE, so then you might be = in=20 > trouble again because the accelelator might not support the=20 > LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it = because=20 > in my deployment we don't do PPPoE. >=20 > So the problems aren't really technical, they're all business = related. The=20 > vendors are doing pushback on all these different versions of doing = pretty=20 > much the same thing, that all require development resources. >=20 > So let me list some of the common use-cases the IETF/ISPs basically = is=20 > asking them to support. >=20 > 6to4 > ds.lite > LW4o6 > MAP(-e and -t) > 6RD >=20 > all of the above over: >=20 > PPPoE over DSL, PON and ethernet > PPPoA over DSL > Native Ethernet >=20 > ..... plus probably something else I forgot. That's tens of = different=20 > combinations for doing what looks to be almost the same thing. Some = others=20 > also expect them to have multiple VLANs on WAN, because that's how = the=20 > operator likes to deply their IPTV and VoIP service. >=20 > The linux kernel does all of the above, but the packet accelerators=20= > typically in these kinds of devices do not support all of it. There = are=20 > lots of different platforms, and all customers have whole = departments that=20 > are penny-pinching price on each device when doing procurement. >=20 > Things are improving as the business ecosystem is moving to more = common=20 > operating systems and fewer platforms, but it's still an issue, and = it's=20 > going to be an issue for a long time. >=20 > The vendors don't typically jump on whatever new stuff the IETF = came up=20 > with last month, I've heard some who say "we typically wait 2-3 = years=20 > until we consider implementing an RFC to see if it actually gets = some=20 > support". >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 18 01:22:17 2018 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 35CB31292F1 for ; Thu, 18 Oct 2018 01:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giMCiulxT-QH for ; Thu, 18 Oct 2018 01:22:13 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6EB128CF3 for ; Thu, 18 Oct 2018 01:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539850930; x=1540455730; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=H/yoc6H1I2orP2vhfcUQ9bSky6DKpKYPuxtMfvu02TE=; b=wLSdXgL105EpM U+cR8VZBoZC3RznD65gjQbczBLIaUokHeIHMhbfpxqZ39wK8e2Qvig3ZdElZ6pIm aGf9Id97KasBFTr0scjk2XNmlpEfmhA8CZhpwbwOyqIAOVeEOKYJxHIx61564Prk OaV6Q2v77IPKls+jBVooGqrF+OYrP8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Oct 2018 10:22:10 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Oct 2018 10:22:10 +0200 Received: from [193.0.26.61] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005913587.msg for ; Thu, 18 Oct 2018 10:22:09 +0200 X-MDRemoteIP: 2001:67c:64:42:99a3:da6d:83a4:b624 X-MDHelo: [193.0.26.61] X-MDArrival-Date: Thu, 18 Oct 2018 10:22:09 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1829bff37a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Thu, 18 Oct 2018 10:22:05 +0200 From: JORDI PALET MARTINEZ To: Ole Troan CC: Mikael Abrahamsson , Lee Howard , Message-ID: <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> In-Reply-To: <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 08:22:16 -0000 Hi Ole, I've posted some time ago a comparison in terms of code size in OpenWRT com= paring all the IPv4aaS, not going to repeat that, just for short, CLAT code= size in OpenWRT is 4 Kbytes: https://openwrt.org/packages/pkgdata/464xlat I can see the code simplicity at: https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat= .sh If you remove the comment lines, is less than 100 very simple code lines. Of course, there are other implementations, all can be googled for, such as= Jool, Android, VPP and the one from Tore Anderson. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Ole Troan Fecha: jueves, 18 de octubre de 2018, 10:10 Para: JORDI PALET MARTINEZ CC: Mikael Abrahamsson , Lee Howard , Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup Jordi, =20 =20 > I guess you're forgetting the CLAT, which is the simpler one to imple= ment as part of the packet accelerator. =20 Can you substantiate that? By what metric. If you look at number of lines of code, amount of state, or even provis= ioning complexity you are wrong. =20 Ole =20 =20 >=20 > All what you mention is the reason I started the work on draft-palet-= v6ops-transition-ipv4aas, which unfortunately take much longer than expecte= d. >=20 > We need to point the SoC vendors, not just the CE vendors, to this do= cument. >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Mikael Abrahamsson > Organizaci=C3=B3n: People's Front Against WWW > Fecha: jueves, 18 de octubre de 2018, 9:34 > Para: Lee Howard > CC: > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our wor= king group >=20 > On Thu, 18 Oct 2018, Lee Howard wrote: >=20 >> Yannis, I'm interested in hearing more about what isn't working well= ,=20 >> either on-line or directly. >=20 >> From my experience, the biggest problem is the same as Yannis is=20 > presenting, it's all about HGW support for these things. The major= vendors=20 > support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's= =20 > problematic. >=20 > One of the major SoC vendors had a packet accelerator problem with= LW4o6=20 > in that the accelerator "forgot" to NAT44 the packets when it took= over=20 > the flow. I spent 9 months getting nowhere until finally I managed= the use=20 > threats to get through to some engineering people and explain my c= ase.=20 > They fixed the problem 2 weeks later. They said they didn't first= =20 > understand what I wanted, and basically had asked the wrong questi= on=20 > internally and then probably got a "err, no, not justified by the = business=20 > case". >=20 > But now I have a fully working, fully accelerated LW4o6-supporting= gigabit=20 > ethernet (can actually do that) HGW for LW4o6 use-case on active-e= thernet. >=20 > Someone else might want to do this over PPPoE, so then you might b= e in=20 > trouble again because the accelelator might not support the=20 > LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it= because=20 > in my deployment we don't do PPPoE. >=20 > So the problems aren't really technical, they're all business rela= ted. The=20 > vendors are doing pushback on all these different versions of doin= g pretty=20 > much the same thing, that all require development resources. >=20 > So let me list some of the common use-cases the IETF/ISPs basicall= y is=20 > asking them to support. >=20 > 6to4 > ds.lite > LW4o6 > MAP(-e and -t) > 6RD >=20 > all of the above over: >=20 > PPPoE over DSL, PON and ethernet > PPPoA over DSL > Native Ethernet >=20 > ..... plus probably something else I forgot. That's tens of differ= ent=20 > combinations for doing what looks to be almost the same thing. Som= e others=20 > also expect them to have multiple VLANs on WAN, because that's how= the=20 > operator likes to deply their IPTV and VoIP service. >=20 > The linux kernel does all of the above, but the packet accelerator= s=20 > typically in these kinds of devices do not support all of it. Ther= e are=20 > lots of different platforms, and all customers have whole departme= nts that=20 > are penny-pinching price on each device when doing procurement. >=20 > Things are improving as the business ecosystem is moving to more c= ommon=20 > operating systems and fewer platforms, but it's still an issue, an= d it's=20 > going to be an issue for a long time. >=20 > The vendors don't typically jump on whatever new stuff the IETF ca= me up=20 > with last month, I've heard some who say "we typically wait 2-3 ye= ars=20 > until we consider implementing an RFC to see if it actually gets s= ome=20 > support". >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Oct 18 01:37:37 2018 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 6982B12D4E7 for ; Thu, 18 Oct 2018 01:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvnle1mjciue for ; Thu, 18 Oct 2018 01:37:32 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3761292F1 for ; Thu, 18 Oct 2018 01:37:32 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id A4321FECC077; Thu, 18 Oct 2018 08:37:31 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 621DB7660EF; Thu, 18 Oct 2018 10:37:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> Date: Thu, 18 Oct 2018 10:37:29 +0200 Cc: Mikael Abrahamsson , Lee Howard , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 08:37:36 -0000 Jordi, So the metric you use to justify your claim is code size? > I've posted some time ago a comparison in terms of code size in = OpenWRT comparing all the IPv4aaS, not going to repeat that, just for = short, CLAT code size in OpenWRT is 4 Kbytes: = https://openwrt.org/packages/pkgdata/464xlat >=20 > I can see the code simplicity at: >=20 > = https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xla= t.sh >=20 > If you remove the comment lines, is less than 100 very simple code = lines. >=20 > Of course, there are other implementations, all can be googled for, = such as Jool, Android, VPP and the one from Tore Anderson. But if your claim had been correct, then the other mechanisms would have = had more code lines right? And you do need to include the whole packet path. And provisioning. Either you substantiate your claim, or you stop making it. I would = suggest the latter would save both you, me and the list some time. Ole > =EF=BB=BF-----Mensaje original----- > De: Ole Troan > Fecha: jueves, 18 de octubre de 2018, 10:10 > Para: JORDI PALET MARTINEZ > CC: Mikael Abrahamsson , Lee Howard = , > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >=20 > Jordi, >=20 >=20 >> I guess you're forgetting the CLAT, which is the simpler one to = implement as part of the packet accelerator. >=20 > Can you substantiate that? By what metric. > If you look at number of lines of code, amount of state, or even = provisioning complexity you are wrong. >=20 > Ole >=20 >=20 >>=20 >> All what you mention is the reason I started the work on = draft-palet-v6ops-transition-ipv4aas, which unfortunately take much = longer than expected. >>=20 >> We need to point the SoC vendors, not just the CE vendors, to this = document. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >> De: v6ops en nombre de Mikael Abrahamsson = >> Organizaci=C3=B3n: People's Front Against WWW >> Fecha: jueves, 18 de octubre de 2018, 9:34 >> Para: Lee Howard >> CC: >> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >>=20 >> On Thu, 18 Oct 2018, Lee Howard wrote: >>=20 >>> Yannis, I'm interested in hearing more about what isn't working = well,=20 >>> either on-line or directly. >>=20 >>> =46rom my experience, the biggest problem is the same as Yannis is=20= >> presenting, it's all about HGW support for these things. The major = vendors=20 >> support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's=20= >> problematic. >>=20 >> One of the major SoC vendors had a packet accelerator problem with = LW4o6=20 >> in that the accelerator "forgot" to NAT44 the packets when it took = over=20 >> the flow. I spent 9 months getting nowhere until finally I managed = the use=20 >> threats to get through to some engineering people and explain my = case.=20 >> They fixed the problem 2 weeks later. They said they didn't first=20 >> understand what I wanted, and basically had asked the wrong question=20= >> internally and then probably got a "err, no, not justified by the = business=20 >> case". >>=20 >> But now I have a fully working, fully accelerated LW4o6-supporting = gigabit=20 >> ethernet (can actually do that) HGW for LW4o6 use-case on = active-ethernet. >>=20 >> Someone else might want to do this over PPPoE, so then you might be = in=20 >> trouble again because the accelelator might not support the=20 >> LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it = because=20 >> in my deployment we don't do PPPoE. >>=20 >> So the problems aren't really technical, they're all business = related. The=20 >> vendors are doing pushback on all these different versions of doing = pretty=20 >> much the same thing, that all require development resources. >>=20 >> So let me list some of the common use-cases the IETF/ISPs basically = is=20 >> asking them to support. >>=20 >> 6to4 >> ds.lite >> LW4o6 >> MAP(-e and -t) >> 6RD >>=20 >> all of the above over: >>=20 >> PPPoE over DSL, PON and ethernet >> PPPoA over DSL >> Native Ethernet >>=20 >> ..... plus probably something else I forgot. That's tens of = different=20 >> combinations for doing what looks to be almost the same thing. Some = others=20 >> also expect them to have multiple VLANs on WAN, because that's how = the=20 >> operator likes to deply their IPTV and VoIP service. >>=20 >> The linux kernel does all of the above, but the packet accelerators=20= >> typically in these kinds of devices do not support all of it. There = are=20 >> lots of different platforms, and all customers have whole = departments that=20 >> are penny-pinching price on each device when doing procurement. >>=20 >> Things are improving as the business ecosystem is moving to more = common=20 >> operating systems and fewer platforms, but it's still an issue, and = it's=20 >> going to be an issue for a long time. >>=20 >> The vendors don't typically jump on whatever new stuff the IETF came = up=20 >> with last month, I've heard some who say "we typically wait 2-3 = years=20 >> until we consider implementing an RFC to see if it actually gets = some=20 >> support". >>=20 >> --=20 >> Mikael Abrahamsson email: swmike@swm.pp.se >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 From nobody Thu Oct 18 01:59:22 2018 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 2B1E012D4EC for ; Thu, 18 Oct 2018 01:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj1vO58Mu_Nj for ; Thu, 18 Oct 2018 01:59:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5B5128CF3 for ; Thu, 18 Oct 2018 01:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539853155; x=1540457955; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=aMIYzqD66ZAx+oaqMgc26CKaZC4HHI0CsgkF12l6Q1M=; b=UTCpnODfsXDQq JcnNhfxI8PxVd6/ORe8QfMWBNHk6sbhiMP9Ig03W94eNzU7bhxkuuWrmiKsaDYG8 g5nHP2OPQ5bMf9zajIMthvkjGjSMmNokfAiUXJorrrs6gxTs+8C+FesMNVYXHJsv 8yt5DGhUUJ81wyycr4sot82j4tIABw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Oct 2018 10:59:15 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Oct 2018 10:59:15 +0200 Received: from [193.0.26.61] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005913617.msg for ; Thu, 18 Oct 2018 10:59:14 +0200 X-MDRemoteIP: 2001:67c:64:42:ade1:9400:5800:2cad X-MDHelo: [193.0.26.61] X-MDArrival-Date: Thu, 18 Oct 2018 10:59:14 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1829bff37a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Thu, 18 Oct 2018 10:59:12 +0200 From: JORDI PALET MARTINEZ To: Ole Troan CC: Mikael Abrahamsson , Lee Howard , Message-ID: <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> In-Reply-To: <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 08:59:20 -0000 Ole, I stated clearly CLAT not the complete 464XLAT. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Ole Troan Fecha: jueves, 18 de octubre de 2018, 10:37 Para: JORDI PALET MARTINEZ CC: Mikael Abrahamsson , Lee Howard , Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup Jordi, =20 So the metric you use to justify your claim is code size? =20 > I've posted some time ago a comparison in terms of code size in OpenW= RT comparing all the IPv4aaS, not going to repeat that, just for short, CLA= T code size in OpenWRT is 4 Kbytes: https://openwrt.org/packages/pkgdata/46= 4xlat >=20 > I can see the code simplicity at: >=20 > https://github.com/openwrt-routing/packages/blob/master/nat46/files/4= 64xlat.sh >=20 > If you remove the comment lines, is less than 100 very simple code li= nes. >=20 > Of course, there are other implementations, all can be googled for, s= uch as Jool, Android, VPP and the one from Tore Anderson. =20 But if your claim had been correct, then the other mechanisms would hav= e had more code lines right? And you do need to include the whole packet path. And provisioning. =20 Either you substantiate your claim, or you stop making it. I would sugg= est the latter would save both you, me and the list some time. =20 Ole =20 =20 > =EF=BB=BF-----Mensaje original----- > De: Ole Troan > Fecha: jueves, 18 de octubre de 2018, 10:10 > Para: JORDI PALET MARTINEZ > CC: Mikael Abrahamsson , Lee Howard , > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our wor= king group >=20 > Jordi, >=20 >=20 >> I guess you're forgetting the CLAT, which is the simpler one to impl= ement as part of the packet accelerator. >=20 > Can you substantiate that? By what metric. > If you look at number of lines of code, amount of state, or even pr= ovisioning complexity you are wrong. >=20 > Ole >=20 >=20 >>=20 >> All what you mention is the reason I started the work on draft-palet= -v6ops-transition-ipv4aas, which unfortunately take much longer than expect= ed. >>=20 >> We need to point the SoC vendors, not just the CE vendors, to this d= ocument. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >> De: v6ops en nombre de Mikael Abrahamsson <= swmike@swm.pp.se> >> Organizaci=C3=B3n: People's Front Against WWW >> Fecha: jueves, 18 de octubre de 2018, 9:34 >> Para: Lee Howard >> CC: >> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our wo= rking group >>=20 >> On Thu, 18 Oct 2018, Lee Howard wrote: >>=20 >>> Yannis, I'm interested in hearing more about what isn't working wel= l,=20 >>> either on-line or directly. >>=20 >>> From my experience, the biggest problem is the same as Yannis is=20 >> presenting, it's all about HGW support for these things. The major = vendors=20 >> support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's= =20 >> problematic. >>=20 >> One of the major SoC vendors had a packet accelerator problem with = LW4o6=20 >> in that the accelerator "forgot" to NAT44 the packets when it took = over=20 >> the flow. I spent 9 months getting nowhere until finally I managed = the use=20 >> threats to get through to some engineering people and explain my ca= se.=20 >> They fixed the problem 2 weeks later. They said they didn't first= =20 >> understand what I wanted, and basically had asked the wrong questio= n=20 >> internally and then probably got a "err, no, not justified by the b= usiness=20 >> case". >>=20 >> But now I have a fully working, fully accelerated LW4o6-supporting = gigabit=20 >> ethernet (can actually do that) HGW for LW4o6 use-case on active-et= hernet. >>=20 >> Someone else might want to do this over PPPoE, so then you might be= in=20 >> trouble again because the accelelator might not support the=20 >> LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it = because=20 >> in my deployment we don't do PPPoE. >>=20 >> So the problems aren't really technical, they're all business relat= ed. The=20 >> vendors are doing pushback on all these different versions of doing= pretty=20 >> much the same thing, that all require development resources. >>=20 >> So let me list some of the common use-cases the IETF/ISPs basically= is=20 >> asking them to support. >>=20 >> 6to4 >> ds.lite >> LW4o6 >> MAP(-e and -t) >> 6RD >>=20 >> all of the above over: >>=20 >> PPPoE over DSL, PON and ethernet >> PPPoA over DSL >> Native Ethernet >>=20 >> ..... plus probably something else I forgot. That's tens of differe= nt=20 >> combinations for doing what looks to be almost the same thing. Some= others=20 >> also expect them to have multiple VLANs on WAN, because that's how = the=20 >> operator likes to deply their IPTV and VoIP service. >>=20 >> The linux kernel does all of the above, but the packet accelerators= =20 >> typically in these kinds of devices do not support all of it. There= are=20 >> lots of different platforms, and all customers have whole departmen= ts that=20 >> are penny-pinching price on each device when doing procurement. >>=20 >> Things are improving as the business ecosystem is moving to more co= mmon=20 >> operating systems and fewer platforms, but it's still an issue, and= it's=20 >> going to be an issue for a long time. >>=20 >> The vendors don't typically jump on whatever new stuff the IETF cam= e up=20 >> with last month, I've heard some who say "we typically wait 2-3 yea= rs=20 >> until we consider implementing an RFC to see if it actually gets so= me=20 >> support". >>=20 >> --=20 >> Mikael Abrahamsson email: swmike@swm.pp.se >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged= or confidential. The information is intended to be for the exclusive use o= f the individual(s) named above and further non-explicilty authorized discl= osure, copying, distribution or use of the contents of this information, ev= en if partially, including attached files, is strictly prohibited and will = be considered a criminal offense. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents of = this information, even if partially, including attached files, is strictly = prohibited, will be considered a criminal offense, so you must reply to the= original sender to inform about this communication and delete it. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 =20 =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Oct 18 02:29:49 2018 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 AB940130E1D for ; Thu, 18 Oct 2018 02:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjx6zRrhYeFs for ; Thu, 18 Oct 2018 02:29:44 -0700 (PDT) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B841B12D4EF for ; Thu, 18 Oct 2018 02:29:44 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 5D06DFECC0A1; Thu, 18 Oct 2018 09:29:43 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 3F8D076700B; Thu, 18 Oct 2018 11:29:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> Date: Thu, 18 Oct 2018 11:29:40 +0200 Cc: Mikael Abrahamsson , Lee Howard , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 09:29:48 -0000 Jordi, > I stated clearly CLAT not the complete 464XLAT. Packet path for the CE. Including in the case of CLAT the two stateful = NATs. SIIT etc. Another metric is to measure the number of cycles used to process the = packet. Compare CLAT processing and non-translation solutions. CLAT comes worse off both in matter of cycles and lines of code, and = likely provisioning. Enough to care=E2=80=A6 who knows. My point was, just stop spreading = incorrect information. You can not claim that CLAT is = simpler/cheaper/faster to implement than the others. Ole > =EF=BB=BF-----Mensaje original----- > De: Ole Troan > Fecha: jueves, 18 de octubre de 2018, 10:37 > Para: JORDI PALET MARTINEZ > CC: Mikael Abrahamsson , Lee Howard = , > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >=20 > Jordi, >=20 > So the metric you use to justify your claim is code size? >=20 >> I've posted some time ago a comparison in terms of code size in = OpenWRT comparing all the IPv4aaS, not going to repeat that, just for = short, CLAT code size in OpenWRT is 4 Kbytes: = https://openwrt.org/packages/pkgdata/464xlat >>=20 >> I can see the code simplicity at: >>=20 >> = https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xla= t.sh >>=20 >> If you remove the comment lines, is less than 100 very simple code = lines. >>=20 >> Of course, there are other implementations, all can be googled for, = such as Jool, Android, VPP and the one from Tore Anderson. >=20 > But if your claim had been correct, then the other mechanisms would = have had more code lines right? > And you do need to include the whole packet path. And provisioning. >=20 > Either you substantiate your claim, or you stop making it. I would = suggest the latter would save both you, me and the list some time. >=20 > Ole >=20 >=20 >> =EF=BB=BF-----Mensaje original----- >> De: Ole Troan >> Fecha: jueves, 18 de octubre de 2018, 10:10 >> Para: JORDI PALET MARTINEZ >> CC: Mikael Abrahamsson , Lee Howard = , >> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >>=20 >> Jordi, >>=20 >>=20 >>> I guess you're forgetting the CLAT, which is the simpler one to = implement as part of the packet accelerator. >>=20 >> Can you substantiate that? By what metric. >> If you look at number of lines of code, amount of state, or even = provisioning complexity you are wrong. >>=20 >> Ole >>=20 >>=20 >>>=20 >>> All what you mention is the reason I started the work on = draft-palet-v6ops-transition-ipv4aas, which unfortunately take much = longer than expected. >>>=20 >>> We need to point the SoC vendors, not just the CE vendors, to this = document. >>>=20 >>> Regards, >>> Jordi >>>=20 >>>=20 >>>=20 >>> =EF=BB=BF-----Mensaje original----- >>> De: v6ops en nombre de Mikael Abrahamsson = >>> Organizaci=C3=B3n: People's Front Against WWW >>> Fecha: jueves, 18 de octubre de 2018, 9:34 >>> Para: Lee Howard >>> CC: >>> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >>>=20 >>> On Thu, 18 Oct 2018, Lee Howard wrote: >>>=20 >>>> Yannis, I'm interested in hearing more about what isn't working = well,=20 >>>> either on-line or directly. >>>=20 >>>> =46rom my experience, the biggest problem is the same as Yannis is=20= >>> presenting, it's all about HGW support for these things. The major = vendors=20 >>> support 6to4, 6RD and ds.lite (plus regular dual stack). Then it's=20= >>> problematic. >>>=20 >>> One of the major SoC vendors had a packet accelerator problem with = LW4o6=20 >>> in that the accelerator "forgot" to NAT44 the packets when it took = over=20 >>> the flow. I spent 9 months getting nowhere until finally I managed = the use=20 >>> threats to get through to some engineering people and explain my = case.=20 >>> They fixed the problem 2 weeks later. They said they didn't first=20 >>> understand what I wanted, and basically had asked the wrong question=20= >>> internally and then probably got a "err, no, not justified by the = business=20 >>> case". >>>=20 >>> But now I have a fully working, fully accelerated LW4o6-supporting = gigabit=20 >>> ethernet (can actually do that) HGW for LW4o6 use-case on = active-ethernet. >>>=20 >>> Someone else might want to do this over PPPoE, so then you might be = in=20 >>> trouble again because the accelelator might not support the=20 >>> LW4o6-over-IPv6-over-PPPoE case. I don't know, I haven't tested it = because=20 >>> in my deployment we don't do PPPoE. >>>=20 >>> So the problems aren't really technical, they're all business = related. The=20 >>> vendors are doing pushback on all these different versions of doing = pretty=20 >>> much the same thing, that all require development resources. >>>=20 >>> So let me list some of the common use-cases the IETF/ISPs basically = is=20 >>> asking them to support. >>>=20 >>> 6to4 >>> ds.lite >>> LW4o6 >>> MAP(-e and -t) >>> 6RD >>>=20 >>> all of the above over: >>>=20 >>> PPPoE over DSL, PON and ethernet >>> PPPoA over DSL >>> Native Ethernet >>>=20 >>> ..... plus probably something else I forgot. That's tens of = different=20 >>> combinations for doing what looks to be almost the same thing. Some = others=20 >>> also expect them to have multiple VLANs on WAN, because that's how = the=20 >>> operator likes to deply their IPTV and VoIP service. >>>=20 >>> The linux kernel does all of the above, but the packet accelerators=20= >>> typically in these kinds of devices do not support all of it. There = are=20 >>> lots of different platforms, and all customers have whole = departments that=20 >>> are penny-pinching price on each device when doing procurement. >>>=20 >>> Things are improving as the business ecosystem is moving to more = common=20 >>> operating systems and fewer platforms, but it's still an issue, and = it's=20 >>> going to be an issue for a long time. >>>=20 >>> The vendors don't typically jump on whatever new stuff the IETF came = up=20 >>> with last month, I've heard some who say "we typically wait 2-3 = years=20 >>> until we consider implementing an RFC to see if it actually gets = some=20 >>> support". >>>=20 >>> --=20 >>> Mikael Abrahamsson email: swmike@swm.pp.se >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>>=20 >>>=20 >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.consulintel.es >>> The IPv6 Company >>>=20 >>> This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 From nobody Thu Oct 18 02:55:06 2018 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 0762A130934 for ; Thu, 18 Oct 2018 02:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb8WPwew3vZF for ; Thu, 18 Oct 2018 02:55:02 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92992120072 for ; Thu, 18 Oct 2018 02:55:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 127DDB0; Thu, 18 Oct 2018 11:55:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539856500; bh=xAQqSutY9FFJhKrToeDTKCPxBijHZig8dSDgxuVik1I=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=x3R+K1zhF4CoucIVFET23kiRp/tEasWh4zq0JX1pbtU9o3AD/I0xzXxyyCLbgF4Mb Tq203NDJLJIwDEp5e4olzzxgLXFb3vIMzDWgoI3sXr5mkGW4C5r17nQ/IufRzV5t9t U1tjmuMJ3yTth97N62Sb8B6tLtRxXfey9uxzgmbs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0FD09AF; Thu, 18 Oct 2018 11:55:00 +0200 (CEST) Date: Thu, 18 Oct 2018 11:55:00 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: JORDI PALET MARTINEZ , v6ops@ietf.org In-Reply-To: Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-678231105-1539856500=:26856" Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 09:55:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-678231105-1539856500=:26856 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 18 Oct 2018, Ole Troan wrote: > Enough to care… who knows. My point was, just stop spreading incorrect > information. You can not claim that CLAT is simpler/cheaper/faster to > implement than the others. I agree. The HGW platform I talked about does 200 megabit/s of packets in pure CPU, around 800-1000 megabit/s of traffic with some functionality turned on (checksumming and some other things then done in SoC/NIC instead of purely by CPU), and then bidirectional wirespeed with small packets with full acceleration / flow offload (2000 megabit/s with smaller than 1500 byte packets). I have no idea if the packet accelerator in its current form would be able to handle the CLAT functionality. I would doubt it until I see it working in practice. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-678231105-1539856500=:26856-- From nobody Thu Oct 18 06:31:18 2018 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 D179812D7EA for ; Thu, 18 Oct 2018 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un2q2g2ek_le for ; Thu, 18 Oct 2018 06:31:15 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5FB12D4ED for ; Thu, 18 Oct 2018 06:31:15 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id 61-v6so33708700wrb.6 for ; Thu, 18 Oct 2018 06:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rTrnx7MlVwsZ7lPG2qlr5wLXWBoI+USveu2rtuUcfeM=; b=q5/2u5cN7QuUx/O9SAiJNd2E82C4AoneCPPLdgLGSFlQpOYmIujvhwTkiEzz4wac91 e/y5rjGBGuaNNyUm4MQVkyfkPwIIvaPopXaKyVIjobQanmpYScO54tlvhurDJaxV/So2 KQGd+EFiM8h1XEuV3eSdVVAZRPUwFKyxz7lCFJ1NRDYgpmgeBFgBk6jr27zGAEMt3/0D ifViHzZbiUJ3xWHCOGKon/XNKzd9fxSagd0XIKy+qx7s/aaRU197hScFPu4a/gjhXGj7 Mpnpus9qz/jbTaQSEJ101BvvAN6epkVQfCTg0S+4lHMWze+IJZA9VEe5hgnzgNZzRtrt hVhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rTrnx7MlVwsZ7lPG2qlr5wLXWBoI+USveu2rtuUcfeM=; b=NQFePdpNxeHgt4FYgoHDRK4VuiUUceCo0TepM7AdeIvj8hU/ma1KLE7DQoyY9WlCIw u3eerhqLJNESFKjGQAFd/u1ogRMxGmHyl92pAMwAMBnYKXp34RRzgFviFuXJM1LdcrwX krUg6ZEQpUrxWDm63aaIgSupXAdWAaagWEpy4CAYPnexcCDaLZxOu3BAK+J+1550Ddrd v2WrWk/koSELHq2bK9NpWTmBv/4KvNZdOiv9wtnJJH/MLsODXsJuK+ZoKT3YUePlRQXR y/6dhRkGtsEiifUDLHFWVjqB7sDTba2l32ne/yuWAlES9sn8Fej2xSy+RSXQZFEZRPf/ RM+A== X-Gm-Message-State: ABuFfoieOxH5wIL2BsZP5Z16ZK8JIK1sCqAZmQK0Yje+WsV6Jzgfl+Mk orfthyidUbo0mFMw6YF6uEWSlsObGSd1xgvF9GE1dw== X-Google-Smtp-Source: ACcGV63T+VBP+E+EbHSsOUKL0SIq85swCV6Q05whCV6OfZn3g/tCidphje/e6AmlHRrh5wFCEGBitwnmfK0wE9XG9Eg= X-Received: by 2002:adf:9244:: with SMTP id 62-v6mr27841953wrj.130.1539869473528; Thu, 18 Oct 2018 06:31:13 -0700 (PDT) MIME-Version: 1.0 References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> In-Reply-To: From: Ca By Date: Thu, 18 Oct 2018 06:31:02 -0700 Message-ID: To: Mikael Abrahamsson Cc: Ole Troan , v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000f86210057880ccb5" Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 13:31:17 -0000 --000000000000f86210057880ccb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 18, 2018 at 2:55 AM Mikael Abrahamsson wrote= : > On Thu, 18 Oct 2018, Ole Troan wrote: > > > Enough to care=E2=80=A6 who knows. My point was, just stop spreading in= correct > > information. You can not claim that CLAT is simpler/cheaper/faster to > > implement than the others. > > I agree. The HGW platform I talked about does 200 megabit/s of packets in > pure CPU, around 800-1000 megabit/s of traffic with some functionality > turned on (checksumming and some other things then done in SoC/NIC instea= d > of purely by CPU), and then bidirectional wirespeed with small packets > with full acceleration / flow offload (2000 megabit/s with smaller than > 1500 byte packets). > > I have no idea if the packet accelerator in its current form would be abl= e > to handle the CLAT functionality. I would doubt it until I see it working > in practice. > Tl,dr; CLAT likely does not need acceleration since it should not see much traffic. The reason CLAT is so enjoyable in my deployment of 464xlat with DNS64 is that CLAT only handles very few flows that use ipv4 literals or force ipv4 socket by other means. In the home, their is a great varitety of things that behave in many ways, but i would have to assume the typical windows 7+ / ios10+ home at this point is mostly ipv6 traffic. We certainly see Google=E2=80=99s overall num= ber is 35% in the usa, and most of that traffic is Youtube, FB, Netflix ... with v6 ... and many things ask for AAAA and could receive it and therefore leverage standard ipv6 routing on the CPE with no special treatment at the edge > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000f86210057880ccb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu,= Oct 18, 2018 at 2:55 AM Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Thu, 18 Oct 2018, Ole Troan wrote:

> Enough to care=E2=80=A6 who knows. My point was, just stop spreading i= ncorrect
> information. You can not claim that CLAT is simpler/cheaper/faster to =
> implement than the others.

I agree. The HGW platform I talked about does 200 megabit/s of packets in <= br> pure CPU, around 800-1000 megabit/s of traffic with some functionality
turned on (checksumming and some other things then done in SoC/NIC instead =
of purely by CPU), and then bidirectional wirespeed with small packets
with full acceleration / flow offload (2000 megabit/s with smaller than 1500 byte packets).

I have no idea if the packet accelerator in its current form would be able =
to handle the CLAT functionality. I would doubt it until I see it working <= br> in practice.

Tl,dr; CLAT like= ly does not need acceleration since it should not see much traffic.=C2=A0


The reason CLAT is so enjoyable in my deployment of 464xlat with DNS64 i= s that CLAT only handles very few flows that use ipv4 literals or force ipv= 4 socket by other means.=C2=A0

In the home, their is a great varitety of things that behave in many= ways, but i would have to assume the typical windows 7+ / ios10+ home at t= his point is mostly ipv6 traffic. We certainly see Google=E2=80=99s overall= number is 35% in the usa, and most of that traffic is Youtube, FB, Netflix= ... with v6 ... and many things ask for AAAA and could receive it and ther= efore leverage standard ipv6 routing on the CPE with no special treatment a= t the edge



--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se_____________________________________= __________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000f86210057880ccb5-- From nobody Thu Oct 18 06:56:09 2018 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 B0262128CF2 for ; Thu, 18 Oct 2018 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZSUZuUHvfTU for ; Thu, 18 Oct 2018 06:56:05 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F7A124BE5 for ; Thu, 18 Oct 2018 06:56:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1D1E2B0; Thu, 18 Oct 2018 15:56:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539870962; bh=SjgCbg2rJ/hOlZhqI4ypecFYjGw8PJvyQF4zW1qOYG4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=uOmjwdaAHKFNiaVo8G7ymNKrvMRmdLhO/u0qUB3OrDihlBpu97s2p5cawDfU3xt8u FqDw1oVpCEzPHZOiEAaM+oMjc84waydvamwTz46MYRVo2WsKJ5W7gIV+2tym0Sb3Zu 0XHgsFHiUDjXXJa0PhGBfVvdp5C9sZYNkJ21Z7iY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1ADA3AF; Thu, 18 Oct 2018 15:56:02 +0200 (CEST) Date: Thu, 18 Oct 2018 15:56:02 +0200 (CEST) From: Mikael Abrahamsson To: Ca By cc: Ole Troan , v6ops@ietf.org In-Reply-To: Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 13:56:08 -0000 On Thu, 18 Oct 2018, Ca By wrote: > Tl,dr; CLAT likely does not need acceleration since it should not see > much traffic. That's fine. Unfortunately the failure mode of the accelerator might be that it treats the flow wrong and doesn't do what it's supposed to do. It "takes" the flow but then doesn't do the needful. And the only way to easily fix it is to turn off the entire accelerator, device-wide. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 18 07:36:50 2018 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 4081D12958B for ; Thu, 18 Oct 2018 07:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcNO44FP9O_s for ; Thu, 18 Oct 2018 07:36:47 -0700 (PDT) Received: from atl4mhob18.registeredsite.com (atl4mhob18.registeredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3712426A for ; Thu, 18 Oct 2018 07:36:47 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob18.registeredsite.com (8.14.4/8.14.4) with ESMTP id w9IEajKs008725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 18 Oct 2018 10:36:45 -0400 Received: (qmail 15446 invoked by uid 0); 18 Oct 2018 14:36:45 -0000 X-TCPREMOTEIP: 193.0.31.240 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?IPv6:2001:67c:64:49:d14c:b6f5:7420:6ded?) (lee@asgard.org@193.0.31.240) by 0 with ESMTPA; 18 Oct 2018 14:36:44 -0000 To: v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> From: Lee Howard Message-ID: <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> Date: Thu, 18 Oct 2018 16:36:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 14:36:49 -0000 On 10/18/2018 03:56 PM, Mikael Abrahamsson wrote: > On Thu, 18 Oct 2018, Ca By wrote: > >> Tl,dr; CLAT likely does not need acceleration since it should not see >> much traffic. > > That's fine. Unfortunately the failure mode of the accelerator might > be that it treats the flow wrong and doesn't do what it's supposed to > do. It "takes" the flow but then doesn't do the needful. Your argument is that somebody might implement it wrong? Doesn't that apply to literally everything? > > And the only way to easily fix it is to turn off the entire > accelerator, device-wide. > If a process black-holes your packets, you should turn it off. Does that really mean you have to turn off acceleration? Lee From nobody Thu Oct 18 07:44:01 2018 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 C836012D4EB for ; Thu, 18 Oct 2018 07:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMmQ2w0bru6O for ; Thu, 18 Oct 2018 07:43:58 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42F8129C6B for ; Thu, 18 Oct 2018 07:43:57 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id q184-v6so860859qkd.3 for ; Thu, 18 Oct 2018 07:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EQu2TPrUN5DmaYeH5r9K06TFNSlvxpZBG309MQJXWIQ=; b=STpw8X0O7g8Wl73kVSsBmbhVAZCrq3sNopctbnb17M3cFeJxRb5nPdv+3rD4gjfD5X o2UnsNPVG7F4c2FkTKGFOo8tBuNohJoG121MYT9My8jeN1b45Bgo5nGKOGJndDaOgQSE czcMREL1pWym+nhRyxcCtjpxqJSbqe+GCAlOshKSH+o9LWq3rcq8ixmZvOx3gt9A4FBF rVlmqWk1+AVr1RW0L90ZNmM/ykjZ0cjnF9NWEjnXxMmXwiUvVFZTebKHfO7FmsVCBlle FxZ9DbcPsePdc2IXO00UqpjXcy+H/9XmI3FbgEw0vb8L42bb7z9PVDQPi+a4yJDc92WT gWJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EQu2TPrUN5DmaYeH5r9K06TFNSlvxpZBG309MQJXWIQ=; b=tk5CtOc7R8fCz1ENd0/8O88fAg7q753rkp3FK7KhMJchrhgfotFjNw9x0LcKTXppUa PNyfEHqF/4CXx3LtIRWnM8Cb/iKmsA2HDGIAhw6tGea2uw04Wpyn9FRaMvzjTYwTfMpH eCqsG7LwZo502ETUdRhU97s+6kIUrnNIEghHr4RNsJoBFMM9bE/ULNvMa+0U4UCKdglw 3mGear0XO9roa/XLU3C9r2rt4WBJd3bwSvGn72xOduqIBg3i5n8IQ2+V+Ul1ZqUbY1pi ZFMbgHNFugaOEQ2OH1Dts/73OP4EKqOHmBiTzjQ5LNYAIOxfj1Kqtf89qxcxrOydjLBI PGZg== X-Gm-Message-State: ABuFfogqedF2EUxRPPGmGVZXlBXo02IDSVpST/7cKUT+gJMB3lOHTdAA Kpp/xKUoulSx5Jv2Nmcl7gZNaga8PR/H6pETnoQkpWEdaZc= X-Google-Smtp-Source: ACcGV61wZdTxSCHTLpkjSWCYJKlwaiZJJB+FRLCmdQd63nTuV/DcnUi1K1HsuNDbTYkCla+0BsilTtHWdkp+idalwRM= X-Received: by 2002:a37:444b:: with SMTP id r72-v6mr27919519qka.332.1539873836343; Thu, 18 Oct 2018 07:43:56 -0700 (PDT) MIME-Version: 1.0 References: <153919621638.5900.18199747860735930931.idtracker@ietfa.amsl.com> <28C84190-026A-418D-B8E0-147B9F852018@consulintel.es> In-Reply-To: From: Jen Linkova Date: Fri, 19 Oct 2018 01:43:44 +1100 Message-ID: To: Jordi Palet Martinez Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 14:44:00 -0000 On Thu, Oct 18, 2018 at 6:13 AM JORDI PALET MARTINEZ wrote: >> So you are suggesting that DNS operators have to do some work (in >> quite short timeframe) to facilitate something they might not even >> care about...Not sure it would work. > > They should care about providing a good service, right? > A good service today is not just IPv4-only. So you are saying that IETF needs to publish a document which mandates that all DNS operators not providing good services should get their NSes "temporarily suspended"? Well, why stop here? As both of us are at RIPE77 now - maybe it's time to suggest that ASes not advertizing IPv6 blocks (or not getting 5 starts in IPv6 RIPEness?) shall get their v4 blocks taken away? Together with AS numbers? ;) >> Obviously *just* adding AAAA RR for A-only names has nothing to do >> with enabling IPv6 for a service. > > Clearly, we need to rephrase it. We meant not just the RR part, but of course, having the IPv6 connectivity. And - as per the draft - "Probing mechanisms to verify that the relevant AAAA are fully operational MUST be setup by IANA. ". While I'm sure many service owners would love to have a free monitoring system run by IANA, I'm not entirely convinced it's feasible. >> The service needs to have IPv6 connectivity (which might not even be >> available in the specific location) it needs to be tested etc. Adding > > IPv6 free tunnels are available, in case, I doubt, you can't setup a tunnel to your upstream provider or alternatively to any of their upstreams. I've been there, several times, in the most strange and remote locations. I'm not entirely sure recommending tunnels is such a good idea... > I think trying is much better than just complaining and not doing something. Clearly IETF liaison with ICANN need to take actions here. As I described in my previous email, I believe that the proposed actions are more likely to hurt v6 adoption than promote it. > Believe it or not, there are still many DNS "operators" that have no idea about IPv6, and a call for action should enforce them to do something. I do believe you indeed. I did measurements on overlap between signed zones and v4-only names while ago. If those operators have no idea about IPv6 they need to be educated. Publishing a document explaining why not having AAAA in a signed zone is not such a good idea and providing recommendations does sound as a good idea. Requesting something non-feasible and non-enforceable (and not clearly defined) does not sound like a good idea to promote IPv6 deployments. -- SY, Jen Linkova aka Furry From nobody Thu Oct 18 09:11:36 2018 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 50088130E5D for ; Thu, 18 Oct 2018 09:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp8QMDlW792u for ; Thu, 18 Oct 2018 09:11:28 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD70130DD3 for ; Thu, 18 Oct 2018 09:11:28 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id v6-v6so28220217ljc.11 for ; Thu, 18 Oct 2018 09:11:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OD0Raxua55s7vm2C4bbN6zus7t4IR+H6LArf0ERtun0=; b=kTWApSQFbe3X7j0Q+EVxn9Iu4eVZGHgLiD28tsEsB4MTcizI3GA22Zi02Wv0bY0BNz 0Ynj99TeOHYdpRvNl9z1NJc1x0Mbo8KZBx7AQTOBPnKGE2IlE8GHQmSron3PKPKNW6tK MXkE/qNzgvFCkQ9A1kmaqZt6XrHi4T7bfieLpVjkSokmjn67K3Q5GRqN9juNIY5ODyvN iqo3CAGiuds8o1VE8NW+0coYxSMtFQjOUiRsjYAmwqpGwWaxI0TTkwfUVttBh3uMGQYc Umx7/4TmyGAuuUHB70cxYBm8XnVnEgJo1Q1Fd0THuVTfVCXy0PNayD9jTrI5sufJUv4m EoSA== X-Gm-Message-State: ABuFfogKPGquUR2FkfW77rFDfgop8dHu874hDxOiQwL6/jj4SOjDOL/M dZFKMI8uTI2aUzEESFjZ9zGFj8JDAOLnNS9JpMu1lIx7 X-Google-Smtp-Source: ACcGV61PMlakUzf99JcI92fWbCcLIuRyalNTVK09urayDZOKllyy2DbZ5PRnE1/xZ0beFPaan3DlDUyScJbSL+eiBR0= X-Received: by 2002:a2e:8589:: with SMTP id b9-v6mr20645487lji.122.1539879085624; Thu, 18 Oct 2018 09:11:25 -0700 (PDT) MIME-Version: 1.0 References: <735F51BC-5AE4-4C42-8E99-A61CC2D83B31@gmail.com> In-Reply-To: <735F51BC-5AE4-4C42-8E99-A61CC2D83B31@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 18 Oct 2018 09:11:14 -0700 Message-ID: To: Fred Baker Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000e552950578830967" Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 16:11:34 -0000 --000000000000e552950578830967 Content-Type: text/plain; charset="UTF-8" At Wed, 17 Oct 2018 12:29:11 -0700, Fred Baker wrote: > I'm not sure we disagree on your point. However, there is also the issue of shadowing services. For example, in my home I use an OpenDNS resolver; it's built into my router and I said "yes". If my ISP were implementing 464XLAT (they're not to my knowledge, but imagine) and wanted me to use a prefix of their choosing, OpenDNS could either have no record or give me something different. So the DNS approach has a fairly fundamental flaw. > > What might be interesting on routers that want you to configure it manually would be a "use RFC 7050" configuration, in which the router got the record from DNS and advertised it in its RA. This made me wonder whether the background assumption is that the network operator essentially owns leaf routers with some auto-provisioning system. In that case, I see the configuration information is managed effectively only in one place and leaf routers are automatically configured and updated through the provisioning system. In that case I see the configuration overhead is not that different from the DNS based approach. -- JINMEI, Tatuya --000000000000e552950578830967 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Wed, 17 Oct 2018 12:29:11 -0700,
Fr= ed Baker <fredbaker.ietf@gma= il.com> wrote:

> I'm not sure we disagree on your poin= t. However, there is also the issue of shadowing services. For example, in = my home I use an OpenDNS resolver; it's built into my router and I said= "yes". If my ISP were implementing 464XLAT (they're not to m= y knowledge, but imagine) and wanted me to use a prefix of their choosing, = OpenDNS could either have no record or give me something different. So the = DNS approach has a fairly fundamental flaw.
>
> What might be = interesting on routers that want you to configure it manually would be a &q= uot;use RFC 7050" configuration, in which the router got the record fr= om DNS and advertised it in its RA.

This made me wonder whether the = background assumption is that the
network operator essentially owns leaf= routers with some
auto-provisioning system.=C2=A0 In that case, I see t= he configuration
information is managed effectively only in one place an= d leaf routers
are automatically configured and updated through the prov= isioning
system.=C2=A0 In that case I see the configuration overhead is = not that
different from the DNS based approach.

--
JINMEI, Tat= uya
--000000000000e552950578830967-- From nobody Thu Oct 18 09:31:53 2018 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 55D0C12F18C for ; Thu, 18 Oct 2018 09:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMP6dn7nzwlI for ; Thu, 18 Oct 2018 09:31:49 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305B512D4E6 for ; Thu, 18 Oct 2018 09:31:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 24418B0; Thu, 18 Oct 2018 18:31:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539880307; bh=NGZFMrnGAY8axhmYhOF4fgvr8fMX/maMCysWYMDnxB8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0K203VPpWFHXx+B1cFJ++Nnp1f9jbUP7FGksEMK+dw9wKRVDDsqiLCgWu9Yo/YjML CudGhrlC8shXlw3+X8ZJ/iZ2BX8UijNoRe73jR7YYYwSMtZKyKE7umXmlxuXR1i0Nb SMxru6YtjHPaZobBz4WKWyEwmsBPVQGpKpFffM/o= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2156FAF; Thu, 18 Oct 2018 18:31:47 +0200 (CEST) Date: Thu, 18 Oct 2018 18:31:47 +0200 (CEST) From: Mikael Abrahamsson To: Lee Howard cc: v6ops@ietf.org In-Reply-To: <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 16:31:51 -0000 On Thu, 18 Oct 2018, Lee Howard wrote: > Your argument is that somebody might implement it wrong? Nope. > Doesn't that apply to literally everything? Yes. > If a process black-holes your packets, you should turn it off. Does that > really mean you have to turn off acceleration? That's not how it works. This is not a "process". This is HW built into the SoC that conflates lots of things, including NIC, L2 switch, processor, and heaps of other things. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 18 09:46:22 2018 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 F3A9512D7EA for ; Thu, 18 Oct 2018 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmuBgG_TS074 for ; Thu, 18 Oct 2018 09:46:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18214128CE4 for ; Thu, 18 Oct 2018 09:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539881176; x=1540485976; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=emG+hI0c VuLlqLpTyoRHRyhMamLYEeecpIkpJ8RViLI=; b=eST3cZPmXTAiBMvN5eqXZ81c WFCIigNjW+pFjraVdQVe0x40IvvVozLqUgt9ZbdhUnxd/SX5ngiwJ4ByiRyNlKDY e+x97y+vNCGvQaRrMSzAjR1h+YrcOhioXcIhZhTN205knJJ4gfzm/HV8zwBN6Nd+ R5+rDtoqxsjZ3wF+Mgs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Oct 2018 18:46:16 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Oct 2018 18:46:16 +0200 Received: from [10.239.106.110] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005914118.msg for ; Thu, 18 Oct 2018 18:46:15 +0200 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.239.106.110] X-MDArrival-Date: Thu, 18 Oct 2018 18:46:15 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1829bff37a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Thu, 18 Oct 2018 18:46:10 +0200 From: JORDI PALET MARTINEZ To: Lee Howard , , Mikael Abrahamsson Message-ID: Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> In-Reply-To: <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 16:46:21 -0000 Agree, there are better ways to do that. I've been in an equivalent situation recently. Cheap CE (5 Gig ports with HW configurable switch as LAN/WAN, etc.) with So= C Mediatek MT7621, using OpenWRT. This SoC supports up to 2Gbps IPv4/6 rout= ing, NAT, NAPT+HQoS with hardware offloading. In this scenario there was also support for IPTV and VoIP. Both require spe= cific VLANs with their own NAT44. Also, the main Internet VLAN, using PPPoE= , and or course NAT44 is also needed. For some reason (I'm guessing it is an implementation problem of the IPTV a= nd VoIP), if you apply a "global" hardware Routing/NAT Offloading rule, jus= t choosing that option in the OpenWRT GUI, IPTV and VoIP, stop working. You= can still make outgoing phone calls, but incoming ones don't get in (which= once more seems to indicate that it is an implementation or may be even co= nfiguration problem). Internet data works fine. The solution is easy, you can just apply a specific firewall rule to enable= the hw offloading only for the Internet traffic, which is the one that wil= l have a higher bw demand: iptables -A forwarding_rule -i -o -m conntrack --ctstate = RELATED,ESTABLISHED -j FLOWOFFLOAD --hw ip6tables -A forwarding_rule -i -o -m conntrack --ctstate= RELATED,ESTABLISHED -j FLOWOFFLOAD --hw So, in the case of different interfaces for the transition mechanisms (as i= t is the case in OpenWRT), you can also do the same if there is any issue i= n one of the implementations of a specific IPv4aaS interface. Of course, id= eally, you resolve the implementation problem, but meanwhile you're not stu= ck with the "main" traffic not being able to use the offloading. Saludos, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Lee Howard Fecha: jueves, 18 de octubre de 2018, 16:37 Para: Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup =20 =20 On 10/18/2018 03:56 PM, Mikael Abrahamsson wrote: > On Thu, 18 Oct 2018, Ca By wrote: > >> Tl,dr; CLAT likely does not need acceleration since it should not se= e=20 >> much traffic. > > That's fine. Unfortunately the failure mode of the accelerator might= =20 > be that it treats the flow wrong and doesn't do what it's supposed to= =20 > do. It "takes" the flow but then doesn't do the needful. =20 Your argument is that somebody might implement it wrong? Doesn't that apply to literally everything? =20 > > And the only way to easily fix it is to turn off the entire=20 > accelerator, device-wide. > If a process black-holes your packets, you should turn it off. Does tha= t=20 really mean you have to turn off acceleration? =20 Lee =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Oct 18 10:23:40 2018 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 3E5A012F1AC for ; Thu, 18 Oct 2018 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf5m_JDTevPu for ; Thu, 18 Oct 2018 10:23:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF20128CE4 for ; Thu, 18 Oct 2018 10:23:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 68AD2B0; Thu, 18 Oct 2018 19:23:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539883414; bh=wxs5tbnXnaLD6Aa9VcJAkKFFvYCtb3hZzDLd/BzQlxU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=n+aTB/ih27CBTYxjJU/LTy6DhCnm95kAk4PT++vJo5EfJSmalcJ6zubdmAV+1EoDm W35voHuVJ7e8nkpiZREkAWxAj2sSG+QnDkbuLY0x9NwC3Xca0MCJTTvSn/Iw/0afCG n9z6yw/rLpul2FAM/TlqUN/yqV2qFIiqOGskK5sM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 63CF6AF; Thu, 18 Oct 2018 19:23:34 +0200 (CEST) Date: Thu, 18 Oct 2018 19:23:34 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: Lee Howard , v6ops@ietf.org In-Reply-To: Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 17:23:38 -0000 On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: > The solution is easy, you can just apply a specific firewall rule to > enable the hw offloading only for the Internet traffic, which is the one > that will have a higher bw demand: > iptables -A forwarding_rule -i -o -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw > ip6tables -A forwarding_rule -i -o -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw Errr, are you sure FLOWOFFLOAD even does HW offload? On most platforms it does not, instead it uses a slightly more optimized packet forwarding path that was merged into the linux kernel in the last year or so. Also, even though it might work this way on Mediatek, this is not how it works on other platforms. There are as many ways to do this as there are vendors. They all butcher the Linux kernel in their own peculiar way to do what they feel they need to do. There is work in PRPL foundation (https://prplfoundation.org/) to try to standardize this ,but it'll be years until we see the result in volume shipping devices probably. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 18 10:29:25 2018 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 E6A30130E7D for ; Thu, 18 Oct 2018 10:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrlfOtFrWq3C for ; Thu, 18 Oct 2018 10:29:14 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CA9128CE4 for ; Thu, 18 Oct 2018 10:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539883752; x=1540488552; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Qe3RZGTp1Qh5/9f32w4ZvnzneT5Yt12qSqMWWikI8vw=; b=LjB5EFufOyYf7 c2+oPK0SyvdVMZAXWmsF+kae9iVmRglGnkTXxTJIc6JLRXl4K6HKUWlyGBsLgR2L GSihzECBtS01Yb+ygKh0XhRn/20WhZPpzInjfK84M965ggOVO3G6GkyP9lSYGmQD eeMKb/cnQWuagabRTyUszzADcpsaIs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Oct 2018 19:29:12 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Oct 2018 19:29:11 +0200 Received: from [10.239.106.110] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005914148.msg for ; Thu, 18 Oct 2018 19:29:10 +0200 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [10.239.106.110] X-MDArrival-Date: Thu, 18 Oct 2018 19:29:10 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1829bff37a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Thu, 18 Oct 2018 19:29:07 +0200 From: JORDI PALET MARTINEZ To: Mikael Abrahamsson CC: Lee Howard , Message-ID: <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 17:29:24 -0000 Yes, 100% sure in this case. The SoC supports it with several SDKs/OSs: https://www.mediatek.com/products/homeNetworking/mt7621n-a You can enable HW or SW offloading, offers both options (didn't checked wha= t is the difference, I just go for the HW if it works, as I guess outperfor= ms the SW one). The official support in OpenWRT is very recent (as you said, because it is = very recent in Linux kernels), and of course, may be other chip sets are no= t yet supported, as they don't always offer "open" access to all the specs,= require using proprietary binaries, etc. So clearly agree that it may be chipset dependent, and also Linux dependent= , etc.: in short implementation dependent. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Fecha: jueves, 18 de octubre de 2018, 19:23 Para: JORDI PALET MARTINEZ CC: Lee Howard , Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: =20 > The solution is easy, you can just apply a specific firewall rule to= =20 > enable the hw offloading only for the Internet traffic, which is the = one=20 > that will have a higher bw demand: =20 > iptables -A forwarding_rule -i -o -m conntrack --ct= state RELATED,ESTABLISHED -j FLOWOFFLOAD --hw > ip6tables -A forwarding_rule -i -o -m conntrack --c= tstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw =20 Errr, are you sure FLOWOFFLOAD even does HW offload? On most platforms = it=20 does not, instead it uses a slightly more optimized packet forwarding p= ath=20 that was merged into the linux kernel in the last year or so. =20 Also, even though it might work this way on Mediatek, this is not how i= t=20 works on other platforms. =20 There are as many ways to do this as there are vendors. They all butche= r=20 the Linux kernel in their own peculiar way to do what they feel they ne= ed=20 to do. =20 There is work in PRPL foundation (https://prplfoundation.org/) to try t= o=20 standardize this ,but it'll be years until we see the result in volume= =20 shipping devices probably. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Oct 18 10:45:06 2018 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 DE332130DCB for ; Thu, 18 Oct 2018 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uqf0jBOh-jBQ for ; Thu, 18 Oct 2018 10:45:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E2A130DC0 for ; Thu, 18 Oct 2018 10:44:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0E608B0; Thu, 18 Oct 2018 19:44:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1539884696; bh=rLyoYVxxyoNX3h4CrEmCxv+RDwxmDuY3RT5RWN5BSZ4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VdqkPxcY0Qr4GdNjL68fV9WulPUT0oTPWb6ZjeFRcv7dSO3COBgmTE6+4Y8nzyf0r Lczj2NQH7hyLbU9AN4bIp9iVRepP7Pz9IoMRjEeGQcuYRhF2HixlXZOpYf9BivBFsN Q72dV7PEg3gFphrUvuuOIr2tqDFHhbjlRSFRwX0Q= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0B96EAF; Thu, 18 Oct 2018 19:44:56 +0200 (CEST) Date: Thu, 18 Oct 2018 19:44:56 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: v6ops@ietf.org In-Reply-To: <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 17:45:04 -0000 On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: > Yes, 100% sure in this case. > > The SoC supports it with several SDKs/OSs: > > https://www.mediatek.com/products/homeNetworking/mt7621n-a > > You can enable HW or SW offloading, offers both options (didn't checked > what is the difference, I just go for the HW if it works, as I guess > outperforms the SW one). I know the MT7621 does what you're saying in other OSes with their SDK, I'm questioning if the -j FLOWOFFLOAD is the way to do HW acceleration for certain flows. Did you try to run full gig speed through it and check CPU usage? It's the easiest way to tell if the offload works or not. It would be the least intrusive offload implementation I've ever seen in Linux, so if it actually works this way I'd be very happy, and hope more vendors does it the same way. Did you buy some retail device? If you did, what was it? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 18 15:38:39 2018 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 A3BC9130E23; Thu, 18 Oct 2018 15:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUDJoB1afnKg; Thu, 18 Oct 2018 15:38:01 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660135.outbound.protection.outlook.com [40.107.66.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7A9130E13; Thu, 18 Oct 2018 15:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XaSr0sIt7fol78KNasQPuYGsw0AGEav9OwjJFcyFfzk=; b=RdFeyMNguX8hCiBEb4ctwhOEHEPrbtzxEST9fonHzn0pvmUWpfpNDDEUL2/+9shHdykvIWUsCZ0KnSDDeSBUjK3zGenZXdAgRspaIXdseBt+J84oKCAZe4qVr65n15aePuULWUT1lFZf8tNXcTyebqDjkME09YZHlMT03kDoO98= Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM (10.169.141.148) by YQBPR01MB0033.CANPRD01.PROD.OUTLOOK.COM (10.169.140.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.25; Thu, 18 Oct 2018 22:37:59 +0000 Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9af:2ac3:bd40:e2ea]) by YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9af:2ac3:bd40:e2ea%3]) with mapi id 15.20.1250.022; Thu, 18 Oct 2018 22:37:59 +0000 From: Suresh Krishnan To: int-area , 6man , dhcwg , V6 Ops List , "opsawg@ietf.org" , "opsec@ietf.org" Thread-Topic: Considering AD sponsoring draft-bi-savi-wlan-15 Thread-Index: AQHUZzM4rr8N7CUdy0qcarmhx6SfhQ== Date: Thu, 18 Oct 2018 22:37:58 +0000 Message-ID: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [67.22.228.35] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR01MB0033; 6:xHUwhvfXx/SHfYu8Y9IMCvLhLcG2E8C3AkiPrhPskmHcbx86kegwxFKZlZPyGIx4q4lYEki+TLb7b9W7uQY+rWgeY+7dXt7+q0wD6jTSrAx2sdLXuTvf20a9DNNJXwGuNSIwxuL5o+zMtMXYwEBkXv3z6zhd1fbftTjkr+2SmF6t9vuoSGVmmpLGL45SSUYG/YlvBIgzd4T4nPrhqEfxW4DUpqaoOKn3qqKbsRNlyARQ4m9imObTY79MTtmU0cPoSKMdGOtuTfSGfLkgX/TGH6CwClCr3oBdP+6PrAUKQJiBC0fWshDaJmApjiiU9FKsfj5w/fRLgPOsB4B51BkG2vzIZdbUl5ElKiVZfxeRlHSToy2VM7BjYR0tyscBz8qejt0iexgw1Gp0U6haSFnxZC+bYXiBFLMYbAX4YspyK/H+j3VRKL7MwFt7SgOfY32qz8QOl5GgbCNtLPZbpZv3cQ==; 5:C7R8hdiLAViTMYUkjzeFw6HTgHOgyX2wqdUsgtXrjV3TW5vdfouvQhvZPL7jLY1wc/qDK1kLVdJMKwI/Tly+Ii7b7d/dwg37Np08hsvtjI5Y3m+dI8TZetF2T2rDvnWayHCEI29hzsNgmSi9WspsqGlC/qLgLkRZwSAUp/k2RW4=; 7:cLaT9RVgRpYrdpGKwDJTbWQ1IixHsscfqi+qNHvLKfamU/RQqHctq1YsBOJFPFcZU7w+LQLtkhrgl+i60V2am8w62MJgxg15YPHPgIcwNoKNukO7Fbo0scEdNVAqxILaCSMjtiQr/XZwd5Gl3GW2TUPuY3ajG6ACk/0ajz0HIuAjSjNfNeHWJ0iKJEWOHyQNA7MKuDuUgK5LvmKgc13YjjqQxVUeygUAcPQZAKaGosd3O7LbFpzzbV6gYhAhs0Bz x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3b8c7d4c-629c-4fbf-2f07-08d6354a5b04 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:YQBPR01MB0033; x-ms-traffictypediagnostic: YQBPR01MB0033: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(2016111802025)(20161123558120)(20161123562045)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:YQBPR01MB0033; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0033; x-forefront-prvs: 08296C9B35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(346002)(376002)(136003)(366004)(53754006)(189003)(199004)(97736004)(81166006)(71190400001)(81156014)(102836004)(450100002)(71200400001)(256004)(83716004)(25786009)(6506007)(66066001)(8936002)(186003)(2201001)(26005)(2906002)(80792005)(86362001)(6436002)(8676002)(99286004)(5660300001)(6486002)(110136005)(68736007)(6306002)(3846002)(106356001)(6116002)(966005)(316002)(2501003)(2616005)(476003)(53936002)(6512007)(486006)(105586002)(36756003)(33656002)(72206003)(508600001)(2900100001)(14454004)(82746002)(5250100002)(7736002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:YQBPR01MB0033; H:YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: AnzEXmSMLHDeLnkPIk+o+wEgSU8i6PC+GlyntbBlag72vxBgKIesL2gz/pL5SbE15j2Hnk/JjK/EXmaLhpXHxCXVY4r87vAGlnA1mwPaxdvl6+FJHj5gXAOEUr7yerE8UP4ETcqInDrhtXpaiio/mxUrxr88dXpO8SUOO/UYdWOBOSNIzZrQCT4sCHOFQUAyUfmA4CcrB6dSCheXM9Xw3A8KdabRmZM9qeBhWIUf8i61CIErZLhh8ucs91NoVQzM0MgscdhC+pdbA+XP++vq+1D0PeRuW4a1BTROLbYrdSEWo5mUr3Se6VGDB9fpdF/WtYyFfj6yiIgCMTzJFQRwHki9Fb7gQtVB+tdrwJ+psUk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b8c7d4c-629c-4fbf-2f07-08d6354a5b04 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2018 22:37:58.9419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0033 Archived-At: Subject: [v6ops] Considering AD sponsoring draft-bi-savi-wlan-15 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 22:38:05 -0000 Hi all, I am considering AD sponsoring the following draft https://tools.ietf.org/html/draft-bi-savi-wlan-15 that describes a source address validation solution for WLAN. If you have a= ny concerns either with the content of the draft, or about me AD sponsoring it please l= et me know before 2018/11/18. Thanks Suresh NOTE: I have CCed: all the working groups that I thought could be potential= ly interested in this work. If you think I have missed out some WG(s) please l= et me know. From nobody Thu Oct 18 17:07:19 2018 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 7AB9D130E30 for ; Thu, 18 Oct 2018 17:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJNAQrPSc7TT for ; Thu, 18 Oct 2018 17:07:05 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35343130E84 for ; Thu, 18 Oct 2018 17:07:03 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id d80-v6so1505682iof.1 for ; Thu, 18 Oct 2018 17:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sy1ghWjZptAT/y8Jwbm5IxkhS4gw4nta4dFrK1XnBlY=; b=iPLJAGqvtreRwhTpvxqhPBjbbcrcUSrFzAY+3F3elmkkeJuOsGCiAc4xjbfaMDGJ6+ x3jobC9PcSQ6oRiAL6ttxE+Bmd6FmVN8hcJuP+tfa4HmtUgK+OpaFEGbYr7ycTLe7Mgm QBY36MAGv8d8VNp6L8cBPL7sSANiUCzGgRuKoVKr3HkZRAn9Q/EqrNZjLaTaix4lH16J xu413oD1cunTffGlmpQC1QOJcEC8XyAtxvad8o5HzKqWPbfy1ppDlag00xRibie3SGoV M9mxUM9XdemMBS/vPirJHZPJh/w6aHV3fSqtL5I6TwigVUaESvMDEhvVkBHLLXkX74cZ eqRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sy1ghWjZptAT/y8Jwbm5IxkhS4gw4nta4dFrK1XnBlY=; b=dXoO0BJGS/RxEBJMp1pJIjMLYfP7S5thLvMychlAflrgedjim/wtfPYv4fEKvMl5eT uHwx/LJqMuO43YzB3+BR1uUrwMBbBYOeGbR403SSdsp91SivcLIkwAgL/OJRwPz8J6DM yRdEoNXSIjhLIeFyHqdl/hYR3DoQc1UV2T62BoPRQWli4apw1biZwAow4izQex/45dVb f/8KZKrYlRzTslU359SMzCJje39/9mFPoBWD7OOTUbLaZW6vt2nNX7bwJI37oY4zGELG vrn90wQ8YtByU6Lgr6yG1o1yvDNWbYohfyiGUu3HLH/QUA0tO45yU45Rye4kaR/mOVQK 7bgw== X-Gm-Message-State: AGRZ1gKV6qT0Rzf5ujog8Wuh9NZsD2iQ0MmeQV+mr3Y1zpzeygIRNLd5 y/alhKPUeVddpLImFRuMMFxZXIiEXHjA1FHTeLkajg== X-Google-Smtp-Source: AJdET5eTqK8Y3WvOJlWtsCOClRPeHAI0QD9xiRQvuzrm+jqjDZwLxITbAmVAS70rNJ4jpQb/dFzQDQ7rx96WRRRESKA= X-Received: by 2002:a6b:b249:: with SMTP id b70-v6mr1698659iof.252.1539907621990; Thu, 18 Oct 2018 17:07:01 -0700 (PDT) MIME-Version: 1.0 References: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> In-Reply-To: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> From: Lorenzo Colitti Date: Fri, 19 Oct 2018 09:06:50 +0900 Message-ID: To: Suresh Krishnan Cc: int-area@ietf.org, IETF IPv6 Mailing List , dhcwg@ietf.org, "v6ops@ietf.org WG" , opsawg@ietf.org, opsec@ietf.org Content-Type: multipart/alternative; boundary="000000000000cc46d7057889ae96" Archived-At: Subject: Re: [v6ops] [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 00:07:08 -0000 --000000000000cc46d7057889ae96 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan wrote: > I am considering AD sponsoring the following draft > > https://tools.ietf.org/html/draft-bi-savi-wlan-15 > > that describes a source address validation solution for WLAN. If you have > any concerns > either with the content of the draft, or about me AD sponsoring it please > let me know before 2018/11/18. > I skimmed the draft. It looks well-written, and it addresses an important problem which I think is probably solved in (different?) proprietary ways on various implementations in the field today. I'm not very familiar with the AD sponsorship process, so not sure what the has to happen from a process perspective. But I think the document requires further review, especially given that it's making statements about very widely-deployed scenarios (IPv6 over wifi). Should the document be adopted by a WG such as 6man or v6ops? If not, it should definitely be reviewed by those WGs. As a concrete example, here are some things that need to be resolved before the document advances: 1. The proposed scheme relies on DAD packets to create mapping entries. That means that if a DAD packet is lost (which can happen even though 802.11 employs retransmissions at L2), a station could have an IPv6 address that doesn't work with no indication that it's not working. This is basically a non-recoverable outage. Perhaps the document should specify another solution instead, e.g., it could say that mapping entries could be created when a wired station receives a solicited NA response from a wireless station. 2. The document says that the lifetime of SLAAC addresses is the address lifetime, but the network has no way of knowing what the address lifetime is because it depends on which RA(s) the host has received. Cheers, Lorenzo --000000000000cc46d7057889ae96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 19= , 2018 at 7:38 AM Suresh Krishnan <= Suresh@kaloom.com> wrote:
= =C2=A0 =C2=A0I am considering AD sponsoring the following draft

https://tools.ietf.org/html/draft-bi-savi-wlan-15

that describes a source address validation solution for WLAN. If you have a= ny concerns
either with the content of the draft, or about me AD sponsoring it please l= et me know before 2018/11/18.

--000000000000cc46d7057889ae96-- From nobody Fri Oct 19 05:51:55 2018 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 44DF0127333 for ; Fri, 19 Oct 2018 05:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn-OZntdHaSW for ; Fri, 19 Oct 2018 05:51:53 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00731294D7 for ; Fri, 19 Oct 2018 05:51:52 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id g13-v6so1270156qke.8 for ; Fri, 19 Oct 2018 05:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ufFDCbfoTA3cLy2GP/FsgR5nTMh1pkmrjNye0DseKA8=; b=oKCBa1j3eShAcaTvCbpMs98gToAshnyggscpkJv+29GbSX5SDJI3uY6BDOW+aoXA67 qbx4vtERqq4uUy3rr7cyuaVv9jTvPi2IfzCpA0CCwovcVL4gEJxVm3BYcr+og2BMR6dv pfIM7IKMMxXISL0dC+x8TTMnag9qXkq7fphQHT4z+zYzUdpOd1VHp9mMwX+j4oTtorOF i6C3W0mlR5qs2mbvgi6C3oYFrRTm51iupboQ26FnC4ciNuJ13k/hgbz7D/byJ9dzjAr5 buv1CmQn2dSYz8iqh8F3619qWZuDm0BfBQ2dwPVmiR3fz6dkO8x0dB2L9KK21VueKT5F L8Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ufFDCbfoTA3cLy2GP/FsgR5nTMh1pkmrjNye0DseKA8=; b=Kh1PFAfTO3VPiFlUmFTJUB++kV62sfDQ4t+SHqcF29wCxtosXmkEU3NzxwPykl9Czk WgEougtcNaCva2hyawA/BE0H3Mag+jtg3ZTo047RmSjKxsv8fMyQxkmJnmhqOxnoVras sUFSs5TDJ0kBnCMAwznzQS14MvTl/j45xwd3NlgKuetOOdPIAFioJsnhxXjt0XTc4vfS xvRy6IEnuMGt4BwM3hleKWN0KxCConY/P2DBSkDnhxb/XdFj73PyE2yMaFkc3XKNhBXk FSM+eMvveltWJaS/LpiVahiM1vCkdW4kGvD/NgNMN7PATTcc3P4h78ssfznU6eZRzTKr /7EA== X-Gm-Message-State: ABuFfoit++zKY5kzfU9votiPrv2Y4wQULmclSr35wEa6U4HcxUyn3QDj U50q4v9UVCUZUdYsScJUIbRX7nH6p1Ebd9yzzWrZllTs X-Google-Smtp-Source: ACcGV62thN1wbsdOHWeUGQFuHRuxvqtj+0B1uAyilqNkCIBx5SxihGTnNv8eKV0q9kvIKIm2wNl0yDpABC+4xo+lFnM= X-Received: by 2002:a37:b4c7:: with SMTP id d190-v6mr31563139qkf.165.1539953511672; Fri, 19 Oct 2018 05:51:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Fri, 19 Oct 2018 23:51:39 +1100 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 12:51:54 -0000 On Thu, Oct 18, 2018 at 5:22 AM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > I'm afraid we're talking about different issues...maybe I wasn't clear > enough in the above comment, so let me rephrase it: assume if you have > 100 leaf subnets, each of which has an RA-advertising router. If you > want to deploy draft-pref64folks-6man-ra-pref64, you'll need to > configure those 100 routers separately; if the prefix is changed, > you'll need to update the config on these 100 routers. On the other > hand, if you use a DNS-based approach (RFC7050) you'll only have to > configure/update the DNS(64) server (there may be multiple instances > of such server and you may have to configure each of them by hand, but > I assume the number of such instances is generally much smaller than > the number of leaf subnets). I see your point. I think I just assumed that router configuration provisioning problem is slightly outside of the scope of this draft. I need to configure with much more than 100 routers with: - PIO (unique config for each interface on each router); - RDNSS (limited number of configuration templates applied on each inteface= ) - other SLAAC options (usually identical for all routers or very limited number of templates). Most likely large-scale deployments would need some provisioning systems anyway so I'm not sure the draft should discuss it - at least I'm not sure about wording.. > This is different from other SLAAC parameters such as PIO, since the > information is different for different subnets and each router needs > to be configured separately anyway. Not necessary - one might need to configure RDNSS and timers. > > > Similarly, we might want to note that this case in Section 5 should > > > be (very?) atypical even if not forbidden: > > > > > > o The pref64 option presents in a single RA more than once; > > > > It would be necessary for renumbering from one pref64 to another. > > The old pref64 needs to be advertised with zero Lifetime, while the > > new pref64 would have non-zero lifetime. > > Ah, okay. Perhaps that was just my bad reading, but the intent wasn't > clear to me from the draft's context. In fact, it looks like the > other two bullets talk about the case of multiple usable prefixes > (right?) Well, the logic is: - we should allow more than one PREF64 option per RA (as it would be needed for renumbering); - as we can not say 'PREF64 Option can be seen only once' we need to define the host behavior if multiple prefixes are received; - for consistency reason we refer to RFC7050. >Also, if I understand it correctly, "the recommendations > given in Section 3 of [RFC7050]" also discusses the case of multiple > usable prefixes: We shall either explicitly prohibit multiple prefixes (which might be undesirable) or define what to do. > When multiple Pref64 were discovered via RA Pref64 Option [...], > host behaviour with regards to synthesizing IPv6 addresses from IPv4 > addresses SHOULD follow the recommendations given in Section 3 of > [RFC7050], limited to the NAT64 prefixes that have non-zero > lifetime.. > > Only the above one bullet should mean the renumbering case since the > pref64 option should only support at most one usable prefix. One option specifies one PREF64 (the same way as one PIO defines one prefix= ). Multiple options/multiple prefixes do not make much sense from operational perspective (IMHO) but I'm not sure we shall say 'MUST NOT'. >And then > the above paragraph still looks awkward: since "this option specifies > exactly one NAT64 prefix for all IPv4 destinations" (from Section 3) > I'd expect we only have at most one prefix that has non-zero > lifetime. And then there's no point of applying the above > "recommendation" since it's "limited to the NAT64 prefixes that have > non-zero lifetime" (btw there's a redundant period here). > > Perhaps I'm still misunderstanding something fundamental, but I > personally see some need for editorial clarification. I see your point - thanks a lot for your comments, it's really valuable to get a readability feedback. We'll see if we can improve the text. --=20 SY, Jen Linkova aka Furry From nobody Fri Oct 19 07:45:16 2018 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 E495B130EEA; Fri, 19 Oct 2018 07:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.563 X-Spam-Level: X-Spam-Status: No, score=-14.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X75IZhWgfhRK; Fri, 19 Oct 2018 07:44:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E60130EB7; Fri, 19 Oct 2018 07:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15542; q=dns/txt; s=iport; t=1539960279; x=1541169879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=17ycnTk4Koiv0aheB1e4vRC+gINEFwhbpUOXT4axNUg=; b=EsByzlUoHwm5kNlj2JNy2Vl51CTZuojdwipAZhRiy/zbFqmvn2rXZXsy dvch1B+3Xk0XienqjG1xcbAqJy58ST1I36pzBKtCyJPzW4sULgcCKqFIY zhYQ5e2BiKcuEfQsIWxbmzpBk9yBgB3rzt0CnrHqzpT+3xhhx6kr+ShuO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACP7Mlb/4YNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCoNriBiMG4INkUeFSBSBZgs?= =?us-ascii?q?BASOESQIXhG8hNA0NAQMBAQIBAQJtHAyFOQEBAQEDIwpBCxACAQgRBAEBKAM?= =?us-ascii?q?CAgIwFAkIAgQBDQUIE4MHgR1kD6ZrgS6EMAKFYQWLTxeBQT+EI4MbAQEDgSZ?= =?us-ascii?q?GKIJNglcCiQsOhRmQDwkChlyKBh+BT4RziWeMVIlXAhEUgSYdOIFVcBU7gmy?= =?us-ascii?q?LGYU+b4h6K4EBgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,400,1534809600"; d="scan'208,217";a="458436405" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 14:44:37 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9JEibPx019637 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2018 14:44:38 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 19 Oct 2018 09:44:37 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Fri, 19 Oct 2018 09:44:37 -0500 From: "Pascal Thubert (pthubert)" To: Lorenzo Colitti , Suresh Krishnan CC: "v6ops@ietf.org WG" , IETF IPv6 Mailing List , "opsec@ietf.org" , "dhcwg@ietf.org" , "int-area@ietf.org" , "opsawg@ietf.org" Thread-Topic: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 Thread-Index: AQHUZzM4rr8N7CUdy0qcarmhx6SfhaUmBK8AgACTkfA= Date: Fri, 19 Oct 2018 14:44:11 +0000 Deferred-Delivery: Fri, 19 Oct 2018 14:43:54 +0000 Message-ID: References: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.26] Content-Type: multipart/alternative; boundary="_000_da54096864fc4b508931eea7203ae8acXCHRCD001ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 14:44:43 -0000 --_000_da54096864fc4b508931eea7203ae8acXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwgOg0KDQpJIGFncmVlIHdpdGggTG9yZW56bywgdGhpcyBzY2hlbWUgaXMgYXQgYSBo aWdoIGxldmVsIHdoYXQgd2UgY2FuIGZpbmQgaW4gY29tbWVyY2lhbCBwcm9kdWN0cywgYW5kIEkg aGF2ZSBmaXJzdC1oYW5kIGV4cGVyaWVuY2Ugb24gdGhhdC4NCg0KQXMgYW4gaW5mb3JtYXRpb25h bCBkb2N1bWVudCwgdGhpcyBSRkMgY291bGQgYmUgYSB1c2VmdWwgcmVmZXJlbmNlIHRvIGNvbnNp ZGVyIGlmIHdlIHdlcmUgdG8gY2hhbmdlIHRoZSBwcm90b2NvbHMgaW4gYSB3YXkgdGhhdCB3b3Vs ZCBpbXBhY3QgdGhvc2UgZXhpc3RpbmcgYW5kIG5vbi1zdGFuZGFyZCBzbm9vcGluZyBiZWhhdmlv cnMuDQpTbm9vcGluZyBoYXMgcHJvdmVuIHRvIGJlIHZlcnkgdXNlZnVsLCBidXQgYXMgb25lIG1h eSBndWVzcywgaXQgaXMgbm90IHJlbGlhYmxlOyBpdCBtYXkgbWlzcyBwYWNrZXRzLCBtYXkgZmFp bCB0byBjcmVhdGUgYmluZGluZ3MsIG1heSBwb2ludCBvbiBhbiBpbmNvcnJlY3QgbG9jYXRpb24g YXMgd2VsbC4NCg0KU28gSeKAmWQgc2F5IHRoYXQgaWYgd2UgcHVibGlzaCBhcyBSRkMsICB3ZSBz aG91bGQgYWxzbyBpbmRpY2F0ZSB0aGF0IHdpdGggZHJhZnQtaWV0Zi02bG8tYXAtbmQsIHdlICh3 aWxsKSBoYXZlIGEgbW9yZSByb2J1c3Qgc29sdXRpb24gZm9yIGRldmljZXMgdGhhdCBhcmUgd2ls bGluZyB0byBhbm5vdW5jZSB0aGVtc2VsdmVzLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KRnJvbTog aXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xpdHRp DQpTZW50OiB2ZW5kcmVkaSAxOSBvY3RvYnJlIDIwMTggMDI6MDcNClRvOiBTdXJlc2ggS3Jpc2hu YW4gPFN1cmVzaEBrYWxvb20uY29tPg0KQ2M6IHY2b3BzQGlldGYub3JnIFdHIDx2Nm9wc0BpZXRm Lm9yZz47IElFVEYgSVB2NiBNYWlsaW5nIExpc3QgPGlwdjZAaWV0Zi5vcmc+OyBvcHNlY0BpZXRm Lm9yZzsgZGhjd2dAaWV0Zi5vcmc7IGludC1hcmVhQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbZGhjd2ddIENvbnNpZGVyaW5nIEFEIHNwb25zb3JpbmcgZHJhZnQtYmkt c2F2aS13bGFuLTE1DQoNCk9uIEZyaSwgT2N0IDE5LCAyMDE4IGF0IDc6MzggQU0gU3VyZXNoIEty aXNobmFuIDxTdXJlc2hAa2Fsb29tLmNvbTxtYWlsdG86U3VyZXNoQGthbG9vbS5jb20+PiB3cm90 ZToNCiAgIEkgYW0gY29uc2lkZXJpbmcgQUQgc3BvbnNvcmluZyB0aGUgZm9sbG93aW5nIGRyYWZ0 DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaS1zYXZpLXdsYW4tMTUNCg0K dGhhdCBkZXNjcmliZXMgYSBzb3VyY2UgYWRkcmVzcyB2YWxpZGF0aW9uIHNvbHV0aW9uIGZvciBX TEFOLiBJZiB5b3UgaGF2ZSBhbnkgY29uY2VybnMNCmVpdGhlciB3aXRoIHRoZSBjb250ZW50IG9m IHRoZSBkcmFmdCwgb3IgYWJvdXQgbWUgQUQgc3BvbnNvcmluZyBpdCBwbGVhc2UgbGV0IG1lIGtu b3cgYmVmb3JlIDIwMTgvMTEvMTguDQoNCkkgc2tpbW1lZCB0aGUgZHJhZnQuIEl0IGxvb2tzIHdl bGwtd3JpdHRlbiwgYW5kIGl0IGFkZHJlc3NlcyBhbiBpbXBvcnRhbnQgcHJvYmxlbSB3aGljaCBJ IHRoaW5rIGlzIHByb2JhYmx5IHNvbHZlZCBpbiAoZGlmZmVyZW50PykgcHJvcHJpZXRhcnkgd2F5 cyBvbiB2YXJpb3VzIGltcGxlbWVudGF0aW9ucyBpbiB0aGUgZmllbGQgdG9kYXkuIEknbSBub3Qg dmVyeSBmYW1pbGlhciB3aXRoIHRoZSBBRCBzcG9uc29yc2hpcCBwcm9jZXNzLCBzbyBub3Qgc3Vy ZSB3aGF0IHRoZSBoYXMgdG8gaGFwcGVuIGZyb20gYSBwcm9jZXNzIHBlcnNwZWN0aXZlLiBCdXQg SSB0aGluayB0aGUgZG9jdW1lbnQgcmVxdWlyZXMgZnVydGhlciByZXZpZXcsIGVzcGVjaWFsbHkg Z2l2ZW4gdGhhdCBpdCdzIG1ha2luZyBzdGF0ZW1lbnRzIGFib3V0IHZlcnkgd2lkZWx5LWRlcGxv eWVkIHNjZW5hcmlvcyAoSVB2NiBvdmVyIHdpZmkpLiBTaG91bGQgdGhlIGRvY3VtZW50IGJlIGFk b3B0ZWQgYnkgYSBXRyBzdWNoIGFzIDZtYW4gb3IgdjZvcHM/IElmIG5vdCwgaXQgc2hvdWxkIGRl ZmluaXRlbHkgYmUgcmV2aWV3ZWQgYnkgdGhvc2UgV0dzLg0KDQpBcyBhIGNvbmNyZXRlIGV4YW1w bGUsIGhlcmUgYXJlIHNvbWUgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSByZXNvbHZlZCBiZWZvcmUg dGhlIGRvY3VtZW50IGFkdmFuY2VzOg0KDQogIDEuICBUaGUgcHJvcG9zZWQgc2NoZW1lIHJlbGll cyBvbiBEQUQgcGFja2V0cyB0byBjcmVhdGUgbWFwcGluZyBlbnRyaWVzLiBUaGF0IG1lYW5zIHRo YXQgaWYgYSBEQUQgcGFja2V0IGlzIGxvc3QgKHdoaWNoIGNhbiBoYXBwZW4gZXZlbiB0aG91Z2gg ODAyLjExIGVtcGxveXMgcmV0cmFuc21pc3Npb25zIGF0IEwyKSwgYSBzdGF0aW9uIGNvdWxkIGhh dmUgYW4gSVB2NiBhZGRyZXNzIHRoYXQgZG9lc24ndCB3b3JrIHdpdGggbm8gaW5kaWNhdGlvbiB0 aGF0IGl0J3Mgbm90IHdvcmtpbmcuIFRoaXMgaXMgYmFzaWNhbGx5IGEgbm9uLXJlY292ZXJhYmxl IG91dGFnZS4gUGVyaGFwcyB0aGUgZG9jdW1lbnQgc2hvdWxkIHNwZWNpZnkgYW5vdGhlciBzb2x1 dGlvbiBpbnN0ZWFkLCBlLmcuLCBpdCBjb3VsZCBzYXkgdGhhdCBtYXBwaW5nIGVudHJpZXMgY291 bGQgYmUgY3JlYXRlZCB3aGVuIGEgd2lyZWQgc3RhdGlvbiByZWNlaXZlcyBhIHNvbGljaXRlZCBO QSByZXNwb25zZSBmcm9tIGEgd2lyZWxlc3Mgc3RhdGlvbi4NCiAgMi4gIFRoZSBkb2N1bWVudCBz YXlzIHRoYXQgdGhlIGxpZmV0aW1lIG9mIFNMQUFDIGFkZHJlc3NlcyBpcyB0aGUgYWRkcmVzcyBs aWZldGltZSwgYnV0IHRoZSBuZXR3b3JrIGhhcyBubyB3YXkgb2Yga25vd2luZyB3aGF0IHRoZSBh ZGRyZXNzIGxpZmV0aW1lIGlzIGJlY2F1c2UgaXQgZGVwZW5kcyBvbiB3aGljaCBSQShzKSB0aGUg aG9zdCBoYXMgcmVjZWl2ZWQuDQoNCkNoZWVycywNCkxvcmVuem8NCg== --_000_da54096864fc4b508931eea7203ae8acXCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NDc3NDk2MjAzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDEwMTE0MjY0O30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsJm5ic3A7OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0 aCBMb3JlbnpvLCB0aGlzIHNjaGVtZSBpcyBhdCBhIGhpZ2ggbGV2ZWwgd2hhdCB3ZSBjYW4gZmlu ZCBpbiBjb21tZXJjaWFsIHByb2R1Y3RzLCBhbmQgSSBoYXZlIGZpcnN0LWhhbmQgZXhwZXJpZW5j ZSBvbiB0aGF0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5B cyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCB0aGlzIFJGQyBjb3VsZCBiZSBhIHVzZWZ1bCBy ZWZlcmVuY2UgdG8gY29uc2lkZXIgaWYgd2Ugd2VyZSB0byBjaGFuZ2UgdGhlIHByb3RvY29scyBp biBhIHdheSB0aGF0IHdvdWxkIGltcGFjdCB0aG9zZSBleGlzdGluZyBhbmQNCiBub24tc3RhbmRh cmQgc25vb3BpbmcgYmVoYXZpb3JzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U25vb3BpbmcgaGFzIHBy b3ZlbiB0byBiZSB2ZXJ5IHVzZWZ1bCwgYnV0IGFzIG9uZSBtYXkgZ3Vlc3MsIGl0IGlzIG5vdCBy ZWxpYWJsZTsgaXQgbWF5IG1pc3MgcGFja2V0cywgbWF5IGZhaWwgdG8gY3JlYXRlIGJpbmRpbmdz LCBtYXkgcG9pbnQgb24gYW4gaW5jb3JyZWN0IGxvY2F0aW9uDQogYXMgd2VsbC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIEnigJlkIHNheSB0aGF0IGlmIHdl IHB1Ymxpc2ggYXMgUkZDLCAmbmJzcDt3ZSBzaG91bGQgYWxzbyBpbmRpY2F0ZSB0aGF0IHdpdGgg ZHJhZnQtaWV0Zi02bG8tYXAtbmQsIHdlICh3aWxsKSBoYXZlIGEgbW9yZSByb2J1c3Qgc29sdXRp b24gZm9yIGRldmljZXMgdGhhdCBhcmUgd2lsbGluZw0KIHRvIGFubm91bmNlIHRoZW1zZWx2ZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYXNjYWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGlwdjYgJmx0O2lwdjYtYm91bmNlc0BpZXRm Lm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2Vu dDo8L2I+IHZlbmRyZWRpIDE5IG9jdG9icmUgMjAxOCAwMjowNzxicj4NCjxiPlRvOjwvYj4gU3Vy ZXNoIEtyaXNobmFuICZsdDtTdXJlc2hAa2Fsb29tLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHY2 b3BzQGlldGYub3JnIFdHICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IElFVEYgSVB2NiBNYWlsaW5n IExpc3QgJmx0O2lwdjZAaWV0Zi5vcmcmZ3Q7OyBvcHNlY0BpZXRmLm9yZzsgZGhjd2dAaWV0Zi5v cmc7IGludC1hcmVhQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtkaGN3Z10gQ29uc2lkZXJpbmcgQUQgc3BvbnNvcmluZyBkcmFmdC1iaS1zYXZpLXds YW4tMTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE9jdCAxOSwgMjAxOCBhdCA3OjM4IEFNIFN1cmVzaCBL cmlzaG5hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOlN1cmVzaEBrYWxvb20uY29tIj5TdXJlc2hAa2Fs b29tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0kgYW0gY29uc2lkZXJpbmcgQUQg c3BvbnNvcmluZyB0aGUgZm9sbG93aW5nIGRyYWZ0PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpLXNhdmktd2xhbi0xNSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaS1zYXZpLXdsYW4tMTU8L2E+ PGJyPg0KPGJyPg0KdGhhdCBkZXNjcmliZXMgYSBzb3VyY2UgYWRkcmVzcyB2YWxpZGF0aW9uIHNv bHV0aW9uIGZvciBXTEFOLiBJZiB5b3UgaGF2ZSBhbnkgY29uY2VybnM8YnI+DQplaXRoZXIgd2l0 aCB0aGUgY29udGVudCBvZiB0aGUgZHJhZnQsIG9yIGFib3V0IG1lIEFEIHNwb25zb3JpbmcgaXQg cGxlYXNlIGxldCBtZSBrbm93IGJlZm9yZSAyMDE4LzExLzE4LjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBza2ltbWVkIHRoZSBk cmFmdC4mbmJzcDtJdCBsb29rcyB3ZWxsLXdyaXR0ZW4sIGFuZCBpdCBhZGRyZXNzZXMgYW4gaW1w b3J0YW50IHByb2JsZW0gd2hpY2ggSSB0aGluayBpcyBwcm9iYWJseSBzb2x2ZWQgaW4gKGRpZmZl cmVudD8pIHByb3ByaWV0YXJ5IHdheXMgb24gdmFyaW91cyBpbXBsZW1lbnRhdGlvbnMgaW4gdGhl IGZpZWxkIHRvZGF5LiBJJ20gbm90IHZlcnkgZmFtaWxpYXIgd2l0aCB0aGUgQUQgc3BvbnNvcnNo aXANCiBwcm9jZXNzLCBzbyBub3Qgc3VyZSB3aGF0IHRoZSBoYXMgdG8gaGFwcGVuIGZyb20gYSBw cm9jZXNzIHBlcnNwZWN0aXZlLiBCdXQgSSB0aGluayB0aGUgZG9jdW1lbnQgcmVxdWlyZXMgZnVy dGhlciByZXZpZXcsIGVzcGVjaWFsbHkgZ2l2ZW4gdGhhdCBpdCdzIG1ha2luZyBzdGF0ZW1lbnRz IGFib3V0IHZlcnkgd2lkZWx5LWRlcGxveWVkIHNjZW5hcmlvcyAoSVB2NiBvdmVyIHdpZmkpLiBT aG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgYnkNCiBhIFdHIHN1Y2ggYXMgNm1hbiBvciB2 Nm9wcz8gSWYgbm90LCBpdCBzaG91bGQgZGVmaW5pdGVseSBiZSByZXZpZXdlZCBieSB0aG9zZSZu YnNwO1dHcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgYSBjb25jcmV0ZSBleGFtcGxlLCBoZXJlIGFyZSBzb21lIHRoaW5ncyB0aGF0IG5l ZWQgdG8gYmUgcmVzb2x2ZWQgYmVmb3JlIHRoZSBkb2N1bWVudCBhZHZhbmNlczo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBwcm9wb3NlZCBzY2hl bWUgcmVsaWVzIG9uIERBRCBwYWNrZXRzIHRvIGNyZWF0ZSBtYXBwaW5nIGVudHJpZXMuIFRoYXQg bWVhbnMgdGhhdCBpZiBhIERBRCBwYWNrZXQgaXMgbG9zdCAod2hpY2ggY2FuIGhhcHBlbiBldmVu IHRob3VnaCA4MDIuMTEgZW1wbG95cyByZXRyYW5zbWlzc2lvbnMgYXQgTDIpLCBhIHN0YXRpb24g Y291bGQgaGF2ZSBhbiBJUHY2IGFkZHJlc3MgdGhhdCBkb2Vzbid0IHdvcmsgd2l0aCBubyBpbmRp Y2F0aW9uIHRoYXQNCiBpdCdzIG5vdCB3b3JraW5nLiBUaGlzIGlzIGJhc2ljYWxseSBhIG5vbi1y ZWNvdmVyYWJsZSBvdXRhZ2UuIFBlcmhhcHMgdGhlIGRvY3VtZW50IHNob3VsZCBzcGVjaWZ5IGFu b3RoZXIgc29sdXRpb24gaW5zdGVhZCwgZS5nLiwgaXQgY291bGQgc2F5IHRoYXQgbWFwcGluZyBl bnRyaWVzIGNvdWxkIGJlIGNyZWF0ZWQgd2hlbiBhIHdpcmVkIHN0YXRpb24gcmVjZWl2ZXMgYSBz b2xpY2l0ZWQgTkEgcmVzcG9uc2UgZnJvbSBhIHdpcmVsZXNzIHN0YXRpb24uPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhl IGRvY3VtZW50IHNheXMgdGhhdCB0aGUgbGlmZXRpbWUgb2YgU0xBQUMgYWRkcmVzc2VzIGlzIHRo ZSBhZGRyZXNzIGxpZmV0aW1lLCBidXQgdGhlIG5ldHdvcmsgaGFzIG5vIHdheSBvZiBrbm93aW5n IHdoYXQgdGhlIGFkZHJlc3MgbGlmZXRpbWUgaXMgYmVjYXVzZSBpdCBkZXBlbmRzIG9uIHdoaWNo IFJBKHMpIHRoZSBob3N0IGhhcyByZWNlaXZlZC48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9yZW56bzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_da54096864fc4b508931eea7203ae8acXCHRCD001ciscocom_-- From nobody Fri Oct 19 09:50:42 2018 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 393BE130F81 for ; Fri, 19 Oct 2018 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erpof_44pFKA for ; Fri, 19 Oct 2018 09:50:38 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFAB412F295 for ; Fri, 19 Oct 2018 09:50:37 -0700 (PDT) Received: from tpw09926dag18h.domain1.systemhost.net (10.9.212.42) by RDW083A009ED65.bt.com (10.187.98.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 17:50:18 +0100 Received: from tpw09926dag08e.domain1.systemhost.net (10.9.202.35) by tpw09926dag18h.domain1.systemhost.net (10.9.212.42) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 19 Oct 2018 17:50:34 +0100 Received: from RDW083A012ED68.bt.com (10.187.98.38) by tpw09926dag08e.domain1.systemhost.net (10.9.202.35) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Fri, 19 Oct 2018 17:50:33 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (23.103.134.183) by smtpe1.intersmtp.com (62.239.224.234) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 17:49:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=he8TulmviE4F/2ULtRgVdSyCIuLC/2EhRfYsLHpAmoU=; b=MwJ8hNhvwS+WrubYobPtA7jycFVxzIw1jcyIZU1h+cYdY2egADsKAhRpw0fC5EzfCZmz3ZcKi05C6dYCWGT7QPRjtmQGOSgvcwki3fZzydIUpjYLno79B4P73eRnTu629iicYSq+p0biQbJsPpT+eZOwBkKpc2+XMc3uXlboGC0= Received: from LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM (10.166.252.7) by LOXP123MB0933.GBRP123.PROD.OUTLOOK.COM (10.166.251.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.29; Fri, 19 Oct 2018 16:50:33 +0000 Received: from LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM ([fe80::45bc:9ce8:e18:22b5]) by LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM ([fe80::45bc:9ce8:e18:22b5%3]) with mapi id 15.20.1228.035; Fri, 19 Oct 2018 16:50:33 +0000 From: To: Thread-Topic: iOS12 IPv6-only Thread-Index: AdRnyxwF+cC5CHuRS/+94rl96Gg3sA== Date: Fri, 19 Oct 2018 16:50:32 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [77.97.239.204] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LOXP123MB0933; 6:VoOzosFQDLmdQ3yRvRk/K4t9LC+dljxDsCL9TXyR3KO6rAVdu3V1cd6g24+o1n83ApUWREbuzzxj+TGkudgwjjviimz16FTjKzkx1SwEd2WsDiAM9OVvq62HWgfJ0l9efH67pbizr4umyQvMn43jOWWZl5EPrFMTDZ4WrKRIsvz3ncUl8Laxas0ZCqYQsWLRpovIwDMVbNCSlOUcKCMkxJZsNZaO4GZPKpevh1SG0Psml36vNsle/+5m4ErPo2u63cNRKE+5pDhLAaW0fTqjPCUaeNi/oftl0kpGfomgOX30uwuwPjc4KziQJ1h1oHpMz67ay8DGO9FpchdoeAm5DsKWjb6OHZ3PEeeXbaq4eNub4YOJuywSRJiFtWZ5vSCcrE12FmU90NeowML87J6h9a+tnEF8+fS8wclyZGEFSodfM0i8iV3M6LqvrXaoQlRoGUyChiRxSiTTGkUncIdQjQ==; 5:eGHT11nAPJhrAgmyGGdryvckAdJl5ccFGxXxdlLvefQdRTIbDVTGS1YNG1EGTrDHIHZIeoC6Ee5kMKlaS2+ZkLJdfnIOPlfkP8GqBIQzo641PavOkfCmWuOWeYN0g/eJLH0bPrhtntChqu32CnjkJ23XmjcFXxI5ZCAl7a58WDQ=; 7:vzmH5AQ3B364mrLFiUO9oRF8Th53uQ5YbhQJObRDrh3r3gMtRYJRl7c1CgecNWSAYHw95TQRGliZCzROupvsmTUelRuS8mKIi5rxMu/QxoB98lR8GWbv4d8EJKgrT/PkYS3MxGMlS8xi7/BXtcA/OOV0Bie8sWrij6LSRcR+tmE5euszJkyBUcqPNEJohOQgliCk2Lh3RssTIvLfb3XPpYyK/JpSUPzur3hRQXVEqmi00iN6xQS2ABtbM4gHzMp7 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e9baa3cb-5608-478a-0335-08d635e2fc3b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:LOXP123MB0933; x-ms-traffictypediagnostic: LOXP123MB0933: x-antispam-2: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:LOXP123MB0933; BCL:0; PCL:0; RULEID:; SRVR:LOXP123MB0933; x-forefront-prvs: 0830866D19 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(396003)(136003)(199004)(189003)(966005)(97736004)(14454004)(66066001)(102836004)(316002)(606006)(478600001)(6506007)(74316002)(486006)(7736002)(3846002)(6116002)(6436002)(790700001)(2900100001)(6916009)(476003)(86362001)(2906002)(236005)(9686003)(6306002)(54896002)(256004)(186003)(105586002)(71200400001)(26005)(106356001)(71190400001)(5250100002)(81156014)(81166006)(8676002)(68736007)(99286004)(53936002)(7696005)(55016002)(8936002)(33656002)(25786009)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:LOXP123MB0933; H:LOXP123MB1063.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OaXaPfYIHk9X0SlKN2vCTbRPtWP3w5xx1k/FwHmqjnZLfEOFef7dgVqqohvx6mOjZ7qRmhDyPSRfLny0FRyGjQXnSVixNtZse9k150ULCwMV23UtYOeX5Wp1LO3E1RSQ5PpxomNNE6TxGY2lCkE9yvSZTohhT8e26d8ngrHX9YPhjspHTvo6wHEHg+Y3xZ7WC6MMq5RTAzbkrMgLiEM0NGhvl6GBNYi4bHcaUjKSHAR6fGptd5O3wvGVcU518QwDAI70w1ySRlObK8fZylpYKIaVw08A57n4EW/rNcn0EvsTs2yVwG8/9SuY2GbXe3EzKLXGfMUfQ2a+n1t9hA8ScpOvMbGUFq1sT6Yj4z1L3zk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LOXP123MB10635A010A29B7D29B22473BEAF90LOXP123MB1063GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9baa3cb-5608-478a-0335-08d635e2fc3b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 16:50:32.9173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOXP123MB0933 X-OriginatorOrg: bt.com Archived-At: Subject: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 16:50:41 -0000 --_000_LOXP123MB10635A010A29B7D29B22473BEAF90LOXP123MB1063GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, I want to mention iOS12 is driving our IPv6-only rollout. Thanks to Apple make use of 464xlat for tethering (i.e. specific to wifi te= thering interface to cellular), this has allowed us to skip dualstack on ou= r common APN. So I believe onboard apps just use Happy Eyeballs v2. Nick https://stats.labs.apnic.net/ipv6/AS12576?a=3D12576&c=3DGB&x=3D1&s=3D0&p=3D= 1&w=3D15 --_000_LOXP123MB10635A010A29B7D29B22473BEAF90LOXP123MB1063GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

I want to mention iOS12 is driving our IPv6-only rol= lout.

Thanks to Apple make use of 464xlat for tethering (i= .e. specific to wifi tethering interface to cellular), this has allowed us = to skip dualstack on our common APN.

So I believe onboard apps just use Happy Eyeballs v2= .

Nick

https://sta= ts.labs.apnic.net/ipv6/AS12576?a=3D12576&c=3DGB&x=3D1&s=3D0&= ;p=3D1&w=3D15

 

 

--_000_LOXP123MB10635A010A29B7D29B22473BEAF90LOXP123MB1063GBRP_-- From nobody Fri Oct 19 10:36:34 2018 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 4BF50130DDC for ; Fri, 19 Oct 2018 10:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8Z10YohoP81 for ; Fri, 19 Oct 2018 10:36:29 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001093.outbound.protection.outlook.com [40.92.1.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA60130F73 for ; Fri, 19 Oct 2018 10:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J8pk479nVqylAqPMujuDNfxp7iDD794pDxTr88vIBhA=; b=fhE1ob8eyltIq5EhxVmMp5RlVv5z5n8jnACLDw17nXASkNRFxrytyELBseyjmRkOyPHqQdsRQIJU4tW4IP1ENIhEedILfxFb5FtUnpKminLQhSXhgCNfyr8WZxs6ukjmJtbMUEV9y8qkIqX1H849m0jlkanulkyRQ3bb329rxLKs1ny3UmrUZ9uWdWo14iBV/9Zecktuyigl/NdI18dwGq6qIx+vJWomf2S/HYHjZoPuNbLPNYK8wd6IUTOhlTeMmnJXUsuLKOqJl0fiXSp6BtX8ZU8BWQj9FHVwiLsxnbEICjKes2W/ilLxMF3JtRHBOEWtG3/5rHDrkLeJYp+obw== Received: from BN3NAM01FT024.eop-nam01.prod.protection.outlook.com (10.152.66.58) by BN3NAM01HT005.eop-nam01.prod.protection.outlook.com (10.152.66.255) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.12; Fri, 19 Oct 2018 17:36:28 +0000 Received: from BN6PR04MB0932.namprd04.prod.outlook.com (10.152.66.54) by BN3NAM01FT024.mail.protection.outlook.com (10.152.67.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.12 via Frontend Transport; Fri, 19 Oct 2018 17:36:28 +0000 Received: from BN6PR04MB0932.namprd04.prod.outlook.com ([fe80::5134:457b:5abf:9266]) by BN6PR04MB0932.namprd04.prod.outlook.com ([fe80::5134:457b:5abf:9266%4]) with mapi id 15.20.1228.035; Fri, 19 Oct 2018 17:36:28 +0000 From: Kristian McColm To: "nick.heatley@bt.com" , "v6ops@ietf.org" Thread-Topic: iOS12 IPv6-only Thread-Index: AdRnyxwF+cC5CHuRS/+94rl96Gg3sAABtPiw Date: Fri, 19 Oct 2018 17:36:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:D94E6A6E2A09A5BA4F7C31E5F38ADAE3079B627C58C30DE5F8EF914453093CBB; UpperCasedChecksum:D4F219DDFE0CF9B859036C40CB9346F0A5B5D5DB5B314705B3F98947CE54758F; SizeAsReceived:7173; Count:45 x-tmn: [v8Og9XmQLPVLUXIn95msALR7Tib1C9PLgfOXB2Q1FVComKxnyXsO8e8COn+9+SYAsJRST4p4hJg=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT005; 6:3eHQLcntbjnijsvKo3hp3qpbtAinEmsro+rCBSw4G3W+seKdB7Ft2KQN0bpUOy0hFZryLIrW8vhVZZuBEe0443whhoxE9GdpQZXSK6fNWcvIaFT+4/gh6cIRHzIZz81bGOpbMkyJg/rB4qft+kNpNT6jldfcq45eiTfYAl2gftkTaRuCFVL00T8aGe2YneuPGqBVBKcVlkgANbDHa2gzi9saTEnS2I9G54lzhX1K4MLjllWlhk6HRbW+hkdoH4468QwIezJaozfCSZLiX3mbT3RpbUfLjc4MC7SjydeWQAZj5RI9yEbFifafFgTqbp8dJI7bxwef0W8Ekd11kY0U1iQO7GofxBQGl14bLZMb+Z8KWx5lhPyiI2PqZfdee9ypIvg0YnJgEhRPGJo/8SAIatIH9huCQOochJdhVV4n1Tvy/cZ3cPLleIAa5k7/3NGk/ESAdQhPlwdU0U02FQf1Ug==; 5:gWfe91vfV8t7TWO3hD+ZgsmTzGqo99gGzANmC1xhZbhYJlFmwXwyBMtgbPfnPFXpVtvkqWrHJ3DdR/FE+EZH2g7dRDUy2l8OMqRsx5tz8ggoDgoJ02ONFWRtHdDNoIqxrRvM+7gHA5y/SxYwFn6deIABeiwQdgfS41BOedJu6QQ=; 7:amXIWwUWW/o9WoWh7WuYbSZ4Qc8WFva9rIp2uI6HhdURMQQhQn5orfvpqZFNkdmtMn13baAlohJufsmckNULcHLvtVORmvSnxsx1UNOynQIqJyhD/ob9GkNxYWDIpizFbSfS7rmTZ8bvuHyp/Z3Sb8Bcir4XMPm8k5D9OHbp8CXHYldZ8jPzZymlw8zTI3s/m9xDIt0Yn/XlOCF2VqDC/1Et5/+91ZVwT0Z9TAx3sFvuFE+zOwTP5tdPEjyIxLAF x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:BN3NAM01HT005; x-ms-traffictypediagnostic: BN3NAM01HT005: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BN3NAM01HT005; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT005; x-microsoft-antispam-message-info: aZmmUXi9IOUF3+CAq7ZEb90aiSH4Cj6jZo/aVzdoavDT1Jbk0hU8g9AmG3dKsYZG Content-Type: multipart/alternative; boundary="_000_BN6PR04MB09324A430D26E18D302CF63FDDF90BN6PR04MB0932namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: 553418f3-9637-4965-d0a8-08d635e96683 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 17:36:28.1719 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT005 Archived-At: Subject: Re: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 17:36:32 -0000 --_000_BN6PR04MB09324A430D26E18D302CF63FDDF90BN6PR04MB0932namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nick, That's good news! Do you know of any way to determine if 464XLAT/clat is ac= tive on the IOS12 device? With Android it was merely a matter of bringing u= p a shell with adb and looking for the clat interface but with IOS its not = so simple unfortunately. I am trying to determine under what conditions the clat is brought up on IO= S12 for selfish reasons. Regards Kristian From: v6ops On Behalf Of nick.heatley@bt.com Sent: October 19, 2018 12:51 To: v6ops@ietf.org Subject: [v6ops] iOS12 IPv6-only Hi folks, I want to mention iOS12 is driving our IPv6-only rollout. Thanks to Apple make use of 464xlat for tethering (i..e. specific to wifi t= ethering interface to cellular), this has allowed us to skip dualstack on o= ur common APN. So I believe onboard apps just use Happy Eyeballs v2.. Nick https://stats.labs.apnic.net/ipv6/AS12576?a=3D12576&c=3DGB&x=3D1&s=3D0&p=3D= 1&w=3D15 --_000_BN6PR04MB09324A430D26E18D302CF63FDDF90BN6PR04MB0932namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nick,

 

That’s good news! Do you know of any way to de= termine if 464XLAT/clat is active on the IOS12 device? With Android it was = merely a matter of bringing up a shell with adb and looking for the clat in= terface but with IOS its not so simple unfortunately.

 

I am trying to determine under what conditions the c= lat is brought up on IOS12 for selfish reasons.

 

Regards
Kristian

 

 

From: v6ops <v6ops-bounces@ietf.org> On Behalf Of nick.heatley@bt.com
Sent: October 19, 2018 12:51
To: v6ops@ietf.org
Subject: [v6ops] iOS12 IPv6-only

 

Hi folks,

I want to mention iOS12 is driv= ing our IPv6-only rollout.

Thanks to Apple make use of 464= xlat for tethering (i..e. specific to wifi tethering interface to cellular)= , this has allowed us to skip dualstack on our common APN.

So I believe onboard apps just = use Happy Eyeballs v2..

Nick

https://stats.labs.apnic.net/ipv6/AS12576?a=3D12576&c=3DGB&am= p;x=3D1&s=3D0&p=3D1&w=3D15

 

 

--_000_BN6PR04MB09324A430D26E18D302CF63FDDF90BN6PR04MB0932namp_-- From nobody Fri Oct 19 11:57:03 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A9113108F; Fri, 19 Oct 2018 11:56:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: v6ops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997538446.6592.11156681497621538567.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:24 -0700 Archived-At: Subject: [v6ops] v6ops - Requested session has been scheduled for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:31 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00 requested) Monday, 5 November 2018, Morning Session I 0900-1100 Room Name: Meeting 1 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/v6ops.ics Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: rtgwg mboned ipsecme dnsop grow intarea 6man ippm Second Priority: suit tsvwg opsec idr Third Priority: 6lo bess bier ccamp ipwave l2sm lsr lsvr mpls netmod nvo3 opsawg quic sfc teas People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 19 13:03:41 2018 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 DD442130FEE for ; Fri, 19 Oct 2018 13:03:39 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzH8fmFtU_q2 for ; Fri, 19 Oct 2018 13:03:36 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681E2130DD8 for ; Fri, 19 Oct 2018 13:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1539979413; x=1540584213; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=uoZ/QpznL8BokaYVh9LnpuabrHLiJoYV2yt9CALAXDQ=; b=wAnVX4M0TD+10 X7CYLtreL6s7QAlLJY9cIk3e4bpMS3q9DbonYJJaDY/P6zpNXV/lPrFaMUwzl982 FMya4kP/WBLlyvw4/I8hlxKNqrWet/2eeQldBWdvwBFKXhW8rWidzyeArUWEPby4 VIu1GgT4e5Db2P3qrvKhiwTo62thbk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 19 Oct 2018 22:03:33 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 19 Oct 2018 22:03:32 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005915851.msg for ; Fri, 19 Oct 2018 22:03:32 +0200 X-MDRemoteIP: 10.10.10.99 X-MDHelo: [10.10.10.99] X-MDArrival-Date: Fri, 19 Oct 2018 22:03:32 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=18302c4a18=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Fri, 19 Oct 2018 21:49:48 +0200 From: JORDI PALET MARTINEZ To: Mikael Abrahamsson CC: Message-ID: Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 20:03:40 -0000 Hi Mikael, Sorry, was coming back from the RIPE and arranging a small test to show you= the results, which are consistent with what I recall from my previous test= ing. I'm using an ubuntu VM as the server, running in ESXi 6.5, and as client my= own laptop. There is a Cisco switch between the server, the MT7621 device and my client= . Ubuntu VM in ESXi --- Cisco Gig switch --- MT7621 under test --- client dev= ice Server command: iperf3 -s 1) LAN-to-LAN test (so both the server and client are connected to the LANs= of the MT7621) iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 10.10.10.99 port 51300 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 113 MBytes 951 Mbits/sec =20 [ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 2.00-3.00 sec 112 MBytes 938 Mbits/sec =20 [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 4.00-5.00 sec 112 MBytes 936 Mbits/sec =20 [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 7.00-8.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 8.00-9.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 9.00-10.00 sec 112 MBytes 936 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec sende= r [ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec recei= ver 2) LAN-to-WAN NAT test without offloading iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 192.168.1.139 port 51447 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 48.8 MBytes 409 Mbits/sec =20 [ 4] 1.00-2.00 sec 45.8 MBytes 384 Mbits/sec =20 [ 4] 2.00-3.00 sec 45.2 MBytes 379 Mbits/sec =20 [ 4] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec =20 [ 4] 4.00-5.00 sec 45.0 MBytes 378 Mbits/sec =20 [ 4] 5.00-6.00 sec 44.9 MBytes 377 Mbits/sec =20 [ 4] 6.00-7.00 sec 45.2 MBytes 379 Mbits/sec =20 [ 4] 7.00-8.00 sec 45.1 MBytes 378 Mbits/sec =20 [ 4] 8.00-9.00 sec 45.3 MBytes 380 Mbits/sec =20 [ 4] 9.00-10.00 sec 45.2 MBytes 379 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec sende= r [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec recei= ver 3) LAN-to-WAN NAT test with SOFTWARE offloading iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 192.168.1.139 port 51484 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 98.4 MBytes 826 Mbits/sec =20 [ 4] 1.00-2.00 sec 98.2 MBytes 824 Mbits/sec =20 [ 4] 2.00-3.00 sec 96.9 MBytes 813 Mbits/sec =20 [ 4] 3.00-4.00 sec 97.6 MBytes 819 Mbits/sec =20 [ 4] 4.00-5.00 sec 98.2 MBytes 824 Mbits/sec =20 [ 4] 5.00-6.00 sec 96.5 MBytes 809 Mbits/sec =20 [ 4] 6.00-7.00 sec 96.0 MBytes 805 Mbits/sec =20 [ 4] 7.00-8.00 sec 96.1 MBytes 806 Mbits/sec =20 [ 4] 8.00-9.00 sec 97.8 MBytes 820 Mbits/sec =20 [ 4] 9.00-10.00 sec 97.5 MBytes 818 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 973 MBytes 816 Mbits/sec sende= r [ 4] 0.00-10.00 sec 971 MBytes 815 Mbits/sec recei= ver 4) LAN-to-WAN NAT test with HARDWARE offloading iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 192.168.1.139 port 51523 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 110 MBytes 926 Mbits/sec =20 [ 4] 1.00-2.00 sec 112 MBytes 938 Mbits/sec =20 [ 4] 2.00-3.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 3.00-4.00 sec 111 MBytes 935 Mbits/sec =20 [ 4] 4.00-5.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 7.00-8.00 sec 110 MBytes 923 Mbits/sec =20 [ 4] 8.00-9.00 sec 111 MBytes 934 Mbits/sec =20 [ 4] 9.00-10.00 sec 111 MBytes 933 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.09 GBytes 932 Mbits/sec sende= r [ 4] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec recei= ver Regarding CPU utilization, using htop, with both NO offloading and SW offlo= ading, it is evident that the CPU is being used reaching close to 100% of o= ne of the cores, a bit less in the others, while HW offloading CPU remains = with the 1-2% utilization. By the way the devices are cheap ones, different vendors, no difference if = I do the test with one or the other (tested with 3 different ones and got s= ame results). The most expensive one is probably around 30 USD (ZBT-WG3526-= 16M). I've used the stable builds and then upgraded everything to the latest vers= ions. https://downloads.openwrt.org/releases/18.06.1/targets/ramips/mt7621/ If you're interested and coming to BKK, I can bring one of them and we can = play a bit. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Fecha: jueves, 18 de octubre de 2018, 19:45 Para: JORDI PALET MARTINEZ CC: Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: =20 > Yes, 100% sure in this case. > > The SoC supports it with several SDKs/OSs: > > https://www.mediatek.com/products/homeNetworking/mt7621n-a > > You can enable HW or SW offloading, offers both options (didn't check= ed=20 > what is the difference, I just go for the HW if it works, as I guess= =20 > outperforms the SW one). =20 I know the MT7621 does what you're saying in other OSes with their SDK,= =20 I'm questioning if the -j FLOWOFFLOAD is the way to do HW acceleration = for=20 certain flows. Did you try to run full gig speed through it and check C= PU=20 usage? It's the easiest way to tell if the offload works or not. =20 It would be the least intrusive offload implementation I've ever seen i= n=20 Linux, so if it actually works this way I'd be very happy, and hope mor= e=20 vendors does it the same way. =20 Did you buy some retail device? If you did, what was it? =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Oct 19 22:11:29 2018 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 F2151130E30 for ; Fri, 19 Oct 2018 22:11:27 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_H9Bir0O2h6 for ; Fri, 19 Oct 2018 22:11:26 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5757129AB8 for ; Fri, 19 Oct 2018 22:11:25 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id y11-v6so5400331wma.3 for ; Fri, 19 Oct 2018 22:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=atlLKUrruJdlnr2lA3iAiLP9GS9x21NYMC1Mi8jh7EI=; b=OIHyYZhpYfFch4NdjMtdKA5YSBkWzsn65KgMa+OHPVhTe/QlO2kT5TsOlXuKYyxzcB W/QEKi/04sLTti8y+9i/Vj+9lRe7LqjNAQYJeCik3dxggybC7nwH1n8A7PsLZ9LaVVe2 fBggZaBVIoMVj1OcFW7krMGY7Dgdz6BkfeD7KBBy4X4PCM8kgJASDmwRZFlQgNhQrLk3 IUOUfJGY9eob4Br7MZEv7dcOF1WmkL815i0LCVblw1gZEt4mmkvOz1UYTl2/SlKt1Lm5 +dZ9+LoaISWTsMYPgSYYjjT0KXj4Q+exDBDgWlpdAzThfxH0QIygNKHn9M6TRyVyJsGS 8knA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=atlLKUrruJdlnr2lA3iAiLP9GS9x21NYMC1Mi8jh7EI=; b=bjpJSNzEIubmbnRM5qO0OcOG67rSdiAhtFRt43iOcp/iYz0XdyangoGY6b2Jg0CY/8 XyJ2UysCnwqf1j8yCOCEFkg5Lb4j9leshsm6ZkG/+tyIORewRlqs+njzLM2DPAQ9XqWl DNIzPPH+wRhaGYIV7FCvpBA7blYXusYRcyzDTpFly5oxbFuFD95yP10a9Gd4Je9H3tKx cWqNZSHJLyVzYWv4H/t1a0eSAa6pcdDn1HhDGLmc9RzNc1dUARvZQdSmZY9ng9o2k5En 7QIjeSKkYBlK+lpgAqLQEg30c4Z1uhrx8hZHmKh1GdpLzn4YIJoHj1xpeEq9LhzlytwA +9ug== X-Gm-Message-State: ABuFfogZzA7gJI2tuZ9OKAKhmRRElsjpwkCJ0Opmqgyba2esn3deeJYq MBHfudBxBgDqLIAoxqsWS9IjO8aybXI= X-Google-Smtp-Source: ACcGV60rIJBHSo/gWvOqUSlb5Acfkwc6/OA42Afaw2kTmGIj+oGdC8VxWVsSGkYtzSYm0meEXMZiRw== X-Received: by 2002:a1c:bce:: with SMTP id 197-v6mr7170542wml.15.1540012283929; Fri, 19 Oct 2018 22:11:23 -0700 (PDT) Received: from [192.168.50.230] ([213.27.245.162]) by smtp.gmail.com with ESMTPSA id y41-v6sm6249410wrd.25.2018.10.19.22.11.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Oct 2018 22:11:22 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_915289D1-A04B-45BF-BA40-B4AB9DDDC928"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: References: <153997538446.6592.11156681497621538567.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org list" Date: Sat, 20 Oct 2018 07:11:20 +0200 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Fwd: v6ops - Requested session has been scheduled for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 05:11:28 -0000 --Apple-Mail=_915289D1-A04B-45BF-BA40-B4AB9DDDC928 Content-Type: multipart/alternative; boundary="Apple-Mail=_4872C707-D6CE-4023-B37D-B6CA9B3C86D1" --Apple-Mail=_4872C707-D6CE-4023-B37D-B6CA9B3C86D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI > Begin forwarded message: >=20 > From: "\"IETF Secretariat\"" > Subject: v6ops - Requested session has been scheduled for IETF 103 > Date: October 19, 2018 at 8:56:24 PM GMT+2 > To: , > Cc: v6ops@ietf.org, warren@kumari.net >=20 > Dear Fred Baker, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. >=20 >=20 > v6ops Session 1 (2:00 requested) > Monday, 5 November 2018, Morning Session I 0900-1100 > Room Name: Meeting 1 size: 150 > --------------------------------------------- >=20 >=20 > iCalendar: https://datatracker.ietf.org/meeting/103/sessions/v6ops.ics >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 70 > Conflicts to Avoid: > First Priority: rtgwg mboned ipsecme dnsop grow intarea 6man ippm > Second Priority: suit tsvwg opsec idr > Third Priority: 6lo bess bier ccamp ipwave l2sm lsr lsvr mpls netmod = nvo3 opsawg quic sfc teas >=20 >=20 > People who must be present: > Fred Baker > Ron Bonica > Warren "Ace" Kumari >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_4872C707-D6CE-4023-B37D-B6CA9B3C86D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI

Begin forwarded message:

From: = "\"IETF Secretariat\"" <agenda@ietf.org>
Subject: = v6ops - Requested = session has been scheduled for IETF 103
Date: = October 19, 2018 at 8:56:24 PM = GMT+2
To: = <v6ops-chairs@ietf.org>, <fredbaker.ietf@gmail.com>
Cc: = v6ops@ietf.org, warren@kumari.net

Dear Fred Baker,

The session(s) that you have requested have = been scheduled.
Below is the scheduled session information = followed by
the original request.


   v6ops Session 1 (2:00 = requested)
   Monday, 5 November 2018, = Morning Session I 0900-1100
   Room Name: = Meeting 1 size: 150
=    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/103/sessions/v6ops.ics=

Request Information:


---------------------------------------------------------
Working Group Name: IPv6 Operations
Area Name: = Operations and Management Area
Session Requester: Fred = Baker

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of = Attendees: 70
Conflicts to Avoid:
First = Priority: rtgwg mboned ipsecme dnsop grow intarea 6man ippm
= Second Priority: suit tsvwg opsec idr
Third Priority: = 6lo bess bier ccamp ipwave l2sm lsr lsvr mpls netmod nvo3 opsawg quic = sfc teas


People who must be = present:
 Fred Baker
 Ron = Bonica
 Warren &quot;Ace&quot; Kumari

Resources Requested:

Special Requests:

---------------------------------------------------------


---------------------------------------------------------------= -----------------
The fact that = there is a highway to hell and a stairway to heaven is an interesting = comment on projected traffic volume...

= --Apple-Mail=_4872C707-D6CE-4023-B37D-B6CA9B3C86D1-- --Apple-Mail=_915289D1-A04B-45BF-BA40-B4AB9DDDC928 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvKuPkACgkQEhdRnd2G P+CG5xAAxGrKWh4vtrqJ5PfnFyCPmLga5TZS+cTkwZzEQGtL5h35wQ5K1/RUlS/J XXJ2GsNrFVxehxHK660a0fQNtV3USE3C57vW8aAAg9HGXbKBAxoUMwLw6KJqcPCR K0hZ6D8nFftwo3JWcFXUT1me4GF/3WQvcNicQANGdl4LVbfr60d6yHTMvE50Vikh SGBkP4XVEs+6fAkd/gUyDjIW5KxVbe5TLDdsauQiAY46c5xxXpiNFtG8SnwK4iUe Y4Y2aPooB/weBFduY7xGxeg9K/ur3ywwX4DRHTRzh2aG1kB56aRtaPS+gky0V06/ W7ipT3sGIqLVVkFL5SUjc6Tvw34DOIwu9z7JNC5WiCJ0ZDVOwjgCQAeBBmAcCcg8 LMVIjtxJ3uN5z6AHdtrkvJ/OZhHqkPR//v08tWrUN+xAHSWRsPA1pEjsTZkkJTex Xhg448eVIo6qCWbXX95k5vBt9rmunKJppbJsbMlOxuN0QGSMbZBz5N/WRfnRI3/6 ZA6JuX3S0Dq81IOnf/QD5kWofiekF0LyU2/RUzVdZ6PvyCezmkra0FrTrZH8/LLX DEqaxrudKYYMIw2jcWbdiIZoUqPWaCSt7hgyvylQx0JmoFKyOX8b/PrmZUnvL3F3 E1/bavTnqumeJdC+xGmaV1w3/gj45uLS4Czm0k30n42KSbEX/fY= =mpZZ -----END PGP SIGNATURE----- --Apple-Mail=_915289D1-A04B-45BF-BA40-B4AB9DDDC928-- From nobody Sat Oct 20 12:12:19 2018 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 1B0B3130EB4 for ; Sat, 20 Oct 2018 12:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZywJw15dghgg for ; Sat, 20 Oct 2018 12:12:15 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9188A130E14 for ; Sat, 20 Oct 2018 12:12:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9B51BB0; Sat, 20 Oct 2018 21:12:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1540062731; bh=2zJ/y+K9pKfL0xnRepzEjVoAobxa1y/4vpVsVmboApg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=OvHQP6Oy2mM6hTlZz8IAcqn1TdoZq2yvsUQU4VQ1WbF3G9hk5T2hsgahjmbT4jdmB OQhpQgJd9/hitN+RZeoCzDXuSjvB0POicpGMP2OvQecM0XFn3QiI7MSqbM9f3t1w+x YhB+dARNh0teIzwN1pzZdacOSNWCYlZsvEaRFjTE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 962F2AF; Sat, 20 Oct 2018 21:12:11 +0200 (CEST) Date: Sat, 20 Oct 2018 21:12:11 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 19:12:18 -0000 On Fri, 19 Oct 2018, JORDI PALET MARTINEZ wrote: > https://downloads.openwrt.org/releases/18.06.1/targets/ramips/mt7621/ > > If you're interested and coming to BKK, I can bring one of them and we can play a bit. Thanks, I will try to acquire one of these devices in the mean time. I will be at the hackathon on both saturday and sunday, so if you can bring one that'd be great in case I am not able to get one before then. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 22 00:12:23 2018 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 5103C130DE7 for ; Mon, 22 Oct 2018 00:12:21 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QqTDS4db6G3 for ; Mon, 22 Oct 2018 00:12:19 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5FE130DC2 for ; Mon, 22 Oct 2018 00:12:18 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id z9-v6so4874476qto.7 for ; Mon, 22 Oct 2018 00:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=15e22NmKa9j/awUIZXm5wo3/iZFFwGppgG9DskkXP/A=; b=AeZWH8leHwY6ykOVj34qevqkD6OuU07wKxCEjAJ1N1GuW6VYC4tTcAlzb/JW3eGwMM ezDzwbUPT3nNXLTZOTW1HP6Zkm0RGz8eqPcI2AjDWzT8dqK3Ueddce1bLIU0bFs4GEP4 lcaQw1pbp5Xx6spxXdm+okxIJYRCkuDmjSETQqjUkGvTWsGzITfLG781KNRoJymp7Fox SokNEsYhqaIzwTqsBXnE94LTcpwHLEG+dQI918zyWguL5XT7KW6hG3cmHxrzEx9HtOhZ 8xydSMSbGEj1DaKfbCEydCyEroN0ORIm4FcN5U59m7xMK4cPHmE7fRy/4b27eSm7JEX1 5vmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=15e22NmKa9j/awUIZXm5wo3/iZFFwGppgG9DskkXP/A=; b=LY7lzf6vLAAr5qN8GQ+zE3YM8rDlrbkd12+DRlpcwQIXRS5cADxwfaP5k6m2lpJQ3g wfAsVuAjBnQjX82099p8FVm8a48ChKsHWlP/fpdh1D8rfhDe8BisFnYIh0IG0kEddQe5 hUIFwjHEjOq03Iy9zgjp0/pcEh0MxuUaT3POag9GJeZzDS0J3sPVJ5aeY6O2PH2FcoNu 7wEru3CkXcJi9Vajn3u5AZS+xrTRDN8ZKxiHNjWosWR0pPP9l29OSixqNdlNf8KZHPu2 lSo1dAhFkgWrTnNHunXK1Xzvhgaz3cQX97nhEsOO7A2Ex+Gq8a0TMF1DhKM6SgdKp0VC rO4g== X-Gm-Message-State: ABuFfohP9Buz3SRP9SXSWusBMhoPxNdDGlgWq1vDpbBRSYM1Opax930j ei2Zf8Q6T9ooEb3XB5+pX/4WuN0y4clTg8zIvmGrbhptMG8= X-Google-Smtp-Source: ACcGV63YIwYdwOXh0+NTs2RndDF7/fZiSnc8x8v5HsZB+zIGNdNy8iyAedRlD58Wdl5QfiRnNU63Ti2h5QvsuqXQYQ8= X-Received: by 2002:ac8:939:: with SMTP id t54-v6mr41790428qth.169.1540192337867; Mon, 22 Oct 2018 00:12:17 -0700 (PDT) MIME-Version: 1.0 References: <154019189916.15300.12693242988091118713.idtracker@ietfa.amsl.com> In-Reply-To: <154019189916.15300.12693242988091118713.idtracker@ietfa.amsl.com> From: Davey Song Date: Mon, 22 Oct 2018 15:12:05 +0800 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000002f388e0578cbf986" Archived-At: Subject: [v6ops] Fwd: New Version Notification for draft-xie-v6ops-network-happyeyeballs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 07:12:22 -0000 --0000000000002f388e0578cbf986 Content-Type: text/plain; charset="UTF-8" Hi folks, A new version of NHE was submited. it takes plance of draft-v6ops-xie -network-happyeyeballs-00 with another name draft-xie-v6ops-network-happyeyeballs-00 to fit the ID naming rule. In this version we change it largely focusing on IPv6 performance measurement, IPv6 failure report (contributed by Jordi) and a use case as a work around by delaying AAAA record response. Comments are welcome. Best regards, Davey ---------- Forwarded message --------- From: Date: Mon, 22 Oct 2018 at 15:05 Subject: New Version Notification for draft-xie-v6ops-network-happyeyeballs-00.txt To: Chongfeng Xie , Jordi Palet Martinez < jordi.palet@theipv6company.com>, Linjian Song A new version of I-D, draft-xie-v6ops-network-happyeyeballs-00.txt has been successfully submitted by Linjian Song and posted to the IETF repository. Name: draft-xie-v6ops-network-happyeyeballs Revision: 00 Title: Network-side Happy Eyeballs based on accurate IPv6 measurement Document date: 2018-10-22 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-xie-v6ops-network-happyeyeballs-00.txt Status: https://datatracker.ietf.org/doc/draft-xie-v6ops-network-happyeyeballs/ Htmlized: https://tools.ietf.org/html/draft-xie-v6ops-network-happyeyeballs-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-xie-v6ops-network-happyeyeballs Abstract: During the period of IPv6 transition, both ISPs and ICPs (Internet Content Providers) care about user's experience in dual-stack networks. They hesitate to provide IPv6 to their users due to the fear of poor IPv6 performance. Network-based Happy Eyeballs (NHE) is proposed in this memo as an approach to facilitate ISPs to identify IPv6 connectivity issues and provide better connectivity to end users. NHE does accurate measurements and comparison on IPv6/IPv4 performance on the network side compared with client-side as in Happy Eyeballs v2 (HEv2) [RFC8305]. It works independently with client's adoption of HEv2 and both coexist without conflicting. REMOVE BEFORE PUBLICATION: The source of the document with test script is currently placed at GitHub [NHE-GitHub]. Comments and pull request are welcome. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000002f388e0578cbf986 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

A new version of NHE was submited.= it takes plance of=C2=A0 draft-v6ops-xie=C2=A0-network-happyeyeballs-00=C2=A0 with another name draft-xie-v6ops-network-happyeyeballs-00=C2=A0 to fit the ID naming rule.= =C2=A0

In this version we change it largely focusing on = IPv6 performance measurement, IPv6 failure report (contributed by Jordi) an= d a use case as a=C2=A0 work around by delaying AAAA record response.

Comments are welcome.

Best regards= ,
Davey
----------= Forwarded message ---------
From: <internet-drafts@ietf.org>
Dat= e: Mon, 22 Oct 2018 at 15:05
Subject: New Version Notification for draft= -xie-v6ops-network-happyeyeballs-00.txt
To: Chongfeng Xie <xiechf.bri@chinatelecom.cn>, Jor= di Palet Martinez <jor= di.palet@theipv6company.com>, Linjian Song <songlinjian@gmail.com>



A new version of I-D, draft-xie-v6ops-network-happyeyeballs-00.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-xie-v6ops-network-happy= eyeballs
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network-side Happy Eyeballs based = on accurate IPv6 measurement
Document date:=C2=A0 2018-10-22
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-xie-v= 6ops-network-happyeyeballs-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-xie-v6ops-network-happye= yeballs/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-xie-v6ops-network-happyeyeballs-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-xie-v6ops-network-h= appyeyeballs


Abstract:
=C2=A0 =C2=A0During the period of IPv6 transition, both ISPs and ICPs (Inte= rnet
=C2=A0 =C2=A0Content Providers) care about user's experience in dual-st= ack
=C2=A0 =C2=A0networks.=C2=A0 They hesitate to provide IPv6 to their users d= ue to the
=C2=A0 =C2=A0fear of poor IPv6 performance.=C2=A0 Network-based Happy Eyeba= lls (NHE) is
=C2=A0 =C2=A0proposed in this memo as an approach to facilitate ISPs to ide= ntify
=C2=A0 =C2=A0IPv6 connectivity issues and provide better connectivity to en= d
=C2=A0 =C2=A0users.=C2=A0 NHE does accurate measurements and comparison on = IPv6/IPv4
=C2=A0 =C2=A0performance on the network side compared with client-side as i= n Happy
=C2=A0 =C2=A0Eyeballs v2 (HEv2) [RFC8305].=C2=A0 It works independently wit= h client's
=C2=A0 =C2=A0adoption of HEv2 and both coexist without conflicting.

=C2=A0 =C2=A0REMOVE BEFORE PUBLICATION: The source of the document with tes= t
=C2=A0 =C2=A0script is currently placed at GitHub [NHE-GitHub].=C2=A0 Comme= nts and pull
=C2=A0 =C2=A0request are welcome.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--0000000000002f388e0578cbf986-- From nobody Mon Oct 22 03:23:13 2018 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 8BE751274D0 for ; Mon, 22 Oct 2018 03:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZja3hdIGEzL for ; Mon, 22 Oct 2018 03:23:08 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17A0130E02 for ; Mon, 22 Oct 2018 03:23:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9MAN5Ce188894 for ; Mon, 22 Oct 2018 12:23:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C055820502B for ; Mon, 22 Oct 2018 12:23:05 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B6CA82012BA for ; Mon, 22 Oct 2018 12:23:05 +0200 (CEST) Received: from [10.8.68.45] ([10.8.68.45]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9MAN4Qf021573 for ; Mon, 22 Oct 2018 12:23:05 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <42af202d-a7d0-ceec-96b7-244873a51260@gmail.com> Date: Mon, 22 Oct 2018 12:23:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 10:23:12 -0000 Le 19/10/2018 à 18:50, nick.heatley@bt.com a écrit : > Hi folks, > > I want to mention iOS12 is driving our IPv6-only rollout. > > Thanks to Apple make use of 464xlat for tethering (i..e. specific to > wifi tethering interface to cellular), this has allowed us to skip > dualstack on our common APN. I am happy to see IPv6-only rollout plan. But I do not understand what do you plan for IPv6 tethering? Do you use DHCPv6 Prefix Delegation? Alex > > So I believe onboard apps just use Happy Eyeballs v2.. > > Nick > > https://stats.labs.apnic.net/ipv6/AS12576?a=12576&c=GB&x=1&s=0&p=1&w=15 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Oct 22 04:14:02 2018 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 23BE0130E30 for ; Mon, 22 Oct 2018 04:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRNM0K5RZ7nV for ; Mon, 22 Oct 2018 04:13:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BB2128CF3 for ; Mon, 22 Oct 2018 04:13:50 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CEEA3B0; Mon, 22 Oct 2018 13:13:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1540206827; bh=24iBVnq8FUldJcC0boAS1agFmiCEotdqjGFPk9p7gVk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TvW+K6oAhJQTaoWeulM58HJOQ5U6/dk/UNCHxUnwX4hjOhzycvb8Vgf4ddd4966p8 xwkyu9qIdKpQFiPcMUnhxdJCodPr+Dq/NHq7J98HhwGNjgqFG5Z/XlwpVojy77a3Nj wfk6imi30niTOjLarcAR6Uee5Zy8G6z/zZbMIQ6g= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CBF58AF; Mon, 22 Oct 2018 13:13:47 +0200 (CEST) Date: Mon, 22 Oct 2018 13:13:47 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: <42af202d-a7d0-ceec-96b7-244873a51260@gmail.com> Message-ID: References: <42af202d-a7d0-ceec-96b7-244873a51260@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 11:14:01 -0000 On Mon, 22 Oct 2018, Alexandre Petrescu wrote: > But I do not understand what do you plan for IPv6 tethering? Do you use > DHCPv6 Prefix Delegation? All phones I am aware of use https://datatracker.ietf.org/doc/rfc7278/ (64SHARE) to extend the WAN /64 to a single LAN. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 22 10:57:38 2018 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 334DB130EBB for ; Mon, 22 Oct 2018 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuuC_vx0Fl7T for ; Mon, 22 Oct 2018 10:57:26 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 53D6C130E52 for ; Mon, 22 Oct 2018 10:57:26 -0700 (PDT) Received: from [192.168.1.8] (dusted.otenet.gr [195.167.126.245]) by calypso.otenet.gr (ESMTP) with ESMTPA id 9FD7C13803D; Mon, 22 Oct 2018 20:57:24 +0300 (EEST) To: Lee Howard , JORDI PALET MARTINEZ , v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <20180925072015.GV11393@Space.Net> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <5167BC92-DAC7-4F40-8DD4-E4A0ECEAC4BD@gmail.com> <3ecf8076-3056-94a5-1229-959cb2e38e6d@gmail.com> <96bb5ddb-95f9-2437-f0b2-b1274912bf3c@asgard.org> <998ee2b5-1506-db20-c09a-9eb13e6e4e38@otenet.gr> <4802145C-8FC0-46AD-95A8-7498C52F67FD@consulintel.es> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> From: Yannis Nikolopoulos Message-ID: <74b08f4c-8cd2-0726-7561-e88efa98d343@otenet.gr> Date: Mon, 22 Oct 2018 20:57:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 17:57:36 -0000 hello Lee, all On 10/18/18 10:08 AM, Lee Howard wrote: > Chairs, > > I'd be very interested in a lw4over6 experience report from Yannis. > > Yannis, I'm interested in hearing more about what isn't working well, > either on-line or directly. In no particular order: 1. CPE (almost OK after ~2 years and god knows how many iterations) 2. lwaftr performance (worth noting the the lwaftr is implemented as a VNF 3. vendor's reluctance to continue (much needed) dev/ment because of lack of interest from other ISPs > > Lee > > > On 10/15/2018 12:57 PM, Yannis Nikolopoulos wrote: >> >> In our case, we did not invest in CGN. We invested in preparing for >> IPv6 early, and so we did. When IPv4 exhaustion hit us, we did not >> decide to invest in either CGN or buying IPv4 addresses. Again , we >> invested in IPv6 (lw4o6). In the mean time between deploying lw4o6, >> we had to mitigate the issue, in a quick n dirty manner... that's >> when CGNcame into the picture. Some years later, we have a lot of CGN >> users and not so many in IPv6-only (lw4o6).  It just seems that, >> IPv6-only technologies (lw4o6 in our case) were not so straighforward >> to deploy and more importantly, not so cheap (performance-wise) >> either. Maybe the "stateless card" has been overplayed or exaggerated >> at the very least. >> >>> >>> Regards, >>> Jordi >>> >>> -----Mensaje original----- >>> De: v6ops en nombre de Yannis Nikolopoulos >>> >>> Fecha: lunes, 15 de octubre de 2018, 8:57 >>> Para: Lee Howard , >>> Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our >>> working group >>> >>>           On 9/28/18 8:47 PM, Lee Howard wrote: >>>      > Agreed, for now different people are choosing different >>> mechanisms, >>>      > and there isn't yet a clear winner. >>>           I've had this in my mailbox for days/weeks now. I just >>> wanted to write >>>      "are they? are they really?" . I don't see people choosing >>> mechanisms, >>>      people are not choosing mechanisms.People are deploying CGN en >>> masse, >>>      people are buying IPv4 addresses under the table or people are >>> just not >>>      touched by the IPv4 exhaustion. That is what people are doing, >>> at least >>>      most of them. And I wonder: what went wrong? 3-4 years ago, I was >>>      willing to bet that by 2017, fixed ISPs would've switched to >>> MAP or >>>      lw4o6. How wrong was I... I feel very disappointed . >>>           We switched to dual-stack about 10 years ago. 4 years ago, >>> we started >>>      considering our IPv6-only service options and we've been >>> running lw4o6 >>>      for the past 2 years. Our lw4o6 deployment is pretty small (40k >>> users >>>      out of 1.5M) still because of various issues: CPE is a pain, >>> DHCP is a >>>      pain, even lwaftr is a pain (more info can be provided on >>> request). Most >>>      importantly, we do not see the economy at scale here. CGN >>> (NAT444) is >>>      strangely cheaper and troubles-free. On top of that, we're >>> about to test >>>      it with IPv6 support. >>>           I'm called to present a case to mgmt and I despise the >>> fact that I've >>>      ran out of arguments for supporting an IPv6-only residential >>> service: >>>      the only one I have left is the trouble-free native IPv6 path, >>> but that >>>      doesn't really hold up since the percentage of complaining >>> users is so >>>      small. So, it comes down to that: we're about to have our lw4o6 >>>      deployment shut and our CGN is almost consuming half our userbase >>>      already. The future is bleak, indeed. I've even considered >>> 464xlat for >>>      everyone (since we're also a mobile carrier, where dual-stack >>> and CGN >>>      are deployed) >>>           thanks for listening, >>>      Yannis >>>           _______________________________________________ >>>      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 confidential. The information is intended to be for the exclusive >>> use of the individual(s) named above and further non-explicilty >>> authorized disclosure, copying, distribution or use of the contents >>> of this information, even if partially, including attached files, is >>> strictly prohibited and will be considered a criminal offense. If >>> you are not the intended recipient be aware that any disclosure, >>> copying, distribution or use of the contents of this information, >>> even if partially, including attached files, is strictly prohibited, >>> will be considered a criminal offense, so you must reply to the >>> original sender to inform about this communication and delete it. >>> >>> >>> >>> >> > From nobody Mon Oct 22 12:13:15 2018 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 950B4128766 for ; Mon, 22 Oct 2018 12:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxiRGk1hfCKR for ; Mon, 22 Oct 2018 12:12:56 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC7B130E46 for ; Mon, 22 Oct 2018 12:12:56 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-40-230.kabelnet.hu [79.121.40.230]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w9MJCjms086404 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 22 Oct 2018 21:12:51 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-40-230.kabelnet.hu [79.121.40.230] claimed to be [192.168.1.119] References: <154022456964.5779.4933276388358541182.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org list" From: =?UTF-8?Q?Lencse_G=c3=a1bor?= X-Forwarded-Message-Id: <154022456964.5779.4933276388358541182.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 22 Oct 2018 21:12:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154022456964.5779.4933276388358541182.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------5B700D2286E3E43C059A9744" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.40.230; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:13:06 -0000 This is a multi-part message in MIME format. --------------5B700D2286E3E43C059A9744 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, We have revised our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS". Special thanks to Ole Troan for his many correction recommendations, to Cameron Byrne for traffic statistics, and to everyone who contributed. Further comments are welcome. What kind of further aspects of comparison would be useful for you if you would need to choose an IPv4aaS technology for your network? Best regards, Gábor Lencse -------- Továbbított üzenet -------- Tárgy: New Version Notification for draft-lmhp-v6ops-transition-comparison-01.txt Dátum: Mon, 22 Oct 2018 09:09:29 -0700 Feladó: internet-drafts@ietf.org Címzett: Lee Howard , Jordi Palet , Jordi Palet Martinez , Gabor Lencse , Richard Patterson A new version of I-D, draft-lmhp-v6ops-transition-comparison-01.txt has been successfully submitted by Gabor Lencse and posted to the IETF repository. Name: draft-lmhp-v6ops-transition-comparison Revision: 01 Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS Document date: 2018-10-22 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-01.txt Status: https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ Htmlized: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison Diff: https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-01 Abstract: Several IPv6 transition technologies can be used to provide IPv4-as- a-service (IPv4aaS) to the customers, while the ISPs have only IPv6 in their access and or core network. All these technologies have their advantages and disadvantages. Depending on several various conditions and preferences, different technologies may prove to be the most appropriate solution. This document examines the five most prominent IPv4aaS technologies considering several different aspects in order to provide network operators with an easy to use guideline for selecting the technology that suit their needs the best. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------5B700D2286E3E43C059A9744 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

We have revised our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS".

Special thanks to Ole Troan for his many correction recommendations, to Cameron Byrne for traffic statistics, and to everyone who contributed.

Further comments are welcome.

What kind of further aspects of comparison would be useful for you if you would need to choose an IPv4aaS technology for your network?

Best regards,

Gábor Lencse

-------- Továbbított üzenet --------
Tárgy: New Version Notification for draft-lmhp-v6ops-transition-comparison-01.txt
Dátum: Mon, 22 Oct 2018 09:09:29 -0700
Feladó: internet-drafts@ietf.org
Címzett: Lee Howard <lee@asgard.org>, Jordi Palet <jordi.palet@theipv6company.com>, Jordi Palet Martinez <jordi.palet@theipv6company.com>, Gabor Lencse <lencse@hit.bme.hu>, Richard Patterson <richard.patterson@sky.uk> 


A new version of I-D, draft-lmhp-v6ops-transition-comparison-01.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

Name:		draft-lmhp-v6ops-transition-comparison
Revision:	01
Title:		Pros and Cons of IPv6 Transition Technologies for IPv4aaS
Document date:	2018-10-22
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-01.txt
Status:         https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
Htmlized:       https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison
Diff:           https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-01

Abstract:
   Several IPv6 transition technologies can be used to provide IPv4-as-
   a-service (IPv4aaS) to the customers, while the ISPs have only IPv6
   in their access and or core network. All these technologies have
   their advantages and disadvantages. Depending on several various
   conditions and preferences, different technologies may prove to be
   the most appropriate solution. This document examines the five most
   prominent IPv4aaS technologies considering several different aspects
   in order to provide network operators with an easy to use guideline
   for selecting the technology that suit their needs the best.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------5B700D2286E3E43C059A9744-- From nobody Mon Oct 22 19:29:41 2018 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 7A53B130E74; Mon, 22 Oct 2018 19:29:11 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt8YLsfCKHvU; Mon, 22 Oct 2018 19:29:07 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660130.outbound.protection.outlook.com [40.107.66.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090D4130F36; Mon, 22 Oct 2018 19:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gviCOrTXnc5P6q0Ry3ezOfze9Fjaz2+HdWP3Lvq4QRw=; b=JsIWn9ZLyj+TQfzr6+1RvA1/PVXHIdez/0SvlM5130cum52Yuo/rp2YxWsLfGZcvpSTuyKQdcO/QkPS+9vStg/aSSZNoRVTrfii9TsFuV4jp73C5RCaTy50MN3gxL3I2Hs/12DI7WJHkITqN2PzC5cP5ZHa0GY9flsvhhCg4pFU= Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM (10.169.141.148) by YQBPR01MB0162.CANPRD01.PROD.OUTLOOK.COM (10.169.141.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Tue, 23 Oct 2018 02:29:04 +0000 Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9af:2ac3:bd40:e2ea]) by YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9af:2ac3:bd40:e2ea%3]) with mapi id 15.20.1250.028; Tue, 23 Oct 2018 02:29:04 +0000 From: Suresh Krishnan To: "Pascal Thubert (pthubert)" , Lorenzo Colitti , Bernard Aboba CC: "v6ops@ietf.org WG" , IETF IPv6 Mailing List , "opsec@ietf.org" , "dhcwg@ietf.org" , "int-area@ietf.org" , "opsawg@ietf.org" Thread-Topic: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 Thread-Index: AQHUZzM4x98Ypd1MCEKu+GX87R2CxqUlsN0AgAD1IYCABXvvgA== Date: Tue, 23 Oct 2018 02:29:04 +0000 Message-ID: <3BB81D98-E70D-45B4-A99D-94AF29D89526@kaloom.com> References: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR01MB0162; 6:hKY6EHXUq5fsXAuQ5EDPGM9CMKwPtNNatWHwkRJWvqamtCGxdtoxkhuUBRhxl1gPFeJwCATZ8rgn6PlluRr8k0ayYiY2hNQ+dOyoW+QKZL/XgN125d8kE8+CRDqBTySRYs2G2pICYIUKvYYWADuyjleEO5IDZks9VcqAPyGHd7JFqohrTnYcRDZ8QSdZ0Ig4zol0buiUc/WN8+8DVPtd83C6zvljZzkaxXFrNDLrdwLK/d4VeuhVtl183YuSFIw3goqN4/QNZ3RpCby6RY4Ju+CjYmw8VuBGBOAtf/djyq/druGHuQvJfTSk9f5Cp/to0Rg156/k7p3keehuuPq+QaoN/pLnx5B+eVvhV32BWkarA158RIlSNqYJhFdivlLmezZpsyUedj+VIP2Br8RypuQhlByhi55X4/FHA9OOP9m+sLz7lyTc41ZMiB5+ATuvdHECCeYY7IjdJAf9ONIdtQ==; 5:KUmzyR2uMkFS4Vd8Nq+Y/vgyg5ihl2IuWkRWEGr+UEjGCTKsTEBm/JVNTY3JdsQKWXLoiaXgY1jguA/kNUKJNwPpBVgDSPAA2P+DRtz5m6a5L6c35NV/HZgSErNQnrfwI7bCH0oQTdyzs4dhJoE5UpPBK8YG5l7wZMwad6wyVqs=; 7:U7N5KMT5j/+AVcZfy3b+u/e8GeIEy6rXnUaZydJ/KNxTpL0LYrqoyh/d4rRUafmKEPoTibL6I/XQOORRFxR3hbpGcvOrc6rG+eGPTxyWR0o7H0drJiNkoN81QtVco09MXSvBQge/5W7IMXBcapfMbvJjh/EvyqHniOXnOrtU/Dxd81xoxm6SCvvncWBOByAGGhroevphOD7rX+G4ksVMORTJBeKLT/kpHaSRztDjFSfOPXVJZB4v05S9ygcqFho2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 89f38d46-92a0-411b-42ae-08d6388f4d07 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YQBPR01MB0162; x-ms-traffictypediagnostic: YQBPR01MB0162: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:YQBPR01MB0162; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0162; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39840400004)(396003)(366004)(376002)(199004)(189003)(83716004)(54906003)(54896002)(229853002)(508600001)(2900100001)(236005)(80792005)(105586002)(5250100002)(2906002)(71200400001)(476003)(39060400002)(72206003)(256004)(26005)(106356001)(36756003)(71190400001)(102836004)(76176011)(25786009)(4326008)(446003)(11346002)(2616005)(486006)(3846002)(97736004)(6116002)(81166006)(81156014)(6486002)(6436002)(316002)(606006)(6246003)(8676002)(186003)(86362001)(53546011)(99286004)(6506007)(14444005)(33656002)(966005)(14454004)(68736007)(53936002)(66066001)(6512007)(7736002)(8936002)(110136005)(82746002)(5660300001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:YQBPR01MB0162; H:YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GgZNIyAbYxucrAcJ7sF1ipgDR2kYGkpYyPyPkDN4Sp9qxHiUPw0arnrV0uPFK5AXJmaV6iV2GM7EjU7lVLiy63m28HKYsR+fUJSyCu+Q1xL+2wpHzG+3VB5GkhEaP15nqTrXHxVCovs16TmFElFmNJcW9F2jrATUkCdRC0wDiH+wAChRvV9UMSTD2cp9BGnox8iYaG2ac4fytCHwOlSE1j+cvaynTePKwCVUgoSa1pCvr45XP0pl49CFIGFv4Ud9gsFMwiogjNtaNXU2RcqgDaXHI/Knrkn6dy6n2gUgrWXsNBAp6jcGR6jRY77PoIirf96c+nIJYEOKbqnlfMr18Cs4/2wa1YlDL0WNsuCg/xQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3BB81D98E70D45B4A99D94AF29D89526kaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89f38d46-92a0-411b-42ae-08d6388f4d07 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 02:29:04.2679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0162 Archived-At: Subject: Re: [v6ops] [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 02:29:12 -0000 --_000_3BB81D98E70D45B4A99D94AF29D89526kaloomcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIExvcmVuem8sIFBhc2NhbCBhbmQgQmVybmFyZCBmb3IgeW91ciBjb21tZW50cy4gSSBo YXZlIGFza2VkIHRoZSBhdXRob3JzIHRvIHJlc3BvbmQgdG8geW91ciBjb21tZW50cyBvbiB0aGUg aW50YXJlYSBtYWlsaW5nIGxpc3QuIEFsc28sIEJlcm5hcmQgc3VnZ2VzdGVkIGEgODAyLjExIHJl dmlldyBvZiB0aGlzIGRyYWZ0LCBhbmQgSSBpbnRlbmQgdG8gcHVyc3VlIHRoYXQgYXMgd2VsbCBp ZiB0aGUgZHJhZnQgcHJvZ3Jlc3Nlcy4gSSBjb3VsZCBub3QgZmluZCBhIFdHIHRoYXQgd291bGQg YmUgYSBleGFjdCBmaXQgZm9yIHRoaXMgd29yaywgYW5kIHRoYXQgaXMgd2h5IEkgZGVjaWRlZCB0 byBjYXN0IHRoZSBuZXQgd2lkZSBmb3IgcG90ZW50aWFsbHkgcmVsZXZhbnQgV0dzIGluIHRoZSBo b3BlIG9mIGdldHRpbmcgcmV2aWV3cy4gSSB3aWxsIGJlIGV4dHJlbWVseSBoYXBweSBpZiB0aGlz IGNhbiBiZSBob3N0ZWQgaW4gYSBXRyBpbnN0ZWFkIGFuZCBnZXQgc3VmZmljaWVudCByZXZpZXcg dGhlcmUuDQoNClJlZ2FyZHMNClN1cmVzaA0KDQpPbiBPY3QgMTksIDIwMTgsIGF0IDEwOjQ0IEFN LCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0 aHViZXJ0QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpEZWFyIGFsbCA6DQoNCkkgYWdyZWUgd2l0aCBM b3JlbnpvLCB0aGlzIHNjaGVtZSBpcyBhdCBhIGhpZ2ggbGV2ZWwgd2hhdCB3ZSBjYW4gZmluZCBp biBjb21tZXJjaWFsIHByb2R1Y3RzLCBhbmQgSSBoYXZlIGZpcnN0LWhhbmQgZXhwZXJpZW5jZSBv biB0aGF0Lg0KDQpBcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCB0aGlzIFJGQyBjb3VsZCBi ZSBhIHVzZWZ1bCByZWZlcmVuY2UgdG8gY29uc2lkZXIgaWYgd2Ugd2VyZSB0byBjaGFuZ2UgdGhl IHByb3RvY29scyBpbiBhIHdheSB0aGF0IHdvdWxkIGltcGFjdCB0aG9zZSBleGlzdGluZyBhbmQg bm9uLXN0YW5kYXJkIHNub29waW5nIGJlaGF2aW9ycy4NClNub29waW5nIGhhcyBwcm92ZW4gdG8g YmUgdmVyeSB1c2VmdWwsIGJ1dCBhcyBvbmUgbWF5IGd1ZXNzLCBpdCBpcyBub3QgcmVsaWFibGU7 IGl0IG1heSBtaXNzIHBhY2tldHMsIG1heSBmYWlsIHRvIGNyZWF0ZSBiaW5kaW5ncywgbWF5IHBv aW50IG9uIGFuIGluY29ycmVjdCBsb2NhdGlvbiBhcyB3ZWxsLg0KDQpTbyBJ4oCZZCBzYXkgdGhh dCBpZiB3ZSBwdWJsaXNoIGFzIFJGQywgIHdlIHNob3VsZCBhbHNvIGluZGljYXRlIHRoYXQgd2l0 aCBkcmFmdC1pZXRmLTZsby1hcC1uZCwgd2UgKHdpbGwpIGhhdmUgYSBtb3JlIHJvYnVzdCBzb2x1 dGlvbiBmb3IgZGV2aWNlcyB0aGF0IGFyZSB3aWxsaW5nIHRvIGFubm91bmNlIHRoZW1zZWx2ZXMu DQoNCkNoZWVycywNCg0KUGFzY2FsDQpGcm9tOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0 dGkNClNlbnQ6IHZlbmRyZWRpIDE5IG9jdG9icmUgMjAxOCAwMjowNw0KVG86IFN1cmVzaCBLcmlz aG5hbiA8U3VyZXNoQGthbG9vbS5jb208bWFpbHRvOlN1cmVzaEBrYWxvb20uY29tPj4NCkNjOiB2 Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IFdHIDx2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+PjsgSUVURiBJUHY2IE1haWxpbmcgTGlzdCA8aXB2NkBpZXRm Lm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4+OyBvcHNlY0BpZXRmLm9yZzxtYWlsdG86b3BzZWNA aWV0Zi5vcmc+OyBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+OyBpbnQtYXJl YUBpZXRmLm9yZzxtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFp bHRvOm9wc2F3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIENvbnNpZGVyaW5nIEFE IHNwb25zb3JpbmcgZHJhZnQtYmktc2F2aS13bGFuLTE1DQoNCk9uIEZyaSwgT2N0IDE5LCAyMDE4 IGF0IDc6MzggQU0gU3VyZXNoIEtyaXNobmFuIDxTdXJlc2hAa2Fsb29tLmNvbTxtYWlsdG86U3Vy ZXNoQGthbG9vbS5jb20+PiB3cm90ZToNCiAgIEkgYW0gY29uc2lkZXJpbmcgQUQgc3BvbnNvcmlu ZyB0aGUgZm9sbG93aW5nIGRyYWZ0DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1iaS1zYXZpLXdsYW4tMTUNCg0KdGhhdCBkZXNjcmliZXMgYSBzb3VyY2UgYWRkcmVzcyB2YWxp ZGF0aW9uIHNvbHV0aW9uIGZvciBXTEFOLiBJZiB5b3UgaGF2ZSBhbnkgY29uY2VybnMNCmVpdGhl ciB3aXRoIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCwgb3IgYWJvdXQgbWUgQUQgc3BvbnNvcmlu ZyBpdCBwbGVhc2UgbGV0IG1lIGtub3cgYmVmb3JlIDIwMTgvMTEvMTguDQoNCkkgc2tpbW1lZCB0 aGUgZHJhZnQuIEl0IGxvb2tzIHdlbGwtd3JpdHRlbiwgYW5kIGl0IGFkZHJlc3NlcyBhbiBpbXBv cnRhbnQgcHJvYmxlbSB3aGljaCBJIHRoaW5rIGlzIHByb2JhYmx5IHNvbHZlZCBpbiAoZGlmZmVy ZW50PykgcHJvcHJpZXRhcnkgd2F5cyBvbiB2YXJpb3VzIGltcGxlbWVudGF0aW9ucyBpbiB0aGUg ZmllbGQgdG9kYXkuIEknbSBub3QgdmVyeSBmYW1pbGlhciB3aXRoIHRoZSBBRCBzcG9uc29yc2hp cCBwcm9jZXNzLCBzbyBub3Qgc3VyZSB3aGF0IHRoZSBoYXMgdG8gaGFwcGVuIGZyb20gYSBwcm9j ZXNzIHBlcnNwZWN0aXZlLiBCdXQgSSB0aGluayB0aGUgZG9jdW1lbnQgcmVxdWlyZXMgZnVydGhl ciByZXZpZXcsIGVzcGVjaWFsbHkgZ2l2ZW4gdGhhdCBpdCdzIG1ha2luZyBzdGF0ZW1lbnRzIGFi b3V0IHZlcnkgd2lkZWx5LWRlcGxveWVkIHNjZW5hcmlvcyAoSVB2NiBvdmVyIHdpZmkpLiBTaG91 bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgYnkgYSBXRyBzdWNoIGFzIDZtYW4gb3IgdjZvcHM/ IElmIG5vdCwgaXQgc2hvdWxkIGRlZmluaXRlbHkgYmUgcmV2aWV3ZWQgYnkgdGhvc2UgV0dzLg0K DQpBcyBhIGNvbmNyZXRlIGV4YW1wbGUsIGhlcmUgYXJlIHNvbWUgdGhpbmdzIHRoYXQgbmVlZCB0 byBiZSByZXNvbHZlZCBiZWZvcmUgdGhlIGRvY3VtZW50IGFkdmFuY2VzOg0KDQogIDEuICBUaGUg cHJvcG9zZWQgc2NoZW1lIHJlbGllcyBvbiBEQUQgcGFja2V0cyB0byBjcmVhdGUgbWFwcGluZyBl bnRyaWVzLiBUaGF0IG1lYW5zIHRoYXQgaWYgYSBEQUQgcGFja2V0IGlzIGxvc3QgKHdoaWNoIGNh biBoYXBwZW4gZXZlbiB0aG91Z2ggODAyLjExIGVtcGxveXMgcmV0cmFuc21pc3Npb25zIGF0IEwy KSwgYSBzdGF0aW9uIGNvdWxkIGhhdmUgYW4gSVB2NiBhZGRyZXNzIHRoYXQgZG9lc24ndCB3b3Jr IHdpdGggbm8gaW5kaWNhdGlvbiB0aGF0IGl0J3Mgbm90IHdvcmtpbmcuIFRoaXMgaXMgYmFzaWNh bGx5IGEgbm9uLXJlY292ZXJhYmxlIG91dGFnZS4gUGVyaGFwcyB0aGUgZG9jdW1lbnQgc2hvdWxk IHNwZWNpZnkgYW5vdGhlciBzb2x1dGlvbiBpbnN0ZWFkLCBlLmcuLCBpdCBjb3VsZCBzYXkgdGhh dCBtYXBwaW5nIGVudHJpZXMgY291bGQgYmUgY3JlYXRlZCB3aGVuIGEgd2lyZWQgc3RhdGlvbiBy ZWNlaXZlcyBhIHNvbGljaXRlZCBOQSByZXNwb25zZSBmcm9tIGEgd2lyZWxlc3Mgc3RhdGlvbi4N CiAgMi4gIFRoZSBkb2N1bWVudCBzYXlzIHRoYXQgdGhlIGxpZmV0aW1lIG9mIFNMQUFDIGFkZHJl c3NlcyBpcyB0aGUgYWRkcmVzcyBsaWZldGltZSwgYnV0IHRoZSBuZXR3b3JrIGhhcyBubyB3YXkg b2Yga25vd2luZyB3aGF0IHRoZSBhZGRyZXNzIGxpZmV0aW1lIGlzIGJlY2F1c2UgaXQgZGVwZW5k cyBvbiB3aGljaCBSQShzKSB0aGUgaG9zdCBoYXMgcmVjZWl2ZWQuDQoNCg0KQ2hlZXJzLA0KTG9y ZW56bw0KDQo= --_000_3BB81D98E70D45B4A99D94AF29D89526kaloomcom_ Content-Type: text/html; charset="utf-8" Content-ID: <767D1F02DBE92B478CDD331395A093C9@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcyBMb3JlbnpvLCBQYXNjYWwgYW5kIEJl cm5hcmQgZm9yIHlvdXIgY29tbWVudHMuIEkgaGF2ZSBhc2tlZCB0aGUgYXV0aG9ycyB0byByZXNw b25kIHRvIHlvdXIgY29tbWVudHMgb24gdGhlIGludGFyZWEgbWFpbGluZyBsaXN0LiBBbHNvLCBC ZXJuYXJkIHN1Z2dlc3RlZCBhIDgwMi4xMSByZXZpZXcgb2YgdGhpcyBkcmFmdCwgYW5kIEkgaW50 ZW5kIHRvIHB1cnN1ZSB0aGF0IGFzIHdlbGwgaWYgdGhlIGRyYWZ0IHByb2dyZXNzZXMuIEkgY291 bGQNCiBub3QgZmluZCBhIFdHIHRoYXQgd291bGQgYmUgYSBleGFjdCBmaXQgZm9yIHRoaXMgd29y aywgYW5kIHRoYXQgaXMgd2h5IEkgZGVjaWRlZCB0byBjYXN0IHRoZSBuZXQgd2lkZSBmb3IgcG90 ZW50aWFsbHkgcmVsZXZhbnQgV0dzIGluIHRoZSBob3BlIG9mIGdldHRpbmcgcmV2aWV3cy4gSSB3 aWxsIGJlIGV4dHJlbWVseSBoYXBweSBpZiB0aGlzIGNhbiBiZSBob3N0ZWQgaW4gYSBXRyBpbnN0 ZWFkIGFuZCBnZXQgc3VmZmljaWVudCByZXZpZXcgdGhlcmUuDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRzPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlN1cmVzaDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE9jdCAxOSwg MjAxOCwgYXQgMTA6NDQgQU0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0OzxhIGhyZWY9 Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iIGNsYXNzPSIiPnB0aHViZXJ0QGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdl OiBXb3JkU2VjdGlvbjE7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+RGVhciBhbGwmbmJz cDs6PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xh c3M9IiI+SSBhZ3JlZSB3aXRoIExvcmVuem8sIHRoaXMgc2NoZW1lIGlzIGF0IGEgaGlnaCBsZXZl bCB3aGF0IHdlIGNhbiBmaW5kIGluIGNvbW1lcmNpYWwgcHJvZHVjdHMsIGFuZCBJIGhhdmUgZmly c3QtaGFuZCBleHBlcmllbmNlIG9uIHRoYXQuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj5BcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCB0aGlzIFJG QyBjb3VsZCBiZSBhIHVzZWZ1bCByZWZlcmVuY2UgdG8gY29uc2lkZXIgaWYgd2Ugd2VyZSB0byBj aGFuZ2UgdGhlIHByb3RvY29scyBpbiBhIHdheSB0aGF0IHdvdWxkIGltcGFjdCB0aG9zZSBleGlz dGluZyBhbmQNCiBub24tc3RhbmRhcmQgc25vb3BpbmcgYmVoYXZpb3JzLjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ U25vb3BpbmcgaGFzIHByb3ZlbiB0byBiZSB2ZXJ5IHVzZWZ1bCwgYnV0IGFzIG9uZSBtYXkgZ3Vl c3MsIGl0IGlzIG5vdCByZWxpYWJsZTsgaXQgbWF5IG1pc3MgcGFja2V0cywgbWF5IGZhaWwgdG8g Y3JlYXRlIGJpbmRpbmdzLCBtYXkgcG9pbnQgb24gYW4gaW5jb3JyZWN0IGxvY2F0aW9uDQogYXMg d2VsbC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlNv IEnigJlkIHNheSB0aGF0IGlmIHdlIHB1Ymxpc2ggYXMgUkZDLCAmbmJzcDt3ZSBzaG91bGQgYWxz byBpbmRpY2F0ZSB0aGF0IHdpdGggZHJhZnQtaWV0Zi02bG8tYXAtbmQsIHdlICh3aWxsKSBoYXZl IGEgbW9yZSByb2J1c3Qgc29sdXRpb24gZm9yIGRldmljZXMgdGhhdCBhcmUgd2lsbGluZw0KIHRv IGFubm91bmNlIHRoZW1zZWx2ZXMuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IiBjbGFzcz0iIj5DaGVlcnMsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IiBjbGFzcz0iIj5QYXNjYWw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0 LXdpZHRoOiAxLjVwdDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IHBhZGRpbmc6IDBjbSAwY20g MGNtIDRwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1z dHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IGJvcmRlci10b3At Y29sb3I6IHJnYigyMjUsIDIyNSwgMjI1KTsgcGFkZGluZzogM3B0IDBjbSAwY207IiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNz PSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+aXB2NiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9 IiI+aXB2Ni1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+T24NCiBCZWhhbGYgT2Y8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkxvcmVuem8gQ29s aXR0aTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj52ZW5kcmVkaSAxOSBvY3RvYnJlIDIwMTgg MDI6MDc8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlN1cmVzaCBLcmlzaG5hbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOlN1cmVzaEBrYWxvb20uY29tIiBjbGFzcz0iIj5TdXJlc2hAa2Fsb29tLmNvbTwv YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86djZvcHNAaWV0 Zi5vcmciIGNsYXNzPSIiPnY2b3BzQGlldGYub3JnPC9hPiBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnY2b3BzQGlldGYub3JnIiBjbGFzcz0iIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7OyBJRVRGIElQ djYgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgY2xhc3M9 IiI+aXB2NkBpZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm9wc2VjQGlldGYub3Jn IiBjbGFzcz0iIj5vcHNlY0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRm Lm9yZyIgY2xhc3M9IiI+DQpkaGN3Z0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppbnQt YXJlYUBpZXRmLm9yZyIgY2xhc3M9IiI+aW50LWFyZWFAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0i bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyIgY2xhc3M9IiI+b3BzYXdnQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW2RoY3dnXSBDb25zaWRlcmluZyBBRCBzcG9u c29yaW5nIGRyYWZ0LWJpLXNhdmktd2xhbi0xNTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gRnJp LCBPY3QgMTksIDIwMTggYXQgNzozOCBBTSBTdXJlc2ggS3Jpc2huYW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpTdXJlc2hAa2Fsb29tLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+U3VyZXNoQGthbG9vbS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFw dDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZzogMGNtIDBj bSAwY20gNnB0OyBtYXJnaW4tbGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDogMGNtOyIgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDtJIGFtIGNvbnNpZGVyaW5nIEFEIHNwb25zb3JpbmcgdGhlIGZv bGxvd2luZyBkcmFmdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaS1zYXZpLXdsYW4tMTUiIHRhcmdldD0iX2Js YW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmktc2F2aS13bGFuLTE1 PC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCnRoYXQgZGVzY3JpYmVzIGEgc291cmNl IGFkZHJlc3MgdmFsaWRhdGlvbiBzb2x1dGlvbiBmb3IgV0xBTi4gSWYgeW91IGhhdmUgYW55IGNv bmNlcm5zPGJyIGNsYXNzPSIiPg0KZWl0aGVyIHdpdGggdGhlIGNvbnRlbnQgb2YgdGhlIGRyYWZ0 LCBvciBhYm91dCBtZSBBRCBzcG9uc29yaW5nIGl0IHBsZWFzZSBsZXQgbWUga25vdyBiZWZvcmUg MjAxOC8xMS8xOC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJp ZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBz ZXJpZjsiIGNsYXNzPSIiPg0KSSBza2ltbWVkIHRoZSBkcmFmdC4mbmJzcDtJdCBsb29rcyB3ZWxs LXdyaXR0ZW4sIGFuZCBpdCBhZGRyZXNzZXMgYW4gaW1wb3J0YW50IHByb2JsZW0gd2hpY2ggSSB0 aGluayBpcyBwcm9iYWJseSBzb2x2ZWQgaW4gKGRpZmZlcmVudD8pIHByb3ByaWV0YXJ5IHdheXMg b24gdmFyaW91cyBpbXBsZW1lbnRhdGlvbnMgaW4gdGhlIGZpZWxkIHRvZGF5LiBJJ20gbm90IHZl cnkgZmFtaWxpYXIgd2l0aCB0aGUgQUQgc3BvbnNvcnNoaXAgcHJvY2Vzcywgc28gbm90DQogc3Vy ZSB3aGF0IHRoZSBoYXMgdG8gaGFwcGVuIGZyb20gYSBwcm9jZXNzIHBlcnNwZWN0aXZlLiBCdXQg SSB0aGluayB0aGUgZG9jdW1lbnQgcmVxdWlyZXMgZnVydGhlciByZXZpZXcsIGVzcGVjaWFsbHkg Z2l2ZW4gdGhhdCBpdCdzIG1ha2luZyBzdGF0ZW1lbnRzIGFib3V0IHZlcnkgd2lkZWx5LWRlcGxv eWVkIHNjZW5hcmlvcyAoSVB2NiBvdmVyIHdpZmkpLiBTaG91bGQgdGhlIGRvY3VtZW50IGJlIGFk b3B0ZWQgYnkgYSBXRyBzdWNoIGFzIDZtYW4NCiBvciB2Nm9wcz8gSWYgbm90LCBpdCBzaG91bGQg ZGVmaW5pdGVseSBiZSByZXZpZXdlZCBieSB0aG9zZSZuYnNwO1dHcy48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQpBcyBhIGNvbmNyZXRlIGV4 YW1wbGUsIGhlcmUgYXJlIHNvbWUgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSByZXNvbHZlZCBiZWZv cmUgdGhlIGRvY3VtZW50IGFkdmFuY2VzOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOiAwY207IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyI+DQpUaGUgcHJvcG9zZWQgc2NoZW1lIHJl bGllcyBvbiBEQUQgcGFja2V0cyB0byBjcmVhdGUgbWFwcGluZyBlbnRyaWVzLiBUaGF0IG1lYW5z IHRoYXQgaWYgYSBEQUQgcGFja2V0IGlzIGxvc3QgKHdoaWNoIGNhbiBoYXBwZW4gZXZlbiB0aG91 Z2ggODAyLjExIGVtcGxveXMgcmV0cmFuc21pc3Npb25zIGF0IEwyKSwgYSBzdGF0aW9uIGNvdWxk IGhhdmUgYW4gSVB2NiBhZGRyZXNzIHRoYXQgZG9lc24ndCB3b3JrIHdpdGggbm8gaW5kaWNhdGlv biB0aGF0DQogaXQncyBub3Qgd29ya2luZy4gVGhpcyBpcyBiYXNpY2FsbHkgYSBub24tcmVjb3Zl cmFibGUgb3V0YWdlLiBQZXJoYXBzIHRoZSBkb2N1bWVudCBzaG91bGQgc3BlY2lmeSBhbm90aGVy IHNvbHV0aW9uIGluc3RlYWQsIGUuZy4sIGl0IGNvdWxkIHNheSB0aGF0IG1hcHBpbmcgZW50cmll cyBjb3VsZCBiZSBjcmVhdGVkIHdoZW4gYSB3aXJlZCBzdGF0aW9uIHJlY2VpdmVzIGEgc29saWNp dGVkIE5BIHJlc3BvbnNlIGZyb20gYSB3aXJlbGVzcyBzdGF0aW9uLjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCBzZXJpZjsiPg0KVGhlIGRvY3VtZW50IHNheXMgdGhhdCB0aGUgbGlmZXRpbWUgb2Yg U0xBQUMgYWRkcmVzc2VzIGlzIHRoZSBhZGRyZXNzIGxpZmV0aW1lLCBidXQgdGhlIG5ldHdvcmsg aGFzIG5vIHdheSBvZiBrbm93aW5nIHdoYXQgdGhlIGFkZHJlc3MgbGlmZXRpbWUgaXMgYmVjYXVz ZSBpdCBkZXBlbmRzIG9uIHdoaWNoIFJBKHMpIHRoZSBob3N0IGhhcyByZWNlaXZlZC48bzpwIGNs YXNzPSIiPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCkNoZWVycyw8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4N CkxvcmVuem88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_3BB81D98E70D45B4A99D94AF29D89526kaloomcom_-- From nobody Mon Oct 22 22:21:32 2018 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 2A6FD130F0D for ; Mon, 22 Oct 2018 21:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqM5L_4EDhuA for ; Mon, 22 Oct 2018 21:05:51 -0700 (PDT) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22524130F3F for ; Mon, 22 Oct 2018 21:05:44 -0700 (PDT) Received: by mail-it1-x136.google.com with SMTP id k206-v6so316556ite.0 for ; Mon, 22 Oct 2018 21:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k+HzzJJHq6KPCjImtGoJpgG+9AtIknSpNXA3o0FE5sg=; b=nNrwHnf0Rn0UdKqlFgLkuVRCO189oINy6tVP+36T3qNvITeKJdH73rF77uH0lKzOMM +84m6y7ZkiOHC0RADlFKNiKFWkS7pUH5XHYT+erH8SxWIaCDHKqhZNno0EhE5MFMftYA GwZUDQTU1Lr090DRFsnIX8JYpCI5plXAmM5TaSC5VhYzeInEOr7+zAB/CSKe32N2zv3V yZQcnJdUhG9fvvk5FdU5JdYDh/V5Txf2Bz+is2sVck7YhKihRx905vnUH9LwpE8FLIgU r1rVa9tcfUgsnqEYFR/IuaiSM0LUOpf4imF0WoBNqtTd1oW/gwI8iFeRGEvN1woGCOq8 5hBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k+HzzJJHq6KPCjImtGoJpgG+9AtIknSpNXA3o0FE5sg=; b=nODBQqwds/kbcL+X+TMryHixZuBBngWafibd440P0+WPQb3mO9e6xE5M4XzO4cGCmW xNXmNG/g15g7Fn6fv4RbCNbqzpKhlQDO1lg8uhXqYiYlMNPCKwyAJqZzkdChQsq7cASo DZ2pocq8CoQu/sbVOkkIsUETepRlIaJE4Wj0JkEBxnieygnwcbObkH7grAUiof9c4MWa 5F5LwumR2eFBPr/HEabQv5MH+UJ6SRaBg45HcQYIZm1DQga6zeW9XZwMOyJp2yJjTSTZ +mIrSK6uRJnXLn8TmeJoHAhXxuMfHyM685ZhMH9oN1gRxnvRqM+ujHJCuyVS4Vgfoqcg B11g== X-Gm-Message-State: AGRZ1gKHylJGp4H3c2SNTjnWLEbJPQerxTTVtsPHF6T/qJoUvUh7WnAq nWComdZdHseeCO6ucafIwhNoA9uvSjmVxDm+v4aG6Q== X-Google-Smtp-Source: AJdET5cqsiLZUUTTOYGJrpL3o/DohDPeDpNgoNveFXJhy1yVSTl/r4dO35soZh/iYkspkdHDq2Hl5uNRPxUyuxmzALU= X-Received: by 2002:a24:cb81:: with SMTP id u123-v6mr1206883itg.24.1540267542958; Mon, 22 Oct 2018 21:05:42 -0700 (PDT) MIME-Version: 1.0 References: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> <3BB81D98-E70D-45B4-A99D-94AF29D89526@kaloom.com> In-Reply-To: <3BB81D98-E70D-45B4-A99D-94AF29D89526@kaloom.com> From: Lorenzo Colitti Date: Tue, 23 Oct 2018 13:05:30 +0900 Message-ID: To: Suresh Krishnan Cc: "Pascal Thubert (pthubert)" , lorenzo=40google.com@dmarc.ietf.org, Bernard Aboba , "v6ops@ietf.org WG" , int-area@ietf.org, IETF IPv6 Mailing List , opsec@ietf.org, dhcwg@ietf.org, opsawg@ietf.org Content-Type: multipart/alternative; boundary="000000000000c24be40578dd7b36" Archived-At: X-Mailman-Approved-At: Mon, 22 Oct 2018 22:21:31 -0700 Subject: Re: [v6ops] [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 04:06:00 -0000 --000000000000c24be40578dd7b36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Isn't v6ops a natural fit for this, since it essentially documents an operational practice that is implemented by real hardware? On Tue, Oct 23, 2018 at 11:29 AM Suresh Krishnan wrote: > Thanks Lorenzo, Pascal and Bernard for your comments. I have asked the > authors to respond to your comments on the intarea mailing list. Also, > Bernard suggested a 802.11 review of this draft, and I intend to pursue > that as well if the draft progresses. I could not find a WG that would be= a > exact fit for this work, and that is why I decided to cast the net wide f= or > potentially relevant WGs in the hope of getting reviews. I will be > extremely happy if this can be hosted in a WG instead and get sufficient > review there. > > Regards > Suresh > > On Oct 19, 2018, at 10:44 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > > Dear all : > > I agree with Lorenzo, this scheme is at a high level what we can find in > commercial products, and I have first-hand experience on that. > > As an informational document, this RFC could be a useful reference to > consider if we were to change the protocols in a way that would impact > those existing and non-standard snooping behaviors. > Snooping has proven to be very useful, but as one may guess, it is not > reliable; it may miss packets, may fail to create bindings, may point on = an > incorrect location as well. > > So I=E2=80=99d say that if we publish as RFC, we should also indicate th= at with > draft-ietf-6lo-ap-nd, we (will) have a more robust solution for devices > that are willing to announce themselves. > > Cheers, > > Pascal > *From:* ipv6 *On Behalf Of *Lorenzo Colitti > *Sent:* vendredi 19 octobre 2018 02:07 > *To:* Suresh Krishnan > *Cc:* v6ops@ietf.org WG ; IETF IPv6 Mailing List < > ipv6@ietf.org>; opsec@ietf.org; dhcwg@ietf.org; int-area@ietf.org; > opsawg@ietf.org > *Subject:* Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 > > On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan wrote= : > > I am considering AD sponsoring the following draft > > https://tools.ietf.org/html/draft-bi-savi-wlan-15 > > that describes a source address validation solution for WLAN. If you have > any concerns > either with the content of the draft, or about me AD sponsoring it please > let me know before 2018/11/18. > > > I skimmed the draft. It looks well-written, and it addresses an important > problem which I think is probably solved in (different?) proprietary ways > on various implementations in the field today. I'm not very familiar with > the AD sponsorship process, so not sure what the has to happen from a > process perspective. But I think the document requires further review, > especially given that it's making statements about very widely-deployed > scenarios (IPv6 over wifi). Should the document be adopted by a WG such a= s > 6man or v6ops? If not, it should definitely be reviewed by those WGs. > > As a concrete example, here are some things that need to be resolved > before the document advances: > > 1. The proposed scheme relies on DAD packets to create mapping > entries. That means that if a DAD packet is lost (which can happen eve= n > though 802.11 employs retransmissions at L2), a station could have an = IPv6 > address that doesn't work with no indication that it's not working. Th= is is > basically a non-recoverable outage. Perhaps the document should specif= y > another solution instead, e.g., it could say that mapping entries coul= d be > created when a wired station receives a solicited NA response from a > wireless station. > 2. The document says that the lifetime of SLAAC addresses is the > address lifetime, but the network has no way of knowing what the addre= ss > lifetime is because it depends on which RA(s) the host has received. > > > Cheers, > Lorenzo > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --000000000000c24be40578dd7b36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Isn't v6ops a natural fit for this, since it essential= ly documents an operational practice that is implemented by real hardware?<= /div>
On Tue, Oct 23, 2018 a= t 11:29 AM Suresh Krishnan <Suresh@= kaloom.com> wrote:
Thanks Lorenzo, Pascal and Bernard for your comments. I have asked the auth= ors to respond to your comments on the intarea mailing list. Also, Bernard = suggested a 802.11 review of this draft, and I intend to pursue that as wel= l if the draft progresses. I could not find a WG that would be a exact fit for this work, and that is why I d= ecided to cast the net wide for potentially relevant WGs in the hope of get= ting reviews. I will be extremely happy if this can be hosted in a WG inste= ad and get sufficient review there.

Regards
Suresh

On Oct 19, 2018, at 10:44 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wr= ote:

Dear all=C2=A0:
=C2=A0
I agree with Lorenzo, this scheme is at a high level what we can fi= nd in commercial products, and I have first-hand experience on that.=
=C2=A0
As an informational document, this RFC could be a useful reference = to consider if we were to change the protocols in a way that would impact t= hose existing and non-standard snooping behaviors.=C2=A0
Snooping has proven to be very useful, but as one may guess, it is = not reliable; it may miss packets, may fail to create bindings, may point o= n an incorrect location as well.
=C2=A0
So I=E2=80=99d say that if we publish as RFC, =C2=A0we should also = indicate that with draft-ietf-6lo-ap-nd, we (will) have a more robust solut= ion for devices that are willing to announce themselves.
=C2=A0
Cheers,
=C2=A0
Pascal
From:=C2=A0ipv6 <= ipv6-bounces@iet= f.org>= =C2=A0On Behalf Of=C2= =A0Lorenzo Colitti
Sent:=C2= =A0vendredi 19 octobre 2018 02:07
To:=C2= =A0Suresh Krishnan <Suresh@kaloom.com>
Cc:=C2= =A0v6ops@ietf.or= g WG <v6ops@ietf= .org>; IETF IPv6 Mailing List <ipv6@ietf.org>; opsec@ietf.org; dhcwg@ietf.org; = int-area@ietf.org; opsawg@ietf.org Subject:= =C2=A0Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15=
=C2=A0
On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan <Suresh@kaloom.com> wrote:
=C2=A0 =C2=A0I am considering AD sponsoring the following draft

https://tools.ietf.or= g/html/draft-bi-savi-wlan-15

that describes a source address validation solution for WLAN. If you have a= ny concerns
either with the content of the draft, or about me AD sponsoring it please l= et me know before 2018/11/18.
=C2=A0
I skimmed the draft.=C2=A0It looks well-written, and it addresses an import= ant problem which I think is probably solved in (different?) proprietary wa= ys on various implementations in the field today. I'm not very familiar= with the AD sponsorship process, so not sure what the has to happen from a process perspective. But I think the do= cument requires further review, especially given that it's making state= ments about very widely-deployed scenarios (IPv6 over wifi). Should the doc= ument be adopted by a WG such as 6man or v6ops? If not, it should definitely be reviewed by those=C2=A0WGs.
=C2=A0
As a concrete example, here are some things that need to be resolved before= the document advances:
  1. The proposed scheme relies on DAD packets to create mapping entries. That m= eans that if a DAD packet is lost (which can happen even though 802.11 empl= oys retransmissions at L2), a station could have an IPv6 address that doesn= 't work with no indication that it's not working. This is basically a non-recoverable outage. Perhaps = the document should specify another solution instead, e.g., it could say th= at mapping entries could be created when a wired station receives a solicit= ed NA response from a wireless station.
  2. The document says that the lifetime of SLAAC addresses is the address lifet= ime, but the network has no way of knowing what the address lifetime is bec= ause it depends on which RA(s) the host has received.
    3. =C2=A0
    Cheers,
Lorenzo

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
--000000000000c24be40578dd7b36-- From nobody Mon Oct 22 22:46:49 2018 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 81EB6130E89 for ; Mon, 22 Oct 2018 22:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp1KXVXJC2Eh for ; Mon, 22 Oct 2018 22:46:45 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84925130DF0 for ; Mon, 22 Oct 2018 22:46:45 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id x6-v6so351966wmc.5 for ; Mon, 22 Oct 2018 22:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=XY+KU0XF+vQjPeLFBKxI8aAJBoeOuiQ3eLt4aWZa6bM=; b=tFZ4oYbpxYyk8jB1FnaEWwzaM8ytp1GCfkg5Z+DO+Rv8Z2AWeZvfwRLN5MndPVBGAm WW0/OLgU5r7yIaekNZsTN9X4wtSLn0qD0uKWAKPV7rKytN4QLL0VjUYJfIP2+ozWja7j tMtVgxLvyxmhPn9e3RtH+qMF4wc6ynatcqMrTUTO5SrgG9hWnyMyxBQxf/tR2HfLxano kK+vGeA602uUhuHWYkbjgSj3tDfkA87NVGWnFjnbFS3o0DTf6VlQOpLuSjZoOZEKVYnI q/20bZE7YoiBoM9NqVY1Q1eDpbT4vx5XBwxAqKdz+xaH+7x6d95bRvn1jticXJSZ0KM4 zkaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=XY+KU0XF+vQjPeLFBKxI8aAJBoeOuiQ3eLt4aWZa6bM=; b=h61MrjOW6uefFxbItDsuqmzUOStpPIAvSiWAObrz+oF28NvDlymIN7REyy0U7SaI59 e5p/F/JU2qUYdscFp++fy82d18TpmTsBQHD6ok+0NOgPJw2gTBETU+DIvyiPdUtPqKu5 w6IjMvxDMxOiZU2+S8j4aPAAhvJ3b2NMjFBaaydfoHsfF276VHskiPfJb7EzsIhWYHeq PNfb2BveJ6SR0EL5aIP1yckwN4WESCewG6y1CVlfiZ6OXUaAKhO7F7YVy6xHBhhhzoN/ bLXihbNTw5zzFFb3uX1qh1Nko6JpHaY4CQrQ/SNf7kwQR+PExHKDkPm+yWyVuKbFDsNI ELxw== X-Gm-Message-State: AGRZ1gIJlfJ3mtfZ4LtQdlcOMbWjDsNMmaw3IB8AovX8n+3L6jbRfJPu LtrIEwOqxGCNjkh7deU87Cb5D/S7Lqw= X-Google-Smtp-Source: AJdET5eGCCqrhUwoaP4EMZBYYfZDW/hd4kD7LonmiFRj7V5rSnQQo6kxUPR9flObyC/EiX0N4zQqWw== X-Received: by 2002:a1c:2846:: with SMTP id o67-v6mr472462wmo.60.1540273603569; Mon, 22 Oct 2018 22:46:43 -0700 (PDT) Received: from [192.168.50.230] ([213.27.245.162]) by smtp.gmail.com with ESMTPSA id j6-v6sm166264wru.20.2018.10.22.22.46.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 22:46:42 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_7908DFD3-B482-4993-A42B-CA21BEAE8B44"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 23 Oct 2018 07:46:40 +0200 To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Proposed agenda for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 05:46:48 -0000 --Apple-Mail=_7908DFD3-B482-4993-A42B-CA21BEAE8B44 Content-Type: multipart/mixed; boundary="Apple-Mail=_C7F9276F-16F9-440D-8308-2DA02B2CC873" --Apple-Mail=_C7F9276F-16F9-440D-8308-2DA02B2CC873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ron and I are proposing this as the agenda this time around: = https://datatracker.ietf.org/meeting/103/materials/agenda-103-v6ops-02 If there is time at the end of the meeting and people want to do what = amounts to a lightning talk, we can open the floor for that. However, = with a single two-hour slot, I expect it will be a busy meeting. In case it's useful to you, I have included some additional links in the = attached file - data tracker, html draft, discussion thread, and rfcdiff = against the previous version if any. --Apple-Mail=_C7F9276F-16F9-440D-8308-2DA02B2CC873 Content-Disposition: attachment; filename=v6ops-enhanced-agenda.html Content-Type: text/html; x-unix-mode=0644; name="v6ops-enhanced-agenda.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis --Apple-Mail=_C7F9276F-16F9-440D-8308-2DA02B2CC873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_C7F9276F-16F9-440D-8308-2DA02B2CC873-- --Apple-Mail=_7908DFD3-B482-4993-A42B-CA21BEAE8B44 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvOtcEACgkQEhdRnd2G P+C/Ag//WixwpzQcS+omslpqlJl4QLOLnJw2XA4mrnb5+mlRXvzm84FgKrzIl6qd txgoWXIYFpceIquFZRuM2JJRG23RrypaEghgaBee3kx2wuftNbyGuVISpMsbjob3 YoQA7dtWW/VL1LFxSKBwFxMOnzbec238y2Ki4eokQmLGZuoOuzkNu3sedRgrMK2K K6KmX0pssrxGkucgreubv5Q8B0QfkRWF/0N1bWwWBAfHQNftZBMChJreve+PyeAY JFYRVqYlJLro7yAdAYYgxLdjvuvQ7QS83X5ynUwTCRO0BuuyiJ4mrm01pPBK1bJM YSbpalTbOUeEQrnSwCcqOs9nbpAIgmBLFPI+Vx1d6hLdpqQIroXBuhQkco23stBi pIkoOkHdO0MK4NS9wEUdvvw2hVmcAqc3DHpQZqvVnyY87jnzpVCAu5bAGW/oUK2V I+VtPLPO16N6rnOCRMFhvBnYRy9NzTBjkq4lNAHoG63lJTXM34Vbg34dWu/0Uymo PZrpHBaBHTg7ZC7zKqRqNHPigT3SBNGOu7u9oNDf3PyRCXG+Ym2aXCD9zno6QTFf 88sligrPiDeJEaUq51HT70v+FL8PpJr9iuERBkJo6ET/Kb8rnHjiK8oq728y1nnG kxMp7pKCTeF1TKqTeriIN/f/1CPG7Tvk5OvlrLcKujxeH7yHmVQ= =Y6ga -----END PGP SIGNATURE----- --Apple-Mail=_7908DFD3-B482-4993-A42B-CA21BEAE8B44-- From nobody Mon Oct 22 23:29:04 2018 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 26257130F50 for ; Mon, 22 Oct 2018 23:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_MravbOFXFZ for ; Mon, 22 Oct 2018 23:28:53 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3428130F5B for ; Mon, 22 Oct 2018 23:28:53 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id d14-v6so248209qto.4 for ; Mon, 22 Oct 2018 23:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zLMI8xjtwhix37ve4Ho1OlLZhntXhHcZr3S1/6A0ZFU=; b=EdOjgbCcFeRXIdpVKPOFCMCN15mCJgaqv9G50up0M9O9WEXOzP+y+myRMdN+5irZOE bfGpyyy4fhY16SOaS5oNbMGKzgvVSMqIx41nb+x+xTmLrh8l1gMQkTDrh0V55r5R57jX AiMud37ednupyxKl6NPI4xNn9jfZHWaFSJ9C5gVXcQT59+NsOV+btRiPYRIl1LegrRhx 1JByyL7cF7Akq5TtqstM32l/X+LzA0gQ3shvOp9ooWKOJrwJ+4yfPcYk1kxyMLjdguIv wcZCLwykHQJQ+KB47V97Zmsq5NPw8sjRtWHgHSVuzz8oc1gx6H1CT3BDHcRb2J55uCLs FhOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zLMI8xjtwhix37ve4Ho1OlLZhntXhHcZr3S1/6A0ZFU=; b=ADx2rUpDZNzFoqYkOilea0zn6K/VYO2doPeMoS7ZOp4tU59UPJXleWeojoHuDc7O/m lqqYSZen7KjAAubGfQ6VWy5FAaPICEVcyqKJEWJRdNDPFfNyu9lo8o/YL07BvUsohXzV 5k2PeflXchbjLi6H69riSi8BRpYqmX3wStlc4fI/tKLLk3LlVEMt49BjmK6iY1rr89z8 D9gtDH80kLOm/riMvpEvIodHXVaHAWz6adBywuauvMbGueeCIj7qU89BsJ0DvLh/Gu/L zjvCEmUR0ymOtbBglDz+hhZr42hxPCrQ9F+z3zuH26HNoETpt2eZO57qUgGlqoxrpjD/ /nsw== X-Gm-Message-State: AGRZ1gIug3fPBE8dWGfeQH11bktiDX1WYETxi9pFc4aL7r1PBYKxEVYQ QqQc/rspjNf/k0PYsl2CYvfXYS+exuvvWnKKNwraqF8a X-Google-Smtp-Source: AJdET5eABBVF38BDT1EVBk7YvvcX7jXlprfqINPDQjPjb3PiLU3qH9b6UNP16hmcp3OP64hfHDa8TbRB5ImNe5agHu0= X-Received: by 2002:a0c:8087:: with SMTP id 7mr7064698qvb.41.1540276132769; Mon, 22 Oct 2018 23:28:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Davey Song Date: Tue, 23 Oct 2018 14:28:41 +0800 Message-ID: To: fredbaker.ietf@gmail.com Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000bff4a40578df7b26" Archived-At: Subject: Re: [v6ops] Proposed agenda for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 06:29:02 -0000 --000000000000bff4a40578df7b26 Content-Type: text/plain; charset="UTF-8" I'm confused that in IETF BKK some busy working group like v6ops and dnsop only has one sesion (2 hours). Usually they had 2 . Is IETF BKK sepcially and the schedule is so packed? Davey On Tue, 23 Oct 2018 at 13:47, Fred Baker wrote: > Ron and I are proposing this as the agenda this time around: > https://datatracker.ietf.org/meeting/103/materials/agenda-103-v6ops-02 > > If there is time at the end of the meeting and people want to do what > amounts to a lightning talk, we can open the floor for that. However, with > a single two-hour slot, I expect it will be a busy meeting. > > In case it's useful to you, I have included some additional links in the > attached file - data tracker, html draft, discussion thread, and rfcdiff > against the previous version if any. > > > > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000bff4a40578df7b26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm confused that in IETF BKK some busy working group = like v6ops and dnsop only has one sesion (2 hours). Usually they had 2 . Is= IETF BKK sepcially and the schedule is so packed?

Davey=

On Tue, 23 Oct = 2018 at 13:47, Fred Baker <f= redbaker.ietf@gmail.com> wrote:
Ron and I are proposing this as the agenda this time around: https://datatracker.ietf.org/meeting/103= /materials/agenda-103-v6ops-02

If there is time at the end of the meeting and people want to do what amoun= ts to a lightning talk, we can open the floor for that. However, with a sin= gle two-hour slot, I expect it will be a busy meeting.

In case it's useful to you, I have included some additional links in th= e attached file - data tracker, html draft, discussion thread, and rfcdiff = against the previous version if any.


---------------------------------------------------------------------------= -----
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
=C2=A0 =C2=A0 =C2=A0Sun Tzu

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000bff4a40578df7b26-- From nobody Tue Oct 23 01:57:54 2018 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 5FBB012008A for ; Tue, 23 Oct 2018 01:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT6JPHBgIERH for ; Tue, 23 Oct 2018 01:57:49 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EA5127148 for ; Tue, 23 Oct 2018 01:57:49 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 193-v6so893107wme.3 for ; Tue, 23 Oct 2018 01:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xugBJX0Wy8KDmTlUBvT9sMV8yHblFfX8XmDZyBB9zrI=; b=mL/csSmyzQJgn9YJfI1PGoqg82fhugKguz70bGc27NLNESJaYS01E/fEYRctW3AjyU 4W+BMDVPvnpCTunpdeeSewUHAow71iVzo2LdMEl6uZ3B/06YRI6Hyyi/rtbwp3Lzud0P zFFIhV0GwgGG8i0Si28s3hL0nAlVUQc1cDsvMlId3K4GWiLlFYH7zNKPiEB6pPTSbJiv aCkRGJHbpTOsQew+1oTC9fLHmgPe2n0LYJ8i5LCawjF5KDqYxx9I0RgyLW4h/psx/YBl 2nU2ON/PnCPgom0MaQ8YLNvcXgy3ExknvYoKVX+vnP4y0Kw36ffjrYA5g9z9bpAPL9IX 5ysg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xugBJX0Wy8KDmTlUBvT9sMV8yHblFfX8XmDZyBB9zrI=; b=U7i1G4UO/cvrraH3lCNnSZObEjKIakCy6WxcSexXD6bWI9MvtIM7VIzymODUhyMsZn e8mM89nGYwXuauWoVVkhqsKKggW5em9srhn9yjw20etOUhPVvX8M3Y5Gz9ydxW1P/2/c MVy14mpL/GV/wO8VNQ9v38FqoVQb1OQz0JhGB6j85bM+Vfj7vi2Z6rnkOxa3o6MJr0tK JWjtdfmh7+pLz4DrmhL5zbGUOmzAOr6YMFrX1Q++upL08UXf6bsjDYB/sRMEZO5kFGav inGBEiY1MggyAYUz3W4KNv1kvnJSOTUOMfCpOT3i3oUuwKVJvvRp15T2XFbw5o7M1PwL V28g== X-Gm-Message-State: ABuFfoibzQpw2iDmwyAcEkLKpTQDmNFBF02x8vC95V6xbzV0qDO4dxfS e81VMcplTDvyRffVDym5DVc= X-Google-Smtp-Source: ACcGV63EZWpztaYiOygQNGyn/QF82E9MaTRkxMwPVLf98E6LxMmEmeKp4gOMS22jNpK+Nho8uZ6d+A== X-Received: by 2002:a1c:41c5:: with SMTP id o188-v6mr20594254wma.34.1540285067361; Tue, 23 Oct 2018 01:57:47 -0700 (PDT) Received: from ?IPv6:2620:f:8000:210:51b7:2724:449d:2da? ([2620:f:8000:210:51b7:2724:449d:2da]) by smtp.gmail.com with ESMTPSA id l70-v6sm1230012wma.0.2018.10.23.01.57.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Oct 2018 01:57:46 -0700 (PDT) From: Fred Baker Message-Id: <1638D5FD-47BE-468E-9695-C1A19296F848@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2E837125-C9F6-439A-A5F6-2847A5271293"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 23 Oct 2018 10:57:44 +0200 In-Reply-To: Cc: v6ops@ietf.org To: Davey Song References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Proposed agenda for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 08:57:52 -0000 --Apple-Mail=_2E837125-C9F6-439A-A5F6-2847A5271293 Content-Type: multipart/mixed; boundary="Apple-Mail=_4223984D-278B-4380-9DED-53A4EC5DF433" --Apple-Mail=_4223984D-278B-4380-9DED-53A4EC5DF433 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2018, at 8:28 AM, Davey Song wrote: > I'm confused that in IETF BKK some busy working group like v6ops and = dnsop only has one sesion (2 hours). Usually they had 2 . Is IETF BKK = sepcially and the schedule is so packed? First, yes, IETF 103 is different than other IETFs in several ways. It = is discussed in an email: = https://www.ietf.org/mail-archive/web/ietf/current/msg107813.html. In = short, while Fridays have always been a day few people wanted to have = their meeting on, this time there are no scheduled meetings on Friday. = In addition, we have no 2.5 hour sessions. V6ops has historically = usually used at least one 2.5 hour session, and often two 2 hour = sessions. In essence, the number of slots is less, and their length is = reduced. Ron and I have gone back and forth on scheduling, both on the number of = meeting slots we ask for and how they are used. At IETF 101, we only = asked for one 2.5 hour slot, and wound up pushing a lot of work (too = much, in hindsight) into that slot. At IETF 102, we asked for two slots = (one of which wound up on Friday), and wound up using one for v6ops work = and the other as an open session. For IETF 103, in view of the = experiment the IESG is carrying out, we only asked for one slot, and it = was the largest available to us - two hours. Let me walk through the process by which Ron and I develop the agenda. I = have attached a file I create daily for my own amusement (I do this for = each IETF working group and IRTF RG), because I find it useful. It sorts = out the drafts currently before the working group by their status with = the RFC Editor, IESG, and Working Group, and among documents at our = level, divides between those that have been updated since the last IETF = meeting and those that have not. It tells us how to review discussion of = a given draft - not just on v6ops@, but on all IETF mailing lists, as = that is sometimes useful to know. Drafts that are eligible for agenda = time are those that are at the working group level (sometimes ones the = AD or IESG is kicking around, but those are exceptions), are within the = scope of our charter, have been updated since the last meeting, and have = had recent supportive discussion on the mailing list. To expound slightly on that last concept - it's one that seems to get = discussed from time to time - we're looking for discussion (no mail = since last IETF =3D> no discussion) and support (not just "gee, that = could be an interesting concept intellectually", but "and I think I = would like to deploy it in my part of the world if it meets my needs, = which I might need to discuss"). This is an operational community, and = yes, we're looking for operational comments. Others are welcome too, of = course - I'm an example of "other" - but operators are at the head of = the line in consideration. Ron and I also apply some editorial judgement, of course. For IETF 103, Ron and I originally asked Xing Li to talk about CERNET2, = which has been an IPv6-only network for about ten years, and connects a = couple hundred universities in China. We have been inviting a talk each = meeting to let people talk about their experience with IPv6-only = networking, or to cover nascent topics. We had three drafts that pretty = clearly needed discussion, and we posted those in a provisional agenda. = We had three requests for time in addition to that, one of which came = from you. We reviewed the mailing list discussion (your was interesting = in that it was largely cross-posted with dnsop, so many of the messages = were duplicated), and tried to figure out what was most interesting to = the working group. We accepted one of the drafts "time permitting", we = decided to not include yours for reasons I described to you in email, = and for the third request added an "AOB" section to the agenda. Something else we have been doing - which I have experimented with = before and between IETF 101 and 102 and then 102 and 103 - is asking the = working group once a week to look at some draft (usually a v6ops draft, = but sometimes others) and comment on it from an operational perspective. = Obvious objectives there include improvement of the draft and giving he = chairs guidance on what should happen with it if anything. We have had a = couple of instances where the discussion made it pretty clear that the = draft should be adopted by the working group or progressed in status, = and a few discussions that have been well-characterized with a yawn. = Besides improving drafts and pushing status along, we hope that this = helps offload and improve the f2f meeting. This happened for your draft = during the last week in September. --Apple-Mail=_4223984D-278B-4380-9DED-53A4EC5DF433 Content-Disposition: attachment; filename=raw-agenda-data-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="raw-agenda-data-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

This document describes the drafts associated with this working group. It describes their current state as seen by the RFC Editor, IESG/AD, and the working group. For working group drafts and individual submissions, it also indicates whether the draft has been updated since the previous IETF meeting. Drafts that are new or have been updated are "current"; other drafts are "old".

On each draft, there are three or four links:

  • the relevant datatracker link,
  • a pointer to the HTML version of the draft in the tools directory,
  • a pointer to the email archived on IETF mailing lists related to the draft, and
  • a pointer to RFCDIFF against the previous version, if there was one.

IESG: AD Evaluation

WG: Unupdated WG Document

WG: Updated WG Document

Individual Submission: Unupdated

Individual Submission: Updated

Tue Oct 23 06:10:56 2018

--Apple-Mail=_4223984D-278B-4380-9DED-53A4EC5DF433 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_4223984D-278B-4380-9DED-53A4EC5DF433-- --Apple-Mail=_2E837125-C9F6-439A-A5F6-2847A5271293 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvO4ogACgkQEhdRnd2G P+AcvRAAgKdP1Ml7Vkt7r2AtMRqVBlCPhXhZMUnqpDEQL7mUHW8C2LIPbUj19jqP 0YUk/nenR7j8lBzEpaAWhSVmne29KNkAWlzfLX+n14crnx3kG3PrK+nn+F9NYzd/ Wjsc3uYEP7NfQtQQ8S9PQKveuYNpa66B5dAcv8hKf7rOq8JiyIGavL2ahlLlKCy7 ihqqedEy+Zmx21lhhUbkyJDlB/kr5yneeIOXPsp+HlaNt1lvQ3QrHCta2xr/vIzA 69fgmhtKNmL6liNC2C2/3x82iUMjZNcdeiTH04SQwpqU9H1aoWHLWwIsR/6TPsaq FU/ZlUGBk4yHDO5GY1YubVB6abxNdBtmEamK0HVHTNkwDsG8zYVUw0Rmh/Pw4jxz Vhv4kb0+j9O+zAL7+Agzk+gOd/lUe1UfOTW8Kun/QJdSvcSnUFEnEKg6WmFy1cjn wad/hRR73440fJdvR8XqpPIVuozv6Zp6TfudO5OtNfkBM+b58drTYJUpsa7KInfa wZEU0n+b3d3Oulz7k0Mr96wJKQOJthdAu2s66Z5VxBpKIFrLN2dwC2cV5SUI7R8H hi2Cx9YbE83I/QKuc+7qyXnZ07rbPstlFkOlcYk4F/FNXWilOTIAvovH5h8pIeDr uxs7B4uv6OT5e7tMeRQDgrQiMSoRwzFkMm91R1ZZzpHwTLe/taA= =l7F7 -----END PGP SIGNATURE----- --Apple-Mail=_2E837125-C9F6-439A-A5F6-2847A5271293-- From nobody Tue Oct 23 02:41:06 2018 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 B23FC130EFE for ; Tue, 23 Oct 2018 02:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JJbKBVcAu4F for ; Tue, 23 Oct 2018 02:40:52 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337B2130F81 for ; Tue, 23 Oct 2018 02:40:52 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id m17-v6so364395qkk.10 for ; Tue, 23 Oct 2018 02:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=48OHCsSjCz7FB2HmVtj5WXNYF3qfUg49V2ZNAv1bk4w=; b=OysXiifRg2llhVHPNfgTjuknTxIof87NdwwWLUZFw2oI4zlP647SSSwJOthBD/VYXQ 0UI7f+hY7ctPnx7XySBEKFCxYhfK9MOcOfFMtea/MDYlO9B1QWngBKplfWlCp5IwXg7T 1ObLkUda6jaJbSf4CPS2Qc6vMvS7rpvhNG/PdPu7u3P15AAw+t2gNSyHZcuAdU3Z+tTg KlS4Fv/r8VkWSKXR97KSnfxnvofRwK2MUMePtbw82wOq+ZdLUHbqR3Q+6RSgCTMjDMLe ufijGR323KRjQ/xsLOUCyAjRC/DKpxHnr3RuVtZcskSwkqSUd51+1Hj7CEXtB2zQ8tOf LCWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=48OHCsSjCz7FB2HmVtj5WXNYF3qfUg49V2ZNAv1bk4w=; b=du4YPbos0Hjmysrk3j4lx8A2giNqIQycKrEIjqk9YoNVwmp8CQGt1xe6WjIWe9/u5T 8wuJAlUGjrU5ttaL/Zz/MFBF3YB2f8gR+WAeSzAWUozedIlTTdjDXbalogRK5gdWlL2Q QKv6zffxBLWDOE1dbuEC0ZqsnyGhc4rbl7hHz/a4nAD0/+NvUyX8DR2tILWiD2f3XA5C SUE0q/ESHIb7kkXWNIvEfE8IzdskrkoWu9lB08oyyHLoh2rzR1mopltYQweDTk0YO/rC Tshq1xGtxs1EUNBUeiWOML/aFi74mHstJ1U2R3+BiqoYnDClXx4ne4WHYX+zKgECB4Wo jfrA== X-Gm-Message-State: AGRZ1gJUrCgILXm7++w3Ss4qjVGD+teEiQ0Wl9ajD0ctd/I/veYzPuH8 dldrbQwvScEf/a/eRV7qdnN8cTxVPKTnjqFFH0AgBQYWP30= X-Google-Smtp-Source: AJdET5cNGnUh/2O/oO+U3RnL2Ehzlfy4foUb0F8r5eiewA7DBxDR9aC1gLXdqHIYHqG2itOt9DljAtqgh4t5q4ullBo= X-Received: by 2002:a37:c68c:: with SMTP id s12mr5153362qkl.66.1540287651321; Tue, 23 Oct 2018 02:40:51 -0700 (PDT) MIME-Version: 1.0 References: <1638D5FD-47BE-468E-9695-C1A19296F848@gmail.com> In-Reply-To: <1638D5FD-47BE-468E-9695-C1A19296F848@gmail.com> From: Davey Song Date: Tue, 23 Oct 2018 17:40:29 +0800 Message-ID: To: fredbaker.ietf@gmail.com Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f1c910578e22a24" Archived-At: Subject: Re: [v6ops] Proposed agenda for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 09:41:01 -0000 --0000000000004f1c910578e22a24 Content-Type: text/plain; charset="UTF-8" Thanks for your sharing and I feel grateful for the Chair's effort to schedule all this with transparency. I'm sorry for over demanding it. Davey On Tue, 23 Oct 2018 at 16:57, Fred Baker wrote: > > > On Oct 23, 2018, at 8:28 AM, Davey Song wrote: > > I'm confused that in IETF BKK some busy working group like v6ops and > dnsop only has one sesion (2 hours). Usually they had 2 . Is IETF BKK > sepcially and the schedule is so packed? > > First, yes, IETF 103 is different than other IETFs in several ways. It is > discussed in an email: > https://www.ietf.org/mail-archive/web/ietf/current/msg107813.html. In > short, while Fridays have always been a day few people wanted to have their > meeting on, this time there are no scheduled meetings on Friday. In > addition, we have no 2.5 hour sessions. V6ops has historically usually used > at least one 2.5 hour session, and often two 2 hour sessions. In essence, > the number of slots is less, and their length is reduced. > > Ron and I have gone back and forth on scheduling, both on the number of > meeting slots we ask for and how they are used. At IETF 101, we only asked > for one 2.5 hour slot, and wound up pushing a lot of work (too much, in > hindsight) into that slot. At IETF 102, we asked for two slots (one of > which wound up on Friday), and wound up using one for v6ops work and the > other as an open session. For IETF 103, in view of the experiment the IESG > is carrying out, we only asked for one slot, and it was the largest > available to us - two hours. > > Let me walk through the process by which Ron and I develop the agenda. I > have attached a file I create daily for my own amusement (I do this for > each IETF working group and IRTF RG), because I find it useful. It sorts > out the drafts currently before the working group by their status with the > RFC Editor, IESG, and Working Group, and among documents at our level, > divides between those that have been updated since the last IETF meeting > and those that have not. It tells us how to review discussion of a given > draft - not just on v6ops@, but on all IETF mailing lists, as that is > sometimes useful to know. Drafts that are eligible for agenda time are > those that are at the working group level (sometimes ones the AD or IESG is > kicking around, but those are exceptions), are within the scope of our > charter, have been updated since the last meeting, and have had recent > supportive discussion on the mailing list. > > To expound slightly on that last concept - it's one that seems to get > discussed from time to time - we're looking for discussion (no mail since > last IETF => no discussion) and support (not just "gee, that could be an > interesting concept intellectually", but "and I think I would like to > deploy it in my part of the world if it meets my needs, which I might need > to discuss"). This is an operational community, and yes, we're looking for > operational comments. Others are welcome too, of course - I'm an example of > "other" - but operators are at the head of the line in consideration. > > Ron and I also apply some editorial judgement, of course. > > For IETF 103, Ron and I originally asked Xing Li to talk about CERNET2, > which has been an IPv6-only network for about ten years, and connects a > couple hundred universities in China. We have been inviting a talk each > meeting to let people talk about their experience with IPv6-only > networking, or to cover nascent topics. We had three drafts that pretty > clearly needed discussion, and we posted those in a provisional agenda. We > had three requests for time in addition to that, one of which came from > you. We reviewed the mailing list discussion (your was interesting in that > it was largely cross-posted with dnsop, so many of the messages were > duplicated), and tried to figure out what was most interesting to the > working group. We accepted one of the drafts "time permitting", we decided > to not include yours for reasons I described to you in email, and for the > third request added an "AOB" section to the agenda. > > Something else we have been doing - which I have experimented with before > and between IETF 101 and 102 and then 102 and 103 - is asking the working > group once a week to look at some draft (usually a v6ops draft, but > sometimes others) and comment on it from an operational perspective. > Obvious objectives there include improvement of the draft and giving he > chairs guidance on what should happen with it if anything. We have had a > couple of instances where the discussion made it pretty clear that the > draft should be adopted by the working group or progressed in status, and a > few discussions that have been well-characterized with a yawn. Besides > improving drafts and pushing status along, we hope that this helps offload > and improve the f2f meeting. This happened for your draft during the last > week in September. > > > -------------------------------------------------------------------------------- > The fact that there is a highway to hell and a stairway to heaven is an > interesting comment on projected traffic volume... > > --0000000000004f1c910578e22a24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your sharing and I feel g= rateful for the Chair's effort to schedule all this with transparency. = I'm sorry for over demanding it.=C2=A0=C2=A0

Davey

O= n Tue, 23 Oct 2018 at 16:57, Fred Baker <fredbaker.ietf@gmail.com> wrote:


On Oct 23, 2018, at 8:28 AM, Davey Song <songlinjian@gmail.com> wrote:
> I'm confused that in IETF BKK some busy working group like v6ops a= nd dnsop only has one sesion (2 hours). Usually they had 2 . Is IETF BKK se= pcially and the schedule is so packed?

First, yes, IETF 103 is different than other IETFs in several ways. It is d= iscussed in an email: https://www.i= etf.org/mail-archive/web/ietf/current/msg107813.html. In short, while F= ridays have always been a day few people wanted to have their meeting on, t= his time there are no scheduled meetings on Friday. In addition, we have no= 2.5 hour sessions. V6ops has historically usually used at least one 2.5 ho= ur session, and often two 2 hour sessions. In essence, the number of slots = is less, and their length is reduced.

Ron and I have gone back and forth on scheduling, both on the number of mee= ting slots we ask for and how they are used. At IETF 101, we only asked for= one 2.5 hour slot, and wound up pushing a lot of work (too much, in hindsi= ght) into that slot. At IETF 102, we asked for two slots (one of which woun= d up on Friday), and wound up using one for v6ops work and the other as an = open session. For IETF 103, in view of the experiment the IESG is carrying = out, we only asked for one slot, and it was the largest available to us - t= wo hours.

Let me walk through the process by which Ron and I develop the agenda. I ha= ve attached a file I create daily for my own amusement (I do this for each = IETF working group and IRTF RG), because I find it useful. It sorts out the= drafts currently before the working group by their status with the RFC Edi= tor, IESG, and Working Group, and among documents at our level, divides bet= ween those that have been updated since the last IETF meeting and those tha= t have not. It tells us how to review discussion of a given draft - not jus= t on v6ops@, but on all IETF mailing lists, as that is sometimes useful to = know. Drafts that are eligible for agenda time are those that are at the wo= rking group level (sometimes ones the AD or IESG is kicking around, but tho= se are exceptions), are within the scope of our charter, have been updated = since the last meeting, and have had recent supportive discussion on the ma= iling list.

To expound slightly on that last concept - it's one that seems to get d= iscussed from time to time - we're looking for discussion (no mail sinc= e last IETF =3D> no discussion) and support (not just "gee, that co= uld be an interesting concept intellectually", but "and I think I= would like to deploy it in my part of the world if it meets my needs, whic= h I might need to discuss"). This is an operational community, and yes= , we're looking for operational comments. Others are welcome too, of co= urse - I'm an example of "other" - but operators are at the h= ead of the line in consideration.

Ron and I also apply some editorial judgement, of course.

For IETF 103, Ron and I originally asked Xing Li to talk about CERNET2, whi= ch has been an IPv6-only network for about ten years, and connects a couple= hundred universities in China. We have been inviting a talk each meeting t= o let people talk about their experience with IPv6-only networking, or to c= over nascent topics. We had three drafts that pretty clearly needed discuss= ion, and we posted those in a provisional agenda. We had three requests for= time in addition to that, one of which came from you. We reviewed the mail= ing list discussion (your was interesting in that it was largely cross-post= ed with dnsop, so many of the messages were duplicated), and tried to figur= e out what was most interesting to the working group. We accepted one of th= e drafts "time permitting", we decided to not include yours for r= easons I described to you in email, and for the third request added an &quo= t;AOB" section to the agenda.

Something else we have been doing - which I have experimented with before a= nd between IETF 101 and 102 and then 102 and 103 - is asking the working gr= oup once a week to look at some draft (usually a v6ops draft, but sometimes= others) and comment on it from an operational perspective. Obvious objecti= ves there include improvement of the draft and giving he chairs guidance on= what should happen with it if anything. We have had a couple of instances = where the discussion made it pretty clear that the draft should be adopted = by the working group or progressed in status, and a few discussions that ha= ve been well-characterized with a yawn. Besides improving drafts and pushin= g status along, we hope that this helps offload and improve the f2f meeting= . This happened for your draft during the last week in September.

---------------------------------------------------------------------------= -----
The fact that there is a highway to hell and a stairway to heaven is an int= eresting comment on projected traffic volume...

--0000000000004f1c910578e22a24-- From nobody Tue Oct 23 10:18:59 2018 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 54202130ECA for ; Tue, 23 Oct 2018 10:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.969 X-Spam-Level: X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE_FRKyH-yrx for ; Tue, 23 Oct 2018 10:18:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A73130FB7 for ; Tue, 23 Oct 2018 10:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54462; q=dns/txt; s=iport; t=1540315119; x=1541524719; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=01wAyguQKKaUpTj7sve33irRmFeOKxyYvAF3aDDQ6zA=; b=JAQjRoYWs9cooh2m4CZLV4W/+rgV8lfxfe+2WA3SlDTZ7MTr9K1ylwhS jSyCEXKzgwn4gYqZ5E4TK5aZl1WddY+LvcNM3dmeS2oe3JoC7qG2Ewa62 a2Dqhekkzs8Qb2DgDE97eN93wXnxNRNf2mK8wyiHEuHeb068l870jH6e/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAA5V89b/5pdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCoNriBiMHYINlxUUgWMDCwE?= =?us-ascii?q?BGAEKgVSCL0YCF4UTITQNDQEDAQECAQECbRwMhToBAQEDAQEBIUsLBQsCAQg?= =?us-ascii?q?RAwECIQEGAwICAiULFAkIAgQBCQQFgyEBgR1cCA+nPYEuhCwBhXWKRYEdF4F?= =?us-ascii?q?BPyZrJx+CTIMbAQECgSMJARIBCQkdBwkMCgiCRTGCJgKISggBOoUqhhKKBwk?= =?us-ascii?q?ChmGBA4ZpgiUXgVKOXoxciWgCERSBJh04ZHFwFTsqAYINAQEBMQmCHReDSHu?= =?us-ascii?q?EGYU+bwEBimANF4EIgRQLAQE?= X-IronPort-AV: E=Sophos;i="5.54,416,1534809600"; d="scan'208,217";a="470729321" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 17:18:38 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w9NHIcKE029037 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 17:18:38 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 12:18:37 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 12:18:37 -0500 From: "Rajiv Asati (rajiva)" To: JORDI PALET MARTINEZ , "Mikael Abrahamsson" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group Thread-Index: AQHUZFRdzx2gLAh2jUKHSWGKEkPPZaUga2IAgAALaoCABHc9AIAABuQAgAADRICAAAb5AIAAA02AgAAETYCAAAYSAIAACIMAgAAHFACAADxcAIAABvwAgAALXACAACQtAIAACnMAgAABjYCAAARrAIABtTgAgASB0QA= Date: Tue, 23 Oct 2018 17:18:37 +0000 Message-ID: References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.208.213] Content-Type: multipart/alternative; boundary="_000_AD4EA0BFE55E4B6B8A68FA080C59339Dciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 17:18:57 -0000 --_000_AD4EA0BFE55E4B6B8A68FA080C59339Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9yZGksDQoNClRoaXMgaXMgcXVpdGUgdXNlZnVsLiBEbyB5b3UgYWxzbyBoYXBwZW4gdG8gaGF2 ZSBzaW1pbGFyIHRlc3QgbnVtYmVycyB3aXRoIENMQVQgZnVuY3Rpb25hbGl0eSB2cy4gTUFQKC1U L0UpIENFIGZ1bmN0aW9uYWxpdHk/IFRoYXQgd291bGQgcmVhbGx5IGhlbHAsIGFuZCBPcGVuV1JU IHN1cHBvcnRzIHRoZW0uDQoNCkl0IHdvdWxkIGJlIHBlcnRpbmVudCB0byBoYXZlIGNvbnNpc3Rl bnQgdHJhZmZpYyBhbW91bnQgYW5kIG5vIG9mIGNvbm5lY3Rpb25zL2Zsb3dzIGluIGVhY2ggY2Fz ZS4NCg0KU2F5LCA2MCUgSVB2NiBhbmQgNDAlIElQdjQgdHJhZmZpYyAoYnkgYnBzKSBhcyB3ZWxs IGFzIGNvbm5lY3Rpb25zLg0KDQpIYXMgYW55Ym9keSBnb3QgYW55IHJlY2VudCBtZWFzdXJlbWVu dCBhYm91dCBubyBvZiBjb25uZWN0aW9ucyBwZXIgSEdXPyBNaW5lIGlzIGRhdGVkIGluIDIwMTIt MjAxMy4NCg0KQ2hlZXJzLA0KUmFqaXYNCg0KDQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldD00 MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDE5 LCAyMDE4IGF0IDQ6MDQgUE0NClRvOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAu c2U+DQpDYzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3Y2b3BzXSBUcmFqZWN0b3J5IGZvciAidHJhbnNpdGlvbiIgbWVjaGFuaXNtcyBpbiBvdXIgd29y a2luZyBncm91cA0KDQpIaSBNaWthZWwsDQoNClNvcnJ5LCB3YXMgY29taW5nIGJhY2sgZnJvbSB0 aGUgUklQRSBhbmQgYXJyYW5naW5nIGEgc21hbGwgdGVzdCB0byBzaG93IHlvdSB0aGUgcmVzdWx0 cywgd2hpY2ggYXJlIGNvbnNpc3RlbnQgd2l0aCB3aGF0IEkgcmVjYWxsIGZyb20gbXkgcHJldmlv dXMgdGVzdGluZy4NCg0KSSdtIHVzaW5nIGFuIHVidW50dSBWTSBhcyB0aGUgc2VydmVyLCBydW5u aW5nIGluIEVTWGkgNi41LCBhbmQgYXMgY2xpZW50IG15IG93biBsYXB0b3AuDQoNClRoZXJlIGlz IGEgQ2lzY28gc3dpdGNoIGJldHdlZW4gdGhlIHNlcnZlciwgdGhlIE1UNzYyMSBkZXZpY2UgYW5k IG15IGNsaWVudC4NCg0KVWJ1bnR1IFZNIGluIEVTWGkgLS0tIENpc2NvIEdpZyBzd2l0Y2ggLS0t IE1UNzYyMSB1bmRlciB0ZXN0IC0tLSBjbGllbnQgZGV2aWNlDQoNClNlcnZlciBjb21tYW5kOiBp cGVyZjMgLXMNCg0KMSkgTEFOLXRvLUxBTiB0ZXN0IChzbyBib3RoIHRoZSBzZXJ2ZXIgYW5kIGNs aWVudCBhcmUgY29ubmVjdGVkIHRvIHRoZSBMQU5zIG9mIHRoZSBNVDc2MjEpDQppcGVyZjMgLWMg MTAuMTAuMTAuMw0KQ29ubmVjdGluZyB0byBob3N0IDEwLjEwLjEwLjMsIHBvcnQgNTIwMQ0KWyAg NF0gbG9jYWwgMTAuMTAuMTAuOTkgcG9ydCA1MTMwMCBjb25uZWN0ZWQgdG8gMTAuMTAuMTAuMyBw b3J0IDUyMDENClsgSURdIEludGVydmFsICAgICAgICAgICBUcmFuc2ZlciAgICAgQmFuZHdpZHRo DQpbICA0XSAgIDAuMDAtMS4wMCAgIHNlYyAgIDExMyBNQnl0ZXMgICA5NTEgTWJpdHMvc2VjDQpb ICA0XSAgIDEuMDAtMi4wMCAgIHNlYyAgIDExMiBNQnl0ZXMgICA5MzcgTWJpdHMvc2VjDQpbICA0 XSAgIDIuMDAtMy4wMCAgIHNlYyAgIDExMiBNQnl0ZXMgICA5MzggTWJpdHMvc2VjDQpbICA0XSAg IDMuMDAtNC4wMCAgIHNlYyAgIDExMiBNQnl0ZXMgICA5MzcgTWJpdHMvc2VjDQpbICA0XSAgIDQu MDAtNS4wMCAgIHNlYyAgIDExMiBNQnl0ZXMgICA5MzYgTWJpdHMvc2VjDQpbICA0XSAgIDUuMDAt Ni4wMCAgIHNlYyAgIDExMiBNQnl0ZXMgICA5MzcgTWJpdHMvc2VjDQpbICA0XSAgIDYuMDAtNy4w MCAgIHNlYyAgIDExMiBNQnl0ZXMgICA5MzcgTWJpdHMvc2VjDQpbICA0XSAgIDcuMDAtOC4wMCAg IHNlYyAgIDExMiBNQnl0ZXMgICA5MzcgTWJpdHMvc2VjDQpbICA0XSAgIDguMDAtOS4wMCAgIHNl YyAgIDExMiBNQnl0ZXMgICA5MzcgTWJpdHMvc2VjDQpbICA0XSAgIDkuMDAtMTAuMDAgIHNlYyAg IDExMiBNQnl0ZXMgICA5MzYgTWJpdHMvc2VjDQotIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtDQpbIElEXSBJbnRlcnZhbCAgICAgICAgICAgVHJhbnNmZXIg ICAgIEJhbmR3aWR0aA0KWyAgNF0gICAwLjAwLTEwLjAwICBzZWMgIDEuMDkgR0J5dGVzICAgOTM4 IE1iaXRzL3NlYyAgICAgICAgICAgICAgICAgIHNlbmRlcg0KWyAgNF0gICAwLjAwLTEwLjAwICBz ZWMgIDEuMDkgR0J5dGVzICAgOTM3IE1iaXRzL3NlYyAgICAgICAgICAgICAgICAgIHJlY2VpdmVy DQoNCjIpIExBTi10by1XQU4gTkFUIHRlc3Qgd2l0aG91dCBvZmZsb2FkaW5nDQppcGVyZjMgLWMg MTAuMTAuMTAuMw0KQ29ubmVjdGluZyB0byBob3N0IDEwLjEwLjEwLjMsIHBvcnQgNTIwMQ0KWyAg NF0gbG9jYWwgMTkyLjE2OC4xLjEzOSBwb3J0IDUxNDQ3IGNvbm5lY3RlZCB0byAxMC4xMC4xMC4z IHBvcnQgNTIwMQ0KWyBJRF0gSW50ZXJ2YWwgICAgICAgICAgIFRyYW5zZmVyICAgICBCYW5kd2lk dGgNClsgIDRdICAgMC4wMC0xLjAwICAgc2VjICA0OC44IE1CeXRlcyAgIDQwOSBNYml0cy9zZWMN ClsgIDRdICAgMS4wMC0yLjAwICAgc2VjICA0NS44IE1CeXRlcyAgIDM4NCBNYml0cy9zZWMNClsg IDRdICAgMi4wMC0zLjAwICAgc2VjICA0NS4yIE1CeXRlcyAgIDM3OSBNYml0cy9zZWMNClsgIDRd ICAgMy4wMC00LjAwICAgc2VjICA0NS4yIE1CeXRlcyAgIDM3OSBNYml0cy9zZWMNClsgIDRdICAg NC4wMC01LjAwICAgc2VjICA0NS4wIE1CeXRlcyAgIDM3OCBNYml0cy9zZWMNClsgIDRdICAgNS4w MC02LjAwICAgc2VjICA0NC45IE1CeXRlcyAgIDM3NyBNYml0cy9zZWMNClsgIDRdICAgNi4wMC03 LjAwICAgc2VjICA0NS4yIE1CeXRlcyAgIDM3OSBNYml0cy9zZWMNClsgIDRdICAgNy4wMC04LjAw ICAgc2VjICA0NS4xIE1CeXRlcyAgIDM3OCBNYml0cy9zZWMNClsgIDRdICAgOC4wMC05LjAwICAg c2VjICA0NS4zIE1CeXRlcyAgIDM4MCBNYml0cy9zZWMNClsgIDRdICAgOS4wMC0xMC4wMCAgc2Vj ICA0NS4yIE1CeXRlcyAgIDM3OSBNYml0cy9zZWMNCi0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0NClsgSURdIEludGVydmFsICAgICAgICAgICBUcmFuc2Zl ciAgICAgQmFuZHdpZHRoDQpbICA0XSAgIDAuMDAtMTAuMDAgIHNlYyAgIDQ1NiBNQnl0ZXMgICAz ODIgTWJpdHMvc2VjICAgICAgICAgICAgICAgICAgc2VuZGVyDQpbICA0XSAgIDAuMDAtMTAuMDAg IHNlYyAgIDQ1NiBNQnl0ZXMgICAzODIgTWJpdHMvc2VjICAgICAgICAgICAgICAgICAgcmVjZWl2 ZXINCg0KMykgTEFOLXRvLVdBTiBOQVQgdGVzdCB3aXRoIFNPRlRXQVJFIG9mZmxvYWRpbmcNCmlw ZXJmMyAtYyAxMC4xMC4xMC4zDQpDb25uZWN0aW5nIHRvIGhvc3QgMTAuMTAuMTAuMywgcG9ydCA1 MjAxDQpbICA0XSBsb2NhbCAxOTIuMTY4LjEuMTM5IHBvcnQgNTE0ODQgY29ubmVjdGVkIHRvIDEw LjEwLjEwLjMgcG9ydCA1MjAxDQpbIElEXSBJbnRlcnZhbCAgICAgICAgICAgVHJhbnNmZXIgICAg IEJhbmR3aWR0aA0KWyAgNF0gICAwLjAwLTEuMDAgICBzZWMgIDk4LjQgTUJ5dGVzICAgODI2IE1i aXRzL3NlYw0KWyAgNF0gICAxLjAwLTIuMDAgICBzZWMgIDk4LjIgTUJ5dGVzICAgODI0IE1iaXRz L3NlYw0KWyAgNF0gICAyLjAwLTMuMDAgICBzZWMgIDk2LjkgTUJ5dGVzICAgODEzIE1iaXRzL3Nl Yw0KWyAgNF0gICAzLjAwLTQuMDAgICBzZWMgIDk3LjYgTUJ5dGVzICAgODE5IE1iaXRzL3NlYw0K WyAgNF0gICA0LjAwLTUuMDAgICBzZWMgIDk4LjIgTUJ5dGVzICAgODI0IE1iaXRzL3NlYw0KWyAg NF0gICA1LjAwLTYuMDAgICBzZWMgIDk2LjUgTUJ5dGVzICAgODA5IE1iaXRzL3NlYw0KWyAgNF0g ICA2LjAwLTcuMDAgICBzZWMgIDk2LjAgTUJ5dGVzICAgODA1IE1iaXRzL3NlYw0KWyAgNF0gICA3 LjAwLTguMDAgICBzZWMgIDk2LjEgTUJ5dGVzICAgODA2IE1iaXRzL3NlYw0KWyAgNF0gICA4LjAw LTkuMDAgICBzZWMgIDk3LjggTUJ5dGVzICAgODIwIE1iaXRzL3NlYw0KWyAgNF0gICA5LjAwLTEw LjAwICBzZWMgIDk3LjUgTUJ5dGVzICAgODE4IE1iaXRzL3NlYw0KLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLQ0KWyBJRF0gSW50ZXJ2YWwgICAgICAgICAg IFRyYW5zZmVyICAgICBCYW5kd2lkdGgNClsgIDRdICAgMC4wMC0xMC4wMCAgc2VjICAgOTczIE1C eXRlcyAgIDgxNiBNYml0cy9zZWMgICAgICAgICAgICAgICAgICBzZW5kZXINClsgIDRdICAgMC4w MC0xMC4wMCAgc2VjICAgOTcxIE1CeXRlcyAgIDgxNSBNYml0cy9zZWMgICAgICAgICAgICAgICAg ICByZWNlaXZlcg0KDQo0KSBMQU4tdG8tV0FOIE5BVCB0ZXN0IHdpdGggSEFSRFdBUkUgb2ZmbG9h ZGluZw0KaXBlcmYzIC1jIDEwLjEwLjEwLjMNCkNvbm5lY3RpbmcgdG8gaG9zdCAxMC4xMC4xMC4z LCBwb3J0IDUyMDENClsgIDRdIGxvY2FsIDE5Mi4xNjguMS4xMzkgcG9ydCA1MTUyMyBjb25uZWN0 ZWQgdG8gMTAuMTAuMTAuMyBwb3J0IDUyMDENClsgSURdIEludGVydmFsICAgICAgICAgICBUcmFu c2ZlciAgICAgQmFuZHdpZHRoDQpbICA0XSAgIDAuMDAtMS4wMCAgIHNlYyAgIDExMCBNQnl0ZXMg ICA5MjYgTWJpdHMvc2VjDQpbICA0XSAgIDEuMDAtMi4wMCAgIHNlYyAgIDExMiBNQnl0ZXMgICA5 MzggTWJpdHMvc2VjDQpbICA0XSAgIDIuMDAtMy4wMCAgIHNlYyAgIDExMSBNQnl0ZXMgICA5MzMg TWJpdHMvc2VjDQpbICA0XSAgIDMuMDAtNC4wMCAgIHNlYyAgIDExMSBNQnl0ZXMgICA5MzUgTWJp dHMvc2VjDQpbICA0XSAgIDQuMDAtNS4wMCAgIHNlYyAgIDExMSBNQnl0ZXMgICA5MzMgTWJpdHMv c2VjDQpbICA0XSAgIDUuMDAtNi4wMCAgIHNlYyAgIDExMSBNQnl0ZXMgICA5MzMgTWJpdHMvc2Vj DQpbICA0XSAgIDYuMDAtNy4wMCAgIHNlYyAgIDExMSBNQnl0ZXMgICA5MzMgTWJpdHMvc2VjDQpb ICA0XSAgIDcuMDAtOC4wMCAgIHNlYyAgIDExMCBNQnl0ZXMgICA5MjMgTWJpdHMvc2VjDQpbICA0 XSAgIDguMDAtOS4wMCAgIHNlYyAgIDExMSBNQnl0ZXMgICA5MzQgTWJpdHMvc2VjDQpbICA0XSAg IDkuMDAtMTAuMDAgIHNlYyAgIDExMSBNQnl0ZXMgICA5MzMgTWJpdHMvc2VjDQotIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtDQpbIElEXSBJbnRlcnZhbCAg ICAgICAgICAgVHJhbnNmZXIgICAgIEJhbmR3aWR0aA0KWyAgNF0gICAwLjAwLTEwLjAwICBzZWMg IDEuMDkgR0J5dGVzICAgOTMyIE1iaXRzL3NlYyAgICAgICAgICAgICAgICAgIHNlbmRlcg0KWyAg NF0gICAwLjAwLTEwLjAwICBzZWMgIDEuMDggR0J5dGVzICAgOTMxIE1iaXRzL3NlYyAgICAgICAg ICAgICAgICAgIHJlY2VpdmVyDQoNClJlZ2FyZGluZyBDUFUgdXRpbGl6YXRpb24sIHVzaW5nIGh0 b3AsIHdpdGggYm90aCBOTyBvZmZsb2FkaW5nIGFuZCBTVyBvZmZsb2FkaW5nLCBpdCBpcyBldmlk ZW50IHRoYXQgdGhlIENQVSBpcyBiZWluZyB1c2VkIHJlYWNoaW5nIGNsb3NlIHRvIDEwMCUgb2Yg b25lIG9mIHRoZSBjb3JlcywgYSBiaXQgbGVzcyBpbiB0aGUgb3RoZXJzLCB3aGlsZSBIVyBvZmZs b2FkaW5nIENQVSByZW1haW5zIHdpdGggdGhlIDEtMiUgdXRpbGl6YXRpb24uDQoNCkJ5IHRoZSB3 YXkgdGhlIGRldmljZXMgYXJlIGNoZWFwIG9uZXMsIGRpZmZlcmVudCB2ZW5kb3JzLCBubyBkaWZm ZXJlbmNlIGlmIEkgZG8gdGhlIHRlc3Qgd2l0aCBvbmUgb3IgdGhlIG90aGVyICh0ZXN0ZWQgd2l0 aCAzIGRpZmZlcmVudCBvbmVzIGFuZCBnb3Qgc2FtZSByZXN1bHRzKS4gVGhlIG1vc3QgZXhwZW5z aXZlIG9uZSBpcyBwcm9iYWJseSBhcm91bmQgMzAgVVNEIChaQlQtV0czNTI2LTE2TSkuDQoNCkkn dmUgdXNlZCB0aGUgc3RhYmxlIGJ1aWxkcyBhbmQgdGhlbiB1cGdyYWRlZCBldmVyeXRoaW5nIHRv IHRoZSBsYXRlc3QgdmVyc2lvbnMuDQoNCmh0dHBzOi8vZG93bmxvYWRzLm9wZW53cnQub3JnL3Jl bGVhc2VzLzE4LjA2LjEvdGFyZ2V0cy9yYW1pcHMvbXQ3NjIxLw0KDQpJZiB5b3UncmUgaW50ZXJl c3RlZCBhbmQgY29taW5nIHRvIEJLSywgSSBjYW4gYnJpbmcgb25lIG9mIHRoZW0gYW5kIHdlIGNh biBwbGF5IGEgYml0Lg0KDQpSZWdhcmRzLA0KSm9yZGkNCg0KLS0tLS1NZW5zYWplIG9yaWdpbmFs LS0tLS0NCkRlOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U8bWFpbHRvOnN3 bWlrZUBzd20ucHAuc2U+Pg0KT3JnYW5pemFjacOzbjogUGVvcGxlJ3MgRnJvbnQgQWdhaW5zdCBX V1cNCkZlY2hhOiBqdWV2ZXMsIDE4IGRlIG9jdHVicmUgZGUgMjAxOCwgMTk6NDUNClBhcmE6IEpP UkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lczxtYWlsdG86am9y ZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+Pg0KQ0M6IDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZv cHNAaWV0Zi5vcmc+Pg0KQXN1bnRvOiBSZTogW3Y2b3BzXSBUcmFqZWN0b3J5IGZvciAidHJhbnNp dGlvbiIgbWVjaGFuaXNtcyBpbiBvdXIgd29ya2luZyBncm91cA0KDQogICAgT24gVGh1LCAxOCBP Y3QgMjAxOCwgSk9SREkgUEFMRVQgTUFSVElORVogd3JvdGU6DQoNCiAgICA+IFllcywgMTAwJSBz dXJlIGluIHRoaXMgY2FzZS4NCiAgICA+DQogICAgPiBUaGUgU29DIHN1cHBvcnRzIGl0IHdpdGgg c2V2ZXJhbCBTREtzL09TczoNCiAgICA+DQogICAgPiBodHRwczovL3d3dy5tZWRpYXRlay5jb20v cHJvZHVjdHMvaG9tZU5ldHdvcmtpbmcvbXQ3NjIxbi1hDQogICAgPg0KICAgID4gWW91IGNhbiBl bmFibGUgSFcgb3IgU1cgb2ZmbG9hZGluZywgb2ZmZXJzIGJvdGggb3B0aW9ucyAoZGlkbid0IGNo ZWNrZWQNCiAgICA+IHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UsIEkganVzdCBnbyBmb3IgdGhlIEhX IGlmIGl0IHdvcmtzLCBhcyBJIGd1ZXNzDQogICAgPiBvdXRwZXJmb3JtcyB0aGUgU1cgb25lKS4N Cg0KICAgIEkga25vdyB0aGUgTVQ3NjIxIGRvZXMgd2hhdCB5b3UncmUgc2F5aW5nIGluIG90aGVy IE9TZXMgd2l0aCB0aGVpciBTREssDQogICAgSSdtIHF1ZXN0aW9uaW5nIGlmIHRoZSAtaiBGTE9X T0ZGTE9BRCBpcyB0aGUgd2F5IHRvIGRvIEhXIGFjY2VsZXJhdGlvbiBmb3INCiAgICBjZXJ0YWlu IGZsb3dzLiBEaWQgeW91IHRyeSB0byBydW4gZnVsbCBnaWcgc3BlZWQgdGhyb3VnaCBpdCBhbmQg Y2hlY2sgQ1BVDQogICAgdXNhZ2U/IEl0J3MgdGhlIGVhc2llc3Qgd2F5IHRvIHRlbGwgaWYgdGhl IG9mZmxvYWQgd29ya3Mgb3Igbm90Lg0KDQogICAgSXQgd291bGQgYmUgdGhlIGxlYXN0IGludHJ1 c2l2ZSBvZmZsb2FkIGltcGxlbWVudGF0aW9uIEkndmUgZXZlciBzZWVuIGluDQogICAgTGludXgs IHNvIGlmIGl0IGFjdHVhbGx5IHdvcmtzIHRoaXMgd2F5IEknZCBiZSB2ZXJ5IGhhcHB5LCBhbmQg aG9wZSBtb3JlDQogICAgdmVuZG9ycyBkb2VzIGl0IHRoZSBzYW1lIHdheS4NCg0KICAgIERpZCB5 b3UgYnV5IHNvbWUgcmV0YWlsIGRldmljZT8gSWYgeW91IGRpZCwgd2hhdCB3YXMgaXQ/DQoNCiAg ICAtLQ0KICAgIE1pa2FlbCBBYnJhaGFtc3NvbiAgICBlbWFpbDogc3dtaWtlQHN3bS5wcC5zZTxt YWlsdG86c3dtaWtlQHN3bS5wcC5zZT4NCg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZvciB0 aGUgbmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNClRoZSBJUHY2IENv bXBhbnkNCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hp Y2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMg aW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMp IG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xv c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhp cyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxl cywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWlu YWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2Fy ZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRo ZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVk aW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNp ZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2lu YWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBp dC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K --_000_AD4EA0BFE55E4B6B8A68FA080C59339Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1806E99D23942A49B78F6CAA5B521950@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkpvcmRpLDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBxdWl0ZSB1c2VmdWwuIERvIHlvdSBhbHNv IGhhcHBlbiB0byBoYXZlIHNpbWlsYXIgdGVzdCBudW1iZXJzIHdpdGggQ0xBVCBmdW5jdGlvbmFs aXR5IHZzLiBNQVAoLVQvRSkgQ0UgZnVuY3Rpb25hbGl0eT8gVGhhdCB3b3VsZCByZWFsbHkgaGVs cCwgYW5kIE9wZW5XUlQgc3VwcG9ydHMgdGhlbS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIHBl cnRpbmVudCB0byBoYXZlIGNvbnNpc3RlbnQgdHJhZmZpYyBhbW91bnQgYW5kIG5vIG9mIGNvbm5l Y3Rpb25zL2Zsb3dzIGluIGVhY2ggY2FzZS4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2F5LCA2MCUgSVB2NiBh bmQgNDAlIElQdjQgdHJhZmZpYyAoYnkgYnBzKSBhcyB3ZWxsIGFzIGNvbm5lY3Rpb25zLg0KPC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IYXMgYW55Ym9keSBnb3QgYW55IHJlY2VudCBtZWFzdXJlbWVudCBhYm91dCBu byBvZiBjb25uZWN0aW9ucyBwZXIgSEdXPyBNaW5lIGlzIGRhdGVkIGluIDIwMTItMjAxMy48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNoZWVycyw8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SYWppdjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj52Nm9wcyAmbHQ7djZvcHMtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaICZsdDtq b3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5GcmlkYXksIE9jdG9iZXIgMTksIDIwMTggYXQgNDowNCBQTTxicj4NCjxiPlRvOiA8 L2I+TWlrYWVsIEFicmFoYW1zc29uICZsdDtzd21pa2VAc3dtLnBwLnNlJmd0Ozxicj4NCjxiPkNj OiA8L2I+JnF1b3Q7djZvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Y2b3BzQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3Y2b3BzXSBUcmFqZWN0b3J5IGZvciAmcXVvdDt0cmFu c2l0aW9uJnF1b3Q7IG1lY2hhbmlzbXMgaW4gb3VyIHdvcmtpbmcgZ3JvdXA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgTWlrYWVsLDwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Tb3JyeSwgd2FzIGNvbWluZyBiYWNrIGZy b20gdGhlIFJJUEUgYW5kIGFycmFuZ2luZyBhIHNtYWxsIHRlc3QgdG8gc2hvdyB5b3UgdGhlIHJl c3VsdHMsIHdoaWNoIGFyZSBjb25zaXN0ZW50IHdpdGggd2hhdCBJIHJlY2FsbCBmcm9tIG15IHBy ZXZpb3VzIHRlc3RpbmcuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkknbSB1 c2luZyBhbiB1YnVudHUgVk0gYXMgdGhlIHNlcnZlciwgcnVubmluZyBpbiBFU1hpIDYuNSwgYW5k IGFzIGNsaWVudCBteSBvd24gbGFwdG9wLjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5UaGVyZSBpcyBhIENpc2NvIHN3aXRjaCBiZXR3ZWVuIHRoZSBzZXJ2ZXIsIHRoZSBNVDc2 MjEgZGV2aWNlIGFuZCBteSBjbGllbnQuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPlVidW50dSBWTSBpbiBFU1hpIC0tLSBDaXNjbyBHaWcgc3dpdGNoIC0tLSBNVDc2MjEgdW5k ZXIgdGVzdCAtLS0gY2xpZW50IGRldmljZTwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5TZXJ2ZXIgY29tbWFuZDogaXBlcmYzIC1zPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjEpIExBTi10by1MQU4gdGVzdCAoc28gYm90aCB0aGUgc2VydmVyIGFuZCBjbGll bnQgYXJlIGNvbm5lY3RlZCB0byB0aGUgTEFOcyBvZiB0aGUgTVQ3NjIxKTwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5pcGVy ZjMgLWMgMTAuMTAuMTAuMzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db25uZWN0aW5nIHRvIGhvc3QgMTAuMTAuMTAuMywg cG9ydCA1MjAxPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSBsb2NhbCAxMC4xMC4xMC45OSBwb3J0 IDUxMzAwIGNvbm5lY3RlZCB0byAxMC4xMC4xMC4zIHBvcnQgNTIwMTwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bIElEXSBJ bnRlcnZhbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUcmFuc2ZlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCYW5kd2lkdGg8L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDAuMDAtMS4wMCZuYnNwOyZuYnNwOyBz ZWMmbmJzcDsmbmJzcDsgMTEzIE1CeXRlcyZuYnNwOyZuYnNwOyA5NTEgTWJpdHMvc2VjJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsm bmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyAxLjAwLTIuMDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7 Jm5ic3A7IDExMiBNQnl0ZXMmbmJzcDsmbmJzcDsgOTM3IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5i c3A7NF0mbmJzcDsmbmJzcDsgMi4wMC0zLjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOyAx MTIgTUJ5dGVzJm5ic3A7Jm5ic3A7IDkzOCBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5i c3A7Jm5ic3A7IDMuMDAtNC4wMCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJzcDsgMTEyIE1CeXRl cyZuYnNwOyZuYnNwOyA5MzcgTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNw OyA0LjAwLTUuMDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7Jm5ic3A7IDExMiBNQnl0ZXMmbmJzcDsm bmJzcDsgOTM2IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgNS4wMC02 LjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOyAxMTIgTUJ5dGVzJm5ic3A7Jm5ic3A7IDkz NyBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDYuMDAtNy4wMCZuYnNw OyZuYnNwOyBzZWMmbmJzcDsmbmJzcDsgMTEyIE1CeXRlcyZuYnNwOyZuYnNwOyA5MzcgTWJpdHMv c2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyA3LjAwLTguMDAmbmJzcDsmbmJzcDsg c2VjJm5ic3A7Jm5ic3A7IDExMiBNQnl0ZXMmbmJzcDsmbmJzcDsgOTM3IE1iaXRzL3NlYyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5b Jm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgOC4wMC05LjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNw OyZuYnNwOyAxMTIgTUJ5dGVzJm5ic3A7Jm5ic3A7IDkzNyBNYml0cy9zZWMmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZu YnNwOzRdJm5ic3A7Jm5ic3A7IDkuMDAtMTAuMDAmbmJzcDsmbmJzcDtzZWMmbmJzcDsmbmJzcDsg MTEyIE1CeXRlcyZuYnNwOyZuYnNwOyA5MzYgTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC08L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyBJRF0gSW50ZXJ2YWwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVHJhbnNmZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFuZHdpZHRoPC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsm bmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyAwLjAwLTEwLjAwJm5ic3A7Jm5ic3A7c2VjJm5ic3A7 Jm5ic3A7MS4wOSBHQnl0ZXMmbmJzcDsmbmJzcDsgOTM4IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NlbmRlcjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5i c3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgMC4wMC0xMC4wMCZuYnNwOyZuYnNwO3NlYyZuYnNwOyZu YnNwOzEuMDkgR0J5dGVzJm5ic3A7Jm5ic3A7IDkzNyBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZWNlaXZlcjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4yKSBMQU4tdG8tV0FOIE5BVCB0ZXN0IHdpdGhvdXQgb2Zm bG9hZGluZzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5pcGVyZjMgLWMgMTAuMTAuMTAuMzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db25uZWN0aW5n IHRvIGhvc3QgMTAuMTAuMTAuMywgcG9ydCA1MjAxPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSBs b2NhbCAxOTIuMTY4LjEuMTM5IHBvcnQgNTE0NDcgY29ubmVjdGVkIHRvIDEwLjEwLjEwLjMgcG9y dCA1MjAxPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPlsgSURdIEludGVydmFsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRyYW5zZmVyJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEJhbmR3aWR0aDwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsg MC4wMC0xLjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOzQ4LjggTUJ5dGVzJm5ic3A7Jm5i c3A7IDQwOSBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDEuMDAtMi4w MCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJzcDs0NS44IE1CeXRlcyZuYnNwOyZuYnNwOyAzODQg TWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyAyLjAwLTMuMDAmbmJzcDsm bmJzcDsgc2VjJm5ic3A7Jm5ic3A7NDUuMiBNQnl0ZXMmbmJzcDsmbmJzcDsgMzc5IE1iaXRzL3Nl YyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgMy4wMC00LjAwJm5ic3A7Jm5ic3A7IHNl YyZuYnNwOyZuYnNwOzQ1LjIgTUJ5dGVzJm5ic3A7Jm5ic3A7IDM3OSBNYml0cy9zZWMmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZu YnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDQuMDAtNS4wMCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsm bmJzcDs0NS4wIE1CeXRlcyZuYnNwOyZuYnNwOyAzNzggTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJz cDs0XSZuYnNwOyZuYnNwOyA1LjAwLTYuMDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7Jm5ic3A7NDQu OSBNQnl0ZXMmbmJzcDsmbmJzcDsgMzc3IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJz cDsmbmJzcDsgNi4wMC03LjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOzQ1LjIgTUJ5dGVz Jm5ic3A7Jm5ic3A7IDM3OSBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7 IDcuMDAtOC4wMCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJzcDs0NS4xIE1CeXRlcyZuYnNwOyZu YnNwOyAzNzggTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyA4LjAwLTku MDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7Jm5ic3A7NDUuMyBNQnl0ZXMmbmJzcDsmbmJzcDsgMzgw IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgOS4wMC0xMC4wMCZuYnNw OyZuYnNwO3NlYyZuYnNwOyZuYnNwOzQ1LjIgTUJ5dGVzJm5ic3A7Jm5ic3A7IDM3OSBNYml0cy9z ZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLTwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5bIElEXSBJbnRlcnZhbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUcmFuc2ZlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBCYW5kd2lkdGg8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDAuMDAtMTAu MDAmbmJzcDsmbmJzcDtzZWMmbmJzcDsmbmJzcDsgNDU2IE1CeXRlcyZuYnNwOyZuYnNwOyAzODIg TWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7c2VuZGVyPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyAwLjAwLTEwLjAw Jm5ic3A7Jm5ic3A7c2VjJm5ic3A7Jm5ic3A7IDQ1NiBNQnl0ZXMmbmJzcDsmbmJzcDsgMzgyIE1i aXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3JlY2VpdmVyPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjMpIExBTi10by1X QU4gTkFUIHRlc3Qgd2l0aCBTT0ZUV0FSRSBvZmZsb2FkaW5nPC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmlwZXJmMyAtYyAx MC4xMC4xMC4zPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPkNvbm5lY3RpbmcgdG8gaG9zdCAxMC4xMC4xMC4zLCBwb3J0IDUy MDE8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdIGxvY2FsIDE5Mi4xNjguMS4xMzkgcG9ydCA1MTQ4 NCBjb25uZWN0ZWQgdG8gMTAuMTAuMTAuMyBwb3J0IDUyMDE8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyBJRF0gSW50ZXJ2 YWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVHJhbnNmZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFuZHdpZHRoPC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyAwLjAwLTEuMDAmbmJzcDsmbmJzcDsgc2VjJm5i c3A7Jm5ic3A7OTguNCBNQnl0ZXMmbmJzcDsmbmJzcDsgODI2IE1iaXRzL3NlYyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7 Jm5ic3A7NF0mbmJzcDsmbmJzcDsgMS4wMC0yLjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNw Ozk4LjIgTUJ5dGVzJm5ic3A7Jm5ic3A7IDgyNCBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRd Jm5ic3A7Jm5ic3A7IDIuMDAtMy4wMCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJzcDs5Ni45IE1C eXRlcyZuYnNwOyZuYnNwOyA4MTMgTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZu YnNwOyAzLjAwLTQuMDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7Jm5ic3A7OTcuNiBNQnl0ZXMmbmJz cDsmbmJzcDsgODE5IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgNC4w MC01LjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOzk4LjIgTUJ5dGVzJm5ic3A7Jm5ic3A7 IDgyNCBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDUuMDAtNi4wMCZu YnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJzcDs5Ni41IE1CeXRlcyZuYnNwOyZuYnNwOyA4MDkgTWJp dHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyA2LjAwLTcuMDAmbmJzcDsmbmJz cDsgc2VjJm5ic3A7Jm5ic3A7OTYuMCBNQnl0ZXMmbmJzcDsmbmJzcDsgODA1IE1iaXRzL3NlYyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgNy4wMC04LjAwJm5ic3A7Jm5ic3A7IHNlYyZu YnNwOyZuYnNwOzk2LjEgTUJ5dGVzJm5ic3A7Jm5ic3A7IDgwNiBNYml0cy9zZWMmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNw OyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDguMDAtOS4wMCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJz cDs5Ny44IE1CeXRlcyZuYnNwOyZuYnNwOyA4MjAgTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0 XSZuYnNwOyZuYnNwOyA5LjAwLTEwLjAwJm5ic3A7Jm5ic3A7c2VjJm5ic3A7Jm5ic3A7OTcuNSBN Qnl0ZXMmbmJzcDsmbmJzcDsgODE4IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsgSURdIEludGVydmFsJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRy YW5zZmVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhbmR3aWR0aDwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7 Jm5ic3A7NF0mbmJzcDsmbmJzcDsgMC4wMC0xMC4wMCZuYnNwOyZuYnNwO3NlYyZuYnNwOyZuYnNw OyA5NzMgTUJ5dGVzJm5ic3A7Jm5ic3A7IDgxNiBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzZW5kZXI8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZu YnNwOzRdJm5ic3A7Jm5ic3A7IDAuMDAtMTAuMDAmbmJzcDsmbmJzcDtzZWMmbmJzcDsmbmJzcDsg OTcxIE1CeXRlcyZuYnNwOyZuYnNwOyA4MTUgTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVjZWl2ZXI8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+NCkgTEFOLXRvLVdBTiBOQVQgdGVzdCB3aXRoIEhBUkRXQVJFIG9m ZmxvYWRpbmc8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+aXBlcmYzIC1jIDEwLjEwLjEwLjM8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q29ubmVjdGlu ZyB0byBob3N0IDEwLjEwLjEwLjMsIHBvcnQgNTIwMTwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0g bG9jYWwgMTkyLjE2OC4xLjEzOSBwb3J0IDUxNTIzIGNvbm5lY3RlZCB0byAxMC4xMC4xMC4zIHBv cnQgNTIwMTwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5bIElEXSBJbnRlcnZhbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUcmFuc2ZlciZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBCYW5kd2lkdGg8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7 IDAuMDAtMS4wMCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJzcDsgMTEwIE1CeXRlcyZuYnNwOyZu YnNwOyA5MjYgTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyAxLjAwLTIu MDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7Jm5ic3A7IDExMiBNQnl0ZXMmbmJzcDsmbmJzcDsgOTM4 IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgMi4wMC0zLjAwJm5ic3A7 Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOyAxMTEgTUJ5dGVzJm5ic3A7Jm5ic3A7IDkzMyBNYml0cy9z ZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDMuMDAtNC4wMCZuYnNwOyZuYnNwOyBz ZWMmbmJzcDsmbmJzcDsgMTExIE1CeXRlcyZuYnNwOyZuYnNwOyA5MzUgTWJpdHMvc2VjJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsm bmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyA0LjAwLTUuMDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7 Jm5ic3A7IDExMSBNQnl0ZXMmbmJzcDsmbmJzcDsgOTMzIE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5i c3A7NF0mbmJzcDsmbmJzcDsgNS4wMC02LjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOyAx MTEgTUJ5dGVzJm5ic3A7Jm5ic3A7IDkzMyBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5i c3A7Jm5ic3A7IDYuMDAtNy4wMCZuYnNwOyZuYnNwOyBzZWMmbmJzcDsmbmJzcDsgMTExIE1CeXRl cyZuYnNwOyZuYnNwOyA5MzMgTWJpdHMvc2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNw OyA3LjAwLTguMDAmbmJzcDsmbmJzcDsgc2VjJm5ic3A7Jm5ic3A7IDExMCBNQnl0ZXMmbmJzcDsm bmJzcDsgOTIzIE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgOC4wMC05 LjAwJm5ic3A7Jm5ic3A7IHNlYyZuYnNwOyZuYnNwOyAxMTEgTUJ5dGVzJm5ic3A7Jm5ic3A7IDkz NCBNYml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+WyZuYnNwOyZuYnNwOzRdJm5ic3A7Jm5ic3A7IDkuMDAtMTAuMDAmbmJz cDsmbmJzcDtzZWMmbmJzcDsmbmJzcDsgMTExIE1CeXRlcyZuYnNwOyZuYnNwOyA5MzMgTWJpdHMv c2VjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPi0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC08 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+WyBJRF0gSW50ZXJ2YWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVHJhbnNmZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQmFuZHdpZHRoPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsmbmJzcDsmbmJzcDs0XSZuYnNwOyZuYnNwOyAwLjAwLTEw LjAwJm5ic3A7Jm5ic3A7c2VjJm5ic3A7Jm5ic3A7MS4wOSBHQnl0ZXMmbmJzcDsmbmJzcDsgOTMy IE1iaXRzL3NlYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3NlbmRlcjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5bJm5ic3A7Jm5ic3A7NF0mbmJzcDsmbmJzcDsgMC4wMC0xMC4w MCZuYnNwOyZuYnNwO3NlYyZuYnNwOyZuYnNwOzEuMDggR0J5dGVzJm5ic3A7Jm5ic3A7IDkzMSBN Yml0cy9zZWMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtyZWNlaXZlcjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZWdhcmRpbmcg Q1BVIHV0aWxpemF0aW9uLCB1c2luZyBodG9wLCB3aXRoIGJvdGggTk8gb2ZmbG9hZGluZyBhbmQg U1cgb2ZmbG9hZGluZywgaXQgaXMgZXZpZGVudCB0aGF0IHRoZSBDUFUgaXMgYmVpbmcgdXNlZCBy ZWFjaGluZyBjbG9zZSB0byAxMDAlIG9mIG9uZSBvZiB0aGUgY29yZXMsIGEgYml0IGxlc3MgaW4g dGhlIG90aGVycywgd2hpbGUgSFcgb2ZmbG9hZGluZw0KIENQVSByZW1haW5zIHdpdGggdGhlIDEt MiUgdXRpbGl6YXRpb24uPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJ5IHRo ZSB3YXkgdGhlIGRldmljZXMgYXJlIGNoZWFwIG9uZXMsIGRpZmZlcmVudCB2ZW5kb3JzLCBubyBk aWZmZXJlbmNlIGlmIEkgZG8gdGhlIHRlc3Qgd2l0aCBvbmUgb3IgdGhlIG90aGVyICh0ZXN0ZWQg d2l0aCAzIGRpZmZlcmVudCBvbmVzIGFuZCBnb3Qgc2FtZSByZXN1bHRzKS4gVGhlIG1vc3QgZXhw ZW5zaXZlIG9uZSBpcyBwcm9iYWJseSBhcm91bmQgMzAgVVNEDQogKFpCVC1XRzM1MjYtMTZNKS48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSd2ZSB1c2VkIHRoZSBzdGFibGUg YnVpbGRzIGFuZCB0aGVuIHVwZ3JhZGVkIGV2ZXJ5dGhpbmcgdG8gdGhlIGxhdGVzdCB2ZXJzaW9u cy48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGEgaHJlZj0iaHR0cHM6Ly9k b3dubG9hZHMub3BlbndydC5vcmcvcmVsZWFzZXMvMTguMDYuMS90YXJnZXRzL3JhbWlwcy9tdDc2 MjEvIj5odHRwczovL2Rvd25sb2Fkcy5vcGVud3J0Lm9yZy9yZWxlYXNlcy8xOC4wNi4xL3Rhcmdl dHMvcmFtaXBzL210NzYyMS88L2E+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PklmIHlvdSdyZSBpbnRlcmVzdGVkIGFuZCBjb21pbmcgdG8gQktLLCBJIGNhbiBicmluZyBvbmUg b2YgdGhlbSBhbmQgd2UgY2FuIHBsYXkgYSBiaXQuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlJlZ2FyZHMsPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkpvcmRpPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPi0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tPC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkRlOiBNaWth ZWwgQWJyYWhhbXNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpzd21pa2VAc3dtLnBwLnNlIj5zd21p a2VAc3dtLnBwLnNlPC9hPiZndDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T3JnYW5pemFjacOzbjogUGVvcGxlJ3MgRnJv bnQgQWdhaW5zdCBXV1c8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RmVjaGE6IGp1ZXZlcywgMTggZGUgb2N0dWJyZSBkZSAy MDE4LCAxOTo0NTwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5QYXJhOiBKT1JESSBQQUxFVCBNQVJUSU5FWiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzIj5qb3JkaS5wYWxldEBjb25zdWxp bnRlbC5lczwvYT4mZ3Q7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNDOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFzdW50bzogUmU6IFt2Nm9w c10gVHJhamVjdG9yeSBmb3IgJnF1b3Q7dHJhbnNpdGlvbiZxdW90OyBtZWNoYW5pc21zIGluIG91 ciB3b3JraW5nIGdyb3VwPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO09uIFRodSwgMTggT2N0IDIwMTgsIEpPUkRJIFBBTEVUIE1BUlRJ TkVaIHdyb3RlOjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBZZXMsIDEwMCUgc3VyZSBpbiB0aGlzIGNhc2UuPC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jmd0OyBUaGUgU29DIHN1cHBvcnRzIGl0IHdpdGggc2V2ZXJhbCBTREtzL09T czo8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lm1lZGlhdGVrLmNvbS9w cm9kdWN0cy9ob21lTmV0d29ya2luZy9tdDc2MjFuLWEiPg0KaHR0cHM6Ly93d3cubWVkaWF0ZWsu Y29tL3Byb2R1Y3RzL2hvbWVOZXR3b3JraW5nL210NzYyMW4tYTwvYT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm Z3Q7IFlvdSBjYW4gZW5hYmxlIEhXIG9yIFNXIG9mZmxvYWRpbmcsIG9mZmVycyBib3RoIG9wdGlv bnMgKGRpZG4ndCBjaGVja2VkDQo8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0 OyB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlLCBJIGp1c3QgZ28gZm9yIHRoZSBIVyBpZiBpdCB3b3Jr cywgYXMgSSBndWVzcw0KPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgb3V0 cGVyZm9ybXMgdGhlIFNXIG9uZSkuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJIGtub3cgdGhlIE1UNzYyMSBkb2VzIHdo YXQgeW91J3JlIHNheWluZyBpbiBvdGhlciBPU2VzIHdpdGggdGhlaXIgU0RLLA0KPC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0knbSBxdWVzdGlvbmluZyBpZiB0aGUgLWogRkxPV09G RkxPQUQgaXMgdGhlIHdheSB0byBkbyBIVyBhY2NlbGVyYXRpb24gZm9yDQo8L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2VydGFpbiBmbG93cy4gRGlkIHlvdSB0cnkgdG8gcnVuIGZ1 bGwgZ2lnIHNwZWVkIHRocm91Z2ggaXQgYW5kIGNoZWNrIENQVQ0KPC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3VzYWdlPyBJdCdzIHRoZSBlYXNpZXN0IHdheSB0byB0ZWxsIGlmIHRo ZSBvZmZsb2FkIHdvcmtzIG9yIG5vdC48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0l0IHdvdWxkIGJlIHRoZSBsZWFzdCBp bnRydXNpdmUgb2ZmbG9hZCBpbXBsZW1lbnRhdGlvbiBJJ3ZlIGV2ZXIgc2VlbiBpbg0KPC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0xpbnV4LCBzbyBpZiBpdCBhY3R1YWxseSB3b3Jr cyB0aGlzIHdheSBJJ2QgYmUgdmVyeSBoYXBweSwgYW5kIGhvcGUgbW9yZQ0KPC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3ZlbmRvcnMgZG9lcyBpdCB0aGUgc2FtZSB3YXkuPC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtEaWQgeW91IGJ1eSBzb21lIHJldGFpbCBkZXZpY2U/IElmIHlvdSBkaWQsIHdoYXQgd2Fz IGl0PzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7LS0gPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO01pa2Fl bCBBYnJhaGFtc3NvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VtYWlsOiA8YSBocmVmPSJtYWls dG86c3dtaWtlQHN3bS5wcC5zZSI+DQpzd21pa2VAc3dtLnBwLnNlPC9hPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Kioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JUHY0 IGlzIG92ZXI8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+QXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxhIGhyZWY9Imh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMiPmh0dHA6Ly93d3cuY29u c3VsaW50ZWwuZXM8L2E+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBJUHY2IENvbXBhbnk8L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5m b3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5m b3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhv cml6ZWQNCiBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBj b250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5n IGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNp ZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsDQogY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBw YXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVw bHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0 aW9uIGFuZCBkZWxldGUNCiBpdC48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+djZv cHMgbWFpbGluZyBsaXN0PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+ djZvcHNAaWV0Zi5vcmc8L2E+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHM8L2E+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AD4EA0BFE55E4B6B8A68FA080C59339Dciscocom_-- From nobody Tue Oct 23 10:32:07 2018 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 75DDC124C04 for ; Tue, 23 Oct 2018 10:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWDffJ_wGgnX for ; Tue, 23 Oct 2018 10:32:01 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF07127B92 for ; Tue, 23 Oct 2018 10:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1540315917; x=1540920717; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=xkL50wJGI4EquAZa6t4Eld iHdvcSjlHM/XFa9qJZ/HA=; b=aO1joV+yy7pEf72RkCUZCGR+jblsxJDn4puUJK mlxUydncWGkodns2yts4H6pfvIsyFPuOszhMlEVYNPYPHC43T4RoazzMPfYD3Lvk m8Hma52RnIxKVkFQwAnogUUdy/OiLyfqWHvHL0qHfbo9Mz6Ko4w02iIwPn8mHB+u ANnZ4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 23 Oct 2018 19:31:57 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 23 Oct 2018 19:31:56 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005921276.msg for ; Tue, 23 Oct 2018 19:31:55 +0200 X-MDRemoteIP: 2001:470:1f09:495:e029:6e39:5a:1318 X-MDHelo: [10.10.10.99] X-MDArrival-Date: Tue, 23 Oct 2018 19:31:55 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1834938bf9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.3.181015 Date: Tue, 23 Oct 2018 19:31:50 +0200 From: JORDI PALET MARTINEZ To: "Rajiv Asati (rajiva)" , Mikael Abrahamsson CC: "v6ops@ietf.org" Message-ID: <3712E83E-5DD3-44F4-B80C-C488030F10EE@consulintel.es> Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3623167910_773103428" Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 17:32:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3623167910_773103428 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Rajiv, =20 In the scope of draft-lmhp-v6ops-transition-comparison, we are planning som= e measurements, but I=E2=80=99m not sure when and how we will be able to do= them. =20 Also, if we really want to have those being realistic, we should plan diffe= rent testing combinations, and also differentiate the performance of the CE= part vs the =E2=80=9Cnetwork=E2=80=9D part and the combination of both. =20 Last but not least, we can easily do with opensource, for example OpenWRT o= r VPP in for the CPE and Jool or VPP for the NAT64/BR on the other side, or= combinations of them, but trying to make it with hardware from vendors, un= less they want to provide it, will be difficult. =20 I=E2=80=99m happy to invest time in that, but we need to correctly plan all= the details to be fair with the measurements. =20 It may be a topic also for a hackathon, but I=E2=80=99m not sure there is s= ufficient time in a weekend for all the testing =E2=80=A6 Regards, Jordi =20 =20 =20 De: v6ops en nombre de "Rajiv Asati (rajiva)" Fecha: martes, 23 de octubre de 2018, 19:20 Para: JORDI PALET MARTINEZ ,= Mikael Abrahamsson CC: "v6ops@ietf.org" Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup =20 Jordi, =20 This is quite useful. Do you also happen to have similar test numbers with = CLAT functionality vs. MAP(-T/E) CE functionality? That would really help, = and OpenWRT supports them. =20 It would be pertinent to have consistent traffic amount and no of connectio= ns/flows in each case.=20 =20 Say, 60% IPv6 and 40% IPv4 traffic (by bps) as well as connections.=20 =20 Has anybody got any recent measurement about no of connections per HGW? Min= e is dated in 2012-2013. =20 Cheers, Rajiv =20 =20 From: v6ops on behalf of JORDI PALET MARTINEZ Date: Friday, October 19, 2018 at 4:04 PM To: Mikael Abrahamsson Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working = group =20 Hi Mikael, =20 Sorry, was coming back from the RIPE and arranging a small test to show you= the results, which are consistent with what I recall from my previous test= ing. =20 I'm using an ubuntu VM as the server, running in ESXi 6.5, and as client my= own laptop. =20 There is a Cisco switch between the server, the MT7621 device and my client= . =20 Ubuntu VM in ESXi --- Cisco Gig switch --- MT7621 under test --- client dev= ice =20 Server command: iperf3 -s =20 1) LAN-to-LAN test (so both the server and client are connected to the LANs= of the MT7621) iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 10.10.10.99 port 51300 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 113 MBytes 951 Mbits/sec =20 [ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 2.00-3.00 sec 112 MBytes 938 Mbits/sec =20 [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 4.00-5.00 sec 112 MBytes 936 Mbits/sec =20 [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 7.00-8.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 8.00-9.00 sec 112 MBytes 937 Mbits/sec =20 [ 4] 9.00-10.00 sec 112 MBytes 936 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec sende= r [ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec recei= ver =20 2) LAN-to-WAN NAT test without offloading iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 192.168.1.139 port 51447 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 48.8 MBytes 409 Mbits/sec =20 [ 4] 1.00-2.00 sec 45.8 MBytes 384 Mbits/sec =20 [ 4] 2.00-3.00 sec 45.2 MBytes 379 Mbits/sec =20 [ 4] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec =20 [ 4] 4.00-5.00 sec 45.0 MBytes 378 Mbits/sec =20 [ 4] 5.00-6.00 sec 44.9 MBytes 377 Mbits/sec =20 [ 4] 6.00-7.00 sec 45.2 MBytes 379 Mbits/sec =20 [ 4] 7.00-8.00 sec 45.1 MBytes 378 Mbits/sec =20 [ 4] 8.00-9.00 sec 45.3 MBytes 380 Mbits/sec =20 [ 4] 9.00-10.00 sec 45.2 MBytes 379 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec sende= r [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec recei= ver =20 3) LAN-to-WAN NAT test with SOFTWARE offloading iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 192.168.1.139 port 51484 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 98.4 MBytes 826 Mbits/sec =20 [ 4] 1.00-2.00 sec 98.2 MBytes 824 Mbits/sec =20 [ 4] 2.00-3.00 sec 96.9 MBytes 813 Mbits/sec =20 [ 4] 3.00-4.00 sec 97.6 MBytes 819 Mbits/sec =20 [ 4] 4.00-5.00 sec 98.2 MBytes 824 Mbits/sec =20 [ 4] 5.00-6.00 sec 96.5 MBytes 809 Mbits/sec =20 [ 4] 6.00-7.00 sec 96.0 MBytes 805 Mbits/sec =20 [ 4] 7.00-8.00 sec 96.1 MBytes 806 Mbits/sec =20 [ 4] 8.00-9.00 sec 97.8 MBytes 820 Mbits/sec =20 [ 4] 9.00-10.00 sec 97.5 MBytes 818 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 973 MBytes 816 Mbits/sec sende= r [ 4] 0.00-10.00 sec 971 MBytes 815 Mbits/sec recei= ver =20 4) LAN-to-WAN NAT test with HARDWARE offloading iperf3 -c 10.10.10.3 Connecting to host 10.10.10.3, port 5201 [ 4] local 192.168.1.139 port 51523 connected to 10.10.10.3 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 110 MBytes 926 Mbits/sec =20 [ 4] 1.00-2.00 sec 112 MBytes 938 Mbits/sec =20 [ 4] 2.00-3.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 3.00-4.00 sec 111 MBytes 935 Mbits/sec =20 [ 4] 4.00-5.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec =20 [ 4] 7.00-8.00 sec 110 MBytes 923 Mbits/sec =20 [ 4] 8.00-9.00 sec 111 MBytes 934 Mbits/sec =20 [ 4] 9.00-10.00 sec 111 MBytes 933 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.09 GBytes 932 Mbits/sec sende= r [ 4] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec recei= ver =20 Regarding CPU utilization, using htop, with both NO offloading and SW offlo= ading, it is evident that the CPU is being used reaching close to 100% of o= ne of the cores, a bit less in the others, while HW offloading CPU remains = with the 1-2% utilization. =20 By the way the devices are cheap ones, different vendors, no difference if = I do the test with one or the other (tested with 3 different ones and got s= ame results). The most expensive one is probably around 30 USD (ZBT-WG3526-= 16M). =20 I've used the stable builds and then upgraded everything to the latest vers= ions. =20 https://downloads.openwrt.org/releases/18.06.1/targets/ramips/mt7621/ =20 If you're interested and coming to BKK, I can bring one of them and we can = play a bit. =20 Regards, Jordi =20 -----Mensaje original----- De: Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Fecha: jueves, 18 de octubre de 2018, 19:45 Para: JORDI PALET MARTINEZ CC: Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup =20 On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: =20 > Yes, 100% sure in this case. > > The SoC supports it with several SDKs/OSs: > > https://www.mediatek.com/products/homeNetworking/mt7621n-a > > You can enable HW or SW offloading, offers both options (didn't check= ed=20 > what is the difference, I just go for the HW if it works, as I guess= =20 > outperforms the SW one). =20 I know the MT7621 does what you're saying in other OSes with their SDK,= =20 I'm questioning if the -j FLOWOFFLOAD is the way to do HW acceleration = for=20 certain flows. Did you try to run full gig speed through it and check C= PU=20 usage? It's the easiest way to tell if the offload works or not. =20 It would be the least intrusive offload implementation I've ever seen i= n=20 Linux, so if it actually works this way I'd be very happy, and hope mor= e=20 vendors does it the same way. =20 Did you buy some retail device? If you did, what was it? =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3623167910_773103428 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Rajiv,

=  

In the scope of d= raft-lmhp-v6ops-transition-comparison, we are planning some measurements, b= ut I=E2=80=99m not sure when and how we will be able to do them.=

 

Also, if we really want to have = those being realistic, we should plan different testing combinations, and a= lso differentiate the performance of the CE part vs the =E2=80=9Cnetwork=E2= =80=9D part and the combination of both.

 =

Last but not least, we can easily do with opensource, fo= r example OpenWRT or VPP in for the CPE and Jool or VPP for the NAT64/BR on= the other side, or combinations of them, but trying to make it with hardwa= re from vendors, unless they want to provide it, will be difficult.

 

I=E2=80=99m happy to invest t= ime in that, but we need to correctly plan all the details to be fair with = the measurements.

 

It m= ay be a topic also for a hackathon, but I=E2=80=99m not sure there is suffi= cient time in a weekend for all the testing =E2=80=A6

=


Regards,

Jordi

 

 

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>De: v6ops <v6ops-bounces@ietf.org> en nombre de "Rajiv Asati = (rajiva)" <rajiva@cisco.com>
Fecha: martes, 23 de octu= bre de 2018, 19:20
Para: JORDI PALET MARTINEZ <jordi.palet=3D4= 0consulintel.es@dmarc.ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se= >
CC: "v6ops@ietf.org" <v6ops@ietf.org>
= Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in= our working group

 

Jordi,

 

This is quite useful. Do you also happen to have simila= r test numbers with CLAT functionality vs. MAP(-T/E) CE functionality? That= would really help, and OpenWRT supports them.

 

It would be pertinent to have consistent tr= affic amount and no of connections/flows in each case.

 

Say, 60% IPv6 and 40% IPv4 traffic (b= y bps) as well as connections.

 

Has anybody got any recent measurement about no of connect= ions per HGW? Mine is dated in 2012-2013.

 

Cheers,

Rajiv

 

 

From: <= /span>v6ops <v6ops-boun= ces@ietf.org> on behalf of JORDI PALET MARTINEZ <jordi.palet=3D40cons= ulintel.es@dmarc.ietf.org>
Date: Friday, October 19, 2018 at 4= :04 PM
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: = "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re= : [v6ops] Trajectory for "transition" mechanisms in our working g= roup

 

Hi Mikael,

 

Sorry, was coming back from the RIPE a= nd arranging a small test to show you the results, which are consistent wit= h what I recall from my previous testing.

 

<= p class=3DMsoNormal style=3D'margin-left:71.4pt'>I'm using an ubuntu VM as = the server, running in ESXi 6.5, and as client my own laptop.

 

There = is a Cisco switch between the server, the MT7621 device and my client.=

&nbs= p;

Ubuntu VM in ESXi --- Cisco Gig switch --- MT7621 under test --- client = device

 

Server command: iperf3 -s

 

<= p class=3DMsoNormal style=3D'margin-left:71.4pt'>1) LAN-to-LAN test (so bot= h the server and client are connected to the LANs of the MT7621)=

iperf3 -c = 10.10.10.3

Connecting to host 10.10.10.3, port 5201

[  4] local 1= 0.10.10.99 port 51300 connected to 10.10.10.3 port 5201

[ ID] Interval = ;          Transfer  = ;   Bandwidth

[  4]   0.00-1.00   s= ec   113 MBytes   951 Mbits/sec    =             &nb= sp; 

[  4]   1.00-2.00   sec  = 112 MBytes   937 Mbits/sec      &n= bsp;           =

[  4] &nbs= p; 2.00-3.00   sec   112 MBytes   938 Mbits/s= ec            &= nbsp;     

[  4]   3.00-4.00&n= bsp;  sec   112 MBytes   937 Mbits/sec  =             &nb= sp;   

[  4]   4.00-5.00   s= ec   112 MBytes   936 Mbits/sec    =             &nb= sp; 

[  4]   5.00-6.00   sec  = 112 MBytes   937 Mbits/sec      &n= bsp;           =

[&nb= sp; 4]   6.00-7.00   sec   112 MBytes&nb= sp;  937 Mbits/sec        &nbs= p;         

[  4]&nb= sp;  7.00-8.00   sec   112 MBytes   937 = Mbits/sec           =        

[  4]   8.00= -9.00   sec   112 MBytes   937 Mbits/sec = ;            &n= bsp;    

[  4]   9.00-10.00 &n= bsp;sec   112 MBytes   936 Mbits/sec   &= nbsp;           &nbs= p;  

- - - - - - - - - - - - - - - - - - - - - - - - -=

[ ID] Inte= rval           Transfer&n= bsp;    Bandwidth

[  4]   0.00-10.00&nbs= p; sec  1.09 GBytes   938 Mbits/sec  &nb= sp;            =    sender

[  4]   0.00-10.00  = sec  1.09 GBytes   937 Mbits/sec    = ;            &n= bsp; receiver

 

2) LAN-to-WAN NAT test without offloading

iperf3 = -c 10.10.10.3

Connecting to host 10.10.10.3, port 5201

=

[  4] loca= l 192.168.1.139 port 51447 connected to 10.10.10.3 port 5201

=

[ ID] Interval=            Transfer =     Bandwidth

[  4]   0.00-1.00 &nb= sp; sec  48.8 MBytes   409 Mbits/sec   &= nbsp;              

[  4]   1= .00-2.00   sec  45.8 MBytes   384 Mbits/sec&n= bsp;            = ;     

[  4]   2.00-3.00 =   sec  45.2 MBytes   379 Mbits/sec  &nbs= p;            &= nbsp;  

[  4]   3.00-4.00   sec&nbs= p; 45.2 MBytes   379 Mbits/sec     =             &nb= sp;

[  4]   4.00-5.00   sec  45.0 M= Bytes   378 Mbits/sec       &n= bsp;          =

[ &nb= sp;4]   5.00-6.00   sec  44.9 MBytes &nb= sp; 377 Mbits/sec         &nbs= p;        

[  4] &nb= sp; 6.00-7.00   sec  45.2 MBytes   379 Mbits/= sec            =       

[  4]   7.00-8.00&= nbsp;  sec  45.1 MBytes   378 Mbits/sec  = ;            &n= bsp;   

[  4]   8.00-9.00   s= ec  45.3 MBytes   380 Mbits/sec    =             &nb= sp; 

[  4]   9.00-10.00  sec  = 45.2 MBytes   379 Mbits/sec      &n= bsp;           =

- - = - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval  &nb= sp;        Transfer   &nb= sp; Bandwidth

[  4]   0.00-10.00  sec &n= bsp; 456 MBytes   382 Mbits/sec     &nbs= p;            s= ender

[  4]   0.00-10.00  sec   456= MBytes   382 Mbits/sec       =            receiver<= o:p>

=  

3) LAN-to-WAN NAT test with SOFTWARE offloading

=

iperf3 -c 10.10.10.3=

Connecting to host 10.10.10.3, port 5201

[  4] local 192.168.1.1= 39 port 51484 connected to 10.10.10.3 port 5201

[ ID] Interval         &n= bsp; Transfer     Bandwidth

[  4]  = 0.00-1.00   sec  98.4 MBytes   826 Mbits/sec=             &nb= sp;     

[  4]   1.00-2.00&nbs= p;  sec  98.2 MBytes   824 Mbits/sec  &n= bsp;            = ;   

[  4]   2.00-3.00   sec&n= bsp; 96.9 MBytes   813 Mbits/sec    &nbs= p;            &= nbsp;

[  4]   3.00-4.00   sec  97.6= MBytes   819 Mbits/sec       =            

[ &= nbsp;4]   4.00-5.00   sec  98.2 MBytes &= nbsp; 824 Mbits/sec         &n= bsp;        

[  4] &= nbsp; 5.00-6.00   sec  96.5 MBytes   809 Mbit= s/sec           &nbs= p;      

[  4]   6.00-7.0= 0   sec  96.0 MBytes   805 Mbits/sec &nb= sp;            =     

[  4]   7.00-8.00   = sec  96.1 MBytes   806 Mbits/sec    = ;            &n= bsp; 

[  4]   8.00-9.00   sec  = ;97.8 MBytes   820 Mbits/sec      &= nbsp;           

[&n= bsp; 4]   9.00-10.00  sec  97.5 MBytes&n= bsp;  818 Mbits/sec        &nb= sp;         

- - - - - - - - -= - - - - - - - - - - - - - - - -

[ ID] Interval    &nbs= p;      Transfer     Bandwidth=

[  4]   0.00-10.00  sec   973 MByt= es   816 Mbits/sec        = ;          sender

[ =  4]   0.00-10.00  sec   971 MBytes =   815 Mbits/sec         &= nbsp;        receiver

 

4) LAN= -to-WAN NAT test with HARDWARE offloading

iperf3 -c 10.10.10.3

Connecting to host 10.10.10.3, port 5201<= /o:p>

[&nbs= p; 4] local 192.168.1.139 port 51523 connected to 10.10.10.3 port 5201=

[ ID] Interval          = Transfer     Bandwidth

[  4]   0.0= 0-1.00   sec   110 MBytes   926 Mbits/sec&nbs= p;            &= nbsp;    

[  4]   1.00-2.00 &n= bsp; sec   112 MBytes   938 Mbits/sec   =             &nb= sp;  

[  4]   2.00-3.00   sec =   111 MBytes   933 Mbits/sec     &n= bsp;            = ;

[  4]   3.00-4.00   sec   111 MBy= tes   935 Mbits/sec       &nbs= p;          

[  = ;4]   4.00-5.00   sec   111 MBytes  = ; 933 Mbits/sec          =         

<= p class=3DMsoNormal style=3D'margin-left:71.4pt'>[  4]  = ; 5.00-6.00   sec   111 MBytes   933 Mbits/se= c            &n= bsp;     

[  4]   6.00-7.00&nb= sp;  sec   111 MBytes   933 Mbits/sec  &= nbsp;           &nbs= p;   

[  4]   7.00-8.00   sec&= nbsp;  110 MBytes   923 Mbits/sec    &nb= sp;            =  

[  4]   8.00-9.00   sec   11= 1 MBytes   934 Mbits/sec       = ;           

[ =  4]   9.00-10.00  sec   111 MBytes =   933 Mbits/sec         &= nbsp;        

<= div>

- - - - - - - - - - -= - - - - - - - - - - - - - -

[ ID] Interval     &n= bsp;     Transfer     Bandwidth

[&n= bsp; 4]   0.00-10.00  sec  1.09 GBytes&n= bsp;  932 Mbits/sec        &nb= sp;         sender<= /p>

[ &nbs= p;4]   0.00-10.00  sec  1.08 GBytes &nbs= p; 931 Mbits/sec               &nb= sp;  receiver

 

Regarding CPU utilization, using htop, with = both NO offloading and SW offloading, it is evident that the CPU is being u= sed reaching close to 100% of one of the cores, a bit less in the others, w= hile HW offloading CPU remains with the 1-2% utilization.

 =

By the way= the devices are cheap ones, different vendors, no difference if I do the t= est with one or the other (tested with 3 different ones and got same result= s). The most expensive one is probably around 30 USD (ZBT-WG3526-16M).=

&nbs= p;

I've used the stable builds and then upgraded everything to the latest v= ersions.

 

 

If you're interested and coming to BKK, I ca= n bring one of them and we can play a bit.

 

=

Regards,

Jordi=

 

---= --Mensaje original-----

De: Mikael Abrahamsson <swmike@swm.pp.se>

Organizaci=C3=B3n: People's Front Agai= nst WWW

Fecha: jueves, 18 de octubre de 2018, 19:45

Para: JORDI PALET MARTI= NEZ <jordi.palet@consulint= el.es>

CC: <v6ops@ietf.org&= gt;

Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in= our working group

 

    On Thu, 18 Oct 2018, JORD= I PALET MARTINEZ wrote:

    

<= p class=3DMsoNormal style=3D'margin-left:71.4pt'>    &g= t; Yes, 100% sure in this case.

    >

=

  &n= bsp; > The SoC supports it with several SDKs/OSs:

   = ; >

    >

<= div>

    > You can enable HW or = SW offloading, offers both options (didn't checked

    = ;> what is the difference, I just go for the HW if it works, as I guess =

    > outperforms the SW one).

=

   &n= bsp;

    I know the MT7621 does what you're saying in o= ther OSes with their SDK,

    I'm questioning if the -= j FLOWOFFLOAD is the way to do HW acceleration for

    = ;certain flows. Did you try to run full gig speed through it and check CPU =

    usage? It's the easiest way to tell if the offload= works or not.

    

    It would = be the least intrusive offload implementation I've ever seen in =

 &nbs= p;  Linux, so if it actually works this way I'd be very happy, an= d hope more

    vendors does it the same way.

 &n= bsp;  

    Did you buy some retail device? If= you did, what was it?

    

<= p class=3DMsoNormal style=3D'margin-left:71.4pt'>    --=

    Mikael Abrahamsson    email: = swmike@swm.pp.se

   =  

 

 

 

**********************************************<= o:p>

= IPv4 is over

Are you ready for the new Internet ?

The IPv6 Company

<= /div>

 

This ele= ctronic message contains information which may be privileged or confidentia= l. The information is intended to be for the exclusive use of the individua= l(s) named above and further non-explicilty authorized disclosure, copying,= distribution or use of the contents of this information, even if partially= , including attached files, is strictly prohibited and will be considered a= criminal offense. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this informatio= n, even if partially, including attached files, is strictly prohibited, wil= l be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it.

 

 

 =

__________= _____________________________________

v6ops mailing list

 =

_________= ______________________________________ v6ops mailing list v6ops@ietf.org ht= tps://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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3623167910_773103428-- From nobody Tue Oct 23 11:55:10 2018 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 C8BBC12DDA3 for ; Tue, 23 Oct 2018 11:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pohHKyUsh-u for ; Tue, 23 Oct 2018 11:55:03 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEA5130EEC for ; Tue, 23 Oct 2018 11:55:02 -0700 (PDT) Received: from [192.168.1.119] (host-79-121-40-230.kabelnet.hu [79.121.40.230]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w9NIsZtQ014374 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Oct 2018 20:54:42 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-40-230.kabelnet.hu [79.121.40.230] claimed to be [192.168.1.119] To: v6ops@ietf.org References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> <3712E83E-5DD3-44F4-B80C-C488030F10EE@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Cc: Marius Georgescu Message-ID: <7778a6a0-30dd-1953-eb3f-9d85fe0997a6@hit.bme.hu> Date: Tue, 23 Oct 2018 20:54:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3712E83E-5DD3-44F4-B80C-C488030F10EE@consulintel.es> Content-Type: multipart/alternative; boundary="------------7A96A9FFD72BB9219E3B963F" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.40.230; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 18:55:10 -0000 This is a multi-part message in MIME format. --------------7A96A9FFD72BB9219E3B963F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, 10/23/2018 7:31 PM keltezéssel, JORDI PALET MARTINEZ írta: > > Hi Rajiv, > > In the scope of draft-lmhp-v6ops-transition-comparison, we are > planning some measurements, but I’m not sure when and how we will be > able to do them. > > Also, if we really want to have those being realistic, we should plan > different testing combinations, and also differentiate the performance > of the CE part vs the “network†part and the combination of both. > > Last but not least, we can easily do with opensource, for example > OpenWRT or VPP in for the CPE and Jool or VPP for the NAT64/BR on the > other side, or combinations of them, but trying to make it with > hardware from vendors, unless they want to provide it, will be difficult. > > I’m happy to invest time in that, but we need to correctly plan all > the details to be fair with the measurements. > > It may be a topic also for a hackathon, but I’m not sure there is > sufficient time in a weekend for all the testing … > As for benchmarking, iperf or RFC 2544 (RFC 5180) compliant testers may only be used when the devices are used in pairs. RFC 8219 call this as "Dual DUT" setup. Testing according to the "Single DUT" setup would require special Testers. (E.g. for testing a NAT64 gateway: the Tester needs to be able to send IPv6 packets to the DUT and receive IPv4 traffic from the DUT in one direction, while it needs to send IPv4 packets to the DUT and receive IPv6 packets from the DUT in the other direction at the same time, as bidirectional traffic is required.) As far as I know, no special Testers available yet. (One of my PhD students working on a DPDK based stateless NAT64 tester, but it is far from usable.) I think implementing RFC 8219 compliant special Testers for the five IPv4aaS technologies mentioned in draft-lmhp-v6ops-transition-comparison, would be an interesting task for hackathon! I definitely recommend using DPDK to achieve the required performance. (Perhaps TRex https://trex-tgn.cisco.com/ may help in implementing the Testers, but later it may be more complicated to use them. ) Best regards, Gábor Lencse > > Regards, > > Jordi > > *De: *v6ops en nombre de "Rajiv Asati > (rajiva)" > *Fecha: *martes, 23 de octubre de 2018, 19:20 > *Para: *JORDI PALET MARTINEZ > , Mikael Abrahamsson > > *CC: *"v6ops@ietf.org" > *Asunto: *Re: [v6ops] Trajectory for "transition" mechanisms in our > working group > > Jordi, > > This is quite useful. Do you also happen to have similar test numbers > with CLAT functionality vs. MAP(-T/E) CE functionality? That would > really help, and OpenWRT supports them. > > It would be pertinent to have consistent traffic amount and no of > connections/flows in each case. > > Say, 60% IPv6 and 40% IPv4 traffic (by bps) as well as connections. > > Has anybody got any recent measurement about no of connections per > HGW? Mine is dated in 2012-2013. > > Cheers, > > Rajiv > > *From: *v6ops on behalf of JORDI PALET > MARTINEZ > *Date: *Friday, October 19, 2018 at 4:04 PM > *To: *Mikael Abrahamsson > *Cc: *"v6ops@ietf.org" > *Subject: *Re: [v6ops] Trajectory for "transition" mechanisms in our > working group > > Hi Mikael, > > Sorry, was coming back from the RIPE and arranging a small test to > show you the results, which are consistent with what I recall from my > previous testing. > > I'm using an ubuntu VM as the server, running in ESXi 6.5, and as > client my own laptop. > > There is a Cisco switch between the server, the MT7621 device and my > client. > > Ubuntu VM in ESXi --- Cisco Gig switch --- MT7621 under test --- > client device > > Server command: iperf3 -s > > 1) LAN-to-LAN test (so both the server and client are connected to the > LANs of the MT7621) > > iperf3 -c 10.10.10.3 > > Connecting to host 10.10.10.3, port 5201 > > [  4] local 10.10.10.99 port 51300 connected to 10.10.10.3 port 5201 > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-1.00   sec   113 MBytes   951 Mbits/sec > > [  4] 1.00-2.00   sec   112 MBytes   937 Mbits/sec > > [  4] 2.00-3.00   sec   112 MBytes   938 Mbits/sec > > [  4] 3.00-4.00   sec   112 MBytes   937 Mbits/sec > > [  4] 4.00-5.00   sec   112 MBytes   936 Mbits/sec > > [  4] 5.00-6.00   sec   112 MBytes   937 Mbits/sec > > [  4] 6.00-7.00   sec   112 MBytes   937 Mbits/sec > > [  4] 7.00-8.00   sec   112 MBytes   937 Mbits/sec > > [  4] 8.00-9.00   sec   112 MBytes   937 Mbits/sec > > [  4] 9.00-10.00  sec   112 MBytes   936 Mbits/sec > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-10.00  sec  1.09 GBytes   938 Mbits/sec                  sender > > [  4] 0.00-10.00  sec  1.09 GBytes   937 > Mbits/sec                  receiver > > 2) LAN-to-WAN NAT test without offloading > > iperf3 -c 10.10.10.3 > > Connecting to host 10.10.10.3, port 5201 > > [  4] local 192.168.1.139 port 51447 connected to 10.10.10.3 port 5201 > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-1.00   sec  48.8 MBytes   409 Mbits/sec > > [  4] 1..00-2.00   sec  45.8 MBytes   384 Mbits/sec > > [  4] 2.00-3.00   sec  45.2 MBytes   379 Mbits/sec > > [  4] 3.00-4.00   sec  45.2 MBytes   379 Mbits/sec > > [  4] 4.00-5.00   sec  45.0 MBytes   378 Mbits/sec > > [  4] 5.00-6.00   sec  44.9 MBytes   377 Mbits/sec > > [  4] 6.00-7.00   sec  45.2 MBytes   379 Mbits/sec > > [  4] 7.00-8.00   sec  45.1 MBytes   378 Mbits/sec > > [  4] 8.00-9.00   sec  45.3 MBytes   380 Mbits/sec > > [  4] 9.00-10.00  sec  45.2 MBytes   379 Mbits/sec > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-10.00  sec   456 MBytes   382 Mbits/sec                  sender > > [  4] 0.00-10.00  sec   456 MBytes   382 > Mbits/sec                  receiver > > 3) LAN-to-WAN NAT test with SOFTWARE offloading > > iperf3 -c 10.10.10.3 > > Connecting to host 10.10.10.3, port 5201 > > [  4] local 192.168.1.139 port 51484 connected to 10.10.10.3 port 5201 > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-1.00   sec  98.4 MBytes   826 Mbits/sec > > [  4] 1.00-2.00   sec  98.2 MBytes   824 Mbits/sec > > [  4] 2.00-3.00   sec  96.9 MBytes   813 Mbits/sec > > [  4] 3.00-4.00   sec  97.6 MBytes   819 Mbits/sec > > [  4] 4.00-5.00   sec  98.2 MBytes   824 Mbits/sec > > [  4] 5.00-6.00   sec  96.5 MBytes   809 Mbits/sec > > [  4] 6.00-7.00   sec  96.0 MBytes   805 Mbits/sec > > [  4] 7.00-8.00   sec  96.1 MBytes   806 Mbits/sec > > [  4] 8.00-9.00   sec  97.8 MBytes   820 Mbits/sec > > [  4] 9.00-10.00  sec  97.5 MBytes   818 Mbits/sec > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-10.00  sec   973 MBytes   816 Mbits/sec                  sender > > [  4] 0.00-10.00  sec   971 MBytes   815 > Mbits/sec                  receiver > > 4) LAN-to-WAN NAT test with HARDWARE offloading > > iperf3 -c 10.10.10.3 > > Connecting to host 10.10.10.3, port 5201 > > [  4] local 192.168.1.139 port 51523 connected to 10.10.10.3 port 5201 > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-1.00   sec   110 MBytes   926 Mbits/sec > > [  4] 1.00-2.00   sec   112 MBytes   938 Mbits/sec > > [  4] 2.00-3.00   sec   111 MBytes   933 Mbits/sec > > [  4] 3.00-4.00   sec   111 MBytes   935 Mbits/sec > > [  4] 4.00-5.00   sec   111 MBytes   933 Mbits/sec > > [  4] 5.00-6.00   sec   111 MBytes   933 Mbits/sec > > [  4] 6.00-7.00   sec   111 MBytes   933 Mbits/sec > > [  4] 7.00-8.00   sec   110 MBytes   923 Mbits/sec > > [  4] 8.00-9.00   sec   111 MBytes   934 Mbits/sec > > [  4] 9.00-10.00  sec   111 MBytes   933 Mbits/sec > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval           Transfer     Bandwidth > > [  4] 0.00-10.00  sec  1.09 GBytes   932 Mbits/sec                  sender > > [  4] 0.00-10.00  sec  1.08 GBytes   931 > Mbits/sec                  receiver > > Regarding CPU utilization, using htop, with both NO offloading and SW > offloading, it is evident that the CPU is being used reaching close to > 100% of one of the cores, a bit less in the others, while HW > offloading CPU remains with the 1-2% utilization. > > By the way the devices are cheap ones, different vendors, no > difference if I do the test with one or the other (tested with 3 > different ones and got same results). The most expensive one is > probably around 30 USD (ZBT-WG3526-16M). > > I've used the stable builds and then upgraded everything to the latest > versions. > > https://downloads.openwrt.org/releases/18.06.1/targets/ramips/mt7621/ > > If you're interested and coming to BKK, I can bring one of them and we > can play a bit. > > Regards, > > Jordi > > -----Mensaje original----- > > De: Mikael Abrahamsson > > > Organización: People's Front Against WWW > > Fecha: jueves, 18 de octubre de 2018, 19:45 > > Para: JORDI PALET MARTINEZ > > > CC: > > > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our > working group > >     On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: > >     > Yes, 100% sure in this case. > >     > > >     > The SoC supports it with several SDKs/OSs: > >     > > >     > https://www.mediatek.com/products/homeNetworking/mt7621n-a > >     > > >     > You can enable HW or SW offloading, offers both options (didn't > checked > >     > what is the difference, I just go for the HW if it works, as I > guess > >     > outperforms the SW one). > >     I know the MT7621 does what you're saying in other OSes with their > SDK, > >     I'm questioning if the -j FLOWOFFLOAD is the way to do HW > acceleration for > >     certain flows. Did you try to run full gig speed through it and > check CPU > >     usage? It's the easiest way to tell if the offload works or not. > >     It would be the least intrusive offload implementation I've ever > seen in > >     Linux, so if it actually works this way I'd be very happy, and > hope more > >     vendors does it the same way. > >     Did you buy some retail device? If you did, what was it? > >     -- > >     Mikael Abrahamsson    email: swmike@swm.pp.se > > > ********************************************** > > 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 confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > _______________________________________________ > > 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 confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------7A96A9FFD72BB9219E3B963F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

10/23/2018 7:31 PM keltezéssel, JORDI PALET MARTINEZ írta:

Hi Rajiv,

 

In the scope of draft-lmhp-v6ops-transition-comparison, we are planning some measurements, but I’m not sure when and how we will be able to do them.

 

Also, if we really want to have those being realistic, we should plan different testing combinations, and also differentiate the performance of the CE part vs the “network†part and the combination of both.

 

Last but not least, we can easily do with opensource, for example OpenWRT or VPP in for the CPE and Jool or VPP for the NAT64/BR on the other side, or combinations of them, but trying to make it with hardware from vendors, unless they want to provide it, will be difficult.

 

I’m happy to invest time in that, but we need to correctly plan all the details to be fair with the measurements.

 

It may be a topic also for a hackathon, but I’m not sure there is sufficient time in a weekend for all the testing …


As for benchmarking, iperf or RFC 2544 (RFC 5180) compliant testers may only be used when the devices are used in pairs. RFC 8219 call this as "Dual DUT" setup.
Testing according to the "Single DUT" setup would require special Testers. (E.g. for testing a NAT64 gateway: the Tester needs to be able to send IPv6 packets to the DUT and receive IPv4 traffic from the DUT in one direction, while it needs to send IPv4 packets to the DUT and receive IPv6 packets from the DUT in the other direction at the same time, as bidirectional traffic is required.) As far as I know, no special Testers available yet. (One of my PhD students working on a DPDK based stateless NAT64 tester, but it is far from usable.)

I think implementing RFC 8219 compliant special Testers for the five IPv4aaS technologies mentioned in draft-lmhp-v6ops-transition-comparison, would be an interesting task for hackathon!

I definitely recommend using DPDK to achieve the required performance. (Perhaps TRex https://trex-tgn.cisco.com/ may help in implementing the Testers, but later it may be more complicated to use them. )

 Best regards,

Gábor Lencse


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Fecha: martes, 23 de octubre de 2018, 19:20
Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working group

 

Jordi,

 

This is quite useful. Do you also happen to have similar test numbers with CLAT functionality vs. MAP(-T/E) CE functionality? That would really help, and OpenWRT supports them.

 

It would be pertinent to have consistent traffic amount and no of connections/flows in each case.

 

Say, 60% IPv6 and 40% IPv4 traffic (by bps) as well as connections.

 

Has anybody got any recent measurement about no of connections per HGW? Mine is dated in 2012-2013.

 

Cheers,

Rajiv

 

 

From: v6ops <v6ops-bounces@ietf.org> on behalf of JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Date: Friday, October 19, 2018 at 4:04 PM
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group

 

Hi Mikael,

 

Sorry, was coming back from the RIPE and arranging a small test to show you the results, which are consistent with what I recall from my previous testing.

 

I'm using an ubuntu VM as the server, running in ESXi 6.5, and as client my own laptop.

 

There is a Cisco switch between the server, the MT7621 device and my client.

 

Ubuntu VM in ESXi --- Cisco Gig switch --- MT7621 under test --- client device

 

Server command: iperf3 -s

 

1) LAN-to-LAN test (so both the server and client are connected to the LANs of the MT7621)

iperf3 -c 10.10.10.3

Connecting to host 10.10.10.3, port 5201

[  4] local 10.10.10.99 port 51300 connected to 10.10.10.3 port 5201

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-1.00   sec   113 MBytes   951 Mbits/sec                  

[  4]   1.00-2.00   sec   112 MBytes   937 Mbits/sec                  

[  4]   2.00-3.00   sec   112 MBytes   938 Mbits/sec                  

[  4]   3.00-4.00   sec   112 MBytes   937 Mbits/sec                  

[  4]   4.00-5.00   sec   112 MBytes   936 Mbits/sec                  

[  4]   5.00-6.00   sec   112 MBytes   937 Mbits/sec                  

[  4]   6.00-7.00   sec   112 MBytes   937 Mbits/sec                  

[  4]   7.00-8.00   sec   112 MBytes   937 Mbits/sec                  

[  4]   8.00-9.00   sec   112 MBytes   937 Mbits/sec                  

[  4]   9.00-10.00  sec   112 MBytes   936 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec                  sender

[  4]   0.00-10.00  sec  1.09 GBytes   937 Mbits/sec                  receiver

 

2) LAN-to-WAN NAT test without offloading

iperf3 -c 10.10.10.3

Connecting to host 10.10.10.3, port 5201

[  4] local 192.168.1.139 port 51447 connected to 10.10.10.3 port 5201

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-1.00   sec  48.8 MBytes   409 Mbits/sec                  

[  4]   1..00-2.00   sec  45.8 MBytes   384 Mbits/sec                  

[  4]   2.00-3.00   sec  45.2 MBytes   379 Mbits/sec                  

[  4]   3.00-4.00   sec  45.2 MBytes   379 Mbits/sec                  

[  4]   4.00-5.00   sec  45.0 MBytes   378 Mbits/sec                  

[  4]   5.00-6.00   sec  44.9 MBytes   377 Mbits/sec                  

[  4]   6.00-7.00   sec  45.2 MBytes   379 Mbits/sec                  

[  4]   7.00-8.00   sec  45.1 MBytes   378 Mbits/sec                  

[  4]   8.00-9.00   sec  45.3 MBytes   380 Mbits/sec                  

[  4]   9.00-10.00  sec  45.2 MBytes   379 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-10.00  sec   456 MBytes   382 Mbits/sec                  sender

[  4]   0.00-10.00  sec   456 MBytes   382 Mbits/sec                  receiver

 

3) LAN-to-WAN NAT test with SOFTWARE offloading

iperf3 -c 10.10.10.3

Connecting to host 10.10.10.3, port 5201

[  4] local 192.168.1.139 port 51484 connected to 10.10.10.3 port 5201

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-1.00   sec  98.4 MBytes   826 Mbits/sec                  

[  4]   1.00-2.00   sec  98.2 MBytes   824 Mbits/sec                  

[  4]   2.00-3.00   sec  96.9 MBytes   813 Mbits/sec                  

[  4]   3.00-4.00   sec  97.6 MBytes   819 Mbits/sec                  

[  4]   4.00-5.00   sec  98.2 MBytes   824 Mbits/sec                  

[  4]   5.00-6.00   sec  96.5 MBytes   809 Mbits/sec                  

[  4]   6.00-7.00   sec  96.0 MBytes   805 Mbits/sec                  

[  4]   7.00-8.00   sec  96.1 MBytes   806 Mbits/sec                  

[  4]   8.00-9.00   sec  97.8 MBytes   820 Mbits/sec                  

[  4]   9.00-10.00  sec  97.5 MBytes   818 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-10.00  sec   973 MBytes   816 Mbits/sec                  sender

[  4]   0.00-10.00  sec   971 MBytes   815 Mbits/sec                  receiver

 

4) LAN-to-WAN NAT test with HARDWARE offloading

iperf3 -c 10.10.10.3

Connecting to host 10.10.10.3, port 5201

[  4] local 192.168.1.139 port 51523 connected to 10.10.10.3 port 5201

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-1.00   sec   110 MBytes   926 Mbits/sec                  

[  4]   1.00-2.00   sec   112 MBytes   938 Mbits/sec                  

[  4]   2.00-3.00   sec   111 MBytes   933 Mbits/sec                  

[  4]   3.00-4.00   sec   111 MBytes   935 Mbits/sec                  

[  4]   4.00-5.00   sec   111 MBytes   933 Mbits/sec                  

[  4]   5.00-6.00   sec   111 MBytes   933 Mbits/sec                  

[  4]   6.00-7.00   sec   111 MBytes   933 Mbits/sec                  

[  4]   7.00-8.00   sec   110 MBytes   923 Mbits/sec                  

[  4]   8.00-9.00   sec   111 MBytes   934 Mbits/sec                  

[  4]   9.00-10.00  sec   111 MBytes   933 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-10.00  sec  1.09 GBytes   932 Mbits/sec                  sender

[  4]   0.00-10.00  sec  1.08 GBytes   931 Mbits/sec                  receiver

 

Regarding CPU utilization, using htop, with both NO offloading and SW offloading, it is evident that the CPU is being used reaching close to 100% of one of the cores, a bit less in the others, while HW offloading CPU remains with the 1-2% utilization.

 

By the way the devices are cheap ones, different vendors, no difference if I do the test with one or the other (tested with 3 different ones and got same results). The most expensive one is probably around 30 USD (ZBT-WG3526-16M).

 

I've used the stable builds and then upgraded everything to the latest versions.

 

 

If you're interested and coming to BKK, I can bring one of them and we can play a bit.

 

Regards,

Jordi

 

-----Mensaje original-----

De: Mikael Abrahamsson <swmike@swm.pp.se>

Organización: People's Front Against WWW

Fecha: jueves, 18 de octubre de 2018, 19:45

Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>

Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working group

 

    On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote:

    

    > Yes, 100% sure in this case.

    >

    > The SoC supports it with several SDKs/OSs:

    >

    >

    > You can enable HW or SW offloading, offers both options (didn't checked

    > what is the difference, I just go for the HW if it works, as I guess

    > outperforms the SW one).

    

    I know the MT7621 does what you're saying in other OSes with their SDK,

    I'm questioning if the -j FLOWOFFLOAD is the way to do HW acceleration for

    certain flows. Did you try to run full gig speed through it and check CPU

    usage? It's the easiest way to tell if the offload works or not.

    

    It would be the least intrusive offload implementation I've ever seen in

    Linux, so if it actually works this way I'd be very happy, and hope more

    vendors does it the same way.

    

    Did you buy some retail device? If you did, what was it?

    

    --

    Mikael Abrahamsson    email: swmike@swm.pp.se

    

 

 

 

**********************************************

IPv4 is over

Are you ready for the new Internet ?

The IPv6 Company

 

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

 

 

 

_______________________________________________

v6ops mailing list

 

_______________________________________________ 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 confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------7A96A9FFD72BB9219E3B963F-- From nobody Tue Oct 23 12:46:07 2018 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 AC419129BBF for ; Tue, 23 Oct 2018 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BDfyMfSI1NM for ; Tue, 23 Oct 2018 12:46:04 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26B9130E5C for ; Tue, 23 Oct 2018 12:46:00 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9NJcWk8008734; Tue, 23 Oct 2018 12:45:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=N8AjbGLFad5kAZJLHemUI1qFtr5dc28VlpIXAmLUMZo=; b=Nco6ye/lLw15u6nZeQFhPEr42LNu50JlD4rI61AKeVQa8uzK6ngAWo4viUPnUVkv+bX9 EBDQjcaSkxI/caoTiaDs2s4JeUnI4eFe2ul6iaISeYDDclFFSN3sOv3ZuawN7B1X1P+M 6XZ02WI+iEApwHcmuBUiP17s69lK3ihY3qiDOjZfb3EKyDl4Q1fwmssmVZ3fjHayoT9L F0M94xleMdftvin8Y/xPyyHqGBIXRpdP4k10GEwaCNIDWF4a1CxuejU2U8FRlcn2GK6s PgOLSCSX9Gl+u6DPPWVmIJE2qSAfxZ5ehnFpt8JUYiC+mMXWUFV6cwpz+5BYNpXFHBJB Wg== Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp0242.outbound.protection.outlook.com [216.32.181.242]) by mx0a-00273201.pphosted.com with ESMTP id 2na0031905-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 12:45:59 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4455.namprd05.prod.outlook.com (52.135.203.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.10; Tue, 23 Oct 2018 19:45:57 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::2524:9c8a:2dd3:7772%5]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 19:45:57 +0000 From: Ron Bonica To: Fred Baker , "v6ops@ietf.org list" Thread-Topic: Proposed agenda for IETF 103 Thread-Index: AQHUapQrk6HZzJ2T5Uam8m8I2j6WuKUtPNLg Date: Tue, 23 Oct 2018 19:45:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.58 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4455; 6:0H6KDPj3pH9jxslK2mx6Nu1fN2IpHQVAgaGpKIOjp/Y5Ro3hAF4Zyrll9gBqqpwRgIsVZbv70z6wltt3RT06uc+oXMhY2DtgTk3THjAA0/t8AM81snYFgK3Hw7XfoLhsEv/3clJxFJ5JyJghC7UCWpoVEvjwnddaHj62YmdZ0kyOksX3MIcowcSPDu7lnIYq8y/u/AhqwERyi2cLiq1K90RLKjm8qKojBYqyB+XGCa8VVwbFG+o19w+lpSfF3A0Y2RrLnhjFK7TZQGgmc9MGbk2UTutd6DfWCFEPe3heWOx8d785nPo5lPGUQaEj0RBep99QkaUvzN/0kuNyJQ3lPF7P1U9FIlWg7ykot4RUyrwWujiUqen//7sC8dQkWk3SmDCqWsMuwgXqHFt4qZ0Hx/Ktt1IGJSfTSMty40f9VYdQlk4RHrpPpkB3qvA3S8i4CDnL0/IxCAlTEr12rO36sA==; 5:R+zBnE46E+R+POler3DlUTcVtQHC8dM9d2aThKyuwAQMZ3wsl23NXXD6AYo92futs+8uJKB9ivY922LxUCKBipsCR6w/QGr65H4p9ZU95feMkHY+qEOVAwl7AL0JZhtlz/bQTi46m31qK4CVy3qqluhv5ADrpQPixBAOn6M+2mU=; 7:VCX14jNmAHKkkE7ZlXHaBBnlzFZYkVMgbjj5rv9OfwTXWupgD8/VA8MNWLPe4QThiXOtZEwZLX5OqsmBHnxAYb4cOYH5pYQwA2tEYXqA9YUE3y1OueSjrJtdTeL/kBl0sVHSYByOVd/y31kwvv3cFw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3d56acda-bd51-4ef1-c580-08d639202718 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4455; x-ms-traffictypediagnostic: BYAPR05MB4455: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(85827821059158)(138986009662008); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB4455; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4455; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(366004)(376002)(346002)(13464003)(189003)(199004)(6246003)(14454004)(316002)(2900100001)(97736004)(105586002)(102836004)(68736007)(33656002)(2906002)(9686003)(86362001)(110136005)(6436002)(6116002)(74316002)(3846002)(7736002)(55016002)(25786009)(446003)(476003)(71190400001)(71200400001)(11346002)(39060400002)(26005)(186003)(8676002)(81156014)(4326008)(81166006)(6306002)(486006)(53936002)(229853002)(305945005)(5024004)(5250100002)(66066001)(106356001)(53546011)(256004)(478600001)(6506007)(8936002)(7696005)(5660300001)(76176011)(966005)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4455; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: XKLNYrqabdMfquRBMOup3I+ceLChbL1zotov/rFkmOHgYjgOIRnjcdnHgN1Rv0YQ7mXfXcOb1ia9aI31/PnYl7obnj/tkW8Wv2fpvRgIu7zm71f7VYfo5uZ21VijM8n3fhXOympSo1WWQ1iy5X2GO1xk0VYRACwUcKsQpKd9muVlMEtnPFviLjfU3INEPaFuw59k7dN67AKx3+2xnHVy5DR5PDC4mqYqnxXuL4lEAWs/mvFj4ipavnMg08khcsBtmQmAdwJN0M6enCOKZJJ2pnGsQlzWeuLEHM4Oud1EyZaD9sZNOp9E3B/f3LFevRLEqqzfrUm8QB4c+c9K0z1/m4M/2bmsijBgwyYST0ZRkr0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3d56acda-bd51-4ef1-c580-08d639202718 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 19:45:57.6114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4455 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230160 Archived-At: Subject: Re: [v6ops] Proposed agenda for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 19:46:06 -0000 Looks good to me > -----Original Message----- > From: Fred Baker > Sent: Tuesday, October 23, 2018 1:47 AM > To: v6ops@ietf.org list > Cc: Warren Kumari ; Ron Bonica > > Subject: Proposed agenda for IETF 103 >=20 > Ron and I are proposing this as the agenda this time around: > https://datatracker.ietf.org/meeting/103/materials/agenda-103-v6ops-02 >=20 > If there is time at the end of the meeting and people want to do what amo= unts > to a lightning talk, we can open the floor for that. However, with a sing= le two- > hour slot, I expect it will be a busy meeting. >=20 > In case it's useful to you, I have included some additional links in the = attached > file - data tracker, html draft, discussion thread, and rfcdiff against t= he > previous version if any. From nobody Tue Oct 23 23:18:35 2018 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 7EB6F130DDA; Tue, 23 Oct 2018 20:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKvEh6hkz6jC; Tue, 23 Oct 2018 20:13:19 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670107.outbound.protection.outlook.com [40.107.67.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9971D130DD8; Tue, 23 Oct 2018 20:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7CLAtRD9slOJjLEP7rdnIZtCLodbbiMUbyR2yL/YcyM=; b=j3iJYUcnhdpCNIkWMQBFbEAk4xEb4eP8opGLvathF+ZK55hyiOXcRFZLhXNyOlLm1omyPsWCpYFHzpdHmt0oezRMYP0kFjDUYdnEMpBGWzerJDbqIRw1uWHsHMBC3W6DcowlSeGnogykYAu2UY0T95TE3IaZtk/2ood9nNCvhLA= Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM (10.169.141.148) by YQBPR01MB0611.CANPRD01.PROD.OUTLOOK.COM (10.169.144.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Wed, 24 Oct 2018 03:13:17 +0000 Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9af:2ac3:bd40:e2ea]) by YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9af:2ac3:bd40:e2ea%4]) with mapi id 15.20.1273.014; Wed, 24 Oct 2018 03:13:17 +0000 From: Suresh Krishnan To: Lorenzo Colitti CC: "Pascal Thubert (pthubert)" , Lorenzo Colitti , Bernard Aboba , "v6ops@ietf.org WG" , int-area , IETF IPv6 Mailing List , "opsec@ietf.org" , dhcwg , "opsawg@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 Thread-Index: AQHUZzM4x98Ypd1MCEKu+GX87R2CxqUlsN0AgAD1IYCABXvvgIAAGvIAgAGDvQA= Date: Wed, 24 Oct 2018 03:13:17 +0000 Message-ID: <02B5B763-C10C-4EC9-BD9D-96B6A3F11A33@kaloom.com> References: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> <3BB81D98-E70D-45B4-A99D-94AF29D89526@kaloom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR01MB0611; 6:p9pzs2IYJS8yYKRx8obIylSvu9QbjB09bIwjwimorAleMrXQS1LbyTZEt63KDWSe76op+Dw7FqOCarz4hWM3ODCIZOIW7V58AXLJ8dsFm8rN/CPonfteELE49kvg1a2C75nVWu/xyfyOs+/f+t5jb8dnYiCwFYtsgJqgKtHOaHAmKhsLmQmP7+3bNyvacIXWtcRnkUvZTwVnZGg6+94YbjtYzTu2FpXCvioerfIq6RfgciRI1D998pPs3x1SjvnrnNS0OSoI+WZHCtTvh168k4xGBAp2RtpmO8rG/wKUOEuhM0qzkEE6Y8jb1eTrMXbOgXg+P69AjCGKADGXuxnoFOrjkNHPJ1jy2gb06/iKxstJryZPE5cZawiqnhO+6jXBCJz/i0xMeAxW+qKvxdHAxVrI0ZMQYywFSbveWSj38LE5zE3MxJpw7RfWlkGP3uj8j3UqzBtD0uZ99ZLbN4ogoA==; 5:rKq7OVfv2pF8fC58ZzpGPgFyDyVCTG99M8Q5pYQ9OcIZUruVex79eaLrtgsyW+Tt3hxvZ8ApiSZ0u62ejm7rKl420kGRxf4/Jfglr7am/3obNPclNeTFcrGkkA4nZJjg+cs9osINpaUdDD6ir+ursZr5e/CTO1QOop307RK9i+E=; 7:NOdL2pqYtvQcWu57h1X2Wgwer5/bZgWXjHNaq/vhMlolH/dvrmgRVXM2jbIbIsV7k9Dne8EIKb7+Kelc85kcWXpQTC/YJGNl/LR/1C6yZ6f5aJFDkpkSisde2/a19FyowYX5VPGDnmmJxWkwwGlBnxG1Z1pALJuMyLMYUgWhDBvzhDUGQpptR5KWO88yxg7eFbOLFsK/UEADtgBNxVPZHOScxZwWhmIDfqATWJgIv2Ad/rsKAEs6DGTwhSDijNmb x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ca9c6d2a-b71b-4b98-ce95-08d6395ea4b6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YQBPR01MB0611; x-ms-traffictypediagnostic: YQBPR01MB0611: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(2016111802025)(20161123560045)(20161123562045)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:YQBPR01MB0611; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0611; x-forefront-prvs: 083526BF8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(396003)(39840400004)(366004)(189003)(199004)(81166006)(81156014)(82746002)(3846002)(83716004)(71190400001)(71200400001)(6916009)(8676002)(508600001)(256004)(6116002)(53936002)(25786009)(8936002)(54906003)(11346002)(93886005)(53546011)(6436002)(66066001)(36756003)(6506007)(76176011)(33656002)(186003)(316002)(6246003)(39060400002)(446003)(26005)(97736004)(229853002)(5660300001)(6486002)(486006)(7416002)(2900100001)(68736007)(4326008)(102836004)(106356001)(86362001)(99286004)(105586002)(6512007)(72206003)(80792005)(2616005)(14454004)(7736002)(476003)(2906002)(5250100002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:YQBPR01MB0611; H:YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: r3aaCA2cFo3Eqyy00ioMP+LuWKeMmoh3V8LVxVzZAwYIbZV9VJjlIV2YfSBQNUDHmNipQdu4UJlLGSHPHVRmq7ZcwPyemLH+7uywPty63D4qjOnlwmDbF1IA2Ixbv5YIZAdDu0piOuq8VBIwxTurTNwBBh/MTkKZe7y4sF2KOGlO0xFR9aY/GYNkDG1kHADJbcN7Gai/l++M8k1lDJxb9lBoWIUfJmkqjzEeR848ZgF+gTyv/WxYJKDEQNoLJ95yg+cDery4S2im130zfCn5zSIZ3kXjhIeTNjk7d5eaOTP64upj751Q9Y8HPkzqe7YDooTZ5ThuqhMeDY1W4ZUFAZ/GgxmXG/la1mdjd5NiJrQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca9c6d2a-b71b-4b98-ce95-08d6395ea4b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 03:13:17.1095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0611 Archived-At: X-Mailman-Approved-At: Tue, 23 Oct 2018 23:18:34 -0700 Subject: Re: [v6ops] [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 03:13:22 -0000 Hi Lorenzo, > On Oct 23, 2018, at 12:05 AM, Lorenzo Colitti wrote: >=20 > Isn't v6ops a natural fit for this, since it essentially documents an ope= rational practice that is implemented by real hardware? I did think of it, but the draft is also expected to work with IPv4 and tha= t made me reconsider (In fact one of my solicited reviews for the previous = version of this draft was from Fred Baker). Fred/Ron, do you think this dra= ft can fit in v6ops? If so, I will send the authors your way. Thanks Suresh From nobody Wed Oct 24 05:22:09 2018 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 9A232130E39 for ; Wed, 24 Oct 2018 05:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka7W8mz8ED4a for ; Wed, 24 Oct 2018 05:21:59 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45E6130DFE for ; Wed, 24 Oct 2018 05:21:57 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id q7-v6so5352035wrr.8 for ; Wed, 24 Oct 2018 05:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TFxOQdP8HObwLuwQOhaG4DaYMUK06UarLvyZwRSp9YY=; b=Uwg3kcluKwbwZo1cIGO292pJxR0qlBwEwA94yPz6cy0WzRyEqptOo8qMFV0sw6oSlE citr9nF2XQ0MQJjanhYWxh/nG/A2kaLCs5n0AZViFS/lNYXP+6hggbILyRrsHOqbXcMN ErMrR7td/F5Brl2wn5xLW2ZMDtYo63C3ZOup4COcnJndG3/JpBv11/yIcMb747jJIbRx bJbhOeg7U9vjUVhJoal0Q1qC6PyceoUDnI1CRpLHspYVJN+DAujJi0rvaW42vAdOAqYf 4y4yf6zQSNE1kK53F49uGj/vG7zCAOwIrCG3NE5YzAVjoV5/hK2F5RXg5BvFzTlIJQYF oS6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TFxOQdP8HObwLuwQOhaG4DaYMUK06UarLvyZwRSp9YY=; b=BnFV8ZRyQRYrZWwEi72lv0oKMVAgFoLdYYUoqtLpeN5jZYL6bcI/dT6HHQ1xdpbhtJ XsQij3G9KsOv2aso2RHjRjTY9v6UqS18fwIwOzf4FqAvqVmV8xyMihenFBpLuLrAfIXV qKLcbfOkAONm+Ecor7tZ+5KXzO2CuNQ8yyF/uqWk5fzK/N31I/zhbsLfwn0UdixjUIFx Lv485L+BSNqTSpdDsfYEWQ9WyqcAM49vkQgw9xCY7fRu1kpoS2CuqH3wAG2uO4S9+8IX hv9IVR/dAVznvXNQEm8KhkKO+qKWkBZozdFWi/Jql/kXOxv684B/wkQVymvDVqUhm5ws jxeg== X-Gm-Message-State: AGRZ1gL6oh2PufoZv3UzOkIOG97uyMKzltMB6bc1braGlhRrZwH6tJDw aCRTDyGSmVRnwoGo1FaDvexXYARm0vI= X-Google-Smtp-Source: AJdET5dedCYbjERpKzHyZWUcU5BIQO3caGQZgHfojOht1iLxZVY5qe9JTtvj1hJ3Iwjok0P+DoVirA== X-Received: by 2002:a5d:44ce:: with SMTP id z14-v6mr2798002wrr.286.1540383716244; Wed, 24 Oct 2018 05:21:56 -0700 (PDT) Received: from [192.168.50.230] ([213.27.245.162]) by smtp.gmail.com with ESMTPSA id a18sm2637572wrx.55.2018.10.24.05.21.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 05:21:55 -0700 (PDT) From: Fred Baker Message-Id: <41F5AF22-E69E-471E-B5F4-B7F4E0AA3B15@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_70EA8245-71A2-41F7-8AEB-CBD7EB384CFA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 24 Oct 2018 14:21:53 +0200 In-Reply-To: Cc: JORDI PALET MARTINEZ , Mikael Abrahamsson , "v6ops@ietf.org" To: "Rajiv Asati (rajiva)" References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 12:22:08 -0000 --Apple-Mail=_70EA8245-71A2-41F7-8AEB-CBD7EB384CFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don't have measurements, but I have a comment on the design of the = CLAT protocol operation (RFC 7915). It maintains no tables; it simply = appends the IPv4 source and destination addresses to relevant /96 = prefixes and writes an IPv6 header, and does the reverse on packet = receipt. The PLAT, which is not very different from NAPT44 except using = IPv6 as the source, is far more complex by nature. Since it keeps no = session state and does nothing session-related, I would be surprised to = find session-count an issue in a CLAT. > On Oct 23, 2018, at 7:18 PM, Rajiv Asati (rajiva) = wrote: >=20 > Jordi, >=20 > This is quite useful. Do you also happen to have similar test numbers = with CLAT functionality vs. MAP(-T/E) CE functionality? That would = really help, and OpenWRT supports them. >=20 > It would be pertinent to have consistent traffic amount and no of = connections/flows in each case. >=20 > Say, 60% IPv6 and 40% IPv4 traffic (by bps) as well as connections. >=20 > Has anybody got any recent measurement about no of connections per = HGW? Mine is dated in 2012-2013. >=20 > Cheers, > Rajiv >=20 >=20 > From: v6ops on behalf of JORDI PALET MARTINEZ = > Date: Friday, October 19, 2018 at 4:04 PM > To: Mikael Abrahamsson > Cc: "v6ops@ietf.org" > Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >=20 > Hi Mikael, >=20 > Sorry, was coming back from the RIPE and arranging a small test to = show you the results, which are consistent with what I recall from my = previous testing. >=20 > I'm using an ubuntu VM as the server, running in ESXi 6.5, and as = client my own laptop. >=20 > There is a Cisco switch between the server, the MT7621 device and my = client. >=20 > Ubuntu VM in ESXi --- Cisco Gig switch --- MT7621 under test --- = client device >=20 > Server command: iperf3 -s >=20 > 1) LAN-to-LAN test (so both the server and client are connected to the = LANs of the MT7621) > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 10.10.10.99 port 51300 connected to 10.10.10.3 port 5201 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 113 MBytes 951 Mbits/sec > [ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec > [ 4] 2.00-3.00 sec 112 MBytes 938 Mbits/sec > [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec > [ 4] 4.00-5.00 sec 112 MBytes 936 Mbits/sec > [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec > [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec > [ 4] 7.00-8.00 sec 112 MBytes 937 Mbits/sec > [ 4] 8.00-9.00 sec 112 MBytes 937 Mbits/sec > [ 4] 9.00-10.00 sec 112 MBytes 936 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec = sender > [ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec = receiver >=20 > 2) LAN-to-WAN NAT test without offloading > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 192.168.1.139 port 51447 connected to 10.10.10.3 port 5201 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 48.8 MBytes 409 Mbits/sec > [ 4] 1.00-2.00 sec 45.8 MBytes 384 Mbits/sec > [ 4] 2.00-3.00 sec 45.2 MBytes 379 Mbits/sec > [ 4] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec > [ 4] 4.00-5.00 sec 45.0 MBytes 378 Mbits/sec > [ 4] 5.00-6.00 sec 44.9 MBytes 377 Mbits/sec > [ 4] 6.00-7.00 sec 45.2 MBytes 379 Mbits/sec > [ 4] 7.00-8.00 sec 45.1 MBytes 378 Mbits/sec > [ 4] 8.00-9.00 sec 45.3 MBytes 380 Mbits/sec > [ 4] 9.00-10.00 sec 45.2 MBytes 379 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec = sender > [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec = receiver >=20 > 3) LAN-to-WAN NAT test with SOFTWARE offloading > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 192.168.1.139 port 51484 connected to 10.10.10.3 port 5201 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 98.4 MBytes 826 Mbits/sec > [ 4] 1.00-2.00 sec 98.2 MBytes 824 Mbits/sec > [ 4] 2.00-3.00 sec 96.9 MBytes 813 Mbits/sec > [ 4] 3.00-4.00 sec 97.6 MBytes 819 Mbits/sec > [ 4] 4.00-5.00 sec 98.2 MBytes 824 Mbits/sec > [ 4] 5.00-6.00 sec 96.5 MBytes 809 Mbits/sec > [ 4] 6.00-7.00 sec 96.0 MBytes 805 Mbits/sec > [ 4] 7.00-8.00 sec 96.1 MBytes 806 Mbits/sec > [ 4] 8.00-9.00 sec 97.8 MBytes 820 Mbits/sec > [ 4] 9.00-10.00 sec 97.5 MBytes 818 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 973 MBytes 816 Mbits/sec = sender > [ 4] 0.00-10.00 sec 971 MBytes 815 Mbits/sec = receiver >=20 > 4) LAN-to-WAN NAT test with HARDWARE offloading > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 192.168.1.139 port 51523 connected to 10.10.10.3 port 5201 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 110 MBytes 926 Mbits/sec > [ 4] 1.00-2.00 sec 112 MBytes 938 Mbits/sec > [ 4] 2.00-3.00 sec 111 MBytes 933 Mbits/sec > [ 4] 3.00-4.00 sec 111 MBytes 935 Mbits/sec > [ 4] 4.00-5.00 sec 111 MBytes 933 Mbits/sec > [ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec > [ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec > [ 4] 7.00-8.00 sec 110 MBytes 923 Mbits/sec > [ 4] 8.00-9.00 sec 111 MBytes 934 Mbits/sec > [ 4] 9.00-10.00 sec 111 MBytes 933 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 1.09 GBytes 932 Mbits/sec = sender > [ 4] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec = receiver >=20 > Regarding CPU utilization, using htop, with both NO offloading and SW = offloading, it is evident that the CPU is being used reaching close to = 100% of one of the cores, a bit less in the others, while HW offloading = CPU remains with the 1-2% utilization. >=20 > By the way the devices are cheap ones, different vendors, no = difference if I do the test with one or the other (tested with 3 = different ones and got same results). The most expensive one is probably = around 30 USD (ZBT-WG3526-16M). >=20 > I've used the stable builds and then upgraded everything to the latest = versions. >=20 > https://downloads.openwrt.org/releases/18.06.1/targets/ramips/mt7621/ >=20 > If you're interested and coming to BKK, I can bring one of them and we = can play a bit. >=20 > Regards, > Jordi >=20 > -----Mensaje original----- > De: Mikael Abrahamsson > Organizaci=C3=B3n: People's Front Against WWW > Fecha: jueves, 18 de octubre de 2018, 19:45 > Para: JORDI PALET MARTINEZ > CC: > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our = working group >=20 > On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: >=20 > > Yes, 100% sure in this case. > > > > The SoC supports it with several SDKs/OSs: > > > > https://www.mediatek.com/products/homeNetworking/mt7621n-a > > > > You can enable HW or SW offloading, offers both options (didn't = checked > > what is the difference, I just go for the HW if it works, as I = guess > > outperforms the SW one). >=20 > I know the MT7621 does what you're saying in other OSes with their = SDK, > I'm questioning if the -j FLOWOFFLOAD is the way to do HW = acceleration for > certain flows. Did you try to run full gig speed through it and = check CPU > usage? It's the easiest way to tell if the offload works or not. >=20 > It would be the least intrusive offload implementation I've ever = seen in > Linux, so if it actually works this way I'd be very happy, and = hope more > vendors does it the same way. >=20 > Did you buy some retail device? If you did, what was it? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 > _______________________________________________ > 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 = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_70EA8245-71A2-41F7-8AEB-CBD7EB384CFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvQY+EACgkQEhdRnd2G P+C4sA/9G+iNzzQxYlAe4kNqGL9+T85KTog8GvPWdq1cKaGmYFsTyoCeW/4rldLd 17fWX0rGZp8FFyxMJw/zLwRKDZfsESpN+cuP3HWMneCr/dinvz5Hj2R3+Z742whl SWlJ2Qen4zHvnwwNv+MNCsDFsICxsbJ4SlUUQG+R8T2PriCPdRVaR330tzAMyaTc aeOfn9gZcP0iP3/bNWYEdIbeuAnqenCVjW/UaOif5VrjF/oq4FsG9R3raqIZPxCO EQrJ0/YbCG00WI/jH7bppReojkjcteH79nm7K5ELQDf/N5/6wqh6nR9Qhks94yjP af/yBaGDqoQ52LJ2EVqH6iZ4uDnLLZNaBtjIu3QuF9YsTyQkB1puMZyBLJaqoeiJ S2g5bnefmImYA8kddLsbsZisJRzU125OJUqwrNV8Qzihu0/1r3/FnGou1q/2UFe9 4xpf0tAsttu7ojfLc0GVnX6l00pQlrURhp3fvm2n5772JiQMqZ1wBfHyDhiqZL7h 7OIB4yAP9EKB2K6iAIeEz3qZvHBQfm3i/M43Z/9e1hhvVIj31JrzmEI92jsdwa0o piXpfvpQ362/cMU6RD+W2ZNL3UwS1O7u48YVgBEXjsFzkfP+T6Jx7RgfSuhLT2kj 68RMfyYEyS1Moo/Jcva4xAFJR7uC2EvSoaE/8jHfZoH/LsKA+6s= =nyax -----END PGP SIGNATURE----- --Apple-Mail=_70EA8245-71A2-41F7-8AEB-CBD7EB384CFA-- From nobody Wed Oct 24 05:26:43 2018 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 A2EE0126DBF; Wed, 24 Oct 2018 05:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbeMjxuHmbDu; Wed, 24 Oct 2018 05:25:16 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95D4130DFE; Wed, 24 Oct 2018 05:25:13 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id a8-v6so5183831wmf.1; Wed, 24 Oct 2018 05:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=crAFyU+3MmdYegFOnVnp21K02fLD2BHm5N6NH4Xn9KY=; b=eLPxMTkx+pC8LOUFzXwiTGtHCmBX425v217t/5gmpLNCf6eGuCrLKcjg6+WC6yJK0v LNgnF9CETQa3LbWfZ/ZI48EEPXAatJgTZv4oLTfb3bs+EXifBmtWxw2e2kI7ik4erU9e tLnyY38JASdKBACWhybWK+47j+Aoo1m+OfXv3swkiOBGp1OmopgKZeHIYc+9bdWLIuWv wT+JcUldEz66ciEmeOc+DzIRVhHEVrOUP4wfKcPxI6muQXtx1hioVC1Rm1NIaD7WW/wX x1xL9AgItHKeViv/ERSvsmT9NnaBp5gYkiF2iLx9gxhgQ40IdWBfbSIsjf8mY/iNIibl FxLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=crAFyU+3MmdYegFOnVnp21K02fLD2BHm5N6NH4Xn9KY=; b=rHRCjWrUYanL9eHrgh6nnA5DJu2X36RVq5cEKLYWRGhLM4R2uPQLcOSnlr3Nc3QzBh 2KSoB7WLvpAx+yOSx+Jvo9a8LOMTBkrz2WSwLMDZYiPYMWgxF50SnJQdYmmUbgnRnhrd yUOk4JmkGQSIb03/JMyfOTmGAOvfOkMYQmjswkdVpNEBAwJSs2pMYzHxfd6cP5VP7zzp EQjcsdOZxrGckzC59M5W1w2kXi9ZZRz3WVgGmvskxkcA4l+55qkipwwdQbvtR4b/m+ag BfnIEY3Zv+lQOdiNl+93+ZjAqiY182drmFH9DHNAQLVtzNzp8ZPpq1tH7pQwGkE8xa8l 0aGw== X-Gm-Message-State: AGRZ1gIDtL6YyQ45nFxWrdpFcUUQq2EKvXjZI/9ayHZ8MO/Z0leVEwWS mUwKcgC2LWcWF7QZoRsBAeQ= X-Google-Smtp-Source: AJdET5fbJJVwCItpFUo8kuhaEIv2CSYugvbUyHN5SMNhvIvgwzewXxPBVvExnMl7M5K8CFvoKXmpIQ== X-Received: by 2002:a1c:1314:: with SMTP id 20-v6mr2625912wmt.132.1540383912416; Wed, 24 Oct 2018 05:25:12 -0700 (PDT) Received: from [192.168.50.230] ([213.27.245.162]) by smtp.gmail.com with ESMTPSA id y19-v6sm5953353wra.60.2018.10.24.05.25.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 05:25:11 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A9FB9A8B-6121-4A55-A947-F759A8F1B940"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 24 Oct 2018 14:25:09 +0200 In-Reply-To: <02B5B763-C10C-4EC9-BD9D-96B6A3F11A33@kaloom.com> Cc: Lorenzo Colitti , "Pascal Thubert (pthubert)" , Lorenzo Colitti , Bernard Aboba , "v6ops@ietf.org WG" , int-area , IETF IPv6 Mailing List , "opsec@ietf.org" , dhcwg , "opsawg@ietf.org" , "v6ops-chairs@ietf.org" , Warren Kumari To: Suresh Krishnan References: <9E0D2E7C-FC28-49AC-A165-241C0BC3487E@kaloom.com> <3BB81D98-E70D-45B4-A99D-94AF29D89526@kaloom.com> <02B5B763-C10C-4EC9-BD9D-96B6A3F11A33@kaloom.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-Mailman-Approved-At: Wed, 24 Oct 2018 05:26:43 -0700 Subject: Re: [v6ops] [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 12:25:19 -0000 --Apple-Mail=_A9FB9A8B-6121-4A55-A947-F759A8F1B940 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Well, it's not crazy to bring it to v6ops. I sent the authors to = int-area IIRC, but we could look at it in the IETF 104 timeframe and in = email in between time. It won't make the agenda for 103 - we're full up. > On Oct 24, 2018, at 5:13 AM, Suresh Krishnan = wrote: >=20 > I did think of it, but the draft is also expected to work with IPv4 = and that made me reconsider (In fact one of my solicited reviews for the = previous version of this draft was from Fred Baker). Fred/Ron, do you = think this draft can fit in v6ops? If so, I will send the authors your = way. = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_A9FB9A8B-6121-4A55-A947-F759A8F1B940 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvQZKUACgkQEhdRnd2G P+BlpQ//XFPHiEjrsSTuryLPztNkY93Fc5ingpg4tUGaUB1yXGFtEBdV0k/eoq7D ufVQoJ3s4CFd/CKSU4JxHvjwFkzPyb73GyF2i56rQNN+fp2ZHoNI0DuUybuydIds cg+9PAOrSCYu2RblSUKU8AhbW5OpH7rl/05AvxIA1v0wacE+J8yqFs8kvD4ULox1 Nu2aKEkcWjFaLc9vPDZMny4GHTmY1QhB2ug/y+P0lq3MpOdX3yqrDf3nGcVf5GSE w4/1oxgBDAJFakE9kIZJRIA6aShM0U8a563uw1hbqR6fL4u93CJNBvaowoYzdrwP ZPtX6hQXqXojqIEMiR9jjEh6dfJe2SOEDj+vXlZVRguNWgJUMuzFGF7Jwc0rVQ1R 4IocB0fcy0r3RXaf5K1GbHrAcpa+pn0ZJfy3wMck3PChGIBjM/wE9yESQMn/FXlC jfRoRimri3vy8YNmocr9oNPqR6K2bWfial+mPauyiNkjHNktZAmyXZJr1U+ZlCzE U0H0RhySs4jfKurpYWGN5ssU0Gwmy3DnWc2vEEg2i0B6+iZs9ceNLhZXO9pgno6c IlQKxBfvk9MKPZbJDLh9H04vhu1nIeWnCu9xRIk+NUkFndhn3yGiAOj7JVGLkbcs d4dHZUkaOJr171OBlJNKeBqz4senwMbhgzs0VyEHdx+5EZMqCVQ= =FUcx -----END PGP SIGNATURE----- --Apple-Mail=_A9FB9A8B-6121-4A55-A947-F759A8F1B940-- From nobody Wed Oct 24 06:15:16 2018 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 C67D5128DFD for ; Wed, 24 Oct 2018 06:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWoakiGgociU for ; Wed, 24 Oct 2018 06:15:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0E1128A6E for ; Wed, 24 Oct 2018 06:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1540386909; x=1540991709; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Mq/loSs5rTJuVR6lwzqvYomApS1iKDqbYk0URdKFJHs=; b=aQp0ywD+QiONi jEvACNM98IGE8w/0R8EIa/pPzwlsZg+dPlNfZdzLDZjnYI0KWRjXIl/KEwRkuOB5 IGxvsczmXhisMfF9QYl+PhGbte3/mZO4a5CdVP0Fw2Yt7t+HV+oCFdLgFUvy8PeH D277Uoajwn+ysSICPKKSE8iYx286qA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 24 Oct 2018 15:15:09 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 24 Oct 2018 15:15:08 +0200 Received: from [172.17.38.90] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005922348.msg for ; Wed, 24 Oct 2018 15:15:07 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [172.17.38.90] X-MDArrival-Date: Wed, 24 Oct 2018 15:15:07 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1835a99611=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.3.181015 Date: Wed, 24 Oct 2018 15:15:04 +0200 From: JORDI PALET MARTINEZ To: Fred Baker , "Rajiv Asati (rajiva)" CC: "v6ops@ietf.org" Message-ID: <5220F845-EFBA-4A6E-A3C2-DE15403B2D0F@consulintel.es> Thread-Topic: [v6ops] Trajectory for "transition" mechanisms in our working group References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <06e64fd9-a6bf-adca-72f4-860c7771c41f@otenet.gr> <7872C714-A9AB-4750-BFD7-65B51D6F175C@consulintel.es> <406158AF-3450-44B8-BAB6-0EA75520922D@employees.org> <6104C9CF-5B63-4236-B123-1CE20364F41E@consulintel.es> <4D9F971A-62BC-4F53-9125-0B37E2CB0AC1@employees.org> <39CAAA09-67A1-4BD0-B23F-C3FC988D22A3@consulintel.es> <943cc5e8-ec11-0848-b8c1-4a173b158cfc@asgard.org> <21A53047-5BEB-4339-9237-69F158CCC820@consulintel.es> <41F5AF22-E69E-471E-B5F4-B7F4E0AA3B15@gmail.com> In-Reply-To: <41F5AF22-E69E-471E-B5F4-B7F4E0AA3B15@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:15:15 -0000 Hi Fred, Agree and depending on the specific IPv4aaS technology, it may be very simi= lar the CE part to what happens in the CLAT. However, and that's part of the issue, the CLAT (as well as some of the oth= er IPv4aaS) also runs a NAT44, and the combination of the NAT46 and NAT44 c= an be implemented in different ways, including a stateful one. Moreover, in some CEs, even if it is stateful, is not an issue, because is = done with hardware offloading. Some chipsets support it, some not. Some sup= port it but opensource implementations are not able to use it because the c= hipset vendor is not providing the code ... The other advantage, as reported by Cameron, is that if using DNS64, less t= han 1% of the traffic will use the CLAT, and only 25% will use the PLAT. Of= course, as more content/application providers deploy IPv6, those numbers w= ill keep going lower and lower. Of course, when doing performance testing, we need to isolate all that, or = it will not be a fair comparison. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: mi=C3=A9rcoles, 24 de octubre de 2018, 14:22 Para: "Rajiv Asati (rajiva)" CC: "v6ops@ietf.org" , JORDI PALET MARTINEZ Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our working g= roup I don't have measurements, but I have a comment on the design of the CL= AT protocol operation (RFC 7915). It maintains no tables; it simply appends= the IPv4 source and destination addresses to relevant /96 prefixes and wri= tes an IPv6 header, and does the reverse on packet receipt. The PLAT, which= is not very different from NAPT44 except using IPv6 as the source, is far = more complex by nature. Since it keeps no session state and does nothing se= ssion-related, I would be surprised to find session-count an issue in a CLA= T. =20 > On Oct 23, 2018, at 7:18 PM, Rajiv Asati (rajiva) = wrote: >=20 > Jordi, >=20 > This is quite useful. Do you also happen to have similar test numbers= with CLAT functionality vs. MAP(-T/E) CE functionality? That would really = help, and OpenWRT supports them. >=20 > It would be pertinent to have consistent traffic amount and no of con= nections/flows in each case. >=20 > Say, 60% IPv6 and 40% IPv4 traffic (by bps) as well as connections. >=20 > Has anybody got any recent measurement about no of connections per HG= W? Mine is dated in 2012-2013. >=20 > Cheers, > Rajiv >=20 >=20 > From: v6ops on behalf of JORDI PALET MARTINE= Z > Date: Friday, October 19, 2018 at 4:04 PM > To: Mikael Abrahamsson > Cc: "v6ops@ietf.org" > Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our wo= rking group >=20 > Hi Mikael, >=20 > Sorry, was coming back from the RIPE and arranging a small test to sh= ow you the results, which are consistent with what I recall from my previou= s testing. >=20 > I'm using an ubuntu VM as the server, running in ESXi 6.5, and as cli= ent my own laptop. >=20 > There is a Cisco switch between the server, the MT7621 device and my = client. >=20 > Ubuntu VM in ESXi --- Cisco Gig switch --- MT7621 under test --- clie= nt device >=20 > Server command: iperf3 -s >=20 > 1) LAN-to-LAN test (so both the server and client are connected to th= e LANs of the MT7621) > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 10.10.10.99 port 51300 connected to 10.10.10.3 port 5201 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 113 MBytes 951 Mbits/sec > [ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec > [ 4] 2.00-3.00 sec 112 MBytes 938 Mbits/sec > [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec > [ 4] 4.00-5.00 sec 112 MBytes 936 Mbits/sec > [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec > [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec > [ 4] 7.00-8.00 sec 112 MBytes 937 Mbits/sec > [ 4] 8.00-9.00 sec 112 MBytes 937 Mbits/sec > [ 4] 9.00-10.00 sec 112 MBytes 936 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec = sender > [ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec = receiver >=20 > 2) LAN-to-WAN NAT test without offloading > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 192.168.1.139 port 51447 connected to 10.10.10.3 port 520= 1 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 48.8 MBytes 409 Mbits/sec > [ 4] 1.00-2.00 sec 45.8 MBytes 384 Mbits/sec > [ 4] 2.00-3.00 sec 45.2 MBytes 379 Mbits/sec > [ 4] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec > [ 4] 4.00-5.00 sec 45.0 MBytes 378 Mbits/sec > [ 4] 5.00-6.00 sec 44.9 MBytes 377 Mbits/sec > [ 4] 6.00-7.00 sec 45.2 MBytes 379 Mbits/sec > [ 4] 7.00-8.00 sec 45.1 MBytes 378 Mbits/sec > [ 4] 8.00-9.00 sec 45.3 MBytes 380 Mbits/sec > [ 4] 9.00-10.00 sec 45.2 MBytes 379 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec = sender > [ 4] 0.00-10.00 sec 456 MBytes 382 Mbits/sec = receiver >=20 > 3) LAN-to-WAN NAT test with SOFTWARE offloading > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 192.168.1.139 port 51484 connected to 10.10.10.3 port 520= 1 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 98.4 MBytes 826 Mbits/sec > [ 4] 1.00-2.00 sec 98.2 MBytes 824 Mbits/sec > [ 4] 2.00-3.00 sec 96.9 MBytes 813 Mbits/sec > [ 4] 3.00-4.00 sec 97.6 MBytes 819 Mbits/sec > [ 4] 4.00-5.00 sec 98.2 MBytes 824 Mbits/sec > [ 4] 5.00-6.00 sec 96.5 MBytes 809 Mbits/sec > [ 4] 6.00-7.00 sec 96.0 MBytes 805 Mbits/sec > [ 4] 7.00-8.00 sec 96.1 MBytes 806 Mbits/sec > [ 4] 8.00-9.00 sec 97.8 MBytes 820 Mbits/sec > [ 4] 9.00-10.00 sec 97.5 MBytes 818 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 973 MBytes 816 Mbits/sec = sender > [ 4] 0.00-10.00 sec 971 MBytes 815 Mbits/sec = receiver >=20 > 4) LAN-to-WAN NAT test with HARDWARE offloading > iperf3 -c 10.10.10.3 > Connecting to host 10.10.10.3, port 5201 > [ 4] local 192.168.1.139 port 51523 connected to 10.10.10.3 port 520= 1 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 110 MBytes 926 Mbits/sec > [ 4] 1.00-2.00 sec 112 MBytes 938 Mbits/sec > [ 4] 2.00-3.00 sec 111 MBytes 933 Mbits/sec > [ 4] 3.00-4.00 sec 111 MBytes 935 Mbits/sec > [ 4] 4.00-5.00 sec 111 MBytes 933 Mbits/sec > [ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec > [ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec > [ 4] 7.00-8.00 sec 110 MBytes 923 Mbits/sec > [ 4] 8.00-9.00 sec 111 MBytes 934 Mbits/sec > [ 4] 9.00-10.00 sec 111 MBytes 933 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 1.09 GBytes 932 Mbits/sec = sender > [ 4] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec = receiver >=20 > Regarding CPU utilization, using htop, with both NO offloading and SW= offloading, it is evident that the CPU is being used reaching close to 100= % of one of the cores, a bit less in the others, while HW offloading CPU re= mains with the 1-2% utilization. >=20 > By the way the devices are cheap ones, different vendors, no differen= ce if I do the test with one or the other (tested with 3 different ones and= got same results). The most expensive one is probably around 30 USD (ZBT-W= G3526-16M). >=20 > I've used the stable builds and then upgraded everything to the lates= t versions. >=20 > https://downloads.openwrt.org/releases/18.06.1/targets/ramips/mt7621/ >=20 > If you're interested and coming to BKK, I can bring one of them and w= e can play a bit. >=20 > Regards, > Jordi >=20 > -----Mensaje original----- > De: Mikael Abrahamsson > Organizaci=C3=B3n: People's Front Against WWW > Fecha: jueves, 18 de octubre de 2018, 19:45 > Para: JORDI PALET MARTINEZ > CC: > Asunto: Re: [v6ops] Trajectory for "transition" mechanisms in our wor= king group >=20 > On Thu, 18 Oct 2018, JORDI PALET MARTINEZ wrote: >=20 > > Yes, 100% sure in this case. > > > > The SoC supports it with several SDKs/OSs: > > > > https://www.mediatek.com/products/homeNetworking/mt7621n-a > > > > You can enable HW or SW offloading, offers both options (didn't= checked > > what is the difference, I just go for the HW if it works, as I = guess > > outperforms the SW one). >=20 > I know the MT7621 does what you're saying in other OSes with thei= r SDK, > I'm questioning if the -j FLOWOFFLOAD is the way to do HW acceler= ation for > certain flows. Did you try to run full gig speed through it and c= heck CPU > usage? It's the easiest way to tell if the offload works or not. >=20 > It would be the least intrusive offload implementation I've ever = seen in > Linux, so if it actually works this way I'd be very happy, and ho= pe more > vendors does it the same way. >=20 > Did you buy some retail device? If you did, what was it? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > 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 =20 -----------------------------------------------------------------------= --------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Oct 29 04:31:33 2018 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 8464A130EA9 for ; Mon, 29 Oct 2018 04:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV92bo7E54fv for ; Mon, 29 Oct 2018 04:31:30 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0EF130EA1 for ; Mon, 29 Oct 2018 04:31:30 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id w66-v6so2380556oiw.4 for ; Mon, 29 Oct 2018 04:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=g1qMZ5sIjrk65QYtTczZKCPFQEqzX9kHYv30ozdkiXc=; b=uFLjGfjmSR3bvaCwtMEr36+4iiBJYUHU2lPIJaEsM9A+BWrVsOfKf79cPgLbNUwSTR 7Ea5670EdIaGfxNWxXOQUKP9rxUnhCfCoAvJH4vc5LSiIsKQPOA+GouJr84pS46N+S1U vC7Vf1VT25GsKn1oMfDH5rxJps/meN5pYGebOzlmgjQ2l+yE5zG/vjbD+sgsuQrEJksR 36DqDO3KRnMqtkXoYY/5snew9VuIBnWxQkcSEQ4I9GKhuEoe8p+hz3BzrWMoi4AgnOrI OQ3MjYgNojQ9y+ih82ZtZwx17LPYkSqyunaZfnLvpJBcF9NGtD2OdcMNrHwfSJrZf5I9 TBrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=g1qMZ5sIjrk65QYtTczZKCPFQEqzX9kHYv30ozdkiXc=; b=L/ZzyLZ5nXgJiX+BWbZbakjFQT/PFXSLgY/gmDjeR0MFC062AnJSatu/YJs6MsEFL+ QTWDXgz/0693TPTUBHIx79xwhnshokE/bUXcUeZ1vcKUC6YBvQD6Oddk2EQ4U1ADeT2/ rYwcTbmUAlKERmxF/D+VpUh2vi+xYWaiEDmA8tUg/SBmSYxFP311rPbwCc5qPLisl+XY aaE1KfNKPOJZG5lM86pkEC/J/LX1u5ZNVqWrXsNSkXVPLAgixidf6Kf50RFCHrCXcVUV V2O9hB55bx+lz299snwujciFqdETVecY2jla6fcAIeZPgJaBBkQP4wnkO8vgP7lU6V7u o+dA== X-Gm-Message-State: AGRZ1gJ0IIY/QAuz3OQxyybt5yJNiUX342GEJOVpQoN7MMmM2kGWUGgQ 6aZso9HCrAYB5Cz5YLFgag9BUofb X-Google-Smtp-Source: AJdET5f+dHIEFvIaSjXflnNV3DME1nmNV9Ew+wzpQ+62a2sEGvm1pBEfzzcWHoMbEt1w7A1On82f1w== X-Received: by 2002:aca:1c6:: with SMTP id 189-v6mr8610971oib.325.1540812689141; Mon, 29 Oct 2018 04:31:29 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1012? ([2600:8802:5600:1546::1012]) by smtp.gmail.com with ESMTPSA id f5-v6sm7501746oih.51.2018.10.29.04.31.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 04:31:28 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_0BEBD44E-769C-4B3F-8D78-941A030F8BC8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <3A6498AF-02FC-448B-980C-4099B73CE4D2@gmail.com> Date: Mon, 29 Oct 2018 04:31:26 -0700 Cc: Ron Bonica To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Functions needed for IETF 103 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 11:31:32 -0000 --Apple-Mail=_0BEBD44E-769C-4B3F-8D78-941A030F8BC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii V6ops will need two volunteers for v6ops at IETF 103, which is Monday = morning 5 November at 9:00-11:00: a note taker and a jabber scribe. Any = volunteers? --Apple-Mail=_0BEBD44E-769C-4B3F-8D78-941A030F8BC8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvW744ACgkQEhdRnd2G P+AE+A/+MVu77Ojgf+P+M/ZYy3EhooVql9duGbonXbL8IW7g7XN9AmNiLLYqt/WA HsX8PjUesOxhx/h5w9ydr9Iuc248jQhrYeFrEBG3bp5Gdx4LFS6RonuNHG4+STm5 so2vkSvUiDE4HZpqXzD6j9N7miTdIqCSKu3mLjGHlpcam4QNA8c02P3EoRF+G1gY Ce5gGWN0dGxng6gDjz3G/8i4mlbd/5PFODVJJMv1eYDKWnp0iCWBpWz61sDUfoo0 Z/jDWob+UDIif4Hq+CFwHwTQt5SYpesis9GkU9448Ghl9XYfrcfEPHJ2hV2Dc0/G VvRIF52cq07wxA4qlu0dvSWiLbps+oa1CQOX1UxHz7FSibysX3eH0jBDaFhvhRIR GladsU8jKLpAJ5fFER2YoyurBBOTuWTCOZzh6urqVlZbDZNBQNyl0R2qmoMAwJz7 x8gvgr42bhd8xCUwsYSH001TtOzyLyLUtGTLltC6FWvyTNpabbtwtK5zBy26bKUe cx3TwXsPwzvrrigSa6f5eSiR7d4kjAIZ8/S5mASiZzhdhIeHwLZC6dKr2hoVmZa4 IvbTdSbU06U7FhXoukKMmNr4afHPXGfTOhjdDcMAoplvWZDfEKKKUrWWol7fKEUO eA2jO7eD8FzKcAYtPDRJe7PuvPJQmtMki5lYyUwTS21VPyB1OhY= =M7Q7 -----END PGP SIGNATURE----- --Apple-Mail=_0BEBD44E-769C-4B3F-8D78-941A030F8BC8-- From nobody Mon Oct 29 07:31:48 2018 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 35022130E29 for ; Mon, 29 Oct 2018 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_7U9T-KYfmT for ; Mon, 29 Oct 2018 07:31:45 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3446130D7A for ; Mon, 29 Oct 2018 07:31:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9TEVhRj025652; Mon, 29 Oct 2018 15:31:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 095BE203EDE; Mon, 29 Oct 2018 15:31:43 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EF857203ECD; Mon, 29 Oct 2018 15:31:42 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w9TEVgpm019412; Mon, 29 Oct 2018 15:31:42 +0100 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <42af202d-a7d0-ceec-96b7-244873a51260@gmail.com> From: Alexandre Petrescu Message-ID: <25fc67a4-aec5-9665-dc57-fcd959064f65@gmail.com> Date: Mon, 29 Oct 2018 15:31:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 14:31:47 -0000 Le 22/10/2018 à 13:13, Mikael Abrahamsson a écrit : > On Mon, 22 Oct 2018, Alexandre Petrescu wrote: > >> But I do not understand what do you plan for IPv6 tethering?  Do you >> use DHCPv6 Prefix Delegation? > > All phones I am aware of use https://datatracker.ietf.org/doc/rfc7278/ > (64SHARE) to extend the WAN /64 to a single LAN. I guess these phones dont understand the bit 'L' in RA to stand for 'on-link' prefix, right? (the link between phone and PGW is distinct than the wifi link; one bit can not hold three values). (these remarks came to me while reviewing a draft by somebody else about a related topic). Alex From nobody Mon Oct 29 07:35:12 2018 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 56215130D7A for ; Mon, 29 Oct 2018 07:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAG2MVBN5Ugk for ; Mon, 29 Oct 2018 07:35:08 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAD9130F67 for ; Mon, 29 Oct 2018 07:35:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DDADDB1; Mon, 29 Oct 2018 15:35:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1540823705; bh=8/Ivt1pdCsBo+NNYrVtYzzXRq0eUWg7HBTIo+1GGO/I=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Y+MTeHf91wPgLMdEpznoA33T03ik1NFK+r7Hh9L7Gt1JXv3J8UGjm8l3YsCJ30hPt 1Ez41NwR8kIbSHgieS9WwRv0GPndo5pID1HtGpHSk0BQ1XxX/hElwYCd+eatUn0Y6E HaTA6e/E5urY/MrqmcqeHzgH4cu4FfB+eo630ToQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DB333AF; Mon, 29 Oct 2018 15:35:05 +0100 (CET) Date: Mon, 29 Oct 2018 15:35:05 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: <25fc67a4-aec5-9665-dc57-fcd959064f65@gmail.com> Message-ID: References: <42af202d-a7d0-ceec-96b7-244873a51260@gmail.com> <25fc67a4-aec5-9665-dc57-fcd959064f65@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 14:35:10 -0000 On Mon, 29 Oct 2018, Alexandre Petrescu wrote: > I guess these phones dont understand the bit 'L' in RA to stand for > 'on-link' prefix, right? (the link between phone and PGW is distinct > than the wifi link; one bit can not hold three values). The link between PGW and phone is a point-to-point link. No ND is performed. PGW doesn't have any addresses on this link. If you want to nit-pick that into this being two links that's fine, but it's also pointless. 64SHARE works fine and has been deployed into billions of devices. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 29 08:03:25 2018 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 17719130F9C for ; Mon, 29 Oct 2018 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRup2gH3HYg9 for ; Mon, 29 Oct 2018 08:03:20 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173A9130F7C for ; Mon, 29 Oct 2018 08:03:20 -0700 (PDT) Received: from [IPv6:2601:647:4201:4561:d9a1:fed3:f991:4021] ([IPv6:2601:647:4201:4561:d9a1:fed3:f991:4021]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w9TF3G6U074014; Mon, 29 Oct 2018 15:03:17 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Joel Jaeggli In-Reply-To: Date: Mon, 29 Oct 2018 08:03:16 -0700 Cc: Alexandre Petrescu , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1F7D0586-4E2E-40A3-AFBC-7AD6AD7A7ACA@bogus.com> References: <42af202d-a7d0-ceec-96b7-244873a51260@gmail.com> <25fc67a4-aec5-9665-dc57-fcd959064f65@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 15:03:23 -0000 > On Oct 29, 2018, at 07:35, Mikael Abrahamsson = wrote: >=20 > On Mon, 29 Oct 2018, Alexandre Petrescu wrote: >=20 >> I guess these phones dont understand the bit 'L' in RA to stand for = 'on-link' prefix, right? (the link between phone and PGW is distinct = than the wifi link; one bit can not hold three values). >=20 > The link between PGW and phone is a point-to-point link. No ND is = performed. PGW doesn't have any addresses on this link. ND and the associated collection of host routes does not scale in this = context, so this is essentially prefix per host. What you do with it = ultimately is your business=E2=80=A6 >=20 > If you want to nit-pick that into this being two links that's fine, = but it's also pointless. 64SHARE works fine and has been deployed into = billions of devices. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Oct 29 08:30:46 2018 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 F0FD1130FB1 for ; Mon, 29 Oct 2018 08:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.969 X-Spam-Level: X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0uJr-HxowxF for ; Mon, 29 Oct 2018 08:30:42 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39191130F52 for ; Mon, 29 Oct 2018 08:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7424; q=dns/txt; s=iport; t=1540827042; x=1542036642; h=from:to:subject:date:message-id:mime-version; bh=YoV49l3N0GTY9fzVaDMOvBuqMTjqyf1v8XY1H96Ni2k=; b=hIDCQOFVFhhzk0FjFdR4/bN9r5WX9kJ+VvnMmuEoL9hqA892faS9GBRP pVuMrYCQTnp1wXlhyfvPw9xBILiv3rAexvdcWxuj7Ut2R5WAFvSRVZbaS xAzycbgRUPP99rGC1/q/8FgqllCBbj917f/v4bS0VvxCBNhx1Wb3rlt8G w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABFJ9db/5JdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDXdmfygKg2uIGIwXgg2RVYVLgXoLAQEjhEk?= =?us-ascii?q?ZgxYhNA0NAQMBAQIBAQJtHAyFOgEGI2gBCBEDAQIrAgQwHQoEARKDIQGBHWQ?= =?us-ascii?q?PqDCBLoQsAYEOhFMFi2cXgUE/gTgfgkyDGwQYgWeCZDGCJgKOSpA/CQKGaIo?= =?us-ascii?q?aGJBHjHCKBQIRFIEmHTiBVXAVZQGCQYpehXlvAYwFgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,440,1534809600"; d="scan'208,217";a="193287008" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2018 15:30:41 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w9TFUfEj012657 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Oct 2018 15:30:41 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 10:30:40 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 10:30:40 -0500 From: "Rajiv Asati (rajiva)" To: "nick.heatley@bt.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] iOS12 IPv6-only Thread-Index: AQHUb5xZ+cC5CHuRS/+94rl96Gg3sA== Date: Mon, 29 Oct 2018 15:30:40 +0000 Message-ID: <4802C555-4E6F-4FE4-B6A0-E9D2208F1867@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.3.181015 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.225.40] Content-Type: multipart/alternative; boundary="_000_4802C5554E6F4FE4B6A0E9D2208F1867ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [v6ops] iOS12 IPv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 15:30:44 -0000 --_000_4802C5554E6F4FE4B6A0E9D2208F1867ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljaywNCg0KQ29uZ3JhdHMuIFRoZSBncmFwaCBpcyBiZWF1dGlmdWwuIElQdjYgZ29pbmcg PjIwJSBpbiBvbmUgbW9udGguIFRoYW5rcyBmb3Igc2hhcmluZy4NCg0KQlRXLCBjb3VsZCB5b3Ug Y29uZmlybSB0aGF0IEFwcGxlIHN1cHBvcnQgZm9yIDQ2NFhMQVQgY29tZSBvdXQgaW4gaU9TMTI/ IEkgbWF5IGhhdmUgbWlzc2VkIGl0Lg0KSWYgYSB3aWZpIGRldmljZSBiZWhpbmQgaU9TIGRldmlj ZSBnZXRzIGFuIElQdjQgYWRkcmVzcyAod2l0aCBvciB3aXRob3V0IElQdjYgcHJlZml4KSwgdGhl biA0NjRYTEFUIG11c3QgYmUgd29ya2luZyBvbiBpdC4gQW55IGRhdGFwb2ludHMgd291bGQgYmUg c3VwZXJiICENCg0KDQpDaGVlcnMsDQpSYWppdg0KDQoNCkZyb206IHY2b3BzIDx2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIm5pY2suaGVhdGxleUBidC5jb20iIDxuaWNrLmhl YXRsZXlAYnQuY29tPg0KRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDE5LCAyMDE4IGF0IDEyOjUxIFBN DQpUbzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdjZvcHNd IGlPUzEyIElQdjYtb25seQ0KDQpIaSBmb2xrcywNCkkgd2FudCB0byBtZW50aW9uIGlPUzEyIGlz IGRyaXZpbmcgb3VyIElQdjYtb25seSByb2xsb3V0Lg0KVGhhbmtzIHRvIEFwcGxlIG1ha2UgdXNl IG9mIDQ2NHhsYXQgZm9yIHRldGhlcmluZyAoaS4uZS4gc3BlY2lmaWMgdG8gd2lmaSB0ZXRoZXJp bmcgaW50ZXJmYWNlIHRvIGNlbGx1bGFyKSwgdGhpcyBoYXMgYWxsb3dlZCB1cyB0byBza2lwIGR1 YWxzdGFjayBvbiBvdXIgY29tbW9uIEFQTi4NClNvIEkgYmVsaWV2ZSBvbmJvYXJkIGFwcHMganVz dCB1c2UgSGFwcHkgRXllYmFsbHMgdjIuLg0KTmljaw0KaHR0cHM6Ly9zdGF0cy5sYWJzLmFwbmlj Lm5ldC9pcHY2L0FTMTI1NzY/YT0xMjU3NiZjPUdCJng9MSZzPTAmcD0xJnc9MTUNCg0KDQo= --_000_4802C5554E6F4FE4B6A0E9D2208F1867ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBOaWNrLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25ncmF0cy4gVGhlIGdy YXBoIGlzIGJlYXV0aWZ1bC4gSVB2NiBnb2luZyAmZ3Q7MjAlIGluIG9uZSBtb250aC4gVGhhbmtz IGZvciBzaGFyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFcsIGNvdWxkIHlvdSBjb25m aXJtIHRoYXQgQXBwbGUgc3VwcG9ydCBmb3IgNDY0WExBVCBjb21lIG91dCBpbiBpT1MxMj8gSSBt YXkgaGF2ZSBtaXNzZWQgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J ZiBhIHdpZmkgZGV2aWNlIGJlaGluZCBpT1MgZGV2aWNlIGdldHMgYW4gSVB2NCBhZGRyZXNzICh3 aXRoIG9yIHdpdGhvdXQgSVB2NiBwcmVmaXgpLCB0aGVuIDQ2NFhMQVQgbXVzdCBiZSB3b3JraW5n IG9uIGl0LiBBbnkgZGF0YXBvaW50cyB3b3VsZCBiZSBzdXBlcmIgITxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFqaXY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj52Nm9wcyAmbHQ7djZvcHMtYm91bmNlc0BpZXRmLm9y ZyZndDsgb24gYmVoYWxmIG9mICZxdW90O25pY2suaGVhdGxleUBidC5jb20mcXVvdDsgJmx0O25p Y2suaGVhdGxleUBidC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgT2N0b2JlciAx OSwgMjAxOCBhdCAxMjo1MSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7djZvcHNAaWV0Zi5vcmcm cXVvdDsgJmx0O3Y2b3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bdjZvcHNd IGlPUzEyIElQdjYtb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgd2FudCB0byBtZW50aW9uIGlPUzEyIGlzIGRyaXZpbmcg b3VyIElQdjYtb25seSByb2xsb3V0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYW5rcyB0byBBcHBsZSBtYWtlIHVzZSBvZiA0 NjR4bGF0IGZvciB0ZXRoZXJpbmcgKGkuLmUuIHNwZWNpZmljIHRvIHdpZmkgdGV0aGVyaW5nIGlu dGVyZmFjZSB0byBjZWxsdWxhciksIHRoaXMgaGFzIGFsbG93ZWQgdXMgdG8gc2tpcCBkdWFsc3Rh Y2sgb24gb3VyIGNvbW1vbiBBUE4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+U28gSSBiZWxpZXZlIG9uYm9hcmQgYXBwcyBqdXN0 IHVzZSBIYXBweSBFeWViYWxscyB2Mi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8v c3RhdHMubGFicy5hcG5pYy5uZXQvaXB2Ni9BUzEyNTc2P2E9MTI1NzYmYW1wO2M9R0ImYW1wO3g9 MSZhbXA7cz0wJmFtcDtwPTEmYW1wO3c9MTUiPmh0dHBzOi8vc3RhdHMubGFicy5hcG5pYy5uZXQv aXB2Ni9BUzEyNTc2P2E9MTI1NzYmYW1wO2M9R0ImYW1wO3g9MSZhbXA7cz0wJmFtcDtwPTEmYW1w O3c9MTU8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4802C5554E6F4FE4B6A0E9D2208F1867ciscocom_--