From nobody Wed Jul 2 03:22:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3C1B28F2 for ; Wed, 2 Jul 2014 03:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 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, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, J_CHICKENPOX_32=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 DYHpGnaoX6kN for ; Wed, 2 Jul 2014 03:22:15 -0700 (PDT) Received: from nm33.bullet.mail.bf1.yahoo.com (nm33.bullet.mail.bf1.yahoo.com [72.30.238.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8D11B28EB for ; Wed, 2 Jul 2014 03:22:15 -0700 (PDT) Received: from [98.139.212.153] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2014 10:22:14 -0000 Received: from [98.139.212.217] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2014 10:22:14 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 02 Jul 2014 10:22:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 998679.71966.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 54675 invoked by uid 60001); 2 Jul 2014 10:22:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1404296533; bh=6fJnzBSTDFcSMHzwjHS/tupDq1IuhpDa+9ZCtZ+DCgo=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b45W6+FNrcFtBicourKImOrkVZP85qdV72WWLIdmGOSgDa8tEWuZ43+WzmA3k86TyS3XLT1S0Yz54SswDO7JyQKniVW69SDTm5adFEpnuNQmpN6s58hx4/nVzrgFHnOzPHhr+qkiMIQCBPIp91srDCL6wAMfz84JC25PQkjvx6k= X-YMail-OSG: qyswkwsVM1knSV4nKlsmNuhJi3rDCzH5kWBq2lFNad5cZr1 NdreoTtg3U0zqinwA1bENeQtdKtzS2u0xEAVXioBUs1yFdtQgJHh54GtkiAX IbMGnH4pJONeWkiZmdSs3ULZ8TrsR3G.SiwFY9vQo7eXLhcebZLP42hx0LqQ 91cv2F1uDW60UGDCvU8haHtK_AL5UI388KKAPowBEaS_Rxe2ZoxRhpF88NGY 47OWavWrRruq4KU7P6Wp2p9u71gjAZSUYT7P1pRc6kisKFJOR14t3WIvH13L XtOvzj8KnPZrTIvOylPOfn1vhJasCQ8zbZDsao0aUtakvlapsIZBPrER1VV4 5quqC9Be2HxqG0JLwIZrn7wV0_v0uqqV0juf8iJni_GMzGwPkRYmTL9ef0A7 8kNpdFkV4i0953qOOW4gvBtIHsnGJHLeWiPAerf7qdQXwlej.GB_4ZyhMLxd x83VyJXNsloG1xdDU8MdiBmdCyh0qSCLqLUsZ6bivjcTKL.eER9HlSYJxbO6 wTHIeDw9pMDwem099G2bRjVgC6I.KobUw6IZnHL0Y0e6d4XamvhSxFaI- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Wed, 02 Jul 2014 03:22:13 PDT X-Rocket-MIMEInfo: 002.001, CgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20.Cj4gVG86IFNoaXNoaW8gVHN1Y2hpeWEgKHNodHN1Y2hpKSA8c2h0c3VjaGlAY2lzY28uY29tPgo.IENjOiAia3NoaW1penVAanVuaXBlci5uZXQiIDxrc2hpbWl6dUBqdW5pcGVyLm5ldD47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPjsgImkxOG5AamFub2cuZ3IuanAiIDxpMThuQGphbm9nLmdyLmpwPgo.IFNlbnQ6IE1vbmRheSwgMzAgSnVuZSAyMDE0IDIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 References: <53AD471B.6070009@cisco.com> <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8ECC41@nkgeml506-mbx.china.huawei.com> Message-ID: <1404296533.59165.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Wed, 2 Jul 2014 03:22:13 -0700 From: Mark ZZZ Smith To: "Liubing \(Leo\)" , "Shishio Tsuchiya \(shtsuchi\)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ECC41@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/maBy2eYrcTZ45UeXbxTUflFCCY4 Cc: "kshimizu@juniper.net" , "v6ops@ietf.org" , "i18n@janog.gr.jp" Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 10:22:17 -0000 =0A=0A=0A----- Original Message -----=0A> From: Liubing (Leo) =0A> To: Shishio Tsuchiya (shtsuchi) =0A> Cc= : "kshimizu@juniper.net" ; "v6ops@ietf.org" ; "i18n@janog.gr.jp" =0A> Sent: Monday, 30 June 20= 14 2:10 PM=0A> Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2=0A> = =0A> Hi Shishio,=0A> =0A> Thanks much for sharing the information. It's gre= at that JANOG34 will =0A> provide more experience of using ULAs.=0A> =0A> B= asically I agree with Fred that it is important to see whether the statemen= ts =0A> of the draft is correct. In addition to Fred's comments, I have som= e other =0A> concerns:=0A=0ASo I added a ULA /64 to my home network in addi= tion to my ISP assigned GUA /64 in around May last year IIRC, so see if it = would cause any problems. I generally try to be a 'user' at home so that I = can get some insight into what the typical non-technical person experiences= .=0A=0AI haven't had any issues since adding the ULA, which could mean any = of (a) the ULA is never used, (b) the right choice is being made between th= e ULA and GUA prefix, and (c) happy eyeballs is hiding any IPv4 vs IPv6 ULA= issues. Not very scientific, but then again there has never been any issue= s which has made me consider the ULA prefix to be a possible cause. I have = for somewhere in the order of the last six months switched off the RA PIO L= bit for both my GUA and ULA prefix to see how hairpinning all traffic exce= pt link-local through my default router works, and have also not really not= iced anything, other than Linux Network manager taking over IPv6 configurat= ion from the kernel, and not obeying the RA PIO L bit (which should be fixe= d now).=0A=0A=0A> - Is it easy to configure a host with ULA+PA? E.g., both = through SLAAC=0A=0AYes. I'm using OpenWRT on my CPE, I added the ULA prefix= via the 'luci' gui. It is now an additional RA PIO, and I'm using SLAAC ad= dressing, so my hosts get both GUA and ULA prefixes/addresses (and temporar= y addresses as well, as I've also enabled that).=0A=0A> or =0A> through SLA= AC/DHCPv6 respectively.=0A=0ADon't know about DHCPv6.=0A=0A> - Are there st= ill many hosts using the old address selection algorithm [3484]? =0A> Since= [RFC3484] hosts will face the problem of selecting un-expected ULA-PA =0A>= source/destination address pairs.=0A=0AEither yes, or most likely. My 'nor= mal' or commonly used hosts are Linux (currently Fedora 20, 3 of them), and= for a while I was updating /etc/gai.conf with the new RFC6724 rules. Howev= er I haven't got around to doing that for the most recent Fedora 20 install= s, so I think it is likely that those hosts are still using RFC3484 rules f= or the last six months.=0A=0AI do have some virtual windows hosts, however = I haven't looked closely at them in this regard. My Android phone is has bo= th GUA and ULA addresses (and privacy addresses for both GUA and ULA prefix= es), and I've had no issues with using that. I recently got a Chromecast wh= ich can use IPv6 to stream content, and it doesn't seem to have had any iss= ues with the ULA prefix when accessing GUA IPv6 only available content.=0A= =0AThe ULA vs GUA rules in RFC6724 only really matter if there is a choice = between a GUA and a ULA. ULAs shouldn't be in the global DNS, so in most ca= ses there will be no choice, it'll either be one or more GUAs or one or mor= e ULAs exclusively.=0A=0ASome people seem to be concerned about ULAs being = put in the global DNS, and therefore causing problems if a host tries to us= e an unreachable ULA instead of a reachable GUA address. In my experience I= haven't seen that problem occur with RFC1918s in global IPv4 DNS entries, = so I don't think it will happen much with IPv6 ULAs. That being said, I thi= nk the Happy Eyeballs approach applied to the set of returned IPv6 addresse= s, which might be a mix of GUAs and ULAs, not just across IPv4 and IPv6 add= resses would mitigate that.=0A=0A> - Let me confirm the ULA-only Deployment= in JANOG34, did you mean "connect =0A> to the Internet through ULA-only" o= r "ULA-only in an isolated network =0A> or for internal use only"? (The 3.2= .1 of the draft specifically means the =0A> former.) =0A>=0A=0AThese questi= ons sound a bit to me like you haven't added a ULA prefix to an IPv6 networ= k you're commonly using. So if you haven't, I think you should - 'the proof= of the pudding is in the eating'.=0A=0ARegards,=0A=0AMark.=0A=A0 =0A> Best= regards,=0A> Bing=0A> =0A> =0A>> -----Original Message-----=0A>> From: F= red Baker (fred) [mailto:fred@cisco.com]=0A>> Sent: Saturday, June 28, 201= 4 8:58 AM=0A>> To: Shishio Tsuchiya (shtsuchi)=0A>> Cc: Liubing (Leo); ks= himizu@juniper.net; v6ops@ietf.org; i18n@janog.gr.jp=0A>> Subject: Re: [v6= ops] JANOG34 provides 3.2.1 and 3.2.2=0A>> =0A>> =0A>> On Jun 27, 2014, at= 3:27 AM, Shishio Tsuchiya =0A> wrote:=0A>> =0A>> > L= eo and v6ops=0A>> > F.Y.I=0A>> > JANOG(JApan Network Operator's Group) de= cided to provide ula =0A> address=0A>> to the JANOG34 conference network.= =0A>> > http://www.janog.gr.jp/en/index.php?JANOG34_Meeting=0A>> >=0A>> = > They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with=0A= >> GUA.=0A>> >=0A>> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usag= e-recommendations-02=0A>> >=0A>> > If you would like to confirm something= on the network , please let me=0A>> know.=0A>> =0A>> Thanks for this.=0A= >> =0A>> I would expect that the key things to prove are the statements in= the =0A> draft.=0A>> Also, any observations that might come up would be u= seful. For example,=0A>> was it fair to say that the network that was isol= ated remained isolated? =0A> Did=0A>> using a ULA and a GUA on a globally-= accessible network cause any issues?=0A>> What, if anything, was necessary= in the router(s) in question to prevent =0A> hosts=0A>> from using ULA so= urce addresses to connect to GUA addresses? Did hosts in=0A>> fact form bo= th ULA and GUA-based addresses and use them appropriately=0A>> when connec= ting to applications inside and outside the network?=0A>> =0A>> What one m= ight hope would be that ULA-based addresses were used to=0A>> connect to o= ther ULA-based addresses, as their bit strings were most =0A> similar,=0A>>= and GUA-based addresses were used to connect to other GUA-based=0A>> add= resses, for the same reason. One might hope that ULA prefixes were not=0A>>= announced in BGP without needing extra thought, and that if they were=0A>= > announced, they were not accepted. One might further hope that when a=0A= >> ULA was not announced into a neighboring domain, a packet sent to the U= LA=0A>> prefix didn't cross the domain boundary.=0A>> =0A>> Of course, we= need to hear about any extra work that was required, and any=0A>> problem= s that arose. And we need to understand if the deployment of a ULA=0A>> pr= efix necessarily implied the deployment of an IPv6/IPv6 NAT or NAPT. I=0A>>= don't expect that it will and am certainly not asking for it to, but =0A>= that=0A>> expectation has been promoted.=0A>> =0A>> JANOG will be Wednes= day-Friday the week before IETF 90, and v6ops will=0A>> meet Monday and Tu= esday. It would be nice if someone could make a point=0A>> of reporting on= the experiment.=0A> =0A> _______________________________________________= =0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman= /listinfo/v6ops=0A> From nobody Wed Jul 2 04:40:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8071A0035 for ; Wed, 2 Jul 2014 04:39: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_05=-0.5, 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, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 EpcGYsLBpDqw for ; Wed, 2 Jul 2014 04:39:59 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09481A001C for ; Wed, 2 Jul 2014 04:39:58 -0700 (PDT) Received: from [98.139.215.141] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2014 11:39:58 -0000 Received: from [98.139.212.251] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2014 11:39:58 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 02 Jul 2014 11:39:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 196272.8476.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 74271 invoked by uid 60001); 2 Jul 2014 11:39:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1404301198; bh=Sv94FHymBPME/VI5FcMU3NFsjgQox56Vnu6KUgbb4Sg=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QZ1PFY4gVrYp4+jMnamcZjKkAZhf0juo9GrBRlimw2Sz8RgVeU2leV0dbUkRMRBo0qZG1IIOZB59Y/u+PjTi1eJdqGKSDFgyBeNIBRqE3EUsM1d3L3+yQOhe+4S4un2/WwBfDGg4A0cas5mScu1smdGtlDYzdhsx1jNCuBVADYo= X-YMail-OSG: 3NZrINAVM1mqQPqkbdjfKzuvDIuXOli1olIWMAaCF71R4ia gN83dVVCmOHK0hN9QFiUCxTWKHEhFz3.ufJRwUbqj2pDhO85HHVjSYOnIT_u BQHEVCdbzsCuzMYoMLtm34dTloGiHpeY1r0V_01sLGHQAjVmc9phqgZJdPXT N.Zpyoy.HooPTBEGs7Sw6s98pF.oBadsQfjYaSUaHoOm4cK6.kb_eMF83dOk kDmNoKBoeofLw_V6g45Q2P44RKlH9FWeXIUr6XGbppDh95F6xqGmp3B23bSM 4keIdaj_u6uwtM6rwR2ihGoMRuwYsUfdoRrOO7aZjjYFpt0m7RAxszvk_tXV LehH1whrACUq8N5W1A19j5ht4MtYe9VdR3a3amZNxEqTBp.H8nYsvSlZuMVi NVD6ylJle8fOVuCIYSGY2tQhOdRlzsZU_7ldb8HhHAxE5MhFoWPhT81TIhQq R2JkDRhRg96hVOVG0hRSFEPoPhqJZEzKc_OMxgmEuKaQpVggHCuR0tJfSDa4 mp7OkHZS1G_zgebzgM8ztMfoOczG82SXzojoxfpp5EVwMBQhgSv0pSKy5vyx R.vGj Received: from [150.101.221.237] by web162203.mail.bf1.yahoo.com via HTTP; Wed, 02 Jul 2014 04:39:58 PDT X-Rocket-MIMEInfo: 002.001, PHNuaXA.Cj4gCj4gU28gSSBhZGRlZCBhIFVMQSAvNjQgdG8gbXkgaG9tZSBuZXR3b3JrIGluIGFkZGl0aW9uIHRvIG15IElTUCBhc3NpZ25lZCBHVUEgLzY0wqAKCkp1c3QgdG8gcXVhbGlmeSB0aGF0IGJlY2F1c2UgSSBkb24ndCBiZWxpZXZlIElTUHMgc2hvdWxkIGdpdmUgb3V0IGEgc2luZ2xlIC82NCwgSSBnZXQgYSAvNTYgZnJvbSBteSBJU1AgKGFzIEkgc2hvdWxkIGF0IGxlYXN0KSwgSSBvbmx5IGN1cnJlbnRseSBoYXZlIGEgc2luZ2xlIExBTiBzZWdtZW50LCBzbyBJJ20gb25seSB1c2luZyBvbmUgb2YBMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 References: <53AD471B.6070009@cisco.com> <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8ECC41@nkgeml506-mbx.china.huawei.com> <1404296533.59165.YahooMailNeo@web162204.mail.bf1.yahoo.com> Message-ID: <1404301198.63756.YahooMailNeo@web162203.mail.bf1.yahoo.com> Date: Wed, 2 Jul 2014 04:39:58 -0700 From: Mark ZZZ Smith To: Mark ZZZ Smith , "Liubing \(Leo\)" , "Shishio Tsuchiya \(shtsuchi\)" In-Reply-To: <1404296533.59165.YahooMailNeo@web162204.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/R-piAG-noTxdrU2EqhJzt2KWR6w Cc: "kshimizu@juniper.net" , "v6ops@ietf.org" , "i18n@janog.gr.jp" Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 11:39:59 -0000 =0A> =0A> So I added a ULA /64 to my home network in addition to my I= SP assigned GUA /64=A0=0A=0AJust to qualify that because I don't believe IS= Ps should give out a single /64, I get a /56 from my ISP (as I should at le= ast), I only currently have a single LAN segment, so I'm only using one of = my /64s (with a random subnet number to minimise predictability). (It might= be interesting if my CPE sent unsolicited inbound traffic to all of my oth= er /64s to an RFC6018 Greynet somewhere.) From nobody Wed Jul 2 20:10:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F521A0AEA for ; Wed, 2 Jul 2014 20:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, J_CHICKENPOX_55=0.6, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 KHe3BeFvOMx9 for ; Wed, 2 Jul 2014 20:10:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23121A0ADF for ; Wed, 2 Jul 2014 20:10:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJN21609; Thu, 03 Jul 2014 03:10:23 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 04:10:22 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 11:10:17 +0800 From: "Liubing (Leo)" To: Mark ZZZ Smith , "Shishio Tsuchiya (shtsuchi)" Thread-Topic: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 Thread-Index: AQHPkfJyy4YNtnZygkqC4I6HwJUT9JuFLg2AgAPJYdCAAx2LgIABisZA Date: Thu, 3 Jul 2014 03:10:16 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED92F@nkgeml506-mbx.china.huawei.com> References: <53AD471B.6070009@cisco.com> <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8ECC41@nkgeml506-mbx.china.huawei.com> <1404296533.59165.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1404296533.59165.YahooMailNeo@web162204.mail.bf1.yahoo.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r0u5FQrMefVA3J21-fY--dJ13Xk Cc: "kshimizu@juniper.net" , "v6ops@ietf.org" , "i18n@janog.gr.jp" Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 03:10:33 -0000 Hi Mark, Thanks much for sharing the detailed experience. > These questions sound a bit to me like you haven't added a ULA prefix to = an > IPv6 network you're commonly using. So if you haven't, I think you should= - > 'the proof of the pudding is in the eating'. [Bing] We did some test in the lab, mostly on ULA+PA, and it worked well, j= ust as you experienced. And there were also some feedbacks of successful us= age of ULAs in home networks in the mailing list. ULA+PA is also recommende= d by the Homenet WG. Personally I believe ULA+PA in home networks has got s= ufficient proof. However, we haven't had plenty of experience of using ULAs in a real produc= tion network, e.g. a JANOG event, or a middle/big size enterprise network o= r ISP networks .etc. That's why the WG suggested the draft to be "Informati= onal", and to change the key words "recommendation"/"guidelines" to "consid= erations" in the draft. So I think experiences like JANOG34 would help us to proof more about the s= tatements in the draft. If we could have more experiences like this in the future, maybe we can cha= nge the document to BCP. Best regards, Bing =20 > Regards, >=20 > Mark. >=20 > > Best regards, > > Bing > > > > > >> -----Original Message----- > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Saturday, June 28, 2014 8:58 AM > >> To: Shishio Tsuchiya (shtsuchi) > >> Cc: Liubing (Leo); kshimizu@juniper.net; v6ops@ietf.org; > >> i18n@janog.gr.jp > >> Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 > >> > >> > >> On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya > > wrote: > >> > >> > Leo and v6ops > >> > F.Y.I > >> > JANOG(JApan Network Operator's Group) decided to provide ula > > address > >> to the JANOG34 conference network. > >> > http://www.janog.gr.jp/en/index.php?JANOG34_Meeting > >> > > >> > They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along > >> with GUA. > >> > > >> > >> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations > >> -02 > >> > > >> > If you would like to confirm something on the network , please let > >> me know. > >> > >> Thanks for this. > >> > >> I would expect that the key things to prove are the statements in > >> the > > draft. > >> Also, any observations that might come up would be useful. For > >> example, was it fair to say that the network that was isolated remain= ed > isolated? > > Did > >> using a ULA and a GUA on a globally-accessible network cause any > issues? > >> What, if anything, was necessary in the router(s) in question to > >> prevent > > hosts > >> from using ULA source addresses to connect to GUA addresses? Did > >> hosts in fact form both ULA and GUA-based addresses and use them > >> appropriately when connecting to applications inside and outside the > network? > >> > >> What one might hope would be that ULA-based addresses were used to > >> connect to other ULA-based addresses, as their bit strings were most > > similar, > >> and GUA-based addresses were used to connect to other GUA-based > >> addresses, for the same reason. One might hope that ULA prefixes were > >> not announced in BGP without needing extra thought, and that if they > >> were announced, they were not accepted. One might further hope that > >> when a ULA was not announced into a neighboring domain, a packet > >> sent to the ULA prefix didn't cross the domain boundary. > >> > >> Of course, we need to hear about any extra work that was required, > >> and any problems that arose. And we need to understand if the > >> deployment of a ULA prefix necessarily implied the deployment of an > >> IPv6/IPv6 NAT or NAPT. I don't expect that it will and am certainly > >> not asking for it to, but > > that > >> expectation has been promoted. > >> > >> JANOG will be Wednesday-Friday the week before IETF 90, and v6ops > >> will meet Monday and Tuesday. It would be nice if someone could make > >> a point of reporting on the experiment. > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Jul 3 00:48:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52B61A037A for ; Thu, 3 Jul 2014 00:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 ytnoLGqnbo1R for ; Thu, 3 Jul 2014 00:48:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BA51A01BE for ; Thu, 3 Jul 2014 00:48:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGS97945; Thu, 03 Jul 2014 07:48:39 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 08:48:38 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 15:48:35 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: Multiple IPv6 prefixes issues-//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPlpMxxzM69XejJUCyDwyFI9MS4w== Date: Thu, 3 Jul 2014 07:48:34 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Cp-LzGaD9_bH3TE4pJ46_U7sSHQ Subject: [v6ops] Multiple IPv6 prefixes issues-//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 07:48:44 -0000 SGkgYWxsLA0KDQpXZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gV2Ugb25j ZSBoYWQgc29tZSBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuDQpUaGlzIG5ldyB2ZXJzaW9uIGNs ZWFybHkgc2VwYXJhdGVkIHRoZSBzY29wZSBmcm9tIE1JRi4gQW5kIHRoZXJlIGFyZSBsb3RzIG9m IHRleHRzIHJldmlzaW9uIHRvIG1ha2UgaXQgcGF5IG1vcmUgYXR0ZW50aW9uIG9uIG9wZXJhdGlv bmFsIGNvbnNpZGVyYXRpb25zIGFuZCBwcm9ibGVtcy4gDQoNClBhcnRpY3VsYXJseSwgdGhlcmUg aXMgYSBuZXdseSBpZGVudGlmaWVkIG9wZXJhdGlvbmFsIGlzc3VlIGluIHJlYWwgcHJvZHVjdCBu ZXR3b3JrIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMiwgdGhlICIgTkQgdGFibGUgc3BhY2Ug c2hvcnRhZ2UgaW4gYmlnIEwyIG5ldHdvcmtzIiwgSSdkIGxpa2UgdG8gaGVhciBjb21tZW50cyBm cm9tIHlvdSBvbiB0aGlzIHNwZWNpZmljIGlzc3VlLiANCkNvbW1lbnRzIG9uIG90aGVyIGNvbnRl bnQgYXJlIG9mIGNvdXJzZSB3ZWxjb21lZCBhcyB3ZWxsLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5n DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXks IEp1bHkgMDMsIDIwMTQgMzozMSBQTQ0KVG86IEJveWFuZzsgU2hlbmcgSmlhbmc7IExpdWJpbmcg KExlbyk7IFNoZW5nIEppYW5nOyBCb3lhbmc7IExpdWJpbmcgKExlbykNClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LXY2b3BzLXJ1bm5pbmctbXVsdGlwbGUt cHJlZml4ZXMtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS12Nm9w cy1ydW5uaW5nLW11bHRpcGxlLXByZWZpeGVzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6CQlkcmFmdC1saXUtdjZvcHMtcnVubmluZy1tdWx0aXBsZS1wcmVmaXhlcw0KUmV2 aXNpb246CTAxDQpUaXRsZToJCVJ1bm5pbmcgTXVsdGlwbGUgSVB2NiBQcmVmaXhlcw0KRG9jdW1l bnQgZGF0ZToJMjAxNC0wNy0wMw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJMTENClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saXUtdjZvcHMtcnVubmluZy1tdWx0aXBsZS1wcmVmaXhlcy0wMS50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtdjZv cHMtcnVubmluZy1tdWx0aXBsZS1wcmVmaXhlcy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtdjZvcHMtcnVubmluZy1tdWx0aXBsZS1wcmVmaXhl cy0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWxpdS12Nm9wcy1ydW5uaW5nLW11bHRpcGxlLXByZWZpeGVzLTAxDQoNCkFic3RyYWN0Og0K ICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgdGhhdCBtdWx0aXBsZSBwcmVmaXhlcyBpbiBvbmUg bmV0d29yay9ob3N0DQogICBtaWdodCBiZSBjb21tb24gaW4gSVB2NiBkZXBsb3ltZW50LCBhbmQg ZGVzY3JpYmVzIHNldmVyYWwgdHlwaWNhbA0KICAgbXVsdGlwbGUgcHJlZml4ZXMgdXNlIGNhc2Vz LiBUaGVuIHNvbWUgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgYW5kDQogICBjdXJyZW50IHBy b2JsZW1zIG9mIHJ1bm5pbmcgbXVsdGlwbGUgcHJlZml4ZXMgYXJlIGRlc2NyaWJlZC4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu Jul 3 01:27:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FE91A0451 for ; Thu, 3 Jul 2014 01:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 WamiRidinqp7 for ; Thu, 3 Jul 2014 01:27:21 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60241A03E9 for ; Thu, 3 Jul 2014 01:27:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6013FA1; Thu, 3 Jul 2014 10:27:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404376039; bh=A5iYxuqqjQYIiB0TsW2V362jmWdV7nhlDA1teQVvTM4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=gARHtt+3K63Le0E0Vt19OlDdyXARFLBNVp0xnE8oicOhr323l1TlJ6ZpZivmarT0R sCBMYTbpnUc2yl8wtIuWBs4SAToWc6Ys4AgGDVSxdXlQuTfmvBgTM9D1eX2JjZRtu9 jsrskbwdhmslcSmx8YmcDF9LocdsB3A0kSQlZ1TQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 523A89F; Thu, 3 Jul 2014 10:27:19 +0200 (CEST) Date: Thu, 3 Jul 2014 10:27:19 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: Message-ID: References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QtkMbqfxThdUOl8iRCUirqmd4kg Cc: V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 08:27:23 -0000 On Mon, 2 Jun 2014, Ted Lemon wrote: > The long-lived connection I'd be most interested in would be a download > or a video stream. TBH, I don't know the state of the art on streaming I'd say at least for some streaming service, the state of the art now is to download smaller chunks, for instance a few seconds, at a time. From my understanding, they do this so they can switch data rates/resolution fairly quickly to adapt to network conditions. So a host that has multiple interfaces could potentially pull video data from multiple paths, and it could switch fairly quickly if it had the logic needed. This is one reason why I find MIF very interesting going forward, it removes the need for "mobility" for some devices, because if they could switch over their application streams within a few seconds after being told to do so for instance by a mobile network, there would be a lot less need for tunneling in order to provide mobility. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 3 07:21:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6D51B2A6E for ; Thu, 3 Jul 2014 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 ggI4g5N94kE4 for ; Thu, 3 Jul 2014 07:21:34 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0C21B2A0E for ; Thu, 3 Jul 2014 07:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6274; q=dns/txt; s=iport; t=1404397294; x=1405606894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0ztR5RqbHLA0scgTItvrnbnUOlsjnbE2ZdIajfmpUsA=; b=ahSVdlN5HoElC5P2QEQDZnauCcnl5+gRgBrAa2rJRzMwTAQidKK1PkEx R7lCwCs4VPZc7IhlyfBRPcx0R2eDtxe2ilN4/+BzmfFdhFeyxer+4W5jW Z2p/AyLJ925xozUcM9YFF1lLhXEEP7jRhaLgoiNVg03mkjhqNkOXFK5mc w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAONltVOtJA2G/2dsb2JhbABagw1SWoJvwy4BgQYWdYQDAQEBBCEBQwgMDAQCAQgRBAEBAQ8YAgMCMhQJCAIEDgUOiDQNkH2cIgGbcxeOQBACAU8HBoJuOYEWBZIcgUOCdoQYgUiSQoNDbIFE X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="asc'?scan'208";a="58069162" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 03 Jul 2014 14:21:33 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s63ELXTj018560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 14:21:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 09:21:33 -0500 From: "Fred Baker (fred)" To: V6 Ops List Thread-Topic: Planning for IETF #90 Thread-Index: AQHPdSzfBnWUD3cMwE+7V8ANe7NhvJuORuGQgAC2woA= Date: Thu, 3 Jul 2014 14:21:32 +0000 Message-ID: <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com> References: <43AE4B9F-206F-4969-81B8-AE003DC9DF4C@cisco.com> <8392F9BAC6AD5F47920216A6D7853F7E1D62B8CF@BPXM02GP.gisp.nec.co.jp> In-Reply-To: <8392F9BAC6AD5F47920216A6D7853F7E1D62B8CF@BPXM02GP.gisp.nec.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.202] Content-Type: multipart/signed; boundary="Apple-Mail=_D032D6E9-AE9F-4618-ABCF-A3965B3B35F1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SyahoPpsOcmb8cxUpzztD1GA8XE Cc: "Ata, Shingo \(ata@info.eng.osaka-cu.ac.jp\)" Subject: Re: [v6ops] Planning for IETF #90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:21:37 -0000 --Apple-Mail=_D032D6E9-AE9F-4618-ABCF-A3965B3B35F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp v6ops: Kitamura-san has posted draft-kitamura-ipv6-zoneid-free, and would like = operational views on it. He has also requested agenda time at IETF 90. I = suspect it may be more suited for 6man, but 6man isn=1B$B!G=1B(Bt = meeting. Would you kindly take a look and comment? If there is operational interest, we can give him a slot. Fred On Jul 3, 2014, at 1:47 AM, Hiroshi Kitamura = wrote: > Dear co-chairs of v6ops WG, >=20 > We have submitted a I-D: > "Free from Using Zone Identifier for IPv6 Link-Local Address" > >=20 > I quote the I-D Announce mail at the end of this mail. >=20 > This idea "Zone-ID Free" is simple and harmless to the current system. > We think this idea helps many people who face problems on Zone-ID. >=20 > So, could you give us a presentation time at 90th Toronto meeting, = please? >=20 >=20 > - title and file name of the draft >=20 > "Free from Using Zone Identifier for IPv6 Link-Local Address" > >=20 > - speakers name and email >=20 > Hiroshi KITAMURA > kitamura@da.jp.nec.com >=20 > - how much time >=20 > 10 min. >=20 > Best Regards, > Hiroshi >=20 >=20 >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org >> Sent: Wednesday, July 02, 2014 12:17 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-kitamura-ipv6-zoneid-free-03.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Free from Using Zone Identifier for IPv6 = Link-Local Address >> Authors : Hiroshi Kitamura >> Shingo Ata >> Masayuki Murata >> Filename : draft-kitamura-ipv6-zoneid-free-03.txt >> Pages : 17 >> Date : 2014-07-01 >>=20 >> Abstract: >> This document describes "Zone-ID Free" functions that make end >> users free from using zone identifiers (Zone-ID) for IPv6 link- >> local addresses. >>=20 >> When users deal with IPv6 link-local addresses, it is thought that >> it is mandatory thing to specify accompanied Zone-IDs. For end >> users, however, it is troublesome and nuisance thing to do it. >> Because it is very hard for normal end users to find appropriate >> Zone-IDs for this purpose. >>=20 >> =46rom another viewpoint, the usage of IPv6 link-local addresses >> accompanied with Zone-IDs is quite different from the traditional >> usage of global addresses. Therefore many problems related with >> Zone-ID are caused and new specifications are required to fix these >> problems. >>=20 >> This document explores and describes how "Zone-ID Free" functions >> work and how end users are released from using Zone-IDs when they >> deal with IPv6 link-local addresses. >>=20 >> The "Zone-ID Free" functions are upper compatible with the current >> usages of dealing with IPv6 link-local addresses and harmless to >> the existing communications. >>=20 >> In order to obtain appropriate Zone-ID information, a new >> technology "Zone-ID Learning" that issues multiple probes is >> introduced. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kitamura-ipv6-zoneid-free/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kitamura-ipv6-zoneid-free-03 >=20 >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker = (fred) >> Sent: Thursday, May 22, 2014 4:43 AM >> To: v6ops >> Subject: [v6ops] Planning for IETF #90 >>=20 >> IETF #90 is two months away, and we have about six weeks to get = drafts updated or new drafts filed. This is a heads-up. >> My rule for putting drafts on the agenda is that they are file or = updated since the last IETF meeting and have had supportive >> working group commentary on the list. Filing at the last instant = generally doesn=1B$B!G=1B(Bt help with folks=1B$B!G=1B(B commentary - = you want >> to give them some time to read and think. So, filing drafts or making = updates in June is recommended. >>=20 >> Current draft status: >>=20 >> IESG: >> Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 >> Mar 10 draft-ietf-v6ops-nat64-experience >> Apr 1 draft-ietf-v6ops-64share >>=20 >> Exiting WGLC; on its way to IESG: >> May 19 draft-ietf-v6ops-clatip >>=20 >> Working Group Document updated since IETF: >> Mar 6 draft-ietf-v6ops-design-choices >> Mar 11 draft-ietf-v6ops-mobile-device-profile >>=20 >> Individual Submission updated since IETF: >> Mar 4 draft-cui-v6ops-lte-lw4over6 >> Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >>=20 >> Working Group Document NOT updated since IETF: >> Nov 26 draft-ietf-v6ops-dhcpv6-slaac-problem >> Dec 6 draft-ietf-v6ops-balanced-ipv6-security >> Jan 13 draft-ietf-v6ops-ipv6-roaming-analysis >> Feb 4 draft-ietf-v6ops-dc-ipv6 >> Feb 14 draft-ietf-v6ops-ula-usage-recommendations >>=20 >> Individual Submission NOT updated since IETF: >> Dec 3 draft-taylor-v6ops-fragdrop >> Jan 11 draft-osamu-v6ops-ipv4-literal-in-url >> Feb 13 draft-cui-v6ops-lte-lw4over6 >> Feb 14 draft-foo-v6ops-6rdmtu >> Feb 14 draft-liu-v6ops-dhcpv6-slaac-guidance >=20 --Apple-Mail=_D032D6E9-AE9F-4618-ABCF-A3965B3B35F1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTtWbrbjEdbHIsm0MRAtzTAJ9QsFoFKUCBaFuFNAnLJIlJeoy2OQCgzwDL bNzpzv1kwV8Qkc7PW65AJPg= =2cjW -----END PGP SIGNATURE----- --Apple-Mail=_D032D6E9-AE9F-4618-ABCF-A3965B3B35F1-- From nobody Thu Jul 3 09:33:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32A31B2AAF for ; Thu, 3 Jul 2014 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 mlaN6sSaQxLw for ; Thu, 3 Jul 2014 09:33:46 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667821B2800 for ; Thu, 3 Jul 2014 09:33:46 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so11748451wiv.2 for ; Thu, 03 Jul 2014 09:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=tXPElJycUMabIK0o8drtXb/wnBm0mHBPIIXxVazuMjE=; b=c/4ObokU3uXjsMMWgxaKZWaf5Szef3SL9FDftnLg7SNLWNaodMwQMNy5LGlTkcu8Ei A2XUgvF0E7eHhiHLxdlzxwc61bJWvujWmHAXFJVfKzeNgcA2l+Id83L09woxvYohA4Hx RVa3i1SdOFJTP6lCy8nLiTSyfZOMN0g8tdBrvQPy8BSuZB00QeaBUgVSGePk3AP++k2C WG6uRAynxAvACNOKD0/ohj8C/VrDM7v2H//7Wf3lBI5YP5cuocHUsTPFyO2rt5EEe4tG dyhvBKQIqfw5kbplsgpztI0j1mWUsYlEJpwMOMvcV2kNRLKrkaS+IBDZkI6acC4tNvyU ncsg== MIME-Version: 1.0 X-Received: by 10.194.89.138 with SMTP id bo10mr6181366wjb.22.1404405224995; Thu, 03 Jul 2014 09:33:44 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.63.211 with HTTP; Thu, 3 Jul 2014 09:33:44 -0700 (PDT) In-Reply-To: <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com> References: <43AE4B9F-206F-4969-81B8-AE003DC9DF4C@cisco.com> <8392F9BAC6AD5F47920216A6D7853F7E1D62B8CF@BPXM02GP.gisp.nec.co.jp> <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com> Date: Thu, 3 Jul 2014 09:33:44 -0700 X-Google-Sender-Auth: 9opwsb0oI2Q386FQZKWskBZxtew Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Zoj_wrlYSeJNUwNiKAKrLWBfCNQ Cc: V6 Ops List , "Ata, Shingo \(ata@info.eng.osaka-cu.ac.jp\)" Subject: Re: [v6ops] Planning for IETF #90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:33:48 -0000 At Thu, 3 Jul 2014 14:21:32 +0000, "Fred Baker (fred)" wrote: > > v6ops: > > Kitamura-san has posted draft-kitamura-ipv6-zoneid-free, and would like o= perational views on it. He has also requested agenda time at IETF 90. I sus= pect it may be more suited for 6man, but 6man isn=E2=80=99t meeting. Would = you kindly take a look and comment? > > If there is operational interest, we can give him a slot. FWIW, there was a discussion at 6man on a previous version of the draft: http://www.ietf.org/mail-archive/web/ipv6/current/msg19286.html I gave my own comments in that thread. I've not read the 03 version, and in any case I wouldn't be able to make a useful comment on whether it has operational interest as I'm not a professional operator. -- JINMEI, Tatuya From nobody Thu Jul 3 22:43:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537461B2BDB for ; Thu, 3 Jul 2014 22:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Jr3Ummt-O_Sp for ; Thu, 3 Jul 2014 22:43:51 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 26B061B2BE1 for ; Thu, 3 Jul 2014 22:43:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id ED19A871515; Fri, 4 Jul 2014 07:43:49 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dcV80Jji7W5; Fri, 4 Jul 2014 07:43:49 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:58e3:ef97:6438:9173]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id A45B3870047; Fri, 4 Jul 2014 07:43:49 +0200 (CEST) Message-ID: <53B63F01.1060401@globis.net> Date: Fri, 04 Jul 2014 07:43:29 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <43AE4B9F-206F-4969-81B8-AE003DC9DF4C@cisco.com> <8392F9BAC6AD5F47920216A6D7853F7E1D62B8CF@BPXM02GP.gisp.nec.co.jp> <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com> In-Reply-To: <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pxNSN8CCrDk81l55n_lOdOiavuA Cc: V6 Ops List , "Ata, Shingo \(ata@info.eng.osaka-cu.ac.jp\)" Subject: Re: [v6ops] Planning for IETF #90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 05:43:53 -0000 Fred Baker (fred) wrote: > v6ops: > > Kitamura-san has posted draft-kitamura-ipv6-zoneid-free, and would like operational views on it. He has also requested agenda time at IETF 90. I suspect it may be more suited for 6man, but 6man isn’t meeting. Would you kindly take a look and comment? > > If there is operational interest, we can give him a slot. > > Fred > > On Jul 3, 2014, at 1:47 AM, Hiroshi Kitamura wrote: >> Dear co-chairs of v6ops WG, >> >> We have submitted a I-D: >> "Free from Using Zone Identifier for IPv6 Link-Local Address" >> >> >> I quote the I-D Announce mail at the end of this mail. >> >> This idea "Zone-ID Free" is simple and harmless to the current system. >> We think this idea helps many people who face problems on Zone-ID. >> >> So, could you give us a presentation time at 90th Toronto meeting, please? >> >> >> - title and file name of the draft >> >> "Free from Using Zone Identifier for IPv6 Link-Local Address" >> >> >> - speakers name and email >> >> Hiroshi KITAMURA >> kitamura@da.jp.nec.com >> >> - how much time >> >> 10 min. >> >> Best Regards, >> Hiroshi >> >> >>> -----Original Message----- >>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >>> Sent: Wednesday, July 02, 2014 12:17 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-kitamura-ipv6-zoneid-free-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Free from Using Zone Identifier for IPv6 Link-Local Address >>> Authors : Hiroshi Kitamura >>> Shingo Ata >>> Masayuki Murata >>> Filename : draft-kitamura-ipv6-zoneid-free-03.txt >>> Pages : 17 >>> Date : 2014-07-01 >>> >>> Abstract: >>> This document describes "Zone-ID Free" functions that make end >>> users free from using zone identifiers (Zone-ID) for IPv6 link- >>> local addresses. >>> >>> When users deal with IPv6 link-local addresses, it is thought that >>> it is mandatory thing to specify accompanied Zone-IDs. For end >>> users, however, it is troublesome and nuisance thing to do it. >>> Because it is very hard for normal end users to find appropriate >>> Zone-IDs for this purpose. >>> >>> From another viewpoint, the usage of IPv6 link-local addresses >>> accompanied with Zone-IDs is quite different from the traditional >>> usage of global addresses. Therefore many problems related with >>> Zone-ID are caused and new specifications are required to fix these >>> problems. >>> >>> This document explores and describes how "Zone-ID Free" functions >>> work and how end users are released from using Zone-IDs when they >>> deal with IPv6 link-local addresses. >>> >>> The "Zone-ID Free" functions are upper compatible with the current >>> usages of dealing with IPv6 link-local addresses and harmless to >>> the existing communications. >>> >>> In order to obtain appropriate Zone-ID information, a new >>> technology "Zone-ID Learning" that issues multiple probes is >>> introduced. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-kitamura-ipv6-zoneid-free/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-kitamura-ipv6-zoneid-free-03 >> >> >> >> >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) >>> Sent: Thursday, May 22, 2014 4:43 AM >>> To: v6ops >>> Subject: [v6ops] Planning for IETF #90 >>> >>> IETF #90 is two months away, and we have about six weeks to get drafts updated or new drafts filed. This is a heads-up. >>> My rule for putting drafts on the agenda is that they are file or updated since the last IETF meeting and have had supportive >>> working group commentary on the list. Filing at the last instant generally doesn’t help with folks’ commentary - you want >>> to give them some time to read and think. So, filing drafts or making updates in June is recommended. >>> >>> Current draft status: >>> >>> IESG: >>> Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 >>> Mar 10 draft-ietf-v6ops-nat64-experience >>> Apr 1 draft-ietf-v6ops-64share >>> >>> Exiting WGLC; on its way to IESG: >>> May 19 draft-ietf-v6ops-clatip >>> >>> Working Group Document updated since IETF: >>> Mar 6 draft-ietf-v6ops-design-choices >>> Mar 11 draft-ietf-v6ops-mobile-device-profile >>> >>> Individual Submission updated since IETF: >>> Mar 4 draft-cui-v6ops-lte-lw4over6 >>> Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >>> >>> Working Group Document NOT updated since IETF: >>> Nov 26 draft-ietf-v6ops-dhcpv6-slaac-problem >>> Dec 6 draft-ietf-v6ops-balanced-ipv6-security >>> Jan 13 draft-ietf-v6ops-ipv6-roaming-analysis >>> Feb 4 draft-ietf-v6ops-dc-ipv6 >>> Feb 14 draft-ietf-v6ops-ula-usage-recommendations >>> >>> Individual Submission NOT updated since IETF: >>> Dec 3 draft-taylor-v6ops-fragdrop >>> Jan 11 draft-osamu-v6ops-ipv4-literal-in-url >>> Feb 13 draft-cui-v6ops-lte-lw4over6 >>> Feb 14 draft-foo-v6ops-6rdmtu >>> Feb 14 draft-liu-v6ops-dhcpv6-slaac-guidance > I recognize the issues detailed in this draft and feel that it is well written. 2 comments: 1) IMHO The security considerations are incomplete. Zone-ID free operations appears to assume security equivalence and operational equivalence between all interfaces on a device. two cases come to mind for the probes created in Section 4.2. i) ping6 on a node with an IPv6 interface to a telco e.g. LTE may incur significant charges, especially when roaming ii) users definitely don't want security equivalence in firewall nodes or other devices that enforce network security zoning 2) quote "When receiving Link-Local packets, there are no difficulties. Zone-ID (interface) is easily and naturally identified from interface that is used by received packets." The assumption is made that identifying the zone-ID of inbound traffic is trivial (as it can be identified by the arrival interface) IMHO That is very much implementation dependent whether the physical arrival interface is preserved to upper layers. Where is it defined that a node should enforce that the arrival interface of a link-link packet is preserved (and replies should only be sent on that same interface)? Is there's a potential security / operational consideration in that a link local source address could be spoofed from another interface, and replies would be sent out via a different interface, violating the fact that a link-local address should be local to a link? Maybe it should be made clearer that ND probes (section 4.2) should only be sent when initiating new outbound communication from this node, and not when replying to inbound queries? And also recommend that nodes should enforce tying a link-local source address to a physical interface? Thank you. -- Regards, RayH From nobody Fri Jul 4 01:02:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF731A01AC; Fri, 4 Jul 2014 01:02:12 -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] autolearn=ham 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 sgWeMThbD4ea; Fri, 4 Jul 2014 01:02:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7EB1B2C59; Fri, 4 Jul 2014 01:02:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704080210.16111.63557.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 01:02:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/q_bx24wRUBbnnR5M7CYZEQ8b0bQ Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:02:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Considerations of Using Unique Local Addresses Authors : Bing Liu Sheng Jiang Filename : draft-ietf-v6ops-ula-usage-recommendations-03.txt Pages : 16 Date : 2014-07-04 Abstract: This document provides considerations of how to use ULAs. It analyzes ULA usage scenarios and considers some use cases of ULA addresses as helpful. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-recommendations-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 Fri Jul 4 01:16:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA20E1B2C6C for ; Fri, 4 Jul 2014 01:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Fqm6ntJJSXlM for ; Fri, 4 Jul 2014 01:16:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE28D1B2C76 for ; Fri, 4 Jul 2014 01:16:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU10035; Fri, 04 Jul 2014 08:16:47 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 09:16:46 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 16:16:43 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: draft-ULA-03-//FW: New Version Notification for draft-ietf-v6ops-ula-usage-recommendations-03.txt Thread-Index: AQHPl2BJyQxVeIWiOEuQnr8MMzAOgA== Date: Fri, 4 Jul 2014 08:16:42 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EF326@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mwM6Vx8xpveNMAoDzA0_iHWbztU Subject: [v6ops] draft-ULA-03-//FW: New Version Notification for draft-ietf-v6ops-ula-usage-recommendations-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:16:57 -0000 SGkgYWxsLA0KDQpXZSd2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0K QmFzZWQgb24gcmVjZW50IG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uLCB0aGUgcmV2aXNpb25zIG1h aW5seSBpbmNsdWRlOg0KMS4gQ2hhbmdlZCB0aGUga2V5IHdvcmRzICJSZWNvbW1lbmRhdGlvbiIg Ikd1aWRlbGluZXMiIGludG8gIkNvbnNpZGVyYXRpb25zIiBib3RoIGluIHRoZSB0aXRsZSBhbmQg dGhlIG1haW4gYm9keS4gDQoyLiBSZXZpc2VkIGlzb2xhdGVkIG5ldHdvcmsgZGlzY3Vzc2lvbiBp biBTZWN0aW9uIDQuMS4NCjMuIFJldmlzZWQgTkFUIHJlbGV2YW50IGRlc2NyaXB0aW9uIGluIFNl Y3Rpb24gNC4yDQo0LiBBZGRlZCBhIGJyaWVmIHJlZmVyZW5jZSB0byBzaXRlIGxvY2FsIGFkZHJl c3NlcyBpbiBJbnRyb2R1Y3Rpb24uDQo1LiBBZGRlZCBzb21lIGRpc2N1c3Npb24gb2YgVUxBIGRl ZmF1bHQgcm91dGluZyBpbiBTZWN0aW9uIDQuMi4yICJPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9u cyINCjYuIEFkZGVkIGEgbmV3IFNlY3Rpb24gMiAiUmVxdWlyZW1lbnRzIExhbmd1YWdlIg0KNy4g T3RoZXIgd29yZGluZyByZXZpc2lvbiwgaW5jbHVkaW5nIHVwZGF0aW5nIHRoZSByZWZlcmVuY2Vz DQoNClRoZSBhdXRob3JzIGJlbGlldmUgdGhpcyB2ZXJzaW9uIGhhcyBjb3ZlcmVkIHRoZSBtYWpv ciBhcmd1bWVudHMuIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gaXQuDQpNYW55IHRoYW5r cyENCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA0OjAyIFBNDQpUbzogTGl1Ymlu ZyAoTGVvKTsgTGl1YmluZyAoTGVvKTsgU2hlbmcgSmlhbmc7IFNoZW5nIEppYW5nDQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdl LXJlY29tbWVuZGF0aW9ucy0wMy50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt aWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zLTAzLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRh dGlvbnMNClJldmlzaW9uOgkwMw0KVGl0bGU6CQlDb25zaWRlcmF0aW9ucyBvZiBVc2luZyBVbmlx dWUgTG9jYWwgQWRkcmVzc2VzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA3LTA0DQpHcm91cDoJCXY2 b3BzDQpQYWdlczoJCTE2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zLTAz LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aW9ucy8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1y ZWNvbW1lbmRhdGlvbnMtMDMNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMtMDMN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGNvbnNpZGVyYXRpb25zIG9m IGhvdyB0byB1c2UgVUxBcy4gIEl0DQogICBhbmFseXplcyBVTEEgdXNhZ2Ugc2NlbmFyaW9zIGFu ZCBjb25zaWRlcnMgc29tZSB1c2UgY2FzZXMgb2YgVUxBDQogICBhZGRyZXNzZXMgYXMgaGVscGZ1 bC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jul 4 02:59:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2F91B2CB2; Fri, 4 Jul 2014 02:59: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] autolearn=ham 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 4lnupiTw8_bI; Fri, 4 Jul 2014 02:59:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF621B2CBE; Fri, 4 Jul 2014 02:59:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704095919.7420.94584.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 02:59:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LsgZCa5DO4ip-iEGkcVrl8HUtLg Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:59:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Roaming Behavior Analysis Authors : Gang Chen Hui Deng Dave Michaud Jouni Korhonen Mohamed Boucadair Vizdal Ales Filename : draft-ietf-v6ops-ipv6-roaming-analysis-01.txt Pages : 14 Date : 2014-07-04 Abstract: This document identifies a set of failure cases encountered by an IPv6-enabled IPv6 customers in roaming scenarios. The investigations on those failed cases reveal the causes in order to notice improper configurations, equipment's incomplete functions or inconsistent IPv6 introduction strategy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-01 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 Jul 4 09:24:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885381B2D8A for ; Fri, 4 Jul 2014 09:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 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, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham 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 xj0v68-t7_pP for ; Fri, 4 Jul 2014 09:24:40 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3B81B2D9C for ; Fri, 4 Jul 2014 09:24:39 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s64GOWhT005422 for ; Fri, 4 Jul 2014 17:24:32 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s64GOWhT005422 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1404491073; bh=YXGTZ1qE6B4ebPuXXuexKI5LDjE=; h=From:Subject:Date:References:To:Mime-Version; b=0jspbfRLeZ0sBIpTMqxcSzvUt3xgXQC4gBK+NQ3t9Ipi13bLvt/I0LXppuxkapW+B LEkR1BIKnMgoQdwj4oFwDAO5pKPqnoe+oEk44+kO0emNxgjZhEgW4V14x9/8Sq0Q0r kyX89dNh896M6ew8GyqG+CrOn744ncmfKOHghr2o= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q63HOW0546005240Vu ret-id none; Fri, 04 Jul 2014 17:24:32 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s64GOW0H032700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 Jul 2014 17:24:32 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_ECB8CF74-D88C-4F2A-BFF4-4F51D358E480" Date: Fri, 4 Jul 2014 17:24:33 +0100 References: <20140704131707.3952.10822.idtracker@ietfa.amsl.com> <2A140777-ACCF-4995-B70E-7E88741EF570@ecs.soton.ac.uk> To: v6ops WG Message-ID: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q63HOW054600524000; tid=q63HOW0546005240Vu; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s64GOWhT005422 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0vek3GAHItoiApX_BkFY0p26hYk Subject: [v6ops] Fwd: I-D Action: draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:24:42 -0000 --Apple-Mail=_ECB8CF74-D88C-4F2A-BFF4-4F51D358E480 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Just a quick note to explain this short draft. If there is interest = we=92d be happy to present for 5-10 mins in Toronto. We had a strange issue with ND management tools on our vendor=92s = wireless LAN controller, and as a result it was sending three copies of = certain ND messages in very quick succession. On Mac OS X, this was = triggered a positive DAD event, which meant OS X would deprecate the = tentative address, and IPv6 would be disabled. Certain other OSes continued to configure the interface successfully = though, not considering the messages a DAD event. Which led to a = confusing situation for the administrator to debug. There=92s probably a couple of resulting issues here: 1) There is different behaviour in response to triplicates of certain ND = messages on different OSes. Is the preferred behaviour what the RFC = says? We should certainly try to make the behaviour more predictable = (even if the underlying cause is not a common one). 2) Is there a new DAD attack here beyond the classic =93No, I already = have that address, you can=92t have it=94 one? You could sniff for ND = messages and generate duplicates to prevent (at least an OS X device) = from configuring IPv6 successfully. The rapid duplicates might not be = looked for by existing tools that look for the classic DAD attack in = action. Tim Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt > Date: 4 July 2014 14:17:07 BST > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : DAD And Packet Triplication > Authors : Andrew Yourtchenko > Tim Chown > Seb Rupik > Filename : = draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt > Pages : 4 > Date : 2014-07-04 >=20 > Abstract: > This draft captures the observation of IPv6 Duplicate Address > Detection behavior in the case of excessive packet replication (3x), > the latter caused by by a misbehaving device in the network. Also = it > compares the operation of IPv6 vs. IPv4 as a result. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-yourtchenko-chown-rupik-v6ops-dad-3= x/ >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-yourtchenko-chown-rupik-v6ops-dad-3x-00 --Apple-Mail=_ECB8CF74-D88C-4F2A-BFF4-4F51D358E480 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

Just a quick note to explain = this short draft.  If there is interest we=92d be happy to present = for 5-10 mins in Toronto.

We had a strange = issue with ND management tools on our vendor=92s wireless LAN = controller, and as a result it was sending three copies of certain ND = messages in very quick succession. On Mac OS X, this was triggered a = positive DAD event, which meant OS X would deprecate the tentative = address, and IPv6 would be disabled.

Certain = other OSes continued to configure the interface successfully though, not = considering the messages a DAD event. Which led to a confusing situation = for the administrator to debug.

There=92s = probably a couple of resulting issues here:

1) = There is different behaviour in response to triplicates of certain ND = messages on different OSes. Is the preferred behaviour what the RFC = says? We should certainly try to make the behaviour more predictable = (even if the underlying cause is not a common = one).

2) Is there a new DAD attack here beyond = the classic =93No, I already have that address, you can=92t have it=94 = one?  You could sniff for ND messages and generate duplicates to = prevent (at least an OS X device) from configuring IPv6 successfully. =  The rapid duplicates might not be looked for by existing tools = that look for the classic DAD attack in = action.

Tim

Begin forwarded message:

Subject: = I-D Action: = draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt
Date: 4 July 2014 14:17:07 = BST
Reply-To: internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.


=        Title =           : DAD And = Packet Triplication
=        Authors =         : Andrew Yourtchenko
=             &n= bsp;           &nbs= p;Tim Chown
=             &n= bsp;           &nbs= p;Seb Rupik
= Filename        : = draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt
Pages =           : 4
Date =            : = 2014-07-04

Abstract:
  This draft captures the = observation of IPv6 Duplicate Address
  Detection behavior = in the case of excessive packet replication (3x),
  the = latter caused by by a misbehaving device in the network.  Also = it
  compares the operation of IPv6 vs. IPv4 as a = result.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-yourtchenko-chown-rupik= -v6ops-dad-3x/

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-yourtchenko-chown-rupik-v6ops-dad-= 3x-00

= --Apple-Mail=_ECB8CF74-D88C-4F2A-BFF4-4F51D358E480-- From nobody Mon Jul 7 09:05:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9172B1A0340 for ; Mon, 7 Jul 2014 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 4gzmI1f2WSpZ for ; Mon, 7 Jul 2014 09:05:55 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B78B1A02FE for ; Mon, 7 Jul 2014 09:05:55 -0700 (PDT) Received: from mbp.local (31.66.208.web-pass.com [208.66.31.202] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s67G5sao028347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 7 Jul 2014 16:05:54 GMT (envelope-from joelja@bogus.com) Message-ID: <53BAC55D.1030404@bogus.com> Date: Mon, 07 Jul 2014 09:05:49 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: IPv6 Ops WG X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P7kpu1FxTvDcfuPjt5hk7DhiJKDmbf35g" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 07 Jul 2014 16:05:54 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-VbPMCPJBK_-rAO7yKsIOsJPmow Subject: [v6ops] Drafts lodged against the deadline. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:05:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P7kpu1FxTvDcfuPjt5hk7DhiJKDmbf35g Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, just a helpful reminder to folks who submitted documents right up against the submission deadline. It is incumbent on you the authors to draw our attention to those so that they may be discussed properly prior to the meeting itself and agenda time can be allocated or not as necessar= y. thanks joel --P7kpu1FxTvDcfuPjt5hk7DhiJKDmbf35g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO6xV0ACgkQ8AA1q7Z/VrItGgCghaPyuf0VSFJyfmCBzBKMrdM5 9HUAnieyUTwlQtc6z1MiPVJX9zgiWXeX =yNxa -----END PGP SIGNATURE----- --P7kpu1FxTvDcfuPjt5hk7DhiJKDmbf35g-- From nobody Mon Jul 7 09:47:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877E81A0376 for ; Mon, 7 Jul 2014 09:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 297MywRBBxJa for ; Mon, 7 Jul 2014 09:47:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D705F1A036F for ; Mon, 7 Jul 2014 09:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3782; q=dns/txt; s=iport; t=1404751663; x=1405961263; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=o+xJaPSGj0GkIs3AhKO+bVEkLocq0siO4nZX65w333k=; b=lv78ueIEY011E2v4dDE3c0rIxA9y3gEz9M5/My+/olrG6nY3MvAv9COn Wf4n2ynOw5eqqp2qJ1cbQJc7VU4APiyGK/p0L2FCECKlXwFeJtC7UG+Mo sFbSxmzaPdh81WmFFwjwcHXgDP4/BWVgTrd9i35CmK7xXAsh00beUD+A2 Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAPDNulOtJV2T/2dsb2JhbABagw6BLMY7AYEZFnWEAwEBAQMBfgsCAQhGMiUCBAESDogsCMojF44/D1uDLYEWBZIhgUOHEpQMg0OCMA X-IronPort-AV: E=Sophos;i="5.01,619,1400025600"; d="asc'?scan'208";a="338211502" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2014 16:47:43 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s67GlgM6031759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 16:47:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 11:47:41 -0500 From: "Fred Baker (fred)" To: joel jaeggli , IPv6 Ops WG Thread-Topic: [v6ops] Drafts lodged against the deadline. Thread-Index: AQHPmgMr0qvvbzS9e0OWWCsa57y5Og== Date: Mon, 7 Jul 2014 16:47:41 +0000 Message-ID: References: <53BAC55D.1030404@bogus.com> In-Reply-To: <53BAC55D.1030404@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.44] Content-Type: multipart/signed; boundary="Apple-Mail=_78916554-47EF-420F-A224-CC0E89E408D0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NEzk4mj4pg0s5NFsQfh30DVU04o Subject: Re: [v6ops] Drafts lodged against the deadline. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:47:44 -0000 --Apple-Mail=_78916554-47EF-420F-A224-CC0E89E408D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks, Joel. At this point, Lee and I have not decided what the agenda will contain. = Let me give you my current thoughts; list discussion and Lee=92s = viewpoint when we talk will be important here. On Jul 7, 2014, at 9:05 AM, joel jaeggli wrote: > Greetings, >=20 > just a helpful reminder to folks who submitted documents right up > against the submission deadline. It is incumbent on you the authors to > draw our attention to those so that they may be discussed properly = prior > to the meeting itself and agenda time can be allocated or not as = necessary. >=20 > thanks > joel The drafts break out this way: IESG: Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 Approved-announcement to be sent::Revised I-D Needed Jun 11 draft-ietf-v6ops-clatip Approved-announcement to be sent::Point Raised - writeup = needed Working Group Document updated since IETF 89: Mar 6 draft-ietf-v6ops-design-choices Mar 11 draft-ietf-v6ops-mobile-device-profile Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem Jul 4 draft-ietf-v6ops-ipv6-roaming-analysis Jul 4 draft-ietf-v6ops-ula-usage-recommendations Individual Submission updated since IETF 89: Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node Jul 1 draft-kitamura-ipv6-zoneid-free Jul 3 draft-jaeggli-v6ops-pmtud-ecmp-problem Jul 3 draft-liu-v6ops-running-multiple-prefixes Jul 3 draft-wang-v6ops-flow-label-refelction Jul 4 draft-sun-v6ops-xlat-multi Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x Working Group Document NOT updated since IETF 89: Feb 4 draft-ietf-v6ops-dc-ipv6 Individual Submission NOT updated since IETF 89: Jan 11 draft-osamu-v6ops-ipv4-literal-in-url Feb 13 draft-cui-v6ops-lte-lw4over6 Feb 14 draft-foo-v6ops-6rdmtu Feb 14 draft-liu-v6ops-dhcpv6-slaac-guidance To my way of thinking, draft-ietf-v6ops-design-choices (which was posted = just before the working group meeting in London) was discussed then, and = draft-ietf-v6ops-mobile-device-profile is still working out the last = call comments from last September. So among the working group drafts, = the ones on the table this time include = draft-ietf-v6ops-dhcpv6-slaac-problem, = draft-ietf-v6ops-ipv6-roaming-analysis, and = draft-ietf-v6ops-ula-usage-recommendations. Similarly, to my way of thinking, while = draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node is appealing, v6ops = comments raised concerns about the reliability of MLD (and MLD = implementations) in the context. That sounds like an issue for 6man, not = v6ops.=20 draft-kitamura-ipv6-zoneid-free and = draft-jaeggli-v6ops-pmtud-ecmp-problem have had supportive discussion on = the list, so they seem likely.=20 I=92m looking for list discussion of = draft-liu-v6ops-running-multiple-prefixes, = draft-wang-v6ops-flow-label-refelction, draft-sun-v6ops-xlat-multi, and = draft-yourtchenko-chown-rupik-v6ops-dad-3x. Opinions welcome. As always. --Apple-Mail=_78916554-47EF-420F-A224-CC0E89E408D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTus8tbjEdbHIsm0MRAkwNAJ9rt/qYNSlCNZ8z6xWNUoeiiAK9AwCgz+sC yfwa9kTxvFaY1riYmxwW4LM= =3QPc -----END PGP SIGNATURE----- --Apple-Mail=_78916554-47EF-420F-A224-CC0E89E408D0-- From nobody Mon Jul 7 09:57:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798E81A03C4 for ; Mon, 7 Jul 2014 09:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 mLfgOSAnGigM for ; Mon, 7 Jul 2014 09:57:42 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100571A0395 for ; Mon, 7 Jul 2014 09:57:41 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id il7so4232265vcb.13 for ; Mon, 07 Jul 2014 09:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MEBFd/8m0AWFkOYAWJL52h7MXhXu24jPu6RjndB757Q=; b=IeJT1pM3DamLFYefc6+3hM1DDJ7VeAct71nkttEZrUS2iXXtV9a0+ika6PzxvaprYK 1MqzyMQkGc40xQufJ1pSqFEMUH2nDu+8sYIwGN+lSMZeC05eyS+l844b24tLFHV+H8hG CPixQxtm1qPxDHcIWPD55SKNFC6pVWOhVGTJuuMFYFH3hQZpXtFQ2JMFDgOnBwlkjMw+ qoDDlKjz771FUkLCLrGR405PwVMpqjzH6GQe/zHychQcskrIgCJEs+QeIlWU/OTNI8y7 7bQTvIdFociMGoL2GbJ6AJaXmaa1jfQmoS3TKeCy2bsb4/ts7Q3I7U8t8WPyP6MCnxr6 PqUg== X-Received: by 10.58.29.16 with SMTP id f16mr29252011veh.23.1404752260817; Mon, 07 Jul 2014 09:57:40 -0700 (PDT) Received: from [192.168.0.100] ([186.95.113.251]) by mx.google.com with ESMTPSA id eo9sm62613464vdb.22.2014.07.07.09.57.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 09:57:40 -0700 (PDT) Message-ID: <53BA9235.1030405@gmail.com> Date: Mon, 07 Jul 2014 07:57:33 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <43AE4B9F-206F-4969-81B8-AE003DC9DF4C@cisco.com> <8392F9BAC6AD5F47920216A6D7853F7E1D62B8CF@BPXM02GP.gisp.nec.co.jp> <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com> In-Reply-To: <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ojzRtl7okZPn_x_zF_Jle1QJvkI Subject: Re: [v6ops] Planning for IETF #90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:57:43 -0000 Hi There, I believe in somehow this should have operational interest. As the abstract describes zone-id can confuse and cause problems to the end-user. Alejandro, El 7/3/2014 9:51 AM, Fred Baker (fred) escribi: > v6ops: > > Kitamura-san has posted draft-kitamura-ipv6-zoneid-free, and would > like operational views on it. He has also requested agenda time at > IETF 90. I suspect it may be more suited for 6man, but 6man isnt > meeting. Would you kindly take a look and comment? > > If there is operational interest, we can give him a slot. > > Fred > > On Jul 3, 2014, at 1:47 AM, Hiroshi Kitamura > wrote: >> Dear co-chairs of v6ops WG, >> >> We have submitted a I-D: "Free from Using Zone Identifier for >> IPv6 Link-Local Address" >> >> >> I quote the I-D Announce mail at the end of this mail. >> >> This idea "Zone-ID Free" is simple and harmless to the current >> system. We think this idea helps many people who face problems on >> Zone-ID. >> >> So, could you give us a presentation time at 90th Toronto >> meeting, please? >> >> >> - title and file name of the draft >> >> "Free from Using Zone Identifier for IPv6 Link-Local Address" >> >> >> - speakers name and email >> >> Hiroshi KITAMURA kitamura@da.jp.nec.com >> >> - how much time >> >> 10 min. >> >> Best Regards, Hiroshi >> >> >>> -----Original Message----- From: I-D-Announce >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org Sent: Wednesday, July 02, 2014 12:17 >>> PM To: i-d-announce@ietf.org Subject: I-D Action: >>> draft-kitamura-ipv6-zoneid-free-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> >>> >>> Title : Free from Using Zone Identifier for IPv6 >>> Link-Local Address Authors : Hiroshi Kitamura Shingo >>> Ata Masayuki Murata Filename : >>> draft-kitamura-ipv6-zoneid-free-03.txt Pages : 17 >>> Date : 2014-07-01 >>> >>> Abstract: This document describes "Zone-ID Free" functions that >>> make end users free from using zone identifiers (Zone-ID) for >>> IPv6 link- local addresses. >>> >>> When users deal with IPv6 link-local addresses, it is thought >>> that it is mandatory thing to specify accompanied Zone-IDs. For >>> end users, however, it is troublesome and nuisance thing to do >>> it. Because it is very hard for normal end users to find >>> appropriate Zone-IDs for this purpose. >>> >>> From another viewpoint, the usage of IPv6 link-local addresses >>> accompanied with Zone-IDs is quite different from the >>> traditional usage of global addresses. Therefore many problems >>> related with Zone-ID are caused and new specifications are >>> required to fix these problems. >>> >>> This document explores and describes how "Zone-ID Free" >>> functions work and how end users are released from using >>> Zone-IDs when they deal with IPv6 link-local addresses. >>> >>> The "Zone-ID Free" functions are upper compatible with the >>> current usages of dealing with IPv6 link-local addresses and >>> harmless to the existing communications. >>> >>> In order to obtain appropriate Zone-ID information, a new >>> technology "Zone-ID Learning" that issues multiple probes is >>> introduced. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-kitamura-ipv6-zoneid-free/ >>> >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-kitamura-ipv6-zoneid-free-03 >> >> >> >> >> >> >>> -----Original Message----- From: v6ops >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) >>> Sent: Thursday, May 22, 2014 4:43 AM To: v6ops Subject: [v6ops] >>> Planning for IETF #90 >>> >>> IETF #90 is two months away, and we have about six weeks to get >>> drafts updated or new drafts filed. This is a heads-up. My rule >>> for putting drafts on the agenda is that they are file or >>> updated since the last IETF meeting and have had supportive >>> working group commentary on the list. Filing at the last >>> instant generally doesnt help with folks commentary - you >>> want to give them some time to read and think. So, filing >>> drafts or making updates in June is recommended. >>> >>> Current draft status: >>> >>> IESG: Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 Mar >>> 10 draft-ietf-v6ops-nat64-experience Apr 1 >>> draft-ietf-v6ops-64share >>> >>> Exiting WGLC; on its way to IESG: May 19 >>> draft-ietf-v6ops-clatip >>> >>> Working Group Document updated since IETF: Mar 6 >>> draft-ietf-v6ops-design-choices Mar 11 >>> draft-ietf-v6ops-mobile-device-profile >>> >>> Individual Submission updated since IETF: Mar 4 >>> draft-cui-v6ops-lte-lw4over6 Apr 7 >>> draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >>> >>> Working Group Document NOT updated since IETF: Nov 26 >>> draft-ietf-v6ops-dhcpv6-slaac-problem Dec 6 >>> draft-ietf-v6ops-balanced-ipv6-security Jan 13 >>> draft-ietf-v6ops-ipv6-roaming-analysis Feb 4 >>> draft-ietf-v6ops-dc-ipv6 Feb 14 >>> draft-ietf-v6ops-ula-usage-recommendations >>> >>> Individual Submission NOT updated since IETF: Dec 3 >>> draft-taylor-v6ops-fragdrop Jan 11 >>> draft-osamu-v6ops-ipv4-literal-in-url Feb 13 >>> draft-cui-v6ops-lte-lw4over6 Feb 14 draft-foo-v6ops-6rdmtu Feb >>> 14 draft-liu-v6ops-dhcpv6-slaac-guidance >> > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jul 7 15:44:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E092F1B2974 for ; Mon, 7 Jul 2014 15:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 RIfH8haAW7Tq for ; Mon, 7 Jul 2014 15:44:26 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388CA1B2973 for ; Mon, 7 Jul 2014 15:44:25 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 20EA3E025F; Tue, 8 Jul 2014 00:44:22 +0200 (CEST) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 073ABE00AC; Tue, 8 Jul 2014 00:44:22 +0200 (CEST) Received: from ESTGVMSP221.EUROPE.telefonica.corp ([fe80::79b8:304b:ea62:691d]) by ESTGVMSP104.EUROPE.telefonica.corp ([fe80::71a8:9f8b:d6e6:8648%11]) with mapi id 14.03.0146.002; Tue, 8 Jul 2014 00:44:21 +0200 From: DIEGO LOPEZ GARCIA To: "Fred Baker (fred)" Thread-Topic: [v6ops] Drafts lodged against the deadline. Thread-Index: AQHPmf1sAliXmDcAFUC8Bg50rz2rrpuUsNOAgABjpgA= Date: Mon, 7 Jul 2014 22:44:21 +0000 Message-ID: <92E583FC-1BB4-457D-8B3D-01431719A806@telefonica.com> References: <53BAC55D.1030404@bogus.com> In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.92.4.9] Content-Type: multipart/alternative; boundary="_000_92E583FC1BB4457D8B3D01431719A806telefonicacom_" MIME-Version: 1.0 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wPGIDX4rpGui81T6DUbYn2u2n10 Cc: IPv6 Ops WG Subject: Re: [v6ops] Drafts lodged against the deadline. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:44:30 -0000 --_000_92E583FC1BB4457D8B3D01431719A806telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Regarding the status draft-ietf-v6ops-dc-ipv6 and given that we are still l= ooking for some additional direct operational experience, I think the best = we can do is skip any discussion on it for the coming meeting. If we cannot= gather this additional input before IETF91 I guess we'll have to let it ex= pire and fade out till that direct experience becomes available... Be goode, On 7 Jul 2014, at 18:47 , Fred Baker (fred) > wrote: Thanks, Joel. At this point, Lee and I have not decided what the agenda will contain. Let= me give you my current thoughts; list discussion and Lee=92s viewpoint whe= n we talk will be important here. On Jul 7, 2014, at 9:05 AM, joel jaeggli > wrote: Greetings, just a helpful reminder to folks who submitted documents right up against the submission deadline. It is incumbent on you the authors to draw our attention to those so that they may be discussed properly prior to the meeting itself and agenda time can be allocated or not as necessary. thanks joel The drafts break out this way: IESG: Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 Approved-announcement to be sent::Revised I-D Needed Jun 11 draft-ietf-v6ops-clatip Approved-announcement to be sent::Point Raised - writeup needed Working Group Document updated since IETF 89: Mar 6 draft-ietf-v6ops-design-choices Mar 11 draft-ietf-v6ops-mobile-device-profile Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem Jul 4 draft-ietf-v6ops-ipv6-roaming-analysis Jul 4 draft-ietf-v6ops-ula-usage-recommendations Individual Submission updated since IETF 89: Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node Jul 1 draft-kitamura-ipv6-zoneid-free Jul 3 draft-jaeggli-v6ops-pmtud-ecmp-problem Jul 3 draft-liu-v6ops-running-multiple-prefixes Jul 3 draft-wang-v6ops-flow-label-refelction Jul 4 draft-sun-v6ops-xlat-multi Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x Working Group Document NOT updated since IETF 89: Feb 4 draft-ietf-v6ops-dc-ipv6 Individual Submission NOT updated since IETF 89: Jan 11 draft-osamu-v6ops-ipv4-literal-in-url Feb 13 draft-cui-v6ops-lte-lw4over6 Feb 14 draft-foo-v6ops-6rdmtu Feb 14 draft-liu-v6ops-dhcpv6-slaac-guidance To my way of thinking, draft-ietf-v6ops-design-choices (which was posted ju= st before the working group meeting in London) was discussed then, and draf= t-ietf-v6ops-mobile-device-profile is still working out the last call comme= nts from last September. So among the working group drafts, the ones on the= table this time include draft-ietf-v6ops-dhcpv6-slaac-problem, draft-ietf-= v6ops-ipv6-roaming-analysis, and draft-ietf-v6ops-ula-usage-recommendations= . Similarly, to my way of thinking, while draft-smith-v6ops-mitigate-rtr-dos-= mld-slctd-node is appealing, v6ops comments raised concerns about the relia= bility of MLD (and MLD implementations) in the context. That sounds like an= issue for 6man, not v6ops. draft-kitamura-ipv6-zoneid-free and draft-jaeggli-v6ops-pmtud-ecmp-problem = have had supportive discussion on the list, so they seem likely. I=92m looking for list discussion of draft-liu-v6ops-running-multiple-prefi= xes, draft-wang-v6ops-flow-label-refelction, draft-sun-v6ops-xlat-multi, an= d draft-yourtchenko-chown-rupik-v6ops-dad-3x. Opinions welcome. As always. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_92E583FC1BB4457D8B3D01431719A806telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7D5D4CA199095E4590941EB72022DD4D@telefonica.com> Content-Transfer-Encoding: quoted-printable Hi,

Regarding the status draft-ietf-v6ops-dc-ipv6 and given that we are st= ill looking for some additional direct operational experience, I think the = best we can do is skip any discussion on it for the coming meeting. If we c= annot gather this additional input before IETF91 I guess we'll have to let it expire and fade out till that d= irect experience becomes available...

Be goode,

On 7 Jul 2014, at 18:47 , Fred Baker (fred) <fred@cisco.com> wrote:

Thanks, Joel.

At this point, Lee and I have not decided what the agenda will contain. Let= me give you my current thoughts; list discussion and Lee=92s viewpoint whe= n we talk will be important here.

On Jul 7, 2014, at 9:05 AM, joel jaeggli <joelja@bogus.com> wrote:

Greetings,

just a helpful reminder to folks who submitted documents right up
against the submission deadline. It is incumbent on you the authors to
draw our attention to those so that they may be discussed properly prior to the meeting itself and agenda time can be allocated or not as necessary.=

thanks
joel

The drafts break out this way:

IESG:

   Jan 12  draft-ietf-v6ops-enterprise-incremental-ipv6=
           Approved-= announcement to be sent::Revised I-D Needed
   Jun 11  draft-ietf-v6ops-clatip
           Approved-= announcement to be sent::Point Raised - writeup needed

Working Group Document updated since IETF 89:

   Mar  6  draft-ietf-v6ops-design-choices
   Mar 11  draft-ietf-v6ops-mobile-device-profile
   Jun 18  draft-ietf-v6ops-dhcpv6-slaac-problem
   Jul  4  draft-ietf-v6ops-ipv6-roaming-analysis<= br>    Jul  4  draft-ietf-v6ops-ula-usage-recommendati= ons

Individual Submission updated since IETF 89:

   Apr  7  draft-smith-v6ops-mitigate-rtr-dos-mld-= slctd-node
   Jul  1  draft-kitamura-ipv6-zoneid-free
   Jul  3  draft-jaeggli-v6ops-pmtud-ecmp-problem<= br>    Jul  3  draft-liu-v6ops-running-multiple-prefix= es
   Jul  3  draft-wang-v6ops-flow-label-refelction<= br>    Jul  4  draft-sun-v6ops-xlat-multi
   Jul  4  draft-yourtchenko-chown-rupik-v6ops-dad= -3x

Working Group Document NOT updated since IETF 89:

   Feb  4  draft-ietf-v6ops-dc-ipv6

Individual Submission NOT updated since IETF 89:

   Jan 11  draft-osamu-v6ops-ipv4-literal-in-url
   Feb 13  draft-cui-v6ops-lte-lw4over6
   Feb 14  draft-foo-v6ops-6rdmtu
   Feb 14  draft-liu-v6ops-dhcpv6-slaac-guidance

To my way of thinking, draft-ietf-v6ops-design-choices (which was posted ju= st before the working group meeting in London) was discussed then, and draf= t-ietf-v6ops-mobile-device-profile is still working out the last call comme= nts from last September. So among the working group drafts, the ones on the table this time include draft-ie= tf-v6ops-dhcpv6-slaac-problem, draft-ietf-v6ops-ipv6-roaming-analysis, and = draft-ietf-v6ops-ula-usage-recommendations.

Similarly, to my way of thinking, while draft-smith-v6ops-mitigate-rtr-dos-= mld-slctd-node is appealing, v6ops comments raised concerns about the relia= bility of MLD (and MLD implementations) in the context. That sounds like an= issue for 6man, not v6ops.

draft-kitamura-ipv6-zoneid-free and draft-jaeggli-v6ops-pmtud-ecmp-problem = have had supportive discussion on the list, so they seem likely.

I=92m looking for list discussion of draft-liu-v6ops-running-multiple-prefi= xes, draft-wang-v6ops-flow-label-refelction, draft-sun-v6ops-xlat-multi, an= d draft-yourtchenko-chown-rupik-v6ops-dad-3x.

Opinions welcome. As always.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_92E583FC1BB4457D8B3D01431719A806telefonicacom_-- From nobody Mon Jul 7 18:58:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3550C1B29E1 for ; Mon, 7 Jul 2014 18:58:19 -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, SPF_PASS=-0.001] autolearn=ham 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 AUozuZLoCcoF for ; Mon, 7 Jul 2014 18:58:17 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4B11B2996 for ; Mon, 7 Jul 2014 18:58:16 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id ij19so4749046vcb.23 for ; Mon, 07 Jul 2014 18:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=mrDVUykdJBHH73OggvPJKTakJTFh90bX+t2OILJtdaY=; b=Rflc6ZI+hROHjDCN8nan+gNvIKTE1XzVfFrK8CwF6WdexagIit91LtOJXkVw4kBD64 Nd0NEXoj/Z9IgM8Kza/jL0MTIqZpsTO2XXZITfDVFTtVC1qnKLS3S4P/wBLVaFL0fdpi qZK4qAuHOIlmW3c6kYWRUYci+w/BZA8QTFvlO4Q9RdDi4BLvzO6SxzV0d6ofHj83HMg3 lf3u+I5SIQKNgs8RFsmTkNxyqg3w8iu3FKtW4qS6jji36ik1nnyPEZXNG2rCCWVNpVaq fcfAY+8JpgZgJJPwxUYXlcvV6lBhae38cioedaTn4FYrD1Rv8pHwd/7QU7QGUKVPKzNa XszA== X-Received: by 10.52.252.226 with SMTP id zv2mr25923179vdc.19.1404784696155; Mon, 07 Jul 2014 18:58:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.130.137 with HTTP; Mon, 7 Jul 2014 18:57:36 -0700 (PDT) From: Qiong Date: Tue, 8 Jul 2014 09:57:36 +0800 Message-ID: To: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a1135ed22cce71704fda4ec6b Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/B7gGnFNxCTS2yQUD2fjF3MtUHOY Subject: [v6ops] Fw: New Version Notification for draft-sun-v6ops-xlat-multi-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 01:58:19 -0000 --001a1135ed22cce71704fda4ec6b Content-Type: text/plain; charset=UTF-8 Hi All, We submitted a new draft about deploying multiple PLATs in 464XLAT. Your comments are more than welcome. Thanks a lot! Best wishes Qiong *From:* internet-drafts *Date:* 2014-07-04 21:31 *To:* Qiong Sun ; Qiong Sun ; Zhirong Zhang ; Qin Zhao ; Qin Zhao ; Zhirong Zhang *Subject:* New Version Notification for draft-sun-v6ops-xlat-multi-00.txt A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt has been successfully submitted by Qiong Sun and posted to the IETF repository. Name: draft-sun-v6ops-xlat-multi Revision: 00 Title: Running Multiple PLATs in 464XLAT Document date: 2014-07-04 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-sun-v6ops-xlat-multi-00.txt Status: https://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/ Htmlized: http://tools.ietf.org/html/draft-sun-v6ops-xlat-multi-00 Abstract: The IPv6 transition has been an ongoing process throughout the world due to the exhaustion of the IPv4 address space. The 464XLAT[RFC6877] provides a solution with limited IPv4 connectivity across an IPv6-only network, and the android system (version 2.3 and above) has already implemented the 464XLAT[RFC6877] and the the Prefix discovery solution [RFC7050]. However, the current 464XLAT architecture can only deal with the scenario with single PLAT in the network. When operator deploys multiple PLATs with different Pref64 prefixes, 464XLAT cannot cope with multiple prefixes for different destination addresses. This document describes the architecture with multiple PLATs and also the deployment considerations. 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 --001a1135ed22cce71704fda4ec6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

We submitted a new draft about = deploying multiple PLATs in 464XLAT. Your comments are more than welcome. T= hanks a lot!

Best wishes
Qiong=C2=A0

=C2=A0
Date:=C2=A02014-07-04=C2=A021:31
Subject:=C2=A0New Version Notification for=20 draft-sun-v6ops-xlat-multi-00.txt
=C2=A0
A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.
=C2=A0
Name: draft-sun-v6ops-xlat-multi
Revision: 00
Title: Running Multiple PLATs in 464XLAT
Document date: 2014-07-04
Group: Individual Submission
Pages: 8
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 http://www.ietf.org/internet-drafts/draft-sun-v6ops-xlat-multi-00.tx= t
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 ht= tps://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 http:/= /tools.ietf.org/html/draft-sun-v6ops-xlat-multi-00
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0 The IPv6 transition has been an ongoing process throughou= t the=20 world
=C2=A0=C2=A0 due to the exhaustion of the IPv4 address space.=C2=A0 Th= e
=C2=A0=C2=A0 464XLAT[RFC6877] provides a solution with limited IPv4=20 connectivity
=C2=A0=C2=A0 across an IPv6-only network, and the android system (vers= ion 2.3=20 and
=C2=A0=C2=A0 above) has already implemented the 464XLAT[RFC6877] and t= he the
=C2=A0=C2=A0 Prefix discovery solution [RFC7050].=C2=A0 However, the c= urrent 464XLAT
=C2=A0=C2=A0 architecture can only deal with the scenario with single = PLAT in=20 the
=C2=A0=C2=A0 network.=C2=A0 When operator deploys multiple PLATs with = different=20 Pref64
=C2=A0=C2=A0 prefixes, 464XLAT cannot cope with multiple prefixes for = different
=C2=A0=C2=A0 destination addresses.
=C2=A0
=C2=A0=C2=A0 This document describes the architecture with multiple PL= ATs and=20 also
=C2=A0=C2=A0 the deployment considerations.
=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=20
=C2=A0
=C2=A0
Please note that it may take a couple of minutes from the time of=20 submission
until the htmlized version and diff are available at tools.ietf.org.
=C2=A0
The IETF Secretariat
=C2=A0
--001a1135ed22cce71704fda4ec6b-- From nobody Wed Jul 9 01:38:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F991A03B3 for ; Wed, 9 Jul 2014 01:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 1k0oxE9lTP5k for ; Wed, 9 Jul 2014 01:38:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B85C1A038A for ; Wed, 9 Jul 2014 01:38:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGY12157; Wed, 09 Jul 2014 08:38:21 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 09:38:20 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 16:38:14 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPm1EfCs1tJ+3fVEGmUhRkiSIjZA== Date: Wed, 9 Jul 2014 08:38:13 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xvc6EtKD7TvIzsNJEXARQsbHJVg Subject: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 08:38:25 -0000 Hi All, Please allow me post the below mentioned "ND table space shortage in big L2= networks" issue (which was documented in draft-liu-v6ops-running-multiple-= prefixes-01 as Section 3.2) in the mailing list as below.=20 In summary, the issue is that in Dual-Stack L2 networks, the hosts would co= st much more MAC table space in the switch than the IPv4-only hosts. Thus i= n big L2 networks, there probably comes the MAC table shortage problem. This issue was found in real deployment experience. The most straightforwar= d solution is to just increase the MAC table size. However, relevant hardwa= re resource such as TCAM is very expensive and high power consumption that = in some cost-sensitive scenarios it might not be a good solution.=20 So I was thinking whether this could be considered as an operational issue,= and whether there could be some operational mitigation approach. Your comments would be appreciated very much. "In some scenarios such as campus networks and enterprise networks, the "big L2 network" architecture is often used to reduce the cost and ease the management. In a big L2 network, a large amount of hosts (e.g. 10K users) are aggregated to the core at layer 2. The top-level core switch needs to record the MAC and IP addresses of all the hosts in the aggregation domain as entries in the ARP/ND table, so that incoming packets to the hosts could be forwarded directly by the line cards in a line speed. When the ARP/ND table is full, normally the network would not allow new hosts to access. Because in this situation, the switch need to instantly look up the destination through ARP/ND broadcast/multicast, thus the CPU needs to be involved in this processing. This would significantly cost the performance of the switch and packet loss might happen. According to current state of the art, the maximum amount of ARP/ND entries in a switch is normally under 16K (the high-end ones could reach to 64K, measured by per line card). In IPv4, each host only occupies one entry, so normally the table space is enough. However, when the network is in an IPv6 transition, the table would be in a significant shortage. In implementation, one IPv6 ND entry needs 2-4 times of an IPv4 ARP entry; and one IPv6-enabled host might configure 2-4 IPv6 addresses or even more. For example, an IPv6-enabled Window 7 host would have at least three IPv6 addresses (one link-local address, one permanent global address and one temporary global address) when it connects to an IPv6 network. Finally, a dual-stack network would cost 5-17 times table space than the IPv4 does, so that the table space shortage is likely to happen." Best regards, Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Liubing (Leo) > Sent: Thursday, July 03, 2014 3:49 PM > To: v6ops@ietf.org > Subject: [v6ops] Multiple IPv6 prefixes issues-//FW: New Version > Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt >=20 > Hi all, >=20 > We uploaded a new version of the draft. We once had some discussion on > this topic. > This new version clearly separated the scope from MIF. And there are lots= of > texts revision to make it pay more attention on operational consideration= s > and problems. >=20 > Particularly, there is a newly identified operational issue in real produ= ct > network as described in Section 3.2, the " ND table space shortage in big= L2 > networks", I'd like to hear comments from you on this specific issue. > Comments on other content are of course welcomed as well. >=20 > Best regards, > Bing >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, July 03, 2014 3:31 PM > To: Boyang; Sheng Jiang; Liubing (Leo); Sheng Jiang; Boyang; Liubing (Leo= ) > Subject: New Version Notification for > draft-liu-v6ops-running-multiple-prefixes-01.txt >=20 >=20 > A new version of I-D, draft-liu-v6ops-running-multiple-prefixes-01.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. >=20 > Name: draft-liu-v6ops-running-multiple-prefixes > Revision: 01 > Title: Running Multiple IPv6 Prefixes > Document date: 2014-07-03 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-liu-v6ops-running-multiple-pref= ixe > s-01.txt > Status: > https://datatracker.ietf.org/doc/draft-liu-v6ops-running-multiple-prefixe= s/ > Htmlized: > http://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-v6ops-running-multiple-prefi= xes-0 > 1 >=20 > Abstract: > This document discusses that multiple prefixes in one network/host > might be common in IPv6 deployment, and describes several typical > multiple prefixes use cases. Then some operational considerations and > current problems of running multiple prefixes are described. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 9 02:46:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9AC1A03CB for ; Wed, 9 Jul 2014 02:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 xA4xTewuM2Ow for ; Wed, 9 Jul 2014 02:46:48 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 4C4881A03D3 for ; Wed, 9 Jul 2014 02:46:46 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 084AB60300 for ; Wed, 9 Jul 2014 11:46:44 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B1283602A8 for ; Wed, 9 Jul 2014 11:46:43 +0200 (CEST) Received: (qmail 84417 invoked by uid 1007); 9 Jul 2014 11:46:43 +0200 Date: Wed, 9 Jul 2014 11:46:43 +0200 From: Gert Doering To: "Liubing \(Leo\)" Message-ID: <20140709094643.GA51793@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/548GyVxVsOH6dgQeeeo7RXR4xs4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:46:49 -0000 Hi, On Wed, Jul 09, 2014 at 08:38:13AM +0000, Liubing (Leo) wrote: > In summary, the issue is that in Dual-Stack L2 networks, the hosts > would cost much more MAC table space in the switch than the IPv4-only > hosts. Thus in big L2 networks, there probably comes the MAC table > shortage problem. Uh, what? I can see ND table overflows, but since when did hosts grew extra MAC addresses for IPv6? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard 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 Wed Jul 9 03:24:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EEB1A03E5 for ; Wed, 9 Jul 2014 03:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 Y5HOUTP0K3zd for ; Wed, 9 Jul 2014 03:24:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691BF1A03E1 for ; Wed, 9 Jul 2014 03:24:40 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s69AOWph042738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Jul 2014 10:24:33 GMT (envelope-from joelja@bogus.com) Message-ID: <53BD185B.7030808@bogus.com> Date: Wed, 09 Jul 2014 03:24:27 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Liubing (Leo)" , "v6ops@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HPqu4ubdShpDSkrjTBKoorGtrAnDhoUCb" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 09 Jul 2014 10:24:33 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5Ic9arvJxuke3RhD2LQL3TvERZg Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 10:24:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HPqu4ubdShpDSkrjTBKoorGtrAnDhoUCb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/9/14 1:38 AM, Liubing (Leo) wrote: > Hi All, > > Please allow me post the below mentioned "ND table space shortage in bi= g L2 networks" issue (which was documented in draft-liu-v6ops-running-mul= tiple-prefixes-01 as Section 3.2) in the mailing list as below.=20 > In summary, the issue is that in Dual-Stack L2 networks, the hosts woul= d cost much more MAC table space in the switch than the IPv4-only hosts. = Thus in big L2 networks, there probably comes the MAC table shortage prob= lem. As one of the contributors to rfc6583 I tend to be a believer that no hosts at all are required on a subnet to result in ND table exhaustion. With respect to the question of how much fib memory is required for l2 nexhops, that kinda falls into the design space, just as it does for example layer 3 routes. if you can't scale it to the level necessary then you adopt design that addresses those constraints. whether multiple prefix are in use in one vlan or multiple vlans makes very little differnce to a traditional l2 core, if the l2 networks are overlays then it may make a lot of difference because there may be no core per say that needs to carry these entries. I have some concern as product of direct experience about notion that particularly large L2 networks are actually good practice, ARMD for example kind of ran into trouble in this area. > > This issue was found in real deployment experience. The most straightfo= rward solution is to just increase the MAC table size. However, relevant = hardware resource such as TCAM is very expensive and high power consumpti= on that in some cost-sensitive scenarios it might not be a good solution.= =20 > So I was thinking whether this could be considered as an operational is= sue, and whether there could be some operational mitigation approach. > > Your comments would be appreciated very much. > > "In some scenarios such as campus networks and enterprise networks, > the "big L2 network" architecture is often used to reduce the cost > and ease the management. In a big L2 network, a large amount of host= s > (e.g. 10K users) are aggregated to the core at layer 2. > > The top-level core switch needs to record the MAC and IP addresses o= f > all the hosts in the aggregation domain as entries in the ARP/ND > table, so that incoming packets to the hosts could be forwarded > directly by the line cards in a line speed. When the ARP/ND table is= > full, normally the network would not allow new hosts to access. > Because in this situation, the switch need to instantly look up the > destination through ARP/ND broadcast/multicast, thus the CPU needs t= o > be involved in this processing. This would significantly cost the > performance of the switch and packet loss might happen. > > According to current state of the art, the maximum amount of ARP/ND > entries in a switch is normally under 16K (the high-end ones could > reach to 64K, measured by per line card). For the reasons above I don't think the actual number is very relevant except in the context of a particular design problem. but you're off about at least a factor of 4 of what a reasonably stout switch complex looks like. > In IPv4, each host only > occupies one entry, so normally the table space is enough. However, > when the network is in an IPv6 transition, the table would be in a > significant shortage. In implementation, one IPv6 ND entry needs 2-4= > times of an IPv4 ARP entry; and one IPv6-enabled host might configur= e > 2-4 IPv6 addresses or even more. For example, an IPv6-enabled Window= > 7 host would have at least three IPv6 addresses (one link-local > address, one permanent global address and one temporary global > address) when it connects to an IPv6 network. Finally, a dual-stack > network would cost 5-17 times table space than the IPv4 does, so tha= t > the table space shortage is likely to happen." > > > Best regards, > Bing > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Liubing (Leo)= >> Sent: Thursday, July 03, 2014 3:49 PM >> To: v6ops@ietf.org >> Subject: [v6ops] Multiple IPv6 prefixes issues-//FW: New Version >> Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt >> >> Hi all, >> >> We uploaded a new version of the draft. We once had some discussion on= >> this topic. >> This new version clearly separated the scope from MIF. And there are l= ots of >> texts revision to make it pay more attention on operational considerat= ions >> and problems. >> >> Particularly, there is a newly identified operational issue in real pr= oduct >> network as described in Section 3.2, the " ND table space shortage in = big L2 >> networks", I'd like to hear comments from you on this specific issue. >> Comments on other content are of course welcomed as well. >> >> Best regards, >> Bing >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, July 03, 2014 3:31 PM >> To: Boyang; Sheng Jiang; Liubing (Leo); Sheng Jiang; Boyang; Liubing (= Leo) >> Subject: New Version Notification for >> draft-liu-v6ops-running-multiple-prefixes-01.txt >> >> >> A new version of I-D, draft-liu-v6ops-running-multiple-prefixes-01.txt= >> has been successfully submitted by Bing Liu and posted to the IETF >> repository. >> >> Name: draft-liu-v6ops-running-multiple-prefixes >> Revision: 01 >> Title: Running Multiple IPv6 Prefixes >> Document date: 2014-07-03 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-liu-v6ops-running-multiple-p= refixe >> s-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-liu-v6ops-running-multiple-pref= ixes/ >> Htmlized: >> http://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes-0= 1 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-v6ops-running-multiple-pr= efixes-0 >> 1 >> >> Abstract: >> This document discusses that multiple prefixes in one network/host >> might be common in IPv6 deployment, and describes several typical >> multiple prefixes use cases. Then some operational considerations a= nd >> current problems of running multiple prefixes are described. >> >> >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --HPqu4ubdShpDSkrjTBKoorGtrAnDhoUCb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO9GFsACgkQ8AA1q7Z/VrLoxgCdEGDLrFDSkZQzQin+LEQE37Yx tAAAn1aFxcd/W+6plLxnWIUY4x1dhh0T =2cGU -----END PGP SIGNATURE----- --HPqu4ubdShpDSkrjTBKoorGtrAnDhoUCb-- From nobody Wed Jul 9 03:30:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8E41A03E1 for ; Wed, 9 Jul 2014 03:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 YunDy7zz6uEd for ; Wed, 9 Jul 2014 03:30:27 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B815D1A03D9 for ; Wed, 9 Jul 2014 03:30:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9C073A1; Wed, 9 Jul 2014 12:30:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404901825; bh=I6wgGYqefr/DEpEmvGLwUZI5tiMeztVx2xEsYxaBvX8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=T+9VrJFrMW+xSnN+Bn2MsWfN2LD17pgx2YBvaiQQAK8PW1ntIGtJFuBoQ7vNloAAB EHYi2CwKAhYiqV+cdx5fMGBtmx4wcn833tZB1/Vlmd8VugbR5YNKqyyo47fefgHbAj xlD/r2S40pyBYqKCkPllTFY4SUgSOlVCS8+9RmUs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9879F9F; Wed, 9 Jul 2014 12:30:25 +0200 (CEST) Date: Wed, 9 Jul 2014 12:30:25 +0200 (CEST) From: Mikael Abrahamsson To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1wI9F1YMXvEwp2YnUVwx6mMsHbc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 10:30:29 -0000 On Wed, 9 Jul 2014, Liubing (Leo) wrote: > This issue was found in real deployment experience. The most > straightforward solution is to just increase the MAC table size. > However, relevant hardware resource such as TCAM is very expensive and > high power consumption that in some cost-sensitive scenarios it might > not be a good solution. So I was thinking whether this could be > considered as an operational issue, and whether there could be some > operational mitigation approach. > > Your comments would be appreciated very much. > > "In some scenarios such as campus networks and enterprise networks, > the "big L2 network" architecture is often used to reduce the cost > and ease the management. In a big L2 network, a large amount of hosts > (e.g. 10K users) are aggregated to the core at layer 2. Yeah, this was a bad idea for IPv4, and it's a bad idea for IPv6. I propose making smaller L2 domains by means of L3 switches closer to the devices, and then do routing. This solves several issues when it comes to scalability, while it might be seen as causing problems in other aspects. I am a firm believer in creating a distributed L3 network and that large L2 domains cause problems. The issue you mentioned is just one of them... Only way I can imagine to mitigate this operationally without doing anything else, is to turn off SLACC and just use single DHCPv6_IA. You still use 3 times more space (2 IPv6 addresses and 1 IPv4 address) for dual stacked host than you do for a single stacked host, but that's hard to avoid. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 9 03:54:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3521A03EF for ; Wed, 9 Jul 2014 03:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 z-Oq2TKb_ezb for ; Wed, 9 Jul 2014 03:54:05 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 43EBB1A03ED for ; Wed, 9 Jul 2014 03:54:04 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A1CBA602EF for ; Wed, 9 Jul 2014 12:54:03 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6EDF7602C8 for ; Wed, 9 Jul 2014 12:54:03 +0200 (CEST) Received: (qmail 778 invoked by uid 1007); 9 Jul 2014 12:54:03 +0200 Resent-From: Gert Doering Resent-Date: Wed, 9 Jul 2014 12:54:03 +0200 Resent-Message-ID: <20140709105403.GF51793@Space.Net> Resent-To: v6ops@ietf.org Received: (qmail 618 invoked from network); 9 Jul 2014 12:53:28 +0200 Received: from mobil.space.net (2001:608:2:81::67) by moebius3.space.net with SMTP; 9 Jul 2014 12:53:28 +0200 X-Original-To: gert@space.net Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0DF4960325 for ; Wed, 9 Jul 2014 12:53:28 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C138560344 for ; Wed, 9 Jul 2014 12:53:27 +0200 (CEST) Received: (qmail 612 invoked by uid 1007); 9 Jul 2014 12:53:27 +0200 Date: Wed, 9 Jul 2014 12:53:27 +0200 From: Gert Doering To: "Liubing \(Leo\)" Message-ID: <20140709105327.GE51793@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <20140709094643.GA51793@Space.Net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1CD4@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tx2XG0Hc/yoUCMV6" Content-Disposition: inline In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1CD4@nkgeml506-mbx.china.huawei.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lx68U50odD5ntLO59fFN85JSfN0 Cc: v6ops@ops.ietf.org Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 10:54:07 -0000 --Tx2XG0Hc/yoUCMV6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 09, 2014 at 10:02:51AM +0000, Liubing (Leo) wrote: > > -----Original Message----- > > From: Gert Doering [mailto:gert@space.net] > >=20 > > On Wed, Jul 09, 2014 at 08:38:13AM +0000, Liubing (Leo) wrote: > > > In summary, the issue is that in Dual-Stack L2 networks, the hosts > > > would cost much more MAC table space in the switch than the IPv4-only > > > hosts. Thus in big L2 networks, there probably comes the MAC table > > > shortage problem. > >=20 > > Uh, what? I can see ND table overflows, but since when did hosts grew > > extra MAC addresses for IPv6? >=20 > The scenarios is regarding L3 switches, which record "IP-MAC" pairs.=20 In that case, please make this clear: this is about ND/ARP cache, not=20 about "MAC table space". The latter has a very well defined meaning, and is very much independent from IPv4/IPv6. > So, since hosts have multiple IPv6 addresses, they'll consume multiple "I= P-MAC" records in the L3 switch. And one IPv6 record would cost 2-4 times t= han the IPv4 record. Thus, in dual-stack scenario, the MAC table consumptio= n is much higher than the IPv4 scenario. This is *not* "the MAC table". Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Tx2XG0Hc/yoUCMV6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU70fJ99WwGXkzn/FAQKANRAAqKEiguhSIH87+XvkC/Fp9w2xsAzhke2a poluZPIGPwaVxUXSMJIUqizL2gKnWveDk8x/dkIMNFu+0dSfPEmrHEeZ0etCdmap NoXPyPyykBcqHyGNHtuhd/hNkmQ7lcJPe0+CBSRiSE+1zMsmArTf6QsbFjgtziuW GPdk7KtATxmboGY8Qx995BZSRoAqxlJp3ea3+uv09zOpQvyJRFj2LuPD14Qg5uQs 7gtctnzxGfyt65rY2bo1LribWLdjmlHKDuz7uZ3p59g4nCH92XcnJXs+b4++wCDG 21UDd6PK3HalpaBCj4dtGUMe62oyNrc5Kz1eI6BzzRfTegn8quL/JURJHdLSuxew hXlDRZya6oaL6ITajtYtOaXULw3K9GYOaMotDThemZd2PQfX18o9UIYRBx8HAVOB 0/cKj4Exr4xgwkiqpUjcigRcLwa8Hjd5r/3bWuc5/sOsrZb6caj2C7ZhULQpa4CF 8vmqdZgyHMSIgO9FlCY2kadRQNI/l+5ZRPplMcTgGsbby0aT+EZdF5lUNgekJNbB uJwqHce+c4+lyLfwZVkkZzrmSW60Td0TTU7T2KlstmJKEwtmiouzy17UIBtJ5oyV h8PEwNwhRWf4TJyamDTCZ9HZBQcknXxdy+yos7zxJVQjlFMLzSMdHUR96NQfEuIe agJ6BZwhpTM= =XA7C -----END PGP SIGNATURE----- --Tx2XG0Hc/yoUCMV6-- From nobody Wed Jul 9 05:50:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88EE1A0601 for ; Wed, 9 Jul 2014 05:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 kS_6HY_Q81p2 for ; Wed, 9 Jul 2014 05:50:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854F11A061D for ; Wed, 9 Jul 2014 05:50:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X4rKA-0004VI-7X; Wed, 09 Jul 2014 12:50:14 +0000 Date: Wed, 09 Jul 2014 21:50:13 +0900 Message-ID: From: Randy Bush To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rn4_KZvvSSfNGiBlweuZMftsVM4 Cc: V6 Ops List Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:50:16 -0000 > "In some scenarios such as campus networks and enterprise networks, > the "big L2 network" architecture is often used to reduce the cost > and ease the management. operational, not vendor, experience is that "big l2 network" architecture increases cost, management, and many kinds of pain. randy From nobody Wed Jul 9 07:29:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5441A0AC5 for ; Wed, 9 Jul 2014 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 1ZkafCRZf-GV for ; Wed, 9 Jul 2014 07:29:23 -0700 (PDT) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6401A0ABD for ; Wed, 9 Jul 2014 07:29:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N8G00F0087XU600@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 09 Jul 2014 09:29:22 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.9.141518, SenderIP=0.0.0.0 Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8G0030388WRI30@smtpauth3.wiscmail.wisc.edu>; Wed, 09 Jul 2014 09:29:21 -0500 (CDT) Date: Wed, 09 Jul 2014 09:29:20 -0500 From: "Dale W. Carder" To: "Liubing (Leo)" Message-id: <20140709142919.GG11589@ricotta.doit.wisc.edu> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> In-reply-to: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/S6G0EjPXRHyJ46nq0sAMJJOd2Zk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:29:25 -0000 Thus spake Liubing (Leo) (leo.liubing@huawei.com) on Wed, Jul 09, 2014 at 08:38:13AM +0000: > > "In some scenarios such as campus networks and enterprise networks, > the "big L2 network" architecture is often used to reduce the cost > and ease the management. In a big L2 network, a large amount of hosts > (e.g. 10K users) are aggregated to the core at layer 2. >From our experience "big L2 network" does not reduce cost nor ease management. We have found quite the opposite. (We are now getting close to hitting the 128k mac addr limit on one of our switches... ). Any large scale design has to deal with FIB scale issues. A recommended approach is to "divide & conquer" by pushing the L2/L3 boundary towards the edge. Otherwise you must buy things with bigger FIB's, and that is not a cost saving endeavor. Dale From nobody Wed Jul 9 07:51:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2791A05C3 for ; Wed, 9 Jul 2014 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nAmbEL9fz0Pn for ; Wed, 9 Jul 2014 07:51:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9AD1A0197 for ; Wed, 9 Jul 2014 07:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2557; q=dns/txt; s=iport; t=1404917515; x=1406127115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cWm+K6Bd81FrG6W8EhUTZ+CvuRODS/cLOjKTKaQDW/c=; b=Gx9S5ZGTf+psmC2hNKxjuHGrTfQ4tChFUntRflGY0xgiwIGHDgLefdb7 R2fDwD+o7MQNrprIFPr+WJ4xTMJ6u2KxHN8ZkcB3VKho9kImi5vetawWK bwyb+El4sotqcy1fIPcoIGMj//XbMXyRmGXuS86t/+/lBXVcu8uUheyjw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGlWvVOtJV2P/2dsb2JhbABZgw5SWr8VCIdBAYEPFnWEAwEBAQQBAQFlBgkCEAIBCA4EBiMLJwsXBQkCBAENBRuIJw3IexMEjmARAQJOB4RDBYoXkF+UDIIBgUKBdzk X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="59454456" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 09 Jul 2014 14:51:54 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s69EpnlF022418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 14:51:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 09:51:49 -0500 From: "Eric Vyncke (evyncke)" To: Mikael Abrahamsson , "Liubing (Leo)" Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPm1EfCs1tJ+3fVEGmUhRkiSIjZJuX3saAgABqjYA= Date: Wed, 9 Jul 2014 14:51:48 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nAt3rJvz9CYyO4TJcHY-Dnx3qRU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:51:53 -0000 Mikael I can only second your layer-3 architecture for the same reasons as yours: especially with IPv6 where we can get numerous IPv6 prefixes up to one /64 per host if required. OTOH, let's face reality and a lot of 'resiliency' or 'VM mobility' or ... "DC solutions" requires a L2 spanning multiple kilometers. So, ending in having the same bindings in several layer-3 nodes :-( Another corner case is the WLAN used at large large conferences where it is easy to end up with thousands of WiFi stations on the same layer-2. And, if those WiFi stations have privacy extension addresses (99.9% of them), then the NDP cache can grow and grow... -=E9ric On 9/07/14 12:30, "Mikael Abrahamsson" wrote: >On Wed, 9 Jul 2014, Liubing (Leo) wrote: > >> This issue was found in real deployment experience. The most >> straightforward solution is to just increase the MAC table size. >> However, relevant hardware resource such as TCAM is very expensive and >> high power consumption that in some cost-sensitive scenarios it might >> not be a good solution. So I was thinking whether this could be >> considered as an operational issue, and whether there could be some >> operational mitigation approach. >> >> Your comments would be appreciated very much. >> >> "In some scenarios such as campus networks and enterprise networks, >> the "big L2 network" architecture is often used to reduce the cost >> and ease the management. In a big L2 network, a large amount of hosts >> (e.g. 10K users) are aggregated to the core at layer 2. > >Yeah, this was a bad idea for IPv4, and it's a bad idea for IPv6. I >propose making smaller L2 domains by means of L3 switches closer to the >devices, and then do routing. This solves several issues when it comes to >scalability, while it might be seen as causing problems in other aspects. > >I am a firm believer in creating a distributed L3 network and that large >L2 domains cause problems. The issue you mentioned is just one of them... > >Only way I can imagine to mitigate this operationally without doing >anything else, is to turn off SLACC and just use single DHCPv6_IA. You >still use 3 times more space (2 IPv6 addresses and 1 IPv4 address) for >dual stacked host than you do for a single stacked host, but that's hard >to avoid. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 9 08:13:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B941A0AF0 for ; Wed, 9 Jul 2014 08:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.002 X-Spam-Level: X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 FeUd5LpbPLzH for ; Wed, 9 Jul 2014 08:13:20 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB79B1A0AC7 for ; Wed, 9 Jul 2014 08:13:19 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 357C1A1; Wed, 9 Jul 2014 17:13:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404918798; bh=LFYHU11nWfmhcuaYHed8JF88BYnm44IK4fvFv8mbCgA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ccXwRBEdDmsb7m3sTSrrloECf19GZ1VMg95R7H1ScMduLu6xSRzTUqs/wS4T9L8S5 MzdzwjgK8IbtmWLFofV5yBSXz6BupNgSwWG2ORM+UpryhYzCCLR6fz/bLox7QaewXN zkR2fSP1lz/sQK0OkCFBa9WO0LR4uhhQCK8w+uSw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2CE589F; Wed, 9 Jul 2014 17:13:18 +0200 (CEST) Date: Wed, 9 Jul 2014 17:13:18 +0200 (CEST) From: Mikael Abrahamsson To: "Eric Vyncke (evyncke)" In-Reply-To: Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J2ideQR0r7YFvoRuGPQyTfIkUqo Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:13:22 -0000 On Wed, 9 Jul 2014, Eric Vyncke (evyncke) wrote: > OTOH, let's face reality and a lot of 'resiliency' or 'VM mobility' or > ... "DC solutions" requires a L2 spanning multiple kilometers. So, > ending in having the same bindings in several layer-3 nodes > :-( "Doctor, when I do this, it hurts." Well, tell them to stop, and find other solutions instead. > Another corner case is the WLAN used at large large conferences where it > is easy to end up with thousands of WiFi stations on the same layer-2. > And, if those WiFi stations have privacy extension addresses (99.9% of > them), then the NDP cache can grow and grow... Absolutely, so make the vendors invent mechanisms that work around this, for instance just because you enter a certain SSID, doesn't mean you have to enter the same L2 domain as everybody else. I could imagine solutions where this was hash:ed based on MAC address or something, so that nodes would end up in different L2 domains. For the ND/MAC bindings, well, there is no way around that, you just have to make sure you have a platform that allows for around 4-8 bindings per device you expect to connect to your network. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 9 08:43:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E330C1A0AFF for ; Wed, 9 Jul 2014 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=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 OU-492iCD09U for ; Wed, 9 Jul 2014 08:43:17 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F9A1A0AFC for ; Wed, 9 Jul 2014 08:43:17 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so7702546wes.7 for ; Wed, 09 Jul 2014 08:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v7tO/nue3yjtSfKQGB8c5lenU2bWxyB/SYZR9M2Yd94=; b=G1/MmaFt83RpICCnuRazv0S9k+En8lcnJxVQ0GmG0NAw0jhmJfSafcDW7cGSI4FHf4 HiRa88jrhxG5OkpuvaRTYgxbvdabHw6bRcoXLfjKkCRvAlAy8SuPmHNYwrR564h96dVD P2Nn6OvvaBrZVYio/18MgjuJTDcyBrktpZCjLpKWeqDne775fDNBAJDQ/vD61Ax2OUIR dctYEC9c/Lb5/gS9lAnCrdn1OKdbcVFjlhk7YnICY3fXarOQ/SJ0xXG/iQlqUn45YsdV +PAATz9fFLzPr/7HBw+jjeg+0YdcQZ2SgGVm/NfVeznQDemcvXwemKluRJqooNpZZE2S mdnw== X-Received: by 10.180.89.143 with SMTP id bo15mr12299655wib.78.1404920596074; Wed, 09 Jul 2014 08:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.216.10 with HTTP; Wed, 9 Jul 2014 08:42:55 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> From: Richard Hartmann Date: Wed, 9 Jul 2014 17:42:55 +0200 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sm13fjqFh1J92VYXYuBf0dMFk0s Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:43:19 -0000 On Wed, Jul 9, 2014 at 5:13 PM, Mikael Abrahamsson wrote: > Absolutely, so make the vendors invent mechanisms that work around this, for > instance just because you enter a certain SSID, doesn't mean you have to > enter the same L2 domain as everybody else. I could imagine solutions where > this was hash:ed based on MAC address or something, so that nodes would end > up in different L2 domains. For the ND/MAC bindings, well, there is no way > around that, you just have to make sure you have a platform that allows for > around 4-8 bindings per device you expect to connect to your network. And segment the v4 prefix you have for that automagically, how? All of a sudden, you will also need a lot more VLANs. With some APs limited to 16 VLANs and requirements to keep university network, eduroam, etc pp up at the same time, this is an actual real life scenario where the answer is not immediately obvious. Richard PS: Yes, this is v6ops, but Eric's argument of "large conference WiFi" hits home a bit, for me. From nobody Wed Jul 9 09:06:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5351A0B02 for ; Wed, 9 Jul 2014 09:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 nFHmPHVBgclC for ; Wed, 9 Jul 2014 09:06:19 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B511A0AAF for ; Wed, 9 Jul 2014 09:06:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3A4F3A1; Wed, 9 Jul 2014 18:06:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404921976; bh=GtLYlIBX0747FU0QZ+ZlTCCzvdXv8bsNlGfpME8P2Wg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IhEd4brwKQMqcKyTN3ClgOONKoBxTnZF1YFjhQSzZ1ih8mxEVr3HXnk30o2Q7DtkQ ZILEdwd4ih74JHZ8c7+FQh7w/5Qc1y0aRJmw/ONCxZ9IBgkuIog0j1QS/inOPQx5CD 9uFSeFJIa3v2dpLxZPjE+oUkdQLYXV/b92Tl6wmg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3139A9F; Wed, 9 Jul 2014 18:06:16 +0200 (CEST) Date: Wed, 9 Jul 2014 18:06:16 +0200 (CEST) From: Mikael Abrahamsson To: Richard Hartmann In-Reply-To: Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZjqTvJqvXgOQx5vf1L_niiAuyYU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:06:20 -0000 On Wed, 9 Jul 2014, Richard Hartmann wrote: > And segment the v4 prefix you have for that automagically, how? All of a > sudden, you will also need a lot more VLANs. With some APs limited to 16 > VLANs and requirements to keep university network, eduroam, etc pp up at > the same time, this is an actual real life scenario where the answer is > not immediately obvious. I agree that with the current platforms that are available, there is no obvious solution. This usually means some vendor will come up with a solution, and others will have to follow of lose business. If you don't want to buy new hardware (or have vendor fix current scalability in software if they can) and limit the impact of this, then I suggest using DHCPv6_IA and disallow SLAAC, that at least cuts down on potential IP/MAC bindings that you have to handle to an architectural minimum (that I can see anyway). Make sure to raise the issues you see with your vendor so they at least fix it in next generation hardware and software. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 9 09:41:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318221A029D for ; Wed, 9 Jul 2014 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.552 X-Spam-Level: X-Spam-Status: No, score=-13.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Oy-9br9L4_kX for ; Wed, 9 Jul 2014 09:41:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F341A020B for ; Wed, 9 Jul 2014 09:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3319; q=dns/txt; s=iport; t=1404924111; x=1406133711; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=Xq3oUoyMBJPiCJZJ6qKJqBMR2xEhAeBs7d1yTgETtqc=; b=CZZTr+1ch46ZF7BwbJ2UzjdC1Q09gk3H4ElZUy//BYMKzU6xaVXYdxI/ ii/vVl9pDnWHL3x1yQXxcLwxG46K042/2P/nJDT1SREOaFCRFxOtO+4qV eBA+knz2hjvnCkCu+c+3mVe5tJfLevbAysKfb2HdIu9dv5DfKCJ56/9bE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoMAC1wvVOtJV2R/2dsb2JhbABZgw5SWqtwAQEBAQEBBQFuki0KhmxTAYEQFnWEAwEBAQMBAQEBJBECLgYJAgULCw4FBSMLJycJBg4FGwOIHAgNyG4XhXqIZhACAU8HhEMFnD6SRIIBgURqgUQ X-IronPort-AV: E=Sophos;i="5.01,632,1400025600"; d="scan'208";a="338830292" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2014 16:41:50 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s69GfW0r008098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 16:41:32 GMT Received: from ams-ayourtch-8813.cisco.com (10.55.47.212) by xhc-aln-x11.cisco.com (173.36.12.85) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Jul 2014 11:41:31 -0500 Date: Wed, 9 Jul 2014 18:41:20 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Mikael Abrahamsson In-Reply-To: Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.55.47.212] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Zz8KhaXHMzlJrMYaudlU7lPABDA Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:41:35 -0000 On Wed, 9 Jul 2014, Mikael Abrahamsson wrote: > On Wed, 9 Jul 2014, Eric Vyncke (evyncke) wrote: > >> OTOH, let's face reality and a lot of 'resiliency' or 'VM mobility' or ... >> "DC solutions" requires a L2 spanning multiple kilometers. So, ending in >> having the same bindings in several layer-3 nodes :-( > > "Doctor, when I do this, it hurts." Well, tell them to stop, and find other > solutions instead. > >> Another corner case is the WLAN used at large large conferences where it is >> easy to end up with thousands of WiFi stations on the same layer-2. And, if >> those WiFi stations have privacy extension addresses (99.9% of them), then >> the NDP cache can grow and grow... > > Absolutely, so make the vendors invent mechanisms that work around this, for Here's some data, taken from CiscoLive2014 in Milan half a year ago: http://2014.ciscolive-ipv6.com/munin/ipv6noc/ipv6noc/net_neighbors.html ^ the sum of all entries in "show arp" and "show ipv6 neighbors", with the split by global/link-local for IPv6. We can see the total count for IPv6 is about 3x that of IPv4. Now, this network ran SLAAC, with about 50% clients being recent Apple gear, so understandably the globally routable IPv6 addresses spike up. http://2014.ciscolive-ipv6.com/munin/ipv6noc/ipv6noc/neighbors_unique_per_vlan.html ^ This graph shows duplicates within address family per MAC address collapsed, per VLAN. VLAN4, as obvious, was the VLAN with pretty much all the wireless users. I'll take the numbers below from the maximums of the graphs, so it is not scientific at all but gives the ballpark: IPv4: 9.46k -> 9.35k IPv6: (16.60k global + 7.73k link-local ) -> (6.76k global + 7.55k link-local) So, yeah there is a ~1.7x bloat in the neighbor table due to privacy addresses, but that does not look too dramatic, does it ? > instance just because you enter a certain SSID, doesn't mean you have to > enter the same L2 domain as everybody else. I could imagine solutions where You can only do a subnet-per-area if you have non-overlapping areas of coverage, and are happy to have the clients restart the apps on reconnect. Most of the time it's out of the question. > this was hash:ed based on MAC address or something, so that nodes would end > up in different L2 domains. Then you would need to roam the client within its VLAN across the entire area of coverage. So since there are N equal VLANs, do they share the same physical box as the default gateway ? If they do, there's no win on NDP cache space. I re-read the original mail starting this thread and the problem description there to me boils down to two issues: 1) one IP node has more IP addresses in version 6 than in version 4. 2) an IP address takes more lookup space in version 6 than in version 4. Do I grok it right ? > For the ND/MAC bindings, well, there is no way > around that, you just have to make sure you have a platform that allows for > around 4-8 bindings per device you expect to connect to your network. +1. --a > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jul 9 11:33:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545EB1A854B for ; Wed, 9 Jul 2014 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 QzCqUs2t0TJH for ; Wed, 9 Jul 2014 11:33:50 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBE51A0B17 for ; Wed, 9 Jul 2014 11:33:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E868A1; Wed, 9 Jul 2014 20:33:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404930828; bh=etcRbygGAUofb1zsqX3Za6cZygwJJBeWuguL8XVy8sw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=AYlseRx4lT0bUDhAtKA2EKzgqVg1ax473dccyRB1L6qJczhtJNWG9y8zDncV+HK2d WY2iyY8jMzr2fY9CdevluFXpealsRCh0Glmc79rsVyf49UTyMvuVhgwhGKbcYikfLL Vp5pEi4vO5yxYZXToRD9wjwJOqF2ojOyt4eOxJkc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 56C639F; Wed, 9 Jul 2014 20:33:48 +0200 (CEST) Date: Wed, 9 Jul 2014 20:33:48 +0200 (CEST) From: Mikael Abrahamsson To: Andrew Yourtchenko In-Reply-To: Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1MVVzMJmUpBLJcq7mEe_nfYptqA Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 18:33:52 -0000 On Wed, 9 Jul 2014, Andrew Yourtchenko wrote: > Then you would need to roam the client within its VLAN across the entire area > of coverage. So since there are N equal VLANs, do they share the same > physical box as the default gateway ? Yes, the only thing it would solve is to make the broadcast domains contain fewer devices per broadcast domain, the broadcast domains would still span the same APs. > If they do, there's no win on NDP cache space. Correct, but potentially you could have several smaller boxes, each serving one or more vlans, instead of a bigger box, serving all clients in a single vlan. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 9 13:29:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166691A0463 for ; Wed, 9 Jul 2014 13:29:08 -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, SPF_PASS=-0.001] autolearn=ham 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 9pEdE_0eOSbF for ; Wed, 9 Jul 2014 13:29:06 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B661A0421 for ; Wed, 9 Jul 2014 13:29:06 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kq14so9740992pab.20 for ; Wed, 09 Jul 2014 13:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+X3vGbjD9Ymy311GUkyY/VzTHrzIPoPoOqZPEPv6/Us=; b=eL422i39a0vmp++GYVZx772nzfg37bdTFcXntxqpvp19JRh2kV+91zzPkIfd2OnTQy OZX12iP/aQKgSDMLGteRh1qxnE9RYtctC6KeUzAoU//JVqQyEAZaE9PaJbYtmJF8d3m/ aMn9UjfTTrAoA+/U7WU7/nyVrCe4sH4pvEGYS3efsm6hwwQ4rXh7Ni5/tyTLW3jmMbfB ocujSl+HO5BgtJgiz/rdC0PfCH5V/2oQFcUbXY2WRSZIQkw6Ho3WgL4S8/sgNPhJPWjN dwKyeUlq6WUvTxN6YBBixXyaEU1yxBX9dc121Jtba89sPv379xyeQf5S6s+B3KeMWKmK OmPQ== X-Received: by 10.67.13.176 with SMTP id ez16mr39976589pad.31.1404937746620; Wed, 09 Jul 2014 13:29:06 -0700 (PDT) Received: from [192.168.178.23] (158.197.69.111.dynamic.snap.net.nz. [111.69.197.158]) by mx.google.com with ESMTPSA id by7sm43849297pab.35.2014.07.09.13.29.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 13:29:05 -0700 (PDT) Message-ID: <53BDA616.5050001@gmail.com> Date: Thu, 10 Jul 2014 08:29:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/14iQTRMk23ktI7lrjtZFsOtTIKg Cc: V6 Ops List Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:29:08 -0000 On 10/07/2014 00:50, Randy Bush wrote: >> "In some scenarios such as campus networks and enterprise networks, >> the "big L2 network" architecture is often used to reduce the cost >> and ease the management. > > operational, not vendor, experience is that "big l2 network" > architecture increases cost, management, and many kinds of > pain. Yes, this is something that (to name but three that I know of personally) Boeing, Microsoft and CERN discovered in the late 1980s, and although the value of "big" has increased somewhat since then, it remains true: you can't scale an L2 architecture beyond the limit set by the cost and speed of CAM silicon. Brian From nobody Wed Jul 9 13:43:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C611AD6B0 for ; Wed, 9 Jul 2014 13:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 TFitWKmp4Jxh for ; Wed, 9 Jul 2014 13:43:46 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26C91ACAD6 for ; Wed, 9 Jul 2014 13:43:46 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y13so9633706pdi.13 for ; Wed, 09 Jul 2014 13:43:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OFPlBWdUg9lSf2sDy/Oyl0bcpRKI3klx2vG2UxaU7pY=; b=LlIAoGMUQs8YWkI9eyoGfb2mZEUF/vdpPqhSolf0Ah8hdLMNkjqXi/8Zuuail6Ri4F qS01YbziM9z96RaIowmszcj1nOCpDq4NnUNZYGaQNzI8CIr0Hp+n7CeWVS3RS6aKEf1w R1+8JGViN9kCRbpdzvcPVoiKDnJQUL1i3q9EBgmyC/6E/CMQutmylE/UTAL+Vw1/v6aa xv/9Hwj90v2pqB3l8aUB+br4SnL0J+Ws/YtStjrf5UWhp8BVxhUHNBlSyRrwlI9GFwRk iZ/hSppteq0SmxZy3Wg8/h9e/EfqkH8R8T7PtryCRhJzbfRVokXRFFGuGR6eUqSkQqR4 CC6g== X-Gm-Message-State: ALoCoQlAud1LgqmvoYDkRr2zvFgmqhDKgOMIfRo+UNJbOMi/rOoGR2AjbB8q4K3K7YmlJpt+rXIT MIME-Version: 1.0 X-Received: by 10.68.231.229 with SMTP id tj5mr32828230pbc.101.1404938626419; Wed, 09 Jul 2014 13:43:46 -0700 (PDT) Received: by 10.70.131.100 with HTTP; Wed, 9 Jul 2014 13:43:46 -0700 (PDT) X-Originating-IP: [131.203.247.181] In-Reply-To: <53BDA616.5050001@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <53BDA616.5050001@gmail.com> Date: Thu, 10 Jul 2014 08:43:46 +1200 Message-ID: From: George Michaelson To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b33c65ec2657d04fdc8c344 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Jka6rWeSmMtm85aNomBtbYYLJQA Cc: V6 Ops List Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:43:48 -0000 --047d7b33c65ec2657d04fdc8c344 Content-Type: text/plain; charset=UTF-8 whats a rule-of-thumb size? 500? 1000? 10,000? do we have enough thumbs? On Thu, Jul 10, 2014 at 8:29 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 10/07/2014 00:50, Randy Bush wrote: > >> "In some scenarios such as campus networks and enterprise networks, > >> the "big L2 network" architecture is often used to reduce the cost > >> and ease the management. > > > > operational, not vendor, experience is that "big l2 network" > > architecture increases cost, management, and many kinds of > > pain. > > Yes, this is something that (to name but three that I know > of personally) Boeing, Microsoft and CERN discovered in the > late 1980s, and although the value of "big" has increased > somewhat since then, it remains true: you can't scale an L2 > architecture beyond the limit set by the cost and speed of > CAM silicon. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b33c65ec2657d04fdc8c344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
whats a rule-of-thumb size? 500? 1000? 10,000? =C2=A0
=
do we have enough thumbs?


On Thu, Jul 10, 2014 at 8:29 AM, Bri= an E Carpenter <brian.e.carpenter@gmail.com> wrote= :
On 10/07/2014 00:50, Randy B= ush wrote:
>> "In some scenarios such as campus networks and enterprise net= works,
>> =C2=A0the "big L2 network" architecture is often used to= reduce the cost
>> =C2=A0and ease the management.
>
> operational, not vendor, experience is that "big l2 network"=
> architecture increases cost, management, and many kinds of
> pain.

Yes, this is something that (to name but three that I know
of personally) Boeing, Microsoft and CERN discovered in the
late 1980s, and although the value of "big" has increased
somewhat since then, it remains true: you can't scale an L2
architecture beyond the limit set by the cost and speed of
CAM silicon.

=C2=A0 =C2=A0 Brian

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

--047d7b33c65ec2657d04fdc8c344-- From nobody Wed Jul 9 18:38:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E051A0109 for ; Wed, 9 Jul 2014 18:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 xoZ8WKPAeFf1 for ; Wed, 9 Jul 2014 18:38:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401501A010A for ; Wed, 9 Jul 2014 18:38:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X53JB-0006eL-2L; Thu, 10 Jul 2014 01:38:01 +0000 Date: Thu, 10 Jul 2014 10:38:00 +0900 Message-ID: From: Randy Bush To: Mikael Abrahamsson In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/128Nsbm1a_LuzVTh59yMqGicC0A Cc: V6 Ops List Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 01:38:07 -0000 > For the ND/MAC bindings, well, there is no way around that, you just > have to make sure you have a platform that allows for around 4-8 > bindings per device you expect to connect to your network. and having all those addresses per interface is soooo useful, one of the wonders of ipv6 randy From nobody Wed Jul 9 19:09:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C671A041B for ; Wed, 9 Jul 2014 19:08:51 -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, SPF_PASS=-0.001] autolearn=ham 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 2C3W11uugKrV for ; Wed, 9 Jul 2014 19:08:41 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89341A0403 for ; Wed, 9 Jul 2014 19:08:41 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so10079597pac.5 for ; Wed, 09 Jul 2014 19:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AIaQVu8ZyXGis3c/Q+5F2/Yy2GB2wl8cTqfgvj/hdSQ=; b=g01a9n9qFdrcK22GKleyeS+tAIkmEgf/olOZ07+TkB2gsdj+/Mi87+eB3sLTdX+zrY Jp1U7njTRs8nrP4Q4TgMWWAQ1KAl+Llg0rk2PaDOwcWJeCCuW0MYUgQDYjNVbExxKSix KryjIyLX+CqakWoIK636htbYffh+LrRaIPolj/FOiu2T1goZXURFSwBifQkW2q9o0Xok k7njhCqsyceKpJsuNAeqH7247NoMbPmkRWuux0f8Fxo8/oIWyCiXKCMwJr9hRxiqDl/q VdmhZbRg6CuzYfbITMlgYSiyQZk/mQTz2GunJyJ7u9YahnEZEYrC9E3+M03IpNM5gp7V RAVA== X-Received: by 10.70.0.168 with SMTP id 8mr14317679pdf.34.1404958121462; Wed, 09 Jul 2014 19:08:41 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id y1sm19025275pbw.87.2014.07.09.19.08.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 19:08:40 -0700 (PDT) Message-ID: <53BDF5AE.9000804@gmail.com> Date: Thu, 10 Jul 2014 14:08:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: George Michaelson References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <53BDA616.5050001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ohs_Vpst0I_khelBKLVKO7fKGe8 Cc: V6 Ops List Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 02:08:52 -0000 On 10/07/2014 08:43, George Michaelson wrote: > whats a rule-of-thumb size? 500? 1000? 10,000? I think that there were early L2 bridges with a 1024 limit. I suspect that some modern switches can survive with 10000, but then you'll have other practical problems. The point is that there's always a limit, and (unlike L3 routing) you can't just fix the problem by recursing the solution. I have to say that Randy is correct - the multiaddressing model for IPv6 makes the ND cache significantly larger, but that shouldn't affect switches unless they are snooping L3 stuff. Nobody would do that, would they? Brian > > do we have enough thumbs? > > > On Thu, Jul 10, 2014 at 8:29 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 10/07/2014 00:50, Randy Bush wrote: >>>> "In some scenarios such as campus networks and enterprise networks, >>>> the "big L2 network" architecture is often used to reduce the cost >>>> and ease the management. >>> operational, not vendor, experience is that "big l2 network" >>> architecture increases cost, management, and many kinds of >>> pain. >> Yes, this is something that (to name but three that I know >> of personally) Boeing, Microsoft and CERN discovered in the >> late 1980s, and although the value of "big" has increased >> somewhat since then, it remains true: you can't scale an L2 >> architecture beyond the limit set by the cost and speed of >> CAM silicon. >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Wed Jul 9 19:13:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AC01A036D for ; Wed, 9 Jul 2014 19:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 N6i3J_1PRcgQ for ; Wed, 9 Jul 2014 19:12:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCEA1A01D6 for ; Wed, 9 Jul 2014 19:12:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X53qw-0006k4-TE; Thu, 10 Jul 2014 02:12:55 +0000 Date: Thu, 10 Jul 2014 11:12:54 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <53BDF5AE.9000804@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <53BDA616.5050001@gmail.com> <53BDF5AE.9000804@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2JcnXHntZlXltFSRjPeTFw5b9tw Cc: V6 Ops List Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 02:12:58 -0000 > the multiaddressing model for IPv6 makes the ND cache significantly > larger and it is such a major win. will the police surveillance state mandate that your govt id number be in your ip address? randy From nobody Thu Jul 10 03:02:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959E21B2825 for ; Thu, 10 Jul 2014 03:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 qoTyxaAI45Sk for ; Thu, 10 Jul 2014 03:02:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F7A1B27E6 for ; Thu, 10 Jul 2014 03:02:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJV08020; Thu, 10 Jul 2014 10:02:17 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 11:02:15 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 18:02:08 +0800 From: "Liubing (Leo)" To: Andrew Yourtchenko , Mikael Abrahamsson Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPm1EfCs1tJ+3fVEGmUhRkiSIjZJuXBNiAgABJCACAAAYBAIAAGJkAgAGhbjA= Date: Thu, 10 Jul 2014 10:02:07 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_TZDc03M2SuMF3hNsN-tgsA6dUs Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 10:02:21 -0000 Hi Andrew, > I'll take the numbers below from the maximums of the graphs, so it is not > scientific at all but gives the ballpark: >=20 > IPv4: 9.46k -> 9.35k > IPv6: (16.60k global + 7.73k link-local ) -> (6.76k global + 7.55k link-l= ocal) >=20 > So, yeah there is a ~1.7x bloat in the neighbor table due to privacy addr= esses, > but that does not look too dramatic, does it ? [Bing] Would you like to share more details of the network? E.g. it is a du= al-stack or something else. It is quite often that a host would have at least 3 IPv6 addresses: a link-= local, a global and a privacy address. If ULAs are enabled, DHCPv6/SLAAC co= -existing, there might be more IPv6 addresses. So I was just guessing, maybe the 1.7x only represent that part of the node= s is enabling IPv6? Plus, an IPv6-MAC binding would cost more cache space than an IPv4-MAC bind= ing (2-4 times due to implementation). > I re-read the original mail starting this thread and the problem descript= ion > there to me boils down to two issues: >=20 > 1) one IP node has more IP addresses in version 6 than in version 4. > 2) an IP address takes more lookup space in version 6 than in version 4. >=20 > Do I grok it right ? [Bing] Basically yes. This is one of the problems cause by multiple IPv6 ad= dresses in draft-liu-v6ops-running-multiple-prefixes. B.R. Bing From nobody Thu Jul 10 03:09:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC4E1B282A for ; Thu, 10 Jul 2014 03:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 H55wbzoPBC1z for ; Thu, 10 Jul 2014 03:08:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4091A1B27E6 for ; Thu, 10 Jul 2014 03:08:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJV08735; Thu, 10 Jul 2014 10:08:52 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 11:08:52 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 18:08:45 +0800 From: "Liubing (Leo)" To: "Eric Vyncke (evyncke)" , Mikael Abrahamsson Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPm1EfCs1tJ+3fVEGmUhRkiSIjZJuXBNiAgABJCACAAce3cA== Date: Thu, 10 Jul 2014 10:08:45 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F292D@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LGbED-DnK_5njAC3Rc4WQZg-UjE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 10:08:57 -0000 Hi Eric, > Another corner case is the WLAN used at large large conferences where it = is > easy to end up with thousands of WiFi stations on the same layer-2. > And, if those WiFi stations have privacy extension addresses (99.9% of th= em), > then the NDP cache can grow and grow... [Bing] We also had experience of the problem in a conference, but I think m= aybe it would not need to be a "large large" conference to encounter the pr= oblem. Say, the administrators use a medium-end switch which could handle traffic = of hundreds of WiFi stations but doesn't have enough ND/ARP cache space to = support the full table of each host. B.R. Bing > -=E9ric >=20 >=20 > On 9/07/14 12:30, "Mikael Abrahamsson" wrote: >=20 > >On Wed, 9 Jul 2014, Liubing (Leo) wrote: > > > >> This issue was found in real deployment experience. The most > >> straightforward solution is to just increase the MAC table size. > >> However, relevant hardware resource such as TCAM is very expensive > >> and high power consumption that in some cost-sensitive scenarios it > >> might not be a good solution. So I was thinking whether this could be > >> considered as an operational issue, and whether there could be some > >> operational mitigation approach. > >> > >> Your comments would be appreciated very much. > >> > >> "In some scenarios such as campus networks and enterprise networks, > >> the "big L2 network" architecture is often used to reduce the cost > >> and ease the management. In a big L2 network, a large amount of > hosts > >> (e.g. 10K users) are aggregated to the core at layer 2. > > > >Yeah, this was a bad idea for IPv4, and it's a bad idea for IPv6. I > >propose making smaller L2 domains by means of L3 switches closer to the > >devices, and then do routing. This solves several issues when it comes > >to scalability, while it might be seen as causing problems in other aspe= cts. > > > >I am a firm believer in creating a distributed L3 network and that > >large > >L2 domains cause problems. The issue you mentioned is just one of them..= . > > > >Only way I can imagine to mitigate this operationally without doing > >anything else, is to turn off SLACC and just use single DHCPv6_IA. You > >still use 3 times more space (2 IPv6 addresses and 1 IPv4 address) for > >dual stacked host than you do for a single stacked host, but that's > >hard to avoid. > > > >-- > >Mikael Abrahamsson email: swmike@swm.pp.se > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 10 03:54:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430C81B287B for ; Thu, 10 Jul 2014 03:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 DD5JKwkCmRik for ; Thu, 10 Jul 2014 03:54:42 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37F91B287A for ; Thu, 10 Jul 2014 03:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5553; q=dns/txt; s=iport; t=1404989694; x=1406199294; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=4mc5tRXkNJ9jhQr2xl1se6glOt0go9Qrmq3lrQVrtpw=; b=SFyHapPIeaC01jIYkHGzJntETQjpCcVpXwoVPqP5/K+UHYcRfmx/hOOB qCMLQUMB//yn6kNspWcKUZJqkuVHOSeOfd5qP+2zXREuqKucAUWip+WL8 aKQTXIik6GW/wtg5pza3tOkI6Lkysj5zQ08be9Uqq1+QkdpCnUdsqlZYj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroHACFwvlOtJV2b/2dsb2JhbABZgw5SWqt4AQEBAQEBBQFukjyGbVMBgQoWdYQDAQEBAwEnQQ8CBQsLEygLTgkGDog/CA3HcheFeoh5AQFPB4RDAQScSJJNggGBRGqBCzk X-IronPort-AV: E=Sophos;i="5.01,637,1400025600"; d="scan'208";a="59727020" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 10 Jul 2014 10:54:51 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6AAsekL005570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 10:54:40 GMT Received: from ams-ayourtch-8813.cisco.com (10.55.47.212) by xhc-aln-x11.cisco.com (173.36.12.85) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Jul 2014 05:54:39 -0500 Date: Thu, 10 Jul 2014 12:54:20 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1684318330-1404989682=:93503" X-Originating-IP: [10.55.47.212] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Fn8YWjpsPD9l_Eth9Z_xD7FehwM Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 10:54:45 -0000 --0-1684318330-1404989682=:93503 Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 8BIT Hi Leo, On Thu, 10 Jul 2014, Liubing (Leo) wrote: > Hi Andrew, > >> I'll take the numbers below from the maximums of the graphs, so it is not >> scientific at all but gives the ballpark: >> >> IPv4: 9.46k -> 9.35k >> IPv6: (16.60k global + 7.73k link-local ) -> (6.76k global + 7.55k link-local) >> >> So, yeah there is a ~1.7x bloat in the neighbor table due to privacy addresses, >> but that does not look too dramatic, does it ? > [Bing] Would you like to share more details of the network? E.g. it is a dual-stack or something else. It's dualstack, the vast majority of the clients are on a single wireless segment (the total number of wired devices is ~300-400, so I treat them as noise. The wireless clients are addressed with SLAAC, and are outside of my control (conference attendees). The segment has no officially designated servers. The configuration from the first hop router is below: interface Vlan4 description !!! WIRELESS CLIENTS !!! CiscoLive2014 !!! .. IPv4 configuration omitted .. ipv6 address FE80::1 link-local ipv6 address 2001:4D38:A:400::1/64 ipv6 nd reachable-time 1800000 ipv6 nd prefix default 86400 9000 off-link no-autoconfig ipv6 nd prefix 2001:4D38:A:400::/64 604800 86400 off-link ipv6 nd prefix 2001:4D38:A:6800::/64 604800 0 off-link ipv6 nd router-preference High ipv6 nd ra lifetime 9000 no ipv6 redirects no ipv6 unreachables ipv6 verify unicast source reachable-via rx ipv6 route 2001:4D38:A:400::/64 vlan4 Note a few bits that are specific for the conference setup, and some are specific to the topology: 1) maximally high lifetimes (RAs are throttled on their way to the clients down to 1 RA in 10 minutes). 2) clearing on-link bit: results in clients never trying to resolve the other clients' addresses => less memory usage on the portable devices, smaller ND caches there. 3) default no-autoconfig: to force the necessity to add the prefixes manually, to force the operator to always have the "ipv6 nd prefix ..." with the correct config. 4) two prefixes, one with zero preferred lifetime: there was a second VLAN for disaster recovery purposes, where the clients would have ended up if there was a catastrophic failure no the main pair of the wireless controllers. That VLAN had a mirrored configuration. Experimentally, I've found such a configuration to cause a rapid deprecation of the "wrong" prefix on a iOS and OSX, resulting in minimal disruption to them in case of switchover. 5) interface route for the prefix, to send the traffic to it (configuring the prefix "off-link" had removed the directly connected route). > It is quite often that a host would have at least 3 IPv6 addresses: a >link-local, a global and a privacy address. If ULAs are enabled, >DHCPv6/SLAAC co-existing, there might be more IPv6 addresses. Right. I was well within the constraints for the first hop, so opted to not have DHCPv6. If I wanted a tighter control, I'd have turned off SLAAC and used stateful DHCPv6. Maybe I'll experiment with it this year. > So I was just guessing, maybe the 1.7x only represent that part of the nodes is enabling IPv6? The %% of the nodes running IPv6 was about 80-85% (http://2014.ciscolive-ipv6.com/munin/ipv6noc/ipv6noc/neighbors_dualstack_percentage.html - the dips are the the night times, a lot of internal apps were IPv4 so the neighbor entries went away) I calculated this %% by taking the "show arp" and "show ipv6 neigh" outputs and correlating the hosts by mac address. As I said Apple devices (they are the most aggressive today wrt the privacy addresses) are ~50% of the network, so maybe in another setup the figures would be different. Do you have some numbers you could share ? > Plus, an IPv6-MAC binding would cost more cache space than an IPv4-MAC binding (2-4 times due to implementation). > >> I re-read the original mail starting this thread and the problem description >> there to me boils down to two issues: >> >> 1) one IP node has more IP addresses in version 6 than in version 4. >> 2) an IP address takes more lookup space in version 6 than in version 4. >> >> Do I grok it right ? > [Bing] Basically yes. This is one of the problems cause by multiple > IPv6 addresses in draft-liu-v6ops-running-multiple-prefixes. Ok, then I think that's a tricky one - we can not decrease the number of bits in IPv6 address, nor get the end hosts to go back to ARP for address resolution :-) Also, if iOS 8.0 indeed changes the MAC address upon the wireless connection, the problem is just about to get much worse and not IPv6-specific ;-) So, I think there are several means to combat the lookup space churn: 1) IPv6-only networks. We can't do that today and IPv4 is relatively not *so* much but it's something. 2) Table maintenance/cleanup mechanisms. These appear to work today reasonably. 3) provisioning hardware according to anticipated scale - and either using larger router boxes, or splitting large L3 domains into several smaller segments, like Mikael mentioned. 4) using DHCPv6-only allocation of addresses, with one address per host assignment. Do you think there is something more that is needed besides the above approaches to steer the addresses on the host ? --a --0-1684318330-1404989682=:93503-- From nobody Thu Jul 10 04:17:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3675C1B2883 for ; Thu, 10 Jul 2014 04:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.4 X-Spam-Level: ** X-Spam-Status: No, score=2.4 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 qNTLL5A_Pwpw for ; Thu, 10 Jul 2014 04:17:51 -0700 (PDT) Received: from nm42.bullet.mail.ne1.yahoo.com (nm42.bullet.mail.ne1.yahoo.com [98.138.120.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C88E1A03D9 for ; Thu, 10 Jul 2014 04:17:50 -0700 (PDT) Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2014 11:17:50 -0000 Received: from [98.138.100.111] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2014 11:14:58 -0000 Received: from [66.196.81.170] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2014 11:14:58 -0000 Received: from [98.139.212.194] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jul 2014 11:14:58 -0000 Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 10 Jul 2014 11:14:58 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 628855.22724.bm@omp1003.mail.bf1.yahoo.com Received: (qmail 53190 invoked by uid 60001); 10 Jul 2014 11:14:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1404990898; bh=8KmbiGuYU2DHGu40Uq/Ixnzw1OF7Gg8bGDEfhIL5P8o=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JMG+BLktif40R+dXw8SkcBqQJD20gsbU5xZheyeNdjGVElVqaQf6qGbqzcDLKnrUWL9uvPfZ+ec0lHhsIgd6OMBGwHO0yBDrmubAkxffjUxOaEpjEqPmzbrbg1RNIavszGPGTKrfS2yVAsP9uN1EhmqRk4UE64guUId6zGAd8Pg= X-YMail-OSG: OL.6_rIVM1k8GEwkTqT4hkuZZ22tazYi3Coh3sLcmvuyNQi SjP375Ei_agsBkfTJ_PZ2bmKZy_Il7nUfuL0QaKMpnsXsfyOrOrv8yozUGiA 6UyRW1h8bnD4CsBTlR9_5hZLdnAzqKUTDg2CM4rw_5yyatZjI9f6ZeHZe_4O 51zz4rR4xO4dywc8EjXFhQqvJmXdeUyo8sme56vTujoWhzv3IFQ.0cGJ7BDc mLMEVsUhE0RI5Ed3btCkh.lJljkN0PgyN0gSDE0ScFkFA7b1oaZxrg3iOSAP jKvk90gU9y9ZgD8WRN1qdwCxgIn4ZY_Th1WOcjwzGOtI1Gebi8GX2S.uBrLh QBuO_LFAcvvZ1XCCQKzJxYsZwwhysI9VQYe_dG2lfozfH6T7Rtbxn.zMhcqH B28ckhF76juh4bgFfPfQ1NVD4BFGT09n8V.pBNBgb_EmDSaXOn8UcgdFGK6r mZ..s6l86FBHBroG.bwq.o8PO_5rzdG5hLvhATa1BXfiBGWpbrN2rxf5pKoe mS1gYfaGxpbf5RVNVbOs1cPPeE0TfmMYhXZra23R1SACOaeKDpaYHpNNFU8A Kxto- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Thu, 10 Jul 2014 04:14:58 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKCgo8c25pcD4KPiAKPiBTaW1pbGFybHksIHRvIG15IHdheSBvZiB0aGlua2luZywgd2hpbGUgCj4gZHJhZnQtc21pdGgtdjZvcHMtbWl0aWdhdGUtcnRyLWRvcy1tbGQtc2xjdGQtbm9kZSBpcyBhcHBlYWxpbmcsIHY2b3BzIGNvbW1lbnRzIAo.IHJhaXNlZCBjb25jZXJucyBhYm91dCB0aGUgcmVsaWFiaWxpdHkgb2YgTUxEIChhbmQgTUxEIGltcGxlbWVudGF0aW9ucykgaW4gdGhlIAo.IGNvbnRleHQuIFRoYXQgc291bmRzIGxpa2UgYW4gaXNzdWUgZm9yIDZtYW4sIG5vdCB2Nm9wcy4gCj7CoAoKUmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.194.680 References: <53BAC55D.1030404@bogus.com> Message-ID: <1404990898.11472.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Thu, 10 Jul 2014 04:14:58 -0700 From: Mark ZZZ Smith To: "Fred Baker \(fred\)" , joel jaeggli , IPv6 Ops WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8e_hX24ouAuvV-WAM284fomph9M Subject: Re: [v6ops] Drafts lodged against the deadline. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:17:52 -0000 Hi,=0A=0A=0A=0A=0A=0A> =0A> Similarly, to my way of thinking, while = =0A> draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node is appealing, v6ops = comments =0A> raised concerns about the reliability of MLD (and MLD impleme= ntations) in the =0A> context. That sounds like an issue for 6man, not v6op= s. =0A>=A0=0A=0ARegarding this draft, I have to get back to doing some inve= stigation of implementations' MLD behaviour during address acquisition, whi= ch I'm planning to do soon.=0A=0A=0AI won't be at the next IETF, so leave t= his one off of the agenda.=0A=0AThanks very much,=0AMark.=0A=0A>=A0=0A=0A> = Opinions welcome. As always.=0A> =0A> _____________________________________= __________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.o= rg/mailman/listinfo/v6ops=0A> From nobody Thu Jul 10 08:06:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBB21A0659 for ; Thu, 10 Jul 2014 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pCu_5eDX3XX0 for ; Thu, 10 Jul 2014 08:06:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED941A0AAB for ; Thu, 10 Jul 2014 08:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3336; q=dns/txt; s=iport; t=1405004813; x=1406214413; h=from:to:cc:subject:date:message-id:mime-version; bh=4Tq4zzHup6Qa8n+MolkQBFtF15Rz1kISRZj352BEqdg=; b=OkiqD66jVmQe0p9F3BT+LHFCgOE3WVNrfF48XrD3YNpwm/K6FeWznz9a RitiDPz3vq4bvOKtzgTaTcbZACGsRlYyhfAPahIlRKMFzhWFEjA0UCch2 7asOHGuU+87NoXpRuVg+VoSpkWwUmlT74bgdPJTVYq8dqquZP5f7fW6+m o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAPOqvlOtJA2L/2dsb2JhbABZgkdHgSzGboENFnWECnkSAQwOZhcQBA6IR8gNF49EhEoFih6QYpQVg0OCMA X-IronPort-AV: E=Sophos; i="5.01,638,1400025600"; d="scan'208,217"; a="59793380" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 10 Jul 2014 15:06:52 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6AF6d2o023512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Jul 2014 15:06:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 10:06:39 -0500 From: "Eric Vyncke (evyncke)" To: IPv6 Ops WG Thread-Topic: Late addition to V6OPS agenda: segment routing for IPv6? Thread-Index: AQHPnFCMLc7lfw+FYEqYrOVbl/Eiyw== Date: Thu, 10 Jul 2014 15:06:38 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.72] Content-Type: multipart/alternative; boundary="_000_CFE4789D20A1Devynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HD1pb3uClJlWiAds-dtZyvhdoRQ Cc: "Stefano Previdi \(sprevidi\)" Subject: [v6ops] Late addition to V6OPS agenda: segment routing for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:06:46 -0000 --_000_CFE4789D20A1Devynckeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fred and Joel, You may be aware of segment routing whose architecture and MPLS version are= discussed in the SPRING WG. But, there is also an IPv6 version discussed i= n 6MAN: * draft-previdi-6man-segment-routing-header * draft-vyncke-6man-segment-routing-security-00 It is about a modified routing extension header to allow mainly for traffic= engineering and or replace a MPLS LDP core by a native IPv6 one. Hence, th= ere is a major (we hope) operational impact. Stefano (in cc) and I understand that we are late in the process to get a s= lot in V6OPS, but, if you could get us a 10-minute slot on Monday AM or Tue= sday PM, then we could present what are the goals & architecture of segment= routing for IPv6 (which really leverages IPv6, hence perhaps 'the killing = app' for IPv6 :-)) Thanks in advance and see you in Toronto -=E9ric --_000_CFE4789D20A1Devynckeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
= Fred and Joel,
=
= You may be aware of segment routing whose architecture and MPLS version are= discussed in the SPRING WG. But, there is also an IPv6 version discussed i= n 6MAN: 
  • draft-previdi-6man-segment-routing-header
  • =

    draft-vyncke-6man-segment-routing-security-00
It is about a modified routing extension header t= o allow mainly for traffic engineering and or replace a MPLS LDP core by a = native IPv6 one. Hence, there is a major (we hope) operational im= pact.

Stefano (in cc) and I understand that we are late= in the process to get a slot in V6OPS, but, if you could get us a 10-minut= e slot on Monday AM or Tuesday PM, then we could present what are the goals= & architecture of segment routing for IPv6 (which really leverages IPv6, hence perhaps 'the killing app' for= IPv6 :-))

Thanks in advance and see you in Toronto

-=E9ric
--_000_CFE4789D20A1Devynckeciscocom_-- From nobody Fri Jul 11 01:11:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2631B2AAE for ; Fri, 11 Jul 2014 01:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 esZHZzwCaIA8 for ; Fri, 11 Jul 2014 01:11:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8E81B2AAD for ; Fri, 11 Jul 2014 01:11:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHA11154; Fri, 11 Jul 2014 08:11:31 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Jul 2014 09:11:30 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 11 Jul 2014 16:11:26 +0800 From: "Liubing (Leo)" To: Andrew Yourtchenko Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPnC1ik94AZHMtAkW0lrev3UVEV5uaFjug Date: Fri, 11 Jul 2014 08:11:25 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0jn-9pfhshhXAm8OnYUzxQmQD7E Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 08:11:37 -0000 Hi Andrew, > > [Bing] Would you like to share more details of the network? E.g. it is = a > dual-stack or something else. >=20 > It's dualstack, the vast majority of the clients are on a single wireless > segment (the total number of wired devices is ~300-400, so I treat them a= s > noise. >=20 > The wireless clients are addressed with SLAAC, and are outside of my cont= rol > (conference attendees). >=20 > The segment has no officially designated servers. >=20 > The configuration from the first hop router is below: >=20 > interface Vlan4 > =A0description !!! WIRELESS CLIENTS !!! CiscoLive2014 !!! > .. IPv4 configuration omitted .. > =A0ipv6 address FE80::1 link-local > =A0ipv6 address 2001:4D38:A:400::1/64 > =A0ipv6 nd reachable-time 1800000 > =A0ipv6 nd prefix default 86400 9000 off-link no-autoconfig > =A0ipv6 nd prefix 2001:4D38:A:400::/64 604800 86400 off-link > =A0ipv6 nd prefix 2001:4D38:A:6800::/64 604800 0 off-link > =A0ipv6 nd router-preference High > =A0ipv6 nd ra lifetime 9000 > =A0no ipv6 redirects > =A0no ipv6 unreachables > =A0ipv6 verify unicast source reachable-via rx >=20 > ipv6 route 2001:4D38:A:400::/64 vlan4 >=20 > Note a few bits that are specific for the conference setup, and some are > specific to the topology: >=20 > 1) maximally high lifetimes (RAs are throttled on their way to the client= s > down to 1 RA in 10 minutes). >=20 > 2) clearing on-link bit: results in clients never trying to resolve the o= ther > clients' addresses =3D> less memory usage on the portable devices, smalle= r ND > caches there. >=20 > 3) default no-autoconfig: to force the necessity to add the prefixes manu= ally, > to force the operator to always have the "ipv6 nd prefix ..." > with the correct config. >=20 > 4) two prefixes, one with zero preferred lifetime: there was a second VLA= N > for disaster recovery purposes, where the clients would have ended up if > there was a catastrophic failure no the main pair of the wireless control= lers. > That VLAN had a mirrored configuration. > Experimentally, I've found such a configuration to cause a rapid deprecat= ion > of the "wrong" prefix on a iOS and OSX, resulting in minimal disruption t= o > them in case of switchover. >=20 > 5) interface route for the prefix, to send the traffic to it (configuring= the > prefix "off-link" had removed the directly connected route). [Bing] Andrew, thanks much for sharing the details.=20 > > It is quite often that a host would have at least 3 IPv6 addresses: a > >link-local, a global and a privacy address. If ULAs are enabled, > >DHCPv6/SLAAC co-existing, there might be more IPv6 addresses. >=20 > Right. I was well within the constraints for the first hop, so opted to n= ot have > DHCPv6. If I wanted a tighter control, I'd have turned off SLAAC and used > stateful DHCPv6. Maybe I'll experiment with it this year. >=20 > > So I was just guessing, maybe the 1.7x only represent that part of the > nodes is enabling IPv6? >=20 > The %% of the nodes running IPv6 was about 80-85% > (http://2014.ciscolive-ipv6.com/munin/ipv6noc/ipv6noc/neighbors_dualstac > k_percentage.html > - the dips are the the night times, a lot of internal apps were IPv4 so t= he > neighbor entries went away) >=20 > I calculated this %% by taking the "show arp" and "show ipv6 neigh" > outputs and correlating the hosts by mac address. >=20 > As I said Apple devices (they are the most aggressive today wrt the priva= cy > addresses) are ~50% of the network, so maybe in another setup the figures > would be different. >=20 > Do you have some numbers you could share ? [Bing] The problem was encountered by the co-author (Yang Bo) when doing pr= ojects in some campus/enterprise networks. I'm sorry we don't have the spec= ific statistics data like above, since we don't own the networks.=20 Now there are some enterprise/campus networks under real use or considering= using L2 networks. Some are aiming at better user isolation through VLANs = (some even consider QinQ mechanism); while some are aiming less configurati= on/management than the traditional L3 networks. So there would be thousands= of hosts aggregated to the core switch (normally there are two core switch= es stacked together, but only share one cache space). As IPv6 is beginning = real use, for example, some of the campus networks are already dual-stack, = and the majority of the hosts are Win 7, we once observed in one campus tha= t DHCPv6/SLAAC are both enabled, each Win 7 host had 4 IPv6 addr (SLAAC+DHC= Pv6+Privacy+link-local)+1 IPv4 addr.=20 Current high-end switch can certainly fulfill the thousands of users' IP-MA= C entries, however, the forwarding performance would be a significant redun= dancy, which would cost more budget than expected. This is something that w= on't happen in IPv4, so I thought maybe this could be considered as an IPv6= networks operational issue, and took the issue into the draft and gain som= e opinions in the list. > > Plus, an IPv6-MAC binding would cost more cache space than an IPv4-MAC > binding (2-4 times due to implementation). > > > >> I re-read the original mail starting this thread and the problem > >> description there to me boils down to two issues: > >> > >> 1) one IP node has more IP addresses in version 6 than in version 4. > >> 2) an IP address takes more lookup space in version 6 than in version = 4. > >> > >> Do I grok it right ? > > [Bing] Basically yes. This is one of the problems cause by multiple > > IPv6 addresses in draft-liu-v6ops-running-multiple-prefixes. >=20 > Ok, then I think that's a tricky one - we can not decrease the number of = bits > in IPv6 address, nor get the end hosts to go back to ARP for address > resolution :-) > > Also, if iOS 8.0 indeed changes the MAC address upon the wireless > connection, the problem is just about to get much worse and not > IPv6-specific ;-) >=20 > So, I think there are several means to combat the lookup space churn: >=20 > 1) IPv6-only networks. We can't do that today and IPv4 is relatively not > *so* much but it's something. >=20 > 2) Table maintenance/cleanup mechanisms. These appear to work today > reasonably. >=20 > 3) provisioning hardware according to anticipated scale - and either usin= g > larger router boxes, or splitting large L3 domains into several smaller > segments, like Mikael mentioned. >=20 > 4) using DHCPv6-only allocation of addresses, with one address per host > assignment. >=20 > Do you think there is something more that is needed besides the above > approaches to steer the addresses on the host ? [Bing] Thanks for the proposed approaches. It seems that's what we can do s= o far in operation perspective. As the opinions raised in the mailing list, people tend to consider it as a= network design issue rather than operational issue. I will reflect the opi= nions in the next version of the draft. Best regards, Bing > --a From nobody Fri Jul 11 01:41:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578E1B27D5 for ; Fri, 11 Jul 2014 01:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 t8m5dxDgTzuU for ; Fri, 11 Jul 2014 01:41:06 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDA81A0B17 for ; Fri, 11 Jul 2014 01:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3590; q=dns/txt; s=iport; t=1405068076; x=1406277676; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=WvS6D0hAWLwlWUOVoioSxx+HUD0iAU1SbiJw6GTlLdE=; b=WkecsCWlcgwmt2uMVzcPtWCNu53FCXkigaq/5CaG/azjdOx4ON1D4dfl qBZefm7WeW/SCt1OnIGj0O3tLTVXrrgvS5XEbLrLhvt6NdWGZc5pLmqYx xZyVIjh7mEmAhpXZOIbb2cQL36PceEjPMuQKa16udXM70LvjQTYwXig6T Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwHAIKiv1OtJV2Z/2dsb2JhbABZgw6BLKwBAQEBBQFumzwBgQsWdYQDAQEBAwE4AjICCAECEAs7C04JBg4jiBwIxl0XhXqEAoR5AQFPB4RDAQSvIIICgUSBdTk X-IronPort-AV: E=Sophos;i="5.01,642,1400025600"; d="scan'208";a="60021068" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 11 Jul 2014 08:41:15 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6B8f5vG020649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 08:41:05 GMT Received: from dhcp-10-149-0-20.cisco.com (10.149.0.20) by xhc-aln-x10.cisco.com (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Jul 2014 03:41:04 -0500 Date: Fri, 11 Jul 2014 10:40:36 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.149.0.20] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eTxLHCsCslB_xKgT2VQS7d4S0bw Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 08:41:07 -0000 Hi Leo, On Fri, 11 Jul 2014, Liubing (Leo) wrote: > > Now there are some enterprise/campus networks under real use or >considering using L2 networks. Some are aiming at better user isolation >through VLANs (some even consider QinQ mechanism); while some are aiming >less configuration/management than the traditional L3 networks. So there >would be thousands of hosts aggregated to the core switch (normally there >are two core switches stacked together, but only share one cache space). >As IPv6 is beginning real use, for example, some of the campus networks >are already dual-stack, and the majority of the hosts are Win 7, we once >observed in one campus that DHCPv6/SLAAC are both enabled, each Win 7 >host had 4 IPv6 addr (SLAAC+DHCPv6+Privacy+link-local)+1 IPv4 addr. If the majority of the hosts are Win 7, and are under the control of the administrator, this looks more like a misconfiguration rather than anything else: clear the "A" bit on the prefix, and they'll half the address usage - down to just link-local and DHCPv6-based. > > Current high-end switch can certainly fulfill the thousands of users' >IP-MAC entries, however, the forwarding performance would be a >significant redundancy, which would cost more budget than expected. This >is something that won't happen in IPv4, so I thought maybe this could be >considered as an IPv6 networks operational issue, and took the issue into >the draft and gain some opinions in the list. I'd say it's a question of different scaling requirements, depending on the network design. --a > >>> Plus, an IPv6-MAC binding would cost more cache space than an IPv4-MAC >> binding (2-4 times due to implementation). >>> >>>> I re-read the original mail starting this thread and the problem >>>> description there to me boils down to two issues: >>>> >>>> 1) one IP node has more IP addresses in version 6 than in version 4. >>>> 2) an IP address takes more lookup space in version 6 than in version 4. >>>> >>>> Do I grok it right ? >>> [Bing] Basically yes. This is one of the problems cause by multiple >>> IPv6 addresses in draft-liu-v6ops-running-multiple-prefixes. >> >> Ok, then I think that's a tricky one - we can not decrease the number of bits >> in IPv6 address, nor get the end hosts to go back to ARP for address >> resolution :-) >> >> Also, if iOS 8.0 indeed changes the MAC address upon the wireless >> connection, the problem is just about to get much worse and not >> IPv6-specific ;-) >> >> So, I think there are several means to combat the lookup space churn: >> >> 1) IPv6-only networks. We can't do that today and IPv4 is relatively not >> *so* much but it's something. >> >> 2) Table maintenance/cleanup mechanisms. These appear to work today >> reasonably. >> >> 3) provisioning hardware according to anticipated scale - and either using >> larger router boxes, or splitting large L3 domains into several smaller >> segments, like Mikael mentioned. >> >> 4) using DHCPv6-only allocation of addresses, with one address per host >> assignment. >> >> Do you think there is something more that is needed besides the above >> approaches to steer the addresses on the host ? > > [Bing] Thanks for the proposed approaches. It seems that's what we can do so far in operation perspective. > As the opinions raised in the mailing list, people tend to consider it as a network design issue rather than operational issue. I will reflect the opinions in the next version of the draft. > > Best regards, > Bing > >> --a > From nobody Fri Jul 11 02:40:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2BB1B27D0 for ; Fri, 11 Jul 2014 02:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 4-gKkuPl0rEh for ; Fri, 11 Jul 2014 02:40:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52F81B2ADB for ; Fri, 11 Jul 2014 02:40:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJW01799; Fri, 11 Jul 2014 09:40:08 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Jul 2014 10:40:08 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 11 Jul 2014 17:40:04 +0800 From: "Liubing (Leo)" To: Andrew Yourtchenko Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPnOPgxcBAiMAeFEi+VhPv9/az7ZuamSVg Date: Fri, 11 Jul 2014 09:40:04 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/78WsscyP6sAhDNNWGCYMnABWwDw Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 09:40:11 -0000 Hi Andrew, > > Now there are some enterprise/campus networks under real use or > >considering using L2 networks. Some are aiming at better user isolation > >through VLANs (some even consider QinQ mechanism); while some are > >aiming less configuration/management than the traditional L3 networks. > >So there would be thousands of hosts aggregated to the core switch > >(normally there are two core switches stacked together, but only share o= ne > cache space). > >As IPv6 is beginning real use, for example, some of the campus networks > >are already dual-stack, and the majority of the hosts are Win 7, we > >once observed in one campus that DHCPv6/SLAAC are both enabled, each > >Win 7 host had 4 IPv6 addr (SLAAC+DHCPv6+Privacy+link-local)+1 IPv4 addr= . >=20 > If the majority of the hosts are Win 7, and are under the control of the > administrator, this looks more like a misconfiguration rather than anythi= ng > else: clear the "A" bit on the prefix, and they'll half the address usage= - down > to just link-local and DHCPv6-based. [Bing] I can hardly say SLAAC and DHCPv6 co-existing is a misconfiguration,= but I agree DHCPv6-only deployment can partly relieve the problem. However, even DHCPv6-only would have 2 IPv6 addr+1 IPv4 addr, which would c= ause approximately 5~8 times cache space than IPv4-only. Best regards, Bing From nobody Fri Jul 11 03:28:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B721B2AFD for ; Fri, 11 Jul 2014 03:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jZOwv9vOORYw for ; Fri, 11 Jul 2014 03:28:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C451B2AFE for ; Fri, 11 Jul 2014 03:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1405074519; x=1406284119; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/J1ObbKoYj7JR46tJWb9aoGOcH7qHuOKaFHt2HiQHiQ=; b=BQLNFLI/MZAwSZOoNJTMuaxlMHdUnmUa+CytqsOOr/GvMZX3VoFFTpav kVLLEF41gtw+ySiI4OtkwpZCvvM52FgR5tt8+4fskebHg94EhxjTDvRR6 BvDrOXVrM90vjUNPvRt60FIRwbAouQHG+//SLwCSf1K8zExXSzvs9arcE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAMG7v1OtJV2Y/2dsb2JhbABZgw5SWsBoCodCAYELFnWEAwEBAQQBAQFrCQIQAgEIOwsnCxwJAgQBDQUeiCQNxl0TBIl8hUoHhEMBBIoekGeUG4ICgUKCMA X-IronPort-AV: E=Sophos;i="5.01,642,1400025600"; d="scan'208";a="60036612" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 11 Jul 2014 10:28:38 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6BASNLm026831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 10:28:24 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 05:28:23 -0500 From: "Eric Vyncke (evyncke)" To: "Liubing (Leo)" , "Andrew Yourtchenko (ayourtch)" Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPm1EfCs1tJ+3fVEGmUhRkiSIjZJuXBNiAgABJCACAAAYBAIAAGJkAgAGhbjCAAGnhAIABZNCAgAAIKACAABCdAIAALwWA Date: Fri, 11 Jul 2014 10:28:22 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <612366067AF2464A9494285A21B2AFFF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-K___H_GRgcCFhWLJwEfG0URHQU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:28:26 -0000 Regarding cache space (and no cache entry count), please note that the IP address is only part of the entry, there are many other bytes (counters for example) which also reside in this entry. So, it is not comparing 4 bytes vs. 16 bytes but rather comparing n+4 bytes vs. n+16 bytes (where n > 16 in most implementations I would guess) -=E9ric On 11/07/14 11:40, "Liubing (Leo)" wrote: >Hi Andrew, > >> > Now there are some enterprise/campus networks under real use or >> >considering using L2 networks. Some are aiming at better user isolation >> >through VLANs (some even consider QinQ mechanism); while some are >> >aiming less configuration/management than the traditional L3 networks. >> >So there would be thousands of hosts aggregated to the core switch >> >(normally there are two core switches stacked together, but only share >>one >> cache space). >> >As IPv6 is beginning real use, for example, some of the campus networks >> >are already dual-stack, and the majority of the hosts are Win 7, we >> >once observed in one campus that DHCPv6/SLAAC are both enabled, each >> >Win 7 host had 4 IPv6 addr (SLAAC+DHCPv6+Privacy+link-local)+1 IPv4 >>addr. >>=20 >> If the majority of the hosts are Win 7, and are under the control of the >> administrator, this looks more like a misconfiguration rather than >>anything >> else: clear the "A" bit on the prefix, and they'll half the address >>usage - down >> to just link-local and DHCPv6-based. > >[Bing] I can hardly say SLAAC and DHCPv6 co-existing is a >misconfiguration, but I agree DHCPv6-only deployment can partly relieve >the problem. >However, even DHCPv6-only would have 2 IPv6 addr+1 IPv4 addr, which would >cause approximately 5~8 times cache space than IPv4-only. > >Best regards, >Bing > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 11 03:48:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CF11B282C for ; Fri, 11 Jul 2014 03:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Sn8sUgUnvySp for ; Fri, 11 Jul 2014 03:48:05 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (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 49A341B2817 for ; Fri, 11 Jul 2014 03:48:05 -0700 (PDT) Received: from [IPv6:2601:4:2180:300:a193:8e51:240b:8ca1] ([IPv6:2601:4:2180:300:a193:8e51:240b:8ca1]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s6BAlvc7023004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Jul 2014 06:47:58 -0400 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <27F9B16E-6026-42CC-A0C6-64687C6997F0@puck.nether.net> X-Mailer: iPhone Mail (11D257) From: Jared Mauch Date: Fri, 11 Jul 2014 06:47:56 -0400 To: "Liubing (Leo)" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [IPv6:2001:418:3f4::5]); Fri, 11 Jul 2014 06:47:58 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/f4la3Wlrc9-EqoeHz-Zo6CgLXf8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:48:07 -0000 Apple believes the coexistence of slaac and dhcp6 are a problem and close de= fects as "3rd party problem won't fix" when raised with them.=20 Jared Mauch > On Jul 11, 2014, at 5:40 AM, "Liubing (Leo)" wrot= e: >=20 > Hi Andrew, >=20 >>> Now there are some enterprise/campus networks under real use or >>> considering using L2 networks. Some are aiming at better user isolation >>> through VLANs (some even consider QinQ mechanism); while some are >>> aiming less configuration/management than the traditional L3 networks. >>> So there would be thousands of hosts aggregated to the core switch >>> (normally there are two core switches stacked together, but only share o= ne >> cache space). >>> As IPv6 is beginning real use, for example, some of the campus networks >>> are already dual-stack, and the majority of the hosts are Win 7, we >>> once observed in one campus that DHCPv6/SLAAC are both enabled, each >>> Win 7 host had 4 IPv6 addr (SLAAC+DHCPv6+Privacy+link-local)+1 IPv4 addr= . >>=20 >> If the majority of the hosts are Win 7, and are under the control of the >> administrator, this looks more like a misconfiguration rather than anythi= ng >> else: clear the "A" bit on the prefix, and they'll half the address usage= - down >> to just link-local and DHCPv6-based. >=20 > [Bing] I can hardly say SLAAC and DHCPv6 co-existing is a misconfiguration= , but I agree DHCPv6-only deployment can partly relieve the problem. > However, even DHCPv6-only would have 2 IPv6 addr+1 IPv4 addr, which would c= ause approximately 5~8 times cache space than IPv4-only. >=20 > Best regards, > Bing >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 11 05:01:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275F1B2879 for ; Fri, 11 Jul 2014 05:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ldUJPCtAAXbI for ; Fri, 11 Jul 2014 05:01:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B7C1B2877 for ; Fri, 11 Jul 2014 05:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1700; q=dns/txt; s=iport; t=1405080086; x=1406289686; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=q4+aPervZkkdt+IenRrffDg9sy1rvQ40MKxoN5xJEvg=; b=J3/nzx/DqZlfk8cmYJfpxlqbL9RwDLDAHmtVQdFi7l0Je6GLThjDviNX NXQmAdU3t+amF+v8fsWGCyGXWzDqF1f1IeHYFFgNRf3FJquEIHDJC69Vf PluTVrf3K+uvg/QTi3+IhV8hbPpUF50sZuo+UYL+AGdTN6oIcscugtX0C s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwHABfRv1OtJV2d/2dsb2JhbABZgw6BLKwBAQEBBQFumzwBgQwWdYQDAQEBAwE4Aj0CBQsLOwtOCQYOI4gcCMZ7F4V6iUwHhEMBBK8gggKBRIIu X-IronPort-AV: E=Sophos;i="5.01,642,1400025600"; d="scan'208";a="336214458" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jul 2014 12:01:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6BC1F1n009907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 12:01:16 GMT Received: from dhcp-10-149-0-20.cisco.com (10.149.0.20) by xhc-aln-x10.cisco.com (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Jul 2014 07:01:15 -0500 Date: Fri, 11 Jul 2014 14:00:54 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.149.0.20] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DXzqJbEY_RF1PXa1lK2bpQAgB1w Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:01:40 -0000 Hi Leo, On Fri, 11 Jul 2014, Liubing (Leo) wrote: > Hi Andrew, > >>> Now there are some enterprise/campus networks under real use or >>> considering using L2 networks. Some are aiming at better user isolation >>> through VLANs (some even consider QinQ mechanism); while some are >>> aiming less configuration/management than the traditional L3 networks. >>> So there would be thousands of hosts aggregated to the core switch >>> (normally there are two core switches stacked together, but only share one >> cache space). >>> As IPv6 is beginning real use, for example, some of the campus networks >>> are already dual-stack, and the majority of the hosts are Win 7, we >>> once observed in one campus that DHCPv6/SLAAC are both enabled, each >>> Win 7 host had 4 IPv6 addr (SLAAC+DHCPv6+Privacy+link-local)+1 IPv4 addr. >> >> If the majority of the hosts are Win 7, and are under the control of the >> administrator, this looks more like a misconfiguration rather than anything >> else: clear the "A" bit on the prefix, and they'll half the address usage - down >> to just link-local and DHCPv6-based. > > [Bing] I can hardly say SLAAC and DHCPv6 co-existing is a misconfiguration, Note, I said "for this specific case". If you control your devices *and* devices are DHCPv6-capable *and* you want to minimize the number of addresses using SLAAC is not ideal. > but I agree DHCPv6-only deployment can partly relieve the problem. > However, even DHCPv6-only would have 2 IPv6 addr+1 IPv4 addr, which > would cause approximately 5~8 times cache space than IPv4-only. You can work towards turning off IPv4. Past that - it's just protocol's properties. --a From nobody Fri Jul 11 06:07:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E7A1B28EB for ; Fri, 11 Jul 2014 06:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Hru_huNhFyDs for ; Fri, 11 Jul 2014 06:07:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995081B282E for ; Fri, 11 Jul 2014 06:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1405084057; x=1406293657; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=WLbE3eFrrq4HF70wU2qgmtuiZuKxOhRfFfmJu+zORh4=; b=SLzUnnvLdq6w3PJ6uPdG1mH6zOfewKyVjJwB1M8OmHqVg+AVQToNBgZV 71B5FGAc6/nQv2pb9KxETbPtRHfXbSvOqclJGMHz+iPmG2s/nap9iCKG+ ZBcWFHvicmrd9Di8Pst2OXtcN691eCgrd0wIu7hTx34JqeUxFZC79SvrV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHAM7gv1OtJV2S/2dsb2JhbABZgw5SWqwCAQEBBQFuk3AMh0ABgQoWdYQDAQEBAwEBAQE1AjQJAgULCxgjCycnCQYOBR6IHAgNxlAXhXqEAoVKB4RDAQScT5JRggKBRGqBRA X-IronPort-AV: E=Sophos;i="5.01,643,1400025600"; d="scan'208";a="60074123" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP; 11 Jul 2014 13:07:36 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6BD7HMn022377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 13:07:17 GMT Received: from dhcp-10-149-0-20.cisco.com (10.149.0.20) by xhc-aln-x10.cisco.com (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Jul 2014 08:07:17 -0500 Date: Fri, 11 Jul 2014 15:06:59 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Jared Mauch In-Reply-To: <27F9B16E-6026-42CC-A0C6-64687C6997F0@puck.nether.net> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> <27F9B16E-6026-42CC-A0C6-64687C6997F0@puck.nether.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.149.0.20] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NQLPEajDoIRAnXmsbvPthzP7v4g Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 13:07:32 -0000 On Fri, 11 Jul 2014, Jared Mauch wrote: > Apple believes the coexistence of slaac and dhcp6 are a problem and close defects as "3rd party problem won't fix" when raised with them. Looks like this might be a useful addition to the http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01#section-3.4, or, rather, one more problem in section 2 and reference it from section 3.4. --a > > Jared Mauch > >> On Jul 11, 2014, at 5:40 AM, "Liubing (Leo)" wrote: >> >> Hi Andrew, >> >>>> Now there are some enterprise/campus networks under real use or >>>> considering using L2 networks. Some are aiming at better user isolation >>>> through VLANs (some even consider QinQ mechanism); while some are >>>> aiming less configuration/management than the traditional L3 networks. >>>> So there would be thousands of hosts aggregated to the core switch >>>> (normally there are two core switches stacked together, but only share one >>> cache space). >>>> As IPv6 is beginning real use, for example, some of the campus networks >>>> are already dual-stack, and the majority of the hosts are Win 7, we >>>> once observed in one campus that DHCPv6/SLAAC are both enabled, each >>>> Win 7 host had 4 IPv6 addr (SLAAC+DHCPv6+Privacy+link-local)+1 IPv4 addr. >>> >>> If the majority of the hosts are Win 7, and are under the control of the >>> administrator, this looks more like a misconfiguration rather than anything >>> else: clear the "A" bit on the prefix, and they'll half the address usage - down >>> to just link-local and DHCPv6-based. >> >> [Bing] I can hardly say SLAAC and DHCPv6 co-existing is a misconfiguration, but I agree DHCPv6-only deployment can partly relieve the problem. >> However, even DHCPv6-only would have 2 IPv6 addr+1 IPv4 addr, which would cause approximately 5~8 times cache space than IPv4-only. >> >> Best regards, >> Bing >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jul 11 06:16:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47311A03B9 for ; Fri, 11 Jul 2014 06:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QOd_WL2_WWtk for ; Fri, 11 Jul 2014 06:16:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225521A02FC for ; Fri, 11 Jul 2014 06:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=375; q=dns/txt; s=iport; t=1405084614; x=1406294214; h=date:from:to:cc:subject:message-id:mime-version; bh=0DeyTWm4zho/xPwaqpt6EuMQcg/kjued7ev8DU6T1S8=; b=THMxQeZ7cuPvZ4GZnKmYlktrHU8QomfgnQQra6jovcRefe6rYfpwaZuz dCIxdbLyCROU9ER1wJsfp8EUQY4rvyha94Q3XQmW0E5KqGU+gazvnXTjj NQFe+feLOzi+WnZyt8teSGPG7OExhhfZ+hwc++BmF0ZKN0tcMjSd4HBvj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAHAFvjv1OtJA2E/2dsb2JhbABZgw5SWqtzDwEBAQUBbpN8h0CBCxZ1hEICP4E+DohHDcY/F4V6iH5OhEoFnE+SUYNGgi4 X-IronPort-AV: E=Sophos;i="5.01,643,1400025600"; d="scan'208";a="339296653" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jul 2014 13:16:53 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6BDGblI007327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 11 Jul 2014 13:16:37 GMT Received: from dhcp-10-149-0-20.cisco.com (10.149.0.20) by xhc-aln-x10.cisco.com (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Jul 2014 08:16:37 -0500 Date: Fri, 11 Jul 2014 15:16:19 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "v6ops@ietf.org" Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.149.0.20] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MvkzAFSouou3BJ_iLJ--BIGo-NY Cc: ydesmouc@cisco.com Subject: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 13:16:40 -0000 hi all, last IETF there were presentations about ND, multicast and power usage on the WiFi, the consensus was we need more data on it. Yoann did a nontrivial amount of work on this subject in the meantime and we'd like to show it to you and hear your feedback. http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 thanks a lot! --a From nobody Fri Jul 11 09:14:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7F1B2B55 for ; Fri, 11 Jul 2014 09:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 fRCTaNW-vhK5 for ; Fri, 11 Jul 2014 09:14:11 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AA71B2B54 for ; Fri, 11 Jul 2014 09:14:11 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 35d00c35.2abfdb411940.6742378.00-2476.18666935.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:14:11 +0000 (UTC) X-MXL-Hash: 53c00d5316bdf07e-77f2459a4c598cb95fe6961689590950d33bc775 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 94d00c35.0.6742310.00-2138.18666702.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:14:01 +0000 (UTC) X-MXL-Hash: 53c00d493c75db2c-008ceebd5711e41fd81f87e441b27fc02d1594c5 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 s6BGE0QM004462; Fri, 11 Jul 2014 12:14:00 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGDrp1004241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:13:54 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 11 Jul 2014 16:13:41 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.28]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:13:41 -0400 From: "STARK, BARBARA H" To: Andrew Yourtchenko , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage Thread-Index: AQHPnQpkaOS7jT4BIkuc/rXYfGQhEpubByRg Date: Fri, 11 Jul 2014 16:13:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E07765@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: [135.70.50.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=GTczqEs86RQA:10 a=ofMgfj31e3cA:10 a=1LTgPvdqYhsA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=8PybbigE-IkOPRM] X-AnalysisOut: [mkCIA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA] X-AnalysisOut: [:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qiFOvu0-ne5lSEnOPSmDnMuWA9s Cc: "ydesmouc@cisco.com" Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 16:14:13 -0000 Thanks for sharing. This is a very good thought-provoking paper, and I'm im= pressed with the research that was done. An assumption I'd like to challenge is the one that putting multicast snoop= ing on router/AP Wi-Fi interfaces is "costly in terms of resources and comp= lexity for small systems like home boxes". I have some experience in requir= ing this of CE router vendors (it's absolutely required in CE routers that = support IPTV services because we can't have huge multicast streams flooding= the Wi-Fi connection when a single Wi-Fi device joins a stream). While oth= er aspects of multicast handling have proven difficult to get right (IGMP p= roxy between WAN and LAN), the snooping on the Wi-Fi interface has not prov= en to be a problem. My personal suspicion is that "costly in terms of resou= rces and complexity" is an excuse given by those who don't want to put in t= he effort to actually look into and do it. I also suspect that it would be = holistically more cost-effective to put multicast snooping on router/AP Wi-= Fi interfaces than to put the L2 multicast filter on all end devices (one o= f the options described in the paper). Barbara > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Andrew > Yourtchenko > Sent: Friday, July 11, 2014 9:16 AM > To: v6ops@ietf.org > Cc: ydesmouc@cisco.com > Subject: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6= - > mcast-wifi-power-usage >=20 > hi all, >=20 > last IETF there were presentations about ND, multicast and power usage on > the WiFi, the consensus was we need more data on it. >=20 > Yoann did a nontrivial amount of work on this subject in the meantime and > we'd like to show it to you and hear your feedback. >=20 > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power- > usage-00 >=20 > thanks a lot! >=20 > --a >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Jul 12 08:28:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9A41B2B07 for ; Sat, 12 Jul 2014 08:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 gGxJK4N2O5G6 for ; Sat, 12 Jul 2014 08:28:53 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B861B2914 for ; Sat, 12 Jul 2014 08:28:53 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so4349095vcb.16 for ; Sat, 12 Jul 2014 08:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GViS/L6b8y1yXz/UyTrXHxN8TjQb3f3eZemzzFv+9rs=; b=iRbXos86YSuGbeCmYJLMJ/YYMFmKj0l99YnI1aV0LyOG0CxdlkqExI13Khy5gc49JK BHCSDKqbvFH6eAfZ8mK02xz/iVOxo5ie4N7hYGQMhJZhfBwoAMLbSbEUORWfLVqPSqyS y//4Ghj4whrO3DxUaxgaAhLpGSip6+1WKkLLEUDfWhd+Rfdq5juG/Js0c4idD/6TptQS 2TYZMI8CTL1Pg/4nxlrI55lGFuohRQGtSQ8NHScYZ5MhTeqZ9ReTUAFuvBFcZFvOWj/p sT7dY9wEiVzeacOCl6GrsEjqKkTw0PO+H1fwka4m9ACTiiMgO9nS1ML/2j+AGa9joQNj pBwg== X-Received: by 10.58.150.136 with SMTP id ui8mr5977227veb.14.1405178932395; Sat, 12 Jul 2014 08:28:52 -0700 (PDT) Received: from [192.168.124.102] ([190.78.213.19]) by mx.google.com with ESMTPSA id kh8sm2808296vec.8.2014.07.12.08.28.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 08:28:51 -0700 (PDT) Message-ID: <53C114E8.7020404@gmail.com> Date: Sat, 12 Jul 2014 06:28:48 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VVeDPs439yahcG0-dWCHdDrUYYQ Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 15:28:54 -0000 Hello, Very nice draft and very interesting results. While reading it I was thinking that certain drafts could include something like a "Enviroment friendly section". Alejandro, El 7/11/2014 8:46 AM, Andrew Yourtchenko escribi: > hi all, > > last IETF there were presentations about ND, multicast and power usage > on the WiFi, the consensus was we need more data on it. > > Yoann did a nontrivial amount of work on this subject in the meantime > and we'd like to show it to you and hear your feedback. > > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 > > thanks a lot! > > --a > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Jul 13 18:26:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A311A023F for ; Sun, 13 Jul 2014 18:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 nW5fxiIS66av for ; Sun, 13 Jul 2014 18:26:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B758F1A0218 for ; Sun, 13 Jul 2014 18:26:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX74748; Mon, 14 Jul 2014 01:26:44 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 02:26:43 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 09:26:39 +0800 From: "Liubing (Leo)" To: Jared Mauch Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPnPWZEoY/MBJp2UysHWGIZEB+RJueytfg Date: Mon, 14 Jul 2014 01:26:38 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2C70@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> <27F9B16E-6026-42CC-A0C6-64687C6997F0@puck.nether.net> In-Reply-To: <27F9B16E-6026-42CC-A0C6-64687C6997F0@puck.nether.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WiwYRfGrjY3ev7Bbn-IO7t2u7w8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 01:26:47 -0000 Hi Jared, > Apple believes the coexistence of slaac and dhcp6 are a problem and close > defects as "3rd party problem won't fix" when raised with them. [Bing] This is interesting. Would you mind providing a pointer for more det= ailed information? Does Apple consider dhcpv6/slaac co-existence as a probl= em in general, or just in some specific cases?=20 Best regards, Bing From nobody Sun Jul 13 18:34:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD5C1A023E for ; Sun, 13 Jul 2014 18:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 YMGNEczPr3rh for ; Sun, 13 Jul 2014 18:33:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60F71A0218 for ; Sun, 13 Jul 2014 18:33:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX75092; Mon, 14 Jul 2014 01:33:56 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 02:33:55 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 09:33:53 +0800 From: "Liubing (Leo)" To: Andrew Yourtchenko Thread-Topic: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt Thread-Index: AQHPnP/VZpO9KrP2SUaaf9dQAO2Sl5uey65g Date: Mon, 14 Jul 2014 01:33:52 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2C89@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8EEA21@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F1C32@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F291C@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AB4@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F2AF9@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bK8nz-1viGeuNsQ0rV3rYRaSm8U Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 01:34:00 -0000 Hi Andrew, > > [Bing] I can hardly say SLAAC and DHCPv6 co-existing is a > > misconfiguration, >=20 > Note, I said "for this specific case". If you control your devices *and* = devices > are DHCPv6-capable *and* you want to minimize the number of addresses > using SLAAC is not ideal. [Bing] For this case, I think you're right. It might be good to add some te= xts regarding to the cache table problem in http://tools.ietf.org/html/draf= t-liu-v6ops-dhcpv6-slaac-guidance-01 Thanks. Best regards, Bing From nobody Sun Jul 13 21:30:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138511A02ED; Sun, 13 Jul 2014 21:30:01 -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, SPF_PASS=-0.001] autolearn=ham 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 PvZ2U9StOnDc; Sun, 13 Jul 2014 21:29:59 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544221A02EC; Sun, 13 Jul 2014 21:29:59 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id fp1so1178830pdb.19 for ; Sun, 13 Jul 2014 21:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+cd6+vjRdCcmam3O6LwKu3YbsMT5+KeHLiTcovA8ORk=; b=RcDSXseeW0+m6488i9YAYp3uhRKjpAFF76jdJYpDbPDicT/PpPKcQtXEUbI3ZhXNlf JU+JAQXyIeecGGEd0cu08R/gJPmRRa6cW+sZ+uLN5GKMnu29PEnI6GT7cQJLmo+cF1yY LYupq/hZSWIfs98Ad7wFr70Eh4N5eEVR9WbE6UwkKLNVeDoQLs6YsmHvYrmvpMQ19RMq Rk5o8FX/FaUHtK9d+R76/JsBh00l+S0uY9SSG77M8gQMGAMXuog1vsH3MxRxqRyEI1q2 g2sLMq3QRZXQ5BBf8Cn8rZ0K9Sz18qPzyrTn6eq46aoKvrSOUdAYCuETd6VwekcAUQZG fZQw== X-Received: by 10.68.68.131 with SMTP id w3mr14523726pbt.90.1405312198852; Sun, 13 Jul 2014 21:29:58 -0700 (PDT) Received: from [192.168.178.23] (232.198.69.111.dynamic.snap.net.nz. [111.69.198.232]) by mx.google.com with ESMTPSA id wp3sm9320627pbc.67.2014.07.13.21.29.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jul 2014 21:29:58 -0700 (PDT) Message-ID: <53C35CC4.2070304@gmail.com> Date: Mon, 14 Jul 2014 16:29:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> In-Reply-To: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xec2oO4MGm2H_nIClIAovnDwD7E Cc: opsec@ietf.org, IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 04:30:01 -0000 Hi, (Excuse cross posting but I'm sure v6ops folk will have an opinion, and I'm not on opsec.) Thanks for starting this work. First, a general point. I think you need to be much clearer in the Introduction that there are rules in RFC 7045 that need to be followed. The advice that you give later is all conditional on those rules being applied first. In particular, 7045 has this requirement: > If a forwarding node discards a packet containing a standard IPv6 > extension header, it MUST be the result of a configurable policy and > not just the result of a failure to recognise such a header. This > means that the discard policy for each standard type of extension > header MUST be individually configurable. The default configuration > SHOULD allow all standard extension headers. There is also a reminder in the Security Considerations that this requirement applies to firewalls. You need to be explicit, perhaps, that you are advising operational configurations, not changing the implementation defaults required by RFC 7045. It was out of scope for 7045, but IMHO we should have the same rule for IPv6 options: provide a configuration switch (allow/drop) for each one, and a reasonable default. You could certainly suggest that. I won't comment in detail on the options - at a quick glance, your suggested defaults seems about right. Now some more specific comments on the extension headers: > 2.3.1.1. Uses > > > The Hop-by-Hop Options header is used to carry optional information > that must be examined by every node along a packet's delivery path. In fact, RFC 7145 changes that: > 2.2. Hop-by-Hop Options > > The IPv6 Hop-by-Hop Options header SHOULD be processed by > intermediate forwarding nodes as described in [RFC2460]. However, it > is to be expected that high-performance routers will either ignore it > or assign packets containing it to a slow processing path. You could s/must/should/. More important: > 2.3.1.5. Advice > > > Intermediate systems should, by default, drop packets containing a > IPv6 Hop-by-Hop Option Extension Header. You can't say that! Firstly, RFC 7045 makes it permissible to simply ignore them. That's the simplest DoS defence. Secondly, well, dropping them is the wrong default because it breaks stuff. You could discuss whether to inspect them for valid contents, and you could discuss rate-limiting, which I understand some vendors support already. > 2.3.2. Routing Header for IPv6 (Number=43) ... > 2.3.2.5. Advice > > > Drop packets containing a RHT0. In fact there is considerably more detailed guidance already in RFC 7045 (last paragraph of section 2.1). I think you should send the reader to that. > 2.3.9. Shim6 Protocol (Number=140) ... > 2.3.9.3. Specific Security Implications > > > TBD. You could mention that shim6 uses CGA or HBA cryptographic addresses to prevent a 3rd party hijacking a session by forging shim6 headers with a bogus address. There is an extensive security discussion in RFC 5533. > 2.3.10. Use for experimentation and testing (Numbers=253 and 254) ... > 2.3.10.5. Advice > > > Routers, security gateways, and firewalls SHOULD have configuration > knobs for IP packets that contain this extension header to select > between "ignore & forward" and "drop & log". Well, you might prefer to put that text at the top, since RFC 7045 requires all headers to have a configuration option. To be precise, 7045 says: > Experimental IPv6 extension headers SHOULD be treated in the same way > as standard extension headers, including an individually configurable > discard policy. However, the default configuration MAY drop > experimental extension headers. Regards Brian From nobody Sun Jul 13 23:55:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301E91A0322; Sun, 13 Jul 2014 23:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Q7Il6VCGye8w; Sun, 13 Jul 2014 23:55:22 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA8D1A0320; Sun, 13 Jul 2014 23:55:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4E3CFA1; Mon, 14 Jul 2014 08:55:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1405320917; bh=AR/Nj4RK1F7IG76UYL0GT0PclUh46mkC7uV2e9+CAr0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Y2Qte1AasdwH2IiGu56bytTrdP8IBY+TcIOIh0iQ6FLYfcEOWoc0H3JTtvjxmRlYm JJTeZ2pdunQqp23V1NtTzcPXEwbC5rXYbfNILTMKChOQMLAFaGE4HB3r7opif10tgS os1QRGDzr4u+oYhFjn3HayqHkFwWv+2szzDHLPDw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 433239F; Mon, 14 Jul 2014 08:55:17 +0200 (CEST) Date: Mon, 14 Jul 2014 08:55:17 +0200 (CEST) From: Mikael Abrahamsson To: draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org In-Reply-To: <53C35CC4.2070304@gmail.com> Message-ID: References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NBRg5jVIuI7b-PWHxRllXSqTiMw Cc: opsec@ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 06:55:24 -0000 On Mon, 14 Jul 2014, Brian E Carpenter wrote: > Hi, > > (Excuse cross posting but I'm sure v6ops folk will have an opinion, > and I'm not on opsec.) Yes, at least I do. Thanks for bringing it to v6ops attention. Weird thing, I can't even find the original announcement neither in my opsec nor v6ops folder. Oh, well. Feedback: I find this document advocates dropping things way too much. It uses the term "intermediate" devices. I would like this split up into two types of devices, a "pure packet forwarding device" (=core router), and a "security inspection device" (=device that might have ACLs or being a stateful firewall). I believe a core router which just forwards packets, should not drop packets because of options it can't handle very well. If it can't handle a lot of hop-by-hop header packets, then don't inspect these hop-by-hop header packets, just forward the packets without looking at them. The thought of our core networks limiting what we can and can't do in the future with IPv6, makes me a sad panda. I can understand devices that enforce some kind of security to drop packets they don't understand, but generally recommending blanket dropping of some packets in the core because of potential edge problems, that just doesn't make sense to me. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Jul 14 02:22:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ECE1A0167 for ; Mon, 14 Jul 2014 02:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 XS-43EV0EpSs for ; Mon, 14 Jul 2014 02:22:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C53C1A0051 for ; Mon, 14 Jul 2014 02:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1486; q=dns/txt; s=iport; t=1405329739; x=1406539339; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=HmRc5EQ6Z3d1Ch6Nke3biIQnAaPnLyo4Fk1+/YCIT1c=; b=Q0q4MMYhG+GfHpiBt3JTRacVqeSOEsi7lyOnYCwLLTsBSz0NpatwjA+3 bTSgu8dch5KOQ8c9Vf0A4FRZT6nJ7Sc+LoDqUfBOYQjSIFShmg9FXg4vP ca4FIXiQwcRcVUXuB0dlukVplCHeClrNNGAJGWeoS9uBZhBhvPW1ZJRJP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkKAI2gw1OtJV2Y/2dsb2JhbABZgw5SWqwQAQEBAQEBBQFulDIMh0EBgRgWdYQEAQEDAQEBAWsLBQsLRicwBg4FiDoIDccyF4V7iQJOB4RDAQSKIpI2klOCAoFEgi4 X-IronPort-AV: E=Sophos;i="5.01,657,1400025600"; d="scan'208";a="339807967" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jul 2014 09:22:18 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6E9MIYp015290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 09:22:18 GMT Received: from dhcp-10-149-0-103.cisco.com (10.149.0.103) by xhc-aln-x14.cisco.com (173.36.12.88) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 14 Jul 2014 04:22:18 -0500 Date: Mon, 14 Jul 2014 11:22:02 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Alejandro Acosta In-Reply-To: <53C114E8.7020404@gmail.com> Message-ID: References: <53C114E8.7020404@gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2102602757-1405329739=:23928" X-Originating-IP: [10.149.0.103] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I-tCbw2E_YUOuBmEt2-uBs8m5Sw Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 09:22:21 -0000 --0-2102602757-1405329739=:23928 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8BIT Alejandro, interesting idea. Could you elaborate a bit more ? I'm guessing it would be something to do with the power consumption, but estimating the power consumption in the generic case is really really tricky, so I am wondering how this kind of section might look like to be useful. thanks! --a On Sat, 12 Jul 2014, Alejandro Acosta wrote: > Hello, > Very nice draft and very interesting results. While reading it I was > thinking that certain drafts could include something like a "Enviroment > friendly section". > > Alejandro, > > > El 7/11/2014 8:46 AM, Andrew Yourtchenko escribi: >> hi all, >> >> last IETF there were presentations about ND, multicast and power usage >> on the WiFi, the consensus was we need more data on it. >> >> Yoann did a nontrivial amount of work on this subject in the meantime >> and we'd like to show it to you and hear your feedback. >> >> http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 >> >> thanks a lot! >> >> --a >> >> _______________________________________________ >> 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 > --0-2102602757-1405329739=:23928-- From nobody Mon Jul 14 14:29:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4231A0118 for ; Mon, 14 Jul 2014 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 Pq9rFCjqJWgF for ; Mon, 14 Jul 2014 14:29:20 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5C11A00B9 for ; Mon, 14 Jul 2014 14:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=893; q=dns/txt; s=iport; t=1405373360; x=1406582960; h=from:to:cc:subject:date:message-id:mime-version; bh=p6WLLbaGw0XTiY+oE1nvJjd3/RVCX+S7VuyClz2PlmE=; b=aN+Nbt1Q3Z5azTT2URPqWKq6cgm11kpDjX5FOPvbiYMF0PycTd/sdJUf RqWXLQRWFA0pbggmZJGy948mqr2ihX2UKX1+spX/edwcie4otTEZ4mFGE 7780+ldOCojge+kaeYT0HDVppeJopvRdU6pV2GLoCVDpwD+UObqig48Kf w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQOAIBKxFOtJA2L/2dsb2JhbABZgw5SWAONGrQ5h0OBFBZ1hAp5EgGBAA8YBA4OBYg0DchmF45pEQFQgzSBFgWSL4FFhxqUHoNEgXc5 X-IronPort-AV: E=Sophos;i="5.01,660,1400025600"; d="asc'?scan'208";a="60730607" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 14 Jul 2014 21:29:09 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6ELT9nM027619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 21:29:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 16:29:09 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Agenda posted Thread-Index: AQHPn6qlbEqx6Nao/kKRhEYj/isDVg== Date: Mon, 14 Jul 2014 21:29:08 +0000 Message-ID: <74C99007-D312-4B2C-92BF-CB37A4603C44@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_07C76501-B737-4793-926A-6F1F465C4F8C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YCz2QY0e8ockOiVNA_O40I308m4 Subject: [v6ops] Agenda posted X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 21:29:21 -0000 --Apple-Mail=_07C76501-B737-4793-926A-6F1F465C4F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The v6ops agenda for IETF 90 has been posted, at = http://www.ietf.org/proceedings/90/agenda/agenda-90-v6ops If you want to bash the agenda, reply to this email. That will save us = time in the meeting. --Apple-Mail=_07C76501-B737-4793-926A-6F1F465C4F8C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTxEuibjEdbHIsm0MRAiEJAKDjJpgj0n7Dm9pGaXObuZ+gHErhDACgp9Hw iKGAMK9yjvj/1bLO3e7fYeQ= =QCjA -----END PGP SIGNATURE----- --Apple-Mail=_07C76501-B737-4793-926A-6F1F465C4F8C-- From nobody Mon Jul 14 14:30:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0DD1B27AA for ; Mon, 14 Jul 2014 14:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 5Tcpud4wxr25 for ; Mon, 14 Jul 2014 14:30:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED40F1B27B3 for ; Mon, 14 Jul 2014 14:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=721; q=dns/txt; s=iport; t=1405373415; x=1406583015; h=from:to:cc:subject:date:message-id:mime-version; bh=yE3MmAPZfAFIV/+yKiNXGzaY0vcslqQpylkMhZelbxk=; b=Ahp+PxbNaP6NKTGBkqD3yYj3lEGjzpj5XVpfR3H1Dt+QtiUlHXUXaMc4 pr9QUVeZaC2Gm1d92+a5YbIwSLKmxXHOyKMtGoAHfbwMdeDLs6cTdzQka xKqRDU7CXjxAmKWUT/yU1nYlM/Ar6/aCYmGisP2czGUL3Q0vH9Nk5Dq+Z 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYMAMJKxFOtJA2N/2dsb2JhbAA4IYMOgS2NGrt8gRQWdYQKeRIBgQAUEwQOBQ6INMhzF49LgzSBFgWSL4FFhxqUHoNEgjA X-IronPort-AV: E=Sophos;i="5.01,660,1400025600"; d="asc'?scan'208";a="339971843" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jul 2014 21:30:14 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6ELUEqm015555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 21:30:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 16:30:13 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Need jabber Scribe and minutes taker for v6ops at IETF 90 Thread-Index: AQHPn6rM3/19PpTIvkyCzLlgXcvzEA== Date: Mon, 14 Jul 2014 21:30:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_095A901D-9AC4-4491-B705-D0DD125BAF83"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UhzF6BoN4W7Fb7DZwJPpnpTp7eM Subject: [v6ops] Need jabber Scribe and minutes taker for v6ops at IETF 90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 21:30:16 -0000 --Apple-Mail=_095A901D-9AC4-4491-B705-D0DD125BAF83 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Reply to v6ops-chairs@tools.ietf.org, please. --Apple-Mail=_095A901D-9AC4-4491-B705-D0DD125BAF83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTxEvjbjEdbHIsm0MRAroNAJwLAH/wd8kj/qdNHb9bQ+toJ9hVBwCgheu1 QiphKTiCtkcrajbcdraxD24= =BFPL -----END PGP SIGNATURE----- --Apple-Mail=_095A901D-9AC4-4491-B705-D0DD125BAF83-- From nobody Tue Jul 15 07:49:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2B11B28C3 for ; Tue, 15 Jul 2014 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 9XeU3P9D201q for ; Tue, 15 Jul 2014 07:47:43 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AD91B28D1 for ; Tue, 15 Jul 2014 07:45:19 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so367797ykp.4 for ; Tue, 15 Jul 2014 07:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DMaKJmg90NHCSulzXGSU2CQsB7KXHiw05yJ3lKxB0ok=; b=0uHsbSC0LhwX/SQEZ6RQXyjWwrlU14weLkoAlDj3uJNFgg8wIvPrhJxnGNWdw6goRW 3bUB79e4ORMYl7YmzoX8ZCOZ8VCUyAs5ZSAI1yg+Q8tOEl3+6zbvPU/3bka1FrEEI4ka Hs1GXxoyQvozKqGWvRwKiPGNrvpUVQN0chjnjRMFmhBeMtJnuMUfCMB0hTx+sW8FPVNQ cVT4MmYsT6hczxcHgxi36QY/Q0zIaw94pEbJJ8NMWuXQwmh/xU1MWQZ0kie40lnjkz4q Qf28wN7D/n8RjcqKp7H0LQ00WJP2fXww0paA3q52rADAAhcIdB70SOZawopr2MrlDine k3qg== X-Received: by 10.236.220.33 with SMTP id n31mr5747268yhp.151.1405435518511; Tue, 15 Jul 2014 07:45:18 -0700 (PDT) Received: from [192.168.99.64] ([201.221.226.50]) by mx.google.com with ESMTPSA id p55sm27133203yhh.34.2014.07.15.07.45.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 07:45:17 -0700 (PDT) Message-ID: <53C4FF39.2070600@gmail.com> Date: Tue, 15 Jul 2014 05:45:21 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andrew Yourtchenko References: <53C114E8.7020404@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yedgGRf2oaSKNGssVQBcTdJm4JQ Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:47:45 -0000 Hi Andrew, My only comment inline: El 7/14/2014 4:52 AM, Andrew Yourtchenko escribi: > Alejandro, > > interesting idea. Could you elaborate a bit more ? I'm guessing it would > be something to do with the power consumption, but estimating the power > consumption in the generic case is really really tricky, so I am > wondering how this kind of section might look like to be useful. Thanks for asking, in fact after I sent I got stuck thinking in this topic. While reading http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 I was thinking that probably some drafts or documents might include an environmental section which should be related to green stuff such as power consumption and things no harmful for the environment. Trying to elaborate a bit more the idea would be something very similar to the current Security section which is mandatory. If we include an environmental section it could help IETF to develop better and more friendly protocols to the environment. Is it time to do it?, If we want to be idealistic low power consumption should be encourage in all areas -not only mobile-, devices should be able to get in sleep mode without affecting the network and much more (CPU processing, etc). My 2 cents, Alejandro, > > thanks! > > --a > > On Sat, 12 Jul 2014, Alejandro Acosta wrote: > >> Hello, >> Very nice draft and very interesting results. While reading it I was >> thinking that certain drafts could include something like a "Enviroment >> friendly section". >> >> Alejandro, >> >> >> El 7/11/2014 8:46 AM, Andrew Yourtchenko escribi: >>> hi all, >>> >>> last IETF there were presentations about ND, multicast and power usage >>> on the WiFi, the consensus was we need more data on it. >>> >>> Yoann did a nontrivial amount of work on this subject in the meantime >>> and we'd like to show it to you and hear your feedback. >>> >>> http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 >>> >>> >>> thanks a lot! >>> >>> --a >>> >>> _______________________________________________ >>> 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 Tue Jul 15 16:31:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432471A0172; Tue, 15 Jul 2014 16:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Ymm62sjUDFJ6; Tue, 15 Jul 2014 16:30:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 1CA161A0164; Tue, 15 Jul 2014 16:30:53 -0700 (PDT) Received: from r200-40-240-99.su-static.anteldata.net.uy ([200.40.240.99] helo=[10.0.135.233]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7CBL-0008OR-Si; Wed, 16 Jul 2014 01:30:49 +0200 Message-ID: <53C57F39.7080800@gont.com.ar> Date: Tue, 15 Jul 2014 16:21:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> In-Reply-To: <53C35CC4.2070304@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eWcyT16uHJWV8JP6bSAepBA4JwQ Cc: opsec@ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:30:56 -0000 Hi, Brian, Thanks so much for your feedback! Please find my comments in-line... On 07/14/2014 01:29 AM, Brian E Carpenter wrote: > > Thanks for starting this work. > > First, a general point. I think you need to be much clearer in the > Introduction that there are rules in RFC 7045 that need to be followed. > The advice that you give later is all conditional on those rules being > applied first. In particular, 7045 has this requirement: > >> If a forwarding node discards a packet containing a standard IPv6 >> extension header, it MUST be the result of a configurable policy and >> not just the result of a failure to recognise such a header. This >> means that the discard policy for each standard type of extension >> header MUST be individually configurable. We will try to make this explicit -- but yes, we were assuming this (the filtering rules not being the result of failure to recognise a header, etc.). > The default configuration > SHOULD allow all standard extension headers. > > There is also a reminder in the Security Considerations that this > requirement applies to firewalls. You need to be explicit, perhaps, > that you are advising operational configurations, not changing the > implementation defaults required by RFC 7045. Good point. FWIW, we were kind of hesitating between doing an IPv6 version of RFC7123, and writing a document aimed at firewalls. I'd argue that this one is mostly an IPv6 version of RFC7126 -- i.e., much more permisive than what a firewalls document would be. > It was out of scope for 7045, but IMHO we should have the same rule > for IPv6 options: provide a configuration switch (allow/drop) for > each one, and a reasonable default. You could certainly suggest > that. I'd generally agree with you. The only issue is that for some architectures, doing a per-option-type filtering would imply processing the packet on the slow path.... and this requirement might be deemed as honerous. I guess one could say something like "If you support filtering on a per-option-type basis, then such filtering should be configurable on a per-option-type basis", etc.? > Now some more specific comments on the extension headers: > >> 2.3.1.1. Uses >> >> >> The Hop-by-Hop Options header is used to carry optional information >> that must be examined by every node along a packet's delivery path. > > In fact, RFC 7145 changes that: > >> 2.2. Hop-by-Hop Options >> >> The IPv6 Hop-by-Hop Options header SHOULD be processed by >> intermediate forwarding nodes as described in [RFC2460]. However, it >> is to be expected that high-performance routers will either ignore it >> or assign packets containing it to a slow processing path. > > You could s/must/should/. Will do. Thanks! > More important: > >> 2.3.1.5. Advice >> >> Intermediate systems should, by default, drop packets containing a >> IPv6 Hop-by-Hop Option Extension Header. > > You can't say that! Firstly, RFC 7045 makes it permissible to > simply ignore them. While I understand your point (and agree that RFC7045 is authoritative here), (FWIW) this is what RFC7126 says about Router Alert option, which in some sense is analogous to the HBH EH: ---- cut here ---- This option SHOULD be allowed only in controlled environments, where the option can be used safely. [RFC6398] identifies some such environments. In unsafe environments, packets containing this option SHOULD be dropped. A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Router Alert option. Additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Router Alert option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option. ---- cut here ---- My question is: do we want to do something different with HBH EH than what we do with Router Alert in IPv4? FWIW, defaulting to "ignore" seems sensible to me. >> 2.3.2. Routing Header for IPv6 (Number=43) > ... >> 2.3.2.5. Advice >> >> >> Drop packets containing a RHT0. > > In fact there is considerably more detailed guidance already > in RFC 7045 (last paragraph of section 2.1). I think you should > send the reader to that. Will do. > >> 2.3.9. Shim6 Protocol (Number=140) > ... >> 2.3.9.3. Specific Security Implications >> >> >> TBD. > > You could mention that shim6 uses CGA or HBA cryptographic > addresses to prevent a 3rd party hijacking a session by > forging shim6 headers with a bogus address. There is an > extensive security discussion in RFC 5533. Thanks for the note! >> 2.3.10. Use for experimentation and testing (Numbers=253 and 254) > ... >> 2.3.10.5. Advice >> >> >> Routers, security gateways, and firewalls SHOULD have configuration >> knobs for IP packets that contain this extension header to select >> between "ignore & forward" and "drop & log". > > Well, you might prefer to put that text at the top, since RFC 7045 requires > all headers to have a configuration option. To be precise, 7045 says: > >> Experimental IPv6 extension headers SHOULD be treated in the same way >> as standard extension headers, including an individually configurable >> discard policy. However, the default configuration MAY drop >> experimental extension headers. Our bad :-( -- will cite RFC7045 as appropriate. Thanks so much! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Jul 15 17:08:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B141B2999; Tue, 15 Jul 2014 17:08:25 -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, SPF_PASS=-0.001] autolearn=ham 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 59WzYqPkBZic; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE34F1A01D0; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so185550pde.23 for ; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/mHOiE71DLmwXK56st2CE4KNHSYtCYlryBxkJkM6Gmg=; b=FNGKID6Ssvn6oqaOy9ZiVdoYUL2/Ff5ijmoqaUBG/1ascOZiqhphVIm+QWw3eQZ0JS FTrh4y0BziH5yZLYaWs2Hw+QXijkJGHDpGkLF7qSABjjG/oDbznh0zdebJn2d5x3bFvH 73TwLxUA5xjfe9uRjryr7nf6SxdrSBsGQR3+HcTuiblLHIzRUdfIm9MCrwFvh4y4Xb5W +/tAbPmk+elMXUA+hy/r0Nive7TRQXsz0QAwaKkJMj1zqQO3zxnzBY1Y6gD4jfV90oNC nenj8Y+frdiZHczQ2c7tH9hZcIDTvz1hC+rzuX88MfzjblkoAqL3Ty2uJLNAa2Qd3/rH o85g== X-Received: by 10.70.38.1 with SMTP id c1mr17390369pdk.108.1405469303163; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id fv12sm20245109pdb.25.2014.07.15.17.08.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 17:08:22 -0700 (PDT) Message-ID: <53C5C279.2090600@gmail.com> Date: Wed, 16 Jul 2014 12:08:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> In-Reply-To: <53C57F39.7080800@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rPFWU8TESgS-8bkjckJfgL4itLM Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:08:25 -0000 Thanks Fernando, so to focus on your question: > My question is: do we want to do something different with HBH EH than > what we do with Router Alert in IPv4? The problem with both of these great inventions is that a single box on the path that takes the "drop" option breaks everything, whereas "ignore" at least provides best effort service and protects against any specific attack on the middlebox. As far as the destination host goes, HbH can't be any more dangerous than a destination option. I personally don't care much in the IPv4 case, since router alert seems to be a dead duck anyway. It's possible that's going to be the case for HbH, but I think we should give it a chance. > FWIW, defaulting to "ignore" seems sensible to me. I agree, obviously. Regards Brian From nobody Tue Jul 15 17:37:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7E1B27B0; Tue, 15 Jul 2014 17:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 WkJ-UdbSt1La; Tue, 15 Jul 2014 17:37:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99611B27AA; Tue, 15 Jul 2014 17:37:07 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6G0ai8a015004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 17:36:44 -0700 (PDT) Message-ID: <53C5C91C.2020203@isi.edu> Date: Tue, 15 Jul 2014 17:36:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> In-Reply-To: <53C5C279.2090600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xQf0f0bQiRQjxl5IDmawQiiDDW8 Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:37:09 -0000 On 7/15/2014 5:08 PM, Brian E Carpenter wrote: > The problem with both of these great inventions is that a single > box on the path that takes the "drop" option breaks everything, > whereas "ignore" at least provides best effort service and > protects against any specific attack on the middlebox. > As far as the destination host goes, HbH can't be any more > dangerous than a destination option. IPv6 already indicates - inside the option type - what to do if an option isn't supported. Why is honoring that set of flags not the only correct behavior? Joe From nobody Tue Jul 15 17:53:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED83A1B27BB; Tue, 15 Jul 2014 17:53: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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 P5ukmzEFGgV6; Tue, 15 Jul 2014 17:53:13 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 6CFC61B27AB; Tue, 15 Jul 2014 17:53:13 -0700 (PDT) Received: from r200-40-240-99.su-static.anteldata.net.uy ([200.40.240.99] helo=[10.0.135.233]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7DT4-0000Da-FL; Wed, 16 Jul 2014 02:53:10 +0200 Message-ID: <53C5C911.8080905@si6networks.com> Date: Tue, 15 Jul 2014 21:36:33 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> In-Reply-To: <53C5C279.2090600@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UW-t-2IJtsvzE8C1RliNIfIDv_Y Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:53:16 -0000 On 07/15/2014 09:08 PM, Brian E Carpenter wrote: > Thanks Fernando, so to focus on your question: > >> My question is: do we want to do something different with HBH EH than >> what we do with Router Alert in IPv4? > > The problem with both of these great inventions is that a single > box on the path that takes the "drop" option breaks everything, > whereas "ignore" at least provides best effort service and > protects against any specific attack on the middlebox. As noted, I think this options is a sensible one. That said, let me provide a "heads up" on the current state of affairs with respect to IPv6 EHs: +--------------+-----------------+-----------------+----------------+ | Dataset | DO8 | HBH8 | FH512 | +--------------+-----------------+-----------------+----------------+ | Web | 11.88% | 40.70% | 30.51% | | | (17.60%-20.80%) | (31.43%-40.00%) | (5.08%-6.78%) | +--------------+-----------------+-----------------+----------------+ | Mailservers | 17.07% | 48.86% | 39.17% | | | (6.35%-26.98%) | (40.50%-65.42%) | (2.91%-12.73%) | +--------------+-----------------+-----------------+----------------+ | Namerservers | 15.37% | 43.25% | 38.55% | | | (14.29%-33.46%) | (42.49%-72.07%) | (3.90%-13.96%) | +--------------+-----------------+-----------------+----------------+ (DO8: Dest Options Header of 8 bytes, etc.) The numbers indicate the packet drop rate. The numbers within parenthesis indicate the percentage of cases where such packet drops occur in an AS different from that of the destination system. (i.e., this would suggest "think twice before employing IPv6 EHs.. then don't). > As far as the destination host goes, HbH can't be any more > dangerous than a destination option. As long as intermmediate systems ignore them (as suggested in RFC7045). > I personally don't care much in the IPv4 case, since router > alert seems to be a dead duck anyway. It's possible that's > going to be the case for HbH, but I think we should give it > a chance. That's why I raised the question. That said, the numbers I've provided above would suggest that this other duck is dead already, too. :-( Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 15 17:53:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36B1B29CB; Tue, 15 Jul 2014 17:53:27 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PjSrHYwXO-Bl; Tue, 15 Jul 2014 17:53:22 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 437A41B29D0; Tue, 15 Jul 2014 17:53:22 -0700 (PDT) Received: from r200-40-240-99.su-static.anteldata.net.uy ([200.40.240.99] helo=[10.0.135.233]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7DTD-0000Dh-3C; Wed, 16 Jul 2014 02:53:19 +0200 Message-ID: <53C5CAEE.5080805@si6networks.com> Date: Tue, 15 Jul 2014 21:44:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , Brian E Carpenter , Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> In-Reply-To: <53C5C91C.2020203@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Mzc7g3NJ0UajCQHw3U1yekpZ_Ms Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:53:27 -0000 On 07/15/2014 09:36 PM, Joe Touch wrote: > > On 7/15/2014 5:08 PM, Brian E Carpenter wrote: >> The problem with both of these great inventions is that a single >> box on the path that takes the "drop" option breaks everything, >> whereas "ignore" at least provides best effort service and >> protects against any specific attack on the middlebox. >> As far as the destination host goes, HbH can't be any more >> dangerous than a destination option. > > IPv6 already indicates - inside the option type - what to do if an > option isn't supported. > > Why is honoring that set of flags not the only correct behavior? Because, with the world as we know it, that ends up killing performance -- with the corresponding implications (DoS) in extreme cases. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 16 09:56:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382D01A007E for ; Wed, 16 Jul 2014 09:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 E5xIdfLWsI-A for ; Wed, 16 Jul 2014 09:56:50 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7861A0084 for ; Wed, 16 Jul 2014 09:56:50 -0700 (PDT) Received: (qmail 15160 invoked from network); 16 Jul 2014 09:56:46 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jul 2014 09:56:46 -0700 Date: Wed, 16 Jul 2014 09:56:46 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSEC In-Reply-To: <53C5C279.2090600@gmail.com> Message-ID: References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wKNhw8OdAB0yhM6p6gec_q4jk8E Cc: Fernando Gont , V6OPS Subject: Re: [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 16:56:52 -0000 On Wed, 16 Jul 2014, Brian E Carpenter wrote: > The problem with both of these great inventions is that a single > box on the path that takes the "drop" option breaks everything, In that same vein, I wanted to object to this: | 2.3.6. Destination Options for IPv6 (Number=60) | | 2.3.6.1. Uses | | The Destination Options header is used to carry optional information | that need be examined only by a packet's destination node(s). | | 2.3.6.2. Specification | | This Extension Header is specified in [RFC2460]. At the time of this | writing, no options have been specified for this extension header. | | 2.3.6.3. Specific Security Implications | | No security implications are known, other than the general | implications of IPv6 extension headers. | | 2.3.6.4. Operational and Interoperability Impact if Blocked | | None. Even if there were no destination options currently defined -- which in fact is not true -- there is huge operational impact if this extension header is routinely blocked: it would make it impossible to deploy any destination options at all. The damage caused to the Internet by such practices is a recurring theme, and it should be spelled out explicitly here. Failure to do so makes the advice that follows ("Pass packets that contain the Destination Options Header") seem weak and ill-motivated. In fact, however, an examination of the references in the IANA IPv6 options registry indicates that the following destination options have been defined: Hex Value Binary Value Description Reference Status act chg rest 0x04 00 0 00100 Tunnel Encapsulation Limit [RFC2473] PS 0xC9 11 0 01001 Home Address [RFC6275] PS 0x8B 10 0 01011 ILNP Nonce [RFC6744] EXP 0x8C 10 0 01100 Line-Identification Option [RFC6788] PS The text in 2.3.6.2 needs to be reworked to mention these options. Mike Heard From nobody Wed Jul 16 10:10:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CF01A008B; Wed, 16 Jul 2014 10:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 yyiPDkXVDpSF; Wed, 16 Jul 2014 10:10:09 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4202D1A0068; Wed, 16 Jul 2014 10:10:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6GH9vnE009427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Jul 2014 10:09:58 -0700 (PDT) Message-ID: <53C6B1E5.4060905@isi.edu> Date: Wed, 16 Jul 2014 10:09:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: opsec@ietf.org, IPv6 Operations , Internet Area References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> In-Reply-To: <53C5CAEE.5080805@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nAWiBFHJltIftIuVUshdN1Ra2R8 Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:10:10 -0000 Hi, all, I'm including INTAREA in the discussion because this doc seems to be an end-run around intending to deprecate IPv6 HBH options, or at least to redefine the option behavior bits defined in RFC 2460. IMO, that ought to be addressed in INTAREA, not V6OPS. IMO, the real DOS attack here is twofold: 1) vendors who misrepresent their boxes as IPv6-capable at a given packet rate 2) documents, such as this, that invert the Postel Principle into the Gont Principle: - Postel Principle: Be conservative in what you send and liberal in what you receive. - Gont Principle: Be paranoid in what you receive. Just because you receive something you didn't expect, does NOT make it an attack. I sincerely hope there are others who share this view, or we might as well just go straight to the conclusion that IPv6 routers that can't process 128-bit addresses really ought to be OK just forwarding based on the last 32. Joe On 7/15/2014 5:44 PM, Fernando Gont wrote: > On 07/15/2014 09:36 PM, Joe Touch wrote: >> >> On 7/15/2014 5:08 PM, Brian E Carpenter wrote: >>> The problem with both of these great inventions is that a single >>> box on the path that takes the "drop" option breaks everything, >>> whereas "ignore" at least provides best effort service and >>> protects against any specific attack on the middlebox. >>> As far as the destination host goes, HbH can't be any more >>> dangerous than a destination option. >> >> IPv6 already indicates - inside the option type - what to do if an >> option isn't supported. >> >> Why is honoring that set of flags not the only correct behavior? > > Because, with the world as we know it, that ends up killing performance > -- with the corresponding implications (DoS) in extreme cases. > > Cheers, > From nobody Wed Jul 16 15:13:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EE11A0354 for ; Wed, 16 Jul 2014 15:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 qwLDyOg_Nb1L for ; Wed, 16 Jul 2014 15:13:26 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B744E1A0359 for ; Wed, 16 Jul 2014 15:13:24 -0700 (PDT) Received: (qmail 31778 invoked from network); 16 Jul 2014 15:13:16 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jul 2014 15:13:16 -0700 Date: Wed, 16 Jul 2014 15:13:16 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Joe Touch In-Reply-To: <53C6B1E5.4060905@isi.edu> Message-ID: References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gvd4l9PCuLj15vP8JNYd9MA9K84 Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [v6ops] [Int-area] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:13:26 -0000 On Wed, 16 Jul 2014, Joe Touch wrote: JT> I'm including INTAREA in the discussion because this doc seems to be an JT> end-run around intending to deprecate IPv6 HBH options, or at least to JT> redefine the option behavior bits defined in RFC 2460. IMO, that ought to be JT> addressed in INTAREA, not V6OPS. I think this would be within the purview, not of INTAREA, but of 6MAN, which, as noted by Brian Carpenter earlier in this thread, has recently spoken the subject: On Mon, 14 Jul 2014, Brian E Carpenter wrote: BEC> In fact, RFC [7045] changes that: BEC> BEC> > 2.2. Hop-by-Hop Options BEC> > BEC> > The IPv6 Hop-by-Hop Options header SHOULD be processed by BEC> > intermediate forwarding nodes as described in [RFC2460]. However, it BEC> > is to be expected that high-performance routers will either ignore it BEC> > or assign packets containing it to a slow processing path. BEC> BEC> You could s/must/should/. BEC> BEC> More important: BEC> BEC> > 2.3.1.5. Advice BEC> > BEC> > Intermediate systems should, by default, drop packets containing a BEC> > IPv6 Hop-by-Hop Option Extension Header. BEC> BEC> You can't say that! Firstly, RFC 7045 makes it permissible to BEC> simply ignore them. That's the simplest DoS defence. Secondly, BEC> well, dropping them is the wrong default because it breaks stuff. BEC> You could discuss whether to inspect them for valid contents, and BEC> you could discuss rate-limiting, which I understand some vendors BEC> support already. JT> IMO, the real DOS attack here is twofold: JT> JT> 1) vendors who misrepresent their boxes as IPv6-capable JT> at a given packet rate JT> JT> 2) documents, such as this, JT> that invert the Postel Principle into the Gont Principle: JT> JT> - Postel Principle: JT> Be conservative in what you send JT> and liberal in what you receive. JT> JT> - Gont Principle: JT> Be paranoid in what you receive. JT> JT> Just because you receive something you didn't expect, does NOT make it an JT> attack. JT> JT> I sincerely hope there are others who share this view, or we might as well JT> just go straight to the conclusion that IPv6 routers that can't process JT> 128-bit addresses really ought to be OK just forwarding based on the last 32. I've complained before about "default deny" bias harming the internet, and so have many others. It is a real problem. And it appears that both of the factors you mention are responsible for large-scale dropping of packets with IPv6 fragment headers in today's Internet. That being said, it is a different and more hostile Internet than in Postel's day. Under the Postel Principle, something useless but harmless (w.g., the IPv4 stream ID option) would be ignored; nowadays, you will probably find consensus that it is OK, or even desirable, to block things like that. In fairness to Mr. Gont, this draft is MUCH better that the initial versions of the corresponding IPv4 options filtering document. Even it I don't agree with all of them, the filtering recommendations in this draft do seem to motivated by legitimate operational concerns, not blanket paranoia. I think we should move further discussion back to OPSEC and V6OPS. //cmh From nobody Thu Jul 17 07:44:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1D01AC0D2 for ; Thu, 17 Jul 2014 07:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JCv0WqgpQRha for ; Thu, 17 Jul 2014 07:44:31 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (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 652111ABB17 for ; Thu, 17 Jul 2014 07:44:31 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s6HEgo9c000503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jul 2014 10:43:16 -0400 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA1E@nkgeml506-mbx.china.huawei.com> Date: Thu, 17 Jul 2014 10:45:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B2D1F2C-E5D5-4879-A242-1FC9D8BBD478@puck.nether.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA1E@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Thu, 17 Jul 2014 10:43:16 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_GN_L8ScFVV8jjFb4JtH-tVqigk Cc: v6ops WG Subject: Re: [v6ops] Next step of DHCP/SLAAC problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 14:44:33 -0000 Does someone know who to report this python error to:? check out: http://tools.ietf.org/pdf/draft-ietf-v6ops-dhcpv6-slaac-problem-01.pdf - Jared On Jun 18, 2014, at 5:18 AM, Liubing (Leo) = wrote: > Hi all, >=20 > Currently we have 2 v6ops documents regarding with the DHCPv6/SLAAC = interaction problem: > Problem Statement: > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem > Operational Guidelines: > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01 >=20 > The Problem Statement document has been adopted by the WG (we just = uploaded a new version, details to see the other mail), and the = Operational Guidelines document was discussed in last ietf meeting in = London. > According to the discussion, it seemed people were not clear about = whether we need a separate operational guidelines document or not.=20 >=20 > So let me enumerate possible next steps of the topic to see which you = prefer: > 1. Move forward the PS document to be published, and possibly adopt = the Operational Guidelines document as well (Of course the draft needs = further revision and discussion). > 2. Integrate the operations guidelines into the PS draft, and move = forward it to be published > 3. Move forward the PS document, and drop the operational guidelines = document. >=20 > Looking forward to your opinions. > Many thanks! >=20 > Best regards, > Bing >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 17 13:11:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3571A01EB; Thu, 17 Jul 2014 13:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 0JDLGvVk9nGX; Thu, 17 Jul 2014 13:11:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2551A01E0; Thu, 17 Jul 2014 13:11:36 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6HKBEmq004052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 13:11:14 -0700 (PDT) Message-ID: <53C82DE3.5010007@isi.edu> Date: Thu, 17 Jul 2014 13:11:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3SV-2hjag1Db1Rn9OBH-MZm9Yr0 Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [v6ops] [Int-area] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 20:11:42 -0000 On 7/16/2014 3:13 PM, C. M. Heard wrote: > Even it I don't agree with all of them, the filtering > recommendations in this draft do seem to motivated by legitimate operational > concerns, not blanket paranoia. They need to be characterized as what they are: - an attempt to accommodate devices that are NOT IPv6-compliant I agree that there are legitimate operational concerns, but redefining the behavior or the IPv6 flags is not the purview of operational or management groups in the IETF. If these features cannot be supported, then deprecate them through standards-track updates, not by de-facto deprecation through operational neutering. Joe From nobody Thu Jul 17 14:34:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40E71A0302; Thu, 17 Jul 2014 14:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.568 X-Spam-Level: * X-Spam-Status: No, score=1.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 FQXfSUZGckWq; Thu, 17 Jul 2014 14:34:18 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 DFB231B280A; Thu, 17 Jul 2014 14:34:17 -0700 (PDT) Received: from [209.226.201.241] (helo=[10.205.138.219]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7tJd-0002dg-1O; Thu, 17 Jul 2014 23:34:13 +0200 Message-ID: <53C8392D.9030206@gont.com.ar> Date: Thu, 17 Jul 2014 14:59:25 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , opsec@ietf.org, IPv6 Operations , Internet Area References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> In-Reply-To: <53C6B1E5.4060905@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hk0WDUcC-dcKybu3ats8nzXA0tQ Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:34:20 -0000 Hi, Joe, On 07/16/2014 11:09 AM, Joe Touch wrote: > > I'm including INTAREA in the discussion because this doc seems to be an > end-run around intending to deprecate IPv6 HBH options, or at least to > redefine the option behavior bits defined in RFC 2460. IMO, that ought > to be addressed in INTAREA, not V6OPS. May I ask if you have read the I-D? Because this document is not trying to do any of the above. It simply aims at providing operational advice on how to filter packets with IPv6 EHs/options. > IMO, the real DOS attack here is twofold: > > 1) vendors who misrepresent their boxes as IPv6-capable > at a given packet rate > 2) documents, such as this, > that invert the Postel Principle into the Gont Principle: > > - Postel Principle: > Be conservative in what you send > and liberal in what you receive. > > - Gont Principle: > Be paranoid in what you receive. This document doesn't follow the "be paranoid principle" (if there's such a thing): It recommends to pass lots of stuff that that, if you were really paranoid, you wouldn't pass. And while Postel principle's aims at interoperability, here we're talking about avoiding some specific traffic from breaking your network. SO I don't really follow your analysis. > I sincerely hope there are others who share this view, What's "this view"? Have you followed the thread with Brian Carpenter regarding ignoring rather than dropping HBH? > or we might as > well just go straight to the conclusion that IPv6 routers that can't > process 128-bit addresses really ought to be OK just forwarding based on > the last 32. This document is an operations-related document, not a std track one. As such, it provides advice to the folks *running* the routers not the folks manufacturing them. Just for the sake of reality check: Packet drops rates for different traffic types (and, within parenthesis, the percentage of such drops occurring in a different AS): +--------------+-----------------+-----------------+----------------+ | Dataset | DO8 | HBH8 | FH512 | +--------------+-----------------+-----------------+----------------+ | Web | 11.88% | 40.70% | 30.51% | | | (17.60%-20.80%) | (31.43%-40.00%) | (5.08%-6.78%) | +--------------+-----------------+-----------------+----------------+ | Mailservers | 17.07% | 48.86% | 39.17% | | | (6.35%-26.98%) | (40.50%-65.42%) | (2.91%-12.73%) | +--------------+-----------------+-----------------+----------------+ | Namerservers | 15.37% | 43.25% | 38.55% | | | (14.29%-33.46%) | (42.49%-72.07%) | (3.90%-13.96%) | +--------------+-----------------+-----------------+----------------+ Yes: over 40% of packet drop rate for HBH, already. And quite a few folks (e.g. Google) drop all packets that contain IPv6 EHs. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Thu Jul 17 14:43:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6171A028B; Thu, 17 Jul 2014 14:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 6xw1p7m09ksT; Thu, 17 Jul 2014 14:43:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B171A00BE; Thu, 17 Jul 2014 14:43:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s6HLhKaV008918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 14:43:20 -0700 (PDT) Message-ID: <53C84378.2010200@isi.edu> Date: Thu, 17 Jul 2014 14:43:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , opsec@ietf.org, IPv6 Operations , Internet Area References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C8392D.9030206@gont.com.ar> In-Reply-To: <53C8392D.9030206@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/E3Mu2CRcrPt5NxAlvXZ0JE9gwbM Subject: Re: [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:43:48 -0000 On 7/17/2014 1:59 PM, Fernando Gont wrote: > On 07/16/2014 11:09 AM, Joe Touch wrote: >> > >> >I'm including INTAREA in the discussion because this doc seems to be an >> >end-run around intending to deprecate IPv6 HBH options, or at least to >> >redefine the option behavior bits defined in RFC 2460. IMO, that ought >> >to be addressed in INTAREA, not V6OPS. > > May I ask if you have read the I-D? Because this document is not trying > to do any of the above. ... From draft-gont-opsec-ipv6-eh-filtering-00.txt: 2.3.1.5. Advice Intermediate systems should, by default, drop packets containing a IPv6 Hop-by-Hop Option Extension Header. The currently required behavior of HBH option type "00" in RFC2460: 4.2 Options Two of the currently-defined extension headers -- the Hop-by-Hop Options header and the Destination Options header -- carry a variable number of type-length-value (TLV) encoded "options", of the following format: ... The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. ... From nobody Thu Jul 17 15:04:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480921A0302; Thu, 17 Jul 2014 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 XBpWr8sR9bvN; Thu, 17 Jul 2014 15:03:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 7E4681A0332; Thu, 17 Jul 2014 15:03:59 -0700 (PDT) Received: from [209.226.201.241] (helo=[10.205.138.219]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7tmL-0002jy-Dv; Fri, 18 Jul 2014 00:03:53 +0200 Message-ID: <53C84841.3050702@si6networks.com> Date: Thu, 17 Jul 2014 16:03:45 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> In-Reply-To: <53C82DE3.5010007@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LsUG0ZQTZ8-ooIGDikpmZeE8IbI Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [v6ops] [Int-area] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:04:01 -0000 On 07/17/2014 02:11 PM, Joe Touch wrote: > > > On 7/16/2014 3:13 PM, C. M. Heard wrote: >> Even it I don't agree with all of them, the filtering >> recommendations in this draft do seem to motivated by legitimate >> operational >> concerns, not blanket paranoia. > > They need to be characterized as what they are: > > - an attempt to accommodate devices that are NOT IPv6-compliant I'd have a hard time coming uup with a vendor/device that can process IPv6 packets with HBH header with the same performance as regular packets. So.. are you suggesting that we start claiming that "we currently do not know of any ipv6-compliant routers", or what? (fwiw, I expect you are not) > I agree that there are legitimate operational concerns, but redefining > the behavior or the IPv6 flags is not the purview of operational or > management groups in the IETF. We're not redefining anything. We're just saying "look, if you're running an IPv6 network, this is probably the most sane thing to do". Having that sane advice doesn't prevent you from doing something else if you know better, if you want to allow everything withing your organization, or if you just don't care if your network melts down. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 17 15:06:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AA91B281A; Thu, 17 Jul 2014 15:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 197EmMqK-Ayh; Thu, 17 Jul 2014 15:06:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 DED6A1A0342; Thu, 17 Jul 2014 15:06:02 -0700 (PDT) Received: from [209.226.201.241] (helo=[10.205.138.219]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7toM-0002kw-Fe; Fri, 18 Jul 2014 00:05:58 +0200 Message-ID: <53C848C0.8040506@si6networks.com> Date: Thu, 17 Jul 2014 16:05:52 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "C. M. Heard" , Joe Touch References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cYxrtbp7UotQnBtgxF4gBCwnUdE Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [v6ops] [Int-area] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:06:03 -0000 Hi, Mike, On 07/16/2014 04:13 PM, C. M. Heard wrote: > OK, or even desirable, to block things like that. In fairness to Mr. Gont, this > draft is MUCH better that the initial versions of the corresponding IPv4 options > filtering document. Thanks. And it's an individual -00 version. Nothing is set on stone. Even it I don't agree with all of them, the filtering > recommendations in this draft do seem to motivated by legitimate operational > concerns, not blanket paranoia. > > I think we should move further discussion back to OPSEC and V6OPS. Agree. Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 17 15:39:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2E71A0329; Thu, 17 Jul 2014 15:39:04 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 VmMqbWFBxrxm; Thu, 17 Jul 2014 15:39:00 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C601A0334; Thu, 17 Jul 2014 15:38:59 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6HMcc8B002175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 15:38:38 -0700 (PDT) Message-ID: <53C8506E.1050002@isi.edu> Date: Thu, 17 Jul 2014 15:38:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> <53C84841.3050702@si6networks.com> In-Reply-To: <53C84841.3050702@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UGpJ35Z058F_XU662Z3qRoOh5g8 Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [v6ops] [Int-area] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:39:04 -0000 On 7/17/2014 3:03 PM, Fernando Gont wrote: > On 07/17/2014 02:11 PM, Joe Touch wrote: >> >> >> On 7/16/2014 3:13 PM, C. M. Heard wrote: >>> Even it I don't agree with all of them, the filtering >>> recommendations in this draft do seem to motivated by legitimate >>> operational >>> concerns, not blanket paranoia. >> >> They need to be characterized as what they are: >> >> - an attempt to accommodate devices that are NOT IPv6-compliant > > I'd have a hard time coming uup with a vendor/device that can process > IPv6 packets with HBH header with the same performance as regular > packets. So.. are you suggesting that we start claiming that "we > currently do not know of any ipv6-compliant routers", or what? (fwiw, I > expect you are not) If we are, then it's time to adjust RFC2460. IMO, we ought to: - define the features/capabilities we think are necessary - require that anything that doesn't support what's necessary as non-compliant Otherwise, you're just un-doing all the work that goes into the standards process in the first place. All because you think that anything you don't expect is an attack. It isn't. It just means you're not prepared. Joe From nobody Thu Jul 17 21:34:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBB1A0495; Thu, 17 Jul 2014 21:34:44 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Jpkaa5DwxI_k; Thu, 17 Jul 2014 21:34:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 3E8FE1A0415; Thu, 17 Jul 2014 21:34:42 -0700 (PDT) Received: from static-68-179-14-169.ptr.terago.net ([68.179.14.169] helo=[172.16.52.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7zsO-0006Ml-HY; Fri, 18 Jul 2014 06:34:33 +0200 Message-ID: <53C8A0DF.9000605@si6networks.com> Date: Thu, 17 Jul 2014 22:21:51 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> <53C84841.3050702@si6networks.com> <53C8506E.1050002@isi.edu> In-Reply-To: <53C8506E.1050002@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/q4L46cDdDIkeT7RILhF0NmaTxNg Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [v6ops] [Int-area] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 04:34:44 -0000 On 07/17/2014 04:38 PM, Joe Touch wrote: >>> >>> They need to be characterized as what they are: >>> >>> - an attempt to accommodate devices that are NOT IPv6-compliant >> >> I'd have a hard time coming uup with a vendor/device that can process >> IPv6 packets with HBH header with the same performance as regular >> packets. So.. are you suggesting that we start claiming that "we >> currently do not know of any ipv6-compliant routers", or what? (fwiw, I >> expect you are not) > > If we are, then it's time to adjust RFC2460. I disagree. Operational policy != protocol specification. Actually, the IETF can do whatever it wants with the protocol specs, but not that much with the operational stuff (other than providing *advice* -- because ops folks can do whatever they want with their networks). > IMO, we ought to: > > - define the features/capabilities we think are necessary > > - require that anything that doesn't support what's necessary > as non-compliant > > Otherwise, you're just un-doing all the work that goes into the > standards process in the first place. All because you think that > anything you don't expect is an attack. It isn't. It just means you're > not prepared. We seem to be in disagreement. If anything, anything that I don't want is not an attack, but rather an unnecessary attack surface. But again, please read the I-D... because it really doesn't follow that reasoning. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jul 18 08:52:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D1A1ABB2C for ; Fri, 18 Jul 2014 08:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 S8RAVZbECij8 for ; Fri, 18 Jul 2014 08:52:01 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB28A1A0199 for ; Fri, 18 Jul 2014 08:52:00 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so4888036wes.32 for ; Fri, 18 Jul 2014 08:51:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NfxyEZ9iRUl0lxbOMdCha4PUUQLAiShZnj3smyaOdNk=; b=EQFUDbAva09uOkrzfnXJjc6fNmCJ2rfoCZi1SR1pwz/N/m8/1ZPFJgeBRMW3eFZ54i 3lXMqpe3hoOUnB2ztEb7ZxI/bSA+VkBq1hfqMGhuGokDiESwsYXeLU7hFSZncf+VSrDG zVOf/GXledLzr4QenpY0T9ZfRMXqPOPl9oOG6VrMxBO/ye6uHpm/xA26lZGhspVe22+K GtB1TNycycNxtnWwWV4uFweAHwptce+wryx8ZH011ZjBd1CVMTBKVWOJxEbTHHnjmqHk 98wCZUT+AsIKU1FIxVrzsld2S1RqUg1McUa5CCFIh+4XDDQvVa2gcGjPwFvCsTTfF7wY krBQ== X-Gm-Message-State: ALoCoQk4omJuwESaWjypiDfg7G8F969L7PIHtpwPuZN9DhRjeMuBx6KghvuAOEaP+mjoLS1fWCCh MIME-Version: 1.0 X-Received: by 10.180.90.132 with SMTP id bw4mr32715259wib.42.1405698719213; Fri, 18 Jul 2014 08:51:59 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Fri, 18 Jul 2014 08:51:59 -0700 (PDT) In-Reply-To: <53C8A0DF.9000605@si6networks.com> References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> <53C84841.3050702@si6networks.com> <53C8506E.1050002@isi.edu> <53C8A0DF.9000605@si6networks.com> Date: Fri, 18 Jul 2014 11:51:59 -0400 Message-ID: From: Warren Kumari To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wcbDjq4YPEm_0yVdHRuYz-5I4_w Cc: "C. M. Heard" , OPSEC , Internet Area , IPv6 Operations Subject: Re: [v6ops] [OPSEC] [Int-area] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 15:52:04 -0000 On Fri, Jul 18, 2014 at 12:21 AM, Fernando Gont wrote: > On 07/17/2014 04:38 PM, Joe Touch wrote: >>>> >>>> They need to be characterized as what they are: >>>> >>>> - an attempt to accommodate devices that are NOT IPv6-compliant >>> >>> I'd have a hard time coming uup with a vendor/device that can process >>> IPv6 packets with HBH header with the same performance as regular >>> packets. So.. are you suggesting that we start claiming that "we >>> currently do not know of any ipv6-compliant routers", or what? (fwiw, I >>> expect you are not) >> >> If we are, then it's time to adjust RFC2460. > > I disagree. Operational policy != protocol specification. Actually, the > IETF can do whatever it wants with the protocol specs, but not that much > with the operational stuff (other than providing *advice* -- because ops > folks can do whatever they want with their networks). > > >> IMO, we ought to: >> >> - define the features/capabilities we think are necessary >> >> - require that anything that doesn't support what's necessary >> as non-compliant >> >> Otherwise, you're just un-doing all the work that goes into the >> standards process in the first place. All because you think that >> anything you don't expect is an attack. It isn't. It just means you're >> not prepared. > > We seem to be in disagreement. If anything, anything that I don't want > is not an attack, but rather an unnecessary attack surface. Related to this is http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 -- Why Operators Filter Fragments and What It Implies This expired, but I suspect we may need to revive it... W > But again, > please read the I-D... because it really doesn't follow that reasoning. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Fri Jul 18 10:49:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32141B27E0 for ; Fri, 18 Jul 2014 10:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 Fv3Yeo907Ivk for ; Fri, 18 Jul 2014 10:49:23 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9311A0AAB for ; Fri, 18 Jul 2014 10:49:23 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so3723951wgh.18 for ; Fri, 18 Jul 2014 10:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=yL0mSNyBXwlYpGehc7kAF1k4AFINt/ic2FFgjSFdlgo=; b=qiWLFfb11G08KGaFv9449Rf4qKmpFP0OaLv3oXbg1azNJx0FRYtHiWsTasRSLXArjp kWYTTVrXsQHTrC8S8WGjCIzswRIwDxYmsrsdb8Y05zXWpIynHk/YcPXGYclztuSNSx8F kSgFqcf4nFWR+1wiFO/YTc7ldiUW0NtirWUFi8wIdZgsIe1klJStZMd9k5csMsOiUhQy EY6Iu7C+yjQ213XdrogcoWX7r/5OM1we8N16j9mOu15Zr1EtNQRXRQ6PZk5FtXJmePF2 //VRMRkwgnF+mS444y+fvPH2UwAg5MhynClQ+RJ4NuYQi3Y2CaVtZJp6qft8UMFGONZL z6RQ== MIME-Version: 1.0 X-Received: by 10.180.39.34 with SMTP id m2mr33987550wik.80.1405705760677; Fri, 18 Jul 2014 10:49:20 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.108.166 with HTTP; Fri, 18 Jul 2014 10:49:20 -0700 (PDT) In-Reply-To: References: <20140704131707.3952.10822.idtracker@ietfa.amsl.com> <2A140777-ACCF-4995-B70E-7E88741EF570@ecs.soton.ac.uk> Date: Fri, 18 Jul 2014 10:49:20 -0700 X-Google-Sender-Auth: yyOPhzVCRXqe4Mna9Ys4mUqUecI Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JR14shYBfAr1nl2U2YSqnf7OQmI Cc: v6ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:49:24 -0000 At Fri, 4 Jul 2014 17:24:33 +0100, Tim Chown wrote: > Certain other OSes continued to configure the interface successfully thou= gh, not considering the messages a DAD event. Which led to a confusing situ= ation for the administrator to debug. > > There=E2=80=99s probably a couple of resulting issues here: > > 1) There is different behaviour in response to triplicates of certain ND = messages on different OSes. Is the preferred behaviour what the RFC says? W= e should certainly try to make the behaviour more predictable (even if the = underlying cause is not a common one). To the extent of the usefulness of the DAD itself in general, I believe what the RFC says is the preferred behavior. The condition of "when two nodes run Duplicate Address Detection simultaneously and transmit solicitations at roughly the same time" will be rare, but I can see it happen in practice (e.g. when multiple boxes that have duplicate addresses reboot simultaneously after a power cycle). So it would be better to keep the ability to detect this case. It seems the MacOS behavior is completely valid, and since the description of RFC 4862 on this point is pretty clear, I don't understand why (some) other implementations didn't behave that way. I'd suspect it's some kind of bug, but it could still be a "feature", since there's some flexibility about the expectation on the number of received NSes: - If the actual number of Neighbor Solicitations received exceeds the number expected based on the loopback semantics (e.g., the So, if it's not a bug, those implementations presumably have some interesting interpretation of the expectation. In any case, it's already known that the loopback detection is not reliable. I think this particular variant of the problem should also be addressed with draft-ietf-6man-enhanced-dad. If and when it's widely implemented, this specific problem will also be resolved. BTW, on the draft: this clause wasn't really clear to me: because the replication happened on the very last point - at the network-client attachment. So, the only in particular, it wasn't clear what "at the network-client attachment" means. The description in your email is much clearer, so if you revise the draft I suggest making it a bit more concrete so the meaning will be clearer. -- JINMEI, Tatuya From nobody Sun Jul 20 13:37:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EDA1B27BC for ; Sun, 20 Jul 2014 13:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fNezCguWsqW6 for ; Sun, 20 Jul 2014 13:37:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B43F1B2792 for ; Sun, 20 Jul 2014 13:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14281; q=dns/txt; s=iport; t=1405888636; x=1407098236; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=bWnz4UekuXu9PRp4Sux1NLOmXT0YngKFnTPLg6aldTk=; b=Hfr6WPyilvMZ9RAXw2ToFFbemKvSOlyoQoBiIzYyRuRHMUO12qxF7Trx ghXfRHfBjXTtkR5DUyaVrNjOWV8OPUzbiZCyDmGtRwMfSNhOnZwqudVTM 0KuX2E5JBdOH1St9ANDihhXtrC0m6iGpN3XeaWz59SIxDLmv4KX6xSiNx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAP8nzFOtJV2S/2dsb2JhbABZgkdHUsQWgVcBCYdEAYEGFnaEAwEBAQMBAQEBawkCBQsLEQECAQIvIQYiBggGEwkSiBMDCQgNuH4NhyMXjR6BVUcNBAeDLoEYBYplg16KX4IDgU2FSIZ+hhyDZB0vAYEC X-IronPort-AV: E=Sophos; i="5.01,697,1400025600"; d="scan'208,217"; a="62480828" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 20 Jul 2014 20:37:15 +0000 Received: from [10.21.73.60] ([10.21.73.60]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6KKbCWJ004585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2014 20:37:14 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_BE31CD7E-1B3B-4D11-9041-B6CA910BE5CE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dan Wing In-Reply-To: Date: Sun, 20 Jul 2014 13:36:09 -0700 Message-Id: References: To: Qiong X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/d2Ke_SrprYUP6D3XgE06SDre2Xc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-sun-v6ops-xlat-multi-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:37:18 -0000 --Apple-Mail=_BE31CD7E-1B3B-4D11-9041-B6CA910BE5CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 7, 2014, at 6:57 PM, Qiong wrote: > Hi All, >=20 > We submitted a new draft about deploying multiple PLATs in 464XLAT. = Your comments are more than welcome. Thanks a lot! draft-sun-v6ops-xlat-multi says that networks like this exist: =20 PLAT "A" ----- IPv4-only servers in a data center / IPv6-only node---< \ PLAT "B" ----- IPv4 Internet but I wonder why there are IPv4-only servers in a data center. I see = two operational approaches, which do not require changing 464XLAT. 1. I bet those IPv4-only servers exist because there are IPv4-only nodes = (subscribers) on the same network, which similarly also need to access = both the IPv4-only servers in the datacenter and also the IPv4 Internet. = Those IPv4-only subscribers might (or might not) be going through a = NAT; it doesn't matter. [maybe NAT44] ----- IPv4-only servers in a data = center / IPv4-only node---< \ [maybe NAT44] ----- IPv4 Internet PLAT "A" ----- IPv4-only servers in a data center / IPv6-only node---< \ PLAT "B" ----- IPv4 Internet Of course, those IPv4-only nodes aren't doing anything special; that is, = they don't know how the routing occurs to cause some of their traffic to = go towards the data center and the rest of their traffic towards the = Internet. I do not believe 464xlat needs the IPv6-only 464xlat host to be aware of = which NAT64 is handling its traffic. Instead, the network operator can = route the specific IPv6 /96 addresses that belong to the data center to = a different PLAT -- just like is probably done today for the IPV4-only = clients. 2. Stick a NAT64 in front of the IPv4-only datacenter. -d >=20 > Best wishes > Qiong=20 >=20 > =20 > From: internet-drafts > Date: 2014-07-04 21:31 > To: Qiong Sun; Qiong Sun; Zhirong Zhang; Qin Zhao; Qin Zhao; Zhirong = Zhang > Subject: New Version Notification for = draft-sun-v6ops-xlat-multi-00.txt > =20 > A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt > has been successfully submitted by Qiong Sun and posted to the > IETF repository. > =20 > Name: draft-sun-v6ops-xlat-multi > Revision: 00 > Title: Running Multiple PLATs in 464XLAT > Document date: 2014-07-04 > Group: Individual Submission > Pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-sun-v6ops-xlat-multi-00.txt > Status: = https://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/ > Htmlized: = http://tools.ietf.org/html/draft-sun-v6ops-xlat-multi-00 > =20 > =20 > Abstract: > The IPv6 transition has been an ongoing process throughout the = world > due to the exhaustion of the IPv4 address space. The > 464XLAT[RFC6877] provides a solution with limited IPv4 connectivity > across an IPv6-only network, and the android system (version 2.3 = and > above) has already implemented the 464XLAT[RFC6877] and the the > Prefix discovery solution [RFC7050]. However, the current 464XLAT > architecture can only deal with the scenario with single PLAT in = the > network. When operator deploys multiple PLATs with different = Pref64 > prefixes, 464XLAT cannot cope with multiple prefixes for different > destination addresses. > =20 > This document describes the architecture with multiple PLATs and = also > the deployment considerations. > =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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_BE31CD7E-1B3B-4D11-9041-B6CA910BE5CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 7, 2014, at 6:57 PM, Qiong = <bingxuere@gmail.com> = wrote:

Hi All,

We = submitted a new draft about deploying multiple PLATs in 464XLAT. Your = comments are more than welcome. Thanks a = lot!

draft-sun-v6ops-xlat-mult= i says that networks like this = exist:
 

        =               PLAT "A" ----- = IPv4-only servers in a data center
         =             /
   IPv6-only = node---<
             =         \
            =           PLAT "B" ----- IPv4 = Internet


but I wonder why there are IPv4-only servers in a = data center.  I see two operational approaches, which do not = require changing 464XLAT.

1. I bet those = IPv4-only servers exist because there are IPv4-only nodes (subscribers) = on the same network, which similarly also need to access both the = IPv4-only servers in the datacenter and also the IPv4 Internet. =  Those IPv4-only subscribers might (or might not) be going through = a NAT; it doesn't matter.


               =         [maybe NAT44] ----- IPv4-only servers in a = data center
    =               =    /
   IPv4-only = node---<
             =         \
          =              [maybe NAT44] ----- IPv4 = Internet


                   =     PLAT "A" ----- IPv4-only servers in a data = center
    =               =    /
   IPv6-only = node---<
             =         \
          =             PLAT "B" ----- IPv4 = Internet


Of course, those = IPv4-only nodes aren't doing anything special; that is, they don't know = how the routing occurs to cause some of their traffic to go towards the = data center and the rest of their traffic towards the = Internet.

I do not believe 464xlat needs the = IPv6-only 464xlat host to be aware of which NAT64 is handling its = traffic.  Instead, the network operator can route the specific IPv6 = /96 addresses that belong to the data center to a different PLAT -- just = like is probably done today for the IPV4-only = clients.


2.  Stick a NAT64 = in front of the IPv4-only = datacenter.

-d


Best = wishes
Qiong 

 
Date: 2014-07-04 21:31
Subject: New Version Notification for=20 draft-sun-v6ops-xlat-multi-00.txt
 
A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt
has been successfully submitted by Qiong Sun and posted to = the
IETF repository.
 
Name: draft-sun-v6ops-xlat-multi
Revision: 00
Title: Running Multiple PLATs in 464XLAT
Document date: 2014-07-04
Group: Individual Submission
Pages: 8
=
 
 
Abstract:
   The IPv6 transition has been an ongoing process = throughout the=20 world
   due to the exhaustion of the IPv4 address space.  = The
   464XLAT[RFC6877] provides a solution with limited IPv4=20= connectivity
   across an IPv6-only network, and the android system = (version 2.3=20 and
   above) has already implemented the 464XLAT[RFC6877] = and the the
   Prefix discovery solution [RFC7050].  However, = the current 464XLAT
   architecture can only deal with the scenario with = single PLAT in=20 the
   network.  When operator deploys multiple PLATs = with different=20 Pref64
   prefixes, 464XLAT cannot cope with multiple prefixes = for different
   destination addresses.
 
   This document describes the architecture with multiple = PLATs and=20 also
   the deployment considerations.
 
=
           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;       =20
 
 
Please note that it may take a couple of minutes from the time of=20= 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

= --Apple-Mail=_BE31CD7E-1B3B-4D11-9041-B6CA910BE5CE-- From nobody Mon Jul 21 00:43:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6B1B2D76 for ; Mon, 21 Jul 2014 00:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 U8kfkNC4mTMG for ; Mon, 21 Jul 2014 00:43:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C562D1B2D84 for ; Mon, 21 Jul 2014 00:43:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKI01663; Mon, 21 Jul 2014 07:43:39 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 08:43:38 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 15:43:34 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt Thread-Index: AQHPpLUkwbCSV40UyUSXX+lCauJ9mpuqIPqQ Date: Mon, 21 Jul 2014 07:43:33 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F3D7E@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fMWGACUH0FQtuLmWpbaLj-NpcU0 Subject: [v6ops] FW: New Version Notification for draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 07:43:43 -0000 DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVs eSAyMSwgMjAxNCAzOjI3IFBNDQpUbzogUm9uIEJvbmljYTsgVGlhbmxlIFlhbmc7IFJvbiBCb25p Y2E7IExpdWJpbmcgKExlbyk7IFRpYW5sZSBZYW5nOyBMaXViaW5nIChMZW8pDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS12Nm9wcy1kaGNwdjYtc2xhYWMt Z3VpZGFuY2UtMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS12Nm9w cy1kaGNwdjYtc2xhYWMtZ3VpZGFuY2UtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZToJCWRyYWZ0LWxpdS12Nm9wcy1kaGNwdjYtc2xhYWMtZ3VpZGFuY2UNClJldmlzaW9uOgkw Mg0KVGl0bGU6CQlESENQdjYvU0xBQUMgQWRkcmVzcyBDb25maWd1cmF0aW9uIEludGVyYWN0aW9u IFByb2JsZW0gU3RhdGVtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE0LTA3LTIxDQpHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LXY2b3BzLWRoY3B2Ni1zbGFhYy1n dWlkYW5jZS0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1saXUtdjZvcHMtZGhjcHY2LXNsYWFjLWd1aWRhbmNlLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS12Nm9wcy1kaGNwdjYt c2xhYWMtZ3VpZGFuY2UtMDINCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1saXUtdjZvcHMtZGhjcHY2LXNsYWFjLWd1aWRhbmNlLTAyDQoNCkFi c3RyYWN0Og0KICAgTkQgYW5kIERIQ1B2NiBwcm90b2NvbHMgY291bGQgaGF2ZSBzb21lIGludGVy YWN0aW9uIG9uIGFkZHJlc3MNCiAgIHByb3Zpc2lvbmluZyB3aXRoIHRoZSBBLCBNLCBhbmQgTyBm bGFncyBkZWZpbmVkIGluIE5EIHByb3RvY29sLiAgQnV0DQogICB0aGUgcmVsZXZhbnQgc3RhbmRh cmQgZGVmaW5pdGlvbnMgb2YgdGhlIGZsYWdzIGNvbnRhaW4gYW1iaWd1aXR5LCBzbw0KICAgdGhh dCBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBpbiBvcGVyYXRpbmcgc3lzdGVtcyBoYXZlIHZhcmll ZCBvbg0KICAgaW50ZXJwcmV0aW5nIHRoZSBmbGFncy4gIFRoZSB2YXJpYXRpb24gbWlnaHQgaW1w YWN0IHJlYWwgbmV0d29yaw0KICAgb3BlcmF0aW9ucywgc28gdGhpcyBkb2N1bWVudCBhaW1zIHRv IHByb3ZpZGUgc29tZSBvcGVyYXRpb25hbA0KICAgZ3VpZGFuY2UgdG8gZWxpbWluYXRlIHRoZSBp bXBhY3QgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Mon Jul 21 03:11:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C91B2CCB for ; Mon, 21 Jul 2014 03:11:02 -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, SPF_PASS=-0.001] autolearn=ham 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 5tpp5YCGTm40 for ; Mon, 21 Jul 2014 03:10:56 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC1F1B2C9D for ; Mon, 21 Jul 2014 03:10:55 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so11507606vcb.5 for ; Mon, 21 Jul 2014 03:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8ETciF7UzBIbPvydaC+NVU2p8sPlGbKSH9edPFjeSO0=; b=xr34+5nrUwDX+EOETYw6gAgUrEy5HcR9maZhL4PwHm0OGvBmvrkbxw1nnPcadr2Tyi s6T6O6YmmkI5eeZuCuGChd6WNhZt6RpbzfkmO0unra4gHkzu2Dx5XAdNS66PiZij7Mc2 /raaEsn1kx94VPguVtJrklkszkl3RsUGunut9R3A+dAZo9OEzrG1yyYUI/w7kCfxEEwb CKEyV4DEj13oQmt0dVyxaTcrFaM/TEU/Wy2tr1nMiRCvlfGtG2Uaa8UNKdWvPO35lgXv M+HD6DCU+iR3kIox0i9uNVJab/p6ks/daW+6Eg+Gs0q99ClCvdo0096qoxv9j9tE/zsY ZQLQ== X-Received: by 10.52.31.104 with SMTP id z8mr7837475vdh.23.1405937454672; Mon, 21 Jul 2014 03:10:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.130.137 with HTTP; Mon, 21 Jul 2014 03:10:14 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Mon, 21 Jul 2014 18:10:14 +0800 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=bcaec51d257e8ff03404feb1527e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A99Niy-lp5At-3gbmqB29TfBMLQ Cc: "v6ops@ietf.org" , =?UTF-8?B?6LW16ZKm?= , "zhangzhr@ctbri.com.cn" Subject: Re: [v6ops] New Version Notification for draft-sun-v6ops-xlat-multi-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 10:11:02 -0000 --bcaec51d257e8ff03404feb1527e Content-Type: text/plain; charset=UTF-8 Hi Dan, Thanks a lot for your review and your comments. Please see my explanation inline ~~ On Mon, Jul 21, 2014 at 4:36 AM, Dan Wing wrote: > > On Jul 7, 2014, at 6:57 PM, Qiong wrote: > > Hi All, > > We submitted a new draft about deploying multiple PLATs in 464XLAT. Your > comments are more than welcome. Thanks a lot! > > > draft-sun-v6ops-xlat-multi says that networks like this exist: > > > PLAT "A" ----- IPv4-only servers in a data center > / > IPv6-only node---< > \ > PLAT "B" ----- IPv4 Internet > > > but I wonder why there are IPv4-only servers in a data center. I see two > operational approaches, which do not require changing 464XLAT. > > 1. I bet those IPv4-only servers exist because there are IPv4-only nodes > (subscribers) on the same network, which similarly also need to access both > the IPv4-only servers in the datacenter and also the IPv4 Internet. Those > IPv4-only subscribers might (or might not) be going through a NAT; it > doesn't matter. > > > [maybe NAT44] ----- IPv4-only servers in a data > center > / > IPv4-only node---< > \ > [maybe NAT44] ----- IPv4 Internet > > > PLAT "A" ----- IPv4-only servers in a data center > / > IPv6-only node---< > \ > PLAT "B" ----- IPv4 Internet > > > [Qiong] In 464XLAT, it allows IPv6 UE running IPv4-only application across IPv6-only network and access IPv4-only servers. One survey of IPv6 readiness in the Android Market showed approximately 85% of applications being IPv6-capable. (https://sites.google.com/site/tmoipv6/464xlat) For these applications, most applications can only support IPv6 in the client side, but not on the server side. > Of course, those IPv4-only nodes aren't doing anything special; that is, > they don't know how the routing occurs to cause some of their traffic to go > towards the data center and the rest of their traffic towards the Internet. > > I do not believe 464xlat needs the IPv6-only 464xlat host to be aware of > which NAT64 is handling its traffic. Instead, the network operator can > route the specific IPv6 /96 addresses that belong to the data center to a > different PLAT -- just like is probably done today for the IPV4-only > clients. > [Qiong] In 464XLAT, it does not require the network to deploy DNS64, so the client cannot know the Pref64 by using DNS64. The current implementation is to use Prefix discovery method in [RFC7050 ] to get the Pref64 but it can not be applied in multiple Pref64 case. So in the current implementation, all the traffic will have the same Pref64, and thus the network operator cannot distinguish different Pref64 prefixes for different PALTs. Best wishes Qiong > > > 2. Stick a NAT64 in front of the IPv4-only datacenter. > > -d > > > Best wishes > Qiong > > > *From:* internet-drafts > *Date:* 2014-07-04 21:31 > *To:* Qiong Sun ; Qiong Sun ; > Zhirong Zhang ; Qin Zhao ; Qin > Zhao ; Zhirong Zhang > *Subject:* New Version Notification for draft-sun-v6ops-xlat-multi-00.txt > > A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt > has been successfully submitted by Qiong Sun and posted to the > IETF repository. > > Name: draft-sun-v6ops-xlat-multi > Revision: 00 > Title: Running Multiple PLATs in 464XLAT > Document date: 2014-07-04 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-sun-v6ops-xlat-multi-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/ > Htmlized: http://tools.ietf.org/html/draft-sun-v6ops-xlat-multi-00 > > > Abstract: > The IPv6 transition has been an ongoing process throughout the world > due to the exhaustion of the IPv4 address space. The > 464XLAT[RFC6877] provides a solution with limited IPv4 connectivity > across an IPv6-only network, and the android system (version 2.3 and > above) has already implemented the 464XLAT[RFC6877] and the the > Prefix discovery solution [RFC7050]. However, the current 464XLAT > architecture can only deal with the scenario with single PLAT in the > network. When operator deploys multiple PLATs with different Pref64 > prefixes, 464XLAT cannot cope with multiple prefixes for different > destination addresses. > > This document describes the architecture with multiple PLATs and also > the deployment considerations. > > > > > > 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 > > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --bcaec51d257e8ff03404feb1527e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan,

Thanks a lot for your review an= d your comments. Please see my explanation inline ~~


On Mon, Jul 21, 2014 at 4:36 AM,= Dan Wing <dwing@cisco.com> wrote:

On Jul 7, 2014, at 6:57 PM, Qiong <bingxuere@gmail.com> wrote:

Hi All,

We submitted a n= ew draft about deploying multiple PLATs in 464XLAT. Your comments are more = than welcome. Thanks a lot!

draft-sun-v6ops-xlat-multi say= s that networks like this exist:
=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=A0PLAT &q= uot;A" ----- IPv4-only servers in a data center
=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 IPv6-only n= ode---<
=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 PLAT = "B" ----- IPv4 Internet


but I wonder why there are IPv4-only servers in a= data center. =C2=A0I see two operational approaches, which do not require = changing 464XLAT.

1. I bet those IPv4-only servers exist because there ar= e IPv4-only nodes (subscribers) on the same network, which similarly also n= eed to access both the IPv4-only servers in the datacenter and also the IPv= 4 Internet. =C2=A0Those IPv4-only subscribers might (or might not) be going= through a NAT; it doesn't matter.


=C2=A0=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [maybe NAT44] -----= IPv4-only servers in a data center
=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=A0IPv4-only node---&= lt;
=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[maybe NA= T44] ----- IPv4 Internet


=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=A0PLAT "A" ----- IPv4-only servers in a data center=
=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=A0IPv6-only node---<
=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=A0PLAT "B" ----- IPv4 Internet=


[Qiong] In 464XLAT, i= t allows IPv6 UE running IPv4-only application across IPv6-only network and= access IPv4-only servers. One survey of IPv6 readiness in the Android Mark= et showed approximately 85% of applications being IPv6-capable. (https://sites.google.com/si= te/tmoipv6/464xlat) =C2=A0For these applications, most applications can= only support IPv6 in the client side, but not on the server side. =C2=A0= =C2=A0
=C2=A0
=
Of course, those IPv4-only nodes aren't doing anything special; that is= , they don't know how the routing occurs to cause some of their traffic= to go towards the data center and the rest of their traffic towards the In= ternet.

I do not believe 464xlat needs the IPv6-only 464xlat host to= be aware of which NAT64 is handling its traffic. =C2=A0Instead, the networ= k operator can route the specific IPv6 /96 addresses that belong to the dat= a center to a different PLAT -- just like is probably done today for the IP= V4-only clients.
[Qiong] In 464XLAT, it does not require the network= to deploy DNS64, so the client cannot know the Pref64 by using DNS64. The = current implementation is to use=C2=A0Prefix discovery method in [RFC7050] to get the Pref64 but it can not be applied in mu= ltiple Pref64 case. So in the current implementation, all the traffic will = have the same Pref64, and thus the network operator cannot distinguish diff= erent Pref64 prefixes for different PALTs.

<= font color=3D"#000000">Best wishes
Qiong


2. = =C2=A0Stick a NAT64 in front of the IPv4-only datacenter.

-d

<= div dir=3D"ltr">

Best wishes
Qiong=C2=A0

=C2=A0
From:=C2=A0internet-drafts
Date:=C2=A02014-07-04=C2=A021:31
Subject:=C2=A0New Version Notification for=20 draft-sun-v6ops-xlat-multi-00.txt
=C2=A0
A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.
=C2=A0
Name: draft-sun-v6ops-xlat-multi
Revision: 00
Title: Running Multiple PLATs in 464XLAT
Document date: 2014-07-04
Group: Individual Submission
Pages: 8
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 http://www.ietf.org/internet-drafts/draft-sun-v6op= s-xlat-multi-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 https://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi= /
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 http://tools.ietf.org/html/draft-sun-v6ops-xlat-multi-00
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0 The IPv6 transition has been an ongoing process throughou= t the=20 world
=C2=A0=C2=A0 due to the exhaustion of the IPv4 address space.=C2=A0 Th= e
=C2=A0=C2=A0 464XLAT[RFC6877] provides a solution with limited IPv4=20 connectivity
=C2=A0=C2=A0 across an IPv6-only network, and the android system (vers= ion 2.3=20 and
=C2=A0=C2=A0 above) has already implemented the 464XLAT[RFC6877] and t= he the
=C2=A0=C2=A0 Prefix discovery solution [RFC7050].=C2=A0 However, the c= urrent 464XLAT
=C2=A0=C2=A0 architecture can only deal with the scenario with single = PLAT in=20 the
=C2=A0=C2=A0 network.=C2=A0 When operator deploys multiple PLATs with = different=20 Pref64
=C2=A0=C2=A0 prefixes, 464XLAT cannot cope with multiple prefixes for = different
=C2=A0=C2=A0 destination addresses.
=C2=A0
=C2=A0=C2=A0 This document describes the architecture with multiple PL= ATs and=20 also
=C2=A0=C2=A0 the deployment considerations.
=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=20
=C2=A0
=C2=A0
Please note that it may take a couple of minutes from the time of=20 submission
until the htmlized version and diff are available at tools.ietf.org.
=C2=A0
The IETF Secretariat
=C2=A0
_______________________________________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops



=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Qiong Sun
China Telecom Beijing Research Institude


= Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natc= oord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--bcaec51d257e8ff03404feb1527e-- From nobody Tue Jul 22 12:13:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172621A0AEC for ; Tue, 22 Jul 2014 12:13:39 -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, SPF_PASS=-0.001] autolearn=ham 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 45c4Z4Y53QDS for ; Tue, 22 Jul 2014 12:13:37 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0ED1A00DB for ; Tue, 22 Jul 2014 12:13:36 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so97140wes.32 for ; Tue, 22 Jul 2014 12:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oustb1pwyBYww8+8Rz3FFiEJ3c/EmQUt2t9bOlep980=; b=VvavKhoKUnMeQVjTu32PJuX6oV8MsyqCmqALvYLZxuJ5l1OaFHUOkk0D3yuWjfXOG6 B8rn23Q/n9khlPMNgu+XwzKActWR81c5JL7004vjMDBwf6ha+1D2QmqvLDAw3EO6NRxp UZBxngrP1zXXqp6uGW6hFaAmOayoqmU8BooAtVqrgA47kSuOk8H04YREFIDkV94Z0FLZ AAT2T9wLciNo5THDw0lJIGRm7NeNGdTPajGzvc2pPyCs4RXzAcOr2R/1U+OKG8UsjsAG 4hFxX4FXdxZVaDFPD1mhdDDVtI3OgpwIn0McmtpJJ+fF2p9PAeQwmtSidcTcVKPZ4mCq xcEA== X-Received: by 10.180.78.100 with SMTP id a4mr17733013wix.36.1406056415365; Tue, 22 Jul 2014 12:13:35 -0700 (PDT) Received: from [31.133.162.184] (dhcp-a2b8.meeting.ietf.org. [31.133.162.184]) by mx.google.com with ESMTPSA id lk7sm3017066wjb.24.2014.07.22.12.13.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 12:13:29 -0700 (PDT) Message-ID: <53CEB7DC.6020805@gmail.com> Date: Wed, 23 Jul 2014 07:13:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rX3pAt413WDdido_yVy2gtQax2g Subject: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:13:39 -0000 There wasn't time for me to line up at the microphone, so here are my comments. I think the idea is quite interesting, but a little optimistic. What are the effects of some sessions supporting reflection and others not? We know very well that even the basic RFC 6437 flow label is not supported yet in the real world, so widespread use of reflection is years in the future. There's no discussion of flow label rewriting by firewalls, which we know from the 6man discussions before RFC 6437 is a real issue. If the scope is strictly limited to a single administrative domain, that's OK, but the general end-to-end case probably fails. Actually, the draft doesn't clarify exactly what is a session for flow label purposes. As noted in the meeting, is a "stateless" session (UDP request/reply) a session for this purpose? What about multiple HTTP connections from the same client? The uniqueness rule for flow labels is that a flow is identified by the 3-tuple {Flow Label, Source Addr, Destination Addr}. The flow label value itself might not be unique in the intermediate nodes, so any state must be keyed by the 3-tuple, with the two addresses either way round. The mechanism seems very exposed to on-path attacks, since an attacker could forge a reverse packet with the correct label, even before the first TCP ACK. So nobody should rely on the flow label alone for anything important. (I don't think there is any new risk for off-path attacks.) Finally I think the document would have more chance of success if it was made Informational, without that SHOULD. Just describe this as a use case for the flow label - it is completely consistent with RFC 6437. If the original label is pseudo-random, it will do fine as a reflected label from the other node. Regards Brian From nobody Tue Jul 22 22:41:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480731B27A6 for ; Tue, 22 Jul 2014 22:41:04 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 glJ10iJchfe0 for ; Tue, 22 Jul 2014 22:41:03 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 528891A02FA for ; Tue, 22 Jul 2014 22:41:02 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.77]) by app1 (Coremail) with SMTP id Z0GX06CruQXnP89TQlUZBA==.60278S4; Wed, 23 Jul 2014 12:54:03 +0800 (CST) From: "Aijun Wang" To: "'Brian E Carpenter'" , "'IPv6 Operations'" References: <53CEB7DC.6020805@gmail.com> In-Reply-To: Date: Wed, 23 Jul 2014 13:40:55 +0800 Message-ID: <007501cfa638$ac3b2390$04b16ab0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+l4RoIm9jMPtoKSwO7Vyza1Q7R6gAPbEdwAAZEzHAAADACYA== Content-Language: zh-cn X-CM-TRANSID: Z0GX06CruQXnP89TQlUZBA==.60278S4 X-Coremail-Antispam: 1U3129KBjvJXoWxCF43Xw45Kr13uFyxJr15XFb_yoWrtr4DpF WagryxKr98Jr17G3s7Aw1DWr409rWrGr43AF9xta4UAas8urn29r13tw45AryDWr95J3s0 qrWYgrWDXan3ZFJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjllb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY 1x0267AKxVWUJVW8JwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r1j6r4U0xZFpf9x0JUCD73UUUUU= Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/X-_fZzeQ4plyVao_RtZM4U7Dryk Subject: Re: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 05:41:04 -0000 Hi, Brain: Thanks for your comments. Below is my opinion to your concern points. 1. If some session support reflection, and others not, then the unsupported session will be less likely recognized and controlled, there is no other side-effect. Packets in bi-direction will be load balanced according to the RFC6438, regardless whether the IPv6 flow label is reflected or not. 2.The reason that the IPv6 flow label is not supported in the real world is that we have not find some killer-application that can exploit this field. The mechanism of IPv6 flow label reflection can increase the opportunities of such killer-application be hatched, not the contrary. 3. For mechanism of IPv6 flow label reflection, we strongly recommend this value be manipulated only at the IPv6 packet endpoints, not the in-path device. What is the motion for firewalls to rewrite this value? 4.The session for flow label can be UDP request/reply or TCP request/reply. If one same client have multiple Http connections, there will be multiple distinctive IPv6 Flow label. That is to say, this value is unique in the local host for every TCP/UDP session. 5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr, Destination Addr} to identify the unique session. If the flow label be reflected, then the same 3-tuple can used to identify bi-direction traffic of this session, or else it needs two different 3-tuple, or to parse the extend IPv6 header. 6. Considering on-path attack, I think we can view this value as one magic number, which is widely used in various application protocol. This magic number/IPv6 flow label will be used only to coordinate the bi-direction traffic of one session. If it is changed by some on-path attacker, it only influence the recognition accuracy and control of the session. For differentiated service based on this value, we need other mechanism to protect or authenticate it. It is same risk for differentiated services that based on DSCP value. 7. The IPv6 flow label field is unique in IPv6 packet, we should propose to exploit its potential value actively. From the viewpoint of application developer, there is no more differences between IPv6 packet and IPv4 packet except this field and the length of IP address. The little change of host operation system will be more influence to the IPv6 application and the service that based on IPv6. This change can be deployed incrementally. Best Regards. -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, July 23, 2014 3:14 AM To: IPv6 Operations Subject: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01 There wasn't time for me to line up at the microphone, so here are my comments. I think the idea is quite interesting, but a little optimistic. What are the effects of some sessions supporting reflection and others not? We know very well that even the basic RFC 6437 flow label is not supported yet in the real world, so widespread use of reflection is years in the future. There's no discussion of flow label rewriting by firewalls, which we know from the 6man discussions before RFC 6437 is a real issue. If the scope is strictly limited to a single administrative domain, that's OK, but the general end-to-end case probably fails. Actually, the draft doesn't clarify exactly what is a session for flow label purposes. As noted in the meeting, is a "stateless" session (UDP request/reply) a session for this purpose? What about multiple HTTP connections from the same client? The uniqueness rule for flow labels is that a flow is identified by the 3-tuple {Flow Label, Source Addr, Destination Addr}. The flow label value itself might not be unique in the intermediate nodes, so any state must be keyed by the 3-tuple, with the two addresses either way round. The mechanism seems very exposed to on-path attacks, since an attacker could forge a reverse packet with the correct label, even before the first TCP ACK. So nobody should rely on the flow label alone for anything important. (I don't think there is any new risk for off-path attacks.) Finally I think the document would have more chance of success if it was made Informational, without that SHOULD. Just describe this as a use case for the flow label - it is completely consistent with RFC 6437. If the original label is pseudo-random, it will do fine as a reflected label from the other node. Regards Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 23 05:26:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8C61B2819 for ; Wed, 23 Jul 2014 05:26:23 -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, SPF_PASS=-0.001] autolearn=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 qC2N3UD3q9wq for ; Wed, 23 Jul 2014 05:26:22 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DF81B2802 for ; Wed, 23 Jul 2014 05:26:22 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so1479195oag.28 for ; Wed, 23 Jul 2014 05:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KKSG8H7qNWcDWPb3+Z69g2//iG746hu5rK4Zo/Qw7ZM=; b=oAOrFvs6ZIRb6bbJN6zAqn9lTHuAC3FlTxiV+bwZhrpaTrmMhWl71Il9CAE1ihEAwM aX9B+OzvUGpNdLslAt5wETAzfyeAmeiEVaOPA98SxUaH6f+s4hnGrCtCfclcjE1rjGqK 20yUGF/E3c/ROVRCu+hwkF1A7u0YhcnKPmgGHCQwsUWHbYJtT3lKLVMBUGxK15ls7RKr wJFIZByvs6sLIfsZJj71lEcVcvatzi5S9Abg0Q2K6PMU71vIYGKFZsJy+AvS9W6ye65y FRDhrkqptoHMSdFOBRq24z1vJ8OUAUXRfHYqNh8Dlg8MOWi+4fE302ol1Il5LXvPYp4D yOPQ== MIME-Version: 1.0 X-Received: by 10.182.120.129 with SMTP id lc1mr1301883obb.65.1406118381543; Wed, 23 Jul 2014 05:26:21 -0700 (PDT) Received: by 10.76.133.194 with HTTP; Wed, 23 Jul 2014 05:26:21 -0700 (PDT) In-Reply-To: <53C4FF39.2070600@gmail.com> References: <53C114E8.7020404@gmail.com> <53C4FF39.2070600@gmail.com> Date: Wed, 23 Jul 2014 12:26:21 +0000 Message-ID: From: Nabil Benamar To: Alejandro Acosta Content-Type: multipart/alternative; boundary=089e0117616da4e60004fedb7257 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xNUCTazDBmUZgpHsUSijjC8-ttY Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:26:23 -0000 --089e0117616da4e60004fedb7257 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoann, I really like your draft related to IPv6 multicast. Your current work could become also a good research paper to be submitted to a good journal for publication! As said in the Abstract: "Although the use of multicast does not create real difficulties on wired networks, it can become painful on wireless ones, notably in terms of power consumption" . This is a huge problem in the case of constrained devices such in the Internet of Things. If the sensors are in sleep mode they will nor receive all multicast messages and then their IPv6 connectivity and performances could become intermittent !! So in the introduction " this can have a negative impact on low-energy devices such as smartphones, as stated in [I-D.vyncke-6man-mcast-not-efficient]. The 802.11 protocol [IEEE80211]" you can also mention the case of the constrained devices (IoT) and the LLN (Low Power Lossy Networks). more to come... *Best wishes* *=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88* *Nabil Benamar* *Moulay Ismail University.* *Meknes. Morocco* *nabilbenamar.com * On Tue, Jul 15, 2014 at 10:15 AM, Alejandro Acosta < alejandroacostaalamo@gmail.com> wrote: > Hi Andrew, > My only comment inline: > > El 7/14/2014 4:52 AM, Andrew Yourtchenko escribi=C3=B3: > > Alejandro, > > > > interesting idea. Could you elaborate a bit more ? I'm guessing it woul= d > > be something to do with the power consumption, but estimating the power > > consumption in the generic case is really really tricky, so I am > > wondering how this kind of section might look like to be useful. > > Thanks for asking, in fact after I sent I got stuck thinking in this > topic. > While reading > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-= 00 > I was thinking that probably some drafts or documents might include an > environmental section which should be related to green stuff such as > power consumption and things no harmful for the environment. > Trying to elaborate a bit more the idea would be something very > similar to the current Security section which is mandatory. If we > include an environmental section it could help IETF to develop better > and more friendly protocols to the environment. Is it time to do it?, > If we want to be idealistic low power consumption should be encourage > in all areas -not only mobile-, devices should be able to get in sleep > mode without affecting the network and much more (CPU processing, etc). > > My 2 cents, > > Alejandro, > > > > > > thanks! > > > > --a > > > > On Sat, 12 Jul 2014, Alejandro Acosta wrote: > > > >> Hello, > >> Very nice draft and very interesting results. While reading it I was > >> thinking that certain drafts could include something like a "Enviromen= t > >> friendly section". > >> > >> Alejandro, > >> > >> > >> El 7/11/2014 8:46 AM, Andrew Yourtchenko escribi=C3=B3: > >>> hi all, > >>> > >>> last IETF there were presentations about ND, multicast and power usag= e > >>> on the WiFi, the consensus was we need more data on it. > >>> > >>> Yoann did a nontrivial amount of work on this subject in the meantime > >>> and we'd like to show it to you and hear your feedback. > >>> > >>> > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-= 00 > >>> > >>> > >>> thanks a lot! > >>> > >>> --a > >>> > >>> _______________________________________________ > >>> 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 > --089e0117616da4e60004fedb7257 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yoann,

I really like your draft related to IPv6 multicast. Your current work could= become also a good research paper to be submitted to a good journal for pu= blication!

=C2=A0As said in the Abstract: "Although the use of mult= icast does not create real difficulties on wired networks, it can become pa= inful on wireless ones, notably in terms of power consumption" . This = is a huge problem in the case of constrained devices such in the Internet o= f Things. If the sensors are in sleep mode they will nor receive all multic= ast messages and then their IPv6 connectivity and performances could become= intermittent !!

So in the introduction "=C2=A0this can have a negative i= mpact on low-energy devices such as

smartphones, as stated in [I-D.vyncke-6man-mcast-not-efficien= t]. The

802.11 protocol [IEEE80211]" =C2=A0you can also mention = the case of the constrained devices (IoT) and the LLN (Low Power Lossy Netw= orks).

more to come...



Best wishes
= =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88=
Nabil Benamar
= Moulay Ismail University.
Meknes. Morocco<= /div>


On Tue, Jul 15, 2014 at 10:15 AM, Alejan= dro Acosta <alejandroacostaalamo@gmail.com> wro= te:
Hi Andrew,
=C2=A0 My only comment inline:

El 7/14/2014 4:52 AM, Andrew Yourtchenko escribi=C3=B3:
> Alejandro,
>
> interesting idea. Could you elaborate a bit more ? I'm guessing it= would
> be something to do with the power consumption, but estimating the powe= r
> consumption in the generic case is really really tricky, so I am
> wondering how this kind of section might look like to be useful.

=C2=A0 Thanks for asking, in fact after I sent I got stuck thinking i= n this
topic.
=C2=A0 While reading
http://tools.ietf.org/html/draft-desmouceaux= -ipv6-mcast-wifi-power-usage-00
=C2=A0I was thinking that probably some drafts or documents might include a= n
environmental section which should be related to green stuff such as
power consumption and things no harmful for the environment.
=C2=A0 Trying to elaborate a bit more the idea would be something very
similar to the current Security section which is mandatory. If we
include an environmental section it could help IETF to develop better
and more friendly protocols to the environment. Is it time to do it?,
=C2=A0 If we want to be idealistic low power consumption should be encourag= e
in all areas -not only mobile-, devices should be able to get in sleep
mode without affecting the network and much more (CPU processing, etc).

My 2 cents,

Alejandro,


>
> thanks!
>
> --a
>
> On Sat, 12 Jul 2014, Alejandro Acosta wrote:
>
>> Hello,
>> =C2=A0Very nice draft and very interesting results. While reading = it I was
>> thinking that certain drafts could include something like a "= Enviroment
>> friendly section".
>>
>> Alejandro,
>>
>>
>> El 7/11/2014 8:46 AM, Andrew Yourtchenko escribi=C3=B3:
>>> hi all,
>>>
>>> last IETF there were presentations about ND, multicast and pow= er usage
>>> on the WiFi, the consensus was we need more data on it.
>>>
>>> Yoann did a nontrivial amount of work on this subject in the m= eantime
>>> and we'd like to show it to you and hear your feedback. >>>
>>> http://tools.ietf.org/html/draf= t-desmouceaux-ipv6-mcast-wifi-power-usage-00
>>>
>>>
>>> thanks a lot!
>>>
>>> --a
>>>
>>> _______________________________________________
>>> 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
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--089e0117616da4e60004fedb7257-- From nobody Wed Jul 23 06:23:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A281A0442 for ; Tue, 22 Jul 2014 22:35:58 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 B6k4uNVch95A for ; Tue, 22 Jul 2014 22:35:56 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id CBB891A02FA for ; Tue, 22 Jul 2014 22:35:55 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.77]) by app1 (Coremail) with SMTP id Z0GX06CrtgWmPs9T6k0OBA==.60112S4; Wed, 23 Jul 2014 12:48:55 +0800 (CST) From: "Aijun Wang" To: "'Brian E Carpenter'" , "'IPv6 Operations'" References: <53CEB7DC.6020805@gmail.com> In-Reply-To: Date: Wed, 23 Jul 2014 13:35:33 +0800 Message-ID: <007101cfa637$f524de80$df6e9b80$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+l4RoIm9jMPtoKSwO7Vyza1Q7R6gAPbEdwAAZEzHA= Content-Language: zh-cn X-CM-TRANSID: Z0GX06CrtgWmPs9T6k0OBA==.60112S4 X-Coremail-Antispam: 1U3129KBjvJXoWxCF43Xw45Kr13uFyxJr15XFb_yoWrtr4DpF WagryxKr98Jr17G3s7Aw1DWr409rWrGr43AF9xta4UAas8urn29r13tw45AryDWr95J3s0 qrWYgrWDXan3ZFJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XXDo4biZ96tVn4Td2TUOOVog1ps X-Mailman-Approved-At: Wed, 23 Jul 2014 06:23:31 -0700 Subject: Re: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 05:35:58 -0000 Hi, Brain: Thanks for your comments. Below is my opinion to your concern points. 1. If some session support reflection, and others not, then the unsupported session will be less likely recognized and controlled, there is no other side-effect. Packets in bi-direction will be load balanced according to the RFC6438, regardless whether the IPv6 flow label is reflected or not. 2.The reason that the IPv6 flow label is not supported in the real world is that we have not find some killer-application that can exploit this field. The mechanism of IPv6 flow label reflection can increase the opportunities of such killer-application be hatched, not the contrary. 3. For mechanism of IPv6 flow label reflection, we strongly recommend this value be manipulated only at the IPv6 packet endpoints, not the in-path device. What is the motion for firewalls to rewrite this value? 4.The session for flow label can be UDP request/reply or TCP request/reply. If one same client have multiple Http connections, there will be multiple distinctive IPv6 Flow label. That is to say, this value is unique in the local host for every TCP/UDP session. 5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr, Destination Addr} to identify the unique session. If the flow label be reflected, then the same 3-tuple can used to identify bi-direction traffic of this session, or else it needs two different 3-tuple, or to parse the extend IPv6 header. 6. Considering on-path attack, I think we can view this value as one magic number, which is widely used in various application protocol. This magic number/IPv6 flow label will be used only to coordinate the bi-direction traffic of one session. If it is changed by some on-path attacker, it only influence the recognition accuracy and control of the session. For differentiated service based on this value, we need other mechanism to protect or authenticate it. It is same risk for differentiated services that based on DSCP value. 7. The IPv6 flow label field is unique in IPv6 packet, we should propose to exploit its potential value actively. From the viewpoint of application developer, there is no more differences between IPv6 packet and IPv4 packet except this field and the length of IP address. The little change of host operation system will be more influence to the IPv6 application and the service that based on IPv6. This change can be deployed incrementally. Best Regards. -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, July 23, 2014 3:14 AM To: IPv6 Operations Subject: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01 There wasn't time for me to line up at the microphone, so here are my comments. I think the idea is quite interesting, but a little optimistic. What are the effects of some sessions supporting reflection and others not? We know very well that even the basic RFC 6437 flow label is not supported yet in the real world, so widespread use of reflection is years in the future. There's no discussion of flow label rewriting by firewalls, which we know from the 6man discussions before RFC 6437 is a real issue. If the scope is strictly limited to a single administrative domain, that's OK, but the general end-to-end case probably fails. Actually, the draft doesn't clarify exactly what is a session for flow label purposes. As noted in the meeting, is a "stateless" session (UDP request/reply) a session for this purpose? What about multiple HTTP connections from the same client? The uniqueness rule for flow labels is that a flow is identified by the 3-tuple {Flow Label, Source Addr, Destination Addr}. The flow label value itself might not be unique in the intermediate nodes, so any state must be keyed by the 3-tuple, with the two addresses either way round. The mechanism seems very exposed to on-path attacks, since an attacker could forge a reverse packet with the correct label, even before the first TCP ACK. So nobody should rely on the flow label alone for anything important. (I don't think there is any new risk for off-path attacks.) Finally I think the document would have more chance of success if it was made Informational, without that SHOULD. Just describe this as a use case for the flow label - it is completely consistent with RFC 6437. If the original label is pseudo-random, it will do fine as a reflected label from the other node. Regards Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 23 16:31:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6059F1B2803 for ; Wed, 23 Jul 2014 16:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 J6KiBKPk-9CS for ; Wed, 23 Jul 2014 16:30:59 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id DD55C1B2806 for ; Wed, 23 Jul 2014 16:30:58 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.9/8.14.9) with ESMTP id s6NNUwDg000426 for ; Wed, 23 Jul 2014 19:30:58 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU s6NNUwDg000426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1406158258; bh=1wIT8EBXiXL1smHWtoVZV72S/5w7yoGbIrY3WHhYJjw=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=qGHQ5epQhc2HVKUhBl5cBcCRRDKRBHkgHXCxBvYC86dFBzQCUki57zDK2FlT9Xckx 8LltM3R5Nuo2Mne35jtbOB4K2jhCVwoqyWlWIfGFuPtM2bnrKkRjGEQ0UuZv2yvfhQ B9RAwbWVOMHYzbuz5gzSpA5BnYtCaWQUHCFL373c= Received: from MX3.WPI.EDU (mx3.wpi.edu [130.215.36.147]) by MAIL1.WPI.EDU (8.14.9/8.14.9) with ESMTP id s6NNUwtw000423 for ; Wed, 23 Jul 2014 19:30:58 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by MX3.WPI.EDU (8.14.4/8.14.4) with ESMTP id s6NNUukj030909 for ; Wed, 23 Jul 2014 19:30:57 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id s6NNUugM009930 for ; Wed, 23 Jul 2014 19:30:56 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id s6NNUuR4009929 for v6ops@ietf.org; Wed, 23 Jul 2014 19:30:56 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Wed, 23 Jul 2014 19:30:56 -0400 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20140723233055.GJ23822@angus.ind.WPI.EDU> References: <53C114E8.7020404@gmail.com> <53C4FF39.2070600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/POzcW9E9vNyW6VvCcgRlVGwOp6U Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:31:01 -0000 IPv6 multicast DOES appear to cause problems for wired networks too. This guy experienced MLD reports being sent for 350 solicited node multicast groups by a single Windows box with 350 Privacy Addresses in use: http://blog.bimajority.org/2014/07/16/ipv6-privacy-addresses-windows-just-say-no/ "Apparently the Windows implementation is more aggressive, or Windows applications are more likely to hold connections open, because there are lots of reports of Windows machines having hundreds of these privacy addresses simultaneously and thats what appears to be happening on our problem machine: every time the router sent out a please tell me all your memberships in the next 10 seconds message, the Windows box would reply with 30 MLD responses a second for ten seconds." On Wed, Jul 23, 2014 at 12:26:21PM +0000, Nabil Benamar wrote: > Hi Yoann, > > I really like your draft related to IPv6 multicast. Your current work could > become also a good research paper to be submitted to a good journal for > publication! > > As said in the Abstract: "Although the use of multicast does not create > real difficulties on wired networks, it can become painful on wireless > ones, notably in terms of power consumption" . This is a huge problem in > the case of constrained devices such in the Internet of Things. If the > sensors are in sleep mode they will nor receive all multicast messages and > then their IPv6 connectivity and performances could become intermittent !! > > So in the introduction " this can have a negative impact on low-energy > devices such as > > smartphones, as stated in [I-D.vyncke-6man-mcast-not-efficient]. The > > 802.11 protocol [IEEE80211]" you can also mention the case of the > constrained devices (IoT) and the LLN (Low Power Lossy Networks). > > more to come... > > > > *Best wishes* > * * > *Nabil Benamar* > *Moulay Ismail University.* > *Meknes. Morocco* > *nabilbenamar.com * > > > On Tue, Jul 15, 2014 at 10:15 AM, Alejandro Acosta < > alejandroacostaalamo@gmail.com> wrote: > > > Hi Andrew, > > My only comment inline: > > > > El 7/14/2014 4:52 AM, Andrew Yourtchenko escribi: > > > Alejandro, > > > > > > interesting idea. Could you elaborate a bit more ? I'm guessing it would > > > be something to do with the power consumption, but estimating the power > > > consumption in the generic case is really really tricky, so I am > > > wondering how this kind of section might look like to be useful. > > > > Thanks for asking, in fact after I sent I got stuck thinking in this > > topic. > > While reading > > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 > > I was thinking that probably some drafts or documents might include an > > environmental section which should be related to green stuff such as > > power consumption and things no harmful for the environment. > > Trying to elaborate a bit more the idea would be something very > > similar to the current Security section which is mandatory. If we > > include an environmental section it could help IETF to develop better > > and more friendly protocols to the environment. Is it time to do it?, > > If we want to be idealistic low power consumption should be encourage > > in all areas -not only mobile-, devices should be able to get in sleep > > mode without affecting the network and much more (CPU processing, etc). > > > > My 2 cents, > > > > Alejandro, > > > > > > > > > > thanks! > > > > > > --a > > > > > > On Sat, 12 Jul 2014, Alejandro Acosta wrote: > > > > > >> Hello, > > >> Very nice draft and very interesting results. While reading it I was > > >> thinking that certain drafts could include something like a "Enviroment > > >> friendly section". > > >> > > >> Alejandro, > > >> > > >> > > >> El 7/11/2014 8:46 AM, Andrew Yourtchenko escribi: > > >>> hi all, > > >>> > > >>> last IETF there were presentations about ND, multicast and power usage > > >>> on the WiFi, the consensus was we need more data on it. > > >>> > > >>> Yoann did a nontrivial amount of work on this subject in the meantime > > >>> and we'd like to show it to you and hear your feedback. > > >>> > > >>> > > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 > > >>> > > >>> > > >>> thanks a lot! From nobody Wed Jul 23 16:48:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5851B2892 for ; Wed, 23 Jul 2014 16:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 ZQtBXOHnmV0w for ; Wed, 23 Jul 2014 16:48:23 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9641B288B for ; Wed, 23 Jul 2014 16:48:23 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so2350032qgd.19 for ; Wed, 23 Jul 2014 16:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=f3iQSMi5yURFcxjypMh92r5KFXHWgNerIjcw0C6xYRA=; b=YveNjFYwjB0JKPnEBhZvsCrRNW0nOTt6TpJLZQSV2viE/j5jwxZue2xmsD0kdJP/HW GHWAGuE4nV+9HvTXOG2yPkiv/SgEuQGrseQqP1vwbS0D+v7bV/+89L97pVr+KUsS7utU 9fcFEqdtfieFpp3yumYKUCYZ4s6L9edLvG4iw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=f3iQSMi5yURFcxjypMh92r5KFXHWgNerIjcw0C6xYRA=; b=bJdwfZ2pJjqv7SafsiS2JEpjBY8u/2Z8ufT48P8ebgx6wBgvMq2Sud2BF/aTI10put 7SuSWkBBnWLpnwOk5+Uai/LeI2T1XyiqQRcREcDZ+bw9sZipXgkthRZbB9SaTPtZH0vz dUZRcfeb05S0hSXIiDf8VVRIL7w7roRUmgrJFajWsZNQvtC0XYS7jpZ+35K7/XHnAUe6 /Njk0JhrVirARpoYXgszvD6eda9RYEieYP0/TJw7rfwQwWiEaDZVYm5U6UkblSO0pIRF vNBrGTaZmz4Vp8UwdgIMz2+oJsDZZK3jcssF2WTKynk/WtCnJRtjQ9pvZo3Bc+aAKcmw LBww== X-Gm-Message-State: ALoCoQmqLabHnO4EL89iqs9cEUzYPrFiA/fDRh7w5niJqHgWlbFzN0ihhS5gwT6iPclO+plg6Y1N MIME-Version: 1.0 X-Received: by 10.224.119.198 with SMTP id a6mr8047644qar.39.1406159302415; Wed, 23 Jul 2014 16:48:22 -0700 (PDT) Received: by 10.96.84.233 with HTTP; Wed, 23 Jul 2014 16:48:22 -0700 (PDT) In-Reply-To: <20140723233055.GJ23822@angus.ind.WPI.EDU> References: <53C114E8.7020404@gmail.com> <53C4FF39.2070600@gmail.com> <20140723233055.GJ23822@angus.ind.WPI.EDU> Date: Wed, 23 Jul 2014 16:48:22 -0700 Message-ID: From: Mark Boolootian To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FoHKuwcljo0dR9BbkwufZDaWY0Y Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:48:24 -0000 > IPv6 multicast DOES appear to cause problems for wired networks too. > This guy experienced MLD reports being sent for 350 solicited node > multicast groups by a single Windows box with 350 Privacy Addresses in > use: Can privacy addresses be completely eliminated through the use of DHCPv6 (disabling SLAAC on the router)? From nobody Sat Jul 26 07:27:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD891A02FC for ; Sat, 26 Jul 2014 07:27:49 -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, SPF_PASS=-0.001] autolearn=ham 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 KbwT-CYMblQB for ; Sat, 26 Jul 2014 07:27:47 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CCA1A0202 for ; Sat, 26 Jul 2014 07:27:46 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so6526290qgf.31 for ; Sat, 26 Jul 2014 07:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Cq9YXvUgorMCjStJ5gOuV6bA/IRBPhLe9oDG+1iYqnw=; b=QioMZhF0vQiQPqsAOwkJ0PnQEGp5WE+sy2Ty9g8HElYUnkJKIr13frJR4VP1nR5uZ9 /VhZaUzm2S8xWOfN5TmKTjfzBbwvA2krSqzOz5Q2322gV5mh4BUkxojdpRU5WtZjJwc/ axsLCAlol3xOJqhxdsFY1TASdsZHqntgN6DYFBBnXbtuRqNeEJctkrmmE+Hk7lLcpJ3u JVbCPGPb82BmctUePOMM8v07JoN8MkoUbMMkAjy77jSvWDjYTNPnnuNKvn2LZHwVo8CV jRmPNHTxULJ8BrtUYzet0RR98tZ0aoEEWdqeFPg8R+QIzRG4nVNSZnKWt532C09CJhRO Il+Q== X-Received: by 10.224.93.2 with SMTP id t2mr19103670qam.41.1406384866012; Sat, 26 Jul 2014 07:27:46 -0700 (PDT) Received: from [142.131.64.169] ([206.47.221.210]) by mx.google.com with ESMTPSA id e10sm19044342qae.17.2014.07.26.07.27.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jul 2014 07:27:44 -0700 (PDT) Message-ID: <53D3BADF.9050204@gmail.com> Date: Sun, 27 Jul 2014 02:27:43 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Aijun Wang References: <53CEB7DC.6020805@gmail.com> <007501cfa638$ac3b2390$04b16ab0$@org.cn> In-Reply-To: <007501cfa638$ac3b2390$04b16ab0$@org.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XScffwfy9VreL6jg7zOptIdf_KI Cc: 'IPv6 Operations' Subject: Re: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 14:27:49 -0000 Hi Aijun, Sorry not to reply more quickly but I was quite busy this week ;-) On 23/07/2014 17:40, Aijun Wang wrote: > Hi, Brain: > > Thanks for your comments. Below is my opinion to your concern points. > 1. If some session support reflection, and others not, then the unsupported > session will be less likely recognized and controlled, there is no other > side-effect. Packets in bi-direction will be load balanced according to the > RFC6438, regardless whether the IPv6 flow label is reflected or not. I agree (and of course packets with zero flow labels must still be balanced by traditional methods). I think this needs to be explained in the draft; otherwise everybody will ask the same question. > 2.The reason that the IPv6 flow label is not supported in the real world is > that we have not find some killer-application that can exploit this field. > The mechanism of IPv6 flow label reflection can increase the opportunities > of such killer-application be hatched, not the contrary. Well, I am not certain about that. There are already a few systems that set the flow label, because even under the original RFC 2460 rules or the old RFC 3697 rules, it was possible to do the right thing. However, I hope you are correct. > 3. For mechanism of IPv6 flow label reflection, we strongly recommend this > value be manipulated only at the IPv6 packet endpoints, not the in-path > device. What is the motion for firewalls to rewrite this value? As far as I could tell when we developed RFC 6437, in cases where this is done, it is because of suspicion of a "covert channel" risk, where a user sends encrypted messages in the flow label. In some high security environments this is not an acceptable risk. It may be unusual in a consumer environment but significant in an enterprise or government environment. See section 6.1 of RFC 6437. There is not much the IETF can do about this; firewalls do what they want to do. The other case of course is where the source host does not set the label but a router on the path does so. In that case the router really acts as a flow-label proxy. In a one-way case that's fine; in the reflection case it seems complicated. RFC 6437 precisely defines this case: A node that forwards a flow whose flow label value in arriving packets is zero MAY change the flow label value. In that case, it is RECOMMENDED that the forwarding node sets the flow label field for a flow to a uniformly distributed value as just described for source nodes. For the reflection case, you would have to specify the behaviour of this router in some detail, as an alternative to this RECOMMENDED behaviour. > 4.The session for flow label can be UDP request/reply or TCP request/reply. > If one same client have multiple Http connections, there will be multiple > distinctive IPv6 Flow label. That is to say, this value is unique in the > local host for every TCP/UDP session. And that's a problem for correct load balancing, if a single application layer session is using multiple transport sessions. For other aspects of this, please see the expired draft: http://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing-01 If you really want to improve the problem of flow label persistence, then multi-flow sessions, possibly with different client addresses, need to be covered. > 5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr, > Destination Addr} to identify the unique session. If the flow label be > reflected, then the same 3-tuple can used to identify bi-direction traffic > of this session, or else it needs two different 3-tuple, or to parse the > extend IPv6 header. Yes, the same 3-tuple except that source and destination may be swapped. That's an implementation choice. It's much better to avoid parsing the whole header if possible. > 6. Considering on-path attack, I think we can view this value as one magic > number, which is widely used in various application protocol. This magic > number/IPv6 flow label will be used only to coordinate the bi-direction > traffic of one session. If it is changed by some on-path attacker, it only > influence the recognition accuracy and control of the session. For > differentiated service based on this value, we need other mechanism to > protect or authenticate it. It is same risk for differentiated services that > based on DSCP value. Yes, but your draft needs to explain this. I assume that the worst case is degradation of QoS, which may be considered an acceptable risk. > 7. The IPv6 flow label field is unique in IPv6 packet, we should propose to > exploit its potential value actively. From the viewpoint of application > developer, there is no more differences between IPv6 packet and IPv4 packet > except this field and the length of IP address. The little change of host > operation system will be more influence to the IPv6 application and the > service that based on IPv6. This change can be deployed incrementally. That's true. Personally I hope that once operators become familiar with IPv6 as the normal protocol, there will be more interest in exploiting its features. Do please remember my comment that you can describe this as a use case for the flow label, consistent with RFC 6437. It isn't necessary for it to be on the standards track. Regards Brian > Best Regards. > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Wednesday, July 23, 2014 3:14 AM > To: IPv6 Operations > Subject: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01 > > There wasn't time for me to line up at the microphone, so here are my > comments. I think the idea is quite interesting, but a little optimistic. > > What are the effects of some sessions supporting reflection and others not? > We know very well that even the basic RFC 6437 flow label is not supported > yet in the real world, so widespread use of reflection is years in the > future. > > There's no discussion of flow label rewriting by firewalls, which we know > from the 6man discussions before RFC 6437 is a real issue. If the scope is > strictly limited to a single administrative domain, that's OK, but the > general end-to-end case probably fails. > > Actually, the draft doesn't clarify exactly what is a session for flow label > purposes. As noted in the meeting, is a "stateless" > session (UDP request/reply) a session for this purpose? What about multiple > HTTP connections from the same client? > > The uniqueness rule for flow labels is that a flow is identified by the > 3-tuple {Flow Label, Source Addr, Destination Addr}. The flow label value > itself might not be unique in the intermediate nodes, so any state must be > keyed by the 3-tuple, with the two addresses either way round. > > The mechanism seems very exposed to on-path attacks, since an attacker could > forge a reverse packet with the correct label, even before the first TCP > ACK. So nobody should rely on the flow label alone for anything important. > (I don't think there is any new risk for off-path attacks.) > > Finally I think the document would have more chance of success if it was > made Informational, without that SHOULD. Just describe this as a use case > for the flow label - it is completely consistent with RFC 6437. If the > original label is pseudo-random, it will do fine as a reflected label from > the other node. > > Regards > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > From nobody Sat Jul 26 08:58:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1144E1A02EE for ; Sat, 26 Jul 2014 08:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zRYnY_1jLzG5 for ; Sat, 26 Jul 2014 08:58:46 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B8E1A0012 for ; Sat, 26 Jul 2014 08:58:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E7B40A1; Sat, 26 Jul 2014 17:58:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406390323; bh=JCsOoRBMc0HOJbzyYQUQrA9HROX9texHP6icyznbD8A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Mzi73n1gXHL5r3sz4+Chpdv0invKEFqYZT/J/JgmmuEhF3rLk6w1CR5fF90kQsjLS xLRQ55QTPvp0u8kz3ziskGFWklAws5aB3STVFXHmzaaWRFkZe9U82evjdizBqnWELE GHh/vkRLu9VAMQ4kynSU+w73uPpscQyp5uKupne4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DF29C9F; Sat, 26 Jul 2014 17:58:43 +0200 (CEST) Date: Sat, 26 Jul 2014 17:58:43 +0200 (CEST) From: Mikael Abrahamsson To: Mark Boolootian In-Reply-To: Message-ID: References: <53C114E8.7020404@gmail.com> <53C4FF39.2070600@gmail.com> <20140723233055.GJ23822@angus.ind.WPI.EDU> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QbGE1gnexM4H3-K3h8N2UZ1nemk Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 15:58:48 -0000 On Wed, 23 Jul 2014, Mark Boolootian wrote: > Can privacy addresses be completely eliminated through the use of DHCPv6 > (disabling SLAAC on the router)? Well, depends on your definition of SLAAC, but yes. Send RAs with A-bit=0, M-bit=1 and your machines will only get addresses the DHCPv6 server gives out, and it could enforce only single address per host. Now, not all devices support to get IA_NA via DHCPv6, so your success rate with this will vary with what devices you have if you try this in real life. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Jul 27 11:00:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697D71A0AEC for ; Sun, 27 Jul 2014 11:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 uOhcQ8CynwEu for ; Sun, 27 Jul 2014 11:00:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A511A0028 for ; Sun, 27 Jul 2014 11:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=635; q=dns/txt; s=iport; t=1406484008; x=1407693608; h=date:from:message-id:to:subject:cc; bh=wJVbdJaND5JK7SnB+DaElKO1cawuPAMArm6Y7QGAkWY=; b=MQQzlhKu6b6BpgU614xzT0LL8VcBpYQQOgMfIzpg6zeumgHrQJsXHyG3 1l7lsSjGFIwinkxzIABonfkBC7f8YriKw2SvuxrqqJU/0L2JIlDfLYz99 j/6/WSpxkDbgE6cpDvAkrTlB1nD/tzoN+DtWreH0W8HC0gcS8AXpTgRsf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8MAHs91VOtJA2K/2dsb2JhbABYgw5SWLMsAZgzh0WBCxZ3hQM8NIkiAQ28TBePTB2ENAWKcZItknqDaQ X-IronPort-AV: E=Sophos;i="5.01,743,1400025600"; d="scan'208";a="343264395" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2014 18:00:08 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6RI076S023552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2014 18:00:07 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s6RI05Ct008992; Sun, 27 Jul 2014 11:00:05 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s6RI04sj008989; Sun, 27 Jul 2014 11:00:04 -0700 Date: Sun, 27 Jul 2014 11:00:04 -0700 From: fred@cisco.com Message-Id: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3N8RxVc6Mzvj24Uz6wUj_ilReAM Subject: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 18:00:23 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Sun Jul 27 22:59:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A301A020A for ; Sun, 27 Jul 2014 22:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 jZEJVVDHtdnr for ; Sun, 27 Jul 2014 22:58:50 -0700 (PDT) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by ietfa.amsl.com (Postfix) with SMTP id D9BF31A0063 for ; Sun, 27 Jul 2014 22:58:48 -0700 (PDT) Received: (qmail 59369 messnum 3130556 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 28 Jul 2014 05:58:45 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail04.svc.cra.dublin.eircom.net (qp 59369) with SMTP; 28 Jul 2014 05:58:45 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id Xhye1o00S0mJ9Tz01hyhnk; Mon, 28 Jul 2014 06:58:45 +0100 From: Ross Chandler Content-Type: multipart/alternative; boundary="Apple-Mail=_2777919E-FCDF-4B66-93FB-BABA7AE24AA2" Message-Id: <038E10C7-A2F1-4E63-9A32-48C8A3C1F3DC@eircom.net> Date: Mon, 28 Jul 2014 06:58:37 +0100 To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wfES5o4D00xsJZVjWcqUjGqBG78 Subject: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 05:59:10 -0000 --Apple-Mail=_2777919E-FCDF-4B66-93FB-BABA7AE24AA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi All, I=92m very interested in and supportive of this draft and have gone = through the draft and made updates for nits (spelling errors, minor = suggested, wording changes etc) as per Fred=92s last call. Hopefully, = you=92ll find these useful. I work for eircom including the Mobile network of Meteor (in Ireland). = We have begun the process of enabling IPv6 in our production network. At = this stage we are limiting our plans to Android UEs that support 464xlat = because of the possibility of encountering the issues mentioned in this = draft. Best regards, Ross The whole draft with my changes is below. There are too many to = enumerate, suggest you diff it. Network Working Group G. Chen Internet-Draft H. Deng Intended status: Informational China Mobile Expires: January 5, 2015 D. Michaud Rogers Communications J. Korhonen Renesas Mobile M. Boucadair France Telecom A. Vizdal Deutsche Telekom AG July 4, 2014 IPv6 Roaming Behavior Analysis draft-ietf-v6ops-ipv6-roaming-analysis-01 Abstract This document identifies a set of failure cases that may be = encountered=20 by IPv6-enabled Mobile customers in roaming scenarios. The failure causes include improper configuration, incomplete equipment=20 functionality or inconsistent IPv6 introduction strategy. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires January 5, 2015 [Page 1] Internet-Draft IPv6 Roaming Analysis July 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Roaming Architecture Description . . . . . . . . . . . . . . 3 3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5 4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6 5. Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . . 7 5.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 7 5.2. Case 2: Lack of IPv6 support in applications . . . . . . 8 5.3. Case 3: Fallback Incapability . . . . . . . . . . . . . . 8 5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Many Mobile operators either have already deployed IPv6 or are in a pre-deployment stage of supporting IPv6 in their production networks. A customer in such a network can be provided IPv6 connectivity if=20 their User Equipment (UE) is IPv6-compliant. A detailed overview of=20= IPv6 support in 3GPP architectures is provided in [RFC6459].=20 Operators may adopt various approaches to deploy IPv6 in mobile=20 networks, for example the solutions described in [TR23.975].=20 Depending on network conditions either dual-stack or single-stack=20 IPv6 is selected. In production networks it has been observed that a mobile subscriber roaming around a different operator=92s areas may experience service=20= degradations or interruptions due to inconsistent configurations and=20= incomplete functionality of equipment in the network. This memo intends to document the observed failed cases and analyze the causes. Chen, et al. Expires January 5, 2015 [Page 2] Internet-Draft IPv6 Roaming Analysis July 2014 2. Roaming Architecture Description The roaming process occurs in the following scenarios: o International roaming: a mobile UE enters a visited network, where a different Public Land Mobile Network (PLMN) identity is used. The UE could, either in an automatic mode or a manual mode, attach to the visited PLMN. o Intra-PLMN mobility: a mobile UE moves to a different area of the Home Public Land Mobile Network (HPLMN). However, the subscriber profile may not be stored in the area. To allow network=20= attachment the subscribers profile needs to be downloaded from the=20= home network area. When a UE is turned on or is transferred via a handover to a visited network, the mobile device will scan all radio channels and find available Public Land Mobile Networks (PLMNs) to attach to. The=20 Serving GPRS Support Node (SGSN) or the Mobility Management Entity = (MME) in the visited networks must contact the Home Location Register(HLR) = or=20 Home Subscriber Server(HSS) and obtain the subscriber profile. After the authentication and registration process is completed, the Packet = Data Protocol (PDP) or Packet Data Networks (PDN) activation and traffic flows may be operated differently according to the subscriber profile stored in HLR or HSS. Two modes are shown in the figure to = illustrate,=20 these are =93Home routed traffic=94 (Figure 1) and =93Local breakout"=20= (Figure 2). +---------------------------------+ = +------------------------+ |Visited Network | |Home Network = | | +----+ +--------+ | | +--------+ Traffic = Flow | | UE = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|SGSN/MME|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|GGSN/PGW|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D> | +----+ +--------+ | Signaling | +--------+ = | | |-------------------------->+--------+ = | | | | |HLR/HSS | = | | | | +--------+ = | +---------------------------------+ = +------------------------+ Figure 1: Home Routed Traffic Chen, et al. Expires January 5, 2015 [Page 3] Internet-Draft IPv6 Roaming Analysis July 2014 +---------------------------------+ = +------------------------+ |Visited Network | |Home Network = | | +----+ +--------+ | Signaling | +--------+ = | | | UE |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|SGSN/MME|---------------------->|= HLR/HSS | | | +----+ +--------+ | | +--------+ = | | || | | = | | +--------+ | | = | | |GGSN/PGW| | | = | | +--------+ | | = | | Traffic Flow || | | = | +-----------------------||--------+ = +------------------------+ \/ Figure 2: Local Breakout In the home routed mode, the subscriber's UE activates the PDP/PDN=20 context and get an address from the home network. All traffic is = routed=20 back to the home network. This is likely to be the case = international=20 roaming of Internet data services to facilitate the charging process=20= between the two operators concerned. In the local breakout mode, the subscriber address is assigned by the=20= visited network. The traffic flow is offloaded locally at a network=20= node close to that device's point of attachment in the visited = network. =20 Therefore, a more efficient route to the data service is achieved. = The=20 international roaming of IP Multimedia Subsystem (IMS) based = services,=20 e.g. Voice over LTE (VoLTE)[IR.92] , is claimed to select the local=20= breakout mode in [IR.65]. Data service roaming across different = areas within a operator network could use local breakout mode in order to = get more efficient traffic routing. The local breakout mode could be = also=20 applied to an operators alliance for international roaming of data=20 service. EU Roaming Regulation III [EU-Roaming-III] involves local=20 breakout mode for European subscribers roaming in European 2G/3G=20 networks to choose to have their Internet data routed directly to the=20= Internet from their current VPLMN. The following enumerates the more=20= specific configuration considerations. o Operators may add the APN-OI-Replacement flag defined in 3GPP [TS29.272] into user's subscription-data. The visited network indicates a local domain name to replace the user requested Access Point Name (APN). Consequently, the traffic would be steered to = the=20 visited network. Those functions are normally deployed for the=20 Intra-PLMN mobility cases. o Operators may also configure the VPLMN-Dynamic-Address-Allowed flag [TS29.272] in the user profile to enable local breakout mode in a Visited Public Land Mobile Network (VPLMN). Chen, et al. Expires January 5, 2015 [Page 4] Internet-Draft IPv6 Roaming Analysis July 2014 o 3GPP specified Selected IP Traffic Offload (SIPTO) function [TS23.401] since Release 10 in order to get efficient route paths. It enables an operator to offload certain types of traffic at a network node close to that device's point of attachment to the access network. o GSMA has defined RAVEL [IR.65] as the IMS international roaming architecture. Local breakout mode has been adopted for the IMS roaming architecture. 3. Roaming Scenario Two stages occur when a subscriber roams to a visited network and=20 intends to start data services. o Nework attachment: this occurs when the subscriber enters a visited network. During an attachment, the visited network should authenticate the subsriber and make a location update to the=20 HSS/HLR in the home network of the subsriber. Accordingly, the=20 subscriber profile is offered from the HSS/HLR. The subscriber=20 profile contains the allowed Access Point Names (APN), the allowed PDP/PDN Types and rules regarding the routing of data sessions=20 (i.e. home routed or local breakout mode) [TS29.272]. The SGSN/MME in the visited network can use this information to facilitate the subsequent PDP/PDN session creation. o PDP/PDN context creation: this occurs after the subsriber makes a sucessful attachment. It is worth nothing that this stage is integrated with the attachment stage in the case of 4G, but a seperated process with 2/3G. 3GPP specifies three types of Packet Data Protocol (PDP)/Packet Data Networks (PDN) to describe connections, i.e. PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDN Type IPv4v6. When a subscriber creates a data session their device requests a particular PDP/PDN Type. The allowed PDP/PDN=20 types for that subscriber are learned from the attachment stage.=20= If their subscription profile allows it the SGSN/MME may initiate a PDP/PDN request to the GGSN/PGW. The failures are likely to occur in both stages due to an incompliant implementation in the visited network or a mismatch between the=20 subscriber requested and the capability of the visited network. The=20= failures in the attachment stage are independent of the home routed = or=20 the local breakout mode, while most failure cases in the PDP/PDN=20 context creation stage occur in the local breakout cases. Section 4=20= and 5 describe each case. The below table lists several cases=20 concerning the the PDP/PDN creation stage. Chen, et al. Expires January 5, 2015 [Page 5] Internet-Draft IPv6 Roaming Analysis July 2014 +-------------+-------------------+--------------+ | UE request | PDN/PDP IP Type |Local breakout| | | permitted | | +-------------+-------------------+--------------+ | IPv4v6 | IPv4 or IPv6 |Failure case 1| +-------------+-------------------+--------------+ | IPv4v6 | IPv6 |Failure case 2| +-------------+-------------------+--------------+ | IPv6 | IPv4 |Failure case 3| +-------------+-------------------+--------------+ | IPv6 | IPv6 |Failure case 4| | with 464xlat| without NAT64 | | +-------------+-------------------+--------------+ Table 1: Roaming Scenario Descriptions 4. Failure Case in Attachment Stage 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request both IPv4 and IPv6 within a single PDP/PDN request. This option is stored as a part of subscription data for a subscriber in the HLR/ HSS. PDP/PDN type IPv4v6 was introduced at the inception of Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks should have no issues with the handling of this PDN type. However, support varies in 2/3G networks denpending on Serving GPRS Support Node (SGSN) software version. In theory the S4-SGSN (i.e. an SGSN with a S4 interface) supports the PDP/PDN type IPv4v6 since Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface) supports = it since Release 9. In most cases, operators normally use Gn-SGSN to connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G. The MAP (Mobile Application Part) protocol, as defined in 3GPP [TS29.002], is used over the Gr interface between SGSN and HLR. The MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP Type that is conveyed to SGSN from the HLR within the Insert=20 Subscriber Data (ISD) MAP operation. If the SGSN does not support=20 the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and=20 consequently it must silently discard that IE and continue processing=20= the rest of the ISD MAP message. The issue we observe is that = multiple SGSNs will be unable to correctly process a subscriber's data = received=20 in the Insert Subscriber Data procedure[TS23.060]. As a consequence, it will likely refuse the subscriber attach request. This is = erroneous behaviour due to the equipment not being 3GPP Release 9 compliant. Operators may have to remove the PDP/PDN type IPv4v6 from the = HLR/HSS=20 in the home network, that will restrict UEs to only initiate IPv4 PDP=20= or IPv6 PDP activation. In order to avoid this situation, operators should make a comprehensive roaming agreement to support IPv6 and ensure that it aligns with the GSMA documents, e.g [IR.33], [IR.88] Chen, et al. Expires January 5, 2015 [Page 6] Internet-Draft IPv6 Roaming Analysis July 2014 and [IR.21]. Such an agreement requires the visited operator to get=20= the necessary patch on all their SGSN nodes to support PDP/PDN type=20= IPv4v6. As an alternative solution there are some specific implementations=20 (not standardised by 3GPP) in the HLS/HSS of the home network. When the HLR/HSS receives an Update Location message from a visited=20= SGSN known to not support the PDP type IPv4v6, subscription data with only PDP/PDN type IPv4 will be sent to that SGSN in the Insert=20 Subscriber Data procedure. It guarantees the user profile is=20 compatible with visited SGSN/MME capability. 5. Failure Cases in PDP/PDN Creation When a subscriber succeeds in the attach stage, the IP allocation=20 process takes place to allocate IP addresses to the subscriber. This section summarizes several failures in the break-out cases. 5.1. Case 1: Splitting Dual-stack Bearer Dual-stack capability can be provided using separate PDP/PDN activations. That means only separate parallel single-stack IPv4=20 and IPv6 PDP/PDN connections are allowed to be initiated to = separately allocate IPv4 and IPv6 addresses. The cases are listed below: o The SGSN/MME returns Session Manamgement (SM) Cause #52, "Single address bearers only allowed", or SM Cause #28 "Unknown PDP address or PDP type" as per[TS24.008] and [TS24.301]. o The SGSN/MME does not set the Dual Address Bearer Flag because the operator uses single addressing per bearer to support interworking=20= with nodes of earlier releases A roaming subscriber's UE with IPv4v6 PDP/PDN type has to change the request into two separated PDP/PDN requests with a single IP version = in order to achieve equivalent results.=20 Some drawbacks of this case are listed below: o The parallel PDP/PDN activations would likely double PDP/PDN resources consumption. It also impacts the capacity of GGSN/PGW, since a certain amount of PDP/PDN activations are only allowed on those nodes. o Some networks may only allow one PDP/PDN is alive for each subscriber. For example, an IPv6 PDP/PDN will be rejected if the subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber will lose the IPv6 connection in the visited network. It is even=20= worse as they may have a risk of losing all data connectivity if = the IPv6 PDP gets rejected with a permanent error at the APN-level and not specific to the PDP-Type IPv6 requested. Chen, et al. Expires January 5, 2015 [Page 7] Internet-Draft IPv6 Roaming Analysis July 2014 o Additional correlations between those two PDP/PDN contexts are required on the charging system. o Policy and Charging Rules Function(PCRF)/Policy and Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 session as independent and performs different Quality of Service (QoS) policies. The subscriber may have unstable experiences due to different behaviors on each IP version connection. o Mobile devices may have a limitation on allowed simultaneous PDP/PDN activations. Too many active PDP/PDN connections may = result in other unrelated services broken. Operators may have to disable the local-break mode to avoid the risks. Another approach is to set a dedicated Access Point Name (APN) profile to only request PDP/PDN type IPv4 in the roaming network. 5.2. Case 2: Lack of IPv6 support in applications Some operators may adopt an IPv6-only configuration for the IMS = service, e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite (RCS)[RCC.07]. Since the IMS roaming architecture will offload all traffic in the visited network, a dual-stack subscriber can only be assigned with an IPv6 prefix and no IPv4 address returned. This=20 requires that all the IMS based applications should be IPv6 capable.=20= A translation-based method, for example Bump-in-the-host = (BIH)[RFC6535] or 464xlat [RFC6877] may help to address the issue if there are IPv6 compatibility problems. Those functions could be automatically enabled in an IPv6-only network and disabled in a dual-stack or IPv4 network. 5.3. Case 3: Fallback Incapability 3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4. Therefore, the IPv6 single PDP/PDN type has been well supported and interpretable in the 3GPP network nodes. Roaming to IPv4-only networks and making a IPv6 PDP/PDN request should guarantee that the=20= subscription data is compatible with the visited pre-Release 9 SGSN. When a subscriber requests PDP/PDN type IPv6, the network should only=20= return the expected IPv6 prefix. The mobile device may fail to get an IPv6 prefix if the visited network can only allocate an IPv4 = address=20 to the subscriber. In that case, the request will be dropped and the=20= cause code should be sent to the user. A proper fallback is desirable, however the behavior is = implementation specific. There are some mobile devices have the ability to provide a different configuration for home network and visited network Chen, et al. Expires January 5, 2015 [Page 8] Internet-Draft IPv6 Roaming Analysis July 2014 respectively. For instance, the Android system solves the issue by=20= setting the roaming protocol to IPv4 for the Access Point Name(APN).=20= It guarantees that UE will always initiate an PDP/PDN of type IPv4 in=20= the roaming area. 5.4. Case 4: 464xlat Support 464xlat[RFC6877] is proposed to address the IPv4 compatibility issue=20= in a IPv6 single-stack environment. The function on a mobile device is likely in conjunction with a PDP/PDN IPv6 type request and = requires=20 a remote NAT64 [RFC6146] gateway. 464xlat may use the mechanism=20 defined in [RFC7050] to automatically detect the presence of DNS64 = and to learn the IPv6 prefix used for protocol translation. In the local breakout approach when a mobile device roams to an IPv6 visited = network without the presence of NAT64 or DNS64, 464xlat will fail to = function.=20 =20 The issue has been found mostly in a intra-PLMN mobility case for the time being. Considering the various network's situations, operators may turn off the local breakout and use the home routed mode to = perform 464xlat. Some devices may support the configuration to adopt 464xlat in the home networks and use IPv4-only in the visited networks with different roaming profile configurations. This could also be a solution to address this issue. 6. Discussions Several failure cases have been discussed in this document. It has been testified that the major issues happened at two stages, i.e., the initial network attach and the IP allocation process. During the initial network attach, PDP/PDN type IPv4v6 is the major problem to the visited pre-Release 9 SGSN. The dual-stack deployment is recommended in most cases. However, it may take some times in a mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the early release. Such PDP/PDN type is supported in new-built EPS network, but didn't support well in the third generation network. The situations discussed may cause the roaming issues dropping with the attach request from dual-stack subscribers. Operators may have = to adopt temporary solution unless all the interworking nodes(i.e. the SSGNs) = in the visited network have been upgraded to support the ext-PDP-Type feature. The issues in the IP address allocation process are caused by a local breakout policy. Since the IP address is allocated by the visited=20 GGSN or PGW, the mismatch is found in the following aspects. o The mismatch between the requested PDP/PDN type and the permitted=20= PDP/PDN type Chen, et al. Expires January 5, 2015 [Page 9] Internet-Draft IPv6 Roaming Analysis July 2014 o The mismatch between the application capability and allowed = network connections o The mismatch between mobile device function (e.g., 464xlat) and the support for that function in the vistited network There are some solutions to overcome the issue. Those solutions can be made either in the network side or mobile device side. The below lists potential workarounds. o Change local breakout to the home routed mode o A dedicated roaming APN profile is implemented for the roamer. = When a subscriber roams to a visited network, PDP/PDN type IPv4 is to be=20= always selected for session activation. o Networks could deploy a AAA server to coordinate the mobile device capability. Once the GGSN/PGW receives the session creation request, it will initiate an Access-Request to an AAA server in the home network via the Radius protocol. The Access-Request contains subscriber and visited network information, e.g. PDP/PDN Type, International Mobile Equipment Id (IMEI), Software Version(SV) and visited SGSN/MME location code, etc. The AAA server could take mobile device capability and combine it with the visited network information to ultimately determine the type of session to be created, i.e. IPv4, IPv6 or IPv4v6. 7. IANA Considerations This document makes no request of IANA. 8. Security Considerations This document does not define a new architecture nor a new protocol, but it is encouraged to refer to [RFC6459] for a generic discussion on IPv6-related security considerations. 9. Acknowledgements Many thanks to F. Baker and J. Brzozowski for their support. This document is the result of the IETF v6ops IPv6-Roaming design team effort. The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for their helpful comments. Chen, et al. Expires January 5, 2015 [Page 10] Internet-Draft IPv6 Roaming Analysis July 2014 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 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, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013. 10.2. Informative References [EU-Roaming-III] "http://www.amdocs.com/Products/Revenue- Management/Documents/ amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. [IR.21] Global System for Mobile Communications Association, GSMA., "Roaming Database, Structure and Updating Procedures", July 2012. [IR.33] Global System for Mobile Communications Association, GSMA., "GPRS Roaming Guidelines", July 2012. [IR.65] Global System for Mobile Communications Association, GSMA., "IMS Roaming & Interworking Guidelines", May 2012. Chen, et al. Expires January 5, 2015 [Page 11] Internet-Draft IPv6 Roaming Analysis July 2014 [IR.88] Global System for Mobile Communications Association, GSMA., "LTE Roaming Guidelines", January 2012. [IR.92] Global System for Mobile Communications Association (GSMA), , "IMS Profile for Voice and SMS Version 7.0", March 2013. [RCC.07] Global System for Mobile Communications Association (GSMA), , "Rich Communication Suite 5.1 Advanced Communications Services and Client Specification Version 4.0", November 2013. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012. [TR23.975] 3rd Generation Partnership Project, 3GPP., "IPv6 migration guidelines", June 2011. [TS23.060] 3rd Generation Partnership Project, 3GPP., "General Packet Radio Service (GPRS); Service description; Stage 2 v9.00", March 2009. [TS23.401] 3rd Generation Partnership Project, 3GPP., "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access v9.00", March 2009. [TS24.008] 3rd Generation Partnership Project, 3GPP., "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 v9.00", September 2009. [TS24.301] 3rd Generation Partnership Project, 3GPP., "Non-Access- Stratum (NAS) protocol for Evolved Packet System (EPS) ; Stage 3 v9.00", September 2009. Chen, et al. Expires January 5, 2015 [Page 12] Internet-Draft IPv6 Roaming Analysis July 2014 [TS29.002] 3rd Generation Partnership Project, 3GPP., "Mobile Application Part (MAP) specification v9.00", December 2009. [TS29.272] 3rd Generation Partnership Project, 3GPP., "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol v9.00", September 2009. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: phdgang@gmail.com Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui@chinamobile.com Dave Michaud Rogers Communications 8200 Dixie Rd. Brampton, ON L6T 0C1 Canada Email: dave.michaud@rci.rogers.com Jouni Korhonen Renesas Mobile Porkkalankatu 24 FIN-00180 Helsinki, Finland Email: jouni.nospam@gmail.com Chen, et al. Expires January 5, 2015 [Page 13] Internet-Draft IPv6 Roaming Analysis July 2014 Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.com Vizdal Ales Deutsche Telekom AG Tomickova 2144/1 Prague 4, 149 00 Czech Republic Email: ales.vizdal@t-mobile.cz Chen, et al. Expires January 5, 2015 [Page 14]= --Apple-Mail=_2777919E-FCDF-4B66-93FB-BABA7AE24AA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi All,
I=92m = very interested in and supportive of this draft and have gone through = the draft and made updates for nits (spelling errors, minor suggested, = wording changes etc) as per Fred=92s last call. Hopefully, you=92ll find = these useful.

I work for eircom including the = Mobile network of Meteor (in Ireland). We have begun the process of = enabling IPv6 in our production network. At this stage we are limiting = our plans to Android UEs that support 464xlat because of the possibility = of encountering the issues mentioned in this = draft.

Best = regards,
Ross



=
The whole draft with my changes is below. There are too many to = enumerate, suggest you diff = it.




Network Working Group =                     =                     =    G. Chen
Internet-Draft             =                     =                   H. = Deng
Intended status: = Informational                =               China = Mobile
Expires: January 5, = 2015                  =                   =   D. Michaud
  =                     =                     =          Rogers Communications
            =                     =                     =          J. Korhonen
            =                     =                     =       Renesas Mobile
            =                     =                     =         M. Boucadair
            =                     =                     =       France Telecom
            =                     =                     =            A. Vizdal
            =                     =                     =  Deutsche Telekom AG
                  =                     =                     =   July 4, 2014


                  =    IPv6 Roaming Behavior Analysis
            =   =  draft-ietf-v6ops-ipv6-roaming-analysis-01

Abstract

   This document identifies a set = of failure cases that may be encountered 
   by IPv6-enabled Mobile customers = in roaming scenarios.  The failure
   causes include improper = configuration, incomplete equipment 
   functionality or inconsistent = IPv6 introduction strategy.

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).  Note that other groups = may also distribute
  =  working documents as Internet-Drafts.  The list of = current Internet-
  =  Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

  =  This Internet-Draft will expire on January 5, = 2015.

Copyright = Notice

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





Chen, et al.           =   Expires January 5, 2015          =       [Page 1]


Internet-Draft        =     IPv6 Roaming Analysis        =         July 2014


   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  . . . . . . . = . . . . . . . . . . . . . . . . .   2
   2.  Roaming = Architecture Description  . . . . . . . . . . . . . = .   3
  =  3.  Roaming Scenario  . . . . . . . . . . . . = . . . . . . . . . .   5
   4.  Failure Case in Attachment = Stage  . . . . . . . . . . . . . = .   6
  =  5.  Failure Cases in PDP/PDN Creation . . . . . . . . . = . . . . .   7
     5.1.  Case 1: Splitting Dual-stack = Bearer . . . . . . . . . . .   7
     5.2.  Case 2: = Lack of IPv6 support in applications  . . . . . = .   8
  =    5.3.  Case 3: Fallback Incapability . . . . . . . = . . . . . . .   8
     5.4.  Case 4: 464xlat Support . . . = . . . . . . . . . . . . . .   9
   6.  Discussions . . . = . . . . . . . . . . . . . . . . . . . . . = .   9
  =  7.  IANA Considerations . . . . . . . . . . . . . . . . = . . . . .  10
   8.  Security Considerations . . . . . . . = . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . = . . . . . . . . . . . . . . . . .  10
   10. References  . . . = . . . . . . . . . . . . . . . . . . . . . = .  11
    =  10.1.  Normative References . . . . . . . . . . . . . . = . . . .  11
  =    10.2.  Informative References . . . . . . . . . . = . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . = . . . . . . . . . . . .  13

1.  Introduction

   Many Mobile operators either have already deployed = IPv6 or are in a
  =  pre-deployment stage of supporting IPv6 in their production = networks.
   A = customer in such a network can be provided IPv6 connectivity = if 
   their = User Equipment (UE) is IPv6-compliant. A detailed overview = of 
   IPv6 = support in 3GPP architectures is provided in = [RFC6459]. 
  =  Operators may adopt various approaches to deploy IPv6 in = mobile 
  =  networks, for example the solutions described in = [TR23.975]. 
  =  Depending on network conditions either dual-stack or = single-stack 
  =  IPv6 is selected.

   In production networks it has been observed that a = mobile subscriber
  =  roaming around a different operator=92s areas may experience = service 
  =  degradations or interruptions due to inconsistent configurations = and 
  =  incomplete functionality of equipment in the = network.

  =  This memo intends to document the observed failed cases and = analyze
   the = causes.




Chen, = et al.             Expires = January 5, 2015              =   [Page 2]


Internet-Draft            IPv6 = Roaming Analysis              =   July 2014


2.  Roaming Architecture = Description

  =  The roaming process occurs in the following = scenarios:

  =  o  International roaming: a mobile UE enters a visited = network,
    =   where a different Public Land Mobile Network (PLMN) identity = is
    =   used.  The UE could, either in an automatic mode = or a manual mode,
  =     attach to the visited PLMN.

   o  Intra-PLMN = mobility: a mobile UE moves to a different area of the
      Home Public Land = Mobile Network (HPLMN).  However, the
      subscriber profile = may not be stored in the area. To allow network 
      attachment the = subscribers profile needs to be downloaded from = the 
    =   home network area.

   When a UE is turned on or is transferred via a = handover to a visited
  =  network, the mobile device will scan all radio channels and = find
   available = Public Land Mobile Networks (PLMNs) to attach to. = The 
  =  Serving GPRS Support Node (SGSN) or the Mobility Management Entity = (MME)
   in the = visited networks must contact the Home Location Register(HLR) = or 
   Home = Subscriber Server(HSS) and obtain the subscriber = profile.  After
   the authentication and registration process is = completed, the Packet Data
   Protocol (PDP) or Packet Data Networks (PDN) = activation and traffic
  =  flows may be operated differently according to the subscriber = profile
   stored = in HLR or HSS.  Two modes are shown in the figure = to illustrate, 
   these = are =93Home routed traffic=94 (Figure 1) = and =93Local breakout" 
   (Figure = 2).

+---------------------------------+       =       +------------------------+
|Visited Network        =           |       =       |Home Network        =     |
|  +----+         =   +--------+    |       =       |    +--------+ Traffic = Flow
|  | UE = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|SGSN/MME|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|GGSN/PGW|=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>
|  +----+         =   +--------+    | = Signaling   |    +--------+    =       |
|                  =     =   |-------------------------->+--------+    =       |
|                 =               =   |           =   |    |HLR/HSS |        =   |
|   =                     =           |       =       |    +--------+    =       |
+---------------------------------+       =       +------------------------+

            =            Figure 1: Home Routed = Traffic












Chen, et al.         =     Expires January 5, 2015        =         [Page 3]


Internet-Draft        =     IPv6 Roaming Analysis        =         July 2014


+---------------------------------+       =       +------------------------+
|Visited Network        =           |       =       |Home Network        =     |
|  +----+         =   +--------+    | = Signaling   |    +--------+    =       |
|  | UE = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|SGSN/MME|---------------------->|HL= R/HSS |          |
|  +----+       =     +--------+    |     =         |    +--------+  =         |
|                 =       ||      =   |           =   |                =         |
|                 =   +--------+    |       =       |            =             |
|           =         |GGSN/PGW|  =   |           =   |                =         |
|                 =   +--------+    |       =       |            =             |
|       =   Traffic Flow  ||      =   |           =   |                =         |
+-----------------------||--------+       =       +------------------------+
            =             \/

            =              Figure 2: Local = Breakout

   In = the home routed mode, the subscriber's UE activates the = PDP/PDN 
  =  context and get an address from the home network. All traffic is = routed 
  =  back to the home network.  This is likely to be the case = international 
  =  roaming of Internet data services to facilitate the charging = process 
  =  between the two operators concerned.

   In the local breakout mode, the = subscriber address is assigned by the 
   visited network.  The = traffic flow is offloaded locally at a network 
   node close to that device's = point of attachment in the visited network.  
   Therefore, a more efficient = route to the data service is achieved. The 
   international roaming of IP = Multimedia Subsystem (IMS) based services, 
   e.g.  Voice over LTE = (VoLTE)[IR.92] , is claimed to select the local 
   breakout mode in = [IR.65].  Data service roaming across different = areas
   within a = operator network could use local breakout mode in order to = get
   more = efficient traffic routing.  The local breakout mode could be = also 
  =  applied to an operators alliance for international roaming of = data 
  =  service. EU Roaming Regulation III [EU-Roaming-III] involves = local 
  =  breakout mode for European subscribers roaming in European = 2G/3G 
  =  networks to choose to have their Internet data routed directly to = the 
  =  Internet from their current VPLMN. The following enumerates the = more 
  =  specific configuration considerations.

   o  Operators may add = the APN-OI-Replacement flag defined in 3GPP
      [TS29.272] into = user's subscription-data.  The visited network
      indicates a local = domain name to replace the user requested Access
      Point Name = (APN).  Consequently, the traffic would be steered to = the 
    =   visited network.  Those functions are normally = deployed for the 
  =     Intra-PLMN mobility cases.

   o  Operators may also = configure the VPLMN-Dynamic-Address-Allowed
      flag [TS29.272] in = the user profile to enable local breakout mode
      in a Visited Public = Land Mobile Network (VPLMN).



Chen, et al.         =     Expires January 5, 2015        =         [Page 4]


Internet-Draft        =     IPv6 Roaming Analysis        =         July 2014


   o  3GPP specified = Selected IP Traffic Offload (SIPTO)
      function [TS23.401] since Release 10 in = order to get efficient
  =     route paths.  It enables an operator to = offload certain types of
      traffic at a network node close to that = device's point of
  =     attachment to the access network.

   o  GSMA has defined = RAVEL [IR.65] as the IMS international roaming
    =   architecture.  Local breakout mode has been = adopted for the IMS
  =     roaming architecture.

3.  Roaming = Scenario

   Two = stages occur when a subscriber roams to a visited network = and 
  =  intends to start data services.

   o  Nework attachment: = this occurs when the subscriber enters a
      visited = network.  During an attachment, the visited network = should
    =   authenticate the subsriber and make a location update to = the 
    =   HSS/HLR in the home network of the = subsriber.  Accordingly, the 
      subscriber profile = is offered from the HSS/HLR.  The = subscriber 
  =     profile contains the allowed Access Point Names = (APN), the allowed
  =     PDP/PDN Types and rules regarding the routing of data = sessions 
    =   (i.e. home routed or local breakout mode) [TS29.272]. The = SGSN/MME
    =   in the visited network can use this information to = facilitate the
    =   subsequent PDP/PDN session creation.

   o  PDP/PDN context = creation: this occurs after the subsriber makes
      a sucessful = attachment.  It is worth nothing that this stage = is
    =   integrated with the attachment stage in the case of 4G, but = a
    =   seperated process with 2/3G. 3GPP specifies three types of = Packet
    =   Data Protocol (PDP)/Packet Data Networks (PDN) to = describe
    =   connections, i.e. PDP/PDN Type IPv4, PDP/PDN Type IPv6 and = PDP/
    =   PDN Type IPv4v6.  When a subscriber creates a data = session their
    =   device requests a particular PDP/PDN Type. The allowed = PDP/PDN 
    =   types for that subscriber are learned from the attachment = stage. 
    =   If their subscription profile allows it the SGSN/MME may = initiate
    =   a PDP/PDN request to the GGSN/PGW.

   The failures are likely to occur = in both stages due to an incompliant
   implementation in the visited network or a mismatch = between the 
  =  subscriber requested and the capability of the visited network. = The 
  =  failures in the attachment stage are independent of the home = routed or 
  =  the local breakout mode, while most failure cases in the = PDP/PDN 
  =  context creation stage occur in the local breakout cases. Section = 4 
   and 5 = describe each case. The below table lists several = cases 
  =  concerning the the PDP/PDN creation = stage.




Chen, = et al.             Expires = January 5, 2015              =   [Page 5]


Internet-Draft            IPv6 = Roaming Analysis              =   July 2014


  =  +-------------+-------------------+--------------+
   | UE = request  |  PDN/PDP IP Type  |Local = breakout|
  =  |           =   |     permitted   =   |            =   |
  =  +-------------+-------------------+--------------+
   | IPv4v6    =   |  IPv4 or IPv6     |Failure = case 1|
  =  +-------------+-------------------+--------------+
   | IPv4v6    =   |      IPv6       =   |Failure case 2|
  =  +-------------+-------------------+--------------+
   | IPv6      =   |      IPv4       =   |Failure case 3|
  =  +-------------+-------------------+--------------+
   | IPv6      =   |       IPv6      =   |Failure case 4|
   | with 464xlat|   without = NAT64   |            =   |
  =  +-------------+-------------------+--------------+

            =       Table 1: Roaming Scenario = Descriptions

4.  Failure Case in Attachment = Stage

   3GPP = specified PDP/PDN type IPv4v6 in order to allow a UE = request
   both = IPv4 and IPv6 within a single PDP/PDN request.  This option = is
   stored as a = part of subscription data for a subscriber in the HLR/
   HSS. PDP/PDN type IPv4v6 was = introduced at the inception of
   Evolved Packet System (EPS) in 4G = networks.  The nodes in 4G networks
   should have no issues with the = handling of this PDN type.  However,
   support varies in 2/3G networks = denpending on Serving GPRS
   Support Node (SGSN) software version.  In = theory the S4-SGSN (i.e.
   an SGSN with a S4 interface) supports the PDP/PDN = type IPv4v6 since
  =  Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface) = supports it
  =  since Release 9.  In most cases, operators normally use = Gn-SGSN to
  =  connect either GGSN in 3G or Packet Data Network Gateway (PGW) in = 4G.
   The MAP = (Mobile Application Part) protocol, as defined in 3GPP
   [TS29.002], is used over the Gr = interface between SGSN and HLR.  The
   MAP Information Element (IE) = "ext-pdp-Type" contains the IPv4v6 PDP
   Type that is conveyed to SGSN from the HLR within = the Insert 
  =  Subscriber Data (ISD) MAP operation.  If the SGSN does = not support 
  =  the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE = and 
  =  consequently it must silently discard that IE and continue = processing 
  =  the rest of the ISD MAP message. The issue we observe is that = multiple
   SGSNs = will be unable to correctly process a subscriber's data = received 
  =  in the Insert Subscriber Data procedure[TS23.060]. As a = consequence,
   it = will likely refuse the subscriber attach request. This is = erroneous
  =  behaviour due to the equipment not being 3GPP Release 9 = compliant.

  =  Operators may have to remove the PDP/PDN type IPv4v6 from = the  HLR/HSS 
   in the home network, that will restrict UEs to only = initiate IPv4 PDP 
   or IPv6 PDP activation.  In order to avoid = this situation, operators
   should make a comprehensive roaming agreement to = support IPv6 and
  =  ensure that it aligns with the GSMA documents, e.g [IR.33], = [IR.88]



Chen, et = al.             Expires January = 5, 2015              =   [Page 6]


Internet-Draft            IPv6 = Roaming Analysis              =   July 2014


   and [IR.21].  Such an agreement requires = the visited operator to get 
   the necessary patch on all their SGSN nodes to = support PDP/PDN type 
   IPv4v6.

   As an alternative solution there are some specific = implementations 
  =  (not standardised by 3GPP) in the HLS/HSS of the home = network.
   When = the HLR/HSS receives an Update Location message from a = visited 
  =  SGSN known to not support the PDP type IPv4v6, subscription data = with
   only = PDP/PDN type IPv4 will be sent to that SGSN in the = Insert 
  =  Subscriber Data procedure.  It guarantees the user = profile is 
  =  compatible with visited SGSN/MME capability.

5.  Failure Cases in PDP/PDN = Creation

  =  When a subscriber succeeds in the attach stage, the IP = allocation 
  =  process takes place to allocate IP addresses to the = subscriber.  This
   section summarizes several failures in the break-out = cases.

5.1.  Case 1: Splitting Dual-stack = Bearer

  =  Dual-stack capability can be provided using separate = PDP/PDN
  =  activations.  That means only separate parallel = single-stack IPv4 
   and IPv6 PDP/PDN connections are allowed to be = initiated to separately
   allocate IPv4 and IPv6 addresses.
   The cases are listed = below:

  =  o  The SGSN/MME returns Session Manamgement (SM) Cause = #52, "Single
    =   address bearers only allowed", or SM Cause #28 "Unknown = PDP
    =   address or PDP type" as per[TS24.008] and = [TS24.301].

  =  o  The SGSN/MME does not set the Dual Address Bearer = Flag because the
  =     operator uses single addressing per bearer to support = interworking 
  =     with nodes of earlier releases

   A roaming subscriber's UE with = IPv4v6 PDP/PDN type has to change the
   request into two separated PDP/PDN requests with a = single IP version in
  =  order to achieve equivalent results. 
   Some drawbacks of this case are = listed below:

  =  o  The parallel PDP/PDN activations would likely double = PDP/PDN
    =   resources consumption.  It also impacts the = capacity of GGSN/PGW,
  =     since a certain amount of PDP/PDN activations are = only allowed on
    =   those nodes.

   o  Some networks may only allow one = PDP/PDN is alive for each
      subscriber.  For example, an = IPv6 PDP/PDN will be rejected if the
      subscriber has an active IPv4 = PDP/PDN.  Therefore, the subscriber
      will lose the IPv6 = connection in the visited network.  It is = even 
    =   worse as they may have a risk of losing all data = connectivity if the
  =     IPv6 PDP gets rejected with a permanent error at the = APN-level and
    =   not specific to the PDP-Type IPv6 = requested.


Chen, et = al.             Expires January = 5, 2015              =   [Page 7]


Internet-Draft            IPv6 = Roaming Analysis              =   July 2014


   o  Additional correlations between those = two PDP/PDN contexts are
      required on the charging = system.

  =  o  Policy and Charging Rules Function(PCRF)/Policy and = Charging
    =   Enforcement Function (PCEF) treats the IPv4 and IPv6 session = as
    =   independent and performs different Quality of Service = (QoS)
    =   policies.  The subscriber may have unstable = experiences due to
  =     different behaviors on each IP version = connection.

  =  o  Mobile devices may have a limitation on allowed = simultaneous
    =   PDP/PDN activations.  Too many active PDP/PDN = connections may result in
      other unrelated services = broken.

  =  Operators may have to disable the local-break mode to avoid = the
  =  risks.  Another approach is to set a dedicated Access = Point Name
   (APN) = profile to only request PDP/PDN type IPv4 in the roaming
   network.

5.2.  Case 2: Lack of IPv6 support = in applications

  =  Some operators may adopt an IPv6-only configuration for the IMS = service,
  =  e.g.  Voice over LTE (VoLTE)[IR.92] or Rich = Communication Suite
  =  (RCS)[RCC.07].  Since the IMS roaming architecture will = offload all
  =  traffic in the visited network, a dual-stack subscriber can only = be
   assigned with = an IPv6 prefix and no IPv4 address returned. This 
   requires that all the IMS based = applications should be IPv6 capable. 
   A translation-based method, for = example Bump-in-the-host (BIH)[RFC6535]
   or 464xlat [RFC6877] may help to = address the issue if there are IPv6
   compatibility problems.  Those functions = could be automatically
  =  enabled in an IPv6-only network and disabled in a dual-stack or = IPv4
  =  network.

5.3.  Case 3: Fallback Incapability

   3GPP specified the PDP/PDN type = IPv6 as early as PDP/PDN type IPv4.
   Therefore, the IPv6 single PDP/PDN type has been = well supported and
  =  interpretable in the 3GPP network nodes.  Roaming to = IPv4-only
  =  networks and making a IPv6 PDP/PDN request should guarantee that = the 
  =  subscription data is compatible with the visited pre-Release 9 = SGSN.
   When a = subscriber requests PDP/PDN type IPv6, the network should = only 
  =  return the expected IPv6 prefix.  The mobile device may = fail to get
   an = IPv6 prefix if the visited network can only allocate an IPv4 = address 
   to = the subscriber.  In that case, the request will be dropped and = the 
   cause = code should be sent to the user.

   A proper fallback is desirable, however the behavior = is implementation
  =  specific.  There are some mobile devices have the = ability to provide
  =  a different configuration for home network and visited = network



Chen, et = al.             Expires January = 5, 2015              =   [Page 8]


Internet-Draft            IPv6 = Roaming Analysis              =   July 2014


   respectively.  For instance, the Android = system solves the issue by 
   setting the roaming protocol to IPv4 for the Access = Point Name(APN). 
  =  It guarantees that UE will always initiate an PDP/PDN of type IPv4 = in 
   the = roaming area.

5.4.  Case 4: 464xlat Support

   464xlat[RFC6877] is proposed to = address the IPv4 compatibility issue 
   in a IPv6 single-stack = environment.  The function on a mobile device
   is likely in conjunction with a = PDP/PDN IPv6 type request and requires 
   a remote NAT64 [RFC6146] = gateway. 464xlat may use the mechanism 
   defined in [RFC7050] to = automatically detect the presence of DNS64 and
   to learn the IPv6 prefix used = for protocol translation. In the local
   breakout approach when a mobile device roams to an = IPv6 visited network
  =  without the presence of NAT64 or DNS64, 464xlat will fail to = function. 
  
  =  The issue has been found mostly in a intra-PLMN mobility case for = the
   time = being.  Considering the various network's situations, = operators
   may = turn off the local breakout and use the home routed mode to = perform
  =  464xlat.  Some devices may support the configuration to = adopt 464xlat
   in = the home networks and use IPv4-only in the visited networks = with
   different = roaming profile configurations.  This could also be = a
   solution to = address this issue.

6.  Discussions

   Several failure cases have been discussed in this = document.  It has
   been testified that the major issues happened at two = stages, i.e.,
  =  the initial network attach and the IP allocation = process.

  =  During the initial network attach, PDP/PDN type IPv4v6 is the = major
   problem to = the visited pre-Release 9 SGSN.  The dual-stack = deployment
   is = recommended in most cases.  However, it may take some times in = a
   mobile = environment. 3GPP didn't specify PDP/PDN type IPv4v6 in = the
   early = release.  Such PDP/PDN type is supported in new-built = EPS
   network, but = didn't support well in the third generation network.
   The situations discussed may = cause the roaming issues dropping with
   the attach request from dual-stack = subscribers.  Operators may have to adopt
   temporary solution unless all = the interworking nodes(i.e. the SSGNs) in
   the visited network have been = upgraded to support the ext-PDP-Type
   feature.

   The issues in the IP address allocation process are = caused by a local
  =  breakout policy.  Since the IP address is allocated by = the visited 
  =  GGSN or PGW, the mismatch is found in the following = aspects.

  =  o  The mismatch between the requested PDP/PDN type and = the permitted 
  =     PDP/PDN type



Chen, et al.         =     Expires January 5, 2015        =         [Page 9]


Internet-Draft        =     IPv6 Roaming Analysis        =         July 2014


   o  The mismatch = between the application capability and allowed network
    =   connections

   o  The mismatch between mobile device = function (e.g., 464xlat) and
      the support for that function in the = vistited network

  =  There are some solutions to overcome the issue.  Those = solutions can
   be = made either in the network side or mobile device side.  The = below
   lists = potential workarounds.

   o  Change local breakout to the home = routed mode

  =  o  A dedicated roaming APN profile is implemented for = the roamer. When a
  =     subscriber roams to a visited network, PDP/PDN type = IPv4 is to be 
  =     always selected for session = activation.

  =  o  Networks could deploy a AAA server to coordinate the = mobile device
    =   capability.  Once the GGSN/PGW receives the = session creation
  =     request, it will initiate an Access-Request to an AAA = server in
    =   the home network via the Radius protocol.  The = Access-Request
    =   contains subscriber and visited network information, = e.g.  PDP/PDN
      Type, International Mobile Equipment Id = (IMEI), Software
  =     Version(SV) and visited SGSN/MME location code, = etc.  The AAA
      server could take mobile device = capability and combine it with the
      visited network information to = ultimately determine the type of
      session to be created, = i.e.  IPv4, IPv6 or IPv4v6.

7.  IANA = Considerations

  =  This document makes no request of IANA.

8.  Security = Considerations

  =  This document does not define a new architecture nor a = new
   protocol, = but it is encouraged to refer to [RFC6459] for a generic
   discussion on IPv6-related = security considerations.

9.  Acknowledgements

   Many thanks to = F.  Baker and J.  Brzozowski for their = support.

  =  This document is the result of the IETF v6ops IPv6-Roaming = design
   team = effort.

   The = authors would like to thank Mikael Abrahamsson, Victor = Kuarsingh,
  =  Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne = for
   their = helpful comments.




Chen, et al.           =   Expires January 5, 2015         =       [Page 10]


Internet-Draft        =     IPv6 Roaming Analysis        =         July 2014


10.  References

10.1.  Normative = References

  =  [RFC2119]  Bradner, S., "Key words for use in RFCs to = Indicate
      =         Requirement Levels", BCP 14, RFC 2119, = March 1997.

  =  [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, = M., and X.
    =           Li, "IPv6 Addressing of = IPv4/IPv6 Translators", RFC 6052,
              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, April 2011.

   [RFC6147]  Bagnulo, = M., Sullivan, A., Matthews, P., and I. van
            =   Beijnum, "DNS64: DNS Extensions for Network = Address
      =         Translation from IPv6 Clients to IPv4 = Servers", RFC 6147,
  =             April = 2011.

  =  [RFC6535]  Huang, B., Deng, H., and T. Savolainen, = "Dual-Stack Hosts
  =             Using "Bump-in-the-Host" = (BIH)", RFC 6535, February 2012.

   [RFC6877]  Mawatari, M., Kawashima, M., = and C. Byrne, "464XLAT:
              Combination = of Stateful and Stateless Translation", RFC
            =   6877, April 2013.

   [RFC7050]  Savolainen, T., Korhonen, J., = and D. Wing, "Discovery of
              the IPv6 = Prefix Used for IPv6 Address Synthesis", RFC
            =   7050, November 2013.

10.2.  Informative References

   [EU-Roaming-III]
            =   "http://www.amdocs.com/Products/Revenue-
            =   Management/Documents/
            =   amdocs-eu-roaming-regulation-III-solution.pdf", July = 2013.

  =  [IR.21]    Global System for Mobile Communications = Association,
    =           GSMA., "Roaming Database, = Structure and Updating
  =             Procedures", July = 2012.

  =  [IR.33]    Global System for Mobile Communications = Association,
    =           GSMA., "GPRS Roaming = Guidelines", July 2012.

   [IR.65]    Global System for Mobile = Communications Association,
              GSMA., "IMS = Roaming & Interworking Guidelines", May = 2012.




Chen, = et al.             Expires = January 5, 2015             =   [Page 11]


Internet-Draft            IPv6 = Roaming Analysis              =   July 2014


   [IR.88]    Global System for Mobile = Communications Association,
              GSMA., "LTE = Roaming Guidelines", January 2012.

   [IR.92]    Global System for Mobile = Communications Association
              (GSMA), , = "IMS Profile for Voice and SMS Version 7.0",
            =   March 2013.

   [RCC.07]   Global System for Mobile = Communications Association
              (GSMA), , = "Rich Communication Suite 5.1 Advanced
            =   Communications Services and Client Specification = Version
      =         4.0", November = 2013.

  =  [RFC6459]  Korhonen, J., Soininen, J., Patil, B., = Savolainen, T.,
    =           Bajko, G., and K. Iisakkila, = "IPv6 in 3rd Generation
              Partnership = Project (3GPP) Evolved Packet System (EPS)",
            =   RFC 6459, January 2012.

   [RFC6586]  Arkko, J. = and A. Keranen, "Experiences from an IPv6-Only
            =   Network", RFC 6586, April 2012.

   [TR23.975]
            =   3rd Generation Partnership Project, 3GPP., "IPv6 = migration
    =           guidelines", June = 2011.

  =  [TS23.060]
  =             3rd Generation = Partnership Project, 3GPP., "General Packet
            =   Radio Service (GPRS); Service description; Stage 2 = v9.00",
      =         March 2009.

   [TS23.401]
            =   3rd Generation Partnership Project, 3GPP., "General = Packet
      =         Radio Service (GPRS) enhancements for = Evolved Universal
  =             Terrestrial Radio Access = Network (E-UTRAN) access v9.00",
              March = 2009.

  =  [TS24.008]
  =             3rd Generation = Partnership Project, 3GPP., "Mobile radio
            =   interface Layer 3 specification; Core network = protocols;
    =           Stage 3 v9.00", September = 2009.

  =  [TS24.301]
  =             3rd Generation = Partnership Project, 3GPP., "Non-Access-
            =   Stratum (NAS) protocol for Evolved Packet System (EPS) = ;
        =       Stage 3 v9.00", September = 2009.







Chen, et al.           =   Expires January 5, 2015         =       [Page 12]


Internet-Draft        =     IPv6 Roaming Analysis        =         July 2014


   [TS29.002]
            =   3rd Generation Partnership Project, 3GPP., = "Mobile
      =         Application Part (MAP) specification = v9.00", December
  =             2009.

   [TS29.272]
            =   3rd Generation Partnership Project, 3GPP., = "Mobility
    =           Management Entity (MME) and = Serving GPRS Support Node
              (SGSN) = related interfaces based on Diameter protocol
            =   v9.00", September 2009.

Authors' Addresses

   Gang Chen
   China Mobile
   53A,Xibianmennei = Ave.,
   Xuanwu = District,
  =  Beijing  100053
   China

   Email: phdgang@gmail.com


   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
  =  Beijing  100053
   China

   Email: denghui@chinamobile.com


   Dave Michaud
   Rogers Communications
   8200 Dixie Rd.
   Brampton, ON L6T = 0C1
  =  Canada

  =  Email: dave.michaud@rci.rogers.com


   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24
   FIN-00180 Helsinki, = Finland

  =  Email: jouni.nospam@gmail.com



Chen, et al.           =   Expires January 5, 2015         =       [Page 13]


Internet-Draft        =     IPv6 Roaming Analysis        =         July 2014


   Mohamed = Boucadair
   France = Telecom
  =  Rennes,
  =  35000
  =  France

  =  Email: mohamed.boucadair@orange.com


   Vizdal Ales
   Deutsche Telekom = AG
   Tomickova = 2144/1
   Prague = 4,  149 00
  =  Czech Republic

   Email: ales.vizdal@t-mobile.cz









=
























Chen, et = al.             Expires January = 5, 2015               [Page = 14]
= --Apple-Mail=_2777919E-FCDF-4B66-93FB-BABA7AE24AA2-- From nobody Mon Jul 28 00:16:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BA91A02DB for ; Mon, 28 Jul 2014 00:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 3jvwuaHqoGuS for ; Mon, 28 Jul 2014 00:15:42 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22021A02CF for ; Mon, 28 Jul 2014 00:15:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0C9D1A1; Mon, 28 Jul 2014 09:15:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406531727; bh=XtaV0JdU5FPSG8p3cl25ZgvfflAH4IIixQwX3x3WqJ8=; h=Date:From:To:Subject:In-Reply-To:References:From; b=GllSnArplJL7PqhLrzSoJYJRrsshKaFWlP1wodCVSSpurbtrpOwahIzhXzQHL80Jr EV+leWop2oN+47/M0QEGwfxWGJ1XsfWfunrAS0AriU0RLJB7uksJyRw/ZTQkcsAC1G o8M9lwuIfZxrzlkkHdxVbTzj7RQ6vzM1rchUT6rc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 002D99F for ; Mon, 28 Jul 2014 09:15:26 +0200 (CEST) Date: Mon, 28 Jul 2014 09:15:26 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> Message-ID: References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-DUgBOeVqknTma68j6jkGuHrXTk Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 07:15:44 -0000 On Sun, 27 Jul 2014, fred@cisco.com wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. I have re-read the document. I still find it useful. However, when reading it I can't help of feeling that this document isn't ready for publication yet. It definitely needs a do-over when it comes to language and spelling. Also, on the technical side, I feel the document could be clearer, but I don't know exactly how. I know my comment here isn't really helpful, apart from saying that the document might need more work. One thing that came to mind though, would be a section on how to best provision users in HLR. At least one vendor I know of, doesn't support setting "IPv4v6" on a user in their HLR. In order to support all cases of "IPv4", "IPv6" and "IPv4+IPv6" (dual bearer) and "IPv4v6", one needed to give the user two profiles, one being IPv4+ext_pdp IPv6, and also IPv6+ext_pdp, otherwise the user couldn't connect using IPv6 only. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Jul 28 19:26:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7749D1A0B00 for ; Mon, 28 Jul 2014 19:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=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 s3wFyNdHHy0w for ; Mon, 28 Jul 2014 19:26:09 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25711A0AFB for ; Mon, 28 Jul 2014 19:26:08 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id a108so9267208qge.38 for ; Mon, 28 Jul 2014 19:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eEe0o1dSxDj4uEJcqDLkHBrL1UcpINZKNoPuwZqrfMY=; b=bSORJo6N4T5bTh50Ae/OF8Ji0PKvewPk6T1fM9lCeIMD84hQsOY08DRIED99EI2sOj davKcSqbd6MUufKCYZvu1IiYSdQolD8ukdnCR2ncKaTAnPp6XacuygXqgIcySISK5TB1 T2q435vVjGUUZpjqfZztVzy3oIB7pI4zu5lvw/XoO/H8ervEmLOSPJQZqRsw/8ucdcXz upvGNVVn+HlPf5++FGdd7VaPyIc9rfZXEZpPEoyg1qq3eYsTs3TwS/spuHmCafBE5/KV krf+q9Nu25n1Qk95hOQcLKn1wQFhsAErpWVXYrqVH7CPotbeaRCHsU8+qkSHnkCidkwJ Bx/A== MIME-Version: 1.0 X-Received: by 10.229.211.132 with SMTP id go4mr4100315qcb.0.1406600768020; Mon, 28 Jul 2014 19:26:08 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Mon, 28 Jul 2014 19:26:07 -0700 (PDT) In-Reply-To: References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> Date: Tue, 29 Jul 2014 10:26:07 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4-g9pEOr9rj7o2gtTmrriigiZGo Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 02:26:14 -0000 2014-07-28 15:15 GMT+08:00, Mikael Abrahamsson : > On Sun, 27 Jul 2014, fred@cisco.com wrote: > >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis. >> Please read it now. If you find nits (spelling errors, minor suggested >> wording changes, etc), comment to the authors; if you find greater >> issues, such as disagreeing with a statement or finding additional >> issues that need to be addressed, please post your comments to the >> list. >> >> We are looking specifically for comments on the importance of the >> document as well as its content. If you have read the document and >> believe it to be of operational utility, that is also an important >> comment to make. > > I have re-read the document. I still find it useful. However, when reading > it I can't help of feeling that this document isn't ready for publication > yet. It definitely needs a do-over when it comes to language and spelling. > > Also, on the technical side, I feel the document could be clearer, but I > don't know exactly how. I know my comment here isn't really helpful, apart > from saying that the document might need more work. > > One thing that came to mind though, would be a section on how to best > provision users in HLR. At least one vendor I know of, doesn't support > setting "IPv4v6" on a user in their HLR. In order to support all cases of > "IPv4", "IPv6" and "IPv4+IPv6" (dual bearer) and "IPv4v6", one needed to > give the user two profiles, one being IPv4+ext_pdp IPv6, and also > IPv6+ext_pdp, otherwise the user couldn't connect using IPv6 only. Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support IPv4v6 setting(that is the most case pre-R9), in other words, it can't set ext_pdp. It may not able to support all cases. I guess one way to provision users if HLR can suppor ext_pdp: two profiles: #1: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type, IPv4 & IPv6 pdp-Address PDP-Address OPTIONAL, .... apn-oi-Replacement APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the APN level apn-oi-Replacement and has -- higher priority than UE level apn-oi-Replacement. ext-pdp-Type Ext-PDP-Type OPTIONAL, -- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be -- accessed by dual-stack UEs ext-pdp-Address PDP-Address OPTIONAL, -- contains an additional IP address in case of dual-stack static IP address assignment -- for the UE. -- it may contain an IPv4 or an IPv6 address/prefix, and it may be present -- only if pdp-Address is present; if both are present, each parameter shall -- contain a different type of address (IPv4 or IPv6). ... } #2: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type, IPv4 & IPv6 pdp-Address PDP-Address OPTIONAL, .... apn-oi-Replacement APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the APN level apn-oi-Replacement and has -- higher priority than UE level apn-oi-Replacement. } HLR sends ISR with #1 to vSGSN that above R9; otherwise, it sends #2 to vSGSN that is pre-R9 BRs Gang > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jul 28 19:29:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD721A0AFD for ; Mon, 28 Jul 2014 19:29:06 -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, SPF_PASS=-0.001] autolearn=ham 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 usFypV8Impa2 for ; Mon, 28 Jul 2014 19:29:03 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12FA1A0B05 for ; Mon, 28 Jul 2014 19:29:02 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so8703832qaq.24 for ; Mon, 28 Jul 2014 19:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qHzHbSFYMtcN7qcMJ/2pIewdNyCWbBp0unDubVXcl08=; b=RzrnKRc4R7EI+TNoWInVWO2xUzwi+PiVXsWDcKO4Q372eKverT0rFN+asyH7QuBWcW /KQHqEt1WU1r4hd8R9yVyVRQVzVQ6PFMK/m64QRo+w9l79JtfPz3hEhgA9E7xedrIrmV KZqWCyEKnn9AQ0rz/UnQqEeSKsDv+26l2kJ9tLiBJnd0WumnyRDlb14oYdJg9VjeJUGb smuOuR+Fx8DihNWOivgJioM9B6dHzZlhX3ivAhAuKord7mLrO6bUiCL6DfHQmv4h4IHI FgOCX9okIweQIJCVGgVZ8OOxqDt8PKWwWv88u1x+kBtZx0DPSTO1oTjmNJd0zBOsPF5J MgQA== MIME-Version: 1.0 X-Received: by 10.224.123.8 with SMTP id n8mr66260660qar.40.1406600941941; Mon, 28 Jul 2014 19:29:01 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Mon, 28 Jul 2014 19:29:01 -0700 (PDT) In-Reply-To: <038E10C7-A2F1-4E63-9A32-48C8A3C1F3DC@eircom.net> References: <038E10C7-A2F1-4E63-9A32-48C8A3C1F3DC@eircom.net> Date: Tue, 29 Jul 2014 10:29:01 +0800 Message-ID: From: GangChen To: Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AhOIhOM5sl_fg2OF6VYkgCc_C_g Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 02:29:07 -0000 Thank you for the comments. It's useful to improve the readability. We will incorporate your comments in the next update. BRs Gang 2014-07-28 13:58 GMT+08:00, Ross Chandler : > > Hi All, > I=E2=80=99m very interested in and supportive of this draft and have gone= through > the draft and made updates for nits (spelling errors, minor suggested, > wording changes etc) as per Fred=E2=80=99s last call. Hopefully, you=E2= =80=99ll find these > useful. > > I work for eircom including the Mobile network of Meteor (in Ireland). We > have begun the process of enabling IPv6 in our production network. At thi= s > stage we are limiting our plans to Android UEs that support 464xlat becau= se > of the possibility of encountering the issues mentioned in this draft. > > Best regards, > Ross > > > > The whole draft with my changes is below. There are too many to enumerate= , > suggest you diff it. > > > > > Network Working Group G. Chen > Internet-Draft H. Deng > Intended status: Informational China Mobile > Expires: January 5, 2015 D. Michaud > Rogers Communications > J. Korhonen > Renesas Mobile > M. Boucadair > France Telecom > A. Vizdal > Deutsche Telekom AG > July 4, 2014 > > > IPv6 Roaming Behavior Analysis > draft-ietf-v6ops-ipv6-roaming-analysis-01 > > Abstract > > This document identifies a set of failure cases that may be encountere= d > by IPv6-enabled Mobile customers in roaming scenarios. The failure > causes include improper configuration, incomplete equipment > functionality or inconsistent IPv6 introduction strategy. > > 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). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > 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." > > This Internet-Draft will expire on January 5, 2015. > > Copyright Notice > > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. > > > > > > Chen, et al. Expires January 5, 2015 [Page 1] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Roaming Architecture Description . . . . . . . . . . . . . . 3 > 3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5 > 4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6 > 5. Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . . 7 > 5.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 7 > 5.2. Case 2: Lack of IPv6 support in applications . . . . . . 8 > 5.3. Case 3: Fallback Incapability . . . . . . . . . . . . . . 8 > 5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 > 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 > 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 > 10.2. Informative References . . . . . . . . . . . . . . . . . 11 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 > > 1. Introduction > > Many Mobile operators either have already deployed IPv6 or are in a > pre-deployment stage of supporting IPv6 in their production networks. > A customer in such a network can be provided IPv6 connectivity if > their User Equipment (UE) is IPv6-compliant. A detailed overview of > IPv6 support in 3GPP architectures is provided in [RFC6459]. > Operators may adopt various approaches to deploy IPv6 in mobile > networks, for example the solutions described in [TR23.975]. > Depending on network conditions either dual-stack or single-stack > IPv6 is selected. > > In production networks it has been observed that a mobile subscriber > roaming around a different operator=E2=80=99s areas may experience ser= vice > degradations or interruptions due to inconsistent configurations and > incomplete functionality of equipment in the network. > > This memo intends to document the observed failed cases and analyze > the causes. > > > > > Chen, et al. Expires January 5, 2015 [Page 2] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > 2. Roaming Architecture Description > > The roaming process occurs in the following scenarios: > > o International roaming: a mobile UE enters a visited network, > where a different Public Land Mobile Network (PLMN) identity is > used. The UE could, either in an automatic mode or a manual mode, > attach to the visited PLMN. > > o Intra-PLMN mobility: a mobile UE moves to a different area of the > Home Public Land Mobile Network (HPLMN). However, the > subscriber profile may not be stored in the area. To allow network > attachment the subscribers profile needs to be downloaded from the > home network area. > > When a UE is turned on or is transferred via a handover to a visited > network, the mobile device will scan all radio channels and find > available Public Land Mobile Networks (PLMNs) to attach to. The > Serving GPRS Support Node (SGSN) or the Mobility Management Entity (MM= E) > in the visited networks must contact the Home Location Register(HLR) o= r > Home Subscriber Server(HSS) and obtain the subscriber profile. After > the authentication and registration process is completed, the Packet > Data > Protocol (PDP) or Packet Data Networks (PDN) activation and traffic > flows may be operated differently according to the subscriber profile > stored in HLR or HSS. Two modes are shown in the figure to illustrate= , > these are =E2=80=9CHome routed traffic=E2=80=9D (Figure 1) and =E2=80= =9CLocal breakout" > (Figure 2). > > +---------------------------------+ +------------------------= + > |Visited Network | |Home Network = | > | +----+ +--------+ | | +--------+ Traffic > Flow > | | UE > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|SGSN/MME|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|GGSN/PGW|=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D> > | +----+ +--------+ | Signaling | +--------+ = | > | |-------------------------->+--------+ = | > | | | |HLR/HSS | = | > | | | +--------+ = | > +---------------------------------+ +------------------------= + > > Figure 1: Home Routed Traffic > > > > > > > > > > > > > Chen, et al. Expires January 5, 2015 [Page 3] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > +---------------------------------+ +------------------------= + > |Visited Network | |Home Network = | > | +----+ +--------+ | Signaling | +--------+ = | > | | UE |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|SGSN/MME|---------------------->= |HLR/HSS | | > | +----+ +--------+ | | +--------+ = | > | || | | = | > | +--------+ | | = | > | |GGSN/PGW| | | = | > | +--------+ | | = | > | Traffic Flow || | | = | > +-----------------------||--------+ +------------------------= + > \/ > > Figure 2: Local Breakout > > In the home routed mode, the subscriber's UE activates the PDP/PDN > context and get an address from the home network. All traffic is route= d > back to the home network. This is likely to be the case international > roaming of Internet data services to facilitate the charging process > between the two operators concerned. > > In the local breakout mode, the subscriber address is assigned by the > visited network. The traffic flow is offloaded locally at a network > node close to that device's point of attachment in the visited network= . > > Therefore, a more efficient route to the data service is achieved. The > international roaming of IP Multimedia Subsystem (IMS) based services, > e.g. Voice over LTE (VoLTE)[IR.92] , is claimed to select the local > breakout mode in [IR.65]. Data service roaming across different areas > within a operator network could use local breakout mode in order to ge= t > more efficient traffic routing. The local breakout mode could be also > applied to an operators alliance for international roaming of data > service. EU Roaming Regulation III [EU-Roaming-III] involves local > breakout mode for European subscribers roaming in European 2G/3G > networks to choose to have their Internet data routed directly to the > Internet from their current VPLMN. The following enumerates the more > specific configuration considerations. > > o Operators may add the APN-OI-Replacement flag defined in 3GPP > [TS29.272] into user's subscription-data. The visited network > indicates a local domain name to replace the user requested Access > Point Name (APN). Consequently, the traffic would be steered to th= e > visited network. Those functions are normally deployed for the > Intra-PLMN mobility cases. > > o Operators may also configure the VPLMN-Dynamic-Address-Allowed > flag [TS29.272] in the user profile to enable local breakout mode > in a Visited Public Land Mobile Network (VPLMN). > > > > Chen, et al. Expires January 5, 2015 [Page 4] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > o 3GPP specified Selected IP Traffic Offload (SIPTO) > function [TS23.401] since Release 10 in order to get efficient > route paths. It enables an operator to offload certain types of > traffic at a network node close to that device's point of > attachment to the access network. > > o GSMA has defined RAVEL [IR.65] as the IMS international roaming > architecture. Local breakout mode has been adopted for the IMS > roaming architecture. > > 3. Roaming Scenario > > Two stages occur when a subscriber roams to a visited network and > intends to start data services. > > o Nework attachment: this occurs when the subscriber enters a > visited network. During an attachment, the visited network should > authenticate the subsriber and make a location update to the > HSS/HLR in the home network of the subsriber. Accordingly, the > subscriber profile is offered from the HSS/HLR. The subscriber > profile contains the allowed Access Point Names (APN), the allowed > PDP/PDN Types and rules regarding the routing of data sessions > (i.e. home routed or local breakout mode) [TS29.272]. The SGSN/MME > in the visited network can use this information to facilitate the > subsequent PDP/PDN session creation. > > o PDP/PDN context creation: this occurs after the subsriber makes > a sucessful attachment. It is worth nothing that this stage is > integrated with the attachment stage in the case of 4G, but a > seperated process with 2/3G. 3GPP specifies three types of Packet > Data Protocol (PDP)/Packet Data Networks (PDN) to describe > connections, i.e. PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ > PDN Type IPv4v6. When a subscriber creates a data session their > device requests a particular PDP/PDN Type. The allowed PDP/PDN > types for that subscriber are learned from the attachment stage. > If their subscription profile allows it the SGSN/MME may initiate > a PDP/PDN request to the GGSN/PGW. > > The failures are likely to occur in both stages due to an incompliant > implementation in the visited network or a mismatch between the > subscriber requested and the capability of the visited network. The > failures in the attachment stage are independent of the home routed or > the local breakout mode, while most failure cases in the PDP/PDN > context creation stage occur in the local breakout cases. Section 4 > and 5 describe each case. The below table lists several cases > concerning the the PDP/PDN creation stage. > > > > > Chen, et al. Expires January 5, 2015 [Page 5] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > +-------------+-------------------+--------------+ > | UE request | PDN/PDP IP Type |Local breakout| > | | permitted | | > +-------------+-------------------+--------------+ > | IPv4v6 | IPv4 or IPv6 |Failure case 1| > +-------------+-------------------+--------------+ > | IPv4v6 | IPv6 |Failure case 2| > +-------------+-------------------+--------------+ > | IPv6 | IPv4 |Failure case 3| > +-------------+-------------------+--------------+ > | IPv6 | IPv6 |Failure case 4| > | with 464xlat| without NAT64 | | > +-------------+-------------------+--------------+ > > Table 1: Roaming Scenario Descriptions > > 4. Failure Case in Attachment Stage > > 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request > both IPv4 and IPv6 within a single PDP/PDN request. This option is > stored as a part of subscription data for a subscriber in the HLR/ > HSS. PDP/PDN type IPv4v6 was introduced at the inception of > Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks > should have no issues with the handling of this PDN type. However, > support varies in 2/3G networks denpending on Serving GPRS > Support Node (SGSN) software version. In theory the S4-SGSN (i.e. > an SGSN with a S4 interface) supports the PDP/PDN type IPv4v6 since > Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface) supports it > since Release 9. In most cases, operators normally use Gn-SGSN to > connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G. > The MAP (Mobile Application Part) protocol, as defined in 3GPP > [TS29.002], is used over the Gr interface between SGSN and HLR. The > MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP > Type that is conveyed to SGSN from the HLR within the Insert > Subscriber Data (ISD) MAP operation. If the SGSN does not support > the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and > consequently it must silently discard that IE and continue processing > the rest of the ISD MAP message. The issue we observe is that multiple > SGSNs will be unable to correctly process a subscriber's data received > in the Insert Subscriber Data procedure[TS23.060]. As a consequence, > it will likely refuse the subscriber attach request. This is erroneous > behaviour due to the equipment not being 3GPP Release 9 compliant. > > Operators may have to remove the PDP/PDN type IPv4v6 from the HLR/HSS > in the home network, that will restrict UEs to only initiate IPv4 PDP > or IPv6 PDP activation. In order to avoid this situation, operators > should make a comprehensive roaming agreement to support IPv6 and > ensure that it aligns with the GSMA documents, e.g [IR.33], [IR.88] > > > > Chen, et al. Expires January 5, 2015 [Page 6] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > and [IR.21]. Such an agreement requires the visited operator to get > the necessary patch on all their SGSN nodes to support PDP/PDN type > IPv4v6. > > As an alternative solution there are some specific implementations > (not standardised by 3GPP) in the HLS/HSS of the home network. > When the HLR/HSS receives an Update Location message from a visited > SGSN known to not support the PDP type IPv4v6, subscription data with > only PDP/PDN type IPv4 will be sent to that SGSN in the Insert > Subscriber Data procedure. It guarantees the user profile is > compatible with visited SGSN/MME capability. > > 5. Failure Cases in PDP/PDN Creation > > When a subscriber succeeds in the attach stage, the IP allocation > process takes place to allocate IP addresses to the subscriber. This > section summarizes several failures in the break-out cases. > > 5.1. Case 1: Splitting Dual-stack Bearer > > Dual-stack capability can be provided using separate PDP/PDN > activations. That means only separate parallel single-stack IPv4 > and IPv6 PDP/PDN connections are allowed to be initiated to separately > allocate IPv4 and IPv6 addresses. > The cases are listed below: > > o The SGSN/MME returns Session Manamgement (SM) Cause #52, "Single > address bearers only allowed", or SM Cause #28 "Unknown PDP > address or PDP type" as per[TS24.008] and [TS24.301]. > > o The SGSN/MME does not set the Dual Address Bearer Flag because the > operator uses single addressing per bearer to support interworking > with nodes of earlier releases > > A roaming subscriber's UE with IPv4v6 PDP/PDN type has to change the > request into two separated PDP/PDN requests with a single IP version i= n > order to achieve equivalent results. > Some drawbacks of this case are listed below: > > o The parallel PDP/PDN activations would likely double PDP/PDN > resources consumption. It also impacts the capacity of GGSN/PGW, > since a certain amount of PDP/PDN activations are only allowed on > those nodes. > > o Some networks may only allow one PDP/PDN is alive for each > subscriber. For example, an IPv6 PDP/PDN will be rejected if the > subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber > will lose the IPv6 connection in the visited network. It is even > worse as they may have a risk of losing all data connectivity if th= e > IPv6 PDP gets rejected with a permanent error at the APN-level and > not specific to the PDP-Type IPv6 requested. > > > Chen, et al. Expires January 5, 2015 [Page 7] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > o Additional correlations between those two PDP/PDN contexts are > required on the charging system. > > o Policy and Charging Rules Function(PCRF)/Policy and Charging > Enforcement Function (PCEF) treats the IPv4 and IPv6 session as > independent and performs different Quality of Service (QoS) > policies. The subscriber may have unstable experiences due to > different behaviors on each IP version connection. > > o Mobile devices may have a limitation on allowed simultaneous > PDP/PDN activations. Too many active PDP/PDN connections may resul= t > in > other unrelated services broken. > > Operators may have to disable the local-break mode to avoid the > risks. Another approach is to set a dedicated Access Point Name > (APN) profile to only request PDP/PDN type IPv4 in the roaming > network. > > 5.2. Case 2: Lack of IPv6 support in applications > > Some operators may adopt an IPv6-only configuration for the IMS servic= e, > e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite > (RCS)[RCC.07]. Since the IMS roaming architecture will offload all > traffic in the visited network, a dual-stack subscriber can only be > assigned with an IPv6 prefix and no IPv4 address returned. This > requires that all the IMS based applications should be IPv6 capable. > A translation-based method, for example Bump-in-the-host (BIH)[RFC6535= ] > or 464xlat [RFC6877] may help to address the issue if there are IPv6 > compatibility problems. Those functions could be automatically > enabled in an IPv6-only network and disabled in a dual-stack or IPv4 > network. > > 5.3. Case 3: Fallback Incapability > > 3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4. > Therefore, the IPv6 single PDP/PDN type has been well supported and > interpretable in the 3GPP network nodes. Roaming to IPv4-only > networks and making a IPv6 PDP/PDN request should guarantee that the > subscription data is compatible with the visited pre-Release 9 SGSN. > When a subscriber requests PDP/PDN type IPv6, the network should only > return the expected IPv6 prefix. The mobile device may fail to get > an IPv6 prefix if the visited network can only allocate an IPv4 addres= s > to the subscriber. In that case, the request will be dropped and the > cause code should be sent to the user. > > A proper fallback is desirable, however the behavior is implementation > specific. There are some mobile devices have the ability to provide > a different configuration for home network and visited network > > > > Chen, et al. Expires January 5, 2015 [Page 8] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > respectively. For instance, the Android system solves the issue by > setting the roaming protocol to IPv4 for the Access Point Name(APN). > It guarantees that UE will always initiate an PDP/PDN of type IPv4 in > the roaming area. > > 5.4. Case 4: 464xlat Support > > 464xlat[RFC6877] is proposed to address the IPv4 compatibility issue > in a IPv6 single-stack environment. The function on a mobile device > is likely in conjunction with a PDP/PDN IPv6 type request and requires > a remote NAT64 [RFC6146] gateway. 464xlat may use the mechanism > defined in [RFC7050] to automatically detect the presence of DNS64 and > to learn the IPv6 prefix used for protocol translation. In the local > breakout approach when a mobile device roams to an IPv6 visited networ= k > without the presence of NAT64 or DNS64, 464xlat will fail to function. > > The issue has been found mostly in a intra-PLMN mobility case for the > time being. Considering the various network's situations, operators > may turn off the local breakout and use the home routed mode to perfor= m > 464xlat. Some devices may support the configuration to adopt 464xlat > in the home networks and use IPv4-only in the visited networks with > different roaming profile configurations. This could also be a > solution to address this issue. > > 6. Discussions > > Several failure cases have been discussed in this document. It has > been testified that the major issues happened at two stages, i.e., > the initial network attach and the IP allocation process. > > During the initial network attach, PDP/PDN type IPv4v6 is the major > problem to the visited pre-Release 9 SGSN. The dual-stack deployment > is recommended in most cases. However, it may take some times in a > mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the > early release. Such PDP/PDN type is supported in new-built EPS > network, but didn't support well in the third generation network. > The situations discussed may cause the roaming issues dropping with > the attach request from dual-stack subscribers. Operators may have to > adopt > temporary solution unless all the interworking nodes(i.e. the SSGNs) i= n > the visited network have been upgraded to support the ext-PDP-Type > feature. > > The issues in the IP address allocation process are caused by a local > breakout policy. Since the IP address is allocated by the visited > GGSN or PGW, the mismatch is found in the following aspects. > > o The mismatch between the requested PDP/PDN type and the permitted > PDP/PDN type > > > > Chen, et al. Expires January 5, 2015 [Page 9] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > o The mismatch between the application capability and allowed network > connections > > o The mismatch between mobile device function (e.g., 464xlat) and > the support for that function in the vistited network > > There are some solutions to overcome the issue. Those solutions can > be made either in the network side or mobile device side. The below > lists potential workarounds. > > o Change local breakout to the home routed mode > > o A dedicated roaming APN profile is implemented for the roamer. When= a > subscriber roams to a visited network, PDP/PDN type IPv4 is to be > always selected for session activation. > > o Networks could deploy a AAA server to coordinate the mobile device > capability. Once the GGSN/PGW receives the session creation > request, it will initiate an Access-Request to an AAA server in > the home network via the Radius protocol. The Access-Request > contains subscriber and visited network information, e.g. PDP/PDN > Type, International Mobile Equipment Id (IMEI), Software > Version(SV) and visited SGSN/MME location code, etc. The AAA > server could take mobile device capability and combine it with the > visited network information to ultimately determine the type of > session to be created, i.e. IPv4, IPv6 or IPv4v6. > > 7. IANA Considerations > > This document makes no request of IANA. > > 8. Security Considerations > > This document does not define a new architecture nor a new > protocol, but it is encouraged to refer to [RFC6459] for a generic > discussion on IPv6-related security considerations. > > 9. Acknowledgements > > Many thanks to F. Baker and J. Brzozowski for their support. > > This document is the result of the IETF v6ops IPv6-Roaming design > team effort. > > The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, > Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for > their helpful comments. > > > > > Chen, et al. Expires January 5, 2015 [Page 10] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > 10. References > > 10.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. > Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, > 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, April 2011. > > [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van > Beijnum, "DNS64: DNS Extensions for Network Address > Translation from IPv6 Clients to IPv4 Servers", RFC 6147, > April 2011. > > [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts > Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. > > [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: > Combination of Stateful and Stateless Translation", RFC > 6877, April 2013. > > [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of > the IPv6 Prefix Used for IPv6 Address Synthesis", RFC > 7050, November 2013. > > 10.2. Informative References > > [EU-Roaming-III] > "http://www.amdocs.com/Products/Revenue- > Management/Documents/ > amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. > > [IR.21] Global System for Mobile Communications Association, > GSMA., "Roaming Database, Structure and Updating > Procedures", July 2012. > > [IR.33] Global System for Mobile Communications Association, > GSMA., "GPRS Roaming Guidelines", July 2012. > > [IR.65] Global System for Mobile Communications Association, > GSMA., "IMS Roaming & Interworking Guidelines", May 2012. > > > > > Chen, et al. Expires January 5, 2015 [Page 11] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > [IR.88] Global System for Mobile Communications Association, > GSMA., "LTE Roaming Guidelines", January 2012. > > [IR.92] Global System for Mobile Communications Association > (GSMA), , "IMS Profile for Voice and SMS Version 7.0", > March 2013. > > [RCC.07] Global System for Mobile Communications Association > (GSMA), , "Rich Communication Suite 5.1 Advanced > Communications Services and Client Specification Version > 4.0", November 2013. > > [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., > Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation > Partnership Project (3GPP) Evolved Packet System (EPS)", > RFC 6459, January 2012. > > [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only > Network", RFC 6586, April 2012. > > [TR23.975] > 3rd Generation Partnership Project, 3GPP., "IPv6 migration > guidelines", June 2011. > > [TS23.060] > 3rd Generation Partnership Project, 3GPP., "General Packet > Radio Service (GPRS); Service description; Stage 2 v9.00", > March 2009. > > [TS23.401] > 3rd Generation Partnership Project, 3GPP., "General Packet > Radio Service (GPRS) enhancements for Evolved Universal > Terrestrial Radio Access Network (E-UTRAN) access v9.00", > March 2009. > > [TS24.008] > 3rd Generation Partnership Project, 3GPP., "Mobile radio > interface Layer 3 specification; Core network protocols; > Stage 3 v9.00", September 2009. > > [TS24.301] > 3rd Generation Partnership Project, 3GPP., "Non-Access- > Stratum (NAS) protocol for Evolved Packet System (EPS) ; > Stage 3 v9.00", September 2009. > > > > > > > > Chen, et al. Expires January 5, 2015 [Page 12] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > [TS29.002] > 3rd Generation Partnership Project, 3GPP., "Mobile > Application Part (MAP) specification v9.00", December > 2009. > > [TS29.272] > 3rd Generation Partnership Project, 3GPP., "Mobility > Management Entity (MME) and Serving GPRS Support Node > (SGSN) related interfaces based on Diameter protocol > v9.00", September 2009. > > Authors' Addresses > > Gang Chen > China Mobile > 53A,Xibianmennei Ave., > Xuanwu District, > Beijing 100053 > China > > Email: phdgang@gmail.com > > > Hui Deng > China Mobile > 53A,Xibianmennei Ave., > Xuanwu District, > Beijing 100053 > China > > Email: denghui@chinamobile.com > > > Dave Michaud > Rogers Communications > 8200 Dixie Rd. > Brampton, ON L6T 0C1 > Canada > > Email: dave.michaud@rci.rogers.com > > > Jouni Korhonen > Renesas Mobile > Porkkalankatu 24 > FIN-00180 Helsinki, Finland > > Email: jouni.nospam@gmail.com > > > > Chen, et al. Expires January 5, 2015 [Page 13] > > > Internet-Draft IPv6 Roaming Analysis July 2014 > > > Mohamed Boucadair > France Telecom > Rennes, > 35000 > France > > Email: mohamed.boucadair@orange.com > > > Vizdal Ales > Deutsche Telekom AG > Tomickova 2144/1 > Prague 4, 149 00 > Czech Republic > > Email: ales.vizdal@t-mobile.cz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chen, et al. Expires January 5, 2015 [Page 14] From nobody Mon Jul 28 22:10:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDA31A007C for ; Mon, 28 Jul 2014 22:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 KE-yTs16T1qa for ; Mon, 28 Jul 2014 22:10:23 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D6D1A004A for ; Mon, 28 Jul 2014 22:10:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E5C0BA1; Tue, 29 Jul 2014 07:10:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406610620; bh=jA1X7+z6+tXzQtqT1hEht5CwvEhAiW+kp22Rq9gOWrI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1uUq7D38El469uO0GHh049B1W0/5U7sOAHsVREz6R9hZxjY3LmhiGf7oSGaT47iAI S/kcn4N0xzo0lx/My+losbPgRWgviexTUVkiuTE+oxCgX3n+x5JMQbjDWyZz0VHmec pDlbBWnA1aQYftA3TiTu+j4mn0qgzqqrfVEpyLt8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DCD799F; Tue, 29 Jul 2014 07:10:20 +0200 (CEST) Date: Tue, 29 Jul 2014 07:10:20 +0200 (CEST) From: Mikael Abrahamsson To: GangChen In-Reply-To: Message-ID: References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7aXzUnduaMKfGN4Gvn_KDRM-37E Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 05:10:25 -0000 On Tue, 29 Jul 2014, GangChen wrote: > Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support > IPv4v6 setting(that is the most case pre-R9), in other words, it can't > set ext_pdp. It may not able to support all cases. Then I guess it's a matter of implementation. The HLR I was exposed to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If UE asked for IPv6 only PDP context that didn't work, so we had to add a profile that said "IPv6" without ext_pdp_context_type. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Jul 29 15:14:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B28D1B2905 for ; Tue, 29 Jul 2014 15:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=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 X0ZIkRuNVaYl for ; Tue, 29 Jul 2014 15:14:31 -0700 (PDT) Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by ietfa.amsl.com (Postfix) with SMTP id 202A71B28FA for ; Tue, 29 Jul 2014 15:14:30 -0700 (PDT) Received: (qmail 22363 messnum 1745001 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 29 Jul 2014 22:14:28 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail12.svc.cra.dublin.eircom.net (qp 22363) with SMTP; 29 Jul 2014 22:14:28 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id YNEQ1o01P0mJ9Tz01NEUmw; Tue, 29 Jul 2014 23:14:28 +0100 From: Ross Chandler Content-Type: multipart/alternative; boundary="Apple-Mail=_FBB21BDB-DC8F-43AF-B25C-ECCD39036282" Message-Id: <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 29 Jul 2014 23:14:26 +0100 References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> To: v6ops@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9SLj-wVTiuYl2cDI8p-s89pb0Ec Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 22:14:36 -0000 --Apple-Mail=_FBB21BDB-DC8F-43AF-B25C-ECCD39036282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 29 Jul 2014, at 06:10, Mikael Abrahamsson wrote: > On Tue, 29 Jul 2014, GangChen wrote: >=20 >> Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support >> IPv4v6 setting(that is the most case pre-R9), in other words, it = can't >> set ext_pdp. It may not able to support all cases. >=20 > Then I guess it's a matter of implementation. The HLR I was exposed = to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type = IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If UE = asked for IPv6 only PDP context that didn=92t work, so we had to add a = profile that said "IPv6" without ext_pdp_context_type. We have to define two allowed PDP Types for the same APN, so that legacy = IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same = APN. e.g.=20
On 29 Jul 2014, at 06:10, = Mikael Abrahamsson <swmike@swm.pp.se> = wrote:

On Tue, 29 Jul 2014, GangChen = wrote:

Only the value IPv4v6 is allowed = for ext_pdp. If HLR doesn't support
IPv4v6 setting(that is the most = case pre-R9), in other words, it can't
set ext_pdp. It may not able = to support all cases.

Then I guess it's a matter of = implementation. The HLR I was exposed to, did for 2G/3G show to the user = that IPv4 could have ext_pdp_type IPv6, and this enabled IPv4 and = IPv4v6 to work with this setting. If UE asked for IPv6 only PDP context = that didn=92t work, so we had to add a profile that said "IPv6" = without ext_pdp_context_type.

We have to define = two allowed PDP Types for the same APN, so that legacy IPv4 PDPs and = IPv6 PDPs for 464xlat can both be requested for the same = APN.

e.g. 

<hgppp:pdpcp=3D240;
HLR PACKET DATA PROTOCOL = CONTEXT PROFILE DATA
PDPCP  APNID  EQOSID  VPAA =  PDPCH    PDPTY  PDPID EPDPIND
240     =   80     1    NO         =     IPV4   25    NO
      =     76     1    NO       =       IPV4   26    NO
    =       74     1    NO     =         IPV4   31    NO
  =         73     1    NO   =           IPV4   32    NO =  <-- testdata APN V4 
          = 73     1    NO           =   IPV6   50    NO  <-- testdata APN = V6

If the Android UE APN Protocol is set to =93IPv4/IPv6=94 = with this it sets up parallel bearers to the = GGSN/PGW.

I agree with Mikael that it might be = worth having a section noting this behaviour. An operator doing 464xlat = could have UEs connecting with dual-stack done over separate bearers = when they=92d prefer it to either be single bearer with legacy IPv4 or = IPv6 with 464xlat.  This applies in the home and roaming = case.

Ross
= --Apple-Mail=_FBB21BDB-DC8F-43AF-B25C-ECCD39036282-- From nobody Tue Jul 29 20:16:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B911A0652 for ; Tue, 29 Jul 2014 20:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.006 X-Spam-Level: ** X-Spam-Status: No, score=2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=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 vA-emzJRZHVE for ; Tue, 29 Jul 2014 20:16:24 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD931A04B7 for ; Tue, 29 Jul 2014 20:16:24 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so683998pdb.31 for ; Tue, 29 Jul 2014 20:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=VnEUf8XzuUwLAbG7dHK+MPvwkSrgv22IUIspw+kE09w=; b=YWzFI2E396I8HwWbKNP5WbHu7YlMMWv79Q1FDwHPCzOqXaj6KBo86Eea88ZYssMuri qMOuKw5sadxTsulFX2/E7MkyGHRpQJX+V3R/AB3zhpwRxVqt6tgmiHjSfocS3Y++WQKA q4VPSIKuVnGC9m86Q0HQAkcFSS8V7PLcBNLoM+hS334kvIgrfBLi6A89pZlE97Auas4V VXkbXDNyHzMZxXm3d+cgwRaGiI81gGNs086UV8glJicWNWcowYYvMWkkNUcLyWV+SBIJ A1jcCozwtRlADvkCRcsHjT45K+eZumfSqP9bYEoCQJ3L+2+o14T4TqEmDzD1qlbrYYi5 HPvw== X-Received: by 10.68.162.100 with SMTP id xz4mr1306772pbb.120.1406690184009; Tue, 29 Jul 2014 20:16:24 -0700 (PDT) Received: from [192.168.23.129] ([183.243.251.235]) by mx.google.com with ESMTPSA id xy4sm2972764pac.19.2014.07.29.20.16.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 20:16:23 -0700 (PDT) Message-ID: <53C4B91A.8090702@gmail.com> Date: Mon, 14 Jul 2014 22:16:10 -0700 From: gangchen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> In-Reply-To: <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> Content-Type: multipart/alternative; boundary="------------000305070701000005070001" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xmA7r1o94fT3GSDte7VMKqQH4mk Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 03:16:26 -0000 This is a multi-part message in MIME format. --------------000305070701000005070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mikael and Ross, One section will be added according to the discussion. The following is proposed text. Please kindly check. Section 6. HLR/HSS User Profile Recommendation A proper user profile configuration provides devices with good tolerance to various scenarios. The following are examples to demonstrate the setting. Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices user profile #1: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type-IPv4 .... ext-pdp-Type Ext-PDP-Type ... } user profile #2: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type-IPv6 .... } Note: the full PDP-context list is referred to section 17.7.1 "Mobile Service date types" of TS29.002. User profile 1 and 2 share the same contextId. Scenario 2: Support dual-stack devices with pre-R9 vSGSN access user profile #1: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type-IPv4 .... ext-pdp-Type Ext-PDP-Type ... } user profile #2: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type-IPv4 .... } Note: User profile 1 and 2 share the same contextId. HLR/HSS is able to identify pre-R9 vSGSN and only send user profile#2 to vSGSN. BRs Gang On 07/29/2014 03:14 PM, Ross Chandler wrote: > > On 29 Jul 2014, at 06:10, Mikael Abrahamsson > wrote: > >> On Tue, 29 Jul 2014, GangChen wrote: >> >>> Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support >>> IPv4v6 setting(that is the most case pre-R9), in other words, it can't >>> set ext_pdp. It may not able to support all cases. >> >> Then I guess it's a matter of implementation. The HLR I was exposed >> to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type >> IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If >> UE asked for IPv6 only PDP context that didn't work, so we had to add >> a profile that said "IPv6" without ext_pdp_context_type. > > We have to define two allowed PDP Types for the same APN, so that > legacy IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for > the same APN. > > e.g. > > HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA > PDPCP APNID EQOSID VPAA PDPCH PDPTY PDPID EPDPIND > 240 80 1 NO IPV4 25 NO > 76 1 NO IPV4 26 NO > 74 1 NO IPV4 31 NO > 73 1 NO IPV4 32 NO <-- testdata APN V4 > 73 1 NO IPV6 50 NO <-- testdata APN V6 > > If the Android UE APN Protocol is set to "IPv4/IPv6" with this it sets > up parallel bearers to the GGSN/PGW. > > I agree with Mikael that it might be worth having a section noting > this behaviour. An operator doing 464xlat could have UEs connecting > with dual-stack done over separate bearers when they'd prefer it to > either be single bearer with legacy IPv4 or IPv6 with 464xlat. This > applies in the home and roaming case. > > Ross > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------000305070701000005070001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Mikael and Ross,

 

One section will be added according to the discussion. The following is proposed text.

Please kindly check.

 

Section 6. HLR/HSS User Profile Recommendation

 

A proper user profile configuration provides devices with good

tolerance to various scenarios. The following are examples to demonstrate

the setting.

 

Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices

 

user profile #1:

 

  PDP-Context ::= SEQUENCE {

         pdp-ContextId ContextId,

         pdp-Type           PDP-Type-IPv4

  ....

         ext-pdp-Type    Ext-PDP-Type

  ...

         }

 

 

user profile #2:

 

  PDP-Context ::= SEQUENCE {

         pdp-ContextId ContextId,

         pdp-Type           PDP-Type-IPv6

  ....

         }

 

Note: the full PDP-context list is referred to section 17.7.1 "Mobile Service date types" of TS29.002. User profile 1 and 2 share the same contextId.

 

Scenario 2: Support dual-stack devices with pre-R9 vSGSN access

 

user profile #1:

 

  PDP-Context ::= SEQUENCE {

         pdp-ContextId ContextId,

         pdp-Type           PDP-Type-IPv4

  ....

         ext-pdp-Type    Ext-PDP-Type

  ...

         }

 

 

user profile #2:

 

  PDP-Context ::= SEQUENCE {

         pdp-ContextId ContextId,

         pdp-Type           PDP-Type-IPv4

  ....

         }

          

Note: User profile 1 and 2 share the same contextId.

HLR/HSS is able to identify pre-R9 vSGSN and only send user profile#2 to vSGSN.


BRs

Gang

On 07/29/2014 03:14 PM, Ross Chandler wrote:

On 29 Jul 2014, at 06:10, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Tue, 29 Jul 2014, GangChen wrote:

Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support
IPv4v6 setting(that is the most case pre-R9), in other words, it can't
set ext_pdp. It may not able to support all cases.

Then I guess it's a matter of implementation. The HLR I was exposed to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If UE asked for IPv6 only PDP context that didn’t work, so we had to add a profile that said "IPv6" without ext_pdp_context_type.

We have to define two allowed PDP Types for the same APN, so that legacy IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same APN.

e.g. 

<hgppp:pdpcp=240;
HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA
PDPCP  APNID  EQOSID  VPAA  PDPCH    PDPTY  PDPID EPDPIND
240       80     1    NO             IPV4   25    NO
          76     1    NO             IPV4   26    NO
          74     1    NO             IPV4   31    NO
          73     1    NO             IPV4   32    NO  <-- testdata APN V4 
          73     1    NO             IPV6   50    NO  <-- testdata APN V6

If the Android UE APN Protocol is set to “IPv4/IPv6” with this it sets up parallel bearers to the GGSN/PGW.

I agree with Mikael that it might be worth having a section noting this behaviour. An operator doing 464xlat could have UEs connecting with dual-stack done over separate bearers when they’d prefer it to either be single bearer with legacy IPv4 or IPv6 with 464xlat.  This applies in the home and roaming case.

Ross


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

--------------000305070701000005070001-- From nobody Tue Jul 29 20:20:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9E31A0537 for ; Tue, 29 Jul 2014 20:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=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 318Svoqmsyv8 for ; Tue, 29 Jul 2014 20:20:06 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689971A04B1 for ; Tue, 29 Jul 2014 20:20:06 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j7so686263qaq.0 for ; Tue, 29 Jul 2014 20:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7n9i8J+UqDxCGzS2I9Ez7XX63G1BK7SVkKsqbkdOV/U=; b=LIc6xdmF48x+usIFFtxI2sdF4fQFOdtP1JImN9HmAx3GyLxTS3RFavSgIN2RpSt+qb +dy4+3iT9XewOzBz1K/3HFTSHyL+ewImq+pSFUpBVY5peEJ3LaTVpJLaT/wLb00ztkOq 38p7EsWnVYQzIHYYJdXsx9tG/CA2jDMLkujUX34tdPYO4X7tTiwGiYT8HFw4pZzDEzt+ FO00rukR5efGHkEfcj4Il5rhXehpO+/GS2FY2NlogTpQdZu536oVaIfb4/Kflj6KROOr YjV+VIG8xp0NzqteB1U0ZsgNE9yYh45WGKHV6tzhSs87FobayxtSSEWKmO9Unq8SpxsU QzIA== MIME-Version: 1.0 X-Received: by 10.224.123.8 with SMTP id n8mr1972209qar.40.1406690405669; Tue, 29 Jul 2014 20:20:05 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Tue, 29 Jul 2014 20:20:05 -0700 (PDT) In-Reply-To: References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> Date: Wed, 30 Jul 2014 11:20:05 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Q8pVy5qeyQw6Dz2vKBYi4vq-EbY Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 03:20:07 -0000 2014-07-29 13:10 GMT+08:00, Mikael Abrahamsson : > On Tue, 29 Jul 2014, GangChen wrote: > >> Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support >> IPv4v6 setting(that is the most case pre-R9), in other words, it can't >> set ext_pdp. It may not able to support all cases. > > Then I guess it's a matter of implementation. The HLR I was exposed to, > did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6, and > this enabled IPv4 and IPv4v6 to work with this setting. If UE asked for > IPv6 only PDP context that didn't work, so we had to add a profile that > said "IPv6" without ext_pdp_context_type. If I understand correctly, the setting would be #1 is IPv4 + ext_pdp_type; #2 is IPv6 only; Those two profiles have same ContextId. #1: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type IPv4 .... ext-pdp-Type Ext-PDP-Type ... } #2: PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type PDP-Type, IPv6 .... } BRs Gang > -- > Mikael Abrahamsson email: swmike@swm.pp.se > From nobody Wed Jul 30 00:27:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AC21ABB1D for ; Wed, 30 Jul 2014 00:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=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 MQICZguN8QnQ for ; Wed, 30 Jul 2014 00:27:20 -0700 (PDT) Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by ietfa.amsl.com (Postfix) with SMTP id 78B641ABB33 for ; Wed, 30 Jul 2014 00:27:20 -0700 (PDT) Received: (qmail 35763 messnum 9938980 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 30 Jul 2014 07:27:17 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail07.svc.cra.dublin.eircom.net (qp 35763) with SMTP; 30 Jul 2014 07:27:17 -0000 Received: from [192.168.43.190] ([86.43.53.6]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id YXTD1o00h0829we01XTHCM; Wed, 30 Jul 2014 08:27:17 +0100 From: Ross Chandler Content-Type: multipart/alternative; boundary="Apple-Mail=_871B5464-0F82-4E9F-B52C-A7A729E3AA67" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 30 Jul 2014 08:27:12 +0100 References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> <53C4B91A.8090702@gmail.com> To: v6ops@ietf.org In-Reply-To: <53C4B91A.8090702@gmail.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/k1ochVDzBffAHrauofbV8ke29So Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 07:27:23 -0000 --Apple-Mail=_871B5464-0F82-4E9F-B52C-A7A729E3AA67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 15 Jul 2014, at 06:16, gangchen wrote: Gang, Wording tweak below. I hope haven=92t altered the meaning. Section 6. HLR/HSS User Profile Recommendation A proper user profile configuration should provide deterministic network control of the connectivity that can be set-up from the device: IPv4-only, IPv6-only, dual-stack using separate bearers, or dual-stack using a single beaerer. The HLR/HSS may have to apply extra logic to achieve this. It may be expected that the device could attempt to set-up connectivity = by any of the above means.=20 The following are examples to demonstrate the settings for the scenarios and decision criteria to apply when returning user profile information = to=20 the SGSN. Ross > One section will be added according to the discussion. The following = is proposed text. > Please kindly check. >=20 > =20 >=20 > Section 6. HLR/HSS User Profile Recommendation >=20 > =20 >=20 > A proper user profile configuration should provide devices with good >=20 > tolerance to various scenarios. The following are examples to = demonstrate >=20 > the setting. >=20 > =20 >=20 > Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices >=20 > =20 >=20 > user profile #1: >=20 > =20 >=20 > PDP-Context ::=3D SEQUENCE { >=20 > pdp-ContextId ContextId, >=20 > pdp-Type PDP-Type-IPv4 >=20 > .... >=20 > ext-pdp-Type Ext-PDP-Type >=20 > ... >=20 > } >=20 > =20 >=20 > =20 >=20 > user profile #2: >=20 > =20 >=20 > PDP-Context ::=3D SEQUENCE { >=20 > pdp-ContextId ContextId, >=20 > pdp-Type PDP-Type-IPv6 >=20 > .... >=20 > } >=20 > =20 >=20 > Note: the full PDP-context list is referred to section 17.7.1 "Mobile = Service date types" of TS29.002. User profile 1 and 2 share the same = contextId. >=20 > =20 >=20 > Scenario 2: Support dual-stack devices with pre-R9 vSGSN access >=20 > =20 >=20 > user profile #1: >=20 > =20 >=20 > PDP-Context ::=3D SEQUENCE { >=20 > pdp-ContextId ContextId, >=20 > pdp-Type PDP-Type-IPv4 >=20 > .... >=20 > ext-pdp-Type Ext-PDP-Type >=20 > ... >=20 > } >=20 > =20 >=20 > =20 >=20 > user profile #2: >=20 > =20 >=20 > PDP-Context ::=3D SEQUENCE { >=20 > pdp-ContextId ContextId, >=20 > pdp-Type PDP-Type-IPv4 >=20 > .... >=20 > } >=20 > =20 >=20 > Note: User profile 1 and 2 share the same contextId. >=20 > HLR/HSS is able to identify pre-R9 vSGSN and only send user profile#2 = to vSGSN. >=20 >=20 > BRs >=20 > Gang >=20 > On 07/29/2014 03:14 PM, Ross Chandler wrote: >>=20 >> On 29 Jul 2014, at 06:10, Mikael Abrahamsson = wrote: >>=20 >>> On Tue, 29 Jul 2014, GangChen wrote: >>>=20 >>>> Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't = support >>>> IPv4v6 setting(that is the most case pre-R9), in other words, it = can't >>>> set ext_pdp. It may not able to support all cases. >>>=20 >>> Then I guess it's a matter of implementation. The HLR I was exposed = to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type = IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If UE = asked for IPv6 only PDP context that didn=92t work, so we had to add a = profile that said "IPv6" without ext_pdp_context_type. >>=20 >> We have to define two allowed PDP Types for the same APN, so that = legacy IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the = same APN. >>=20 >> e.g.=20 >>=20 >> > HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA >> PDPCP APNID EQOSID VPAA PDPCH PDPTY PDPID EPDPIND >> 240 80 1 NO IPV4 25 NO >> 76 1 NO IPV4 26 NO >> 74 1 NO IPV4 31 NO >> 73 1 NO IPV4 32 NO <-- testdata = APN V4=20 >> 73 1 NO IPV6 50 NO <-- testdata = APN V6 >>=20 >> If the Android UE APN Protocol is set to =93IPv4/IPv6=94 with this it = sets up parallel bearers to the GGSN/PGW. >>=20 >> I agree with Mikael that it might be worth having a section noting = this behaviour. An operator doing 464xlat could have UEs connecting with = dual-stack done over separate bearers when they=92d prefer it to either = be single bearer with legacy IPv4 or IPv6 with 464xlat. This = applies in the home and roaming case. >>=20 >> Ross >>=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 --Apple-Mail=_871B5464-0F82-4E9F-B52C-A7A729E3AA67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 15 Jul 2014, at 06:16, gangchen = <phdgang@gmail.com> = wrote:

Gang,

Wording = tweak below.  I hope haven=92t altered the = meaning.

Section 6. HLR/HSS User Profile = Recommendation

A proper user profile = configuration should provide deterministic network
control of = the connectivity that can be set-up from the device:
IPv4-only, = IPv6-only, dual-stack using separate bearers, or dual-stack
using a = single beaerer. The HLR/HSS may have to apply extra logic
to achieve = this.

It may be expected that the device could attempt to = set-up connectivity by any
of the above means. 

The following are examples to demonstrate the = settings for the scenarios
and decision criteria to apply when returning = user profile information to 
the SGSN.

Ross


=20 =20
One section will be added according to the discussion. The following is proposed = text.

Please kindly = check.

 

Section 6. HLR/HSS User Profile Recommendation

 

A proper user profile configuration should provide devices with = good

tolerance to various scenarios. The following are examples to = demonstrate

the setting.

 

Scenario 1: Support IPv6-only, IPv4-only and dual-stack = devices

 

user profile #1:

 

  PDP-Context ::=3D = SEQUENCE {

         = pdp-ContextId ContextId,

         = pdp-Type           PDP-Type-IPv4

  ....

         = ext-pdp-Type    Ext-PDP-Type

  ...

         = }

 

 

user profile #2:

 

  PDP-Context ::=3D = SEQUENCE {

         = pdp-ContextId ContextId,

         = pdp-Type           PDP-Type-IPv6

  ....

         } =

 

Note: the full PDP-context list is referred to section 17.7.1 "Mobile Service date types" of TS29.002. User profile 1 and 2 share the same contextId.

 

Scenario 2: Support dual-stack devices with pre-R9 vSGSN = access

 

user profile #1:

 

  PDP-Context ::=3D = SEQUENCE {

         = pdp-ContextId ContextId,

         = pdp-Type           PDP-Type-IPv4

  ....

         = ext-pdp-Type    Ext-PDP-Type

  ...

         = }

 

 

user profile #2:

 

  PDP-Context ::=3D = SEQUENCE {

         = pdp-ContextId ContextId,

         = pdp-Type           PDP-Type-IPv4

  ....

         } =

         =  

Note: User profile 1 and 2 share the same contextId.

HLR/HSS is able to identify pre-R9 vSGSN and = only send user profile#2 to vSGSN.


BRs

Gang

On 07/29/2014 03:14 PM, Ross Chandler wrote:

On 29 Jul 2014, at 06:10, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Tue, 29 Jul 2014, GangChen wrote:

Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support
IPv4v6 setting(that is the most case pre-R9), in other words, it can't
set ext_pdp. It may not able to support all cases.

Then I guess it's a matter of implementation. The HLR I was exposed to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6, and this enabled IPv4 and IPv4v6 to work = with this setting. If UE asked for IPv6 only PDP context that didn=92t work, so we had to add a profile that said "IPv6" without ext_pdp_context_type.

We have to define two allowed PDP Types for the same APN, so that legacy IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same APN.

e.g. 

<hgppp:pdpcp=3D240;
HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA
PDPCP  APNID  EQOSID  VPAA  PDPCH   =  PDPTY  PDPID EPDPIND
240       80     1    NO =             IPV4   25   =  NO
          76     1   =  NO             IPV4   26   =  NO
          74     1   =  NO             IPV4   31   =  NO
          73     1   =  NO             IPV4   32   =  NO  <-- testdata APN V4 
          73     1   =  NO             IPV6   50   =  NO  <-- testdata APN V6

If the Android UE APN Protocol is set to =93IPv4/IPv6=94 with = this it sets up parallel bearers to the GGSN/PGW.

I agree with Mikael that it might be worth having a section noting this behaviour. An operator doing 464xlat could have UEs connecting with dual-stack done over separate bearers when they=92d prefer it to either be single bearer with legacy IPv4 = or IPv6 with 464xlat.  This applies in the home and roaming = case.

Ross


_______________________________________________
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

= --Apple-Mail=_871B5464-0F82-4E9F-B52C-A7A729E3AA67-- From nobody Wed Jul 30 01:32:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91CA1A0272 for ; Wed, 30 Jul 2014 01:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=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 Q0AuMYCEbX6w for ; Wed, 30 Jul 2014 01:32:35 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A58B1A002D for ; Wed, 30 Jul 2014 01:32:34 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so1037694qga.36 for ; Wed, 30 Jul 2014 01:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oajewKl0YZcZ3b841LlCVLbuLASw5CnUctkbI8mOfu0=; b=N/med9vtoa1LyifZ8qZVVgZjWxut1TU/KqfZlOOzxp7NVdneIXmi89zCwvLbrxr0l8 BJNbAzCUQc44TK6FqKkIvyDUmdCdWwXyDXPv2mbBRLqkM+LYzdkG1qPqWTzeXcqWRN82 TK3fxFAKx1fiIkCjHNAvUcPOnhjZw6HgA7rObB2SJGmnCSpzue9fLCjqUk1yQMn97TuI tUghqMNIBL3OnVa4C3UHQelKPKdLXPoJaqTfoLlfEQco106Qd34GK/tkNPCAQt3F+LCY /PMist5Api3zapKK+fkj8YIYJWu+SEMUnvRhMr/czoJrHzTgGdbsmayFWL2GRma76wDL fNqg== MIME-Version: 1.0 X-Received: by 10.224.2.70 with SMTP id 6mr4390254qai.18.1406709154192; Wed, 30 Jul 2014 01:32:34 -0700 (PDT) Received: by 10.224.46.10 with HTTP; Wed, 30 Jul 2014 01:32:34 -0700 (PDT) In-Reply-To: References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> <53C4B91A.8090702@gmail.com> Date: Wed, 30 Jul 2014 16:32:34 +0800 Message-ID: From: GangChen To: Ross Chandler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6_KuKsbGXWn9jvVlRk-pq7UPJwA Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 08:32:36 -0000 2014-07-30 15:27 GMT+08:00, Ross Chandler : > > On 15 Jul 2014, at 06:16, gangchen wrote: > > Gang, > > Wording tweak below. I hope haven=E2=80=99t altered the meaning. > > Section 6. HLR/HSS User Profile Recommendation > > A proper user profile configuration should provide deterministic network > control of the connectivity that can be set-up from the device: > IPv4-only, IPv6-only, dual-stack using separate bearers, or dual-stack > using a single beaerer. The HLR/HSS may have to apply extra logic > to achieve this. IMHO, we may have to avoid dual-stack using separate bearers. So I make a minor revision on the texts as below. A proper user profile configuration could provide deterministic network control of the connectivity requests from dual-stack, IPv4-only and IPv6-only devices. It's desirable that the network could set-up proper connectivity for any type of the devices.The HLR/HSS may have to apply extra logic to achieve this. The following are examples to demonstrate the settings for the scenarios and decision criteria to apply when returning user profile information to the SGSN. BRs Gang > It may be expected that the device could attempt to set-up connectivity b= y > any > of the above means. > > The following are examples to demonstrate the settings for the scenarios > and decision criteria to apply when returning user profile information to > the SGSN. > > Ross > > >> One section will be added according to the discussion. The following is >> proposed text. >> Please kindly check. >> >> >> >> Section 6. HLR/HSS User Profile Recommendation >> >> >> >> A proper user profile configuration should provide devices with good >> >> tolerance to various scenarios. The following are examples to demonstrat= e >> >> the setting. >> >> >> >> Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices >> >> >> >> user profile #1: >> >> >> >> PDP-Context ::=3D SEQUENCE { >> >> pdp-ContextId ContextId, >> >> pdp-Type PDP-Type-IPv4 >> >> .... >> >> ext-pdp-Type Ext-PDP-Type >> >> ... >> >> } >> >> >> >> >> >> user profile #2: >> >> >> >> PDP-Context ::=3D SEQUENCE { >> >> pdp-ContextId ContextId, >> >> pdp-Type PDP-Type-IPv6 >> >> .... >> >> } >> >> >> >> Note: the full PDP-context list is referred to section 17.7.1 "Mobile >> Service date types" of TS29.002. User profile 1 and 2 share the same >> contextId. >> >> >> >> Scenario 2: Support dual-stack devices with pre-R9 vSGSN access >> >> >> >> user profile #1: >> >> >> >> PDP-Context ::=3D SEQUENCE { >> >> pdp-ContextId ContextId, >> >> pdp-Type PDP-Type-IPv4 >> >> .... >> >> ext-pdp-Type Ext-PDP-Type >> >> ... >> >> } >> >> >> >> >> >> user profile #2: >> >> >> >> PDP-Context ::=3D SEQUENCE { >> >> pdp-ContextId ContextId, >> >> pdp-Type PDP-Type-IPv4 >> >> .... >> >> } >> >> >> >> Note: User profile 1 and 2 share the same contextId. >> >> HLR/HSS is able to identify pre-R9 vSGSN and only send user profile#2 to >> vSGSN. >> >> >> BRs >> >> Gang >> >> On 07/29/2014 03:14 PM, Ross Chandler wrote: >>> >>> On 29 Jul 2014, at 06:10, Mikael Abrahamsson wrote: >>> >>>> On Tue, 29 Jul 2014, GangChen wrote: >>>> >>>>> Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support >>>>> IPv4v6 setting(that is the most case pre-R9), in other words, it can'= t >>>>> set ext_pdp. It may not able to support all cases. >>>> >>>> Then I guess it's a matter of implementation. The HLR I was exposed to= , >>>> did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6, >>>> and this enabled IPv4 and IPv4v6 to work with this setting. If UE aske= d >>>> for IPv6 only PDP context that didn=E2=80=99t work, so we had to add a= profile >>>> that said "IPv6" without ext_pdp_context_type. >>> >>> We have to define two allowed PDP Types for the same APN, so that legac= y >>> IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same >>> APN. >>> >>> e.g. >>> >>> >> HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA >>> PDPCP APNID EQOSID VPAA PDPCH PDPTY PDPID EPDPIND >>> 240 80 1 NO IPV4 25 NO >>> 76 1 NO IPV4 26 NO >>> 74 1 NO IPV4 31 NO >>> 73 1 NO IPV4 32 NO <-- testdata APN = V4 >>> >>> 73 1 NO IPV6 50 NO <-- testdata APN >>> V6 >>> >>> If the Android UE APN Protocol is set to =E2=80=9CIPv4/IPv6=E2=80=9D wi= th this it sets up >>> parallel bearers to the GGSN/PGW. >>> >>> I agree with Mikael that it might be worth having a section noting this >>> behaviour. An operator doing 464xlat could have UEs connecting with >>> dual-stack done over separate bearers when they=E2=80=99d prefer it to = either be >>> single bearer with legacy IPv4 or IPv6 with 464xlat. This >>> applies in the home and roaming case. >>> >>> Ross >>> >>> >>> _______________________________________________ >>> 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 Wed Jul 30 04:16:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032D71B2873 for ; Wed, 30 Jul 2014 04:16: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 RFOtCKeZU9kj for ; Wed, 30 Jul 2014 04:15:58 -0700 (PDT) Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id DAA881A02FF for ; Wed, 30 Jul 2014 04:15:57 -0700 (PDT) Received: (qmail 83862 messnum 1755374 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 30 Jul 2014 11:15:56 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail19.svc.cra.dublin.eircom.net (qp 83862) with SMTP; 30 Jul 2014 11:15:56 -0000 Received: from [192.168.43.190] ([86.43.53.6]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id YbFr1o01w0829we01bFvRq; Wed, 30 Jul 2014 12:15:56 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Wed, 30 Jul 2014 12:15:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: <451AABDF-407E-44AE-A5E6-D2409B18DAE7@eircom.net> References: <201407271800.s6RI04sj008989@irp-lnx1.cisco.com> <9A04228A-88BC-4123-BFC3-AF081AEDBDC9@eircom.net> <53C4B91A.8090702@gmail.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NogVJq_NFSXPLTHMbmQOVm3LvgA Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 11:16:01 -0000 On 30 Jul 2014, at 09:32, GangChen wrote: >> > > IMHO, we may have to avoid dual-stack using separate bearers. So I > make a minor revision on the texts as below. Gang, I agree that avoiding dual-stack should be part of the recommendation. Reasons which we might want to also explicitly state: Separate bearers are undesirable because they hold up extra resources in the Radio Access, as well as in the GGSN. and it may complicate the reconciliation of CDRs for a subscriber, particularly in the roaming case. Regards, Ross > > A proper user profile configuration could provide deterministic > network control of > the connectivity requests from dual-stack, IPv4-only and IPv6-only > devices. It's desirable > that the network could set-up proper connectivity for any type of the > devices.The HLR/HSS may have to apply extra logic to achieve this. > > The following are examples to demonstrate the settings for the scenarios > and decision criteria to apply when returning user profile information to > the SGSN. > > BRs > > Gang From nobody Wed Jul 30 04:33:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9A21B278F for ; Wed, 30 Jul 2014 04:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 hlitXXlikOZq for ; Wed, 30 Jul 2014 04:32:54 -0700 (PDT) Received: from smtp06.msg.oleane.net (smtp06.msg.oleane.net [62.161.4.6]) by ietfa.amsl.com (Postfix) with ESMTP id B0FA21A0313 for ; Wed, 30 Jul 2014 04:32:53 -0700 (PDT) Received: from MGosseDellM6800 (AClermont-Ferrand-551-1-193-245.w86-207.abo.wanadoo.fr [86.207.60.245]) (authenticated) by smtp06.msg.oleane.net (MSA) with ESMTP id s6UBVup6014801 for ; Wed, 30 Jul 2014 13:31:57 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Wed, 30 Jul 2014 13:32:45 +0200 Message-ID: <00cb01cfabe9$fc3c3e90$f4b4bbb0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01CFABFA.BFC95450" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+r6clqgjN/XipYSXGrImFW5NgY/A== Content-Language: fr X-Backend: vm-smtp-sophos11v2 X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.30.111818 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/poAe1_RjIZGc8uz3KOybA-2LORw Subject: [v6ops] V6 World 2015: CFP deadline extension X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 11:32:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CC_01CFABFA.BFC95450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fifth Edition of V6 World will take place in Paris from 17 to 18 March, 2015. The agenda will cover in particular SDN, Segment Routing/Spring, V6 in Data Centers and XLAT464 Deployments issues. The call for proposals deadline has been extended to August 22, 2014. More info: http://www.uppersideconferences.com/v6world2015/v6world2015cfp.html ------=_NextPart_000_00CC_01CFABFA.BFC95450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The fifth Edition = of V6 World will take place in Paris = from 17 to 18 March, = 2015. 

The agenda will = cover in particular SDN, Segment Routing/Spring, V6 in Data Centers = and XLAT464 Deployments issues.

 

The call for = proposals deadline has been extended to August 22, = 2014.

 

More info: http://www.uppersideconferences.com/v6world2015/v6world2015cfp.html

 

 

 

------=_NextPart_000_00CC_01CFABFA.BFC95450-- From nobody Thu Jul 31 06:30:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356A21B27F6; Thu, 31 Jul 2014 06:30: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] autolearn=ham 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 jRfLmkoHNZGN; Thu, 31 Jul 2014 06:30:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9981B27FE; Thu, 31 Jul 2014 06:30:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731133023.7121.34025.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 06:30:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JygevLu20bJYSNlxEkkoxjqjVa4 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 13:30:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Enterprise IPv6 Deployment Guidelines Authors : Kiran K. Chittimaneni Tim Chown Lee Howard Victor Kuarsingh Yanick Pouffary Eric Vyncke Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt Pages : 34 Date : 2014-07-31 Abstract: Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-enterprise-incremental-ipv6-06 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/