From nobody Mon Jun 1 10:48:45 2015 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 01F181B2FDD; Mon, 1 Jun 2015 10:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aWG2Pm-AWftR; Mon, 1 Jun 2015 10:48:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A574F1B2FF0; Mon, 1 Jun 2015 10:48:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150601174833.29781.73064.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 10:48:33 -0700 Archived-At: Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Protocol Action: 'IPv6 Prefix Length Recommendation for Forwarding' to Best Current Practice (draft-ietf-v6ops-cidr-prefix-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: Mon, 01 Jun 2015 17:48:42 -0000 The IESG has approved the following document: - 'IPv6 Prefix Length Recommendation for Forwarding' (draft-ietf-v6ops-cidr-prefix-03.txt) as Best Current Practice This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ Technical Summary This short document makes a single BCP recommendation: Hardware and software algorithms should impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. In other words, arbitrary bit boundaries such as 64 bits are arbitrary, and should not be imposed (or slowed) by routing and forwarding engines. It is submitted as a BCP, since it makes recommendations to implementers without updating or contravening any standard. Document Quality Originally discussed in 6man as draft-boucadair-6man-prefix-routing-reco, with three responsive revisions between June and September 2014. Revised again and submitted as draft-ietf-v6ops-cidr-prefix, with an additional revision. The document was discussed in 6man at IETF91, with several comments, and consensus that it was sensible as a recommendation, but not as a protocol update, and therefore more properly belonged in v6ops. It had been discussed on the 6man mailing list in October 2014, with about ten participants. There was some question about whether it was needed or useful, but after discussion objectors generally removed their objections. There was consensus that the recommendation is appropriate. Finally, discussion on v6ops list from December 2014 through February 2015 included a few additional participants. The document was refined into a clear BCP, with one objector worrying that requiring vendors to support any length might result in fewer possible routing table entries. Others did not share this concern. One commenter provided text updates, which were reflected in the final version. Overall, participants have been very clear in expressing their support or concerns. Personnel Shepherd: Lee Howard AD: Joel Jaeggli From nobody Thu Jun 4 07:53:50 2015 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 94EEC1A1ABC for ; Thu, 4 Jun 2015 07:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 YMdVAc_0TP3z for ; Thu, 4 Jun 2015 07:53:48 -0700 (PDT) Received: from tor-smtp-03.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id EC05A1A1AAD for ; Thu, 4 Jun 2015 07:53:47 -0700 (PDT) Received: from [24.114.92.221] (helo=[172.20.10.4]) by tor-smtp-03.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1Z0WWg-0005gT-Mz; Thu, 04 Jun 2015 10:53:47 -0400 From: Philip Matthews Content-Type: multipart/alternative; boundary=Apple-Mail-34--144109045 Date: Thu, 4 Jun 2015 10:53:44 -0400 Message-Id: To: v6ops list Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.92.221] Archived-At: Subject: [v6ops] Looking for info on IGP choices in production dual-stack 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, 04 Jun 2015 14:53:49 -0000 --Apple-Mail-34--144109045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Folks: Victor and I are looking for information on the IGP combinations people = are running in their dual-stack networks. We are gathering this = information so we can document in our Design Choices draft which IGP = choices are known to work well (i.e., people actually run this = combination in production networks without issues). The draft will not = name names, but just discuss things in aggregate: for example, "there = are 5 large production networks that run OSPF for IPv4 and IS-IS for = IPv6, thus that combination is judged to work well". =20 If you have a production dual-stack network, then we would like to know = which IGP you use to route IPv4 and which you use to route IPv6. We = would also like to know roughly how many routers are running this = combination. Feel free to share any successes or concerns with the = combination as well. =20 =20 We are looking particularly at combinations of the following IGPs: = IS-IS, OSPFv2, OSPFv3, EIGRP. If you run something else (RIP?) then we would also like to hear about = this, though we will likely document these differently. [We suspect you = run RIP/RIPng only at the edge for special situations, but feel free to = correct us]. And if you have one of those modern networks that carries dual-stack = customer traffic in a L3VPN or similar and thus don=92t need a = dual-stacked core, then please email us and brag ... Philip= --Apple-Mail-34--144109045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Victor and I are = looking for information on the IGP combinations people are running in = their dual-stack networks. We are gathering this information so we can = document in our Design Choices draft which IGP choices are known to work = well (i.e., people actually run this combination in production networks = without issues). The draft will not name names, but just discuss things = in aggregate: for example, "there are 5 large production networks that = run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to = work well".
Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack networks 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: Fri, 05 Jun 2015 02:54:40 -0000 ------=_Part_6562636_870794964.1433472844573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, From: Philip Matthews To: v6ops list =20 Sent: Friday, 5 June 2015, 0:53 Subject: [v6ops] Looking for info on IGP choices in production dual-stack = networks =20 Folks: Victor and I are looking for information on the IGP combinations people are= running in their dual-stack networks. We are gathering this information so= we can document in our Design Choices draft which IGP choices are known to= work well (i.e., people actually run this combination in production networ= ks without issues). The draft will not name names, but just discuss things = in aggregate: for example, "there are 5 large production networks that run = OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work w= ell".=C2=A0/ I don't think this is really a good thing to be stating in suc= h abstract terms, that is, at the IGP protocol level. I'd think the success= ful co-existence or not of IGPs, assuming the protocols themselves aren't b= roken (e.g., by using the same field value id for two different things), is= =C2=A0implementation dependent, and dependent on which specific revision o= f the implementation a network has chosen to deploy, and how that network h= as chosen to deploy it. For example, a literally perfect implementation of = OSPF + IS-IS might be "judged to work badly" if deployed badly (by, for exa= mple, putting too many routers in the backbone area, overloading control pl= ane resources.)=C2=A0 / I'm wondering a bit what the fundamental question trying to be being answ= ered is?=C2=A0Is it to try to capture some information on the current popul= arity of various IGPs used to carrying IPv6 routes, and how popular the use= of a single IGP to carry both IPv4 and IPv6 routes is? =C2=A0 What particu= lar question or questions would the reader have that this text is trying to= provide an answer for? / Regards,Mark. If you have a production dual-stack network, then we would like to know whi= ch IGP you use to route IPv4 and which you use to route IPv6.=C2=A0 We woul= d also like to know roughly how many routers are running this combination. = Feel free to share any successes or concerns with the combination as well. = =C2=A0=C2=A0We are looking particularly at combinations of the following IG= Ps:=C2=A0 IS-IS, OSPFv2, OSPFv3, EIGRP.If you run something else (RIP?) the= n we would also like to hear about this, though we will likely document the= se differently. [We suspect you run RIP/RIPng only at the edge for special = situations, but feel free to correct us]. And if you have one of those modern networks that carries dual-stack custom= er traffic in a L3VPN or similar and thus don=E2=80=99t need a dual-stacked= core, then please email us and brag ... Philip _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_6562636_870794964.1433472844573 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

From: Philip Ma= tthews <philip_matthews@magma.ca>
To: v6ops list <v6ops@ietf.org>
Sent: Friday, 5 June 2015, 0:53
<= span style=3D"font-weight: bold;">Subject: [v6ops] Looking for i= nfo on IGP choices in production dual-stack=09networks
<= div class=3D"y_msg_container" id=3D"yui_3_16_0_1_1433470360390_3462">
Folks:<= div id=3D"yui_3_16_0_1_1433470360390_3464">
Victor and I are looking for information on the IGP combinations peopl= e are running in their dual-stack networks. We are gathering this informati= on so we can document in our Design Choices draft which IGP choices are kno= wn to work well (i.e., people actually run this combination in production n= etworks without issues). The draft will not name names, but just discuss th= ings in aggregate: for example, "there are 5 large production networks that= run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to w= ork well".
 
/ I d= on't think this is really a good thing to be stating in such abstract terms= , that is, at the IGP protocol level. I'd think the successful co-existence= or not of IGPs, assuming the protocols themselves aren't broken (e.g., by = using the same field value id for two different things), is  implement= ation dependent, and dependent on which specific revision of the implementa= tion a network has chosen to deploy, and how that network has chosen to dep= loy it. For example, a literally perfect implementation of OSPF + IS-IS mig= ht be "judged to work badly" if deployed badly (by, for example, putting to= o many routers in the backbone area, overloading control plane resources.)<= span style=3D"font-size: 11pt;"> 

/ I'm wondering a bit what the fundamental question = trying to be being answered is? Is it to try to capture some information = on the current popularity of various IGPs used to carrying IPv6 routes, and= how popular the use of a single IGP to carry both IPv4 and IPv6 routes is?=   What particular question or questions would the reader have that th= is text is trying to provide an answer for?

/ Regards,
Mark.



If you have a production dual-stack network, then we would= like to know which IGP you use to route IPv4 and which you use to route IP= v6.  We would also like to know roughly how many routers are running t= his combination. Feel free to share any successes or concerns with the comb= ination as well.  
&n= bsp;
We are looking partic= ularly at combinations of the following IGPs:  IS-IS, OSPFv2, OSPFv3, = EIGRP.
If you run somethin= g else (RIP?) then we would also like to hear about this, though we will li= kely document these differently. [We suspect you run RIP/RIPng only at the = edge for special situations, but feel free to correct us].

And if you have one of those modern networks that carries dual-= stack customer traffic in a L3VPN or similar and thus don=E2=80=99t need a = dual-stacked core, then please email us and brag ...

Philip

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


------=_Part_6562636_870794964.1433472844573-- From nobody Fri Jun 5 07:27:48 2015 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 EC3DF1B301C for ; Fri, 5 Jun 2015 07:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9U_p5KeWdF11 for ; Fri, 5 Jun 2015 07:27:45 -0700 (PDT) Received: from tor-smtp-02.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6FA1B3018 for ; Fri, 5 Jun 2015 07:27:45 -0700 (PDT) Received: from [24.114.87.206] (helo=[172.20.10.4]) by tor-smtp-02.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1Z0sb2-00077p-Fe; Fri, 05 Jun 2015 10:27:44 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <817349377.6562637.1433472844577.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 5 Jun 2015 10:27:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <817349377.6562637.1433472844577.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.87.206] Archived-At: Cc: v6ops list Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack 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: Fri, 05 Jun 2015 14:27:47 -0000 [Reformatting and excerpting my original message and Mark's reply due = to some technical issues] On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote: >> Victor and I are looking for information on the IGP combinations = people are running in their dual-stack networks. We are gathering this = information so we can document in our Design Choices draft which IGP = choices are known to work well (i.e., people actually run this = combination in production networks without issues). The draft will not = name names, but just discuss things in aggregate: for example, "there = are 5 large production networks that run OSPF for IPv4 and IS-IS for = IPv6, thus that combination is judged to work well". >> =20 > I don't think this is really a good thing to be stating in such = abstract terms, that is, at the IGP protocol level. I'd think the = successful co-existence or not of IGPs, assuming the protocols = themselves aren't broken (e.g., by using the same field value id for two = different things), is implementation dependent, and dependent on which = specific revision of the implementation a network has chosen to deploy, = and how that network has chosen to deploy it. For example, a literally = perfect implementation of OSPF + IS-IS might be "judged to work badly" = if deployed badly (by, for example, putting too many routers in the = backbone area, overloading control plane resources.)=20 >=20 > I'm wondering a bit what the fundamental question trying to be being = answered is? Is it to try to capture some information on the current = popularity of various IGPs used to carrying IPv6 routes, and how popular = the use of a single IGP to carry both IPv4 and IPv6 routes is? What = particular question or questions would the reader have that this text is = trying to provide an answer for? >=20 > Regards, > Mark. In the draft we have a table that lists the various combinations of IGPs = for IPv4 and IPv6 and gives a few properties for each combination that = people might want to consider when selecting a combination. The idea is = to give people with less IPv6 knowledge some guidance and perhaps some = reassurance when selecting a combination.=20 One of the columns in the table is called "Known to work well". = Originally, Victor and I populated this based on our own experiences and = biases, without consulting others. However, in mid-April Mikael = Abrahamsson commented on this table, noting that he has actually run one = of the combinations that we marked as "not known to work well". So = Victor and I decided that we should be more scientific in populating = this column. Hence this survey of what people actually run. Do you think the draft should NOT contain this type of information? I = can say that I have found the responses so far to be very interesting, = even though it has been just a day so far. Or do you have a suggestion for something else useful to say about each = combination? Victor and I feel it might be nice to add more information = about each combination, but we don't have any ideas yet on what the = "more information" should be. We would love to hear from anyone who has = a suggestion. - Philip From nobody Fri Jun 5 16:11:11 2015 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 07C721A89A7 for ; Fri, 5 Jun 2015 16:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 4UYwA94oz3UN for ; Fri, 5 Jun 2015 16:11:08 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4FC1ABD3F for ; Fri, 5 Jun 2015 16:05:46 -0700 (PDT) Received: by wiga1 with SMTP id a1so34564630wig.0 for ; Fri, 05 Jun 2015 16:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6zrFtzSYTrX90iFvIbt+MByBNrbw/4zFWb4R8niplt0=; b=jEdqKR4PigRi0cE01D8D+vxZuP4EOT2eJl2nD2GHJLMA8w5o52rFXrYSuvEOCkkMLQ xxUosDnwi3KwE5WuWbElwSJ2pNwTzR1UwvrVYmdFpCmt2NOMotLlxvQ+1BEjoscMGc/X X33lerMScc+f7yyqDF0YEExmLmEJA+arnWixo= 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=6zrFtzSYTrX90iFvIbt+MByBNrbw/4zFWb4R8niplt0=; b=Wdsatxlv5uaHr2ivk1P8LZRplCmjaWzn21tBC10MdTMoO8dTxf2BlQRSt/grs12oCF gIKiyAfRVxpOFSyzsMpA96HmjvHF/mJ1/MV11b40ZgUonLxK9V1PJYaFJ23q4A1Zd71H s3JGXAWVAcC+M4XtdOH+s0cdtusZMaP2CPvO6EenXsEEcp5bGjttw+ghiwm6a+10R1mI 45uyEnqPRzMIzCkCDglcgyjcKvYV9Byk2WdOHgZid0enSxxpaaKZiwTxf6gPetkgiom7 VaBY7HXm/ocKj0HwYUdi4mnS4em/WCx4w7mgnMUdNt+0fTt9ZoA7kL49sUTa9H5T4Gox QrYQ== X-Gm-Message-State: ALoCoQkLo7dmGwSipcLmW/pf5Cv3oMLAG5k0z/ST5gXO9Z4dJrrAGiuk06QjvxH6r/Lpa3D8Lgjb MIME-Version: 1.0 X-Received: by 10.180.231.4 with SMTP id tc4mr912679wic.27.1433545545210; Fri, 05 Jun 2015 16:05:45 -0700 (PDT) Received: by 10.28.16.1 with HTTP; Fri, 5 Jun 2015 16:05:45 -0700 (PDT) In-Reply-To: <75D1048A-442C-4520-9E50-95D639741434@cisco.com> References: <20150604111717.12815.48132.idtracker@ietfa.amsl.com> <8C48B86A895913448548E6D15DA7553B06257AF5@xmb-rcd-x09.cisco.com> <20150605.173952.351754227.he@uninett.no> <730C5C1A-2409-47FC-976B-1DE4A533A6FE@cisco.com> <5571E4C2.7070303@si6networks.com> <75D1048A-442C-4520-9E50-95D639741434@cisco.com> Date: Fri, 5 Jun 2015 16:05:45 -0700 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a1134cc28fdec560517cd5433 Archived-At: Subject: Re: [v6ops] I-D Action: draft-baker-6man-hbh-header-handling-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, 05 Jun 2015 23:11:10 -0000 --001a1134cc28fdec560517cd5433 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 5, 2015 at 1:22 PM, Fred Baker (fred) wrote: > > > That's not a joking matter. > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > > definition is an absolute requirement of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > In Fred-speak, MUST means "if you don't do this, something will break", > and I like to say what will break. SHOULD means "I'd like to say 'MUST', > but I can think of a case in which it might be the wrong answer, or at > least can't prove to myself that it is never the wrong answer". When an > implementor decides to not do a SHOULD, I'd like to see their online > documentation say why they chose to not do it, and if not that, I'd like > them to be able to respond sensibly to the question. > Fred, you and I had this discussion verbally at some point, but I thought I would post it. I think your SHOULD can often be re-phrased better as MUST NOT. This is because when you'd like to say MUST, but you can't think of a case where it might be the wrong answer, or at least you can't prove that it's never the wrong answer, the thing you MUST do at that point is to figure out what in particular *can* break and expressly specify that it MUST NOT break. At IETF 92 in Dallas, I was amused to learn from a colleague that the unfortunate soul at UNH IOL tasked with translating RFC 6092 into a test plan had some rather colorful expressions for the trick I used in that document to prevent problems like this from arising. He said, "I've never seen an RFC with so many g*dd*mn MUST NOT keywords in my entire life." (To which my reply was: yep, ain't I a stinker? I know what it's like to be on the implementer side of this stuff, and I know all the tricks.) In the real world, product engineers routinely consider SHOULD as equivalent to OPTIONAL. That's why it's good to raise as many things to the level of MUST or MUST NOT as possible in specifications. Everything else can and will be ignored when the clock is ticking and the sharp knives come out. -- james woodyatt Nest Labs, Communications Engineering --001a1134cc28fdec560517cd5433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 5, 2015 at 1:22 PM, Fred Baker (fred) <fred@cisco.com> = wrote:

That's not a joking matter.

> 1. MUST=C2=A0 =C2=A0This word, or the terms "REQUIRED" or &q= uot;SHALL", mean that the
>=C2=A0 =C2=A0 definition is an absolute requirement of the specificatio= n.
>
> 3. SHOULD=C2=A0 =C2=A0This word, or the adjective "RECOMMENDED&qu= ot;, mean that there
>=C2=A0 =C2=A0 may exist valid reasons in particular circumstances to ig= nore a
>=C2=A0 =C2=A0 particular item, but the full implications must be unders= tood and
>=C2=A0 =C2=A0 carefully weighed before choosing a different course.

In Fred-speak, MUST means "if you don't do this, something will br= eak", and I like to say what will break. SHOULD means "I'd li= ke to say 'MUST', but I can think of a case in which it might be th= e wrong answer, or at least can't prove to myself that it is never the = wrong answer". When an implementor decides to not do a SHOULD, I'd= like to see their online documentation say why they chose to not do it, an= d if not that, I'd like them to be able to respond sensibly to the ques= tion.

Fred, you and I had this discussion verbally at some point= , but I thought I would post it. I think your SHOULD can often be re-phrase= d better as MUST NOT. This is because when you'd like to say MUST, but = you can't think of a case where it might be the wrong answer, or at lea= st you can't prove that it's never the wrong answer, the thing you = MUST do at that point is to figure out what in particular *can* break and e= xpressly specify that it MUST NOT break.

At IETF 92 in Dallas, I w= as amused to learn from a colleague that the unfortunate soul at UNH IOL ta= sked with translating RFC 6092 into a test plan had some rather colorful ex= pressions for the trick I used in that document to prevent problems like th= is from arising. He said, "I've never seen an RFC with so many g*d= d*mn MUST NOT keywords in my entire life." (To which my reply was: yep= , ain't I a stinker? I know what it's like to be on the implementer= side of this stuff, and I know all the tricks.)

In the real world, product engin= eers routinely consider SHOULD as equivalent to OPTIONAL. That's why it= 's good to raise as many things to the level of MUST or MUST NOT as pos= sible in specifications. Everything else can and will be ignored when the c= lock is ticking and the sharp knives come out.


--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineer= ing
--001a1134cc28fdec560517cd5433-- From nobody Sat Jun 6 00:18:00 2015 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 84A501AD35E for ; Sat, 6 Jun 2015 00:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.802 X-Spam-Level: *** X-Spam-Status: No, score=3.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 bVzC_6FnJZ_t for ; Sat, 6 Jun 2015 00:17:56 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D461AD35D for ; Sat, 6 Jun 2015 00:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1433575075; bh=RqGLY27LaaaznInpEkVviGEqrRNx42QQupUgLn7gHZM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=pXy4cIZ0kv3jlyC9RlvtpYNEPvUT16VR6Bwkv/qjOSOgH/XKZiFL5WOsfnmzQbBFEh+0UhWtjBknyz0i2hhfa9DqPz97z0wVECO3uxGjfvzRfPr08sTG6l5c0Hlbmj6a3meqfECZwkpPSB+DhTcTRjQbJwTmPBpMkB3U7fWgbTPJHA+GFUKZ3cP+sbOyClV2sVVeYQRU+4/el27Up45ub0bNO9MUv3bdlkMZ6waeWVjTzZtCZahSTg85xNTpoMR+P5CjlXIOrww4veC8kppQlJSzN4OEwSoJvQ1uMucJ1pxAalP5Zn3VKh68X3IWxflZlAkYMXbaSxjOX3jSWIjxhg== Received: from [98.139.170.181] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jun 2015 07:17:55 -0000 Received: from [98.139.212.215] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jun 2015 07:17:55 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 06 Jun 2015 07:17:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 294364.67595.bm@omp1024.mail.bf1.yahoo.com X-YMail-OSG: vMDdLMAVM1mKXrzvPi05YHlKHX7YE4KHx6ayjZWhR3If4hUlgmL.dpRVFodJVc. P.9ee.PnaFZtEAHGthF729iDtedLiRZx_KRfEFUT9r9wj7jPK5.VN9e8VNSQU3cGvxTW4kQHKjqe 0G4zNa71kxpFFYZFekykTZSZ6Q6xfiUFkXKLz8ri1UW5jyMwmoolXTrElQ8Rdti9kccFShBFUkKg .L2eo0Gbw1.Xz5Mo6eShX.qgzFstXRnm3Vkmg8AeitBEbxbHBqanXjL1wpFrQ1Utdm7iK.s_XyQ7 0IvIjCYQelHyy1zmnqgx8hndj37BQZcme2xJqCeS4MDMdpPTx7lYVsrCegGMIok_Uwyfkf5Fl776 nct90szBEDmePLptceqommBh1WQCoDKDBBd.ML_uBSp9Of5d0gnjd0npKM69VCqQQ5LYLaeZwzx2 fi1JRT2Mc4dMoWHahVq7FmqMJdZ3uCZ.dYqAzh7BkFLxZ7Ou.Wt9TsLKyKRwidMmDeN9GrCKAiT7 bqmxfx5WcLrckQdFyGA-- Received: by 76.13.27.197; Sat, 06 Jun 2015 07:17:54 +0000 Date: Sat, 6 Jun 2015 07:17:41 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews Message-ID: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7129827_990964408.1433575061184" Archived-At: Cc: v6ops list Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack networks 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: Sat, 06 Jun 2015 07:17:58 -0000 ------=_Part_7129827_990964408.1433575061184 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Philip, So I've spent more than the last 2 hours writing many abandoned emailed res= ponses, if the below sounds a bit short, it's only because I want to send s= omething to get some thoughts out there for consideration! From: Philip Matthews To: Mark ZZZ Smith =20 Cc: v6ops list =20 Sent: Saturday, 6 June 2015, 0:27 Subject: Re: [v6ops] Looking for info on IGP choices in production dual-st= ack networks =20 [Reformatting and excerpting my original message and Mark's reply=C2=A0 due= to some technical issues] On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote: >> Victor and I are looking for information on the IGP combinations people = are running in their dual-stack networks. We are gathering this information= so we can document in our Design Choices draft which IGP choices are known= to work well (i.e., people actually run this combination in production net= works without issues). The draft will not name names, but just discuss thin= gs in aggregate: for example, "there are 5 large production networks that r= un OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to wor= k well". >>=C2=A0=20 > I don't think this is really a good thing to be stating in such abstract = terms, that is, at the IGP protocol level. I'd think the successful co-exis= tence or not of IGPs, assuming the protocols themselves aren't broken (e.g.= , by using the same field value id for two different things), is=C2=A0 impl= ementation dependent, and dependent on which specific revision of the imple= mentation a network has chosen to deploy, and how that network has chosen t= o deploy it. For example, a literally perfect implementation of OSPF + IS-I= S might be "judged to work badly" if deployed badly (by, for example, putti= ng too many routers in the backbone area, overloading control plane resourc= es.)=20 >=20 > I'm wondering a bit what the fundamental question trying to be being answ= ered is? Is it to try to capture some information on the current popularity= of various IGPs used to carrying IPv6 routes, and how popular the use of a= single IGP to carry both IPv4 and IPv6 routes is?=C2=A0 What particular qu= estion or questions would the reader have that this text is trying to provi= de an answer for? >=20 > Regards, > Mark. In the draft we have a table that lists the various combinations of IGPs fo= r IPv4 and IPv6 and gives a few properties for each combination that people= might want to consider when selecting a combination. The idea is to give p= eople with less IPv6 knowledge some guidance and perhaps some reassurance w= hen selecting a combination.=20 One of the columns in the table is called "Known to work well". / I think my main issue is with this column. I think it is asserting that, = for example, all implementations of the combination of OSPFv2 for IPv4 and = IS-IS for IPv6 are "Known to work well". So if you pick a combination with = a "Y" in this column, you'll have no issues regardless of your OSPF and IS-= IS implementation choice, or what deployment model you choose (single or mu= ltiple area, number of routers in an area/level etc.) =C2=A0 Originally, Victor and I populated this based on our own experiences= and biases, without consulting others.=C2=A0 However, in mid-April Mikael = Abrahamsson commented on this table, noting that he has actually run one of= the combinations that we marked as "not known to work well".=C2=A0 So Vict= or and I decided that we should be more scientific in populating this colum= n.=C2=A0 Hence this survey of what people actually run. / Rhetorically, for the combination that Mikael has reported, are you going= to put "Yes and No" in the "Known to Work Well" column? Or does Mikael's e= vidence cancel out that evidence that Victor and yourself have? Do you think the draft should NOT contain this type of information?=C2=A0 I= can say that I have found the responses so far to be very interesting, eve= n though it has been just a day so far. / I'm struggling with what criteria should or should not be there, and I th= ink it depends on answers to the following questions: / - are you comparing IGP protocols or experience with IGP protocol impleme= ntations? / I think it is mixing together comparisons of both, but then it is attribu= ting all of those characteristics to the protocols, rather than to either t= he protocols or implementations of the protocols (e.g., "Known to work well= " is certainly a protocol implementation characteristic, and is implementat= ion specific (as Mikael Abrahamsson's contrary evidence shows) ) / The results of comparison of protocols will remain the same unless the pr= otocols change, which doesn't occur often. The results of comparison of imp= lementations of those protocols (e.g., "Known to work well") can change tom= orrow with a firmware update. / - what level of knowledge of IGPs and IGP selection considerations does t= he audience have? / By not including a number of important IGP selection criteria that need t= o be considered (e.g., available control plane resources, addressing aggreg= ation boundaries, vendor implementation maturity etc.), it implies that the= audience should already have an understanding of the all of the criteria f= or IGP selection. / Yet the inclusion of the "Known to work well" information, without any im= plementation or deployment detail, seems to be implying that the choice can= be so simple that if you don't know what to select, just select one of the= protocol combinations with a "Y" in that column. Given how critical an IGP= is to the reliable operation of a network, "staying ignorant" of IGP imple= mentation details such as maturity, capacity limitations etc. is dangerous. / Regards,Mark. Or do you have a suggestion for something else useful to say about each com= bination?=C2=A0 Victor and I feel it might be nice to add more information = about each combination, but we don't have any ideas yet on what the "more i= nformation" should be.=C2=A0 We would love to hear from anyone who has a su= ggestion. - Philip ------=_Part_7129827_990964408.1433575061184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Philip,

So I've = spent more than the last 2 hours writing many abandoned emailed responses, = if the below sounds a bit short, it's only because I want to send something= to get some thoughts out there for consideration!


From: Philip Matthews <philip_matthews= @magma.ca>
To: Mark= ZZZ Smith <markzzzsmith@yahoo.com.au>
Cc: v6ops list <v6ops@ietf.org>
Sent: Saturday, 6 June 2015, 0:27 Subject: Re: [v6ops] Lo= oking for info on IGP choices in production dual-stack=09networks

[Reformatting and excerpting my original message and Mark's reply=   due to some technical issues]

O= n 2015-06-04, at 22:54 , Mark ZZZ Smith wrote:
>> V= ictor and I are looking for information on the IGP combinations people are = running in their dual-stack networks. We are gathering this information so = we can document in our Design Choices draft which IGP choices are known to = work well (i.e., people actually run this combination in production network= s without issues). The draft will not name names, but just discuss things i= n aggregate: for example, "there are 5 large production networks that run O= SPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work we= ll".
>> 
> I don't think= this is really a good thing to be stating in such abstract terms, that is,= at the IGP protocol level. I'd think the successful co-existence or not of= IGPs, assuming the protocols themselves aren't broken (e.g., by using the = same field value id for two different things), is  implementation depe= ndent, and dependent on which specific revision of the implementation a net= work has chosen to deploy, and how that network has chosen to deploy it. Fo= r example, a literally perfect implementation of OSPF + IS-IS might be "jud= ged to work badly" if deployed badly (by, for example, putting too many rou= ters in the backbone area, overloading control plane resources.)
>
> I'm wondering a bit what the fundame= ntal question trying to be being answered is? Is it to try to capture some = information on the current popularity of various IGPs used to carrying IPv6= routes, and how popular the use of a single IGP to carry both IPv4 and IPv= 6 routes is?  What particular question or questions would the reader = have that this text is trying to provide an answer for?
&= gt;
> Regards,
> Mark.

In the draft we have a table that lists the va= rious combinations of IGPs for IPv4 and IPv6 and gives a few properties for= each combination that people might want to consider when selecting a combi= nation. The idea is to give people with less IPv6 knowledge some guidance a= nd perhaps some reassurance when selecting a combination.

One of the columns in the table is called "Known to wo= rk well".

/ I think my main issue is with this column. I= think it is asserting that, for example, all implementations of the combin= ation of OSPFv2 for IPv4 and IS-IS for IPv6 are "Known to work well". So if= you pick a combination with a "Y" in this column, you'll have no issues re= gardless of your OSPF and IS-IS implementation choice, or what deployment m= odel you choose (single or multiple area, number of routers in an area/leve= l etc.)

  Originally, Victor and I populated this based on our = own experiences and biases, without consulting others.  However, in mi= d-April Mikael Abrahamsson commented on this table, noting that he has actu= ally run one of the combinations that we marked as "not known to work well"= .  So Victor and I decided that we should be more scientific in popula= ting this column.  Hence this survey of what people actually run.
/ Rhetorically, for the combination that Mikael has reported= , are you going to put "Yes and No" in the "Known to Work Well" column? Or = does Mikael's evidence cancel out that evidence that Victor and yourself ha= ve?

Do you think the draft should NOT = contain this type of information?  I can say that I have found the res= ponses so far to be very interesting, even though it has been just a day so= far.

/ I'm struggling with what criteria should or s= hould not be there, and I think it depends on answers to the following ques= tions:

/ - are you comparing IGP protocols or experience= with IGP protocol implementations?

/ I thi= nk it is mixing together comparisons of both, but then it is attributing al= l of those characteristics to the protocols, rather than to either the prot= ocols or implementations of the protocols (e.g., "Known to work well" is ce= rtainly a protocol implementation characteristic, and is implementation spe= cific (as Mikael Abrahamsson's contrary evidence shows) )
/ The results of comparison of protocols will remain the sa= me unless the protocols change, which doesn't occur often. The results of c= omparison of implementations of those protocols (e.g., "Known to work well"= ) can change tomorrow with a firmware update.

/ - what level of knowledge of IGPs and IGP selection considerations = does the audience have?

/ By not includi= ng a number of important IGP selection criteria that need to be considered = (e.g., available control plane resources, addressing aggregation boundaries= , vendor implementation maturity etc.), it implies that the audience should= already have an understanding of the all of the criteria for IGP selection= .

/ Yet the inclusion of the "Known to work = well" information, without any implementation or deployment detail, seems t= o be implying that the choice can be so simple that if you don't know what = to select, just select one of the protocol combinations with a "Y" in that = column. Given how critical an IGP is to the reliable operation of a network= , "staying ignorant" of IGP implementation details such as maturity, capaci= ty limitations etc. is dangerous.

/ Regards,=
Mark.


Or do = you have a suggestion for something else useful to say about each combinati= on?  Victor and I feel it might be nice to add more information about = each combination, but we don't have any ideas yet on what the "more informa= tion" should be.  We would love to hear from anyone who has a suggesti= on.



=
- Philip



------=_Part_7129827_990964408.1433575061184-- From nobody Sun Jun 7 08:21:09 2015 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 A07971A90FB for ; Sun, 7 Jun 2015 08:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 9TK2OFHXOr5p for ; Sun, 7 Jun 2015 08:21:03 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6576C1A90FA for ; Sun, 7 Jun 2015 08:21:02 -0700 (PDT) Received: from [192.168.1.86] (dusted.otenet.gr [195.167.126.245]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 40F1D138046; Sun, 7 Jun 2015 18:20:58 +0300 (EEST) Message-ID: <55746159.2080607@otenet.gr> Date: Sun, 07 Jun 2015 18:20:57 +0300 From: Yannis Nikolopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Philip Matthews References: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------060605080805000601090608" Archived-At: Cc: v6ops list Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack 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: Sun, 07 Jun 2015 15:21:07 -0000 This is a multi-part message in MIME format. --------------060605080805000601090608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Mark, Philip (as an operator with a dual stack network in place) when I first read through the draft I found it useful, especially for operators just starting out with IPv6. Please find some comments inline On 06/06/2015 10:17 AM, Mark ZZZ Smith wrote: > Hi Philip, > > So I've spent more than the last 2 hours writing many abandoned > emailed responses, if the below sounds a bit short, it's only because > I want to send something to get some thoughts out there for consideration! > > > *From:* Philip Matthews > *To:* Mark ZZZ Smith > *Cc:* v6ops list > *Sent:* Saturday, 6 June 2015, 0:27 > *Subject:* Re: [v6ops] Looking for info on IGP choices in production > dual-stack networks > > [Reformatting and excerpting my original message and Mark's reply due > to some technical issues] > > On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote: > >> Victor and I are looking for information on the IGP combinations > people are running in their dual-stack networks. We are gathering this > information so we can document in our Design Choices draft which IGP > choices are known to work well (i.e., people actually run this > combination in production networks without issues). The draft will not > name names, but just discuss things in aggregate: for example, "there > are 5 large production networks that run OSPF for IPv4 and IS-IS for > IPv6, thus that combination is judged to work well". > >> > > I don't think this is really a good thing to be stating in such > abstract terms, that is, at the IGP protocol level. I'd think the > successful co-existence or not of IGPs, assuming the protocols > themselves aren't broken (e.g., by using the same field value id for > two different things), is implementation dependent, and dependent on > which specific revision of the implementation a network has chosen to > deploy, and how that network has chosen to deploy it. For example, a > literally perfect implementation of OSPF + IS-IS might be "judged to > work badly" if deployed badly (by, for example, putting too many > routers in the backbone area, overloading control plane resources.) > > > > I'm wondering a bit what the fundamental question trying to be being > answered is? Is it to try to capture some information on the current > popularity of various IGPs used to carrying IPv6 routes, and how > popular the use of a single IGP to carry both IPv4 and IPv6 routes > is? What particular question or questions would the reader have that > this text is trying to provide an answer for? > > > > Regards, > > Mark. > > In the draft we have a table that lists the various combinations of > IGPs for IPv4 and IPv6 and gives a few properties for each combination > that people might want to consider when selecting a combination. The > idea is to give people with less IPv6 knowledge some guidance and > perhaps some reassurance when selecting a combination. > > One of the columns in the table is called "Known to work well". > > / I think my main issue is with this column. I think it is asserting > that, for example, all implementations of the combination of OSPFv2 > for IPv4 and IS-IS for IPv6 are "Known to work well". So if you pick a > combination with a "Y" in this column, you'll have no issues > regardless of your OSPF and IS-IS implementation choice, or what > deployment model you choose (single or multiple area, number of > routers in an area/level etc.) > > Originally, Victor and I populated this based on our own experiences > and biases, without consulting others. However, in mid-April Mikael > Abrahamsson commented on this table, noting that he has actually run > one of the combinations that we marked as "not known to work well". > So Victor and I decided that we should be more scientific in > populating this column. Hence this survey of what people actually run. > > / Rhetorically, for the combination that Mikael has reported, are you > going to put "Yes and No" in the "Known to Work Well" column? Or does > Mikael's evidence cancel out that evidence that Victor and yourself have? > > Do you think the draft should NOT contain this type of information? I > can say that I have found the responses so far to be very interesting, > even though it has been just a day so far. > > / I'm struggling with what criteria should or should not be there, and > I think it depends on answers to the following questions: > > / - are you comparing IGP protocols or experience with IGP protocol > implementations? > In my mind, it's about IGP implementations, not IGPs > / I think it is mixing together comparisons of both, but then it is > attributing all of those characteristics to the protocols, rather than > to either the protocols or implementations of the protocols (e.g., > "Known to work well" is certainly a protocol implementation > characteristic, and is implementation specific (as Mikael > Abrahamsson's contrary evidence shows) ) > > / The results of comparison of protocols will remain the same unless > the protocols change, which doesn't occur often. The results of > comparison of implementations of those protocols (e.g., "Known to work > well") can change tomorrow with a firmware update. > In our case, we've been running the IPv4/OSPFv2 - IPv6/IS-IS combination for quite a few years now so a firmware update or something along those lines, would not really affect the overall "experience" > / - what level of knowledge of IGPs and IGP selection considerations > does the audience have? > supposedly, the audience is network operators, so a certain degree of knowledge should be considered a given. > / By not including a number of important IGP selection criteria that > need to be considered (e.g., available control plane resources, > addressing aggregation boundaries, vendor implementation maturity > etc.), it implies that the audience should already have an > understanding of the all of the criteria for IGP selection. > well, yes they should. This document's intended audience is operators who are starting out with IPv6, not people starting out with IP networks in general. > / Yet the inclusion of the "Known to work well" information, without > any implementation or deployment detail, seems to be implying that the > choice can be so simple that if you don't know what to select, just > select one of the protocol combinations with a "Y" in that column. > Given how critical an IGP is to the reliable operation of a network, > "staying ignorant" of IGP implementation details such as maturity, > capacity limitations etc. is dangerous. The choice is not so simple, you're right. It shouldn't come down to looking up a table in an Internet draft. I believe that the "IGP Choice" table could also be quite useful as it is, even if "Known to work well" column can be a bit ambiguous and/or inadequate on its own as as selection criterion. That's why it would help if the section is enriched with comments and notes about said implementation choices. regards, Yannis > > / Regards, > Mark. > > > Or do you have a suggestion for something else useful to say about > each combination? Victor and I feel it might be nice to add more > information about each combination, but we don't have any ideas yet on > what the "more information" should be. We would love to hear from > anyone who has a suggestion. > > > > > - Philip > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- --------------060605080805000601090608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hello Mark, Philip

(as an operator with a dual stack network in place) when I first read through the draft I found it useful, especially for operators just starting out with IPv6. Please find some comments inline

On 06/06/2015 10:17 AM, Mark ZZZ Smith wrote:
Hi Philip,

So I've spent more than the last 2 hours writing many abandoned emailed responses, if the below sounds a bit short, it's only because I want to send something to get some thoughts out there for consideration!


From: Philip Matthews <philip_matthews@magma.ca>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Cc: v6ops list <v6ops@ietf.org>
Sent: Saturday, 6 June 2015, 0:27
Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack networks

[Reformatting and excerpting my original message and Mark's reply  due to some technical issues]

On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote:
>> Victor and I are looking for information on the IGP combinations people are running in their dual-stack networks. We are gathering this information so we can document in our Design Choices draft which IGP choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft will not name names, but just discuss things in aggregate: for example, "there are 5 large production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work well".
>> 
> I don't think this is really a good thing to be stating in such abstract terms, that is, at the IGP protocol level. I'd think the successful co-existence or not of IGPs, assuming the protocols themselves aren't broken (e.g., by using the same field value id for two different things), is  implementation dependent, and dependent on which specific revision of the implementation a network has chosen to deploy, and how that network has chosen to deploy it. For example, a literally perfect implementation of OSPF + IS-IS might be "judged to work badly" if deployed badly (by, for example, putting too many routers in the backbone area, overloading control plane resources.)
>
> I'm wondering a bit what the fundamental question trying to be being answered is? Is it to try to capture some information on the current popularity of various IGPs used to carrying IPv6 routes, and how popular the use of a single IGP to carry both IPv4 and IPv6 routes is?  What particular question or questions would the reader have that this text is trying to provide an answer for?
>
> Regards,
> Mark.

In the draft we have a table that lists the various combinations of IGPs for IPv4 and IPv6 and gives a few properties for each combination that people might want to consider when selecting a combination. The idea is to give people with less IPv6 knowledge some guidance and perhaps some reassurance when selecting a combination.

One of the columns in the table is called "Known to work well".

/ I think my main issue is with this column. I think it is asserting that, for example, all implementations of the combination of OSPFv2 for IPv4 and IS-IS for IPv6 are "Known to work well". So if you pick a combination with a "Y" in this column, you'll have no issues regardless of your OSPF and IS-IS implementation choice, or what deployment model you choose (single or multiple area, number of routers in an area/level etc.)

  Originally, Victor and I populated this based on our own experiences and biases, without consulting others.  However, in mid-April Mikael Abrahamsson commented on this table, noting that he has actually run one of the combinations that we marked as "not known to work well".  So Victor and I decided that we should be more scientific in populating this column.  Hence this survey of what people actually run.

/ Rhetorically, for the combination that Mikael has reported, are you going to put "Yes and No" in the "Known to Work Well" column? Or does Mikael's evidence cancel out that evidence that Victor and yourself have?

Do you think the draft should NOT contain this type of information?  I can say that I have found the responses so far to be very interesting, even though it has been just a day so far.

/ I'm struggling with what criteria should or should not be there, and I think it depends on answers to the following questions:

/ - are you comparing IGP protocols or experience with IGP protocol implementations?


In my mind, it's about IGP implementations, not IGPs

/ I think it is mixing together comparisons of both, but then it is attributing all of those characteristics to the protocols, rather than to either the protocols or implementations of the protocols (e.g., "Known to work well" is certainly a protocol implementation characteristic, and is implementation specific (as Mikael Abrahamsson's contrary evidence shows) )

/ The results of comparison of protocols will remain the same unless the protocols change, which doesn't occur often. The results of comparison of implementations of those protocols (e.g., "Known to work well") can change tomorrow with a firmware update.


In our case, we've been running the IPv4/OSPFv2 - IPv6/IS-IS combination for quite a few years now so a firmware update or something along those lines, would not really affect the overall "experience"

/ - what level of knowledge of IGPs and IGP selection considerations does the audience have?


supposedly, the audience is network operators, so a certain degree of knowledge should be considered a given.

/ By not including a number of important IGP selection criteria that need to be considered (e.g., available control plane resources, addressing aggregation boundaries, vendor implementation maturity etc.), it implies that the audience should already have an understanding of the all of the criteria for IGP selection.


well, yes they should. This document's intended audience is operators who are starting out with IPv6, not people starting out with IP networks in general.

/ Yet the inclusion of the "Known to work well" information, without any implementation or deployment detail, seems to be implying that the choice can be so simple that if you don't know what to select, just select one of the protocol combinations with a "Y" in that column. Given how critical an IGP is to the reliable operation of a network, "staying ignorant" of IGP implementation details such as maturity, capacity limitations etc. is dangerous.

The choice is not so simple, you're right. It shouldn't come down to looking up a table in an Internet draft. I believe that the "IGP Choice" table could also be quite useful as it is, even if "Known to work well" column can be a bit ambiguous and/or inadequate on its own as as selection criterion. That's why it would help if the section is enriched with comments and notes about said implementation choices.

regards,
Yannis


/ Regards,
Mark.


Or do you have a suggestion for something else useful to say about each combination?  Victor and I feel it might be nice to add more information about each combination, but we don't have any ideas yet on what the "more information" should be.  We would love to hear from anyone who has a suggestion.




- Philip





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



--
--------------060605080805000601090608-- From nobody Sun Jun 7 11:00:09 2015 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 E4EAA1ACCE3 for ; Sun, 7 Jun 2015 11:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.311 X-Spam-Level: X-Spam-Status: No, score=-110.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IXHASH_X1=1.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 K43Qo8IJvvvF for ; Sun, 7 Jun 2015 11:00:04 -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 5D7201ACCE2 for ; Sun, 7 Jun 2015 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1433700004; x=1434909604; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=TtSCflV+Lt4VbORzyjlbnvpIZvXfiu29PwUPFHVhqE0GmiZbby/B0ItH cPIWBsfCTt6HJETrzxZt369zTMrmLonj4+G5K5dzfILyOPyp0k54KdqNk 9MYLKbGdkMeI7q6WBvfdPel2cm+OwFmI7RGCWsEwbhGpyEim6l9SJ0iRu o=; X-IronPort-AV: E=Sophos;i="5.13,569,1427760000"; d="scan'208";a="422921126" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 07 Jun 2015 18:00:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t57I03Oa006848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jun 2015 18:00:03 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 t57I026h017176; Sun, 7 Jun 2015 11:00:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t57I02Dr017134; Sun, 7 Jun 2015 11:00:02 -0700 Date: Sun, 7 Jun 2015 11:00:02 -0700 From: fred@cisco.com Message-Id: <201506071800.t57I02Dr017134@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem 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, 07 Jun 2015 18:00:06 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From nobody Sun Jun 7 12:02:49 2015 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 58C4A1ACD21 for ; Sun, 7 Jun 2015 12:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] 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 ZEyk3e7_bgmg for ; Sun, 7 Jun 2015 12:02:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73181ACD1D for ; Sun, 7 Jun 2015 12:02:45 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:50ab:1f6e:8382:85ed]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t57J2g1A030178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 7 Jun 2015 19:02:43 GMT (envelope-from joelja@bogus.com) To: Brian E Carpenter , v6ops@ietf.org References: <201505311800.t4VI02Cf026378@irp-lnx1.cisco.com> <556B9D1D.802@gmail.com> From: joel jaeggli Message-ID: <55749551.4080801@bogus.com> Date: Sun, 7 Jun 2015 12:02:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <556B9D1D.802@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oe458eOUXiKkLuW3viLhGRholo6MDJXB1" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem 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, 07 Jun 2015 19:02:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oe458eOUXiKkLuW3viLhGRholo6MDJXB1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/15 4:45 PM, Brian E Carpenter wrote: > Hi, >=20 > Generally I think this is useful and almost ready. >=20 >> 3.1. Alternatives >> >> As an alternative, it may be appropriate to lower the TCP MSS to 12= 20 >> in order to accommodate 1280 byte MTU. We consider this undesirabl= e >> as hosts may not be able to independently set TCP MSS by address- >> family thereby impacting IPv4, or alternatively that it relies on a= >> middle-box to clamp the MSS independently from the end-systems. >=20 > The "that" in the second sentence doesn't parse. I don't understand > what the draft is trying to say about MSS clamping. Is this better? or alternatively that middle-boxes need to be employed to clamp the MSS independently from the end-systems. > Also, shouldn't we say "undesirable but possibly necessary in some > cases"? A server at the mercy of an ISP might *need* to apply MSS clamp= ing. since we are dealing with alternative mitigations we are justifying why we don't like them, I thin they can be employed. > Nit: >=20 > It's confusing to have these two sections with identical titles: >=20 >> 3.1. Alternatives >> 3.2.1. Alternatives >=20 > Maybe 3.1 should be "MSS-based Alternatives" > and 3.2.1 "Distributed Proxy Alternatives" nice. thanks > Brian > On 01/06/2015 06:00, fred@cisco.com wrote: >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem. =20 >> 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. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --oe458eOUXiKkLuW3viLhGRholo6MDJXB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlV0lVEACgkQ8AA1q7Z/VrJ0LQCdF/gi/imM63BlRgqsU0+bfVxu +5MAn3D0g+/XssFZijoTYnQm3B+wjayM =klTS -----END PGP SIGNATURE----- --oe458eOUXiKkLuW3viLhGRholo6MDJXB1-- From nobody Sun Jun 7 13:10:55 2015 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 B2CBE1ACD8B for ; Sun, 7 Jun 2015 13:10:54 -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 2V3DZCb3WiAy for ; Sun, 7 Jun 2015 13:10:53 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A42D1ACD8C for ; Sun, 7 Jun 2015 13:10:53 -0700 (PDT) Received: by payr10 with SMTP id r10so82006408pay.1 for ; Sun, 07 Jun 2015 13:10:52 -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=9lAQSYcA7eN8bEWq0/VR/ljGp2mpzq77RJuZm+OSNl0=; b=pq1nLLXLt/evXCypMyD8scgruyvfUoGkE76BppXZQszErTUaYiqrCS6T2VK77Y9l/m UE8HdqlILsNyGLzZz5vsFduZ8Y3DJ1KInHffkG/c5l5LSoR5FhMpU0QcgDYTFOq5WrV3 XddCakbnwlC0PxWmX9R4DR+6Pmh3yAgjIEbh3vCSzhcOvQawclv/HctHa5oU7njfY5X5 4fOcBMTyksYZNhLKlZrJ0de60L19q6XOgLIhwoNEYMHgewf0Ceu6ekkH6aIiRmpxckKR nYmFexvPAUd9x+2+MtAAsVpdMcmLb8vQ2vQCZAjds5sAhlDeaiZzpYs10/E084W6wYBJ NOQg== X-Received: by 10.66.249.168 with SMTP id yv8mr23933337pac.49.1433707852662; Sun, 07 Jun 2015 13:10:52 -0700 (PDT) Received: from ?IPv6:2406:e007:5614:1:28cc:dc4c:9703:6781? ([2406:e007:5614:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id om4sm372384pdb.68.2015.06.07.13.10.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2015 13:10:51 -0700 (PDT) Message-ID: <5574A546.1030007@gmail.com> Date: Mon, 08 Jun 2015 08:10:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: joel jaeggli References: <201505311800.t4VI02Cf026378@irp-lnx1.cisco.com> <556B9D1D.802@gmail.com> <55749551.4080801@bogus.com> In-Reply-To: <55749551.4080801@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem 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, 07 Jun 2015 20:10:54 -0000 On 08/06/2015 07:02, joel jaeggli wrote: > On 5/31/15 4:45 PM, Brian E Carpenter wrote: >> Hi, >> >> Generally I think this is useful and almost ready. >> >>> 3.1. Alternatives >>> >>> As an alternative, it may be appropriate to lower the TCP MSS to 1220 >>> in order to accommodate 1280 byte MTU. We consider this undesirable >>> as hosts may not be able to independently set TCP MSS by address- >>> family thereby impacting IPv4, or alternatively that it relies on a >>> middle-box to clamp the MSS independently from the end-systems. >> >> The "that" in the second sentence doesn't parse. I don't understand >> what the draft is trying to say about MSS clamping. > > Is this better? > > or alternatively that middle-boxes need to be employed to clamp the MSS > independently from the end-systems. That's fine. Brian > >> Also, shouldn't we say "undesirable but possibly necessary in some >> cases"? A server at the mercy of an ISP might *need* to apply MSS clamping. > > since we are dealing with alternative mitigations we are justifying why > we don't like them, I thin they can be employed. > >> Nit: >> >> It's confusing to have these two sections with identical titles: >> >>> 3.1. Alternatives >>> 3.2.1. Alternatives >> >> Maybe 3.1 should be "MSS-based Alternatives" >> and 3.2.1 "Distributed Proxy Alternatives" > > nice. > > thanks > >> Brian >> On 01/06/2015 06:00, fred@cisco.com wrote: >>> This is to initiate a two week working group last call of >>> http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem. >>> 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. >>> >>> _______________________________________________ >>> 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 Sun Jun 7 14:00:46 2015 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 B2DC61ACE31 for ; Sun, 7 Jun 2015 14:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 Gg4FysVUa3-0 for ; Sun, 7 Jun 2015 14:00:41 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1DB1ACDBF for ; Sun, 7 Jun 2015 14:00:40 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 18A7C102099 for ; Sun, 7 Jun 2015 16:00:40 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 566C4136BC5; Sun, 7 Jun 2015 16:00:39 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 8F3962F6740; Sun, 7 Jun 2015 16:55:13 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 842F32F6690; Sun, 7 Jun 2015 16:55:13 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([::1]) with mapi id 14.01.0438.000; Sun, 7 Jun 2015 17:00:38 -0400 From: "Ackermann, Michael" To: Yannis Nikolopoulos , Mark ZZZ Smith , Philip Matthews Thread-Topic: [v6ops] Looking for info on IGP choices in production dual-stack networks Thread-Index: AQHQoTWbYqqlerHNoEyh6H59OH2Gip2hPgxw Date: Sun, 7 Jun 2015 21:00:35 +0000 Deferred-Delivery: Sun, 7 Jun 2015 21:00:00 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CDF63E3@PWN401EA160.ent.corp.bcbsm.com> References: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> <55746159.2080607@otenet.gr> In-Reply-To: <55746159.2080607@otenet.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.83.71] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0CDF63E3PWN401EA160entc_" MIME-Version: 1.0 X-VPM-MSG-ID: 4df71927-3fd2-408f-89cb-66763d8f3b6e X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 94acd5e2-83be-4fd5-8ddb-e879b5b84f5a X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack 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: Sun, 07 Jun 2015 21:00:45 -0000 --_000_4FC37E442D05A748896589E468752CAA0CDF63E3PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an organization which is significantly behind Yannis (and most at = IETF), I would like to thank him for and agree with all of his inline = comments below. I would like to add that this document is and will be of more value to = those of us just now attempting serious IPv6 deployments. Although purveying manifold benefits in this regard, I would like to = highlight that this document: 1. Is unlikely to pick an IGP or specific implementation for those = of us currently looking, but should assist us in determining which ones to = look at. 2. Showing viable implementation scenarios helps eliminate one more = excuse for not implementing IPv6, which is a major barrier in many large = enterprises. Thanks to the authors and others who have contributed=21 Mike From: v6ops It =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Yannis = Nikolopoulos Sent: Sunday, June 07, 2015 11:21 AM To: Mark ZZZ Smith; Philip Matthews Cc: v6ops list Subject: Re: =5Bv6ops=5D Looking for info on IGP choices in production = dual-stack networks Hello Mark, Philip (as an operator with a dual stack network in place) when I first read = through the draft I found it useful, especially for operators just = starting out with IPv6. Please find some comments inline On 06/06/2015 10:17 AM, Mark ZZZ Smith wrote: Hi Philip, So I've spent more than the last 2 hours writing many abandoned emailed = responses, if the below sounds a bit short, it's only because I want to = send something to get some thoughts out there for consideration=21 From: Philip Matthews = To: Mark ZZZ Smith = Cc: v6ops list Sent: Saturday, 6 June 2015, 0:27 Subject: Re: =5Bv6ops=5D Looking for info on IGP choices in production = dual-stack networks =5BReformatting and excerpting my original message and Mark's reply due = to some technical issues=5D On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote: >> Victor and I are looking for information on the IGP combinations people = are running in their dual-stack networks. We are gathering this = information so we can document in our Design Choices draft which IGP = choices are known to work well (i.e., people actually run this combination = in production networks without issues). The draft will not name names, but = just discuss things in aggregate: for example, =22there are 5 large = production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that = combination is judged to work well=22. >> > I don't think this is really a good thing to be stating in such abstract = terms, that is, at the IGP protocol level. I'd think the successful = co-existence or not of IGPs, assuming the protocols themselves aren't = broken (e.g., by using the same field value id for two different things), = is implementation dependent, and dependent on which specific revision of = the implementation a network has chosen to deploy, and how that network = has chosen to deploy it. For example, a literally perfect implementation = of OSPF + IS-IS might be =22judged to work badly=22 if deployed badly (by, = for example, putting too many routers in the backbone area, overloading = control plane resources.) > > I'm wondering a bit what the fundamental question trying to be being = answered is? Is it to try to capture some information on the current = popularity of various IGPs used to carrying IPv6 routes, and how popular = the use of a single IGP to carry both IPv4 and IPv6 routes is? What = particular question or questions would the reader have that this text is = trying to provide an answer for? > > Regards, > Mark. In the draft we have a table that lists the various combinations of IGPs = for IPv4 and IPv6 and gives a few properties for each combination that = people might want to consider when selecting a combination. The idea is to = give people with less IPv6 knowledge some guidance and perhaps some = reassurance when selecting a combination. One of the columns in the table is called =22Known to work well=22. / I think my main issue is with this column. I think it is asserting that, = for example, all implementations of the combination of OSPFv2 for IPv4 and = IS-IS for IPv6 are =22Known to work well=22. So if you pick a combination = with a =22Y=22 in this column, you'll have no issues regardless of your = OSPF and IS-IS implementation choice, or what deployment model you choose = (single or multiple area, number of routers in an area/level etc.) Originally, Victor and I populated this based on our own experiences and = biases, without consulting others. However, in mid-April Mikael = Abrahamsson commented on this table, noting that he has actually run one = of the combinations that we marked as =22not known to work well=22. So = Victor and I decided that we should be more scientific in populating this = column. Hence this survey of what people actually run. / Rhetorically, for the combination that Mikael has reported, are you = going to put =22Yes and No=22 in the =22Known to Work Well=22 column? Or = does Mikael's evidence cancel out that evidence that Victor and yourself = have? Do you think the draft should NOT contain this type of information? I can = say that I have found the responses so far to be very interesting, even = though it has been just a day so far. / I'm struggling with what criteria should or should not be there, and I = think it depends on answers to the following questions: / - are you comparing IGP protocols or experience with IGP protocol = implementations? In my mind, it's about IGP implementations, not IGPs / I think it is mixing together comparisons of both, but then it is = attributing all of those characteristics to the protocols, rather than to = either the protocols or implementations of the protocols (e.g., =22Known = to work well=22 is certainly a protocol implementation characteristic, and = is implementation specific (as Mikael Abrahamsson's contrary evidence = shows) ) / The results of comparison of protocols will remain the same unless the = protocols change, which doesn't occur often. The results of comparison of = implementations of those protocols (e.g., =22Known to work well=22) can = change tomorrow with a firmware update. In our case, we've been running the IPv4/OSPFv2 - IPv6/IS-IS combination = for quite a few years now so a firmware update or something along those = lines, would not really affect the overall =22experience=22 / - what level of knowledge of IGPs and IGP selection considerations does = the audience have? supposedly, the audience is network operators, so a certain degree of = knowledge should be considered a given. / By not including a number of important IGP selection criteria that need = to be considered (e.g., available control plane resources, addressing = aggregation boundaries, vendor implementation maturity etc.), it implies = that the audience should already have an understanding of the all of the = criteria for IGP selection. well, yes they should. This document's intended audience is operators who = are starting out with IPv6, not people starting out with IP networks in = general. / Yet the inclusion of the =22Known to work well=22 information, without = any implementation or deployment detail, seems to be implying that the = choice can be so simple that if you don't know what to select, just select = one of the protocol combinations with a =22Y=22 in that column. Given how = critical an IGP is to the reliable operation of a network, =22staying = ignorant=22 of IGP implementation details such as maturity, capacity = limitations etc. is dangerous. The choice is not so simple, you're right. It shouldn't come down to = looking up a table in an Internet draft. I believe that the =22IGP = Choice=22 table could also be quite useful as it is, even if =22Known to = work well=22 column can be a bit ambiguous and/or inadequate on its own as = as selection criterion. That's why it would help if the section is = enriched with comments and notes about said implementation choices. regards, Yannis / Regards, Mark. Or do you have a suggestion for something else useful to say about each = combination? Victor and I feel it might be nice to add more information = about each combination, but we don't have any ideas yet on what the = =22more information=22 should be. We would love to hear from anyone who = has a suggestion. - Philip _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0CDF63E3PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

As an organization which is significantly behind Yannis = (and most at IETF), I would like to thank him for and agree with all of = his inline comments below. 

 

 

I would like to add that this document is and will be of = more value to those of us just now attempting serious IPv6 = deployments. 

Although purveying manifold benefits in this regard,  = I would like to highlight that this document:

<=21=5Bif = =21supportLists=5D>1.       <=21=5Bendif=5D>Is unlikely to pick an IGP or specific implementation for = those of us currently looking, but should assist us in determining which = ones to look at.

<=21=5Bif = =21supportLists=5D>2.       <=21=5Bendif=5D>Showing viable implementation scenarios helps eliminate one = more excuse for not implementing IPv6, which is a major barrier in many = large enterprises. 

 

 

Thanks to the authors and others who have = contributed=21

 

Mike

 

From: v6ops It =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Yannis Nikolopoulos
Sent: Sunday, June 07, 2015 11:21 AM
To: Mark ZZZ Smith; Philip Matthews
Cc: v6ops list
Subject: Re: =5Bv6ops=5D Looking for info on IGP choices in = production dual-stack networks

 

Hello Mark, Philip

(as an operator with a dual stack network in place) when I first read = through the draft I found it useful, especially for operators just = starting out with IPv6. Please find some comments inline

On 06/06/2015 10:17 AM, Mark ZZZ Smith wrote:

Hi = Philip,

 

So I've spent = more than the last 2 hours writing many abandoned emailed responses, if = the below sounds a bit short, it's only because I want to send something to get some thoughts out there for consideration=21

 

 

Fro= m: = Philip Matthews <philip_matthews=40magma.= ca>
To: Mark ZZZ Smith <markzzzsmith=40yahoo.co= m.au>
Cc: v6ops list <v6ops=40ietf.org>
Sent: Saturday, 6 June 2015, 0:27
Subject: Re: =5Bv6ops=5D Looking for info on IGP choices in = production dual-stack networks


=5BReformatting and excerpting my original message and Mark's reply  = due to some technical issues=5D

On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote:
>> Victor and I are looking for information on the IGP combinations = people are running in their dual-stack networks. We are gathering this = information so we can document in our Design Choices draft which IGP = choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft = will not name names, but just discuss things in aggregate: for example, = "there are 5 large production networks that run OSPF for IPv4 and = IS-IS for IPv6, thus that combination is judged to work well".
>> 
> I don't think this is really a good thing to be stating in such = abstract terms, that is, at the IGP protocol level. I'd think the = successful co-existence or not of IGPs, assuming the protocols themselves = aren't broken (e.g., by using the same field value id for two different things), is  implementation dependent, and = dependent on which specific revision of the implementation a network has = chosen to deploy, and how that network has chosen to deploy it. For = example, a literally perfect implementation of OSPF &=2343; IS-IS might be "judged to work badly" if deployed badly = (by, for example, putting too many routers in the backbone area, = overloading control plane resources.)
>
> I'm wondering a bit what the fundamental question trying to be being = answered is? Is it to try to capture some information on the current = popularity of various IGPs used to carrying IPv6 routes, and how popular = the use of a single IGP to carry both IPv4 and IPv6 routes is?  What particular question or questions would the = reader have that this text is trying to provide an answer for?
>
> Regards,
> Mark.

In the draft we have a table that lists the various combinations of IGPs = for IPv4 and IPv6 and gives a few properties for each combination that = people might want to consider when selecting a combination. The idea is to = give people with less IPv6 knowledge some guidance and perhaps some reassurance when selecting a combination.

One of the columns in the table is called "Known to work = well".

 

/ I think my = main issue is with this column. I think it is asserting that, for example, = all implementations of the combination of OSPFv2 for IPv4 and IS-IS for IPv6 are "Known to work well". So if you pick a combination with a = "Y" in this column, you'll have no issues regardless of your = OSPF and IS-IS implementation choice, or what deployment model you choose = (single or multiple area, number of routers in an area/level etc.)

 

  = Originally, Victor and I populated this based on our own experiences and = biases, without consulting others.  However, in mid-April Mikael = Abrahamsson commented on this table, noting that he has actually run one of the combinations = that we marked as "not known to work well".  So Victor and = I decided that we should be more scientific in populating this = column.  Hence this survey of what people actually = run.

 

/ Rhetorically, = for the combination that Mikael has reported, are you going to put = "Yes and No" in the "Known to Work Well" column? Or = does Mikael's evidence cancel out that evidence that Victor and yourself have?

Do you think the draft should NOT contain this type of information?  = I can say that I have found the responses so far to be very interesting, = even though it has been just a day so far.

/ I'm struggling with what criteria should or should not be there, and I = think it depends on answers to the following = questions:

 

/ - are you = comparing IGP protocols or experience with IGP protocol = implementations?

 


In my mind, it's about IGP implementations, not IGPs


/ I think it is = mixing together comparisons of both, but then it is attributing all of = those characteristics to the protocols, rather than to either the protocols or implementations of the protocols (e.g., "Known to work well" = is certainly a protocol implementation characteristic, and is = implementation specific (as Mikael Abrahamsson's contrary evidence shows) = )

 

/ The results = of comparison of protocols will remain the same unless the protocols = change, which doesn't occur often. The results of comparison of = implementations of those protocols (e.g., "Known to work well") can change = tomorrow with a firmware update.

 


In our case, we've been running the IPv4/OSPFv2 - IPv6/IS-IS combination = for quite a few years now so a firmware update or something along those = lines, would not really affect the overall "experience"


/ - what level = of knowledge of IGPs and IGP selection considerations does the audience = have?

 


supposedly, the audience is network operators, so a certain degree of = knowledge should be considered a given.


/ By not = including a number of important IGP selection criteria that need to be = considered (e.g., available control plane resources, addressing = aggregation boundaries, vendor implementation maturity etc.), it implies that the audience should = already have an understanding of the all of the criteria for IGP = selection.

 


well, yes they should. This document's intended audience is operators who = are starting out with IPv6, not people starting out with IP networks in = general.


/ Yet the = inclusion of the "Known to work well" information, without any = implementation or deployment detail, seems to be implying that the choice = can be so simple that if you don't know what to select, just select one of the protocol = combinations with a "Y" in that column. Given how critical an = IGP is to the reliable operation of a network, "staying = ignorant" of IGP implementation details such as maturity, capacity limitations etc. is dangerous.


The choice is not so simple, you're right. It shouldn't come down to = looking up a table in an Internet draft. I believe that the "IGP = Choice" table could also be quite useful as it is, even if = "Known to work well" column can be a bit ambiguous and/or = inadequate on its own as as selection criterion. That's why it would help if the = section is enriched with comments and notes about said implementation = choices.

regards,
Yannis


 

/ = Regards,

Mark.=

 

 

Or do you have = a suggestion for something else useful to say about each = combination?  Victor and I feel it might be nice to add more = information about each combination, but we don't have any ideas yet on what the "more information" = should be.  We would love to hear from anyone who has a suggestion.

 

 

 

- = Philip

 




_______________________________________________
v6ops mailing list
v6ops=40ietf.org
https://www.ietf.o=
rg/mailman/listinfo/v6ops




--

The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_4FC37E442D05A748896589E468752CAA0CDF63E3PWN401EA160entc_-- From nobody Sun Jun 7 15:07:23 2015 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 AD9271ACF17 for ; Sun, 7 Jun 2015 15:07:21 -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, 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 U_luPjEdhx-z for ; Sun, 7 Jun 2015 15:07:19 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551631ACF08 for ; Sun, 7 Jun 2015 15:07:19 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t57M7FaJ092339 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Jun 2015 23:07:16 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <5574C093.5000909@foobar.org> Date: Sun, 07 Jun 2015 23:07:15 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack 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: Sun, 07 Jun 2015 22:07:21 -0000 On 06/06/2015 08:17, Mark ZZZ Smith wrote: > Yet the inclusion of the "Known to work well" information, without any > implementation or deployment detail, seems to be implying that the choice > can be so simple that if you don't know what to select, just select one of > the protocol combinations with a "Y" in that column. Given how critical an > IGP is to the reliable operation of a network, "staying ignorant" of IGP > implementation details such as maturity, capacity limitations etc. is > dangerous. maybe the root issue we're trying to figure out is what we mean by "Known to work well". E.g. ISIS is known to work well as both an ipv4 and ipv6 IGP unless you happen to use Netgear GSM7224 switches, in which case it doesn't work at all - this hardware flat refuses to forward ISIS frames. EIGRP and Babel are fine for IPv4 and IPv6 IGP operation but completely useless the moment you enable mpls, because they're distance vector protocols and mpls needs a full topology map in order to work. You could even argue that there were situations where rip/ripng made sense. I've even come across a single instance in my career where rip was arguably a good choice of routing protocol in a large production network - but do we really want to push ripv2/ripng as serious general purpose options? I doubt it. Looking at the blanks in the table, I've no doubt that ISIS for ipv4 and OSPFv3 for ipv6 would be fully appropriate for a production network which wanted separate IGPs for each protocol for whatever reason (e.g. mpls for ipv4 but native ipv6). The "Hard Separation" column can disappear as it's redundant. If you're running the same IGP on the same interface to handle two different protocols, it pretty much a necessity to handle this in the same IGP instance on each side. So Hard Separation is equivalent to running the same protocol on each side. The "Similar Configuration Possible" column is awkward. I'm guessing that this refers to old style and new style cisco ospfv2 configuration grammar. Do we really need this? Quagga OSPFv3 is a bit shaky at times. Does that qualify as "Known to work well"? Quagga ISIS doesn't support MT, so if the rest of the network is running ISIS-MT, there might need to be a compatibility mechanism in place. Perhaps as a WG we're heading towards stating truisms here, namely that (with the potential exception of ospfv3 for ipv4 which is relatively new), IGPs which carry a particular protocol work well for that protocol, and that pretty much all competently-written routing stacks can mix-n-match different IGPs for different protocols without causing problems. Could I suggest that the existing section 2.3 be dropped and replaced with either: 1. a couple of paragraphs which state: - the operator needs to make a choice between whether to run the same IGP for each protocol or a different IGP. - it is not unusual practice to run different IGPs for different protocols and the competence of each routing protocol is often implementation dependent. - routing protocol choice for IPv6 often boils down to much the same parameters as for IPv4 which might go from from NOC familiarity to existing deployment requirements. There may be caveats, e.g. potentially no requirement for an ipv6 igp if the network is pure mpls+ldp. or: 2. an description of each IGP which supports ipv6 with a brief rundown of capabilities / limitations. Nick From nobody Sun Jun 7 23:50:02 2015 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 E9F031B2CA7 for ; Sun, 7 Jun 2015 23:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 2PdIKcjmngDi for ; Sun, 7 Jun 2015 23:49:59 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 0EC401B2C96 for ; Sun, 7 Jun 2015 23:49:58 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 49CE460874 for ; Mon, 8 Jun 2015 08:49:56 +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 EC1A86077C for ; Mon, 8 Jun 2015 08:49:55 +0200 (CEST) Received: (qmail 42395 invoked by uid 1007); 8 Jun 2015 08:49:55 +0200 Date: Mon, 8 Jun 2015 08:49:55 +0200 From: Gert Doering To: Nick Hilliard Message-ID: <20150608064955.GA54385@Space.Net> References: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> <5574C093.5000909@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5574C093.5000909@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack 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: Mon, 08 Jun 2015 06:50:01 -0000 hi, On Sun, Jun 07, 2015 at 11:07:15PM +0100, Nick Hilliard wrote: > EIGRP and Babel are fine for IPv4 and IPv6 IGP operation but completely > useless the moment you enable mpls, because they're distance vector > protocols and mpls needs a full topology map in order to work. Don't tell that to my MPLS routers. *TE* needs the topology map, normal LSPs work perfectly well with distance-vector protocols. 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 Mon Jun 8 06:40:02 2015 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 90AB21A8788 for ; Mon, 8 Jun 2015 06:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 jUL7f6t7rHIt for ; Mon, 8 Jun 2015 06:39:55 -0700 (PDT) Received: from tor-smtp-04.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2944A1A8785 for ; Mon, 8 Jun 2015 06:39:53 -0700 (PDT) Received: from [24.114.105.18] (helo=[172.20.10.4]) by tor-smtp-04.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1Z1xHK-0003MJ-5Y; Mon, 08 Jun 2015 09:39:51 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-3-197053811 From: Philip Matthews In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDF63E3@PWN401EA160.ent.corp.bcbsm.com> Date: Mon, 8 Jun 2015 09:39:46 -0400 Message-Id: <083A228E-347F-4F70-82DB-68B4EEF2966D@magma.ca> References: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> <55746159.2080607@otenet.gr> <4FC37E442D05A748896589E468752CAA0CDF63E3@PWN401EA160.ent.corp.bcbsm.com> To: Mark ZZZ Smith , Yannis Nikolopoulos , Michael Ackermann X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.105.18] Archived-At: Cc: v6ops list Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack 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: Mon, 08 Jun 2015 13:40:00 -0000 --Apple-Mail-3-197053811 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, Yannis, Michael: Thanks to all of you for your comments, and especially to Mark for = trying to keep us honest :) Victor and I have not yet had a chance to discuss the responses we are = getting back from the survey. However, to answer one of Mark's = questions, our plan before we sent out the original emails (to various = mailing lists) was to say that a combination was known to work well if = we heard of a number of production deployments running that combination, = say at least four deployments of reasonable size. So just one deployment = was not sufficient grounds to say "known to work well". Never-the-less, I understand some of Mark's concerns. I don't have an = answer right now on how we are going to address them. Give Victor and I = a chance to discuss them and then we will reply. - Philip On 2015-06-07, at 17:00 , Ackermann, Michael wrote: > As an organization which is significantly behind Yannis (and most at = IETF), I would like to thank him for and agree with all of his inline = comments below.=20 > =20 > =20 > I would like to add that this document is and will be of more value to = those of us just now attempting serious IPv6 deployments.=20 > Although purveying manifold benefits in this regard, I would like to = highlight that this document: > 1. Is unlikely to pick an IGP or specific implementation for = those of us currently looking, but should assist us in determining which = ones to look at. > 2. Showing viable implementation scenarios helps eliminate one = more excuse for not implementing IPv6, which is a major barrier in many = large enterprises.=20 > =20 > =20 > Thanks to the authors and others who have contributed! > =20 > Mike > =20 > From: v6ops It [mailto:v6ops-bounces@ietf.org] On Behalf Of Yannis = Nikolopoulos > Sent: Sunday, June 07, 2015 11:21 AM > To: Mark ZZZ Smith; Philip Matthews > Cc: v6ops list > Subject: Re: [v6ops] Looking for info on IGP choices in production = dual-stack networks > =20 > Hello Mark, Philip >=20 > (as an operator with a dual stack network in place) when I first read = through the draft I found it useful, especially for operators just = starting out with IPv6. Please find some comments inline >=20 > On 06/06/2015 10:17 AM, Mark ZZZ Smith wrote: > Hi Philip, > =20 > So I've spent more than the last 2 hours writing many abandoned = emailed responses, if the below sounds a bit short, it's only because I = want to send something to get some thoughts out there for consideration! > =20 > =20 > From: Philip Matthews > To: Mark ZZZ Smith =20 > Cc: v6ops list =20 > Sent: Saturday, 6 June 2015, 0:27 > Subject: Re: [v6ops] Looking for info on IGP choices in production = dual-stack networks >=20 > [Reformatting and excerpting my original message and Mark's reply due = to some technical issues] >=20 > On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote: > >> Victor and I are looking for information on the IGP combinations = people are running in their dual-stack networks. We are gathering this = information so we can document in our Design Choices draft which IGP = choices are known to work well (i.e., people actually run this = combination in production networks without issues). The draft will not = name names, but just discuss things in aggregate: for example, "there = are 5 large production networks that run OSPF for IPv4 and IS-IS for = IPv6, thus that combination is judged to work well". > >> =20 > > I don't think this is really a good thing to be stating in such = abstract terms, that is, at the IGP protocol level. I'd think the = successful co-existence or not of IGPs, assuming the protocols = themselves aren't broken (e.g., by using the same field value id for two = different things), is implementation dependent, and dependent on which = specific revision of the implementation a network has chosen to deploy, = and how that network has chosen to deploy it. For example, a literally = perfect implementation of OSPF + IS-IS might be "judged to work badly" = if deployed badly (by, for example, putting too many routers in the = backbone area, overloading control plane resources.)=20 > >=20 > > I'm wondering a bit what the fundamental question trying to be being = answered is? Is it to try to capture some information on the current = popularity of various IGPs used to carrying IPv6 routes, and how popular = the use of a single IGP to carry both IPv4 and IPv6 routes is? What = particular question or questions would the reader have that this text is = trying to provide an answer for? > >=20 > > Regards, > > Mark. >=20 > In the draft we have a table that lists the various combinations of = IGPs for IPv4 and IPv6 and gives a few properties for each combination = that people might want to consider when selecting a combination. The = idea is to give people with less IPv6 knowledge some guidance and = perhaps some reassurance when selecting a combination.=20 >=20 > One of the columns in the table is called "Known to work well". > =20 > / I think my main issue is with this column. I think it is asserting = that, for example, all implementations of the combination of OSPFv2 for = IPv4 and IS-IS for IPv6 are "Known to work well". So if you pick a = combination with a "Y" in this column, you'll have no issues regardless = of your OSPF and IS-IS implementation choice, or what deployment model = you choose (single or multiple area, number of routers in an area/level = etc.) > =20 > Originally, Victor and I populated this based on our own experiences = and biases, without consulting others. However, in mid-April Mikael = Abrahamsson commented on this table, noting that he has actually run one = of the combinations that we marked as "not known to work well". So = Victor and I decided that we should be more scientific in populating = this column. Hence this survey of what people actually run. > =20 > / Rhetorically, for the combination that Mikael has reported, are you = going to put "Yes and No" in the "Known to Work Well" column? Or does = Mikael's evidence cancel out that evidence that Victor and yourself = have? >=20 > Do you think the draft should NOT contain this type of information? I = can say that I have found the responses so far to be very interesting, = even though it has been just a day so far. >=20 > / I'm struggling with what criteria should or should not be there, and = I think it depends on answers to the following questions: > =20 > / - are you comparing IGP protocols or experience with IGP protocol = implementations? > =20 >=20 > In my mind, it's about IGP implementations, not IGPs >=20 >=20 > / I think it is mixing together comparisons of both, but then it is = attributing all of those characteristics to the protocols, rather than = to either the protocols or implementations of the protocols (e.g., = "Known to work well" is certainly a protocol implementation = characteristic, and is implementation specific (as Mikael Abrahamsson's = contrary evidence shows) ) > =20 > / The results of comparison of protocols will remain the same unless = the protocols change, which doesn't occur often. The results of = comparison of implementations of those protocols (e.g., "Known to work = well") can change tomorrow with a firmware update. > =20 >=20 > In our case, we've been running the IPv4/OSPFv2 - IPv6/IS-IS = combination for quite a few years now so a firmware update or something = along those lines, would not really affect the overall "experience" >=20 >=20 > / - what level of knowledge of IGPs and IGP selection considerations = does the audience have? > =20 >=20 > supposedly, the audience is network operators, so a certain degree of = knowledge should be considered a given. >=20 >=20 > / By not including a number of important IGP selection criteria that = need to be considered (e.g., available control plane resources, = addressing aggregation boundaries, vendor implementation maturity etc.), = it implies that the audience should already have an understanding of the = all of the criteria for IGP selection. > =20 >=20 > well, yes they should. This document's intended audience is operators = who are starting out with IPv6, not people starting out with IP networks = in general. >=20 >=20 > / Yet the inclusion of the "Known to work well" information, without = any implementation or deployment detail, seems to be implying that the = choice can be so simple that if you don't know what to select, just = select one of the protocol combinations with a "Y" in that column. Given = how critical an IGP is to the reliable operation of a network, "staying = ignorant" of IGP implementation details such as maturity, capacity = limitations etc. is dangerous. >=20 > The choice is not so simple, you're right. It shouldn't come down to = looking up a table in an Internet draft. I believe that the "IGP Choice" = table could also be quite useful as it is, even if "Known to work well" = column can be a bit ambiguous and/or inadequate on its own as as = selection criterion. That's why it would help if the section is enriched = with comments and notes about said implementation choices. >=20 > regards, > Yannis >=20 >=20 > =20 > / Regards, > Mark. > =20 > =20 > Or do you have a suggestion for something else useful to say about = each combination? Victor and I feel it might be nice to add more = information about each combination, but we don't have any ideas yet on = what the "more information" should be. We would love to hear from = anyone who has a suggestion. > =20 >=20 > =20 > =20 > - Philip >=20 > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > --=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. >=20 --Apple-Mail-3-197053811 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Mark, = Yannis, Michael:

Thanks to all of you for your = comments, and especially to Mark for trying to keep us honest = :)

Victor and I have not yet had a chance to = discuss the responses we are getting back from the survey. However, to = answer one of Mark's questions, our plan before we sent out the original = emails (to various mailing lists) was to say that a combination was = known to work well if we heard of a number of production deployments = running that combination, say at least four deployments of reasonable = size. So just one deployment was not sufficient grounds to say "known to = work well".

Never-the-less, I understand some = of Mark's concerns. I don't have an answer right now on how we are going = to address them. Give Victor and I a chance to discuss them and then we = will reply.

- = Philip



On = 2015-06-07, at 17:00 , Ackermann, Michael wrote:

As an = organization which is significantly behind Yannis (and most at IETF), I = would like to thank him for and agree with all of his inline comments = below. 
 
I would like to add that this document is and will = be of more value to those of us just now attempting serious IPv6 = deployments. 
Although purveying manifold benefits in this = regard,  I would like to highlight that this = document:
1. Is unlikely to pick an IGP or specific = implementation for those of us currently looking, but should assist us = in determining which ones to look at.
2. Showing viable implementation scenarios helps = eliminate one more excuse for not implementing IPv6, which is a major = barrier in many large enterprises. 
From: Philip Matthews  Mark ZZZ Smith <markzzzsmith@yahoo.com.au> 
Cc: v6ops list <v6ops@ietf.org> 
Sent: Saturday, 6 June 2015, = 0:27
Subject: Re: [v6ops] Looking for = info on IGP choices in production dual-stack networks
>>  
> I don't think this = is really a good thing to be stating in such abstract terms, that is, at = the IGP protocol level. I'd think the successful co-existence or not of = IGPs, assuming the protocols themselves aren't broken (e.g., by using = the same field value id for two different things), is  = implementation dependent, and dependent on which specific revision of = the implementation a network has chosen to deploy, and how that network = has chosen to deploy it. For example, a literally perfect implementation = of OSPF + IS-IS might be "judged to work badly" if deployed badly (by, = for example, putting too many routers in the backbone area, overloading = control plane resources.) 
> 
> I'm wondering a = bit what the fundamental question trying to be being answered is? Is it = to try to capture some information on the current popularity of various = IGPs used to carrying IPv6 routes, and how popular the use of a single = IGP to carry both IPv4 and IPv6 routes is?  What particular = question or questions would the reader have that this text is trying to = provide an answer for?
> 
> Regards,
> = Mark.

In the draft we have a table that lists the various = combinations of IGPs for IPv4 and IPv6 and gives a few properties for = each combination that people might want to consider when selecting a = combination. The idea is to give people with less IPv6 knowledge some = guidance and perhaps some reassurance when selecting a combination. 

One of the columns = in the table is called "Known to work = well".
/ I think = my main issue is with this column. I think it is asserting that, for = example, all implementations of the combination of OSPFv2 for IPv4 and = IS-IS for IPv6 are "Known to work well". So if you pick a combination = with a "Y" in this column, you'll have no issues regardless of your OSPF = and IS-IS implementation choice, or what deployment model you choose = (single or multiple area, number of routers in an area/level = etc.)
  = Originally, Victor and I populated this based on our own experiences and = biases, without consulting others.  However, in mid-April Mikael = Abrahamsson commented on this table, noting that he has actually run one = of the combinations that we marked as "not known to work well".  So = Victor and I decided that we should be more scientific in populating = this column.  Hence this survey of what people actually = run.
/ = Rhetorically, for the combination that Mikael has reported, are you = going to put "Yes and No" in the "Known to Work Well" column? Or does = Mikael's evidence cancel out that evidence that Victor and yourself = have?

Do you think the draft should NOT contain this type of = information?  I can say that I have found the responses so far to = be very interesting, even though it has been just a day so far.

/ = I'm struggling with what criteria should or should not be there, and I = think it depends on answers to the following = questions:
/ - are = you comparing IGP protocols or experience with IGP protocol = implementations?

In my mind, it's about IGP = implementations, not IGPs


/ I think = it is mixing together comparisons of both, but then it is attributing = all of those characteristics to the protocols, rather than to either the = protocols or implementations of the protocols (e.g., "Known to work = well" is certainly a protocol implementation characteristic, and is = implementation specific (as Mikael Abrahamsson's contrary evidence = shows) )
/ The = results of comparison of protocols will remain the same unless the = protocols change, which doesn't occur often. The results of comparison = of implementations of those protocols (e.g., "Known to work well") can = change tomorrow with a firmware = update.

In our case, we've been running the = IPv4/OSPFv2 - IPv6/IS-IS combination for quite a few years now so a = firmware update or something along those lines, would not really affect = the overall "experience"


/ - what = level of knowledge of IGPs and IGP selection considerations does the = audience have?

supposedly, the audience is network = operators, so a certain degree of knowledge should be considered a = given.


/ By not = including a number of important IGP selection criteria that need to be = considered (e.g., available control plane resources, addressing = aggregation boundaries, vendor implementation maturity etc.), it implies = that the audience should already have an understanding of the all of the = criteria for IGP selection.

well, yes they should. This = document's intended audience is operators who are starting out with = IPv6, not people starting out with IP networks in = general.


/ Yet the = inclusion of the "Known to work well" information, without any = implementation or deployment detail, seems to be implying that the = choice can be so simple that if you don't know what to select, just = select one of the protocol combinations with a "Y" in that column. Given = how critical an IGP is to the reliable operation of a network, "staying = ignorant" of IGP implementation details such as maturity, capacity = limitations etc. is = dangerous.

The choice is not so simple, you're = right. It shouldn't come down to looking up a table in an Internet = draft. I believe that the "IGP Choice" table could also be quite useful = as it is, even if "Known to work well" column can be a bit ambiguous = and/or inadequate on its own as as selection criterion. That's why it = would help if the section is enriched with comments and notes about said = implementation = choices.

regards,
Yannis



= --Apple-Mail-3-197053811-- From nobody Tue Jun 9 03:10:39 2015 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 010DA1B2B70 for ; Tue, 9 Jun 2015 03:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.201 X-Spam-Level: *** X-Spam-Status: No, score=3.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 lhAa7ab5UT1R for ; Tue, 9 Jun 2015 03:10:29 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F151B2B44 for ; Tue, 9 Jun 2015 03:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1433844628; bh=KK5MTiyXWXxiNI//bFiSsgmGS7i2CZBU8h7MMSdfOLQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=V9z/WCOY3sX+LgJKgZHkMzp/MJkA2tt8ZNF73M+mFxzYGvCEESnq46aIs3b8jA5qL1Td8WMfLBW2Oku/WAPg+7q9oKdJ6momnLsfGJTWtQSgermwM4XmEqliLNBZHFXSZ5b/fBh7FyOK8z81fJ91lXYeE4pUlTZ0R2yDAsK204tFFxAzOgZIWpC4rVJ9F5+dNs9YVdNT4QxgmFd4w6xONOGm+pE4XL6S0eLalByUAkxyEG4nIJuxF5I74TPflvnqMSrI/V9iDmcI1Gz7Qz7czcMpVu1Yp4H78wOIxn3detpTE9rnE729SVz8xigRXmpkc7U1DpcajMScbnzjALMHfA== Received: from [66.196.81.171] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 09 Jun 2015 10:10:28 -0000 Received: from [98.139.212.203] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 09 Jun 2015 10:10:28 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 09 Jun 2015 10:10:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 502818.87387.bm@omp1012.mail.bf1.yahoo.com X-YMail-OSG: kVhafM4VM1kI9umkFv9G4ec6YYovyXGSV3YqCji4ZdItVdewcCV6iESM48CVlz7 pcVM8RYQEM01a6Szd5DbHqCMoOKPfZOl84C9iaIMOsu4Jzu873E8rKfTcZ2rV4lTtFxxeq.hnusF svRUlGa2wfOjA6xlp6pYXCl87URnoWffSIBqO_Q4RL8sKHcBsXXlLvwQkhUbhXzvibOooG2vK8Xz 88Xxsy1hyyT7VDT8Gf7eHWuriUkEI9OzzdkMLEMLvrBxTQr3faHInFXvVd00uQdT1WHvR33652xK cz_llr4pIr77cRR.zqWcC3Sl8nRusQZCI85EdUCJenD.WvPx2WUixm54D15TVD9m5U3Nqqd79EjZ Tw.2_u7QoB8W8_tbfU7NlvpoPKKtzS64xiADuSxP2I6GDRs_NPLZ_ZnLzc54WkEaxAi9bzuydAnr DDzkKBkjiR_qKBQUebG1ACPPV6Ec5TTT0yZVJ8MkNadL0.9uppjSFc4ZCHYhvLPnKGouBLg83Bea L067Fki0pg3utYL89LvOD9a0sloiOhE6jazAQSIF3ALMo Received: by 66.196.80.122; Tue, 09 Jun 2015 10:10:28 +0000 Date: Tue, 9 Jun 2015 10:09:23 +0000 (UTC) From: Mark ZZZ Smith To: joel jaeggli , Brian E Carpenter , "v6ops@ietf.org" Message-ID: <1266948174.9509110.1433844564027.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <55749551.4080801@bogus.com> References: <55749551.4080801@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem WGLC 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: Tue, 09 Jun 2015 10:10:38 -0000 ________________________________ From: joel jaeggli To: Brian E Carpenter ; v6ops@ietf.org Sent: Monday, 8 June 2015, 5:02 Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem WGLC On 5/31/15 4:45 PM, Brian E Carpenter wrote: > Hi, > > Generally I think this is useful and almost ready. > >> 3.1. Alternatives >> >> As an alternative, it may be appropriate to lower the TCP MSS to 1220 >> in order to accommodate 1280 byte MTU. We consider this undesirable >> as hosts may not be able to independently set TCP MSS by address- >> family thereby impacting IPv4, or alternatively that it relies on a >> middle-box to clamp the MSS independently from the end-systems. > > The "that" in the second sentence doesn't parse. I don't understand > what the draft is trying to say about MSS clamping. Is this better? or alternatively that middle-boxes need to be employed to clamp the MSS independently from the end-systems. / I think it is also necessary to point out that the 1220 MSS value doesn't allow for any EHs if the packet size is limited / being limited to 1280. Middle boxes should also be taking into account the present EHs if they adjust the TCP MSS. > Also, shouldn't we say "undesirable but possibly necessary in some > cases"? A server at the mercy of an ISP might *need* to apply MSS clamping. since we are dealing with alternative mitigations we are justifying why we don't like them, I thin they can be employed. > Nit: > > It's confusing to have these two sections with identical titles: > >> 3.1. Alternatives >> 3.2.1. Alternatives > > Maybe 3.1 should be "MSS-based Alternatives" > and 3.2.1 "Distributed Proxy Alternatives" nice. thanks > Brian > On 01/06/2015 06:00, fred@cisco.com wrote: >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem. >> 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. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jun 9 22:44:05 2015 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 72B5D1AC3A7 for ; Tue, 9 Jun 2015 22:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 RBPAxSZBa2yA for ; Tue, 9 Jun 2015 22:44:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DC51AC39F for ; Tue, 9 Jun 2015 22:44:02 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:c582:6580:5e73:6153]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t5A5i0iB052397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Jun 2015 05:44:01 GMT (envelope-from joelja@bogus.com) To: Mark ZZZ Smith , Brian E Carpenter , "v6ops@ietf.org" References: <55749551.4080801@bogus.com> <1266948174.9509110.1433844564027.JavaMail.yahoo@mail.yahoo.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <5577CEA0.80308@bogus.com> Date: Tue, 9 Jun 2015 22:44:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <1266948174.9509110.1433844564027.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v2nd463GcD9IDFDOHFXFkcKl4gh1gev4t" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem 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, 10 Jun 2015 05:44:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v2nd463GcD9IDFDOHFXFkcKl4gh1gev4t Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/9/15 3:09 AM, Mark ZZZ Smith wrote: >=20 >=20 >=20 >=20 > ________________________________ > From: joel jaeggli > To: Brian E Carpenter ; v6ops@ietf.org=20 > Sent: Monday, 8 June 2015, 5:02 > Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem WGLC >=20 >=20 > On 5/31/15 4:45 PM, Brian E Carpenter wrote: >> Hi, >> >> Generally I think this is useful and almost ready. >> >>> 3.1. Alternatives >>> >>> As an alternative, it may be appropriate to lower the TCP MSS to 1= 220 >>> in order to accommodate 1280 byte MTU. We consider this undesirab= le >>> as hosts may not be able to independently set TCP MSS by address- >>> family thereby impacting IPv4, or alternatively that it relies on = a >>> middle-box to clamp the MSS independently from the end-systems. >> >> The "that" in the second sentence doesn't parse. I don't understand >> what the draft is trying to say about MSS clamping. >=20 > Is this better? >=20 > or alternatively that middle-boxes need to be employed to clamp the MSS= >=20 > independently from the end-systems. >=20 > / I think it is also necessary to point out that the 1220 MSS value doe= sn't allow for any EHs if the packet size is limited / being limited to 1= 280. Middle boxes should also be taking into account the present EHs if t= hey adjust the TCP MSS. It's worth noting i suppose, as a potential contributor to mtu size issues I think we can do that. if you send extension header containing packets or fragments to my servers, pmtud is maybe isn't the biggest problem because they'll never arrive. :/ >> Also, shouldn't we say "undesirable but possibly necessary in some >> cases"? A server at the mercy of an ISP might *need* to apply MSS clam= ping. >=20 > since we are dealing with alternative mitigations we are justifying why= > we don't like them, I thin they can be employed. >=20 >> Nit: >> >> It's confusing to have these two sections with identical titles: >> >>> 3.1. Alternatives >>> 3.2.1. Alternatives >> >> Maybe 3.1 should be "MSS-based Alternatives" >> and 3.2.1 "Distributed Proxy Alternatives" >=20 > nice. >=20 > thanks >=20 >=20 >=20 >=20 >> Brian >> On 01/06/2015 06:00, fred@cisco.com wrote: >>> This is to initiate a two week working group last call of >>> http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem.=20 >>> Please read it now. If you find nits (spelling errors, minor suggeste= d >>> 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. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --v2nd463GcD9IDFDOHFXFkcKl4gh1gev4t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlV3zqAACgkQ8AA1q7Z/VrJ+fgCeLP9eY6/YnR+eIy1bv2X2rBs/ BOYAnj7zvjB6KS25PCwSmY+z7naw1pOK =bnrv -----END PGP SIGNATURE----- --v2nd463GcD9IDFDOHFXFkcKl4gh1gev4t-- From nobody Wed Jun 10 06:05:25 2015 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 0ADF21A1BCC for ; Wed, 10 Jun 2015 06:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 LYU-Uqs5bmbG for ; Wed, 10 Jun 2015 06:05:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C5F1A1BD9 for ; Wed, 10 Jun 2015 06:05:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5AD5Cpc029892 for ; Wed, 10 Jun 2015 15:05:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A6024203698 for ; Wed, 10 Jun 2015 15:07:47 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CFF8F203696 for ; Wed, 10 Jun 2015 15:07:38 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5AD521P024327 for ; Wed, 10 Jun 2015 15:05:03 +0200 Message-ID: <557835FE.1020800@gmail.com> Date: Wed, 10 Jun 2015 15:05:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <54EB1F2F.4000604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) 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, 10 Jun 2015 13:05:23 -0000 Resurecting an earlier discussion... I hear Apple just announced about mandating IPv6 in each app submitted to store, and about a tech to offer IPv6 hotspots to app developpers on IPv4. Not sure that includes a CLAT implementation on iPhone, nor about what kind of protocol spec can realize that IPv4-IPv6 behaviour (CLAT, 64share, DS-MIP, NAT/NPT, any new?). Alex Le 23/02/2015 21:38, James Woodyatt a écrit : > p1. I have no inside information from Apple's Core OS Networking > group newer than seventeen months ago when I separated. I'm not at > liberty to discuss confidential stuff even today. That said, I can > dispel some myths. > > p2. The security architecture for networking on iOS will effectively > prevent any third-party efforts from delivering a CLAT for iOS. > Andrew Yourtchenko wrote one for OS X, but it will be necessary for > Apple Core OS engineers to deliver it on iOS. Anyone who wants to > review the source code for the Darwin kernel in > publicsource.apple.com should be able > to get a sense of the scope of this problem. > > p3. The Android implementation may be Apache-licensed, but— like Mr. > Yourtchenko's implementation— it's unsuitable for general production > use with Apple's networking stack, which has diverged substantially > from FreeBSD in the last several years. The Darwin kernel networking > stack in iOS and OS X has interface scoped routes, which the Core > Networking and Core Telephony subsystems use extensively. The IPv4 > addresses assigned to the host via the CLAT must be attached to the > same interface as the translated IPv6 address or the interface scoped > routing won't work properly. Again, see the Darwin kernel source code > for details. > > p4. It might be comparatively easy for Apple to deliver a very > limited CLAT, using one of several Darwin-specific tricks, e.g. a > socket filter, that only works to enable certain 3rd-party > applications, e.g. Skype, on IPv6-only LTE networks with a PLAT > service available, but that will also have some interoperability > issues that make it unsuitable for general reliability. I hope they > don't go that way, but I don't work there anymore, and I don't think > anyone there would listen to me anyway, if that's what they were to > decide to do. I can kinda see why they might choose to do this. > > For these reasons, I would counsel any operators expecting Apple to > deliver a CLAT in a forthcoming release of iOS to test it extensively > before accepting it. Especially: A) test it with Internet Sharing > enabled, B) test it with VPN connect-on-demand, and C) test it with > AirDrop and AirPlay in use. Whatever method they choose to implement > a CLAT, it will be a tricky job, and I would be surprised if it > doesn't take a lot of Radar problems to be opened and closed before > it works acceptably. > > Shorter james: I don't think IETF should list having a CLAT as > requirement for 3GPP mobile devices. It could be awkward for us while > the leading vendor of IPv6-capable handsets is shipping without > one. > > > On Mon, Feb 23, 2015 at 4:38 AM, Alexandru Petrescu > > > wrote: > > Hello participants to v6ops WG, > > What is the status of a CLAT implementation on iPhone? Any hint in > that direction? > > I am asking because in private conversation I have noticed doubts > about this being done. Or, since the iPhone relies on a bsd > derivative, it would be technically feasible to implement CLAT on it; > it is nothing more than some iptables address translation plus a bit > of python scripting in case. > > (CLAT is needed by some IPv4 apps to continue working on a > smartphone connected solely with an IPv6-only PDP type). > > Alex > > _________________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > > > > -- james woodyatt > Nest > Labs, Communications Engineering > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jun 10 06:24:29 2015 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 60B151ACEF4 for ; Wed, 10 Jun 2015 06:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fQI4R-O5mNY2 for ; Wed, 10 Jun 2015 06:24:26 -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 70C9E1A6F13 for ; Wed, 10 Jun 2015 06:24:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BC285A2; Wed, 10 Jun 2015 15:24:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1433942661; bh=JM+OuPPT52lDOAe8Xm/ARbS3h2m2IpKYya2aet1Y0zQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Rp5Cxi2U1SEITF5FusN2iMklx3H8AEF1M8ajsE7XkqQHcBTl2GD1WX7yjBo1Yuk0g TKuGUBB/RVwaRKiA0QQVl5YfY7nwCnoeuvhC5JKyoLSSmhNG3oyrD+lH5IR8TZ3Z2Z y1uu65xXol1EMUU8YV1+4x1C3A0EnGoC+Vc5LCSU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B7DA49F; Wed, 10 Jun 2015 15:24:21 +0200 (CEST) Date: Wed, 10 Jun 2015 15:24:21 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <557835FE.1020800@gmail.com> Message-ID: References: <54EB1F2F.4000604@gmail.com> <557835FE.1020800@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; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) 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, 10 Jun 2015 13:24:28 -0000 On Wed, 10 Jun 2015, Alexandru Petrescu wrote: > Resurecting an earlier discussion... > > I hear Apple just announced about mandating IPv6 in each app submitted to > store, and about a tech to offer IPv6 hotspots to app developpers on IPv4. > > Not sure that includes a CLAT implementation on iPhone, nor about what > kind of protocol spec can realize that IPv4-IPv6 behaviour (CLAT, > 64share, DS-MIP, NAT/NPT, any new?). http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/ If I were to guess from that article, it sounds like OSX will come with a mode where it can create an IPv6 only wifi, and then do DNS64+NAT64 towards an IPv4 only connection to the outside. If that is indeed the case, this is great, a lot more people will easily be able to test easily if their applications work well in a DNS64+NAT64 environment. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jun 10 06:49:31 2015 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 4A92F1B2A45 for ; Wed, 10 Jun 2015 06:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 XDUn1_X7w7Dq for ; Wed, 10 Jun 2015 06:49:29 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31711B2A44 for ; Wed, 10 Jun 2015 06:49:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5ADnQ6i014137; Wed, 10 Jun 2015 15:49:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1BC77204D89; Wed, 10 Jun 2015 15:52:02 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0678F203733; Wed, 10 Jun 2015 15:52:02 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5ADnPGM023705; Wed, 10 Jun 2015 15:49:26 +0200 Message-ID: <55784065.20208@gmail.com> Date: Wed, 10 Jun 2015 15:49:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <54EB1F2F.4000604@gmail.com> <557835FE.1020800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) 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, 10 Jun 2015 13:49:30 -0000 Le 10/06/2015 15:24, Mikael Abrahamsson a écrit : > On Wed, 10 Jun 2015, Alexandru Petrescu wrote: > >> Resurecting an earlier discussion... >> >> I hear Apple just announced about mandating IPv6 in each app submitted >> to store, and about a tech to offer IPv6 hotspots to app developpers >> on IPv4. >> >> Not sure that includes a CLAT implementation on iPhone, nor about what >> kind of protocol spec can realize that IPv4-IPv6 behaviour (CLAT, >> 64share, DS-MIP, NAT/NPT, any new?). > > http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/ > > > If I were to guess from that article, it sounds like OSX will come with > a mode where it can create an IPv6 only wifi, and then do DNS64+NAT64 > towards an IPv4 only connection to the outside. Would that use ULAs inside the IPv6-only WiFi? Would it use IPv6 NAT? I couldn't see otherwise. > If that is indeed the case, this is great, a lot more people will easily > be able to test easily if their applications work well in a DNS64+NAT64 > environment. I agree. Alex > From nobody Wed Jun 10 06:53:49 2015 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 DF8A41B2A35 for ; Wed, 10 Jun 2015 06:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cMpq8venOBMc for ; Wed, 10 Jun 2015 06:53:47 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BA11A0046 for ; Wed, 10 Jun 2015 06:53:47 -0700 (PDT) Received: by oihb142 with SMTP id b142so32505133oih.3 for ; Wed, 10 Jun 2015 06:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xDRpV1Cpx8p3DxVLPHbzGMCSqdBVke3mxS4MG2QvCrA=; b=VNQYfn0rdFUF3xTu0CjbVzt7a6onDfy198orqSZcy1dbPJSy6VADDhlbtVc4h566Bn XMXJmVjwy18Z6HhGjQGvwRU/mTOd4keDcHyQvUYmGOqmGTgawqPf4HANucPZexQpCDzx g1lSkkxrt24RWglm6RQrYSKcfk8WxOCeBydnfBSchYEUY3/vVVjFSuI+v5O0KnOeruXH 8JpiZo3U0tSqOYUGAjcXuxafI1VV8rq5b5EXImHM47J43eub3XZBA9jHjQgwA8ZuUqqu jlz1QGkTkr/WZyRq3eR1Rd5xzv4ObT5f+MyLhnMljhCDqcdAtrQ9F3ZL28+SGoAPZbDQ +igQ== 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:from:date :message-id:subject:to:cc:content-type; bh=xDRpV1Cpx8p3DxVLPHbzGMCSqdBVke3mxS4MG2QvCrA=; b=SIR7F5cZipl0kgENx+77FlUTxiWB4AxpgfOQlJ7nx6oSPWcgqOFRomayqbqnnIsVu3 ufGOCo2xwvrHRpqDzt8yPsdwtli71IngOViFHN13hmjqXASzRskWlre+VqXJ5RTU5RuG OxXEsizpQzGo2+ZvTb86lqey1BCqtY0hxp2lCYYz5mk1e6xStDOVHlWsy/cr6Kmz5hMb iC0NcskASNWBqkcuXSW9hmB9eYzo2AprB1pnI4vmxQGKClErKogvF8vnVfkSbtEAYwo0 sxwzZfOGb2pnQaX78y8Miv+c8VOQQlhyIKpnajmeiKXfRGymwnMBZGxo/Q8PJJvX1acK Q9TQ== X-Gm-Message-State: ALoCoQlG5vaBg8OerH6Agg4PXlOu+10nIg3xV59EDzM8sEbuqj1ZHdNKWhVMmtdyM2Rdt0EZzplb X-Received: by 10.202.61.70 with SMTP id k67mr2880930oia.88.1433944426496; Wed, 10 Jun 2015 06:53:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.134.198 with HTTP; Wed, 10 Jun 2015 06:53:25 -0700 (PDT) In-Reply-To: <55784065.20208@gmail.com> References: <54EB1F2F.4000604@gmail.com> <557835FE.1020800@gmail.com> <55784065.20208@gmail.com> From: Lorenzo Colitti Date: Wed, 10 Jun 2015 22:53:25 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a113cd5222b6b5005182a3435 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) 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, 10 Jun 2015 13:53:48 -0000 --001a113cd5222b6b5005182a3435 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 10, 2015 at 10:49 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Would that use ULAs inside the IPv6-only WiFi? > > Would it use IPv6 NAT? > > I couldn't see otherwise. It doesn't need to do IPv6 NAT (and it can't, unless it has an IPv6 upstream). It only needs to do NAT64. --001a113cd5222b6b5005182a3435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 10, 2015 at 10:49 PM, Alexandru Petrescu <alexandru.pet= rescu@gmail.com> wrote:
Wou= ld that use ULAs inside the IPv6-only=C2=A0 WiFi?

Would it use IPv6 NAT?

I couldn't see otherwise.

It doesn'= t need to do IPv6 NAT (and it can't, unless it has an IPv6 upstream). I= t only needs to do NAT64.
--001a113cd5222b6b5005182a3435-- From nobody Wed Jun 10 06:59:12 2015 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 3F7191B2A64 for ; Wed, 10 Jun 2015 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 gdV832SIKfmK for ; Wed, 10 Jun 2015 06:59:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD521B2A71 for ; Wed, 10 Jun 2015 06:59:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5ADx3tD021726; Wed, 10 Jun 2015 15:59:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 41DF920371D; Wed, 10 Jun 2015 16:01:39 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2A3F9200C38; Wed, 10 Jun 2015 16:01:39 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5ADx2Bv000661; Wed, 10 Jun 2015 15:59:03 +0200 Message-ID: <557842A6.9080609@gmail.com> Date: Wed, 10 Jun 2015 15:59:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <54EB1F2F.4000604@gmail.com> <557835FE.1020800@gmail.com> <55784065.20208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) 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, 10 Jun 2015 13:59:11 -0000 Le 10/06/2015 15:53, Lorenzo Colitti a écrit : > On Wed, Jun 10, 2015 at 10:49 PM, Alexandru Petrescu > > wrote: > > Would that use ULAs inside the IPv6-only WiFi? > > Would it use IPv6 NAT? > > I couldn't see otherwise. > > > It doesn't need to do IPv6 NAT (and it can't, unless it has an IPv6 > upstream). It only needs to do NAT64. Right, sorry. I dont see otherwise than NAT64, i.e. have an IPv4 address on one side and a ULA prefix on the other side. Alex From nobody Wed Jun 10 11:02:48 2015 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 90B041B33EC for ; Wed, 10 Jun 2015 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vNnkP7EIUQEd for ; Wed, 10 Jun 2015 11:02:45 -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 041681B33E9 for ; Wed, 10 Jun 2015 11:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1570; q=dns/txt; s=iport; t=1433959366; x=1435168966; h=from:to:subject:date:message-id:mime-version; bh=0siwW6l8ibl8OKGTQ7KZQYDhuKSFdxeHXM470V+P8H0=; b=GPa8O9TmKZkbyAfbj4lcUmNloe6/RnQN/Gmuy/ZN0p8LWW+yOTwvu199 sfkzHwootNADgAsgj/S4UT3xu+MC+Pvg7r4UA+gSfFuLSQhUnLjJJnJi1 SXUHwNm5gHomllolO67FJbNwZICaCyLOSPsAER2Q4aNvP4c7TDl4kpe14 I=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BQD/enhV/5hdJa1cgxABU18BBYMYum0JgVIPhzY4FAEBAQEBAQGBCoQpI2gBSgI0JwQhiCANnhaPX6QiAQEBAQYBAQEBAQEBG5M4L4EWBZNKghyBSWGGcAGBL0CSMINbJGKDFm+BRoEBAQEB X-IronPort-AV: E=Sophos; i="5.13,588,1427760000"; d="asc'?scan'208"; a="6145186" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jun 2015 18:02:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5AI2i5N016800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Jun 2015 18:02:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.34]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 10 Jun 2015 13:02:44 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: Heads up for IETF 93 Thread-Index: AQHQo6el0ug0aST15EGx1Jj7sFCizg== Date: Wed, 10 Jun 2015 18:02:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.198.122] Content-Type: multipart/signed; boundary="Apple-Mail=_22C99D63-7DFA-4346-AD59-63E436FB6DD2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Heads up for IETF 93 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, 10 Jun 2015 18:02:46 -0000 --Apple-Mail=_22C99D63-7DFA-4346-AD59-63E436FB6DD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The draft cut-off is about a month away: http://ietf.org/meeting/important-dates-2015.html#ietf93 =E2=80=A2 2015-07-06 (Monday): Internet Draft submission cut-off (for = all drafts, including -00) by UTC 23:59, upload using IETF ID Submission = Tool. If you're preparing a draft for discussion at the meeting, we need to = have it posted by that date, and we need supportive discussion on the = list to qualify it. So get your draft-yourname-v6ops-*-00.txt drafts = posted, and forward the draft notification (which you will receive and = v6ops won't) to the list inviting discussion. --Apple-Mail=_22C99D63-7DFA-4346-AD59-63E436FB6DD2 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 iQEVAwUBVXh7wZ9ieig10VPpAQITDQf/ZUP1Fqi7w68m5J/lmNwRLrE6eB4w1Gvk SiQ1+kbcAMq3t56UKZ2AMQhoPv8DkNSY0gc4FEt0Cj3l5eK8b8DH/+mjzZ2QkBaL 16S4UaRMZ+iDiPdBI7adWwaCwS7EOmYwcpZidSEm/PYDO5crbvkKn6qCegtwvtvu 8qU3uLc04Ql37J5pS04gZXahhCkj0NV3LJl3zxXonhaXRLri5v37Q5CfE1E1loMj QcV9oabNuBjEsWtkrxp6YQlYE/OH/Bukoomrmu4Gj3ZT8a9QAmlvV85wbxfFWqCo 8i+edir5ugHv99Lbhp+4pxAq3801ukBM45Oc4mxhNYwF+8p8fdz5kA== =0bDh -----END PGP SIGNATURE----- --Apple-Mail=_22C99D63-7DFA-4346-AD59-63E436FB6DD2-- From nobody Thu Jun 11 09:59:08 2015 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 F1CA21A8901 for ; Thu, 11 Jun 2015 09:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, 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 EnGS9aDFPQYH for ; Thu, 11 Jun 2015 09:59:04 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 990AE1A8852 for ; Thu, 11 Jun 2015 09:59:02 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 10A4F745DD; Thu, 11 Jun 2015 18:58:59 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id CEFB88B5; Thu, 11 Jun 2015 18:58:58 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 9D023C49F0; Thu, 11 Jun 2015 18:58:58 +0200 (CEST) Date: Thu, 11 Jun 2015 18:58:58 +0200 From: Enno Rey To: ipv6-wg@ripe.net Message-ID: <20150611165858.GT39827@ernw.de> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 11 Jun 2015 16:59:07 -0000 Eric, All, On Mon, May 18, 2015 at 06:07:45AM +0000, Eric Vyncke (evyncke) wrote: > Let me chime in ;-) > > On this topic, I am suffering of schizophrenia with a double personality... > > - security person: I hate when there are too many options and sub-options > and my usual recommendation is to use white list approach at the > destination (being plain layer-4 ACL or more content filtering) and at the > source (let's try to cut down covert channels): block unused ports, block > unused protocols (remember IP protocol 41), block unused extension headers > and drop everything which is not a normal IP packet (from address spoofing > to invalid EH chain). the problem here is the definition of "normal IP packet" as of RFC2460. To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets potentially crashing CRS-3 line cards: "The vulnerability is due to incorrect processing of an IPv6 packet carrying IPv6 extension headers that are valid but unlikely to be seen during normal operation. An attacker could exploit this vulnerability by sending such an IPv6 packet to an affected device that is configured to process IPv6 traffic. An exploit could allow the attacker to cause a reload of the line card, resulting in a DoS condition." two question come to mind here: - is a "valid but unlikely" extension header chain "normal"? - what ("combination of FW & IPS or whatever") would you put in front of a CRS? my (sad) expectation is that we'll see much more of these (types of) issues in the future. given the current level of freedom that the RFC2460 leaves (see also discussion/picture in http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/) "properly parsing an IPv6 packet, let alone in wire speed" seems a pretty much unsolvable task to me. That said I still fail to see any useful extension header besides AH&ESP (not even FH) to be transported in the Internet. best Enno If your firewall cannot implement this policy, then > it is time to change or to use a combination of FW & IPS or whatever. > > - network person: as I will live with IPv6 for the rest of my life, then I > want a way to extend it and I need any packet to travel to my source to my > destination. Any IPv6 packet should be able to traverse the > Internet/private network as long as its layer-3 header is valid > (filtering/dropping can be done exceptionally for good operational > reason). Did we remember the IPv4 teardrop attack? It is blocked by > default by most routers for years ;-) > > Bugs will plague us for ever... And make our life more complex than the > above description of course ;-) > > -??ric > > On 17/05/15 20:43, "Silvia Hagen" wrote: > > >Hi > > > >I keep stumbling about that "recommendational wording" in RFC 2460 > >everytime I teach it. > > > >Couldn't we update RFC2460 and make this list a strict order? > > > >I would want my firewall to notify me if the EHs in a packet do not > >follow the list. > >And limiting the number of possible EHs per packet might be a good idea. > > > >Silvia > > > >-----Urspr??ngliche Nachricht----- > >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt > >Stockebrand > >Gesendet: Sonntag, 17. Mai 2015 18:39 > >An: ipv6-wg@ripe.net > >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > > > >Hi Enno and list, > > > >Enno Rey writes: > > > >> hope everybody had a great #RIPE70 meeting. We did! > >> Many thanks to the organizers and chairs! > > > >and thanks to the actual speakers as well the speakers we had to turn > >down due to time constraints, too:-) > > > >> If the chairs consider this appropriate we will happily give a > >> presentation on this stuff in Bucharest or at another occasion. > > > >Sounds good to me! > > > >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > >> their number, order[...] > > > >Actually, as far as I'm concerned that's the real core of the problem. > >Or more specifically, the first two lines of RFC 2460, section 4.1: > > > > When more than one extension header is used in the same packet, it is > > recommended that those headers appear in the following order: > > > >followed on the next page by > > > > Each extension header should occur at most once, except for the > > Destination Options header which should occur at most twice (once > > before a Routing header and once before the upper-layer header). > > > >Note in particular that these are not even RFC 2119 "SHOULD" or > >"RECOMMENDED" and such. > > > >The impact here is actually at least twofold: > > > >- It is impossible to implement this as a simple pipeline architecture > > in hardware; at least for cases deviating from the "recommendations" > > above this effectively becomes either excessively complex to implement > > in hardware or an invitation to DoS when implemented in software on an > > otherwise hardware router. > > > >- As I understand it, at least some of the issues you have found are > > effectively based on violating the second paragraph quoted, making it > > impossible to come up with a lower bound on how long the header chain > > can actually get and therefore leading to the fragmentation related > > attacks and similar you have discovered. > > > >The original idea was that the extension headers are processed strictly > >in the order they occur, so one question to ask is if there is any valid > >reason to violate these "recommendations" for other than malicious > >purposes. > > > > > >Cheers, > > > > Benedikt > > > >-- > >Benedikt Stockebrand, Stepladder IT Training+Consulting > >Dipl.-Inform. http://www.stepladder-it.com/ > > > > Business Grade IPv6 --- Consulting, Training, Projects > > > >BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > > > > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Sun Jun 14 11:00:07 2015 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 24C3B1B307B for ; Sun, 14 Jun 2015 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 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, T_RP_MATCHES_RCVD=-0.01, 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 djz-D-D35V9p for ; Sun, 14 Jun 2015 11:00:05 -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 DDC901B3073 for ; Sun, 14 Jun 2015 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=622; q=dns/txt; s=iport; t=1434304804; x=1435514404; h=date:from:message-id:to:subject:cc; bh=ibxusZpVHOa9myXKN8JbGFcIghpxi/bHeSiJZgRv+gk=; b=IVJ2EziC9Evz4aoSwyVlUwf1UomVBY38T/Zuh3CIfFuMGYNq8Tr0hV2+ zMC0Zffo7E/3Jpd7YrLfXvegSn2doCjwtpW5w5x30+/eqeUBstG1+KiA5 IRakbzxjLC5FSx3qZtwkUNl1xmhir/57EgtjMRhB8XLzMQfObKrmfA/qu M=; X-IronPort-AV: E=Sophos;i="5.13,614,1427760000"; d="scan'208";a="159156708" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 14 Jun 2015 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5EI036X031941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jun 2015 18:00:04 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 t5EI03H2016999; Sun, 14 Jun 2015 11:00:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t5EI02ol016995; Sun, 14 Jun 2015 11:00:02 -0700 Date: Sun, 14 Jun 2015 11:00:02 -0700 From: fred@cisco.com Message-Id: <201506141800.t5EI02ol016995@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-siit-eam 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, 14 Jun 2015 18:00:06 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-siit-eam. 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 Mon Jun 15 04:26:53 2015 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 1C6FB1B2B96 for ; Mon, 15 Jun 2015 04:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 OFfFqCzjzUEG for ; Mon, 15 Jun 2015 04:26:49 -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 B0C901AD186 for ; Mon, 15 Jun 2015 04:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1434367610; x=1435577210; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GCBYm1L1IWmr8+2WIjSDIipGvWzzS0Rk2Jid4hKc26E=; b=H0ypHYoMQeZb4yPb0qkSifTp0hzTIU7duM1j1AsvsOgml7ypQIUXNc6N hbcYrpQX4QHQ56h8ywQ1jSs19RbkATUErXnb6u8QrTit/2TZdUjmJek4B MBdDTY505V6WDqOTCZiu7tPhWjces8FrXHAIi9NiWrQyR4wwtLuctK6Ta Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnBAAetn5V/4QNJK1cgxBUXwa9WgmBVwqFegKBMjgUAQEBAQEBAYEKhCIBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCIgnDclwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLRIRVOAaDEYEWBZNbAYx0hASDBYt5g1smY4MWb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,618,1427760000"; d="scan'208";a="159396448" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 15 Jun 2015 11:26:49 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5FBQmZh001322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jun 2015 11:26:48 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 06:26:48 -0500 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-siit-eam WGLC Thread-Index: AQHQpsv6CmFF/Tc6RUKsJ+zURc6D2Z2tbV8g Date: Mon, 15 Jun 2015 11:26:48 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168A5B92@xmb-rcd-x06.cisco.com> References: <201506141800.t5EI02ol016995@irp-lnx1.cisco.com> In-Reply-To: <201506141800.t5EI02ol016995@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam 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, 15 Jun 2015 11:26:51 -0000 Tore/Alberto, At the end of the A.1 section you have text that says "Note that this is th= e exact opposite of the SIIT-DC use case". At the end of the A.3 section y= ou have text that says "Note that this is the exact opposite of the 464XLA= T use case". It's not clear to me what is "opposite" referring to. Do you even need th= ese two sentences in the document? Thanks, Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Sunday, June 14, 2015 2:00 PM To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-siit-eam WGLC This is to initiate a two week working group last call of http://tools.ietf= .org/html/draft-ietf-v6ops-siit-eam. =20 Please read it now. If you find nits (spelling errors, minor suggested word= ing 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. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jun 15 05:03:57 2015 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 478C21B2C10 for ; Mon, 15 Jun 2015 05:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 RpP-P6Ratzy4 for ; Mon, 15 Jun 2015 05:03:55 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE9B1B2C0F for ; Mon, 15 Jun 2015 05:03:55 -0700 (PDT) Received: from [2a02:2121:8e:660:0:3:f793:8501] (port=51744 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z4T7H-0004jK-Ni; Mon, 15 Jun 2015 14:03:51 +0200 Date: Mon, 15 Jun 2015 14:03:50 +0200 From: Tore Anderson To: "Hemant Singh (shemant)" Message-ID: <20150615140350.17d819fe@envy.fud.no> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89168A5B92@xmb-rcd-x06.cisco.com> References: <201506141800.t5EI02ol016995@irp-lnx1.cisco.com> <75B6FA9F576969419E42BECB86CB1B89168A5B92@xmb-rcd-x06.cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam 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, 15 Jun 2015 12:03:57 -0000 Hi Hemant, * Hemant Singh (shemant) > At the end of the A.1 section you have text that says "Note that this > is the exact opposite of the SIIT-DC use case". At the end of the > A.3 section you have text that says "Note that this is the exact > opposite of the 464XLAT use case". > > It's not clear to me what is "opposite" referring to. The use cases are opposite to each other, e.g.: - A.1 (464XLAT) is opposite to A.3 (SIIT-DC) - A.3 (SIIT-DC) is opposite to A.1 (464XLAT) ...in the sense that an IPv4 packet traversing a 464XLAT CLAT and being tranlated to IPv6 is sent by a local IPv4 app and is destined for the public Internet, while an IPv4 packet traversing an SIIT-DC gateway is sent from the public Internet and is destined for a local IPv4 service. > Do you even need these two sentences in the document? No, probably not. We'll remove them, thanks! Tore From nobody Mon Jun 15 07:24:26 2015 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 C821C1B2DE1 for ; Mon, 15 Jun 2015 07:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 xsLaBCghcisW for ; Mon, 15 Jun 2015 07:24:23 -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 47FE31B2DE7 for ; Mon, 15 Jun 2015 07:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1315; q=dns/txt; s=iport; t=1434378178; x=1435587778; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2CdFUseS1/wm4fYdUFbW0d0El0yLE3N31b8JWO2xRm4=; b=DhZx0EJqEwDfomK3JcN8JFGgll6SU1jbUSUHpOm4m9Ax3yHWUcY/lF4a +zUOTLuDa3UjHee1soGcmfG9GaYwRvVVSWuvf4pCJMMcK0DXyESoH7h2U oA9mPR3t/G2hIJ23uns+xDNtCfaYDwy36oag/LuxNGCpwR0mK5kn90jKi w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BpBADs3n5V/40NJK1cgxCBMwa9XgmHWQKBNTgUAQEBAQEBAYEKhCIBAQEDATo/BQcEAgEIEQQBAQsUCQcyFAkIAgQOBQiIHwjKXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLRIRVMQcGgxGBFgEEk1sBo1EmY4MWb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,618,1427760000"; d="scan'208";a="159601982" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2015 14:22:57 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5FEMuUd008425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 14:22:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 09:22:56 -0500 From: "Hemant Singh (shemant)" To: Tore Anderson Thread-Topic: [v6ops] draft-ietf-v6ops-siit-eam WGLC Thread-Index: AQHQpsv6CmFF/Tc6RUKsJ+zURc6D2Z2tbV8ggABfiQD//9LEsA== Date: Mon, 15 Jun 2015 14:22:55 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168A5C9B@xmb-rcd-x06.cisco.com> References: <201506141800.t5EI02ol016995@irp-lnx1.cisco.com> <75B6FA9F576969419E42BECB86CB1B89168A5B92@xmb-rcd-x06.cisco.com> <20150615140350.17d819fe@envy.fud.no> In-Reply-To: <20150615140350.17d819fe@envy.fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam 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, 15 Jun 2015 14:24:25 -0000 Tore, Thanks for the explanation - got it. Sounds good to remove the statements.= Other than that, the document looks good to me.=20 Thanks, Hemant -----Original Message----- From: Tore Anderson [mailto:tore@fud.no]=20 Sent: Monday, June 15, 2015 8:04 AM To: Hemant Singh (shemant) Cc: Fred Baker (fred); v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam WGLC Hi Hemant, * Hemant Singh (shemant) > At the end of the A.1 section you have text that says "Note that this=20 > is the exact opposite of the SIIT-DC use case". At the end of the > A.3 section you have text that says "Note that this is the exact=20 > opposite of the 464XLAT use case". >=20 > It's not clear to me what is "opposite" referring to. The use cases are opposite to each other, e.g.: - A.1 (464XLAT) is opposite to A.3 (SIIT-DC) - A.3 (SIIT-DC) is opposite to A.1 (464XLAT) ...in the sense that an IPv4 packet traversing a 464XLAT CLAT and being tra= nlated to IPv6 is sent by a local IPv4 app and is destined for the public I= nternet, while an IPv4 packet traversing an SIIT-DC gateway is sent from th= e public Internet and is destined for a local IPv4 service. > Do you even need these two sentences in the document? No, probably not. We'll remove them, thanks! Tore From nobody Mon Jun 15 15:16:03 2015 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 B555E1B2C91 for ; Mon, 15 Jun 2015 15:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.811 X-Spam-Level: X-Spam-Status: No, score=-13.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 p_lk6ZM0m57l for ; Mon, 15 Jun 2015 15:15:59 -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 12F6C1B2C8F for ; Mon, 15 Jun 2015 15:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11472; q=dns/txt; s=iport; t=1434406559; x=1435616159; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IHLPNzQLgdbiR3tJN70asxfXNOGTuzs8dwalyw0eqag=; b=UmXu89EZ3h7m/ROY5xX1Ma25o17GuDIeHZyjf+tHi7UuJNnMz3/ZsW94 J+Y1jnxTBz32pXm88AauSx5+LOUYWK4Be5VZqDL89zTr628hMxhKgNm76 GzfACQKMycZnZZFT755jWmyQzp6iZLSXdPIi7Osy5qPotO5sx+t4uY/ho 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BKBQA6Tn9V/5ldJa1VBoMQVF8Ggxi8MAyCQoM0AhyBHjsRAQEBAQEBAYEKhCMBAQQBAQEgERUfBgsQAgEIDgQGAgIjAwICAiULFAECDgIEAQ0FGQOIEw21RJZdAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiSGBAoRDKBsHgmiBRQWGe4xgAYUxgXOEHYEzhwmHWIQhg1smggscgVJvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,621,1427760000"; d="scan'208";a="159736298" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 15 Jun 2015 22:15:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5FMFbFq023800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 22:15:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 17:15:37 -0500 From: "Eric Vyncke (evyncke)" To: Enno Rey , "ipv6-wg@ripe.net" Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQpGf5Wn5pwe9fwkWXgHffM0Q9gZ2unjGA Date: Mon, 15 Jun 2015 22:15:36 +0000 Message-ID: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> In-Reply-To: <20150611165858.GT39827@ernw.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.60.138.40] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 15 Jun 2015 22:16:01 -0000 RW5ubywNCg0KQXMgeW91IHByb2JhYmx5IGtub3csIENpc2NvIGhhbmRsZXMgUFNJUlQgaXNzdWVz IHdpdGggY2FyZSwgc28sIEkgaGF2ZSBubw0KY2x1ZSBvbiB0aGlzIHNwZWNpZmljIGFkdmlzb3J5 LiBNeSBvd24gKGVkdWNhdGVkKSBndWVzcyBpcyB0aGF0IHRoZSBwYWNrZXQNCmNhdXNpbmcgYSBM QyByZWxvYWQgaXMgZnVsbHkgUkZDIDI0NjAgY29tcGxpYW50IGJ1dCB1bnVzdWFsLCBzbywgcHJv YmFibHkNCihhIGd1ZXNzIGFnYWluKSBhIGNvbWJpbmF0aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJz IHRyaWdnZXJpbmcgYSBidWcuDQoNCkluIHRoaXMgc3BlY2lmaWMgY2FzZSwgSSB3b3VsZCBub3Qg YmxhbWUgSVB2NiBvciBSRkMgMjQ2MCBidXQgcmF0aGVyIG15DQpvd24gY29tcGFueSAoZXZlbiBp ZiB0aGUgYWZmZWN0ZWQgdmVyc2lvbnMgd2VyZSBxdWl0ZSBvbGQgYXMgbmV3IElPUy1YUg0KdmVy c2lvbnMgYXBwZWFyIHRvIGJlIGltbXVuZSB0byB0aGlzIGJ1ZykuIEFuZCBJIGFwcHJlY2lhdGUg dGhlIGh1bW9yIGluDQp5b3VyIHJoZXRvcmljYWwgcXVlc3Rpb24gYWJvdXQgd2hpY2ggRlcgY291 bGQgcHJvdGVjdCBhIENSUy4uLiBBaXIgZ2FwDQpwcm9iYWJseSA6LSkNCg0KTW9yZSBnZW5lcmFs bHksIHJlZ2FyZGluZyB0aGUgJ3BhcnNpbmcgb2YgdGhlIGhlYWRlcicgYW5kIHBlcmZvcm1hbmNl LCBteQ0KdW5kZXJzdGFuZGluZyAoYW5kIEkgYW0gTk9UIGEgSFcgZW5naW5lZXIpIGlzIHRoYXQg dGhlcmUgYXJlIG11bHRpcGxlIHdheXMNCnRvIHBhcnNlIHRoZSBoZWFkZXIgY2hhaW46DQotIHB1 cmVseSBzb2Z0d2FyZSBpbiBsb3ctZW5kIGRldmljZXMsIHNob3VsZCBoYXZlIGEgbWFyZ2luYWwg cGVyZm9ybWFuY2UNCmltcGFjdA0KLSBzcGVjaWZpYyBBU0lDIGluIG1pZGRsZS1lbmQgZGV2aWNl cyAocmVhZCBoaWdoIGVuZCBlbnRlcnByaXNlKSwgcHJvYmFibHkNCnNvbWUgbGltaXRhdGlvbnMg YW5kIGhlYXZ5IHBlcmZvcm1hbmNlIGltcGFjdCAoYnV0IGFnYWluIHdpdGhpbiBvbmUNCm9yZ2Fu aXphdGlvbiwgc28sIGVhc2llciB0byBmaXggdGhlIHJvb3QgY2F1c2UpDQotIGEgbG90IG9mIHNw ZWNpYWxpemVkIG5ldHdvcmsgcHJvY2Vzc29ycyBpbiBoaWdoLWVuZCBkZXZpY2VzIChTUCBnZWFy cyksDQp3aGljaCBpcyBhIHNpbWlsYXIgY2FzZSBhcyB0aGUgJ2xvdy1lbmQgZGV2aWNlJywgcGVy Zm9ybWFuY2UgaW1wYWN0IGJ1dA0KbWFyZ2luYWwgYXMgcGFyc2luZyB0aGUgY2hhaW4gb2YgaGVh ZGVycyBpcyBub3QgdGhhdCBoYXJkIGFmdGVyIGFsbCBfd2hlbl8NCmNvZGVkIGNvcnJlY3RseQ0K DQpBcyB0aGUgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIHNwZWNpZmljIHRvIElQdjYsIHRoaXMgaXMg YW4gYXJlYSB3aGVuIHdlDQp3aWxsIGFsbCBsZWFybiAoYW5kIGhhdmUgbGVhcm5lZCBhbHJlYWR5 KSBhIGxvdCBvZiB0aGluZ3MuLi4NCg0KSSByZXNwZWN0ZnVsbHkgZGlzYWdyZWUgd2l0aCB5b3Vy IGxhc3Qgc2VudGVuY2UuIE9mIGNvdXJzZSwgZGVzdGluYXRpb24NCkFTL2hvc3QgU0hPVUxEIG9u bHkgYWNjZXB0IHVzZWZ1bCwga25vd24gYW5kIGxlZ2l0IGV4dCBoZWFkZXJzOyBidXQsIHdoeQ0K d291bGQgYW4gSVNQIGZpbHRlciBvbiBleHQgaGVhZGVycyBpZiB0aGV5IGRvIG5vdCBoYXJtIHRo ZWlyIG93biBpbmZyYSBvcg0KYSBjdXN0b21lciBpbmZyYT8gRG8geW91IGVudmlzaW9uIGFuIElu dGVybmV0IHdoZXJlIG9ubHkgVENQLzQ0MyBhbmQNClVEUC80MyB3b3VsZCBiZSBhY2NlcHRlZD8N Cg0KTGFzdCBwb2ludCwgdGhlIEludGVybmV0IHdpbGwgaGF2ZSB0byB1c2UgSVB2NiBmb3IgMTAg b3IgMjAgeWVhcnMgYXQNCmxlYXN0LiBJZiB0aGUgSUVURi9JU1AgYmxvY2sgYWxsIG5ldyBfb3B0 aW9uc18gaW4gX2V4aXN0aW5nXyBleHRlbnNpb24NCmhlYWRlcnMsIHRoZW4gd2Ugd2lsbCBiZSBz dHVjayBpbiAxOTk3IGZvciBuZXR3b3JrIGlubm92YXRpb24uIFdoaWxlIEkgZG8NCm5vdCBsaWtl IHRha2luZyBzZWN1cml0eSByaXNrcywgSSBldmVuIGZlYXIgbW9yZSB0aGUgbGFjayBvZiBpbm5v dmF0aW9uLg0KDQpMZXQncyB0YWxrIG9uIFRodXJzZGF5IGF0IFNpbHZpYSdzIElQdjYgQ29uZmVy ZW5jZSBpbiBadXJpY2ggOy0pDQoNCi3DqXJpYw0KDQpPbiAxMS8wNi8xNSAxMTo1OCwgIkVubm8g UmV5IiA8ZXJleUBlcm53LmRlPiB3cm90ZToNCj4NCj50aGUgcHJvYmxlbSBoZXJlIGlzIHRoZSBk ZWZpbml0aW9uIG9mICJub3JtYWwgSVAgcGFja2V0IiBhcyBvZiBSRkMyNDYwLg0KPlRvIGlsbHVz dHJhdGUgdGhpcyBJIGp1c3QgcXVvdGUgZnJvbSB0b2RheSdzIENpc2NvIGFkdmlzb3J5IChDaXNj byBJT1MgWFINCj5Tb2Z0d2FyZSBDcmFmdGVkIElQdjYgUGFja2V0IERlbmlhbCBvZiBTZXJ2aWNl IFZ1bG5lcmFiaWxpdHkpIG9uIHBhY2tldHMNCj5wb3RlbnRpYWxseSBjcmFzaGluZyBDUlMtMyBs aW5lIGNhcmRzOg0KPg0KPiJUaGUgdnVsbmVyYWJpbGl0eSBpcyBkdWUgdG8gaW5jb3JyZWN0IHBy b2Nlc3Npbmcgb2YgYW4gSVB2NiBwYWNrZXQNCj5jYXJyeWluZyBJUHY2IGV4dGVuc2lvbiBoZWFk ZXJzIHRoYXQgYXJlIHZhbGlkIGJ1dCB1bmxpa2VseSB0byBiZSBzZWVuDQo+ZHVyaW5nIG5vcm1h bCBvcGVyYXRpb24uIEFuIGF0dGFja2VyIGNvdWxkIGV4cGxvaXQgdGhpcyB2dWxuZXJhYmlsaXR5 IGJ5DQo+c2VuZGluZyBzdWNoIGFuIElQdjYgcGFja2V0IHRvIGFuIGFmZmVjdGVkIGRldmljZSB0 aGF0IGlzIGNvbmZpZ3VyZWQgdG8NCj5wcm9jZXNzIElQdjYgdHJhZmZpYy4gQW4gZXhwbG9pdCBj b3VsZCBhbGxvdyB0aGUgYXR0YWNrZXIgdG8gY2F1c2UgYQ0KPnJlbG9hZCBvZiB0aGUgbGluZSBj YXJkLCByZXN1bHRpbmcgaW4gYSBEb1MgY29uZGl0aW9uLiINCj4NCj50d28gcXVlc3Rpb24gY29t ZSB0byBtaW5kIGhlcmU6DQo+DQo+LSBpcyBhICJ2YWxpZCBidXQgdW5saWtlbHkiIGV4dGVuc2lv biBoZWFkZXIgY2hhaW4gIm5vcm1hbCI/DQo+LSB3aGF0ICgiY29tYmluYXRpb24gb2YgRlcgJiBJ UFMgb3Igd2hhdGV2ZXIiKSB3b3VsZCB5b3UgcHV0IGluIGZyb250IG9mDQo+YSBDUlM/DQo+DQo+ bXkgKHNhZCkgZXhwZWN0YXRpb24gaXMgdGhhdCB3ZSdsbCBzZWUgbXVjaCBtb3JlIG9mIHRoZXNl ICh0eXBlcyBvZikNCj5pc3N1ZXMgaW4gdGhlIGZ1dHVyZS4gZ2l2ZW4gdGhlIGN1cnJlbnQgbGV2 ZWwgb2YgZnJlZWRvbSB0aGF0IHRoZSBSRkMyNDYwDQo+bGVhdmVzIChzZWUgYWxzbyBkaXNjdXNz aW9uL3BpY3R1cmUgaW4NCj5odHRwOi8vd3d3Lmluc2ludWF0b3IubmV0LzIwMTUvMDYvaXMtaXB2 Ni1tb3JlLXNlY3VyZS10aGFuLWlwdjQtb3ItbGVzcy8pDQo+InByb3Blcmx5IHBhcnNpbmcgYW4g SVB2NiBwYWNrZXQsIGxldCBhbG9uZSBpbiB3aXJlIHNwZWVkIiBzZWVtcyBhIHByZXR0eQ0KPm11 Y2ggdW5zb2x2YWJsZSB0YXNrIHRvIG1lLg0KPg0KPlRoYXQgc2FpZCBJIHN0aWxsIGZhaWwgdG8g c2VlIGFueSB1c2VmdWwgZXh0ZW5zaW9uIGhlYWRlciBiZXNpZGVzIEFIJkVTUA0KPihub3QgZXZl biBGSCkgdG8gYmUgdHJhbnNwb3J0ZWQgaW4gdGhlIEludGVybmV0Lg0KPg0KPmJlc3QNCj4NCj5F bm5vDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IElmIHlvdXIgZmlyZXdhbGwgY2Fubm90IGltcGxl bWVudCB0aGlzIHBvbGljeSwgdGhlbg0KPj4gaXQgaXMgdGltZSB0byBjaGFuZ2Ugb3IgdG8gdXNl IGEgY29tYmluYXRpb24gb2YgRlcgJiBJUFMgb3Igd2hhdGV2ZXIuDQo+PiANCj4+IC0gbmV0d29y ayBwZXJzb246IGFzIEkgd2lsbCBsaXZlIHdpdGggSVB2NiBmb3IgdGhlIHJlc3Qgb2YgbXkgbGlm ZSwNCj4+dGhlbiBJDQo+PiB3YW50IGEgd2F5IHRvIGV4dGVuZCBpdCBhbmQgSSBuZWVkIGFueSBw YWNrZXQgdG8gdHJhdmVsIHRvIG15IHNvdXJjZSB0bw0KPj5teQ0KPj4gZGVzdGluYXRpb24uIEFu eSBJUHY2IHBhY2tldCBzaG91bGQgYmUgYWJsZSB0byB0cmF2ZXJzZSB0aGUNCj4+IEludGVybmV0 L3ByaXZhdGUgbmV0d29yayBhcyBsb25nIGFzIGl0cyBsYXllci0zIGhlYWRlciBpcyB2YWxpZA0K Pj4gKGZpbHRlcmluZy9kcm9wcGluZyBjYW4gYmUgZG9uZSBleGNlcHRpb25hbGx5IGZvciBnb29k IG9wZXJhdGlvbmFsDQo+PiByZWFzb24pLiBEaWQgd2UgcmVtZW1iZXIgdGhlIElQdjQgdGVhcmRy b3AgYXR0YWNrPyBJdCBpcyBibG9ja2VkIGJ5DQo+PiBkZWZhdWx0IGJ5IG1vc3Qgcm91dGVycyBm b3IgeWVhcnMgOy0pDQo+PiANCj4+IEJ1Z3Mgd2lsbCBwbGFndWUgdXMgZm9yIGV2ZXIuLi4gQW5k IG1ha2Ugb3VyIGxpZmUgbW9yZSBjb21wbGV4IHRoYW4gdGhlDQo+PiBhYm92ZSBkZXNjcmlwdGlv biBvZiBjb3Vyc2UgOy0pDQo+PiANCj4+IC0/P3JpYw0KPj4gDQo+PiBPbiAxNy8wNS8xNSAyMDo0 MywgIlNpbHZpYSBIYWdlbiIgPHNpbHZpYS5oYWdlbkBzdW5ueS5jaD4gd3JvdGU6DQo+PiANCj4+ ID5IaQ0KPj4gPg0KPj4gPkkga2VlcCBzdHVtYmxpbmcgYWJvdXQgdGhhdCAicmVjb21tZW5kYXRp b25hbCB3b3JkaW5nIiBpbiBSRkMgMjQ2MA0KPj4gPmV2ZXJ5dGltZSBJIHRlYWNoIGl0Lg0KPj4g Pg0KPj4gPkNvdWxkbid0IHdlIHVwZGF0ZSBSRkMyNDYwIGFuZCBtYWtlIHRoaXMgbGlzdCBhIHN0 cmljdCBvcmRlcj8NCj4+ID4NCj4+ID5JIHdvdWxkIHdhbnQgbXkgZmlyZXdhbGwgdG8gbm90aWZ5 IG1lIGlmIHRoZSBFSHMgaW4gYSBwYWNrZXQgZG8gbm90DQo+PiA+Zm9sbG93IHRoZSBsaXN0Lg0K Pj4gPkFuZCBsaW1pdGluZyB0aGUgbnVtYmVyIG9mIHBvc3NpYmxlIEVIcyBwZXIgcGFja2V0IG1p Z2h0IGJlIGEgZ29vZA0KPj5pZGVhLg0KPj4gPg0KPj4gPlNpbHZpYQ0KPj4gPg0KPj4gPi0tLS0t VXJzcHI/P25nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4+ID5Wb246IGlwdjYtd2cgW21haWx0bzpp cHY2LXdnLWJvdW5jZXNAcmlwZS5uZXRdIEltIEF1ZnRyYWcgdm9uIEJlbmVkaWt0DQo+PiA+U3Rv Y2tlYnJhbmQNCj4+ID5HZXNlbmRldDogU29ubnRhZywgMTcuIE1haSAyMDE1IDE4OjM5DQo+PiA+ QW46IGlwdjYtd2dAcmlwZS5uZXQNCj4+ID5CZXRyZWZmOiBSZTogW2lwdjYtd2ddIEV4dGVuc2lv biBIZWFkZXJzIC8gSW1wYWN0IG9uIFNlY3VyaXR5IERldmljZXMNCj4+ID4NCj4+ID5IaSBFbm5v IGFuZCBsaXN0LA0KPj4gPg0KPj4gPkVubm8gUmV5IDxlcmV5QGVybncuZGU+IHdyaXRlczoNCj4+ ID4NCj4+ID4+IGhvcGUgZXZlcnlib2R5IGhhZCBhIGdyZWF0ICNSSVBFNzAgbWVldGluZy4gV2Ug ZGlkIQ0KPj4gPj4gTWFueSB0aGFua3MgdG8gdGhlIG9yZ2FuaXplcnMgYW5kIGNoYWlycyENCj4+ ID4NCj4+ID5hbmQgdGhhbmtzIHRvIHRoZSBhY3R1YWwgc3BlYWtlcnMgYXMgd2VsbCB0aGUgc3Bl YWtlcnMgd2UgaGFkIHRvIHR1cm4NCj4+ID5kb3duIGR1ZSB0byB0aW1lIGNvbnN0cmFpbnRzLCB0 b286LSkNCj4+ID4NCj4+ID4+IElmIHRoZSBjaGFpcnMgY29uc2lkZXIgdGhpcyBhcHByb3ByaWF0 ZSB3ZSB3aWxsIGhhcHBpbHkgZ2l2ZSBhDQo+PiA+PiBwcmVzZW50YXRpb24gb24gdGhpcyBzdHVm ZiBpbiBCdWNoYXJlc3Qgb3IgYXQgYW5vdGhlciBvY2Nhc2lvbi4NCj4+ID4NCj4+ID5Tb3VuZHMg Z29vZCB0byBtZSENCj4+ID4NCj4+ID4+IC0gbG9va2luZyBhdCB0aGUgImxpYmVydHkiIFJGQzI0 NjAgcHJvdmlkZXMgYXMgZm9yIGV4dF9oZHJzICh3cnQgdG8NCj4+ID4+IHRoZWlyIG51bWJlciwg b3JkZXJbLi4uXQ0KPj4gPg0KPj4gPkFjdHVhbGx5LCBhcyBmYXIgYXMgSSdtIGNvbmNlcm5lZCB0 aGF0J3MgdGhlIHJlYWwgY29yZSBvZiB0aGUgcHJvYmxlbS4NCj4+ID5PciBtb3JlIHNwZWNpZmlj YWxseSwgdGhlIGZpcnN0IHR3byBsaW5lcyBvZiBSRkMgMjQ2MCwgc2VjdGlvbiA0LjE6DQo+PiA+ DQo+PiA+ICAgV2hlbiBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBoZWFkZXIgaXMgdXNlZCBpbiB0 aGUgc2FtZSBwYWNrZXQsIGl0DQo+PmlzDQo+PiA+ICAgcmVjb21tZW5kZWQgdGhhdCB0aG9zZSBo ZWFkZXJzIGFwcGVhciBpbiB0aGUgZm9sbG93aW5nIG9yZGVyOg0KPj4gPg0KPj4gPmZvbGxvd2Vk IG9uIHRoZSBuZXh0IHBhZ2UgYnkNCj4+ID4NCj4+ID4gICBFYWNoIGV4dGVuc2lvbiBoZWFkZXIg c2hvdWxkIG9jY3VyIGF0IG1vc3Qgb25jZSwgZXhjZXB0IGZvciB0aGUNCj4+ID4gICBEZXN0aW5h dGlvbiBPcHRpb25zIGhlYWRlciB3aGljaCBzaG91bGQgb2NjdXIgYXQgbW9zdCB0d2ljZSAob25j ZQ0KPj4gPiAgIGJlZm9yZSBhIFJvdXRpbmcgaGVhZGVyIGFuZCBvbmNlIGJlZm9yZSB0aGUgdXBw ZXItbGF5ZXIgaGVhZGVyKS4NCj4+ID4NCj4+ID5Ob3RlIGluIHBhcnRpY3VsYXIgdGhhdCB0aGVz ZSBhcmUgbm90IGV2ZW4gUkZDIDIxMTkgIlNIT1VMRCIgb3INCj4+ID4iUkVDT01NRU5ERUQiIGFu ZCBzdWNoLg0KPj4gPg0KPj4gPlRoZSBpbXBhY3QgaGVyZSBpcyBhY3R1YWxseSBhdCBsZWFzdCB0 d29mb2xkOg0KPj4gPg0KPj4gPi0gSXQgaXMgaW1wb3NzaWJsZSB0byBpbXBsZW1lbnQgdGhpcyBh cyBhIHNpbXBsZSBwaXBlbGluZSBhcmNoaXRlY3R1cmUNCj4+ID4gIGluIGhhcmR3YXJlOyBhdCBs ZWFzdCBmb3IgY2FzZXMgZGV2aWF0aW5nIGZyb20gdGhlICJyZWNvbW1lbmRhdGlvbnMiDQo+PiA+ ICBhYm92ZSB0aGlzIGVmZmVjdGl2ZWx5IGJlY29tZXMgZWl0aGVyIGV4Y2Vzc2l2ZWx5IGNvbXBs ZXggdG8NCj4+aW1wbGVtZW50DQo+PiA+ICBpbiBoYXJkd2FyZSBvciBhbiBpbnZpdGF0aW9uIHRv IERvUyB3aGVuIGltcGxlbWVudGVkIGluIHNvZnR3YXJlIG9uDQo+PmFuDQo+PiA+ICBvdGhlcndp c2UgaGFyZHdhcmUgcm91dGVyLg0KPj4gPg0KPj4gPi0gQXMgSSB1bmRlcnN0YW5kIGl0LCBhdCBs ZWFzdCBzb21lIG9mIHRoZSBpc3N1ZXMgeW91IGhhdmUgZm91bmQgYXJlDQo+PiA+ICBlZmZlY3Rp dmVseSBiYXNlZCBvbiB2aW9sYXRpbmcgdGhlIHNlY29uZCBwYXJhZ3JhcGggcXVvdGVkLCBtYWtp bmcgaXQNCj4+ID4gIGltcG9zc2libGUgdG8gY29tZSB1cCB3aXRoIGEgbG93ZXIgYm91bmQgb24g aG93IGxvbmcgdGhlIGhlYWRlciBjaGFpbg0KPj4gPiAgY2FuIGFjdHVhbGx5IGdldCBhbmQgdGhl cmVmb3JlIGxlYWRpbmcgdG8gdGhlIGZyYWdtZW50YXRpb24gcmVsYXRlZA0KPj4gPiAgYXR0YWNr cyBhbmQgc2ltaWxhciB5b3UgaGF2ZSBkaXNjb3ZlcmVkLg0KPj4gPg0KPj4gPlRoZSBvcmlnaW5h bCBpZGVhIHdhcyB0aGF0IHRoZSBleHRlbnNpb24gaGVhZGVycyBhcmUgcHJvY2Vzc2VkIHN0cmlj dGx5DQo+PiA+aW4gdGhlIG9yZGVyIHRoZXkgb2NjdXIsIHNvIG9uZSBxdWVzdGlvbiB0byBhc2sg aXMgaWYgdGhlcmUgaXMgYW55DQo+PnZhbGlkDQo+PiA+cmVhc29uIHRvIHZpb2xhdGUgdGhlc2Ug InJlY29tbWVuZGF0aW9ucyIgZm9yIG90aGVyIHRoYW4gbWFsaWNpb3VzDQo+PiA+cHVycG9zZXMu DQo+PiA+DQo+PiA+DQo+PiA+Q2hlZXJzLA0KPj4gPg0KPj4gPiAgICBCZW5lZGlrdA0KPj4gPg0K Pj4gPi0tIA0KPj4gPkJlbmVkaWt0IFN0b2NrZWJyYW5kLCAgICAgICAgICAgICAgICAgICBTdGVw bGFkZGVyIElUDQo+PlRyYWluaW5nK0NvbnN1bHRpbmcNCj4+ID5EaXBsLi1JbmZvcm0uICAgICAg ICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5zdGVwbGFkZGVyLWl0LmNvbS8NCj4+ID4N Cj4+ID4gICAgICAgICAgQnVzaW5lc3MgR3JhZGUgSVB2NiAtLS0gQ29uc3VsdGluZywgVHJhaW5p bmcsIFByb2plY3RzDQo+PiA+DQo+PiA+QklWQmxvZy0tLUJlbmVkaWt0J3MgSVQgVmlkZW8gQmxv ZzoNCj4+aHR0cDovL3d3dy5zdGVwbGFkZGVyLWl0LmNvbS9iaXZibG9nLw0KPj4gPg0KPj4gPg0K Pj4gDQo+DQo+LS0gDQo+RW5ubyBSZXkNCj4NCj5FUk5XIEdtYkggLSBDYXJsLUJvc2NoLVN0ci4g NCAtIDY5MTE1IEhlaWRlbGJlcmcgLSB3d3cuZXJudy5kZQ0KPlRlbC4gKzQ5IDYyMjEgNDgwMzkw IC0gRmF4IDYyMjEgNDE5MDA4IC0gQ2VsbCArNDkgMTczIDY3NDU5MDINCj4NCj5IYW5kZWxzcmVn aXN0ZXIgTWFubmhlaW06IEhSQiAzMzcxMzUNCj5HZXNjaGFlZnRzZnVlaHJlcjogRW5ubyBSZXkN Cj4NCj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQo+QmxvZzogd3d3Lmluc2ludWF0b3IubmV0IHx8IENvbmZlcmVuY2U6IHd3dy50cm9vcGVy cy5kZQ0KPlR3aXR0ZXI6IEBFbm5vX0luc2ludWF0b3INCj49PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9w c0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN Cg0K From nobody Mon Jun 15 15:32:18 2015 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 A95CD1B2B6D for ; Mon, 15 Jun 2015 15:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, 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 x846L7ospH_7 for ; Mon, 15 Jun 2015 15:32:13 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576271A038E for ; Mon, 15 Jun 2015 15:32:13 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so37831267wic.1 for ; Mon, 15 Jun 2015 15:32:12 -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=Hi1J2srepP2oxYa8X2Te3r1OdA1I8NUaNERjMvfTB9w=; b=hEHMFt4UewrOWVyeMaKklsenJyxJjYGPrCT86JU7RmUP/aXMo/L3GYhcINwLPgXyhb Oig6bx+K9fDhihMRofIpIimFApdf4TAy+27rQlPggILQw+1YJfKM2z9dqulQp9F7UzuM 6Au2z9kyFvhwyUarJzBJ5yDrDkqVfo0VbWVr+DA3ryTi2bqr/bRb/rRJDvQn9SmdqcAX ul61ilRuQIMx3xCVT5mDaHN7RpjV86XOIGeHk+1MYDZKsMCKGSgM2I26gr2bC10iinbh HQi0f06q14KpFJtzabeZjv3XqvmqoM2fcirq1QQZi7jPqwLFYDhQ1VbQA74LRs9UAh10 r/7A== MIME-Version: 1.0 X-Received: by 10.180.109.136 with SMTP id hs8mr35403089wib.73.1434407532100; Mon, 15 Jun 2015 15:32:12 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Mon, 15 Jun 2015 15:32:11 -0700 (PDT) In-Reply-To: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> Date: Mon, 15 Jun 2015 15:32:11 -0700 Message-ID: From: Ca By To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=e89a8f23455769ff4f05189607c7 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 15 Jun 2015 22:32:17 -0000 --e89a8f23455769ff4f05189607c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, June 15, 2015, Eric Vyncke (evyncke) wrote: > Enno, > > As you probably know, Cisco handles PSIRT issues with care, so, I have no > clue on this specific advisory. My own (educated) guess is that the packe= t > causing a LC reload is fully RFC 2460 compliant but unusual, so, probably > (a guess again) a combination of extension headers triggering a bug. > > In this specific case, I would not blame IPv6 or RFC 2460 but rather my > own company (even if the affected versions were quite old as new IOS-XR > versions appear to be immune to this bug). And I appreciate the humor in > your rhetorical question about which FW could protect a CRS... Air gap > probably :-) > > More generally, regarding the 'parsing of the header' and performance, my > understanding (and I am NOT a HW engineer) is that there are multiple way= s > to parse the header chain: > - purely software in low-end devices, should have a marginal performance > impact > - specific ASIC in middle-end devices (read high end enterprise), probabl= y > some limitations and heavy performance impact (but again within one > organization, so, easier to fix the root cause) > - a lot of specialized network processors in high-end devices (SP gears), > which is a similar case as the 'low-end device', performance impact but > marginal as parsing the chain of headers is not that hard after all _when= _ > coded correctly > > As the extension headers are specific to IPv6, this is an area when we > will all learn (and have learned already) a lot of things... > > I respectfully disagree with your last sentence. Of course, destination > AS/host SHOULD only accept useful, known and legit ext headers; but, why > would an ISP filter on ext headers if they do not harm their own infra or > a customer infra? Do you envision an Internet where only TCP/443 and > UDP/43 would be accepted? > > Last point, the Internet will have to use IPv6 for 10 or 20 years at > least. If the IETF/ISP block all new _options_ in _existing_ extension > headers, then we will be stuck in 1997 for network innovation. While I do > not like taking security risks, I even fear more the lack of innovation. > > I keep hearing this and it is very bizarre to hear With regards to 1997, believing that there will be innovation in the narrow waist of hour glass (network layer), that is very 1997. The network layer is stable and boring.... Hence it being narrow. Innovation is welcome everywhere except network in the e2e model > Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-) > > -=C3=A9ric > > On 11/06/15 11:58, "Enno Rey" > wrote: > > > >the problem here is the definition of "normal IP packet" as of RFC2460. > >To illustrate this I just quote from today's Cisco advisory (Cisco IOS X= R > >Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets > >potentially crashing CRS-3 line cards: > > > >"The vulnerability is due to incorrect processing of an IPv6 packet > >carrying IPv6 extension headers that are valid but unlikely to be seen > >during normal operation. An attacker could exploit this vulnerability by > >sending such an IPv6 packet to an affected device that is configured to > >process IPv6 traffic. An exploit could allow the attacker to cause a > >reload of the line card, resulting in a DoS condition." > > > >two question come to mind here: > > > >- is a "valid but unlikely" extension header chain "normal"? > >- what ("combination of FW & IPS or whatever") would you put in front of > >a CRS? > > > >my (sad) expectation is that we'll see much more of these (types of) > >issues in the future. given the current level of freedom that the RFC246= 0 > >leaves (see also discussion/picture in > >http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/= ) > >"properly parsing an IPv6 packet, let alone in wire speed" seems a prett= y > >much unsolvable task to me. > > > >That said I still fail to see any useful extension header besides AH&ESP > >(not even FH) to be transported in the Internet. > > > >best > > > >Enno > > > > > > > > > > > > > > > > If your firewall cannot implement this policy, then > >> it is time to change or to use a combination of FW & IPS or whatever. > >> > >> - network person: as I will live with IPv6 for the rest of my life, > >>then I > >> want a way to extend it and I need any packet to travel to my source t= o > >>my > >> destination. Any IPv6 packet should be able to traverse the > >> Internet/private network as long as its layer-3 header is valid > >> (filtering/dropping can be done exceptionally for good operational > >> reason). Did we remember the IPv4 teardrop attack? It is blocked by > >> default by most routers for years ;-) > >> > >> Bugs will plague us for ever... And make our life more complex than th= e > >> above description of course ;-) > >> > >> -??ric > >> > >> On 17/05/15 20:43, "Silvia Hagen" > > wrote: > >> > >> >Hi > >> > > >> >I keep stumbling about that "recommendational wording" in RFC 2460 > >> >everytime I teach it. > >> > > >> >Couldn't we update RFC2460 and make this list a strict order? > >> > > >> >I would want my firewall to notify me if the EHs in a packet do not > >> >follow the list. > >> >And limiting the number of possible EHs per packet might be a good > >>idea. > >> > > >> >Silvia > >> > > >> >-----Urspr??ngliche Nachricht----- > >> >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net ] Im > Auftrag von Benedikt > >> >Stockebrand > >> >Gesendet: Sonntag, 17. Mai 2015 18:39 > >> >An: ipv6-wg@ripe.net > >> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > >> > > >> >Hi Enno and list, > >> > > >> >Enno Rey > writes: > >> > > >> >> hope everybody had a great #RIPE70 meeting. We did! > >> >> Many thanks to the organizers and chairs! > >> > > >> >and thanks to the actual speakers as well the speakers we had to turn > >> >down due to time constraints, too:-) > >> > > >> >> If the chairs consider this appropriate we will happily give a > >> >> presentation on this stuff in Bucharest or at another occasion. > >> > > >> >Sounds good to me! > >> > > >> >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > >> >> their number, order[...] > >> > > >> >Actually, as far as I'm concerned that's the real core of the problem= . > >> >Or more specifically, the first two lines of RFC 2460, section 4.1: > >> > > >> > When more than one extension header is used in the same packet, it > >>is > >> > recommended that those headers appear in the following order: > >> > > >> >followed on the next page by > >> > > >> > Each extension header should occur at most once, except for the > >> > Destination Options header which should occur at most twice (once > >> > before a Routing header and once before the upper-layer header). > >> > > >> >Note in particular that these are not even RFC 2119 "SHOULD" or > >> >"RECOMMENDED" and such. > >> > > >> >The impact here is actually at least twofold: > >> > > >> >- It is impossible to implement this as a simple pipeline architectur= e > >> > in hardware; at least for cases deviating from the "recommendations= " > >> > above this effectively becomes either excessively complex to > >>implement > >> > in hardware or an invitation to DoS when implemented in software on > >>an > >> > otherwise hardware router. > >> > > >> >- As I understand it, at least some of the issues you have found are > >> > effectively based on violating the second paragraph quoted, making = it > >> > impossible to come up with a lower bound on how long the header cha= in > >> > can actually get and therefore leading to the fragmentation related > >> > attacks and similar you have discovered. > >> > > >> >The original idea was that the extension headers are processed strict= ly > >> >in the order they occur, so one question to ask is if there is any > >>valid > >> >reason to violate these "recommendations" for other than malicious > >> >purposes. > >> > > >> > > >> >Cheers, > >> > > >> > Benedikt > >> > > >> >-- > >> >Benedikt Stockebrand, Stepladder IT > >>Training+Consulting > >> >Dipl.-Inform. http://www.stepladder-it.com/ > >> > > >> > Business Grade IPv6 --- Consulting, Training, Projects > >> > > >> >BIVBlog---Benedikt's IT Video Blog: > >>http://www.stepladder-it.com/bivblog/ > >> > > >> > > >> > > > >-- > >Enno Rey > > > >ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > >Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > > >Handelsregister Mannheim: HRB 337135 > >Geschaeftsfuehrer: Enno Rey > > > >=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=3D=3D= =3D=3D=3D=3D=3D=3D > >Blog: www.insinuator.net || Conference: www.troopers.de > >Twitter: @Enno_Insinuator > >=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=3D=3D= =3D=3D=3D=3D=3D=3D > > > >_______________________________________________ > >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 > --e89a8f23455769ff4f05189607c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, June 15, 2015, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
Enno,

As you probably know, Cisco handles PSIRT issues with care, so, I have no clue on this specific advisory. My own (educated) guess is that the packet<= br> causing a LC reload is fully RFC 2460 compliant but unusual, so, probably (a guess again) a combination of extension headers triggering a bug.

In this specific case, I would not blame IPv6 or RFC 2460 but rather my
own company (even if the affected versions were quite old as new IOS-XR
versions appear to be immune to this bug). And I appreciate the humor in your rhetorical question about which FW could protect a CRS... Air gap
probably :-)

More generally, regarding the 'parsing of the header' and performan= ce, my
understanding (and I am NOT a HW engineer) is that there are multiple ways<= br> to parse the header chain:
- purely software in low-end devices, should have a marginal performance impact
- specific ASIC in middle-end devices (read high end enterprise), probably<= br> some limitations and heavy performance impact (but again within one
organization, so, easier to fix the root cause)
- a lot of specialized network processors in high-end devices (SP gears), which is a similar case as the 'low-end device', performance impact= but
marginal as parsing the chain of headers is not that hard after all _when_<= br> coded correctly

As the extension headers are specific to IPv6, this is an area when we
will all learn (and have learned already) a lot of things...

I respectfully disagree with your last sentence. Of course, destination
AS/host SHOULD only accept useful, known and legit ext headers; but, why would an ISP filter on ext headers if they do not harm their own infra or a customer infra? Do you envision an Internet where only TCP/443 and
UDP/43 would be accepted?

Last point, the Internet will have to use IPv6 for 10 or 20 years at
least. If the IETF/ISP block all new _options_ in _existing_ extension
headers, then we will be stuck in 1997 for network innovation. While I do not like taking security risks, I even fear more the lack of innovation.


I keep hearing this and= it is very bizarre to hear=C2=A0

With regards to = 1997, believing that there will be innovation in the narrow waist of hour g= lass (network layer), that is very 1997. The network layer is stable and bo= ring.... Hence it being narrow.=C2=A0 Innovation is welcome everywhere exce= pt network in the e2e model
=C2=A0=C2=A0
Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-)
-=C3=A9ric

On 11/06/15 11:58, "Enno Rey" <erey@ernw.de>= ; wrote:
>
>the problem here is the definition of "normal IP packet" as o= f RFC2460.
>To illustrate this I just quote from today's Cisco advisory (Cisco = IOS XR
>Software Crafted IPv6 Packet Denial of Service Vulnerability) on packet= s
>potentially crashing CRS-3 line cards:
>
>"The vulnerability is due to incorrect processing of an IPv6 packe= t
>carrying IPv6 extension headers that are valid but unlikely to be seen<= br> >during normal operation. An attacker could exploit this vulnerability b= y
>sending such an IPv6 packet to an affected device that is configured to=
>process IPv6 traffic. An exploit could allow the attacker to cause a >reload of the line card, resulting in a DoS condition."
>
>two question come to mind here:
>
>- is a "valid but unlikely" extension header chain "norm= al"?
>- what ("combination of FW & IPS or whatever") would you = put in front of
>a CRS?
>
>my (sad) expectation is that we'll see much more of these (types of= )
>issues in the future. given the current level of freedom that the RFC24= 60
>leaves (see also discussion/picture in
>http://www.insinuator.net/2015/06/is-ipv6-m= ore-secure-than-ipv4-or-less/)
>"properly parsing an IPv6 packet, let alone in wire speed" se= ems a pretty
>much unsolvable task to me.
>
>That said I still fail to see any useful extension header besides AH&am= p;ESP
>(not even FH) to be transported in the Internet.
>
>best
>
>Enno
>
>
>
>
>
>
>
> If your firewall cannot implement this policy, then
>> it is time to change or to use a combination of FW & IPS or wh= atever.
>>
>> - network person: as I will live with IPv6 for the rest of my life= ,
>>then I
>> want a way to extend it and I need any packet to travel to my sour= ce to
>>my
>> destination. Any IPv6 packet should be able to traverse the
>> Internet/private network as long as its layer-3 header is valid >> (filtering/dropping can be done exceptionally for good operational=
>> reason). Did we remember the IPv4 teardrop attack? It is blocked b= y
>> default by most routers for years ;-)
>>
>> Bugs will plague us for ever... And make our life more complex tha= n the
>> above description of course ;-)
>>
>> -??ric
>>
>> On 17/05/15 20:43, "Silvia Hagen" <silvia.hagen@sunny.ch> wrote:
>>
>> >Hi
>> >
>> >I keep stumbling about that "recommendational wording&quo= t; in RFC 2460
>> >everytime I teach it.
>> >
>> >Couldn't we update RFC2460 and make this list a strict ord= er?
>> >
>> >I would want my firewall to notify me if the EHs in a packet d= o not
>> >follow the list.
>> >And limiting the number of possible EHs per packet might be a = good
>>idea.
>> >
>> >Silvia
>> >
>> >-----Urspr??ngliche Nachricht-----
>> >Von: ipv6-wg [mailto:ipv6-wg-bounces@r= ipe.net] Im Auftrag von Benedikt
>> >Stockebrand
>> >Gesendet: Sonntag, 17. Mai 2015 18:39
>> >An: ipv6-wg@ripe.net
>> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security = Devices
>> >
>> >Hi Enno and list,
>> >
>> >Enno Rey <erey@ernw.de> writes:
>> >
>> >> hope everybody had a great #RIPE70 meeting. We did!
>> >> Many thanks to the organizers and chairs!
>> >
>> >and thanks to the actual speakers as well the speakers we had = to turn
>> >down due to time constraints, too:-)
>> >
>> >> If the chairs consider this appropriate we will happily g= ive a
>> >> presentation on this stuff in Bucharest or at another occ= asion.
>> >
>> >Sounds good to me!
>> >
>> >> - looking at the "liberty" RFC2460 provides as = for ext_hdrs (wrt to
>> >> their number, order[...]
>> >
>> >Actually, as far as I'm concerned that's the real core= of the problem.
>> >Or more specifically, the first two lines of RFC 2460, section= 4.1:
>> >
>> >=C2=A0 =C2=A0When more than one extension header is used in th= e same packet, it
>>is
>> >=C2=A0 =C2=A0recommended that those headers appear in the foll= owing order:
>> >
>> >followed on the next page by
>> >
>> >=C2=A0 =C2=A0Each extension header should occur at most once, = except for the
>> >=C2=A0 =C2=A0Destination Options header which should occur at = most twice (once
>> >=C2=A0 =C2=A0before a Routing header and once before the upper= -layer header).
>> >
>> >Note in particular that these are not even RFC 2119 "SHOU= LD" or
>> >"RECOMMENDED" and such.
>> >
>> >The impact here is actually at least twofold:
>> >
>> >- It is impossible to implement this as a simple pipeline arch= itecture
>> >=C2=A0 in hardware; at least for cases deviating from the &quo= t;recommendations"
>> >=C2=A0 above this effectively becomes either excessively compl= ex to
>>implement
>> >=C2=A0 in hardware or an invitation to DoS when implemented in= software on
>>an
>> >=C2=A0 otherwise hardware router.
>> >
>> >- As I understand it, at least some of the issues you have fou= nd are
>> >=C2=A0 effectively based on violating the second paragraph quo= ted, making it
>> >=C2=A0 impossible to come up with a lower bound on how long th= e header chain
>> >=C2=A0 can actually get and therefore leading to the fragmenta= tion related
>> >=C2=A0 attacks and similar you have discovered.
>> >
>> >The original idea was that the extension headers are processed= strictly
>> >in the order they occur, so one question to ask is if there is= any
>>valid
>> >reason to violate these "recommendations" for other = than malicious
>> >purposes.
>> >
>> >
>> >Cheers,
>> >
>> >=C2=A0 =C2=A0 Benedikt
>> >
>> >--
>> >Benedikt Stockebrand,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Stepladder IT
>>Training+Consulting
>> >Dipl.-Inform.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.stepladder-it.com/
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Business Grade IPv6 --- Con= sulting, Training, Projects
>> >
>> >BIVBlog---Benedikt's IT Video Blog:
>>http://www.stepladder-it.com/bivblog/
>> >
>> >
>>
>
>--
>Enno Rey
>
>ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
>Handelsregister Mannheim: HRB 337135
>Geschaeftsfuehrer: Enno Rey
>
>=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=3D= =3D=3D=3D=3D=3D=3D=3D
>Blog: www.insin= uator.net || Conference: www.troopers.de
>Twitter: @Enno_Insinuator
>=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=3D= =3D=3D=3D=3D=3D=3D=3D
>
>_______________________________________________
>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
--e89a8f23455769ff4f05189607c7-- From nobody Mon Jun 15 22:12:04 2015 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 EF7F11B39AA for ; Mon, 15 Jun 2015 22:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, GB_I_INVITATION=-2, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, 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 iGUrRCta83tt for ; Mon, 15 Jun 2015 22:12:00 -0700 (PDT) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1535B1B39AC for ; Mon, 15 Jun 2015 22:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1434431519; bh=DFdMypUQlV69wL0YscCq5EE+IPNdeodiMS2h9cw4FuU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ZFglWcVRyb+8bTg32hKN2U3krCQinj8L2EU8Jgz5yQJnMmJ3uHuRSvPpgxnsHvcdURbevuiOCJW+17fEyBYkDUDpdMt4CZfJ6jcqIbPCqQ8deWnGD57QK9DytyISEud7PCaCoTlWGhAU7Map66VvikhiSL2+JbywOh6fOCO1fIGz9YvhNsvVUzQaI7f9JFITamKTZrn4nRf1ZH/fMUszVeso1vrHUvTfuZdDaQhlWxX7BJQGF5jjq/P/RxRlKcdfRr9WZB04p3i8P0R9+3h/qWLMwjt+UBZQ84zMmZrk7adv+Vk7eWOeIAgTJzwIAVWvNUlGcdC4zUagPPMhRfaHeg== Received: from [98.139.215.142] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jun 2015 05:11:59 -0000 Received: from [98.139.215.230] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jun 2015 05:11:59 -0000 Received: from [127.0.0.1] by omp1070.mail.bf1.yahoo.com with NNFMP; 16 Jun 2015 05:11:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 124078.33806.bm@omp1070.mail.bf1.yahoo.com X-YMail-OSG: _9SZmhYVM1kYNycLzpmZK0E4yc6Y24XvXdOFGLF_jSBkX7MDJRy5_uw7M0WixMY tEyRGRESqa1qSV996jsSYXhZJXwVLkW4sJjwdiW3us1EEo1j51dPhdJl2czjjEgZXEgvkb9bW7Vw IqrqOfBaaRM04xycb9EbT701MhI1OLb8NcQkX.hGPloauIAOtQEs4tzyKtnOSNySfcLPrmaA0S7v o8_9Lje9gj6uKgvZJLgTYGqbjivguqXWO22sVgar0pF77D0ztNo5Y1r..V7mpap.DGxXxMiGW0M_ So8FJbKem9iH2gZ.9qkCdVIXNWs7c1XZr3C90O8QZR08UncN4D_.iflvRznYvDedcdKrgk_mj4qU 1zTBesoKvVAk_Ylh7pYQZayRbGrL2OwkCPng6GLaXalWlYXZnwM61J8xIT1cE2XNu2DhOyLFnsFL WzDvFBmoBwbpyILWhtYy1P9oOxrmIKccN0IJCN0hras8iMIAO6ObG5fzCV3OfumV2P6Gs1P78LYV E6m_yss.uDoINzV2Kza8Syev9pSMcdSz.cmHbwjXoxJzfdEbpwg-- Received: by 66.196.80.120; Tue, 16 Jun 2015 05:11:58 +0000 Date: Tue, 16 Jun 2015 05:11:57 +0000 (UTC) From: Mark ZZZ Smith To: Ca By , "Eric Vyncke (evyncke)" Message-ID: <283392813.4420641.1434431518036.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4420640_10869934.1434431518026" Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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: Tue, 16 Jun 2015 05:12:04 -0000 ------=_Part_4420640_10869934.1434431518026 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Ca By To: Eric Vyncke (evyncke) =20 Cc: "v6ops@ietf.org" ; "ipv6-wg@ripe.net" =20 Sent: Tuesday, 16 June 2015, 8:32 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices =20 On Monday, June 15, 2015, Eric Vyncke (evyncke) wrote: Enno, As you probably know, Cisco handles PSIRT issues with care, so, I have no clue on this specific advisory. My own (educated) guess is that the packet causing a LC reload is fully RFC 2460 compliant but unusual, so, probably (a guess again) a combination of extension headers triggering a bug. In this specific case, I would not blame IPv6 or RFC 2460 but rather my own company (even if the affected versions were quite old as new IOS-XR versions appear to be immune to this bug). And I appreciate the humor in your rhetorical question about which FW could protect a CRS... Air gap probably :-) More generally, regarding the 'parsing of the header' and performance, my understanding (and I am NOT a HW engineer) is that there are multiple ways to parse the header chain: - purely software in low-end devices, should have a marginal performance impact - specific ASIC in middle-end devices (read high end enterprise), probably some limitations and heavy performance impact (but again within one organization, so, easier to fix the root cause) - a lot of specialized network processors in high-end devices (SP gears), which is a similar case as the 'low-end device', performance impact but marginal as parsing the chain of headers is not that hard after all _when_ coded correctly As the extension headers are specific to IPv6, this is an area when we will all learn (and have learned already) a lot of things... I respectfully disagree with your last sentence. Of course, destination AS/host SHOULD only accept useful, known and legit ext headers; but, why would an ISP filter on ext headers if they do not harm their own infra or a customer infra? Do you envision an Internet where only TCP/443 and UDP/43 would be accepted? Last point, the Internet will have to use IPv6 for 10 or 20 years at least. If the IETF/ISP block all new _options_ in _existing_ extension headers, then we will be stuck in 1997 for network innovation. While I do not like taking security risks, I even fear more the lack of innovation. I keep hearing this and it is very bizarre to hear=C2=A0 With regards to 1997, believing that there will be innovation in the narrow= waist of hour glass (network layer), that is very 1997. The network layer = is stable and boring.... Hence it being narrow.=C2=A0 Innovation is welcome= everywhere except network in the e2e model / Absence of evidence is not evidence of absence.=C2=A0 / Consider what the network and host situation was in 1997 (wired network a= ccess, desktops outselling laptops, dialup Internet for residential, corpor= ates in total probably being the largest spenders on Internet access) to to= day and the near future (wireless networks, smartphones/tablets being the d= ominant Internet access device in some markets - and they're multi-homed, M= 2M/IoT considered to be place where the greatest expansion of Internet conn= ected devices is going to occur in the near future.) / IPv6 has had relatively little adoption, and it is only starting to incre= ase quite rapidly in the last few years and that is mainly because of mobil= e networks. There hasn't and still doesn't seem to be much thinking about h= ow IPv6's differences from IPv4's can be taken advantage of yet - an "IPv4 = first" or an "IPv4 =3D=3D IPv6" mindset seems to be still very common (I th= ink the network virtualisation space is where this is might be most promine= nt - I think most of the technologies they're inventing require fork lift n= etwork upgrades, so the costs of deploying IPv6 at the same time become a l= ot less significant. So if there is a "cheap" opportunity to deploy IPv6, a= nd IPv6 is going to be the long term network layer 3, why not optimise for = it now? That was the thinking behind my "Enhancing Virtual Network Encapsul= ation with IPv6" draft)=C2=A0 / We don't want to disable innovation opportunities that IPv6 may provide b= efore people have arrived at an "IPv6 first" or "IPv4 !=3D IPv6" mindset. = =C2=A0 =C2=A0=C2=A0 Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-) -=C3=A9ric On 11/06/15 11:58, "Enno Rey" wrote: > >the problem here is the definition of "normal IP packet" as of RFC2460. >To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR >Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets >potentially crashing CRS-3 line cards: > >"The vulnerability is due to incorrect processing of an IPv6 packet >carrying IPv6 extension headers that are valid but unlikely to be seen >during normal operation. An attacker could exploit this vulnerability by >sending such an IPv6 packet to an affected device that is configured to >process IPv6 traffic. An exploit could allow the attacker to cause a >reload of the line card, resulting in a DoS condition." > >two question come to mind here: > >- is a "valid but unlikely" extension header chain "normal"? >- what ("combination of FW & IPS or whatever") would you put in front of >a CRS? > >my (sad) expectation is that we'll see much more of these (types of) >issues in the future. given the current level of freedom that the RFC2460 >leaves (see also discussion/picture in >http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/) >"properly parsing an IPv6 packet, let alone in wire speed" seems a pretty >much unsolvable task to me. > >That said I still fail to see any useful extension header besides AH&ESP >(not even FH) to be transported in the Internet. > >best > >Enno > > > > > > > > If your firewall cannot implement this policy, then >> it is time to change or to use a combination of FW & IPS or whatever. >> >> - network person: as I will live with IPv6 for the rest of my life, >>then I >> want a way to extend it and I need any packet to travel to my source to >>my >> destination. Any IPv6 packet should be able to traverse the >> Internet/private network as long as its layer-3 header is valid >> (filtering/dropping can be done exceptionally for good operational >> reason). Did we remember the IPv4 teardrop attack? It is blocked by >> default by most routers for years ;-) >> >> Bugs will plague us for ever... And make our life more complex than the >> above description of course ;-) >> >> -??ric >> >> On 17/05/15 20:43, "Silvia Hagen" wrote: >> >> >Hi >> > >> >I keep stumbling about that "recommendational wording" in RFC 2460 >> >everytime I teach it. >> > >> >Couldn't we update RFC2460 and make this list a strict order? >> > >> >I would want my firewall to notify me if the EHs in a packet do not >> >follow the list. >> >And limiting the number of possible EHs per packet might be a good >>idea. >> > >> >Silvia >> > >> >-----Urspr??ngliche Nachricht----- >> >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt >> >Stockebrand >> >Gesendet: Sonntag, 17. Mai 2015 18:39 >> >An: ipv6-wg@ripe.net >> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices >> > >> >Hi Enno and list, >> > >> >Enno Rey writes: >> > >> >> hope everybody had a great #RIPE70 meeting. We did! >> >> Many thanks to the organizers and chairs! >> > >> >and thanks to the actual speakers as well the speakers we had to turn >> >down due to time constraints, too:-) >> > >> >> If the chairs consider this appropriate we will happily give a >> >> presentation on this stuff in Bucharest or at another occasion. >> > >> >Sounds good to me! >> > >> >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to >> >> their number, order[...] >> > >> >Actually, as far as I'm concerned that's the real core of the problem. >> >Or more specifically, the first two lines of RFC 2460, section 4.1: >> > >> >=C2=A0 =C2=A0When more than one extension header is used in the same pa= cket, it >>is >> >=C2=A0 =C2=A0recommended that those headers appear in the following ord= er: >> > >> >followed on the next page by >> > >> >=C2=A0 =C2=A0Each extension header should occur at most once, except fo= r the >> >=C2=A0 =C2=A0Destination Options header which should occur at most twic= e (once >> >=C2=A0 =C2=A0before a Routing header and once before the upper-layer he= ader). >> > >> >Note in particular that these are not even RFC 2119 "SHOULD" or >> >"RECOMMENDED" and such. >> > >> >The impact here is actually at least twofold: >> > >> >- It is impossible to implement this as a simple pipeline architecture >> >=C2=A0 in hardware; at least for cases deviating from the "recommendati= ons" >> >=C2=A0 above this effectively becomes either excessively complex to >>implement >> >=C2=A0 in hardware or an invitation to DoS when implemented in software= on >>an >> >=C2=A0 otherwise hardware router. >> > >> >- As I understand it, at least some of the issues you have found are >> >=C2=A0 effectively based on violating the second paragraph quoted, maki= ng it >> >=C2=A0 impossible to come up with a lower bound on how long the header = chain >> >=C2=A0 can actually get and therefore leading to the fragmentation rela= ted >> >=C2=A0 attacks and similar you have discovered. >> > >> >The original idea was that the extension headers are processed strictly >> >in the order they occur, so one question to ask is if there is any >>valid >> >reason to violate these "recommendations" for other than malicious >> >purposes. >> > >> > >> >Cheers, >> > >> >=C2=A0 =C2=A0 Benedikt >> > >> >-- >> >Benedikt Stockebrand,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Stepladder IT >>Training+Consulting >> >Dipl.-Inform.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.stepladder-it.com/ >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Business Grade IPv6 --- Consulting, = Training, Projects >> > >> >BIVBlog---Benedikt's IT Video Blog: >>http://www.stepladder-it.com/bivblog/ >> > >> > >> > >-- >Enno Rey > >ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > >Handelsregister Mannheim: HRB 337135 >Geschaeftsfuehrer: Enno Rey > >=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=3D=3D= =3D=3D=3D=3D=3D=3D >Blog: www.insinuator.net || Conference: www.troopers.de >Twitter: @Enno_Insinuator >=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=3D=3D= =3D=3D=3D=3D=3D=3D > >_______________________________________________ >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 ------=_Part_4420640_10869934.1434431518026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From: Ca By <cb.list6@gmail.com>
To: Eric Vyncke (evyncke) <evyncke@cisco= .com>
Cc: "v6ops@ie= tf.org" <v6ops@ietf.org>; "ipv6-wg@ripe.net" <ipv6-wg@ripe.net>=
Sent: Tuesday, 16 Ju= ne 2015, 8:32
Subject:= Re: [v6ops] Extension Headers / Impact on Security Devices
<= br>

On Monday, June 15, 2015, Eric Vyncke (= evyncke) <evyncke@cisco= .com> wrote:
Enno,

As you probably know, Cisco handles PSIRT issues with care, so, I have no clue on this specific advisory. My own (educated) guess is that the packet<= br clear=3D"none"> causing a LC reload is fully RFC 2460 compliant but unusual, so, probably (a guess again) a combination of extension headers triggering a bug.

In this specific case, I would not blame IPv6 or RFC 2460 but rather my
own company (even if the affected versions were quite old as new IOS-XR
versions appear to be immune to this bug). And I appreciate the humor in your rhetorical question about which FW could protect a CRS... Air gap
probably :-)

More generally, regarding the 'parsing of the header' and performance, my understanding (and I am NOT a HW engineer) is that there are multiple ways<= br clear=3D"none"> to parse the header chain:
- purely software in low-end devices, should have a marginal performance impact
- specific ASIC in middle-end devices (read high end enterprise), probably<= br clear=3D"none"> some limitations and heavy performance impact (but again within one
organization, so, easier to fix the root cause)
- a lot of specialized network processors in high-end devices (SP gears), which is a similar case as the 'low-end device', performance impact but
marginal as parsing the chain of headers is not that hard after all _when_<= br clear=3D"none"> coded correctly

As the extension headers are specific to IPv6, this is an area when we
will all learn (and have learned already) a lot of things...

I respectfully disagree with your last sentence. Of course, destination
AS/host SHOULD only accept useful, known and legit ext headers; but, why would an ISP filter on ext headers if they do not harm their own infra or a customer infra? Do you envision an Internet where only TCP/443 and
UDP/43 would be accepted?

Last point, the Internet will have to use IPv6 for 10 or 20 years at
least. If the IETF/ISP block all new _options_ in _existing_ extension
headers, then we will be stuck in 1997 for network innovation. While I do not like taking security risks, I even fear more the lack of innovation.


I keep hear= ing this and it is very bizarre to hear 

With regards to 1997, believing that there will be innovation= in the narrow waist of hour glass (network layer), that is very 1997. The = network layer is stable and boring.... Hence it being narrow.  Innovat= ion is welcome everywhere except network in the e2e model

/ Absence of evidence is not evidence of absence. 

/ Consider what the network and host situation was = in 1997 (wired network access, desktops outselling laptops, dialup Internet= for residential, corporates in total probably being the largest spenders o= n Internet access) to today and the near future (wireless networks, smartph= ones/tablets being the dominant Internet access device in some markets - an= d they're multi-homed, M2M/IoT considered to be place where the greatest ex= pansion of Internet connected devices is going to occur in the near future.= )

/ IPv6 has had relatively little = adoption, and it is only starting to increase quite rapidly in the last few= years and that is mainly because of mobile networks. There hasn't and stil= l doesn't seem to be much thinking about how IPv6's differences from IPv4's= can be taken advantage of yet - an "IPv4 first" or an "IPv4 =3D=3D IPv6" m= indset seems to be still very common (I think the network virtualisation sp= ace is where this is might be most prominent - I think most of the technolo= gies they're inventing require fork lift network upgrades, so the costs of = deploying IPv6 at the same time become a lot less significant. So if there = is a "cheap" opportunity to deploy IPv6, and IPv6 is going to be the long t= erm network layer 3, why not optimise for it now? That was the thinking beh= ind my "Enhancing Virtual Network Encapsulation with IPv6" draft) 

/ We don't want to disable= innovation opportunities that IPv6 may provide before people have arrived = at an "IPv6 first" or "IPv4 !=3D IPv6" mindset.  


=   
Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-)

-=C3=A9ric

On 11/06/15 11:58, "Enno Rey" <erey@ernw.de> wrote:
>
>the problem here is the definition of "normal IP packet" as of RFC2460.=
>To illustrate this I just quote from today's Cisco advisory (Cisco IOS = XR
>Software Crafted IPv6 Packet Denial of Service Vulnerability) on packet= s
>potentially crashing CRS-3 line cards:
>
>"The vulnerability is due to incorrect processing of an IPv6 packet
>carrying IPv6 extension headers that are valid but unlikely to be seen<= br clear=3D"none"> >during normal operation. An attacker could exploit this vulnerability b= y
>sending such an IPv6 packet to an affected device that is configured to=
>process IPv6 traffic. An exploit could allow the attacker to cause a >reload of the line card, resulting in a DoS condition."
>
>two question come to mind here:
>
>- is a "valid but unlikely" extension header chain "normal"?
>- what ("combination of FW & IPS or whatever") would you put in fro= nt of
>a CRS?
>
>my (sad) expectation is that we'll see much more of these (types of) >issues in the future. given the current level of freedom that the RFC24= 60
>leaves (see also discussion/picture in
>http://www.= insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/)
>"properly parsing an IPv6 packet, let alone in wire speed" seems a pret= ty
>much unsolvable task to me.
>
>That said I still fail to see any useful extension header besides AH&am= p;ESP
>(not even FH) to be transported in the Internet.
>
>best
>
>Enno
>
>
>
>
>
>
>
> If your firewall cannot implement this policy, then
>> it is time to change or to use a combination of FW & IPS or wh= atever.
>>
>> - network person: as I will live with IPv6 for the rest of my life= ,
>>then I
>> want a way to extend it and I need any packet to travel to my sour= ce to
>>my
>> destination. Any IPv6 packet should be able to traverse the
>> Internet/private network as long as its layer-3 header is valid >> (filtering/dropping can be done exceptionally for good operational=
>> reason). Did we remember the IPv4 teardrop attack? It is blocked b= y
>> default by most routers for years ;-)
>>
>> Bugs will plague us for ever... And make our life more complex tha= n the
>> above description of course ;-)
>>
>> -??ric
>>
>> On 17/05/15 20:43, "Silvia Hagen" <silvia.hagen@sunny.ch> wrote:
>>
>> >Hi
>> >
>> >I keep stumbling about that "recommendational wording" in RFC = 2460
>> >everytime I teach it.
>> >
>> >Couldn't we update RFC2460 and make this list a strict order?<= br clear=3D"none"> >> >
>> >I would want my firewall to notify me if the EHs in a packet d= o not
>> >follow the list.
>> >And limiting the number of possible EHs per packet might be a = good
>>idea.
>> >
>> >Silvia
>> >
>> >-----Urspr??ngliche Nachricht-----
>> >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt
>> >Stockebrand
>> >Gesendet: Sonntag, 17. Mai 2015 18:39
>> >An: ipv6-wg@ripe.= net
>> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security = Devices
>> >
>> >Hi Enno and list,
>> >
>> >Enno Rey <erey= @ernw.de> writes:
>> >
>> >> hope everybody had a great #RIPE70 meeting. We did!
>> >> Many thanks to the organizers and chairs!
>> >
>> >and thanks to the actual speakers as well the speakers we had = to turn
>> >down due to time constraints, too:-)
>> >
>> >> If the chairs consider this appropriate we will happily g= ive a
>> >> presentation on this stuff in Bucharest or at another occ= asion.
>> >
>> >Sounds good to me!
>> >
>> >> - looking at the "liberty" RFC2460 provides as for ext_hd= rs (wrt to
>> >> their number, order[...]
>> >
>> >Actually, as far as I'm concerned that's the real core of the = problem.
>> >Or more specifically, the first two lines of RFC 2460, section= 4.1:
>> >
>> >   When more than one extension header is used in th= e same packet, it
>>is
>> >   recommended that those headers appear in the foll= owing order:
>> >
>> >followed on the next page by
>> >
>> >   Each extension header should occur at most once, = except for the
>> >   Destination Options header which should occur at = most twice (once
>> >   before a Routing header and once before the upper= -layer header).
>> >
>> >Note in particular that these are not even RFC 2119 "SHOULD" o= r
>> >"RECOMMENDED" and such.
>> >
>> >The impact here is actually at least twofold:
>> >
>> >- It is impossible to implement this as a simple pipeline arch= itecture
>> >  in hardware; at least for cases deviating from the "rec= ommendations"
>> >  above this effectively becomes either excessively compl= ex to
>>implement
>> >  in hardware or an invitation to DoS when implemented in= software on
>>an
>> >  otherwise hardware router.
>> >
>> >- As I understand it, at least some of the issues you have fou= nd are
>> >  effectively based on violating the second paragraph quo= ted, making it
>> >  impossible to come up with a lower bound on how long th= e header chain
>> >  can actually get and therefore leading to the fragmenta= tion related
>> >  attacks and similar you have discovered.
>> >
>> >The original idea was that the extension headers are processed= strictly
>> >in the order they occur, so one question to ask is if there is= any
>>valid
>> >reason to violate these "recommendations" for other than malic= ious
>> >purposes.
>> >
>> >
>> >Cheers,
>> >
>> >    Benedikt
>> >
>> >--
>> >Benedikt Stockebrand,           =        Stepladder IT
>>Training+Consulting
>> >Dipl.-Inform.              =              http://w= ww.stepladder-it.com/
>> >
>> >          Business Grade IPv6 --- Con= sulting, Training, Projects
>> >
>> >BIVBlog---Benedikt's IT Video Blog:
>>http://www.stepladder-it.com/bivblog/<= br clear=3D"none"> >> >
>> >
>>
>
>--
>Enno Rey
>
>ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
>Handelsregister Mannheim: HRB 337135
>Geschaeftsfuehrer: Enno Rey
>
>=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=3D= =3D=3D=3D=3D=3D=3D=3D
>Blog: www.insinuator.net || Conference: ww= w.troopers.de
>Twitter: @Enno_Insinuator
>=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=3D= =3D=3D=3D=3D=3D=3D=3D
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6= ops

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



------=_Part_4420640_10869934.1434431518026-- From nobody Tue Jun 16 06:08:27 2015 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 043AF1B342B for ; Tue, 16 Jun 2015 06:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, 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 d1ld7hembzXD for ; Tue, 16 Jun 2015 06:08:20 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42141B3456 for ; Tue, 16 Jun 2015 06:08:18 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so52620246wic.1 for ; Tue, 16 Jun 2015 06:08:17 -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=6ERfw1CFvrCccnHCk/r1StxcMnMqxOW3GDGk2aqqFnI=; b=QPBJZWLqZEsldAIB46COfqJqPpH2cM+Gc4FB1zikooZPl/NqokyTcm5bWoP0gP2OGY zEiVeaiJRuKW+58NKVGIAh0qeBJUqpR1eCfSRl69Q9ejzRlEBQjs5WegRvx5143jDTuW RwFGn859cfLKZ15uRBdQD/S3VQJipfy99WAsfOzNPHVR6J5gTuGCmilErz9vBIuDQBYT pNIiJ+twbvWhvCBo0HwL0IUdf+HiFL64OT5mEoK1NUqQ4nDQH464jyqec/GsxLY7SNGV 4DB5Kw5TlMWEhD8JuUZ+uMcN3NfYvVPientMAokv4Y1pVXa1FYYOj9HmtGJ6x+y3D3pH Dosg== MIME-Version: 1.0 X-Received: by 10.180.100.74 with SMTP id ew10mr44256260wib.12.1434460097520; Tue, 16 Jun 2015 06:08:17 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Tue, 16 Jun 2015 06:08:17 -0700 (PDT) In-Reply-To: <283392813.4420641.1434431518036.JavaMail.yahoo@mail.yahoo.com> References: <283392813.4420641.1434431518036.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 16 Jun 2015 06:08:17 -0700 Message-ID: From: Ca By To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=14dae9cc9c5a8ea8060518a244a0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 16 Jun 2015 13:08:26 -0000 --14dae9cc9c5a8ea8060518a244a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, June 15, 2015, Mark ZZZ Smith wrote: > > ------------------------------ > *From:* Ca By > > *To:* Eric Vyncke (evyncke) > > *Cc:* "v6ops@ietf.org " < > v6ops@ietf.org >; " > ipv6-wg@ripe.net " < > ipv6-wg@ripe.net > > *Sent:* Tuesday, 16 June 2015, 8:32 > *Subject:* Re: [v6ops] Extension Headers / Impact on Security Devices > > > > On Monday, June 15, 2015, Eric Vyncke (evyncke) > wrote: > > Enno, > > As you probably know, Cisco handles PSIRT issues with care, so, I have no > clue on this specific advisory. My own (educated) guess is that the packe= t > causing a LC reload is fully RFC 2460 compliant but unusual, so, probably > (a guess again) a combination of extension headers triggering a bug. > > In this specific case, I would not blame IPv6 or RFC 2460 but rather my > own company (even if the affected versions were quite old as new IOS-XR > versions appear to be immune to this bug). And I appreciate the humor in > your rhetorical question about which FW could protect a CRS... Air gap > probably :-) > > More generally, regarding the 'parsing of the header' and performance, my > understanding (and I am NOT a HW engineer) is that there are multiple way= s > to parse the header chain: > - purely software in low-end devices, should have a marginal performance > impact > - specific ASIC in middle-end devices (read high end enterprise), probabl= y > some limitations and heavy performance impact (but again within one > organization, so, easier to fix the root cause) > - a lot of specialized network processors in high-end devices (SP gears), > which is a similar case as the 'low-end device', performance impact but > marginal as parsing the chain of headers is not that hard after all _when= _ > coded correctly > > As the extension headers are specific to IPv6, this is an area when we > will all learn (and have learned already) a lot of things... > > I respectfully disagree with your last sentence. Of course, destination > AS/host SHOULD only accept useful, known and legit ext headers; but, why > would an ISP filter on ext headers if they do not harm their own infra or > a customer infra? Do you envision an Internet where only TCP/443 and > UDP/43 would be accepted? > > Last point, the Internet will have to use IPv6 for 10 or 20 years at > least. If the IETF/ISP block all new _options_ in _existing_ extension > headers, then we will be stuck in 1997 for network innovation. While I do > not like taking security risks, I even fear more the lack of innovation. > > > > I keep hearing this and it is very bizarre to hear > > With regards to 1997, believing that there will be innovation in the > narrow waist of hour glass (network layer), that is very 1997. The networ= k > layer is stable and boring.... Hence it being narrow. Innovation is > welcome everywhere except network in the e2e model > > / Absence of evidence is not evidence of absence. > > / Consider what the network and host situation was in 1997 (wired network > access, desktops outselling laptops, dialup Internet for residential, > corporates in total probably being the largest spenders on Internet acces= s) > to today and the near future (wireless networks, smartphones/tablets bein= g > the dominant Internet access device in some markets - and they're > multi-homed, M2M/IoT considered to be place where the greatest expansion = of > Internet connected devices is going to occur in the near future.) > > / IPv6 has had relatively little adoption, and it is only starting to > increase quite rapidly in the last few years and that is mainly because o= f > mobile networks. There hasn't and still doesn't seem to be much thinking > about how IPv6's differences from IPv4's can be taken advantage of yet - = an > "IPv4 first" or an "IPv4 =3D=3D IPv6" mindset seems to be still very comm= on (I > think the network virtualisation space is where this is might be most > prominent - I think most of the technologies they're inventing require fo= rk > lift network upgrades, so the costs of deploying IPv6 at the same time > become a lot less significant. So if there is a "cheap" opportunity to > deploy IPv6, and IPv6 is going to be the long term network layer 3, why n= ot > optimise for it now? That was the thinking behind my "Enhancing Virtual > Network Encapsulation with IPv6" draft) > > / We don't want to disable innovation opportunities that IPv6 may provide > before people have arrived at an "IPv6 first" or "IPv4 !=3D IPv6" mindset= . > > > I have heard those stories, i don't find them compelling. CB > > > Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-) > > -=C3=A9ric > > On 11/06/15 11:58, "Enno Rey" wrote: > > > >the problem here is the definition of "normal IP packet" as of RFC2460. > >To illustrate this I just quote from today's Cisco advisory (Cisco IOS X= R > >Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets > >potentially crashing CRS-3 line cards: > > > >"The vulnerability is due to incorrect processing of an IPv6 packet > >carrying IPv6 extension headers that are valid but unlikely to be seen > >during normal operation. An attacker could exploit this vulnerability by > >sending such an IPv6 packet to an affected device that is configured to > >process IPv6 traffic. An exploit could allow the attacker to cause a > >reload of the line card, resulting in a DoS condition." > > > >two question come to mind here: > > > >- is a "valid but unlikely" extension header chain "normal"? > >- what ("combination of FW & IPS or whatever") would you put in front of > >a CRS? > > > >my (sad) expectation is that we'll see much more of these (types of) > >issues in the future. given the current level of freedom that the RFC246= 0 > >leaves (see also discussion/picture in > >http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/= ) > >"properly parsing an IPv6 packet, let alone in wire speed" seems a prett= y > >much unsolvable task to me. > > > >That said I still fail to see any useful extension header besides AH&ESP > >(not even FH) to be transported in the Internet. > > > >best > > > >Enno > > > > > > > > > > > > > > > > If your firewall cannot implement this policy, then > >> it is time to change or to use a combination of FW & IPS or whatever. > >> > >> - network person: as I will live with IPv6 for the rest of my life, > >>then I > >> want a way to extend it and I need any packet to travel to my source t= o > >>my > >> destination. Any IPv6 packet should be able to traverse the > >> Internet/private network as long as its layer-3 header is valid > >> (filtering/dropping can be done exceptionally for good operational > >> reason). Did we remember the IPv4 teardrop attack? It is blocked by > >> default by most routers for years ;-) > >> > >> Bugs will plague us for ever... And make our life more complex than th= e > >> above description of course ;-) > >> > >> -??ric > >> > >> On 17/05/15 20:43, "Silvia Hagen" wrote: > >> > >> >Hi > >> > > >> >I keep stumbling about that "recommendational wording" in RFC 2460 > >> >everytime I teach it. > >> > > >> >Couldn't we update RFC2460 and make this list a strict order? > >> > > >> >I would want my firewall to notify me if the EHs in a packet do not > >> >follow the list. > >> >And limiting the number of possible EHs per packet might be a good > >>idea. > >> > > >> >Silvia > >> > > >> >-----Urspr??ngliche Nachricht----- > >> >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedik= t > >> >Stockebrand > >> >Gesendet: Sonntag, 17. Mai 2015 18:39 > >> >An: ipv6-wg@ripe.net > >> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > >> > > >> >Hi Enno and list, > >> > > >> >Enno Rey writes: > >> > > >> >> hope everybody had a great #RIPE70 meeting. We did! > >> >> Many thanks to the organizers and chairs! > >> > > >> >and thanks to the actual speakers as well the speakers we had to turn > >> >down due to time constraints, too:-) > >> > > >> >> If the chairs consider this appropriate we will happily give a > >> >> presentation on this stuff in Bucharest or at another occasion. > >> > > >> >Sounds good to me! > >> > > >> >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > >> >> their number, order[...] > >> > > >> >Actually, as far as I'm concerned that's the real core of the problem= . > >> >Or more specifically, the first two lines of RFC 2460, section 4.1: > >> > > >> > When more than one extension header is used in the same packet, it > >>is > >> > recommended that those headers appear in the following order: > >> > > >> >followed on the next page by > >> > > >> > Each extension header should occur at most once, except for the > >> > Destination Options header which should occur at most twice (once > >> > before a Routing header and once before the upper-layer header). > >> > > >> >Note in particular that these are not even RFC 2119 "SHOULD" or > >> >"RECOMMENDED" and such. > >> > > >> >The impact here is actually at least twofold: > >> > > >> >- It is impossible to implement this as a simple pipeline architectur= e > >> > in hardware; at least for cases deviating from the "recommendations= " > >> > above this effectively becomes either excessively complex to > >>implement > >> > in hardware or an invitation to DoS when implemented in software on > >>an > >> > otherwise hardware router. > >> > > >> >- As I understand it, at least some of the issues you have found are > >> > effectively based on violating the second paragraph quoted, making = it > >> > impossible to come up with a lower bound on how long the header cha= in > >> > can actually get and therefore leading to the fragmentation related > >> > attacks and similar you have discovered. > >> > > >> >The original idea was that the extension headers are processed strict= ly > >> >in the order they occur, so one question to ask is if there is any > >>valid > >> >reason to violate these "recommendations" for other than malicious > >> >purposes. > >> > > >> > > >> >Cheers, > >> > > >> > Benedikt > >> > > >> >-- > >> >Benedikt Stockebrand, Stepladder IT > >>Training+Consulting > >> >Dipl.-Inform. http://www.stepladder-it.com/ > >> > > >> > Business Grade IPv6 --- Consulting, Training, Projects > >> > > >> >BIVBlog---Benedikt's IT Video Blog: > >>http://www.stepladder-it.com/bivblog/ > >> > > >> > > >> > > > >-- > >Enno Rey > > > >ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > >Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > > >Handelsregister Mannheim: HRB 337135 > >Geschaeftsfuehrer: Enno Rey > > > >=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=3D=3D= =3D=3D=3D=3D=3D=3D > >Blog: www.insinuator.net || Conference: www.troopers.de > >Twitter: @Enno_Insinuator > >=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=3D=3D= =3D=3D=3D=3D=3D=3D > > > >_______________________________________________ > >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 > > > --14dae9cc9c5a8ea8060518a244a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, June 15, 2015, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:
=
From: Ca By <cb.list6@gmail.com>
To: Eric Vyncke (evyncke) <evyncke@cisco.com>
Cc: "v6ops@ietf.org" <= ;v6ops@ietf.org>; "ipv6-w= g@ripe.net" <ipv6-wg@ripe.net>
= Sent: Tuesday, 16 June 2015,= 8:32
Subject: Re: [v6op= s] Extension Headers / Impact on Security Devices
<= br>


On Monday, June 15, 2015= , Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
Enno,
As you probably know, Cisco handles PSIRT issues with care, so, I have no clue on this specific advisory. My own (educated) guess is that the packet<= br clear=3D"none"> causing a LC reload is fully RFC 2460 compliant but unusual, so, probably (a guess again) a combination of extension headers triggering a bug.

In this specific case, I would not blame IPv6 or RFC 2460 but rather my
own company (even if the affected versions were quite old as new IOS-XR
versions appear to be immune to this bug). And I appreciate the humor in your rhetorical question about which FW could protect a CRS... Air gap
probably :-)

More generally, regarding the 'parsing of the header' and performan= ce, my
understanding (and I am NOT a HW engineer) is that there are multiple ways<= br clear=3D"none"> to parse the header chain:
- purely software in low-end devices, should have a marginal performance impact
- specific ASIC in middle-end devices (read high end enterprise), probably<= br clear=3D"none"> some limitations and heavy performance impact (but again within one
organization, so, easier to fix the root cause)
- a lot of specialized network processors in high-end devices (SP gears), which is a similar case as the 'low-end device', performance impact= but
marginal as parsing the chain of headers is not that hard after all _when_<= br clear=3D"none"> coded correctly

As the extension headers are specific to IPv6, this is an area when we
will all learn (and have learned already) a lot of things...

I respectfully disagree with your last sentence. Of course, destination
AS/host SHOULD only accept useful, known and legit ext headers; but, why would an ISP filter on ext headers if they do not harm their own infra or a customer infra? Do you envision an Internet where only TCP/443 and
UDP/43 would be accepted?

Last point, the Internet will have to use IPv6 for 10 or 20 years at
least. If the IETF/ISP block all new _options_ in _existing_ extension
headers, then we will be stuck in 1997 for network innovation. While I do not like taking security risks, I even fear more the lack of innovation.


I keep hearing this and it is very bizarre to hear=C2= =A0

With regards to 1997, believing= that there will be innovation in the narrow waist of hour glass (network l= ayer), that is very 1997. The network layer is stable and boring.... Hence = it being narrow.=C2=A0 Innovation is welcome everywhere except network in t= he e2e model

/ Absence of evidence is not evidence= of absence.=C2=A0

/ Consider what the network= and host situation was in 1997 (wired network access, desktops outselling = laptops, dialup Internet for residential, corporates in total probably bein= g the largest spenders on Internet access) to today and the near future (wi= reless networks, smartphones/tablets being the dominant Internet access dev= ice in some markets - and they're multi-homed, M2M/IoT considered to be= place where the greatest expansion of Internet connected devices is going = to occur in the near future.)

/ IPv6 h= as had relatively little adoption, and it is only starting to increase quit= e rapidly in the last few years and that is mainly because of mobile networ= ks. There hasn't and still doesn't seem to be much thinking about h= ow IPv6's differences from IPv4's can be taken advantage of yet - a= n "IPv4 first" or an "IPv4 =3D=3D IPv6" mindset seems t= o be still very common (I think the network virtualisation space is where t= his is might be most prominent - I think most of the technologies they'= re inventing require fork lift network upgrades, so the costs of deploying = IPv6 at the same time become a lot less significant. So if there is a "= ;cheap" opportunity to deploy IPv6, and IPv6 is going to be the long t= erm network layer 3, why not optimise for it now? That was the thinking beh= ind my "Enhancing Virtual Network Encapsulation with IPv6" draft)= =C2=A0

/ We don't want= to disable innovation opportunities that IPv6 may provide before people ha= ve arrived at an "IPv6 first" or "IPv4 !=3D IPv6" minds= et. =C2=A0


=

I have heard those stories, i don= 9;t find them compelling.=C2=A0

CB=C2=A0
=C2=A0=C2=A0
Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-)
-=C3=A9ric

On 11/06/15 11:58, "Enno Rey" <erey@ernw.de> wrote:
>
>the problem here is the definition of "normal IP packet" as o= f RFC2460.
>To illustrate this I just quote from today's Cisco advisory (Cisco = IOS XR
>Software Crafted IPv6 Packet Denial of Service Vulnerability) on packet= s
>potentially crashing CRS-3 line cards:
>
>"The vulnerability is due to incorrect processing of an IPv6 packe= t
>carrying IPv6 extension headers that are valid but unlikely to be seen<= br clear=3D"none"> >during normal operation. An attacker could exploit this vulnerability b= y
>sending such an IPv6 packet to an affected device that is configured to=
>process IPv6 traffic. An exploit could allow the attacker to cause a >reload of the line card, resulting in a DoS condition."
>
>two question come to mind here:
>
>- is a "valid but unlikely" extension header chain "norm= al"?
>- what ("combination of FW & IPS or whatever") would you = put in front of
>a CRS?
>
>my (sad) expectation is that we'll see much more of these (types of= )
>issues in the future. given the current level of freedom that the RFC24= 60
>leaves (see also discussion/picture in
>http://www.= insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/)
>"properly parsing an IPv6 packet, let alone in wire speed" se= ems a pretty
>much unsolvable task to me.
>
>That said I still fail to see any useful extension header besides AH&am= p;ESP
>(not even FH) to be transported in the Internet.
>
>best
>
>Enno
>
>
>
>
>
>
>
> If your firewall cannot implement this policy, then
>> it is time to change or to use a combination of FW & IPS or wh= atever.
>>
>> - network person: as I will live with IPv6 for the rest of my life= ,
>>then I
>> want a way to extend it and I need any packet to travel to my sour= ce to
>>my
>> destination. Any IPv6 packet should be able to traverse the
>> Internet/private network as long as its layer-3 header is valid >> (filtering/dropping can be done exceptionally for good operational=
>> reason). Did we remember the IPv4 teardrop attack? It is blocked b= y
>> default by most routers for years ;-)
>>
>> Bugs will plague us for ever... And make our life more complex tha= n the
>> above description of course ;-)
>>
>> -??ric
>>
>> On 17/05/15 20:43, "Silvia Hagen" <silvia.hagen@sunny.ch> wrote:
>>
>> >Hi
>> >
>> >I keep stumbling about that "recommendational wording&quo= t; in RFC 2460
>> >everytime I teach it.
>> >
>> >Couldn't we update RFC2460 and make this list a strict ord= er?
>> >
>> >I would want my firewall to notify me if the EHs in a packet d= o not
>> >follow the list.
>> >And limiting the number of possible EHs per packet might be a = good
>>idea.
>> >
>> >Silvia
>> >
>> >-----Urspr??ngliche Nachricht-----
>> >Von: ipv6-wg [mailto:ipv6-w= g-bounces@ripe.net] Im Auftrag von Benedikt
>> >Stockebrand
>> >Gesendet: Sonntag, 17. Mai 2015 18:39
>> >An: ipv6-wg@ripe.net >> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security = Devices
>> >
>> >Hi Enno and list,
>> >
>> >Enno Rey <erey@ernw.de> writes:
>> >
>> >> hope everybody had a great #RIPE70 meeting. We did!
>> >> Many thanks to the organizers and chairs!
>> >
>> >and thanks to the actual speakers as well the speakers we had = to turn
>> >down due to time constraints, too:-)
>> >
>> >> If the chairs consider this appropriate we will happily g= ive a
>> >> presentation on this stuff in Bucharest or at another occ= asion.
>> >
>> >Sounds good to me!
>> >
>> >> - looking at the "liberty" RFC2460 provides as = for ext_hdrs (wrt to
>> >> their number, order[...]
>> >
>> >Actually, as far as I'm concerned that's the real core= of the problem.
>> >Or more specifically, the first two lines of RFC 2460, section= 4.1:
>> >
>> >=C2=A0 =C2=A0When more than one extension header is used in th= e same packet, it
>>is
>> >=C2=A0 =C2=A0recommended that those headers appear in the foll= owing order:
>> >
>> >followed on the next page by
>> >
>> >=C2=A0 =C2=A0Each extension header should occur at most once, = except for the
>> >=C2=A0 =C2=A0Destination Options header which should occur at = most twice (once
>> >=C2=A0 =C2=A0before a Routing header and once before the upper= -layer header).
>> >
>> >Note in particular that these are not even RFC 2119 "SHOU= LD" or
>> >"RECOMMENDED" and such.
>> >
>> >The impact here is actually at least twofold:
>> >
>> >- It is impossible to implement this as a simple pipeline arch= itecture
>> >=C2=A0 in hardware; at least for cases deviating from the &quo= t;recommendations"
>> >=C2=A0 above this effectively becomes either excessively compl= ex to
>>implement
>> >=C2=A0 in hardware or an invitation to DoS when implemented in= software on
>>an
>> >=C2=A0 otherwise hardware router.
>> >
>> >- As I understand it, at least some of the issues you have fou= nd are
>> >=C2=A0 effectively based on violating the second paragraph quo= ted, making it
>> >=C2=A0 impossible to come up with a lower bound on how long th= e header chain
>> >=C2=A0 can actually get and therefore leading to the fragmenta= tion related
>> >=C2=A0 attacks and similar you have discovered.
>> >
>> >The original idea was that the extension headers are processed= strictly
>> >in the order they occur, so one question to ask is if there is= any
>>valid
>> >reason to violate these "recommendations" for other = than malicious
>> >purposes.
>> >
>> >
>> >Cheers,
>> >
>> >=C2=A0 =C2=A0 Benedikt
>> >
>> >--
>> >Benedikt Stockebrand,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Stepladder IT
>>Training+Consulting
>> >Dipl.-Inform.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://w= ww.stepladder-it.com/
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Business Grade IPv6 --- Con= sulting, Training, Projects
>> >
>> >BIVBlog---Benedikt's IT Video Blog:
>>http://www.stepladder-it.com/bivblog/<= br clear=3D"none"> >> >
>> >
>>
>
>--
>Enno Rey
>
>ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
>Handelsregister Mannheim: HRB 337135
>Geschaeftsfuehrer: Enno Rey
>
>=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=3D= =3D=3D=3D=3D=3D=3D=3D
>Blog: www.insinuator.net || Conference: ww= w.troopers.de
>Twitter: @Enno_Insinuator
>=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=3D= =3D=3D=3D=3D=3D=3D=3D
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6= ops

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

<= br>
--14dae9cc9c5a8ea8060518a244a0-- From nobody Tue Jun 16 11:54:13 2015 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 630E71A0470 for ; Tue, 16 Jun 2015 11:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 fA1QeRifnLGT for ; Tue, 16 Jun 2015 11:54:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB771A1A20 for ; Tue, 16 Jun 2015 11:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1447; q=dns/txt; s=iport; t=1434480751; x=1435690351; h=from:to:subject:date:message-id:mime-version; bh=G1fsztVGBeyybetHJCHeFOpppufRsiTDgCU//yIs7ck=; b=HZi28I70J0B4ZJj5s5DPyqMk8OO1Z8qeWuB7pSDRMP1TfYKF610n79Yz CON1FD/3TvPTlWEMJ+zPNGSP4IubQOkDWaiNjC1U6haXR22VxfzktPDOx P32sZfalaMYcJBzgvyU7dZU2J8I93hPRmU+AQlO4UAsto+gtwZf2COixR M=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BNBQDzb4BV/4kNJK1bgxBUGkYFwAmFcQGBRzsRAQEBAQEBAYEKhCmBCwGBACcEIYghDac1pkUBAQEHAQEBAQEBHJNogRYFk18BgiGBTWOGc4EzQZJJg1smg3mCNYEBAQEB X-IronPort-AV: E=Sophos; i="5.13,627,1427760000"; d="asc'?scan'208"; a="2141138" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 16 Jun 2015 18:52:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5GIqUnc015043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jun 2015 18:52:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.178]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 16 Jun 2015 13:52:30 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: IPv6 & iOS9 - interesting factoids in this Ars Technica post Thread-Index: AQHQqGWYlWpJDsMry0Cck6ahVOVCow== Date: Tue, 16 Jun 2015 18:52:30 +0000 Message-ID: <3A1298E7-8422-4C03-8DDD-FF728C22165B@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.123] Content-Type: multipart/signed; boundary="Apple-Mail=_1CA32C44-BD0D-47FC-B872-54976270C633"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 16 Jun 2015 18:54:12 -0000 --Apple-Mail=_1CA32C44-BD0D-47FC-B872-54976270C633 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttp://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-servi= ce-is-coming-soon-get-your-apps-ready/ --Apple-Mail=_1CA32C44-BD0D-47FC-B872-54976270C633 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 iQIVAwUBVYBwbUayAOS/EQ8MAQKPERAAzxJ7kd9M8bQ2Ct6b8nhDxfAHWxpquRc7 ojhtmW1dJQZYOwBOK5wrbJKn9Jgudet5Tq4MLy+Z4oKtgWrkiQ/yV3Bb7zVwcgs9 qH1u047oG8rVAz7My030wNMWhRFoAr5Drho3QbV+6DBLzJedtRquwE/O4yfeB19T C34Li0AVbrzRSUuXb5binWE0RmpP2CNCtn4aWbI62wfJPfB5BghUjHLuwpm8jtTZ M6fMi/przHxlm7xBp4m53Sn/ZMcq0eSMi6yGBkvbZbyqNB0OIYpcubZ60bRBx0PY U1XGFfcRYEW1fef/kXspyFxBkBtq7tLvrTQlxlSD4afgZzcNLPzP2pJVC/Yg5gzK 5TU66FMG4qqSfLE8kIzMqaKDMJvRSG5IdCsnAw+SThp3WXlx0V1bLW6Uf4XY+mex cEOFE/b5hNnVxDs6sgtO4hzXWvMkZ/CW06A32oaSL/g04btha41OFM+3PCsHvPtp apxQ49WBTdu0MBylfeLf03NtZ33xJLZ5QTCn/PZC63rmSHDMUKR9MvJYsPZHnhMr sT3KdvJ32oRrR7D2Xs8HcH5kaPCS1YOU4ZQ8VPaDPcyDZ9ck+dI5Dv1DWW60jYIn eDPwLwXaxMsFHxV7Hvc5fiO1T3SX/+udI/3IaHvDnePdwxHAi6moMVIofD2R+MVm htmitvcjpF0= =pMRE -----END PGP SIGNATURE----- --Apple-Mail=_1CA32C44-BD0D-47FC-B872-54976270C633-- From nobody Tue Jun 16 12:03:07 2015 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 777961ACDDC for ; Tue, 16 Jun 2015 12:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 uVTtZls-Ptcv for ; Tue, 16 Jun 2015 12:03:01 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6921ACD68 for ; Tue, 16 Jun 2015 12:02:56 -0700 (PDT) Received: by ykfr66 with SMTP id r66so21496985ykf.0 for ; Tue, 16 Jun 2015 12:02:56 -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:content-transfer-encoding; bh=73E8n4K+zhwsUsCVxIPYH9nRMbRZgYVMD0upz5xRDds=; b=tvnr4ENnxLnFhGwgtxk9ZHulLutnXHIF0gzszRflR0O7k4kpp1wthvH/rxgLkbag9L E/r3GBBvWudgCwz5gHpmyuf6pvLBce7fCJEBGWPto+PhAJVL9ulX4W4MUneuaDquAoBH G7ptHDd9EgPNFa+d5pxd5reai/2WyGE7khUSrFkuQGeXnHK/YDJPO+9m1c+AaUyFFfqk XKY1KwDX6v+HlHcfr0VVr2VLYC86QldIC4kv7J5Ml1zei4vjjo+IbYI0UICL7sljqSvW OLyJ8Pq9M6KuSiiAlD26toSuYjTCslgCrESpQ8X0ZAml+YMb+jptme8s548v+GxKon9k LlDw== X-Received: by 10.52.69.178 with SMTP id f18mr1425495vdu.83.1434481376267; Tue, 16 Jun 2015 12:02:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.82.130 with HTTP; Tue, 16 Jun 2015 12:02:35 -0700 (PDT) In-Reply-To: <20150611165858.GT39827@ernw.de> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> From: Jen Linkova Date: Tue, 16 Jun 2015 21:02:35 +0200 Message-ID: To: Enno Rey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 16 Jun 2015 19:03:02 -0000 On Thu, Jun 11, 2015 at 6:58 PM, Enno Rey wrote: > the problem here is the definition of "normal IP packet" as of RFC2460. The problem here is what one might mean by "normal" (from Oxford dictionary= ): 1) conforming to a standard; 2) usual, typical, or expected; > To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR= Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets p= otentially crashing CRS-3 line cards: > > "The vulnerability is due to incorrect processing of an IPv6 packet carry= ing IPv6 extension headers that are valid but unlikely to be seen during no= rmal operation. An attacker could exploit this vulnerability by sending suc= h an IPv6 packet to an affected device that is configured to process IPv6 t= raffic. An exploit could allow the attacker to cause a reload of the line c= ard, resulting in a DoS condition." > > two question come to mind here: > > - is a "valid but unlikely" extension header chain "normal"? It is "normal" if you define "normal" as "conforming to a standard", but it's not "normal" if you define "normal" as "usual/typical". > - what ("combination of FW & IPS or whatever") would you put in front of = a CRS? Nothing. There is smth to put *on* CRS however - the image which contains the fix... I do not think we should blame a protocol for software bugs. I've seen router crashes caused by ICMP and BGP packets. Shall we go ahead and start discussing deprecation of the two above mentioned protocols? ;) Especially taking into account than some people like filtering ICMP on the edge of their networks? ;) > my (sad) expectation is that we'll see much more of these (types of) issu= es in the future. given the current level of freedom that the RFC2460 leave= s (see also discussion/picture in http://www.insinuator.net/2015/06/is-ipv6= -more-secure-than-ipv4-or-less/) "properly parsing an IPv6 packet, let alon= e in wire speed" seems a pretty much unsolvable task to me. (shameless plug) a group of enthusiasts have just submitted a new version of document which discusses exactly this problem: https://tools.ietf.org/html/draft-wkumari-long-headers-03 Comments are appreciated... --=20 SY, Jen Linkova aka Furry From nobody Tue Jun 16 13:13:15 2015 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 836101B2F23 for ; Tue, 16 Jun 2015 13:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 KlZ9XqxqJx4o for ; Tue, 16 Jun 2015 13:13:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A241B2F22 for ; Tue, 16 Jun 2015 13:13:12 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t5GKBuLl002070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Jun 2015 13:11:59 -0700 (PDT) Message-ID: <5580830A.7010803@isi.edu> Date: Tue, 16 Jun 2015 13:11:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jen Linkova , Enno Rey References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t5GKBuLl002070 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 16 Jun 2015 20:13:13 -0000 On 6/16/2015 12:02 PM, Jen Linkova wrote: > On Thu, Jun 11, 2015 at 6:58 PM, Enno Rey wrote: >> the problem here is the definition of "normal IP packet" as of RFC2460. > > The problem here is what one might mean by "normal" (from Oxford dictionary): > 1) conforming to a standard; > 2) usual, typical, or expected; That's the trouble with extensions. You can't expect them until they're developed AND deployed, so initially they're never "expected" in terms of actual traffic. Except that we SHOULD expect *everything* that's in a spec. Joe From nobody Tue Jun 16 18:24:08 2015 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 CB8741B3635 for ; Tue, 16 Jun 2015 18:24: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 h3WZyICJ0Est for ; Tue, 16 Jun 2015 18:24:05 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8491B362F for ; Tue, 16 Jun 2015 18:24:05 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so26291764pdb.2 for ; Tue, 16 Jun 2015 18:24:04 -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=tTSAORWnQm8i4Q9qPl7ZQKwqcrnxPON5SuQNss3+OLE=; b=z6sg9ZWIRdZD5ZX3OVuTYgD7PY54RezR+vY3Q84Ab0FvZ/TjtE03BqDSe88RDpEDE5 xhzsfdj5nSwo8EsLVTyz4uzjxQpf2lTQxa38MYGW9Aa/j0DUohK5QTqNVyee9x99zdE/ ejkvF3NhtkgyAWM2dfwACarXcrmsR6/Pdo3c3gWHdLNRBFOmuxxkmk/JztYdsUHErdpw lNkDm/d5utEevz3Gxc+vPIlOFs+E9FmEm/WrqGoJhCIIWqebAhWjOfT9BtZowkZ2kyNu prZiHhhoBP8lNj35Movhmz1Vlb90MpmsqdC6IdgB+IpkmppfEzwJnjgs8AloZBXZrkoG zujw== X-Received: by 10.68.202.7 with SMTP id ke7mr5735868pbc.114.1434504244660; Tue, 16 Jun 2015 18:24:04 -0700 (PDT) Received: from ?IPv6:2406:e007:516f:1:28cc:dc4c:9703:6781? ([2406:e007:516f:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id mp3sm2666919pbc.8.2015.06.16.18.24.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 18:24:03 -0700 (PDT) Message-ID: <5580CC33.2080503@gmail.com> Date: Wed, 17 Jun 2015 13:24:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jen Linkova , Enno Rey References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 01:24:07 -0000 On 17/06/2015 07:02, Jen Linkova wrote: ... > (shameless plug) a group of enthusiasts have just submitted a new > version of document which discusses exactly this problem: > > https://tools.ietf.org/html/draft-wkumari-long-headers-03 > > Comments are appreciated... In REQ-2 on HbH headers, you say: > The forwarder MUST > process each option as specified in Section 4.2 of [RFC2460]. That aspect of RFC 2460 was fundamentally changed by RFC 7045. And of course this is the issue addressed by draft-baker-6man-hbh-header-handling. Personally I still think RFC 7045 is the most realistic on this point, but Fred would like things to get better ;-). I'm sure other things in the long-headers draft need revising as a result of RFC 7045, since its whole topic is the handling of extension headers ("This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future.") Y'all also need to take account of RFC 7112, which forbids fragmented header chains. Brian From nobody Tue Jun 16 20:23:15 2015 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 378F71B37C3 for ; Tue, 16 Jun 2015 20:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 94DcBF1DRpjO for ; Tue, 16 Jun 2015 20:23:12 -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 5051D1ACE7C for ; Tue, 16 Jun 2015 20:23:11 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 577E7A2; Wed, 17 Jun 2015 05:23:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1434511389; bh=qE38LjNYEW8j5NpDqltKhMQJ7Uf8j6bfixFbejz0Juk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Z13tFiCD0xVo9uR3+PX3RH63HmLT7rxFznNVjqwiH6n3yQ3mf4tXjPYpbmzM83tY7 eZ/2ceKz6+ORz5eC6BzhwyVgbuKuonWbTiVtRHbVdmN0iL1YzQFRXcs+NivmhPQ0tY cK4ASNqHiMBoKblEZIrVSBjC9+8CcA6oNf/ONXkw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4E290A1; Wed, 17 Jun 2015 05:23:09 +0200 (CEST) Date: Wed, 17 Jun 2015 05:23:09 +0200 (CEST) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> Message-ID: References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@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; format=flowed; charset=US-ASCII Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 17 Jun 2015 03:23:14 -0000 On Tue, 16 Jun 2015, Fred Baker (fred) wrote: > http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/ https://developer.apple.com/videos/wwdc/2015/?id=719 is the talk that discussed this directly. Well worth spending an hour on. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Jun 16 21:45:20 2015 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 8B85F1B3BC3 for ; Tue, 16 Jun 2015 21:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gxfNJBb34r-p for ; Tue, 16 Jun 2015 21:45:18 -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 5F9871B3BC2 for ; Tue, 16 Jun 2015 21:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1883; q=dns/txt; s=iport; t=1434516318; x=1435725918; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zMkqhQr3EyznEbnSEWUMu2s38gyb/kCcti70zMs5+o8=; b=LJKjb/tbPfKi9e4Nu/y4tSzE1+yqpQ7dMJMAtYAeRQ2+oqNmpE70iwoP tGuL/R2K8NAzl+d9CrJcn5CLl3ULZJHqGVhX7EvAfrIz21ZbivEORlTPC Drgdk0mJkM7lNgAbg6OzdrsJnM6PwM1In4833yWkFgwuLr1jqa9MBJrH+ U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CNBABD+oBV/4wNJK1bgxCBMwa+IAmHXQKBTjgUAQEBAQEBAYEKhCIBAQEDAXkFCwIBCBguIRElAgQOBQ6IDAMKCMgfDYVBAQEBAQEBAQEBAQEBAQEBAQEBAQEYi0SCTYI5B4MXgRYBBJNfAYIhgU2FdYFhkQKHFiaDeW8BgUWBAQEBAQ X-IronPort-AV: E=Sophos; i="5.13,630,1427760000"; d="asc'?scan'208"; a="7900033" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jun 2015 04:45:16 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5H4jGLG003325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 04:45:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.178]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 16 Jun 2015 23:45:16 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQqLhnphTDGj0EuU+xxVy221c3fw== Date: Wed, 17 Jun 2015 04:45:15 +0000 Message-ID: <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> In-Reply-To: <5580CC33.2080503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_AB95CB2B-B0CC-4AA7-9798-05D6C5F28777"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 04:45:19 -0000 --Apple-Mail=_AB95CB2B-B0CC-4AA7-9798-05D6C5F28777 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 16, 2015, at 6:24 PM, Brian E Carpenter = wrote: >=20 > Personally I still think RFC 7045 is the most realistic on this point, > but Fred would like things to get better ;-). And I haven't finished with Dennis Ferguson's comment. Bottom line, if one accepts the present status quo as the state forever, = then we should stop with RFC 7045, and (with Fernando) agree to = deprecate all extension headers. I'd like to not do that, and the only = way I see to not do that is to not accept the status quo. --Apple-Mail=_AB95CB2B-B0CC-4AA7-9798-05D6C5F28777 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 iQIVAwUBVYD7WkayAOS/EQ8MAQJwMQ//QSsF1ATMYs5v6Wve+vY0lwRyxhRNQ5Ly nuCvy+Lw+ibs0WKllsXMSjlC8SS/60dw7iq4qbvSJDIvGUwOsP8HIS5B/5LLrYNq ejbs0F+IK8tl2tmqENi4MGqR8zDqPwjUy3HZdtf6IKq5UQU8vfAGgqxf+V3jUWSR QZBJMbXOO2az8V6VaQH9qkYCRHKC0gWZEpKuJzZtnXSj3mxl0KZZmjSFpxOgwA4f 0wFbW/iQp50NeRk2AjBl785vohP0WBah27aGQpFN1qTYm4OYJMTE6/1skbmUunbg Mx7c+KSFFmfWyaMpBJRvdS1kKuz9kLxEAL4/Cp4RfMfyh1s08/mz3aQ7i9F3SfaI mRLsLE7i/PQU4h/+LYq5GCvBm/UywNyqC0vzJTSVhqpEvhdYINFxLgZHYjT0DHnL HLrzOjpe6P4fjKEjhWEKDNsBE1uLQLj1ASBl5RSFi3dtbreTPmFe+GpheirtyQM7 W+ExusMgsIEiy2Mbic0wC1kf2nPA09LiWgBIW/ONfPTF8NCrB4JlQ9DxTkhpyVL7 Iylo6gBSBs9O4iyvfxGLkYlGOTyMBNl6LkvZF8GU1ZGWLKTW1ahV4fN2El1BSUHj /O53/Cg/u6neCKnvu6Enf0OJHMl+6jUjoYaMH/jNrFnsG/DatjyFu+A7DAfU12oB 3nBRSdRjxRQ= =hzE6 -----END PGP SIGNATURE----- --Apple-Mail=_AB95CB2B-B0CC-4AA7-9798-05D6C5F28777-- From nobody Tue Jun 16 21:52:26 2015 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 5D8911B3BD9 for ; Tue, 16 Jun 2015 21:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 QVMaltF2S8Xo for ; Tue, 16 Jun 2015 21:52:24 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315481B3BC2 for ; Tue, 16 Jun 2015 21:52:23 -0700 (PDT) Received: by wiga1 with SMTP id a1so127009054wig.0 for ; Tue, 16 Jun 2015 21:52:22 -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=We9iW1BTh4GQBQmiN8AeCNvUBrIIzKPqwqqe19McuMQ=; b=rgMDgbvo+cNoqZMnpLFtsVdJKVXR9aAYv8bpgLpS28fZv5NMOJBWA0XZ//D1lFIVyb RHtoNURTuEMdvJS1WvWqmKN8vz4k5RC9XYusT6eI9V95gOp+tE18w6SRVVf2SxhkwHdg kcxhECj7encCuQWqWFOQ2ltKyfVOLkPJB7mz6tGgbymg36+bhja/EFNsGlvYrwLa7Zzj JWbgO3p1zhUDO+OVbaKsO6edaLD4/we+7iJYb7NWzL5Mu3OGLtsmFvoeVrigIGdmm1b9 kvwIQqzAlhbM+RpFEAKUURWLj9KMi+31y4Uc7iMEObAwwRStiVc4a60vqoG4s0wvJ4O7 3o0A== MIME-Version: 1.0 X-Received: by 10.194.24.70 with SMTP id s6mr2112855wjf.25.1434516742684; Tue, 16 Jun 2015 21:52:22 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Tue, 16 Jun 2015 21:52:22 -0700 (PDT) In-Reply-To: <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> Date: Tue, 16 Jun 2015 21:52:22 -0700 Message-ID: From: Ca By To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7b4724d8df469d0518af7480 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 04:52:25 -0000 --047d7b4724d8df469d0518af7480 Content-Type: text/plain; charset=UTF-8 On Tuesday, June 16, 2015, Fred Baker (fred) wrote: > > > On Jun 16, 2015, at 6:24 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > Personally I still think RFC 7045 is the most realistic on this point, > > but Fred would like things to get better ;-). > > And I haven't finished with Dennis Ferguson's comment. > > Bottom line, if one accepts the present status quo as the state forever, > then we should stop with RFC 7045, and (with Fernando) agree to deprecate > all extension headers. I'd like to not do that, and the only way I see to > not do that is to not accept the status quo. > So you build a bridge to nowhere? --047d7b4724d8df469d0518af7480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, June 16, 2015, Fred Baker (fred) <fred@cisco.com> wrote:

> On Jun 16, 2015, at 6:24 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> Personally I still think RFC 7045 is the most realistic on this point,=
> but Fred would like things to get better ;-).

And I haven't finished with Dennis Ferguson's comment.

Bottom line, if one accepts the present status quo as the state forever, th= en we should stop with RFC 7045, and (with Fernando) agree to deprecate all= extension headers. I'd like to not do that, and the only way I see to = not do that is to not accept the status quo.


So you build a bridge to no= where?

=C2=A0
--047d7b4724d8df469d0518af7480-- From nobody Tue Jun 16 23:11:15 2015 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 9167B1A00E7 for ; Tue, 16 Jun 2015 23:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, T_RP_MATCHES_RCVD=-0.01] 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 o_keO3IQt2l7 for ; Tue, 16 Jun 2015 23:11:13 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3050E1A00E6 for ; Tue, 16 Jun 2015 23:11:13 -0700 (PDT) Received: by wiwd19 with SMTP id d19so122321735wiw.0 for ; Tue, 16 Jun 2015 23:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OpZcr+1kFy9gjc46+vMEVJNxYpr4IB6OPz6W/xnkbe0=; b=dvi3UvYabL+S3nmO4l3Bfyh+RPURJ6STedPXK7K+nOWUFY4UqQtKdY94eFUmHRXb8g CrtI0IBWHF65qITIxS6XNZjp++P8wro+9ohCCJLc0Hun03ZL3ETL77xEP32mmVhprQx3 4DMXpX170Oi1LODn2gtKHtoWrdD3TiWoeGK87qiccH+N7+h2WFEOkvVsKbg3gQMPB90m GYT0eFzgfDCzH6cpGYNR0mVpNooVv/qbAiwD653vBKHA4WiypFFy8i+CpaHfZLzbWPdE i5OYWUFePlXYGKyqbCh9TND0Dj/1lASG1AWWV5yTzliyr+QqIq+gayob/yTnK/Y6VaTC rbaA== 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:from:date :message-id:subject:to:cc:content-type; bh=OpZcr+1kFy9gjc46+vMEVJNxYpr4IB6OPz6W/xnkbe0=; b=Fs2nTGRT+BlOlcR8vSO7OZAAetKK/ZcpOmLTmE9a9nPHePIWzl1xMUyg7siYeag2eg gvwWYTNH9SkBGXzxpCONUDe4oNNhlRRWddy9T0Vc7pozoukeFekOh536y9zfB4uV452L 8rDhWCzJHbiOSUP/MHl1dPZcDkK9Z7AmWhQD+Jsym0T7Qi6MI8cj/HtdABv1RgYt5UEf kxj+GleEO9M5WPyZ1QbqFSiM7mYgBi+0n8tfAVw0mEqzloCqp1ILjejhz5qZL+agmXLp JUioz4CnJR+gUBYmON9kHsPYxhAkkbvoLy1nXlJZnXWLExPsteoAc9fqNBjK81p58yw4 Xi5g== X-Gm-Message-State: ALoCoQkG5B8pLJVogl8dACGEcfsodwI5ejKKDH3Rn4DKi0d0gvJVci6yntxE+fub/IfvciRpr/5a X-Received: by 10.180.9.7 with SMTP id v7mr14288246wia.60.1434521471820; Tue, 16 Jun 2015 23:11:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.3 with HTTP; Tue, 16 Jun 2015 23:10:51 -0700 (PDT) In-Reply-To: References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> From: Erik Kline Date: Wed, 17 Jun 2015 15:10:51 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 17 Jun 2015 06:11:14 -0000 On Wed, Jun 17, 2015 at 12:23 PM, Mikael Abrahamsson wrote: > On Tue, 16 Jun 2015, Fred Baker (fred) wrote: > >> >> http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/ > > > https://developer.apple.com/videos/wwdc/2015/?id=719 is the talk that > discussed this directly. Well worth spending an hour on. Sigh. "Streaming is available in Safari, and through the WWDC app." From nobody Tue Jun 16 23:13:53 2015 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 12EC11A009B for ; Tue, 16 Jun 2015 23:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2tHdH0jztEr2 for ; Tue, 16 Jun 2015 23:13:49 -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 01ABC1A0089 for ; Tue, 16 Jun 2015 23:13:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 12E9DA2; Wed, 17 Jun 2015 08:13:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1434521626; bh=/Xe7/9Vuhi2wgAauyU108b21oUYHoSWJLQuEtoKpzP0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VGFneX++SWnMr7py//EBGfHj2ZylnLStf1v8bx3SgIQHwBD+2NX1Z1yZNcCQ/YpFZ 6IUtPNCfBxfhFgKfjPyRSBKXPlsGII+g1/kXZ4pipNkZFkzzBpSd9LtKvptqOimI/l kYUKFy9VnRZCmkQWgdHCj9Sj+xQJYPJvn9Ucup9E= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 03EF0A1; Wed, 17 Jun 2015 08:13:46 +0200 (CEST) Date: Wed, 17 Jun 2015 08:13:45 +0200 (CEST) From: Mikael Abrahamsson To: Erik Kline In-Reply-To: Message-ID: References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@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; format=flowed; charset=US-ASCII Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 17 Jun 2015 06:13:51 -0000 On Wed, 17 Jun 2015, Erik Kline wrote: > Sigh. > > "Streaming is available in Safari, and through the WWDC app." There is a download link at the bottom right, and vlc and mplayer can play these streams. Yes, I agree that it's a pain, but... Actually, if you paste into "open network stream" in VLC, it'll stream it just fine. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jun 17 00:41:42 2015 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 6815E1A1B7B for ; Wed, 17 Jun 2015 00:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.511 X-Spam-Level: X-Spam-Status: No, score=-116.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 VgrIaio36rcH for ; Wed, 17 Jun 2015 00:41:39 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742591A1BA7 for ; Wed, 17 Jun 2015 00:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7858; q=dns/txt; s=iport; t=1434526895; x=1435736495; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ryfnfIL64UANv5r/gTCnWerMD52HhIYjLoqUtYadvOU=; b=euSIwZUhAntQdBArgSKYLF/iwQaWvmvJDXCiVMTrCgwVIaou2TUNxPfP dcwD5SKz01Wg6maoE9ihxy5Ml1cG3hNOplRsHLO3bQ15fqRgvJ8NW3ulP +apVTX4Fn/Ynm/DN/jrQHRXZoIuzKkj2OLaQPAtV8NzTKFiJW+DNQUxry 0=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQAhJIFV/5ldJa1bgxBUXwa/bwyFdgKBTjsRAQEBAQEBAYEKhCIBAQECAQEBAQFGHwYLBQsCAQgOBAYnBycLFAMOAgQOBQ4OiAsIDc1EAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pCgQKEIxEBUQcJgw6BFAWREYJXAYIhgU2BRoFzhB+BNIcTh1uHfiaCCxyBUm+BDDqBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,631,1427760000"; d="asc'?scan'208";a="160077116" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 17 Jun 2015 07:41:34 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5H7fYhZ015863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 07:41:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.178]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 02:41:34 -0500 From: "Fred Baker (fred)" To: Enno Rey Thread-Topic: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices Thread-Index: AQHQqNEIg5ZU+gtmFE6PqXTscgbWoA== Date: Wed, 17 Jun 2015 07:41:33 +0000 Message-ID: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> In-Reply-To: <20150517191841.GA26929@ernw.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_5F3E814B-42A6-485B-AD3E-62527ECCCDA2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 07:41:41 -0000 --Apple-Mail=_5F3E814B-42A6-485B-AD3E-62527ECCCDA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm of course missing the preceding email. No problem with the = cross-posting, but let's get the question on the table? Is this section = 4.1's statement that "it is recommended that those headers appear in the = following order"? I have a hunch that an internet draft requiring headers to be in the = listed order would be looked at with approbation. The issue, if any, = would likely have regard to repeated Destination Option headers. However Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). seems to me fairly definitive. Fernando would like to see a specification of how long the entire list = of extension headers may be, in terms of "how large of a hardware buffer = has to be implemented in a switch?" That has a couple of issues related = to "why does one have to ask the question?" The hardware should = definitely be large enough to read in the IPv6 header, the HBH Header, = and the Routing Header. After that, the only host that SHOULD need to = read it all in is the host itself, and the host can do its processing = from RAM. There is one "gotcha" case, which is when someone uses an ACL = (disallowing Fragmentation Headers, perhaps, or looking for the TCP = port, meaning one has to ask whether a given packet is TCP and what its = port number is). The firewall is going to have to chase down the chain = of extension headers. How big is a HBH header? How big is a routing option such as the Segment = Routing option? If that's a list of 27 services, each with a 16 byte = IPv6 address... > On May 17, 2015, at 12:18 PM, Enno Rey wrote: >=20 > Hi Silvia, >=20 > On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote: >> Hi >>=20 >> I keep stumbling about that "recommendational wording" in RFC 2460 = everytime I teach it. >>=20 >> Couldn't we update RFC2460 and make this list a strict order? >=20 > good luck bringing this suggestion to IETF 6man... ;-) >=20 >=20 >=20 >>=20 >> I would want my firewall to notify me if the EHs in a packet do not = follow the list. >=20 > actually when we tested a number of commercial firewalls in late 2013 = (results here: = https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-project_resu= lts.pdf) it turned out that pretty much all of them follow a (from our = perspective "reasonable approach", that is dropping "unusal combinations = or number of ext_hdrs" by default. (which, of course, violates RFC 2460. = but apparently all major vendors follow a line of reasoning similar to = ours). > so, in short, firewalls "are not affected". >=20 >=20 >> And limiting the number of possible EHs per packet might be a good = idea. >=20 > yes, that _would actually be_ a good idea. >=20 >=20 > I'm cross-posting this to v6ops as there's a related discussion going = on right now. pls forgive this potential Usenet etiquette violation. >=20 > best >=20 > Enno >=20 >=20 >=20 >=20 >>=20 >> Silvia >>=20 >> -----Urspr?ngliche Nachricht----- >> Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von = Benedikt Stockebrand >> Gesendet: Sonntag, 17. Mai 2015 18:39 >> An: ipv6-wg@ripe.net >> Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices >>=20 >> Hi Enno and list, >>=20 >> Enno Rey writes: >>=20 >>> hope everybody had a great #RIPE70 meeting. We did! >>> Many thanks to the organizers and chairs! >>=20 >> and thanks to the actual speakers as well the speakers we had to turn = down due to time constraints, too:-) >>=20 >>> If the chairs consider this appropriate we will happily give a >>> presentation on this stuff in Bucharest or at another occasion. >>=20 >> Sounds good to me! >>=20 >>> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to >>> their number, order[...] >>=20 >> Actually, as far as I'm concerned that's the real core of the = problem. >> Or more specifically, the first two lines of RFC 2460, section 4.1: >>=20 >> When more than one extension header is used in the same packet, it = is >> recommended that those headers appear in the following order: >>=20 >> followed on the next page by >>=20 >> Each extension header should occur at most once, except for the >> Destination Options header which should occur at most twice (once >> before a Routing header and once before the upper-layer header). >>=20 >> Note in particular that these are not even RFC 2119 "SHOULD" or = "RECOMMENDED" and such. >>=20 >> The impact here is actually at least twofold: >>=20 >> - It is impossible to implement this as a simple pipeline = architecture >> in hardware; at least for cases deviating from the "recommendations" >> above this effectively becomes either excessively complex to = implement >> in hardware or an invitation to DoS when implemented in software on = an >> otherwise hardware router. >>=20 >> - As I understand it, at least some of the issues you have found are >> effectively based on violating the second paragraph quoted, making = it >> impossible to come up with a lower bound on how long the header = chain >> can actually get and therefore leading to the fragmentation related >> attacks and similar you have discovered. >>=20 >> The original idea was that the extension headers are processed = strictly in the order they occur, so one question to ask is if there is = any valid reason to violate these "recommendations" for other than = malicious purposes. >>=20 >>=20 >> Cheers, >>=20 >> Benedikt >>=20 >> -- >> Benedikt Stockebrand, Stepladder IT = Training+Consulting >> Dipl.-Inform. http://www.stepladder-it.com/ >>=20 >> Business Grade IPv6 --- Consulting, Training, Projects >>=20 >> BIVBlog---Benedikt's IT Video Blog: = http://www.stepladder-it.com/bivblog/ >>=20 >>=20 >=20 > -- > Enno Rey >=20 > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 >=20 > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey >=20 > =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=3D=3D= =3D=3D=3D=3D=3D=3D > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > =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=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_5F3E814B-42A6-485B-AD3E-62527ECCCDA2 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 iQEVAwUBVYEkrJ9ieig10VPpAQIDVAf/bw229S2hEoncQv+ZvqPWqDPmYxLE+wuU VHNX8Eiw6aakGQkIAE7Bb9wXBQqTjknFGBc70C37W8gHNwcEklZvUPZKhtM8htXT /9LNCX6sWkP+0O3L76Onded2lOl44tpncBA4amWJD4GKlG5LG3xnWu9IJSlR1Mps L8VSnUhmMumhJR/gM1f11xqnZwC+ufBY/PBongo1GY0Tn3OUXCu1Ug1A1SObV70j Db9l8xAUuFTvbGHptCRJGIn7qHEGxApVVwqUR/nPIYJbFWLGpNQzJyAtmT9Wz5xo DdYUjbPLYZpmONnaBoqBVeQnERh3dVbWuCSGQtMNEunUz/sWeEZ0aw== =3C48 -----END PGP SIGNATURE----- --Apple-Mail=_5F3E814B-42A6-485B-AD3E-62527ECCCDA2-- From nobody Wed Jun 17 01:14:32 2015 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 17E5C1A6F7A for ; Wed, 17 Jun 2015 01:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 O4pror8hpzC4 for ; Wed, 17 Jun 2015 01:14:28 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 47FDF1A6F39 for ; Wed, 17 Jun 2015 01:14:27 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 60FC4748B0; Wed, 17 Jun 2015 10:14:25 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 3CED7D73; Wed, 17 Jun 2015 10:14:25 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 0C92EC4102; Wed, 17 Jun 2015 10:14:25 +0200 (CEST) Date: Wed, 17 Jun 2015 10:14:25 +0200 From: Enno Rey To: "Fred Baker (fred)" Message-ID: <20150617081424.GA15514@ernw.de> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 08:14:32 -0000 Fred, All, On Wed, Jun 17, 2015 at 07:41:33AM +0000, Fred Baker (fred) wrote: > I'm of course missing the preceding email. No problem with the cross-posting, but let's get the question on the table? Is this section 4.1's statement that "it is recommended that those headers appear in the following order"? > > I have a hunch that an internet draft requiring headers to be in the listed order would be looked at with approbation. The issue, if any, would likely have regard to repeated Destination Option headers. However > > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > > seems to me fairly definitive. I'm not so sure about this. First probably a capital "SHOULD" would have been more appropriate. Second - and this is our main point/observation - there's too much space of interpretation for actual implementation. To underline this I will just cite two somewhat random sections from the study we performed on evading security controls (IDPS systems) by means of extension headers, combined with fragmentation (https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf). One of the devices (all of them latest code incl. some high-end gear) could be evaded by the following: "Case 1: - An IPv6 Routing Header Type 0 in the unfragmentable part is used. - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 Destinations Option header is padded with six (6) octets of bytes (at least). - AND The IPv6 datagram is fragmented in 2 fragments. Case 2: - An IPv6 Hop-by-Hop Option Header and Routing Header Type 0 in the unfragmentable part is used - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 datagram is fragmented in 2 fragments. Case 3: - An IPv6 Destination Option Header and Routing Header Type 0 in the unfragmentable part is used. - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 datagram is fragmented in 2 fragments. Case 4: - An IPv6 Hop-by-Hop, Destination Option Header and Routing Header Type 0 in the unfragmentable part is used - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 datagram is fragmented in 2 fragments." Another one by the following: "a. The unfragmentable part consists of three (3) Destination Option headers b. The fragmentable part consists of two (2) Destination Option headers plus the layer 4 header. c. The aforementioned datagram is split in two fragments." It should be noted that most operating systems happily accept and process (incl., ofc, reassembly) packets crafted in such ways. [see results section in https://www.ernw.de/download/Advanced%20Attack%20Techniques%20against%20IPv6%20Networks-final.pdf]. It should further be noted that some of the techniques we used would even have worked in settings where RFC 7112 would have been strictly applied. > > Fernando would like to see a specification of how long the entire list of extension headers may be, in terms of "how large of a hardware buffer has to be implemented in a switch?" That has a couple of issues related to "why does one have to ask the question?" The hardware should definitely be large enough to read in the IPv6 header, the HBH Header, and the Routing Header. After that, the only host that SHOULD need to read it all in is the host itself, and the host can do its processing from RAM. There is one "gotcha" case, which is when someone uses an ACL (disallowing Fragmentation Headers, perhaps, or looking for the TCP port, meaning one has to ask whether a given packet is TCP and what its port number is). The firewall is going to have to chase down the chain of extension headers. Which might be a quite difficult task (not least performance-wise) once this chain, by definition, is abitrarily long. best Enno > > How big is a HBH header? How big is a routing option such as the Segment Routing option? If that's a list of 27 services, each with a 16 byte IPv6 address... > > > On May 17, 2015, at 12:18 PM, Enno Rey wrote: > > > > Hi Silvia, > > > > On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote: > >> Hi > >> > >> I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it. > >> > >> Couldn't we update RFC2460 and make this list a strict order? > > > > good luck bringing this suggestion to IETF 6man... ;-) > > > > > > > >> > >> I would want my firewall to notify me if the EHs in a packet do not follow the list. > > > > actually when we tested a number of commercial firewalls in late 2013 (results here: https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-project_results.pdf) it turned out that pretty much all of them follow a (from our perspective "reasonable approach", that is dropping "unusal combinations or number of ext_hdrs" by default. (which, of course, violates RFC 2460. but apparently all major vendors follow a line of reasoning similar to ours). > > so, in short, firewalls "are not affected". > > > > > >> And limiting the number of possible EHs per packet might be a good idea. > > > > yes, that _would actually be_ a good idea. > > > > > > I'm cross-posting this to v6ops as there's a related discussion going on right now. pls forgive this potential Usenet etiquette violation. > > > > best > > > > Enno > > > > > > > > > >> > >> Silvia > >> > >> -----Urspr?ngliche Nachricht----- > >> Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand > >> Gesendet: Sonntag, 17. Mai 2015 18:39 > >> An: ipv6-wg@ripe.net > >> Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > >> > >> Hi Enno and list, > >> > >> Enno Rey writes: > >> > >>> hope everybody had a great #RIPE70 meeting. We did! > >>> Many thanks to the organizers and chairs! > >> > >> and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-) > >> > >>> If the chairs consider this appropriate we will happily give a > >>> presentation on this stuff in Bucharest or at another occasion. > >> > >> Sounds good to me! > >> > >>> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > >>> their number, order[...] > >> > >> Actually, as far as I'm concerned that's the real core of the problem. > >> Or more specifically, the first two lines of RFC 2460, section 4.1: > >> > >> When more than one extension header is used in the same packet, it is > >> recommended that those headers appear in the following order: > >> > >> followed on the next page by > >> > >> Each extension header should occur at most once, except for the > >> Destination Options header which should occur at most twice (once > >> before a Routing header and once before the upper-layer header). > >> > >> Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such. > >> > >> The impact here is actually at least twofold: > >> > >> - It is impossible to implement this as a simple pipeline architecture > >> in hardware; at least for cases deviating from the "recommendations" > >> above this effectively becomes either excessively complex to implement > >> in hardware or an invitation to DoS when implemented in software on an > >> otherwise hardware router. > >> > >> - As I understand it, at least some of the issues you have found are > >> effectively based on violating the second paragraph quoted, making it > >> impossible to come up with a lower bound on how long the header chain > >> can actually get and therefore leading to the fragmentation related > >> attacks and similar you have discovered. > >> > >> The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes. > >> > >> > >> Cheers, > >> > >> Benedikt > >> > >> -- > >> Benedikt Stockebrand, Stepladder IT Training+Consulting > >> Dipl.-Inform. http://www.stepladder-it.com/ > >> > >> Business Grade IPv6 --- Consulting, Training, Projects > >> > >> BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > >> > >> > > > > -- > > Enno Rey > > > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > > > Handelsregister Mannheim: HRB 337135 > > Geschaeftsfuehrer: Enno Rey > > > > ======================================================= > > Blog: www.insinuator.net || Conference: www.troopers.de > > Twitter: @Enno_Insinuator > > ======================================================= > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Jun 17 03:02:03 2015 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 B69391A888F for ; Wed, 17 Jun 2015 03:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 wCcBpkcaB81L for ; Wed, 17 Jun 2015 03:01:54 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6195C1A8880 for ; Wed, 17 Jun 2015 03:01:54 -0700 (PDT) Received: by yhan67 with SMTP id n67so29986578yha.3 for ; Wed, 17 Jun 2015 03:01:53 -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:content-transfer-encoding; bh=jC2yxVJTPIaYBEybUdn1jtBMBK7kkAIpM1xxubEPjwg=; b=DtwIsgFpPurWzB8eLXRYNYxGKQ3HUdp9OPgQ+GyFiwi1aS2s72LAl9AN8pWAc9pt7S LYQIS+dej8Q8TL0hT1ubMgyn2PxJUqBbCtESZD80+9V8VITvJTM7zusNs26bRAplCnyr 75e+DK/rrf+HQTQyrcH+vD30eNsYfq0v3Jxp0PPRxaKFmrupgeHYuxLlxsXnHzjeXqTd k7n1+GXIsT5yBHUieoPJYuuJ4gcCDrAHFWEO4v+eeO9Ha6EWBVTQvHdBZ1m+I77t+XF9 z0zMiLDp5o9/bDWOq6lgkdcA5oeS3ktZmPW2Jnbx9H6hU8Tfzk7L+ozMUmGr+MxcxQ+/ y+Ag== X-Received: by 10.52.227.200 with SMTP id sc8mr4193497vdc.35.1434535313639; Wed, 17 Jun 2015 03:01:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 03:01:33 -0700 (PDT) In-Reply-To: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> From: Jen Linkova Date: Wed, 17 Jun 2015 12:01:33 +0200 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 10:02:01 -0000 On Wed, Jun 17, 2015 at 9:41 AM, Fred Baker (fred) wrote: > Fernando would like to see a specification of how long the entire list of= extension headers may be, in terms of "how large of a hardware buffer has = to be implemented in a switch?" That has a couple of issues related to "why= does one have to ask the question?" The hardware should definitely be larg= e enough to read in the IPv6 header, the HBH Header, and the Routing Header= . After that, the only host that SHOULD need to read it all in is the host = itself, and the host can do its processing from RAM. There is one "gotcha" = case, which is when someone uses an ACL (disallowing Fragmentation Headers,= perhaps, or looking for the TCP port, meaning one has to ask whether a giv= en packet is TCP and what its port number is). The firewall is going to hav= e to chase down the chain of extension headers. I agree. There is a definitely a big difference in requirements for "traditional routers" and devices which are going to implement ACLs (and other types of "multifields classifications" (as QoS based other data than IP header). IMHO it's reasonable to assume that one might need different hardware for "just routing" and enhanced QoS/ACL services (it's a case nowadays anyway). For the latter case the device has to either, as you said, chaise the whole chain down (which might be as long as the whole packet) or have a way to deal with packets it could not parse (applying a specific policy to such packets). > How big is a HBH header? How big is a routing option such as the Segment = Routing option? If that's a list of 27 services, each with a 16 byte IPv6 a= ddress... I'd like to point out that the problem is not specific to IPv6 at all. How deep is MPLS label stack? Where are TCP flags or port number in the packet (so I can match 'tcp established' or 'tcp 443')? oops, we don't know....it depends...so some linecards do not copy enough data, some (newer ones) do. We do not know (could not know) exact numbers, the requirements are changing, so does the hardware we deploy in out network. It's a kind of race ;) and as long as there is a way to predict/configure the behavior of the device when it could not fully parse the packet - I'm fine with it.. > >> On May 17, 2015, at 12:18 PM, Enno Rey wrote: >> >> Hi Silvia, >> >> On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote: >>> Hi >>> >>> I keep stumbling about that "recommendational wording" in RFC 2460 ever= ytime I teach it. >>> >>> Couldn't we update RFC2460 and make this list a strict order? >> >> good luck bringing this suggestion to IETF 6man... ;-) >> >> >> >>> >>> I would want my firewall to notify me if the EHs in a packet do not fol= low the list. >> >> actually when we tested a number of commercial firewalls in late 2013 (r= esults here: https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-= project_results.pdf) it turned out that pretty much all of them follow a (f= rom our perspective "reasonable approach", that is dropping "unusal combina= tions or number of ext_hdrs" by default. (which, of course, violates RFC 24= 60. but apparently all major vendors follow a line of reasoning similar to = ours). >> so, in short, firewalls "are not affected". >> >> >>> And limiting the number of possible EHs per packet might be a good idea= . >> >> yes, that _would actually be_ a good idea. >> >> >> I'm cross-posting this to v6ops as there's a related discussion going on= right now. pls forgive this potential Usenet etiquette violation. >> >> best >> >> Enno >> >> >> >> >>> >>> Silvia >>> >>> -----Urspr?ngliche Nachricht----- >>> Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt = Stockebrand >>> Gesendet: Sonntag, 17. Mai 2015 18:39 >>> An: ipv6-wg@ripe.net >>> Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices >>> >>> Hi Enno and list, >>> >>> Enno Rey writes: >>> >>>> hope everybody had a great #RIPE70 meeting. We did! >>>> Many thanks to the organizers and chairs! >>> >>> and thanks to the actual speakers as well the speakers we had to turn d= own due to time constraints, too:-) >>> >>>> If the chairs consider this appropriate we will happily give a >>>> presentation on this stuff in Bucharest or at another occasion. >>> >>> Sounds good to me! >>> >>>> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to >>>> their number, order[...] >>> >>> Actually, as far as I'm concerned that's the real core of the problem. >>> Or more specifically, the first two lines of RFC 2460, section 4.1: >>> >>> When more than one extension header is used in the same packet, it is >>> recommended that those headers appear in the following order: >>> >>> followed on the next page by >>> >>> Each extension header should occur at most once, except for the >>> Destination Options header which should occur at most twice (once >>> before a Routing header and once before the upper-layer header). >>> >>> Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMM= ENDED" and such. >>> >>> The impact here is actually at least twofold: >>> >>> - It is impossible to implement this as a simple pipeline architecture >>> in hardware; at least for cases deviating from the "recommendations" >>> above this effectively becomes either excessively complex to implement >>> in hardware or an invitation to DoS when implemented in software on an >>> otherwise hardware router. >>> >>> - As I understand it, at least some of the issues you have found are >>> effectively based on violating the second paragraph quoted, making it >>> impossible to come up with a lower bound on how long the header chain >>> can actually get and therefore leading to the fragmentation related >>> attacks and similar you have discovered. >>> >>> The original idea was that the extension headers are processed strictly= in the order they occur, so one question to ask is if there is any valid r= eason to violate these "recommendations" for other than malicious purposes. >>> >>> >>> Cheers, >>> >>> Benedikt >>> >>> -- >>> Benedikt Stockebrand, Stepladder IT Training+Consulti= ng >>> Dipl.-Inform. http://www.stepladder-it.com/ >>> >>> Business Grade IPv6 --- Consulting, Training, Projects >>> >>> BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblo= g/ >>> >>> >> >> -- >> Enno Rey >> >> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 >> >> Handelsregister Mannheim: HRB 337135 >> Geschaeftsfuehrer: Enno Rey >> >> =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=3D=3D= =3D=3D=3D=3D=3D=3D >> Blog: www.insinuator.net || Conference: www.troopers.de >> Twitter: @Enno_Insinuator >> =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=3D=3D= =3D=3D=3D=3D=3D=3D >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 SY, Jen Linkova aka Furry From nobody Wed Jun 17 05:02:47 2015 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 3AFEC1A8A84 for ; Wed, 17 Jun 2015 05:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GuL_yoAOIqWS for ; Wed, 17 Jun 2015 05:02:38 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 3F9651A89B5 for ; Wed, 17 Jun 2015 05:02:37 -0700 (PDT) Received: (qmail 27355 invoked from network); 17 Jun 2015 12:02:35 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Jun 2015 12:02:35 -0000 Date: Wed, 17 Jun 2015 14:02:35 +0200 (CEST) Message-Id: <20150617.140235.74748217.sthaug@nethelp.no> To: fred@cisco.com, furry13@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20150517191841.GA26929@ernw.de> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 12:02:46 -0000 > On Wed, Jun 17, 2015 at 9:41 AM, Fred Baker (fred) wrote: > > Fernando would like to see a specification of how long the entire list of extension headers may be, in terms of "how large of a hardware buffer has to be implemented in a switch?" That has a couple of issues related to "why does one have to ask the question?" The hardware should definitely be large enough to read in the IPv6 header, the HBH Header, and the Routing Header. After that, the only host that SHOULD need to read it all in is the host itself, and the host can do its processing from RAM. There is one "gotcha" case, which is when someone uses an ACL (disallowing Fragmentation Headers, perhaps, or looking for the TCP port, meaning one has to ask whether a given packet is TCP and what its port number is). The firewall is going to have to chase down the chain of extension headers. You may call it a firewall. I call it a "border router" - and the difference between this and a firewall is striking. Most importantly, my border routers don't keep state for the sessions passing through them. However, I *do* expect them to handle basic stateless ACLs, including L4 info (port numbers). For IPv4 and IPv6. > I agree. There is a definitely a big difference in requirements for > "traditional routers" and devices which are going to implement ACLs > (and other types of "multifields classifications" (as QoS based other > data than IP header). IMHO it's reasonable to assume that one might > need different hardware for "just routing" and enhanced QoS/ACL > services (it's a case nowadays anyway). You may feel it is reasonable. Not everybody agrees. If we compare with IPv4: All modern routers I know of (including high speed boxes with multiple 10G and 100G ports) are able to handle stateless ACLs based on IPv4 addresses and port numbers. The boxes with multiple 10G and 100G ports process these ACLs at line rate. I don't pay extra for this functionality - possibly because a box *without* such functionality would have a limited market. > For the latter case the device > has to either, as you said, chaise the whole chain down (which might > be as long as the whole packet) or have a way to deal with packets it > could not parse (applying a specific policy to such packets). > > > How big is a HBH header? How big is a routing option such as the Segment Routing option? If that's a list of 27 services, each with a 16 byte IPv6 address... A small but possibly relevant digression here: My border routers (which happen to be Juniper routers) are configured to disallow source routing. This has been the Juniper *default* since around 2008, see http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-routing/frameset.html I expect (but do not know with certainty) that Juniper changed this source routing default behavior based on customer feedback. Back to IPv6: I might allow "interesting" IPv6 extension headers within my own AS - because in such cases I have much more control. There is no way I'm going to allow IPv6 packets with long chains of "interesting" IPv6 header chains to pass my border routers. Either they have short enough header chains that my border routers can inspect the L4 info at line rate - or they get dropped. > I'd like to point out that the problem is not specific to IPv6 at all. > How deep is MPLS label stack? Where are TCP flags or port number in > the packet (so I can match 'tcp established' or 'tcp 443')? oops, we > don't know....it depends...so some linecards do not copy enough data, > some (newer ones) do. The MPLS label stack is normally used with a single provider - thus the provider is in control. I agree that the IPv4 packet may have options, making it variable length. However the length is still limited by the IHL field, which has a max value of 15 (60 bytes). Steinar Haug, AS 2116 From nobody Wed Jun 17 05:19:12 2015 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 C54FD1A8ACB for ; Wed, 17 Jun 2015 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zek6h1szJhNo for ; Wed, 17 Jun 2015 05:19:10 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3C01A8ACA for ; Wed, 17 Jun 2015 05:19:09 -0700 (PDT) X-Envelope-To: Received: from vpn-248.int.inex.ie (vpn-248.int.inex.ie [193.242.111.248]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t5HCJ6KV005912 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jun 2015 13:19:07 +0100 (IST) (envelope-from nick@foobar.org) To: v6ops@ietf.org References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> From: Nick Hilliard X-Enigmail-Draft-Status: N1110 Message-ID: <558165C4.30904@foobar.org> Date: Wed, 17 Jun 2015 13:19:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 12:19:11 -0000 On 17/06/2015 11:01, Jen Linkova wrote: > I'd like to point out that the problem is not specific to IPv6 at all. > How deep is MPLS label stack? Where are TCP flags or port number in > the packet (so I can match 'tcp established' or 'tcp 443')? oops, we > don't know....it depends...so some linecards do not copy enough data, > some (newer ones) do. bear in mind that each entry in the mpls label stack will be 4 octets, which gives. An EH could be orders of magnitude larger. Nick From nobody Wed Jun 17 05:41:21 2015 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 209231A9059 for ; Wed, 17 Jun 2015 05:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 BFoxtgCnYUIn for ; Wed, 17 Jun 2015 05:41:18 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E081A9055 for ; Wed, 17 Jun 2015 05:41:18 -0700 (PDT) Received: by yhak3 with SMTP id k3so32529612yha.2 for ; Wed, 17 Jun 2015 05:41:17 -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=8fpGFQSvBpwWqr4PUt6mB4+iJ8ABx17UokIj4jYBiyg=; b=QmwWYhTbMbZq9KboIb/AT4eS+mpl2vW798i3rjE4kk/w851w24W69Zwsc/f/HLjxn3 xkYbytB5BdCORAChy7h3tvXj/Ip8BKrY48TpHfXKX9EUPa2pN16FhPH+u6MDRa1CoJ8R upis49EZqtZ2jA7nIKCpG5W+xoaHUMt1GMP4WrEkLcRGcYZtnZplodQ/Qq6OpmfmAhKG qdW9a6BY/A+RUnzHvoUMTBv7ZKQf7/TvJFjvQs5F7Jpt7LNREyygiubh6pCGPPCVCtmI /o+MgkjDXARJO+ihzFT5UGKemTzzXOsyRZQq2iNr2KVDpaNt5TrRv/ov1Yj/8EeNlCRR Qvug== X-Received: by 10.52.124.43 with SMTP id mf11mr4597156vdb.92.1434544877268; Wed, 17 Jun 2015 05:41:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 05:40:36 -0700 (PDT) In-Reply-To: <558165C4.30904@foobar.org> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <558165C4.30904@foobar.org> From: Jen Linkova Date: Wed, 17 Jun 2015 14:40:36 +0200 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 12:41:19 -0000 On Wed, Jun 17, 2015 at 2:19 PM, Nick Hilliard wrote: > On 17/06/2015 11:01, Jen Linkova wrote: >> I'd like to point out that the problem is not specific to IPv6 at all. >> How deep is MPLS label stack? Where are TCP flags or port number in >> the packet (so I can match 'tcp established' or 'tcp 443')? oops, we >> don't know....it depends...so some linecards do not copy enough data, >> some (newer ones) do. > > bear in mind that each entry in the mpls label stack will be 4 octets, > which gives. An EH could be orders of magnitude larger. Sorry, I should have made my point clear. What 'm trying to say is that: 1) if the current approach of 'copy X bytes to on-chip memory' there is always a chance to receive a valid packet which requires more than X bytes to be copied for correct processing.Therefore I believe we should discuss how to handle such situation in general instead of trying to find a magic value of X (I'd suggest 42 then ;)) and limit all headers length by that number. 2) while just a few years ago you might see linecards which could look at...how many? 64 bytes? into packets, nowadays they are replaced with linecards which are able to look much deeper. So while protocol designers should be aware of such limitation, absolute numbers are increasing and the situation is improving (btw my measurements do show that packets with 8 / 16 bytes EHs have much lower drop rate than packets with 512/1024 bytes EHs, which I dare attribute to the hw limitations). 3) I assume that vendors are developing hardware and software to meet customers needs (more or less ;)) - 5 years ago who would need to look deeper than 5 labels? so some linecards were quite upset to see such deep label stack and might crash; now I'm told that 'we can inspect 10 labels easily because there are use cases'. Why could not we expect smth like that happening if/when a use case for EH arises? -- SY, Jen Linkova aka Furry From nobody Wed Jun 17 06:22:51 2015 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 4A0671AC3BA for ; Wed, 17 Jun 2015 06:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 k2I5HBVrZpbs for ; Wed, 17 Jun 2015 06:22:49 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D771A914E for ; Wed, 17 Jun 2015 06:22:49 -0700 (PDT) Received: by yhak3 with SMTP id k3so33358507yha.2 for ; Wed, 17 Jun 2015 06:22:48 -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=cn6KaNtyQpFdG0cJfNOSD0UAdiaSCoFEz8GdHqRl0lw=; b=NwdcaiO14AeUAs26JsJOKiwo4p+T5Ga0pWSWZcQ9imZ04NgxoKgoG9jDo4dJRaMIca YxhDgbiAlsNZDJcN/ZsxWX9hiMdAsooq+KjYSuzOxFvitJ4LjPRoOUdj9HopVR692QdL bv2Kt/pV5SKV9/sOc/bIs3/4O/wfJncX7CvsjZX8oothjWV5dRxQ3b2Ro8p+3Fu8280S w1yNserQAsW60z6WiSnu5A2YwFTK1Hzpps8oM+dUnIUotgQRe64tlvDvOPNGKKKRR33T pxqbPygG0/eDS8OsWx+VP/lxZHcSj6odeXTS2xytlN5S8YG0iIm/4R7mxUwYEqoLXDyj tjhw== X-Received: by 10.52.113.97 with SMTP id ix1mr4686592vdb.1.1434547368581; Wed, 17 Jun 2015 06:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 06:22:27 -0700 (PDT) In-Reply-To: <20150617.140235.74748217.sthaug@nethelp.no> References: <20150517191841.GA26929@ernw.de> <20150617.140235.74748217.sthaug@nethelp.no> From: Jen Linkova Date: Wed, 17 Jun 2015 15:22:27 +0200 Message-ID: To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 13:22:50 -0000 On Wed, Jun 17, 2015 at 2:02 PM, wrote: >> IMHO it's reasonable to assume that one might >> need different hardware for "just routing" and enhanced QoS/ACL >> services (it's a case nowadays anyway). > > You may feel it is reasonable. Not everybody agrees. If we compare > with IPv4: All modern routers I know of (including high speed boxes > with multiple 10G and 100G ports) are able to handle stateless ACLs > based on IPv4 addresses and port numbers. The boxes with multiple > 10G and 100G ports process these ACLs at line rate. I don't pay extra > for this functionality - possibly because a box *without* such > functionality would have a limited market. [skip] > I agree that the IPv4 packet may have options, making it variable > length. However the length is still limited by the IHL field, which > has a max value of 15 (60 bytes). I'm glad you mentioned 60 bytes ;) Because there are a lot of reasonably modern hardware around which copies 64 bytes on-chip. Which means if you happen such hardware in your network and your stateless ACL have 'match tcp flags' rules, you might get quite unexpected results processing packets with 60 bytes IPv4 header....So, while it might be perfectly fine to have such cars in the core, I'd expect people not to install then at the border routers which are supposed to perform enhanced ACL services. It was my point. So we all agree that 'variable length is OK as long as our hardware can look deep enough'? And what people are complaining about is exact number? Which we do not know yet for IPv6 EHs? -- SY, Jen Linkova aka Furry From nobody Wed Jun 17 06:27:54 2015 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 2F0F51AC3D9 for ; Wed, 17 Jun 2015 06:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UPlOzh1PsYZ5 for ; Wed, 17 Jun 2015 06:27:52 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 059B91AC3D6 for ; Wed, 17 Jun 2015 06:27:51 -0700 (PDT) Received: (qmail 31420 invoked from network); 17 Jun 2015 13:27:50 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Jun 2015 13:27:50 -0000 Date: Wed, 17 Jun 2015 15:27:50 +0200 (CEST) Message-Id: <20150617.152750.41635871.sthaug@nethelp.no> To: furry13@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20150617.140235.74748217.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 13:27:54 -0000 > So we all agree that 'variable length is OK as long as our hardware > can look deep enough'? And what people are complaining about is exact > number? Which we do not know yet for IPv6 EHs? Agreed, variable length *by itself* is not the problem. I see *large* variable length headers, in combination with complex parsing rules, as the problem. Steinar Haug, AS 2116 From nobody Wed Jun 17 06:33:41 2015 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 DF5B21AC414 for ; Wed, 17 Jun 2015 06:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKJw7h40ngFJ for ; Wed, 17 Jun 2015 06:33:35 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 80BA71AC3FC for ; Wed, 17 Jun 2015 06:33:30 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id E051E74927; Wed, 17 Jun 2015 15:33:28 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id BB6D8F94; Wed, 17 Jun 2015 15:33:28 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 83D1BC4102; Wed, 17 Jun 2015 15:33:28 +0200 (CEST) Date: Wed, 17 Jun 2015 15:33:28 +0200 From: Enno Rey To: sthaug@nethelp.no Message-ID: <20150617133328.GB16716@ernw.de> References: <20150617.140235.74748217.sthaug@nethelp.no> <20150617.152750.41635871.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150617.152750.41635871.sthaug@nethelp.no> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 13:33:40 -0000 Hi, On Wed, Jun 17, 2015 at 03:27:50PM +0200, sthaug@nethelp.no wrote: > > So we all agree that 'variable length is OK as long as our hardware > > can look deep enough'? And what people are complaining about is exact > > number? Which we do not know yet for IPv6 EHs? > > Agreed, variable length *by itself* is not the problem. > > I see *large* variable length headers, in combination with complex > parsing rules, as the problem. (*large* variable headers) exactly, plus fragmentation and "ambiguities" wrt fragmentable vs. unfragmentable part and how headers point to the next one once there's a cut between them due to fragmentation. the, what we consider, "problem space" is much larger, unfortunately. thanks Enno > > Steinar Haug, AS 2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Jun 17 06:41:24 2015 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 C67EC1AC444 for ; Wed, 17 Jun 2015 06:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 hlT7OIg_-a2M for ; Wed, 17 Jun 2015 06:41:23 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9167F1AC7E7 for ; Wed, 17 Jun 2015 06:41:22 -0700 (PDT) Received: by ykfl8 with SMTP id l8so39906205ykf.1 for ; Wed, 17 Jun 2015 06:41:22 -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=aocfp6y0nJGmZ0RLnUQeazprxlkhUBz1J25r6UGp/Mk=; b=TOB++BniVM7q8cM/mkQyfIusjYTPYBVj+pmuoGUlJtBCfnsJLZqY4KAln0sIGR/SSp Hp3cjQ8aAh/idIfyX52NGcMi8mlCCOn78ipJDLSNft1z3X4SIQvAmms4Vjl1VFzhURyO /Q6/U8OvU/WoFMB2XtTrHVw9Q2AFidY4OwAGHDiyR4d3TO6ikHvwhIFicPeNaFpgGSkk NQRNPkbv676ijCuDmxQyjr1oLuDplWbhM7r0kSNNX2UblEkt+TIoDpB1lnSb2sW2i6qQ hsyYTfVH8ruGnKKIrt26y9AodcqzcBbEbfx7jb20sCWYZaW1RHSng7CCPmQDe3Jn3tk8 pRbA== X-Received: by 10.52.227.200 with SMTP id sc8mr4817285vdc.35.1434548481962; Wed, 17 Jun 2015 06:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 06:41:01 -0700 (PDT) In-Reply-To: <20150617133328.GB16716@ernw.de> References: <20150617.140235.74748217.sthaug@nethelp.no> <20150617.152750.41635871.sthaug@nethelp.no> <20150617133328.GB16716@ernw.de> From: Jen Linkova Date: Wed, 17 Jun 2015 15:41:01 +0200 Message-ID: To: Enno Rey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 13:41:24 -0000 On Wed, Jun 17, 2015 at 3:33 PM, Enno Rey wrote: >> I see *large* variable length headers, in combination with complex >> parsing rules, as the problem. > > (*large* variable headers) exactly, plus fragmentation Fragmentation is not specific to IPv6, is it? And, as the fragment header itself is just 8 bytes (AFAIR, too lazy to check ;)) - I'd not classify it as *large* variable header. > and "ambiguities" wrt fragmentable vs. unfragmentable part and how headers point to the next one once there's a cut between them due to fragmentation. the, what we consider, "problem space" is much larger, unfortunately. Has not RFC7112 addressed this particular problem? -- SY, Jen Linkova aka Furry From nobody Wed Jun 17 07:00:45 2015 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 520F21ACD5A for ; Wed, 17 Jun 2015 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjVY8SKI295b for ; Wed, 17 Jun 2015 07:00:40 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 8BC871ACD58 for ; Wed, 17 Jun 2015 07:00:34 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id F37CF7492E; Wed, 17 Jun 2015 16:00:32 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id B30EEFCD; Wed, 17 Jun 2015 16:00:32 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 8AD49C4102; Wed, 17 Jun 2015 16:00:32 +0200 (CEST) Date: Wed, 17 Jun 2015 16:00:32 +0200 From: Enno Rey To: Jen Linkova Message-ID: <20150617140032.GB16806@ernw.de> References: <20150617.140235.74748217.sthaug@nethelp.no> <20150617.152750.41635871.sthaug@nethelp.no> <20150617133328.GB16716@ernw.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 14:00:44 -0000 Hi, On Wed, Jun 17, 2015 at 03:41:01PM +0200, Jen Linkova wrote: > On Wed, Jun 17, 2015 at 3:33 PM, Enno Rey wrote: > >> I see *large* variable length headers, in combination with complex > >> parsing rules, as the problem. > > > > (*large* variable headers) exactly, plus fragmentation > > Fragmentation is not specific to IPv6, is it? right [even though I'm in the camp of "deprecate fragmentation as a whole" ;-), but let's not open this can of worms here]. BUT: fragmentation becomes a (then somewhat IPv6 specific) huge problem space once you have a datagram containing, say, 20 extension headers of partially variable lenght & pretty much arbitrary order, split into, say, 50 fragments. [again, see https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf]. Such a datagram would be fully valid as of today/RFC2460. Yes, we're aware of RFC7112. It's just: no OS we know and no devices we're aware of (feel free to provide pointers) implement RFC 7112 as of today. but many attack tools implement the techniques mentioned above. Which is why quite some operators (in particular, but not only) from enterprise and managed service provider/cloud space drop all EHs except, maybe, AH+ESP. thanks Enno And, as the fragment > header itself is just 8 bytes (AFAIR, too lazy to check ;)) - I'd not > classify it as *large* variable header. > > > and "ambiguities" wrt fragmentable vs. unfragmentable part and how headers point to the next one once there's a cut between them due to fragmentation. the, what we consider, "problem space" is much larger, unfortunately. > > Has not RFC7112 addressed this particular problem? > > -- > SY, Jen Linkova aka Furry -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Jun 17 08:11:31 2015 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 1F6781ACF57 for ; Wed, 17 Jun 2015 08:11:30 -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 PBQ7shcz2_ED for ; Wed, 17 Jun 2015 08:11:28 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2541ACF1C for ; Wed, 17 Jun 2015 08:11:28 -0700 (PDT) Received: by wiwd19 with SMTP id d19so136825242wiw.0 for ; Wed, 17 Jun 2015 08:11:27 -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=a8z8lCuOb+KmiDZ8cOfUm/x1RpBhvNSgBeWRer7TTY0=; b=0A8ts+7TErMw3VOdUdG4kU1cBJxQF9b3Z8moCDnnzqyxuIiCBFyG1U4lthI9pmvMew O6Swct3guPektUn89NZdSwDmlv7bzefDINPEC8HcS5rBno/BHCebcxxOD4UgSTYrbhxp VoVySxEXOxGqywrAm8hn1v7iiWxXiKPx845yqVPhb0g5bkmJvUmFJoR5Qi8Jdj+uQkET 91nrlaYATLGTwP3pE+yhxz+s1v0PYPIC0fmz0eCzsJ2Yw3GMYQbvLnzITIlm6TEFwv5u xVOyrEObgpE5ejyyQc2ApleCEe58CpnoXKl/gZBk4WKxtWCYgMtQWNnBwbdRK+DANPGr ggXA== MIME-Version: 1.0 X-Received: by 10.180.109.136 with SMTP id hs8mr18413608wib.73.1434553887295; Wed, 17 Jun 2015 08:11:27 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Wed, 17 Jun 2015 08:11:27 -0700 (PDT) In-Reply-To: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> Date: Wed, 17 Jun 2015 08:11:27 -0700 Message-ID: From: Ca By To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=e89a8f234557dd0d670518b81aff Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 15:11:30 -0000 --e89a8f234557dd0d670518b81aff Content-Type: text/plain; charset=UTF-8 On Tue, Jun 16, 2015 at 9:52 PM, Ca By wrote: > > > On Tuesday, June 16, 2015, Fred Baker (fred) wrote: > >> >> > On Jun 16, 2015, at 6:24 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> > >> > Personally I still think RFC 7045 is the most realistic on this point, >> > but Fred would like things to get better ;-). >> >> And I haven't finished with Dennis Ferguson's comment. >> >> Bottom line, if one accepts the present status quo as the state forever, >> then we should stop with RFC 7045, and (with Fernando) agree to deprecate >> all extension headers. I'd like to not do that, and the only way I see to >> not do that is to not accept the status quo. >> > > > So you build a bridge to nowhere? > > > Responding to my own comment. IPv6 is serious business now. That means it needs to be the narrow waist of the internet that is small on services and large on stability and predictability. Please review https://www.iab.org/wp-content/IAB-uploads/2011/03/hourglass-london-ietf.pdf For the folks looking for extension header innovation, would you be willing to work on IP version X instead of IPv6? Or perhaps you can use the Class E IPv4 space for your innovation? Serious. IPv6 is not a place for innovation at the Network / Internet layer. Attempts to do so achieve the results in draft-ietf-v6ops-ipv6-ehs-in-real-world-00 also referenced in slide 7 --e89a8f234557dd0d670518b81aff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 16, 2015 at 9:52 PM, Ca By <cb.list6@gmail.com> wrote:


O= n Tuesday, June 16, 2015, Fred Baker (fred) <fred@cisco.com> wrote:
=
> On Jun 16, 2015, at 6:24 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
>
> Personally I still think RFC 7045 is the most realistic on this point,=
> but Fred would like things to get better ;-).

And I haven't finished with Dennis Ferguson's comment.

Bottom line, if one accepts the present status quo as the state forever, th= en we should stop with RFC 7045, and (with Fernando) agree to deprecate all= extension headers. I'd like to not do that, and the only way I see to = not do that is to not accept the status quo.


So you build a = bridge to nowhere?

=C2=A0
<= br>
Responding to my own comment.

IPv6 i= s serious business now.=C2=A0 That means it needs to be the narrow waist of= the internet that is small on services and large on stability and predicta= bility.

Please review=C2=A0https://w= ww.iab.org/wp-content/IAB-uploads/2011/03/hourglass-london-ietf.pdf

For the folks looking for extension header innovation= , would you be willing to work on IP version X instead of IPv6?=C2=A0 Or pe= rhaps you can use the Class E IPv4 space for your innovation?
Serious.=C2=A0 IPv6 is not a place for innovation at the Networ= k / Internet layer.=C2=A0 Attempts to do so achieve the results in draft-ie= tf-v6ops-ipv6-ehs-in-real-world-00 also referenced in slide 7
=C2=A0

--e89a8f234557dd0d670518b81aff-- From nobody Wed Jun 17 09:46:08 2015 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 1C3DD1B2A78 for ; Wed, 17 Jun 2015 09:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 CSapbWN-G9wx for ; Wed, 17 Jun 2015 09:46:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0CB1AD368 for ; Wed, 17 Jun 2015 09:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3761; q=dns/txt; s=iport; t=1434559565; x=1435769165; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4dH+H5BtQOdM2fDcoKce0UucWCNjIBl8KSzi0P0c3R0=; b=OIU8SQ1V92WjNnXrzaaKoSnX4Gcwowu+YQdHlO9eH92YHUJlB4S5/6n/ qQq1ViLjW0gJle0aSt9bSSIiC8Nv+dYPounkNPle0HpoC3uC0EwTKwPnG /cayFO/mMTdd9wKAiMCzOm8OCDkMB52kq582UxVBB+PaiPxCcAvRFRWBQ 4=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmBADko4FV/4UNJK1cgxBUXwa9VgmBaYV2AoE5OBQBAQEBAQEBgQqEIgEBAQIBAXkFCwIBCA4KLjIlAgQOBQ6IGQgNyWMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItEhCMRAVEHgxeBFAWTaAGCIYFNgzmEH4E0kxGDWyaCCxyBUm+BDDqBAgEBAQ X-IronPort-AV: E=Sophos; i="5.13,633,1427760000"; d="asc'?scan'208"; a="4326536" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jun 2015 16:46:04 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5HGk40B017100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 16:46:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.178]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 11:46:04 -0500 From: "Fred Baker (fred)" To: Enno Rey Thread-Topic: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices Thread-Index: AQHQqR0Y1cqdHQMNH0ivLSqzykYy+g== Date: Wed, 17 Jun 2015 16:46:03 +0000 Message-ID: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> In-Reply-To: <20150617081424.GA15514@ernw.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_511FB745-3A79-4DB6-AABD-60B9ED6377C7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 16:46:07 -0000 --Apple-Mail=_511FB745-3A79-4DB6-AABD-60B9ED6377C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 17, 2015, at 1:14 AM, Enno Rey wrote: >=20 > Fred, All, >=20 > On Wed, Jun 17, 2015 at 07:41:33AM +0000, Fred Baker (fred) wrote: >> I'm of course missing the preceding email. No problem with the = cross-posting, but let's get the question on the table? Is this section = 4.1's statement that "it is recommended that those headers appear in the = following order"? >>=20 >> I have a hunch that an internet draft requiring headers to be in the = listed order would be looked at with approbation. The issue, if any, = would likely have regard to repeated Destination Option headers. However >>=20 >> Each extension header should occur at most once, except for the >> Destination Options header which should occur at most twice (once >> before a Routing header and once before the upper-layer header). >>=20 >> seems to me fairly definitive. >=20 > I'm not so sure about this. First probably a capital "SHOULD" would = have been more appropriate. RFC 2460 doesn't use the RFC 2119 conventions. Yes, it's hard to = remember now, but RFC 2119 conventions weren't always the rule; they = derived from similar usage in RFCs 1122/1123 and 1812. History lesson in = the presence of adult beverages if that's interesting. > Second - and this is our main point/observation - there's too much = space of interpretation for actual implementation. > To underline this I will just cite two somewhat random sections from = the study we performed on evading security controls (IDPS systems) by = means of extension headers, combined with fragmentation = (https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion= -of-HighEnd-IPS-Devices-wp.pdf). One of the devices (all of them latest = code incl. some high-end gear) could be evaded by the following: Cutting to the chase, on the surface it looks like most of the cases you = specified conform to the sequence rule, with the exception of one that = has three Destination Option Headers. What I *think* you're pointing out = is (from your PDF) that this is part of a sequence of messages, one of = which is fragmented, accepted by the intrusion detector, and not = accepted by the ultimate host (perhaps a TCP checksum failed?), and as a = result bypasses the signature that the intrusion detector is looking = for. The issue wasn't that the sequence was incorrect, in most cases; it = was that the intrusion detector made a different choice than the end = host. Tell me this. Would you be happier if the fragmentation rule said that = the first fragment had to contain the entire IPv6 header, plus the = transport layer header (for ACL support)? I think Fernando would support = such a statement (I think I have "heard" him make such a statement). --Apple-Mail=_511FB745-3A79-4DB6-AABD-60B9ED6377C7 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 iQEVAwUBVYGkSp9ieig10VPpAQJ2fwf8DB/9LaRLFUkOO/UoMmpEaI/aTOWXsznE fG80gqOo5nef/BP4ngI3fEXrZiJ5VVRzDbvy6IXGOyqoZ2byyGnq8MTA2d6EVkU/ +Y3FcftrTE2rW/S3jpDt++F6p1ttRHZqh5BN41tP5G44IzryITPb8EXp6V2JZ8jI JSKCleVKIIjtFOMuSIkAwuuHMtq++01okDnZpPLNI5x3gEMt43u8F7Wc5oTZh1ef NhPcuOFBAqkntrliVoVy8vf5CWkH2+P6Kz/KAmb1FroWIFJuF1dB4nheCXdykb4m 8pTADQQEbEZDifDkJbtZo8yG87Ng+X9QRb9rZI43QM6nxp1QjFex0w== =/UDn -----END PGP SIGNATURE----- --Apple-Mail=_511FB745-3A79-4DB6-AABD-60B9ED6377C7-- From nobody Wed Jun 17 09:55:34 2015 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 8D8881B2ADE for ; Wed, 17 Jun 2015 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 xSxnszYb2rOV for ; Wed, 17 Jun 2015 09:55:21 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB041B2AD7 for ; Wed, 17 Jun 2015 09:55:20 -0700 (PDT) Received: by ykfl8 with SMTP id l8so45020603ykf.1 for ; Wed, 17 Jun 2015 09:55:19 -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=rrP7Af7srA6x9Zigh+RSFXR3oRJlX+8YLg8+tkIOatc=; b=BxzVXKzSMooTwd4T6CsaoxjhjtZ8hsvxYvcoVafXlo5abrl4FOXiusbmR4Q+S+K9u4 rDeHMdWg5/m3F5uYDQT0yY/TcVQrx5xz3MGJNd4OEpgHmN5z8qhhniITP6yvQe5j1dUA 08RX1h31BjtIAZE3loaBgdRr4Bb5ElyOAsC9zTPtF9l66xnc1nyOBExes9SeX8DesarQ 7oyPGRXH81xgNCcYnbydtlPsZk62bp4BkJYeXaGMORk4QJ/9R29RP6eGSgxfDVpVEEEo HCWM56wfhmXp5aiN7ZfQg1yySyJLuMlD+FKn7v/HOS7ajqbUWIjsxpsocrde7u9SWxbH 1swA== X-Received: by 10.52.100.103 with SMTP id ex7mr5432812vdb.71.1434560119760; Wed, 17 Jun 2015 09:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 09:54:59 -0700 (PDT) In-Reply-To: <5580CC33.2080503@gmail.com> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> From: Jen Linkova Date: Wed, 17 Jun 2015 18:54:59 +0200 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 16:55:22 -0000 On Wed, Jun 17, 2015 at 3:24 AM, Brian E Carpenter wrote: > On 17/06/2015 07:02, Jen Linkova wrote: >> https://tools.ietf.org/html/draft-wkumari-long-headers-03 >> >> Comments are appreciated... > > In REQ-2 on HbH headers, you say: > >> The forwarder MUST >> process each option as specified in Section 4.2 of [RFC2460]. > > That aspect of RFC 2460 was fundamentally changed by RFC 7045. Oh, very good point. Thanks for pointing this out. Looks like it does cover our REQ2 (but requires different behavior). So, Section 2.1 RFC7045 says about *all* EHs: "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. " and then, in Section 2.1 for HbH: "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. ". I read this as 'if a router does not recognize/parse the HbH header, it MUST not discard it unless there is an explicit policy configured. It may just ignore it or send for "special processing" via slow path. So it assumes that it is always safe to ignore HbH header (as if all options in the header had highest-order two bits set to '00') while our draft proposed quite different approach ("drop and send ICMP back"). Ignoring HbH header seems to be reasonable and safe if we are sure that every single existing or to be developed HbH option can be safely ignored (or options which could be ignored must be in the very beginning of the header...). In the light of RFC7045 it looks to me that one possible approach for REQ2 might be: - if a forwarder can not parse the HbH header and there is no explicitly configurable policy, it SHOULD either: -- if the forwarder can not parse any of options or if all parsed options have highest-order two bits set to '00') - ignore the header; -- if the forwarder was able to parse some of options and at least one of the options has highest-order two bits set to smth except '00' - discard the packet and send ICMPv6 message if Section 4.2 of RFC 2460 requires so (sending ICMPv6 MAY be subject to a configurable policy) or send it to slow path for full header processing (subject to a configurable policy). How does that sound? > I'm sure other things in the long-headers draft need revising as a > result of RFC 7045, since its whole topic is the handling of extension > headers ("This document updates RFC 2460 to clarify how intermediate > nodes should deal with such extension headers and with any that are > defined in the future.") Yes, we'll revise it, thanks for the comment. > > Y'all also need to take account of RFC 7112, which forbids fragmented > header chains. We do mention 7112 but I agree, we should explicitly mention that header chain is limited by a packet size...Will update the doc. -- SY, Jen Linkova aka Furry From nobody Wed Jun 17 10:36:30 2015 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 6EBCD1B2BFE for ; Wed, 17 Jun 2015 10:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 bHeN2aQUJY8H for ; Wed, 17 Jun 2015 10:36:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DF81B2BC0 for ; Wed, 17 Jun 2015 10:36:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5HHaOki010262 for ; Wed, 17 Jun 2015 19:36:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BAED0206F82 for ; Wed, 17 Jun 2015 19:39:09 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A9484206ECC for ; Wed, 17 Jun 2015 19:39:09 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5HHaKtl029204 for ; Wed, 17 Jun 2015 19:36:23 +0200 Message-ID: <5581B014.8070601@gmail.com> Date: Wed, 17 Jun 2015 19:36:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 17 Jun 2015 17:36:28 -0000 Le 17/06/2015 05:23, Mikael Abrahamsson a écrit : > On Tue, 16 Jun 2015, Fred Baker (fred) wrote: > >> http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/ >> > > https://developer.apple.com/videos/wwdc/2015/?id=719 is the talk that > discussed this directly. Well worth spending an hour on. Thanks Mikael for the pointer. It's good it is described at that length - 1 hour. It's an opportunity to learn before the others where these products go with respect to IPv6. But I dont have that hour :-) I would like to know though what kind of IPv6 is made mandatory in that manufacturer's smartphones. Is it using ULAs? Is it using DHCPv6? Prefix Delegation? Is it using NAT66 or not? To those who spent that hour may know... Alex > From nobody Wed Jun 17 10:38:10 2015 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 692C31A8A97 for ; Wed, 17 Jun 2015 10:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 8O0l9pODkNL8 for ; Wed, 17 Jun 2015 10:38:08 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A651AD364 for ; Wed, 17 Jun 2015 10:38:06 -0700 (PDT) Received: by wiga1 with SMTP id a1so147016790wig.0 for ; Wed, 17 Jun 2015 10:38: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=vHJGWDa/qzfLEq46iQfKc6JYnedaUxi97XmIl6ihgeM=; b=b1xbfMyV1niPhoMrQ9+uh2aiEWb1dk2WqWi6rQkYEuGEBGm6lwXIk5EjbA7eM8SYJH wy5wYxzA0LgfJqjUEZDFMDKjiYZedf/PNSINKGC6nrxhKb0bbIUsv4D32OQv6m0L/mbv ml7p1Kn80Gj+eu5bjeMW0t0dH+ab1Akor2mJCYe6XWLdE7uSmQ6F3I9QFYDMbS9kn3j0 vxZmNn80cxgXko2j+skyrJUEmbJYADBXM4w/knd+7eU2b97p3TE8KPykoBkKwvoEPKOK JDI+rWoisaSgjgPkCcC5lBTQkzBoHC7ZG/wEfiCS3LkbBHRXFKdrKeId+OJzvu3vgCfg 6OjQ== MIME-Version: 1.0 X-Received: by 10.194.10.165 with SMTP id j5mr7912131wjb.147.1434562685032; Wed, 17 Jun 2015 10:38:05 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Wed, 17 Jun 2015 10:38:04 -0700 (PDT) In-Reply-To: <5581B014.8070601@gmail.com> References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> Date: Wed, 17 Jun 2015 10:38:04 -0700 Message-ID: From: Ca By To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=e89a8f642b063fe0050518ba27e8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 17 Jun 2015 17:38:09 -0000 --e89a8f642b063fe0050518ba27e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 17, 2015 at 10:36 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 17/06/2015 05:23, Mikael Abrahamsson a =C3=A9crit : > >> On Tue, 16 Jun 2015, Fred Baker (fred) wrote: >> >> >>> http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-s= ervice-is-coming-soon-get-your-apps-ready/ >>> >>> >> https://developer.apple.com/videos/wwdc/2015/?id=3D719 is the talk that >> discussed this directly. Well worth spending an hour on. >> > > Thanks Mikael for the pointer. It's good it is described at that length - > 1 hour. It's an opportunity to learn before the others where these > products go with respect to IPv6. But I dont have that hour :-) > > I would like to know though what kind of IPv6 is made mandatory in that > manufacturer's smartphones. > > Is it using ULAs? > > No > Is it using DHCPv6? Prefix Delegation? > > No > Is it using NAT66 or not? > > No > To those who spent that hour may know... > > Alex > > > >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f642b063fe0050518ba27e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 17, 2015 at 10:36 AM, Alexandru Petrescu = <alexa= ndru.petrescu@gmail.com> wrote:
Le 17/06/2015 05:23, Mikael Abrahamsson a =C3=A9crit = :
On Tue, 16 Jun 2015, Fred Baker (fred) wrote:

http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-on= ly-cell-service-is-coming-soon-get-your-apps-ready/


https://developer.apple.com/videos/wwdc/2015/?= id=3D719 is the talk that
discussed this directly. Well worth spending an hour on.

 Thanks Mikael for the pointer. It's good it is described at that length= - 1 hour.=C2=A0 It's an opportunity to learn before the others where t= hese products go with respect to IPv6.=C2=A0 But I dont have that hour :-)<= br>
I would like to know though what kind of IPv6 is made mandatory in that man= ufacturer's smartphones.

Is it using ULAs?


No
=C2=A0
Is it using DHCPv6?=C2=A0 Prefix Delegation?


No
=C2=A0
Is it using NAT66 or not?


No
=C2=A0
To those who spent that hour may know...

Alex




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

--e89a8f642b063fe0050518ba27e8-- From nobody Wed Jun 17 10:43:41 2015 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 B3EA01B2ADE for ; Wed, 17 Jun 2015 10:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QtYjDt7fT1T for ; Wed, 17 Jun 2015 10:43:24 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 501281B2C60 for ; Wed, 17 Jun 2015 10:43:17 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id C1ED874CA1; Wed, 17 Jun 2015 19:43:15 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 9E292466; Wed, 17 Jun 2015 19:43:15 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 7B9A6C49E1; Wed, 17 Jun 2015 19:43:15 +0200 (CEST) Date: Wed, 17 Jun 2015 19:43:15 +0200 From: Enno Rey To: "Fred Baker (fred)" Message-ID: <20150617174315.GA17641@ernw.de> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 17:43:32 -0000 Fred, On Wed, Jun 17, 2015 at 04:46:03PM +0000, Fred Baker (fred) wrote: > > > Cutting to the chase, on the surface it looks like most of the cases you specified conform to the sequence rule, with the exception of one that has three Destination Option Headers. What I *think* you're pointing out is (from your PDF) that this is part of a sequence of messages, one of which is fragmented, accepted by the intrusion detector, and not accepted by the ultimate host (perhaps a TCP checksum failed?), and as a result bypasses the signature that the intrusion detector is looking for. The issue wasn't that the sequence was incorrect, in most cases; it was that the intrusion detector made a different choice than the end host. Let's put it slightly different: the intrusion detector is supposed to detect/block certain application layer attacks. Which it does as long as those come in/pass by without extension headers/fragmentation. Once the attack packets are crafted in certain ways, the intrusion detector let's them through, the end host happily reassembles and gets hit. The end host does so as the overall datagram does not violate RFC 2460's (dubious) liberty. The detector is "blind" as parsing a single datagram split into an arbitrary number of fragments with an arbitrary number of extension headers in a (mostly) arbitrary order is a, well, complex task. It's not only intrusion detectors facing this type of difficulty, it's other "black list approach" security controls (like so-called First Hop Security features or Infrastructure ACLs), too. [see, for example, http://www.insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/). > > Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? 'm tempted to reply that this would make the Internet world a safer place (without losing any current functionality) and might speeden up overall IPv6 deployment, as some organizations had one (for some of them: severe) concern less. So it's not about my personal happiness; though the factors mentioned might actually contribute to that as well ;-). >From that angle RFC 7112 is certainly a step into the right direction. It's just not widely implemented - while IPv6 is "finally here" - and it doesn't "solve" certain cases (see the link above). That's why I think that a major revision of the whole extension header concept is needed. Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Jun 17 10:48:25 2015 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 52FA41B2C6E for ; Wed, 17 Jun 2015 10:48:23 -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 fG5EbqIUTB0P for ; Wed, 17 Jun 2015 10:48:21 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F060D1B2C73 for ; Wed, 17 Jun 2015 10:48:20 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D1DDA8813C for ; Wed, 17 Jun 2015 10:48:20 -0700 (PDT) Received: from brians-mbp.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7AB2D1368268 for ; Wed, 17 Jun 2015 10:48:20 -0700 (PDT) Message-ID: <5581B2DF.8040207@innovationslab.net> Date: Wed, 17 Jun 2015 13:48:15 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> In-Reply-To: <20150617174315.GA17641@ernw.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pa5t5dGaGu6m7pXA6PbRFTeHH8S7K94rH" Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 17:48:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pa5t5dGaGu6m7pXA6PbRFTeHH8S7K94rH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/17/15 1:43 PM, Enno Rey wrote: >=20 > Let's put it slightly different: the intrusion detector is supposed > to detect/block certain application layer attacks. Which it does as > long as those come in/pass by without extension If the device is trying to inspect application-layer data, it might as well act like the destination and re-assemble the fragments. Yes, this is costly processing, but it mitigates this bypass mechanism. Regards, Brian --pa5t5dGaGu6m7pXA6PbRFTeHH8S7K94rH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVgbLkAAoJEBOZRqCi7goqDKEIAKhebBAd7zId8zOXcH+eW100 v6Yp7ox1gNTY8GQXDcuW+mlNnAXdEvKq2KVhkhBVn0fiWtoHtjxMQHFVwb4vBxQY nfqgm6UHbagA9Kt7GHdLzcYx11jozE6ZWPxnFznEJxSjA6mWEwvwN3J93cWUfktp aTB90rLrI2Q1P4tC7fHPYI0iLy4ni80molaW793pDoekzUAyTju6yyFYzv/Ycp4G +iDt0u69n/OkOSlX1Fbize1oZDw6XwXRO/V6S3nh5pKBtXJs7+k9h4jgTyxvrV5N KeZRrnNIWoq4fHmyeLrsX0DmNFVgAMXw6vI/1rhBGZfkc9DIJpW0/Pz/V2J7Bdc= =KMHw -----END PGP SIGNATURE----- --pa5t5dGaGu6m7pXA6PbRFTeHH8S7K94rH-- From nobody Wed Jun 17 11:04:10 2015 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 4BCEF1B2C85 for ; Wed, 17 Jun 2015 11:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ZqR6pPtY_zIL for ; Wed, 17 Jun 2015 11:04:06 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B14F1A9061 for ; Wed, 17 Jun 2015 11:04:06 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t5HI2HvT028582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Jun 2015 11:02:17 -0700 (PDT) Message-ID: <5581B628.5030206@isi.edu> Date: Wed, 17 Jun 2015 11:02:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ca By , "Fred Baker (fred)" References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t5HI2HvT028582 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 18:04:09 -0000 On 6/17/2015 8:11 AM, Ca By wrote: > IPv6 is serious business now. That means it needs to be the narrow > waist of the internet that is small on services and large on stability > and predictability. > > Please > review https://www.iab.org/wp-content/IAB-uploads/2011/03/hourglass-london-ietf.pdf > > For the folks looking for extension header innovation, would you be > willing to work on IP version X instead of IPv6? Or perhaps you can use > the Class E IPv4 space for your innovation? > > Serious. IPv6 is not a place for innovation at the Network / Internet > layer. ... Hmm. The design of the IPv6 header chain system was intended to overcome these sort of limitations of IPv4, e.g., to understand what to do with unknown options, to separate HBH vs E2E, etc. IPv6 *is* the innovation, and because of that - for over 15 years - "you" (commercial vendors) told users how expensive it would be to implement and it wasn't ready (because "you" were making higher margins on IPv4 equipment). Now that we really need it and thus "you" are making money off it, we (the IETF innovators) are supposed to go away (i.e., use protocol extensions that don't impact your profit margins because you don't support them)? IMO, IPv6 is an E-ticket ride*. If you want to make money off it, IMO "you" need to expect to pay the price to keep up. Joe *https://en.wikipedia.org/wiki/E_ticket From nobody Wed Jun 17 11:04:20 2015 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 CB0511B2C91 for ; Wed, 17 Jun 2015 11:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWNScnTxdzHD for ; Wed, 17 Jun 2015 11:04:16 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 855BA1B2C90 for ; Wed, 17 Jun 2015 11:04:15 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 3EE3E74CA6 for ; Wed, 17 Jun 2015 20:04:10 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 1ABFB470 for ; Wed, 17 Jun 2015 20:04:10 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id E5ED0C49E3; Wed, 17 Jun 2015 20:04:09 +0200 (CEST) Date: Wed, 17 Jun 2015 20:04:09 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20150617180409.GA17739@ernw.de> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5581B2DF.8040207@innovationslab.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 18:04:19 -0000 On Wed, Jun 17, 2015 at 01:48:15PM -0400, Brian Haberman wrote: > > > > > Let's put it slightly different: the intrusion detector is supposed > > to detect/block certain application layer attacks. Which it does as > > long as those come in/pass by without extension > > If the device is trying to inspect application-layer data, it might as > well act like the destination and re-assemble the fragments. Yes, this > is costly processing, but it mitigates this bypass mechanism. in theory yes. Given the majority of end host operating systems happily wait up to 60 seconds for "that last [potentially 42th] fragment" of a single datagram coming in, this is probably not an option for all those types of security controls (intrusion detectors, First Hop Security mechanisms, Infrastructure ACLs) expected to work mostly in wire speed. It is hence not an option for a number of networks using such techniques which is why they usually drop all extension headers except for AH, ESP and (in a few cases) FH. Doing so is a reasonable decision from their side and will not exactly encourage widespread development of new services using extension headers. Which then raises the question: what's the benefit of this thing called extension headers which do not provide much use today and might - given there's a growing number of networks acting as described - not provide much use tomorrow? This thing then seems to add an undesirable layer of complexity. thanks Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Jun 17 11:15:04 2015 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 8D7E71B2CB0 for ; Wed, 17 Jun 2015 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 FyrKkWKEM9_G for ; Wed, 17 Jun 2015 11:15:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25691B2CAB for ; Wed, 17 Jun 2015 11:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1540; q=dns/txt; s=iport; t=1434564902; x=1435774502; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gD2Vui0gzmiDhPjfIjQ9i0TLTgAN2evQ7Zo062nLRSs=; b=IeV4U+/73LsUCF44R0IrN/xx7j0yvQd0uIknHO4rZ8xiGEKnLUhL6P6i EOmfvaEuHcYqouSYmoGJYCrj+MuK2jqHb4TDR7d1tQxlCMvHnIVJJVrOc ijXwxuNGPXXhHqQozu56ONmLIWuy0IlBQ9vIfgDmGjw1K4xSe8yws2vcJ I=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AkBABLuIFV/4wNJK1cDoMCgTMGvVYJh18CgTk4FAEBAQEBAQGBCoQiAQEBAwF5BQsCAQgYLjIlAgQOBQ6IGQjJIQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLRIUGB4MXgRQBBJNoAYIhgU2HWJggJoM7Pm+BRoECAQEB X-IronPort-AV: E=Sophos; i="5.13,634,1427760000"; d="asc'?scan'208"; a="4351644" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jun 2015 18:15:01 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5HIF1XI030245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 18:15:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.178]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 13:15:01 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQqSmGSeHjkF/67E+fZ39CppMgiw== Date: Wed, 17 Jun 2015 18:15:00 +0000 Message-ID: <251C17CD-BFA3-4A59-AC9B-16FB8426E961@cisco.com> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> <5581B628.5030206@isi.edu> In-Reply-To: <5581B628.5030206@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_E1548B36-C1EF-4A01-9E6B-B28EEF065B6D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 18:15:03 -0000 --Apple-Mail=_E1548B36-C1EF-4A01-9E6B-B28EEF065B6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jun 17, 2015, at 11:02 AM, Joe Touch wrote: >=20 > IPv6 *is* the innovation, and because of that - for over 15 years - > "you" (commercial vendors) told users how expensive it would be to > implement and it wasn't ready (because "you" were making higher = margins > on IPv4 equipment). I don't think that's a fair statement. I'd suggest that in discussing = people's motivations, you discuss what you know. I could discuss the = issues we have had with product line management, but not in ASCII. = That's a topic for the bar. --Apple-Mail=_E1548B36-C1EF-4A01-9E6B-B28EEF065B6D 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 iQEVAwUBVYG5Ip9ieig10VPpAQINegf/bhEjTZTX5A4Da1aFsp3Zl5wkjevLDjEb ZGJrUmzSBpUt5z03GmTMH/DaTzYbF+02ZxGo0UQHfqMd0C0uv5uwTm1iyjAaq6/4 P/LVpeRvJJkPsV2iXqAjDLVU0+GXDtJDjirmP7XI6RAKu+GZ5kOnVosS17fcmrQ/ lMu/n//O/rNEIvid4wr8rz/rout+o9HdLgc0lFYx+gblC+e4fwJbKGRROWASk9qD ZjYMSQ6CbPIk42Q3pqtcWm/8kCtbIvDUs3B1MXLfRLwQbQY6qmNGc/QpER+tfZ0/ 2dTaAPz8pK8cDW3UHlopRVMCKb3H3X4l0c/27HGcjv/CTPZGqKdiYg== =FC0P -----END PGP SIGNATURE----- --Apple-Mail=_E1548B36-C1EF-4A01-9E6B-B28EEF065B6D-- From nobody Wed Jun 17 11:18:21 2015 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 957631B2CD1 for ; Wed, 17 Jun 2015 11:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 jId0-sC_TMxj for ; Wed, 17 Jun 2015 11:18:18 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF631B2CB9 for ; Wed, 17 Jun 2015 11:18:17 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::2] (port=53011 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z5Huc-0003ys-Hg; Wed, 17 Jun 2015 20:18:10 +0200 Date: Wed, 17 Jun 2015 20:18:09 +0200 From: Tore Anderson To: sthaug@nethelp.no Message-ID: <20150617201809.54a31cd2@envy.fud.no> In-Reply-To: <20150617.140235.74748217.sthaug@nethelp.no> References: <20150517191841.GA26929@ernw.de> <20150617.140235.74748217.sthaug@nethelp.no> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6-wg@ripe.net, v6ops@ietf.org Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 18:18:19 -0000 * sthaug@nethelp.no > Back to IPv6: I might allow "interesting" IPv6 extension headers > within my own AS - because in such cases I have much more control. > There is no way I'm going to allow IPv6 packets with long chains of > "interesting" IPv6 header chains to pass my border routers. Either > they have short enough header chains that my border routers can > inspect the L4 info at line rate - or they get dropped. Hi Steinar, I wouldn't react to the above if you were operating an enterprise network, but considering you're an ISP and transit provider, I find the above rather surprising (and I do not mean that in a good way). First, your customers might have a perfectly valid reason to send or receive IPv6 headers with IPv6 extension header chains you apparantly will drop at your border. FWIW, if I found out that my upstream arbitrarily dropped packets because they found them "interesting", breaking my applications in the process, I would not remain a customer of theirs for long. Second, the packets might be encrypted using ESP. In that case, you have absolutely no way of knowing if the extension header chain is long enough to be "interesting enough to drop", or if the ESP header is the only extension header there is ("short enough to forward"). What do you do then? Third, your border routers obviously cannot inspect the L4 info in an ESP-encrypted packet at all, line rate or not. Does that mean you drop all ESP packets at your AS borders? I really hope not. Tore From nobody Wed Jun 17 11:22:40 2015 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 812C21A00DF for ; Wed, 17 Jun 2015 11:22:39 -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 bKAyXM-iS0cS for ; Wed, 17 Jun 2015 11:22:38 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCC01A0075 for ; Wed, 17 Jun 2015 11:22:38 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 34F22880ED for ; Wed, 17 Jun 2015 11:22:38 -0700 (PDT) Received: from brians-mbp.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E2E101368282 for ; Wed, 17 Jun 2015 11:22:37 -0700 (PDT) Message-ID: <5581BAE9.3060205@innovationslab.net> Date: Wed, 17 Jun 2015 14:22:33 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net> <20150617180409.GA17739@ernw.de> In-Reply-To: <20150617180409.GA17739@ernw.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MSvkctpGcUKLwH6uEwDgERRR3TubaA62m" Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 18:22:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MSvkctpGcUKLwH6uEwDgERRR3TubaA62m Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Enno, On 6/17/15 2:04 PM, Enno Rey wrote: > On Wed, Jun 17, 2015 at 01:48:15PM -0400, Brian Haberman wrote: >>=20 >>>=20 >>> Let's put it slightly different: the intrusion detector is >>> supposed to detect/block certain application layer attacks. Which >>> it does as long as those come in/pass by without extension >>=20 >> If the device is trying to inspect application-layer data, it might >> as well act like the destination and re-assemble the fragments. >> Yes, this is costly processing, but it mitigates this bypass >> mechanism. >=20 > in theory yes. Given the majority of end host operating systems > happily wait up to 60 seconds for "that last [potentially 42th] Yes, that is a common maximum wait time, but I doubt that it is common. Unfortunately, I don't see any peer-reviewed literature right off that talks about the average wait time to perform fragment re-assembly. > fragment" of a single datagram coming in, this is probably not an > option for all those types of security controls (intrusion detectors, > First Hop Security mechanisms, Infrastructure ACLs) expected to work > mostly in wire speed. It is hence not an option for a number of > networks using such techniques which is why they usually drop all > extension headers except for AH, ESP and (in a few cases) FH. Doing > so is a reasonable decision from their side and will not exactly > encourage widespread development of new services using extension > headers. Which then raises the question: what's the benefit of this > thing called extension headers which do not provide much use today > and might - given there's a growing number of networks acting as > described - not provide much use tomorrow? This thing then seems to > add an undesirable layer of complexity. Hmm... The old NFR platform, which I think got purchased by Checkpoint, performed fragmentation re-assembly prior to doing its analysis. So, at least some products close that hole. Regards, Brian --MSvkctpGcUKLwH6uEwDgERRR3TubaA62m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVgbruAAoJEBOZRqCi7goqObAIAMxScwIb+cenQKNTKNkQ+Uum U9jTmK7TIC5/ZScF1KkcnO74nI5R3WZ03EoTY3mo2ecdgJ2DMNKPFRd1Z1tElCcP nWfDdisfmftZVHLdcNIJk9dtpZ2CgrDRObvi+66Q5CgSB2ABgBj0u00iYiD7OA4f wCMyck6L6iGf1TMAy0/pJJFsoIMZmM/olJ1E2LoDASlc3lZqbWzi6BKeuCN10e/8 VMZm19fW+U6731p0Cfy4hzCtzg90hIidcwI8N+7B0ziv6wzdtBfcaoTkFUEaXXWv B9r9zuXhJ8YOp4sr76da5F4vSp/JzMghgF4jEWLsfwyQc+G4g/h76zEToQRYqL0= =jEbt -----END PGP SIGNATURE----- --MSvkctpGcUKLwH6uEwDgERRR3TubaA62m-- From nobody Wed Jun 17 11:24:29 2015 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 1B4BF1A00EF for ; Wed, 17 Jun 2015 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 5oQ1_sAbHtpG for ; Wed, 17 Jun 2015 11:24:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC541A00EE for ; Wed, 17 Jun 2015 11:24:27 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t5HINCFO024587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Jun 2015 11:23:14 -0700 (PDT) Message-ID: <5581BB0E.70005@isi.edu> Date: Wed, 17 Jun 2015 11:23:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> <5581B628.5030206@isi.edu> <251C17CD-BFA3-4A59-AC9B-16FB8426E961@cisco.com> In-Reply-To: <251C17CD-BFA3-4A59-AC9B-16FB8426E961@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 18:24:28 -0000 On 6/17/2015 11:15 AM, Fred Baker (fred) wrote: > >> On Jun 17, 2015, at 11:02 AM, Joe Touch wrote: >> >> IPv6 *is* the innovation, and because of that - for over 15 years - >> "you" (commercial vendors) told users how expensive it would be to >> implement and it wasn't ready (because "you" were making higher margins >> on IPv4 equipment). > > I don't think that's a fair statement. Perhaps not from those on the vendor's front lines trying to get support for these new protocols into products, but from where the customers sit, that's what we see. Recall there was a time when IPv4 didn't run fast enough and there were proposals to "water it down" so hardware could keep up - or simply skip IP forwarding altogether (via flow/tag switching). The point of my comment was to note that we're repeating history here. We're back where innovation is someone else's problem because hardware can't keep up. I have more faith in the hardware designers. *Temporary* edicts such as "keep the chain short" or sensible caveats such as "keep the headers in the first fragment" are fine, but I hope we don't gut IPv6 for the sole reason of "kicking the can down the road". Joe From nobody Wed Jun 17 11:40:34 2015 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 EAB651B2CD4 for ; Wed, 17 Jun 2015 11:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqUl0cdlJTpM for ; Wed, 17 Jun 2015 11:40:32 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 90C211A1AA6 for ; Wed, 17 Jun 2015 11:40:30 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 645D674CAC; Wed, 17 Jun 2015 20:40:27 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 28279482; Wed, 17 Jun 2015 20:40:27 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id D1785C49E4; Wed, 17 Jun 2015 20:40:26 +0200 (CEST) Date: Wed, 17 Jun 2015 20:40:26 +0200 From: Enno Rey To: Tore Anderson Message-ID: <20150617184026.GA17859@ernw.de> References: <20150517191841.GA26929@ernw.de> <20150617.140235.74748217.sthaug@nethelp.no> <20150617201809.54a31cd2@envy.fud.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150617201809.54a31cd2@envy.fud.no> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 18:40:34 -0000 Hi Tore, On Wed, Jun 17, 2015 at 08:18:09PM +0200, Tore Anderson wrote: > * sthaug@nethelp.no > > > Back to IPv6: I might allow "interesting" IPv6 extension headers > > within my own AS - because in such cases I have much more control. > > There is no way I'm going to allow IPv6 packets with long chains of > > "interesting" IPv6 header chains to pass my border routers. Either > > they have short enough header chains that my border routers can > > inspect the L4 info at line rate - or they get dropped. > > Hi Steinar, > > I wouldn't react to the above if you were operating an enterprise > network, but considering you're an ISP and transit provider, I find the > above rather surprising (and I do not mean that in a good way). > > First, your customers might have a perfectly valid reason to send or > receive IPv6 headers with IPv6 extension header chains you apparantly > will drop at your border. FWIW, if I found out that my upstream > arbitrarily dropped packets because they found them "interesting", > breaking my applications that brings us directly to the core of the debate: break "exactly which application?". there's no single application/service using EHs other than AH/ESP and, maybe in a few corner cases, FH today and I doubt we'll see some tomorrow (given developing such a thing is heavily de-incentivized by the growing number of operators mostly dropping EHs). Taking into account that stateless ACLs of all router vendors we tested (results tb published soon) can be avoided/evaded by adding ~5 extension headers to datagrams I fully understand any operator who does not want SSH on its devices to be reachable from the Internet (over v6 with extension headers) and hence acts in a way similar to the one Steinar described. I doubt Steinar loses many customers (due to "application breakage") by taking that path. In contrary I expect many of his customers valueing the increased level of device & network availability gained by eliminating an entire class of attacks. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Jun 17 12:12:45 2015 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 F0D111A1A94 for ; Wed, 17 Jun 2015 12:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 kcobuA8HZYbY for ; Wed, 17 Jun 2015 12:12:42 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8A41A017C for ; Wed, 17 Jun 2015 12:12:23 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::2] (port=53379 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z5Il1-0005Q3-BG; Wed, 17 Jun 2015 21:12:19 +0200 Date: Wed, 17 Jun 2015 21:12:18 +0200 From: Tore Anderson To: Enno Rey Message-ID: <20150617211218.677e5a88@envy.fud.no> In-Reply-To: <20150617184026.GA17859@ernw.de> References: <20150517191841.GA26929@ernw.de> <20150617.140235.74748217.sthaug@nethelp.no> <20150617201809.54a31cd2@envy.fud.no> <20150617184026.GA17859@ernw.de> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 19:12:44 -0000 Hi Enno, * Enno Rey > On Wed, Jun 17, 2015 at 08:18:09PM +0200, Tore Anderson wrote: > > First, your customers might have a perfectly valid reason to send or > > receive IPv6 headers with IPv6 extension header chains you > > apparantly will drop at your border. FWIW, if I found out that my > > upstream arbitrarily dropped packets because they found them > > "interesting", breaking my applications > > that brings us directly to the core of the debate: break "exactly > which application?" Well, ESP at least. And, by extension, any protocol that might be carried inside ESP, so pretty much all of them. > Taking into account that stateless ACLs of all router vendors we > tested (results tb published soon) can be avoided/evaded by adding ~5 > extension headers to datagrams I fully understand any operator who > does not want SSH on its devices to be reachable from the Internet > (over v6 with extension headers) and hence acts in a way similar to > the one Steinar described. There is a big difference between an operator dropping all packets with EHs that are destined for *his own devices/routers* (I have no problem with that - your devices, your rules), and an operator that drops *transit* traffic destined for his customers because his routers cannot understand/parse/filter its L4/EH payload. In my opinion, an ISP/IP transit network shouldn't even attempt to parse the L4/EH payload in customer traffic (except if the customer asks for it of course), it should just deliver the packets. > I doubt Steinar loses many customers (due to "application breakage") > by taking that path. In contrary I expect many of his customers > valueing the increased level of device & network availability gained > by eliminating an entire class of attacks. The first operator I mentioned above won't lose any customers because his filtering activities doesn't impact customer traffic. The second operator would lose my business, at least. And probably others' too, as business customers might want their site2site IPSEC tunnels to work, residental customers might want their Xbox One online gaming to work, and so on. Tore From nobody Wed Jun 17 13:26:08 2015 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 5DAA81A0092 for ; Wed, 17 Jun 2015 13:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 A4uJSgRU1csb for ; Wed, 17 Jun 2015 13:26:05 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BE4C71A007E for ; Wed, 17 Jun 2015 13:26:04 -0700 (PDT) Received: (qmail 52782 invoked from network); 17 Jun 2015 20:26:02 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Jun 2015 20:26:02 -0000 Date: Wed, 17 Jun 2015 22:26:02 +0200 (CEST) Message-Id: <20150617.222602.74710250.sthaug@nethelp.no> To: tore@fud.no From: sthaug@nethelp.no In-Reply-To: <20150617211218.677e5a88@envy.fud.no> References: <20150617201809.54a31cd2@envy.fud.no> <20150617184026.GA17859@ernw.de> <20150617211218.677e5a88@envy.fud.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 20:26:07 -0000 > > Taking into account that stateless ACLs of all router vendors we > > tested (results tb published soon) can be avoided/evaded by adding ~5 > > extension headers to datagrams I fully understand any operator who > > does not want SSH on its devices to be reachable from the Internet > > (over v6 with extension headers) and hence acts in a way similar to > > the one Steinar described. > > There is a big difference between an operator dropping all packets with > EHs that are destined for *his own devices/routers* (I have no problem > with that - your devices, your rules), and an operator that drops > *transit* traffic destined for his customers because his routers cannot > understand/parse/filter its L4/EH payload. I certainly appreciate this distinction. However, problems arise in practice when customers *ask* for various types of protection - which are most sensibly implemented on border routers. Just to be clear - we don't drop IPsec traffic today (neither IPv6 nor IPv4). > In my opinion, an ISP/IP transit network shouldn't even attempt to > parse the L4/EH payload in customer traffic (except if the customer > asks for it of course), it should just deliver the packets. The problem is - the customer *does* ask for it, in many cases. > > I doubt Steinar loses many customers (due to "application breakage") > > by taking that path. In contrary I expect many of his customers > > valueing the increased level of device & network availability gained > > by eliminating an entire class of attacks. > > The first operator I mentioned above won't lose any customers because > his filtering activities doesn't impact customer traffic. The second > operator would lose my business, at least. And probably others' too, as > business customers might want their site2site IPSEC tunnels to work, > residental customers might want their Xbox One online gaming to work, > and so on. I agree - IPSEC tunnels and Xbox One online gaming need to work. That doesn't mean *all* extension header combinations should be expected to work - and it appears that they often don't. I expect we'll see much more of these discussions in the coming years, as IPv6 traffic grows. And I certainly also expect significant size IPv6 DDoS attacks - at least some of which will probably be based on extension header manipulation. Steinar Haug, AS 2116 From nobody Wed Jun 17 14:13:37 2015 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 7F7FD1A8756 for ; Wed, 17 Jun 2015 14:13:36 -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 fqR18vDy7e6T for ; Wed, 17 Jun 2015 14:13:34 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82541A8729 for ; Wed, 17 Jun 2015 14:13:34 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so49302525pdb.1 for ; Wed, 17 Jun 2015 14:13:34 -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=bKOVIUSUVRmLwxCr2AagMum7bcAFcGxWjPZ56eN6j0c=; b=ByYtde5ws64HhPkFkfLqTXPekJ34t9WWsKu7pv0AJq6DDo3nK8DJaXHJb3bQE3+2dF uieUAH11Q6v4SIaWdvUCNr4C//T6BVgDvym3ygnP1mwk5EM2dEbF4yh7PoDHhNgtK5cm ALTQu5tWt6I1QaqMVi0ol1Ind1rKTMof+by8dqYT6f3lb76GoeUqkSHBdXdua9NMvAHN 6cE/P5nEjyPQeOY7uwsgSiTx9dH2lJXBYwG76PEFz1pmQbwJaj0KfN3QS01NAKaWp5CJ Evz43QAcOaW8VhXkp9BxJw+cp//aihXdxBAL0fncJvcB4zF+UGEAyYttJI8yPzCMAzKy IKSg== X-Received: by 10.66.119.174 with SMTP id kv14mr14471904pab.5.1434575614397; Wed, 17 Jun 2015 14:13:34 -0700 (PDT) Received: from ?IPv6:2406:e007:64d6:1:28cc:dc4c:9703:6781? ([2406:e007:64d6:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id o7sm5706139pdi.16.2015.06.17.14.13.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 14:13:32 -0700 (PDT) Message-ID: <5581E2FF.9080902@gmail.com> Date: Thu, 18 Jun 2015 09:13:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Enno Rey , Jen Linkova References: <20150617.140235.74748217.sthaug@nethelp.no> <20150617.152750.41635871.sthaug@nethelp.no> <20150617133328.GB16716@ernw.de> <20150617140032.GB16806@ernw.de> In-Reply-To: <20150617140032.GB16806@ernw.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 21:13:36 -0000 Catching up on a few points in this thread that went crazy while I was sleeping... On 18/06/2015 02:00, Enno Rey wrote: ... > Yes, we're aware of RFC7112. It's just: no OS we know and no devices we're aware of (feel free to provide pointers) implement RFC 7112 as of today. No, it's too new. But I suggest that it gives you license to drop packets with fragmented header chains, and tell anyone who complains that they don't conform to the IPv6 standard. > but many attack tools implement the techniques mentioned above. Which is why quite some operators (in particular, but not only) from enterprise and managed service provider/cloud space drop all EHs except, maybe, AH+ESP. Whereas dropping *all* EHs breaks the IPv6 standard. On 18/06/2015 03:11, Ca By wrote: > For the folks looking for extension header innovation, would you be willing > to work on IP version X instead of IPv6? Or perhaps you can use the Class > E IPv4 space for your innovation? Now that's a polemic, not an argument. But since you ask: of course not. > Serious. IPv6 is not a place for innovation at the Network / Internet > layer. EHs as an extension mechanism are *not* innovation. They've been in the design for 20 years. I'm actually with Fred on this: it's time for the hardware designers to step up. With RFC 7112, we've told them that the maximum packet size they need to parse is 1280 (after removing tunneling overhead). Brian From nobody Wed Jun 17 16:29:04 2015 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 49E6B1B2C9E for ; Wed, 17 Jun 2015 16:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 vsiQUtCqwcrp for ; Wed, 17 Jun 2015 16:28:59 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F045E1ACDF5 for ; Wed, 17 Jun 2015 16:28:58 -0700 (PDT) Received: by obbsn1 with SMTP id sn1so43387554obb.1 for ; Wed, 17 Jun 2015 16:28:58 -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=ZLNEsacmGcwkFNF+RzfmSxIZSwfwcTvjWuKOaUXPaAk=; b=Nf+9ANGD9PuOa6BQp9knajG+0rhIUMrwq9CkVeYb5qag3IvOJfJxW3sHmErFw2NPce yVzeXoywSbf8aXVgVdjvAoMaHSyF/pIRxxIoostCt5+s5fDJbsoO/I2MSAYZC8kIzvvA Rc/J+PekmYKNor3PHGEfcrURfGyWX/UljKut9PNygKm5rnJd1KVvz+gR0OXFuXGGsb+2 GB01Z75+DwWZdmXZ2JdT2dL5SQiqW4qrg7lj4vNklyApb0sWt+MBCafmvCRg9ZkrDwF2 6oOGMkdE0knKqfNPWesDpTsVPuDnZ83xQn8dj97EK+hzPSMo4pJz6X10Ai+s2dW/lYM/ 5sog== X-Gm-Message-State: ALoCoQnzYUWhIw/FV8yK2UPxu0EcNr5+jiF//2vifRsPbiPZYGHOmfgcjfDJ5YmVVPhdmR0ua05V MIME-Version: 1.0 X-Received: by 10.60.34.36 with SMTP id w4mr4363952oei.69.1434583738397; Wed, 17 Jun 2015 16:28:58 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Wed, 17 Jun 2015 16:28:58 -0700 (PDT) In-Reply-To: <5581B2DF.8040207@innovationslab.net> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net> Date: Wed, 17 Jun 2015 19:28:58 -0400 Message-ID: From: Warren Kumari To: Brian Haberman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 17 Jun 2015 23:29:01 -0000 On Wed, Jun 17, 2015 at 1:48 PM, Brian Haberman wrote: > > > On 6/17/15 1:43 PM, Enno Rey wrote: > >> >> Let's put it slightly different: the intrusion detector is supposed >> to detect/block certain application layer attacks. Which it does as >> long as those come in/pass by without extension > > If the device is trying to inspect application-layer data, it might as > well act like the destination and re-assemble the fragments. Yes, this > is costly processing, but it mitigates this bypass mechanism. It also: A: assume that all the packets go through this device and B: that the device has enough state space to store bits until the fragments have all shown up (a standard attack against reassembling firewalls / ALGs is to send a fragment with the attack, then a whole heap-o-fragments that you never intend to complete (to starve buffer space) and then the final attack fragment. The FW can choose to A: fail open (allow the oldest uncompleted fragment when the buffer fills up) or B: fail closed / DoS (drop oldest fragments when the buffer fills). Neither is good. The attacker gets to set how long they wait before sending the final bits... I have some expense reports that I desperately don't want to do, so I'll procrastinate and try figure out just if this is even build able, regardless of cost... Linux has 60s (http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/net/ipv6.h#L253 ), but let's choose 10s for how long we expect to be able to reassemble for - that's 125GB on a 100Gb interface. Unfortunately we cannot just use regular DRAM here (buffer memory for 100Gbps needs to be fast, especially for small packets), so realistically you are looking at RLDRAM (reduced latency DRAM) - SRAM would be draw even more power, cost more, lower density, etc and DDR3 doesn't have the cycle time. A quick look shows Micron's largest RLDRAM seems to be MT44K32M36RCT-125E (http://www.micron.com/~/media/documents/products/data-sheet/dram/1gb_twindie_rldram3.pdf), a 10ns cycle time 32Meg x 36 wide chip, for 144MB (1152Mbit) per part. For 125GB I'll need 889 of those. A Cisco CRS-16 with CRS-X 4-Port 100GE blades gives me 64x 100Gb ports, so 8TB of fast RAM, or 56,896 ram chips. Calculating current consumption is tricky, because it depends upon how the memory is being accessed (which the attacker can also (somewhat) control, but using Micron's helpful power calculator spreadsheet we get ranges from 2154mw to 4035mw. Assuming there are no reads or writes 99% of the times, we get a consumption of 2022mw + 151mw, for a total of 2173mw, or 2.127W per chip. We have almost 57,000 of them, so that's 123KW per router in memory alone (keep in mind there is also the memory management, etc) . Currently the max power of a fully loaded CRS-1 16 is ~10KW, so that's a 12X increase just for the RAM. Tempkin / RAS's NANOG presentation "Help! My Big Expensive Router Is Really Expensive! " (https://www.nanog.org/sites/default/files/wednesday.general.temkin.panel.pdf) and Wobker's 'Power Consumption in High-End Routing Systems' (https://www.nanog.org/meetings/nanog54/presentations/Wednesday/Wobker.pdf ) shows the power consumption becomes distinctly linear -- you need to move so much air to cool many KW that your fan / cooling system starts to become a significant power draw. At this point you need to start pumping even more air to cool the cooling, and so it spirals out of control... I'm not going to bother trying to calculate that, because, frankly, I've gotten bored and want my dinner :-) ... and success, it is now too late to do my expense report, that will be pushed to tomorrow :-) W > > Regards, > Brian > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Jun 17 18:31:43 2015 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 BAE2F1A9051 for ; Wed, 17 Jun 2015 18:31:41 -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 KX2fllDOjXOB for ; Wed, 17 Jun 2015 18:31:39 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01F31A906F for ; Wed, 17 Jun 2015 18:31:38 -0700 (PDT) Received: by pdjn11 with SMTP id n11so53848989pdj.0 for ; Wed, 17 Jun 2015 18:31:38 -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=HxM3TIbXLjKMN/8DSOkTCYOjvlFhzjCFx5pR10mVcAo=; b=KPGqwMbrWa94I6IJy17g3/IbzrvC/ZGdm1dcUSBxJA3S9Vr/5a6tmsmXNjw0wVRgBz Ry1ZCouR5fFfTf3ZdnlzuzVDTRraVllu6uLylQwGBTfD02hbAtq+L5q5Cbvuc3yMOOFk 8Bz5lN3EWI9dKnoHIJxMdYCkvQEv5t73JMkvs/D5rriPDL/6kNUt5qqHI97l81AXJNFz MRrVjuRyr9JQ01i+aRA9TCXjenO8pwfTdlGkv4qTpc3CXdjiXmVQy5FJDVyM1V4URlol X2OmdR8WrVxL6r87FagDJC3jxzSDxJ2BKipm/ligioN6FFkagUMvD0U+o48lgVZ4xI6V 6EvA== X-Received: by 10.70.96.65 with SMTP id dq1mr16413107pdb.79.1434591098531; Wed, 17 Jun 2015 18:31:38 -0700 (PDT) Received: from ?IPv6:2406:e007:64d6:1:28cc:dc4c:9703:6781? ([2406:e007:64d6:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bn5sm5992309pbc.82.2015.06.17.18.31.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 18:31:37 -0700 (PDT) Message-ID: <55821F7B.6010005@gmail.com> Date: Thu, 18 Jun 2015 13:31:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jen Linkova References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 18 Jun 2015 01:31:41 -0000 On 18/06/2015 04:54, Jen Linkova wrote: > On Wed, Jun 17, 2015 at 3:24 AM, Brian E Carpenter > wrote: >> On 17/06/2015 07:02, Jen Linkova wrote: >>> https://tools.ietf.org/html/draft-wkumari-long-headers-03 >>> >>> Comments are appreciated... >> >> In REQ-2 on HbH headers, you say: >> >>> The forwarder MUST >>> process each option as specified in Section 4.2 of [RFC2460]. >> >> That aspect of RFC 2460 was fundamentally changed by RFC 7045. > > Oh, very good point. Thanks for pointing this out. Looks like it does > cover our REQ2 (but requires different behavior). > > So, Section 2.1 RFC7045 says about *all* EHs: > > "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. " > > and then, in Section 2.1 for HbH: > "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. ". > > I read this as 'if a router does not recognize/parse the HbH header, > it MUST not discard it unless there is an explicit policy configured. > It may just ignore it or send for "special processing" via slow path. > > So it assumes that it is always safe to ignore HbH header (as if all > options in the header had highest-order two bits set to '00') while > our draft proposed quite different approach ("drop and send ICMP > back"). Right. And we can have that discussion, of course, but IMNSHO a firewall should either let stuff through or drop it for a congigured reason; dropping it because the product development manager made a lazy choice is not OK. > Ignoring HbH header seems to be reasonable and safe if we are sure > that every single existing or to be developed HbH option can be safely > ignored (or options which could be ignored must be in the very > beginning of the header...). Well, we can't know today what sort of crazy option might be invented in future; so the thinking behind draft-ietf-opsec-ipv6-eh-filtering seems right to me. Maybe that's a draft you need to be tracking. To be honest what I was thinking when we added discussion of HbH to RFC 7045 was not so much fixing the slow routers, but warning the community that "hop-by-hop" does not mean every hop. Fred would like to fix that with his 6man draft, and I don't mean to attack that idea. > In the light of RFC7045 it looks to me that one possible approach for > REQ2 might be: > - if a forwarder can not parse the HbH header and there is no > explicitly configurable policy, AND if the forwarder is trying to be a firewall or otherwise wants to interfere. If not, just forward the packet, already! > it SHOULD > either: > -- if the forwarder can not parse any of options or if all parsed > options have highest-order two bits set to '00') - ignore the header; > -- if the forwarder was able to parse some of options and at least > one of the options has highest-order two bits set to smth except '00' > - discard the packet and send ICMPv6 message if Section 4.2 of RFC > 2460 requires so (sending ICMPv6 MAY be subject to a configurable > policy) > or send it to slow path for full header processing (subject to a > configurable policy). > > How does that sound? As I said: if the forwarder insists on doing something, OK. But we have to think for a typical use case: does it matter if a forwarder simply ignores the HbH header? For example, for the IntServ/RSVP case, it just makes that router transparent to RSVP. That doesn't break RSVP; discarding the packet does. That was the thinking behind RFC 7045. Brian >> I'm sure other things in the long-headers draft need revising as a >> result of RFC 7045, since its whole topic is the handling of extension >> headers ("This document updates RFC 2460 to clarify how intermediate >> nodes should deal with such extension headers and with any that are >> defined in the future.") > > Yes, we'll revise it, thanks for the comment. >> >> Y'all also need to take account of RFC 7112, which forbids fragmented >> header chains. > > We do mention 7112 but I agree, we should explicitly mention that > header chain is limited by a packet size...Will update the doc. > > From nobody Wed Jun 17 21:26:30 2015 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 78A2B1B2B6E; Wed, 17 Jun 2015 21:26:27 -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 J_7hgkdKhOFX; Wed, 17 Jun 2015 21:26:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 426A61B2B72; Wed, 17 Jun 2015 21:26:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150618042625.603.37450.idtracker@ietfa.amsl.com> Date: Wed, 17 Jun 2015 21:26:25 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-02.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, 18 Jun 2015 04:26:27 -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 : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) Authors : Matt Byerly Matt Hite Joel Jaeggli Filename : draft-ietf-v6ops-pmtud-ecmp-problem-02.txt Pages : 8 Date : 2015-06-17 Abstract: This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-pmtud-ecmp-problem-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 17 21:29:26 2015 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 B069A1B2B99 for ; Wed, 17 Jun 2015 21:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.201 X-Spam-Level: *** X-Spam-Status: No, score=3.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 7sVyioHro1L0 for ; Wed, 17 Jun 2015 21:29:23 -0700 (PDT) Received: from nm47-vm7.bullet.mail.bf1.yahoo.com (nm47-vm7.bullet.mail.bf1.yahoo.com [216.109.115.142]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7BE1B2BB3 for ; Wed, 17 Jun 2015 21:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1434601762; bh=wkHGg38bWu40lvUxndTNktigBBl5wnxS4V/Ztay7ulo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=DMRcVCOUdjjXLT2CP+Rtgl1jbHV7mo3eQ9qnPAwKSpzpk77MIrj5UaQNsYVK7szgfj46wlmrXy5Pky2mgGOOlr7l9i4TkI4YcwBzqc7DzSrwgECIRMNqiHDx4Z9jEJdT4Rvyf0f5xXltuJtOTfRsiQYUNlrV/nD8KR4xADCcx4/7H8meSop3AV9QwGUGKw8+yT88JSRaRAZB+TyP3psrHVKIzZNZWGppkdEQ0WOwer+YEKS4HgLXbeKY0THRyqLdqLFNe3cMRZLxhwAR7Y0MKfi17Sz7RtYMi9prIti/6lA/kigz4DsdFo3K9j7SL6Ukp8aVdYRLwfav1t9HT2XdCw== Received: from [66.196.81.172] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 04:29:22 -0000 Received: from [98.139.212.226] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 04:29:22 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 04:29:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 716871.14771.bm@omp1035.mail.bf1.yahoo.com X-YMail-OSG: IsKZOxQVM1mB_zKNVwyVkvcY3oVH4GvGGu4d22WDhJX9N3Z39Hr5OVUScr2WUdU WVy5DK5uH2JWlLNy6MTWbSpAz5CzgU7.EEcgSUDUn0bSKQnlqLt0GPGJB8MfYBq9FUpLbjx0s17h GHqCqTobZokPGJp.sO5fLUBU2EJx7H3hIL8oRKmif356f1EfhJPtanFrAZEiGAEOQh3dgIi05K.o yKsZbmH7.zIImFrK9b5a0tIoHwgtb9OZKAmT8F_oA2dicx6W0hATNVoJfitDJBBWqOvF3qvJ2sKz eXT2cBsIKSQbvPK79k6J1ffHJTrRLPCcqy9r8FH9OnaOyoMx6TXbATbHsE9QFclpwJRPV1SOUTlu BEQIx4q7uEHkAZS8DjRUBcbX8VYF2Lb1wWgW1gu4r_C0xIbWPhVaodPLKv.aMCey.OkDcoBkbfLt 6CWSr9jDcQotD0CO52zjHhgjtl0e7CSibMqaRzs43yiQRpy_u_4LtWHgjHu1JKZlU9sSEW5K2ieG Fld9_2Is5zL6DDRHiUJB7V3uwOI1mTCwmX0vy6AzFJx.6oMGl_g-- Received: by 66.196.80.148; Thu, 18 Jun 2015 04:29:22 +0000 Date: Thu, 18 Jun 2015 04:29:21 +0000 (UTC) From: Mark ZZZ Smith To: "v6ops@ietf.org" Message-ID: <1011211331.1157047.1434601761591.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <5581B2DF.8040207@innovationslab.net> References: <5581B2DF.8040207@innovationslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] So what is or are the problem or problems to be solved? (Re: [ipv6-wg] Extension Headers / Impact on Security Devices) 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, 18 Jun 2015 04:29:24 -0000 Hi, ________________________________ From: Brian Haberman To: v6ops@ietf.org=20 Sent: Thursday, 18 June 2015, 3:48 Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devic= es On 6/17/15 1:43 PM, Enno Rey wrote: >=20 > Let's put it slightly different: the intrusion detector is supposed > to detect/block certain application layer attacks. Which it does as > long as those come in/pass by without extension If the device is trying to inspect application-layer data, it might as well act like the destination and re-assemble the fragments. Yes, this is costly processing, but it mitigates this bypass mechanism. / Not specifically replying to Brian's email, however I think it is a step = towards what I'm going to ask. / So I think everybody is making valid points, yet the set of points are in= consistent and sometimes in conflict. I think that is a sign to step back a= nd think a bit more about better identifying and describing the problem or = problems. / I think there are actually 3 security problems people are trying to solve= in this discussion: / (1) mitigating network capacity DoS attacks on high speed forwarding devi= ces / (2) protecting the in-band control plane of forwarding devices / (3) performing host/application security via a proxy device in the networ= k ("firewalling, IDS/IPS", i.e., middleboxes) / So for each of these different problems, what are the requirements, the c= onstraints and where are they best solved (in the network, in the hosts, or= possibly a mix of both)? / A few thoughts I have on the above: / (1) I think TCP/UDP port level filtering for this purpose is certainly a = nice to have but not a necessary to have, because network capacity DoSs wil= l use some other protocol for their DoS if mitigating DoSs using TCP/UDP tr= affic becomes too effective. Completely dropping DoS traffic identified jus= t by src and/or dst address, or plonking that traffic into a scavenger QoS = class for a while if complete dropping is too severe is a general solution = that will work regardless of the type of DoS traffic. Using TCP/UDP ports i= f they're easily available would allow the dropping to be more granular, bu= t is not required to mitigate the network capacity DoS. /(2) The control plane is really a host (because it is the final destinatio= n for the packets sent to the control plane), so it needs "host style" prot= ection, which I think means stateless methods aren't effective enough - for= example, I think spoofed src address fragmented OSPF packets could be used= to attack the OSPF instance, yet they'd pass the stateless ACLs, which is = why we enable IGP/BGP authentication, validate hopcounts etc.. Ultimately, = moving the control plane completely out of band (as the telephony people di= d, and "SDN"/Openflow does) would place the control plane completely out of= reach of malicious in-band traffic sources. / (3) I think this is always going to be impractical to do well in fast, fi= xed or limited function hardware, as it is necessary to do just too much ho= st type processing. We scale solutions to problems on the Internet by using= "divide-and-conquer" and achieve that by pushing them towards or onto the = actual edge i.e., the hosts. So I think (3) is far more possible to achieve= d by either doing it in lots of lower throughput but higher inspection soft= ware based forwarding devices close to the edge, or leaving the hosts to do= it themselves (because they know best what is and isn't legitimate traffic= for their own OS and applications, and they might also be multi-homed, so = have a security perspective that a single device on one of the upstream lin= ks can't.), with perhaps close by devices in the network performing a secon= dary assisting and more coarse security role (e.g., stateless ACLs that mat= ch on no more either basic src/dst address or TCP/UDP ports, following an E= H chain to find the TCP/UDP port information if necessary, but not doing an= y further analysis, leaving that to the receiving host) / Regards, Mark. From nobody Wed Jun 17 23:54:02 2015 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 9BB4D1B3054 for ; Wed, 17 Jun 2015 23:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 19K5mc4FGJb0 for ; Wed, 17 Jun 2015 23:53:59 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id E653E1B3053 for ; Wed, 17 Jun 2015 23:53:58 -0700 (PDT) Received: (qmail 77095 invoked from network); 18 Jun 2015 06:53:56 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 18 Jun 2015 06:53:56 -0000 Date: Thu, 18 Jun 2015 08:53:56 +0200 (CEST) Message-Id: <20150618.085356.74676764.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com From: sthaug@nethelp.no In-Reply-To: <5581E2FF.9080902@gmail.com> References: <20150617140032.GB16806@ernw.de> <5581E2FF.9080902@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 18 Jun 2015 06:54:01 -0000 > > Yes, we're aware of RFC7112. It's just: no OS we know and no devices we're aware of (feel free to provide pointers) implement RFC 7112 as of today. > > No, it's too new. But I suggest that it gives you license to drop packets > with fragmented header chains, and tell anyone who complains that they > don't conform to the IPv6 standard. It may be relevant to ask for RFC 7112 support next time we're doing an equipment RFQ (in a few years). > > but many attack tools implement the techniques mentioned above. Which is why quite some operators (in particular, but not only) from enterprise and managed service provider/cloud space drop all EHs except, maybe, AH+ESP. > > Whereas dropping *all* EHs breaks the IPv6 standard. Obviously. But until RFC 7112 support is available, I believe we will see a significant amount of breakage for IPv6 extension headers - and header chains will be limited to significantly less than 1280 bytes. > EHs as an extension mechanism are *not* innovation. They've been in the design > for 20 years. I'm actually with Fred on this: it's time for the hardware > designers to step up. With RFC 7112, we've told them that the maximum packet > size they need to parse is 1280 (after removing tunneling overhead). IPv6 extension header processing is sufficiently complex that I'm not at all sure that "time for the hardware designers to step up" will be enough. My prediction is that we'll see security alerts from hardware manufacturers for many years to come, due to the complexity. Steinar Haug, AS 2116 From nobody Thu Jun 18 02:30:34 2015 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 0BE1B1B30C2 for ; Thu, 18 Jun 2015 02:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 zcqHKKIxv4he for ; Thu, 18 Jun 2015 02:30:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A271B30C1 for ; Thu, 18 Jun 2015 02:30:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5I9USZB016290; Thu, 18 Jun 2015 11:30:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 280BC2043B7; Thu, 18 Jun 2015 11:33:15 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0F70A2043BC; Thu, 18 Jun 2015 11:33:15 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5I9USsu004505; Thu, 18 Jun 2015 11:30:28 +0200 Message-ID: <55828FB4.9000706@gmail.com> Date: Thu, 18 Jun 2015 11:30:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ca By References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 18 Jun 2015 09:30:32 -0000 Then is it using 64share? CLAT? Alex Le 17/06/2015 19:38, Ca By a écrit : > > > On Wed, Jun 17, 2015 at 10:36 AM, Alexandru Petrescu > > wrote: > > Le 17/06/2015 05:23, Mikael Abrahamsson a écrit : > > On Tue, 16 Jun 2015, Fred Baker (fred) wrote: > > http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/ > > > https://developer.apple.com/videos/wwdc/2015/?id=719 is the talk > that > discussed this directly. Well worth spending an hour on. > > > Thanks Mikael for the pointer. It's good it is described at that > length - 1 hour. It's an opportunity to learn before the others > where these products go with respect to IPv6. But I dont have that > hour :-) > > I would like to know though what kind of IPv6 is made mandatory in > that manufacturer's smartphones. > > Is it using ULAs? > > > No > > Is it using DHCPv6? Prefix Delegation? > > > No > > Is it using NAT66 or not? > > > No > > To those who spent that hour may know... > > Alex > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Jun 18 03:04:50 2015 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 2A0BF1B310A for ; Thu, 18 Jun 2015 03:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 ZBEiOn5ebxzX for ; Thu, 18 Jun 2015 03:04:46 -0700 (PDT) Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by ietfa.amsl.com (Postfix) with SMTP id 3CA191B3109 for ; Thu, 18 Jun 2015 03:04:45 -0700 (PDT) Received: (qmail 85684 messnum 2469632 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 18 Jun 2015 10:04:43 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail00.svc.cra.dublin.eircom.net (qp 85684) with SMTP; 18 Jun 2015 10:04:43 -0000 Received: from [192.168.1.2] ([95.44.35.164]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id hm4g1q00S3YUviP01m4jcR; Thu, 18 Jun 2015 11:04:43 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: <55828FB4.9000706@gmail.com> Date: Thu, 18 Jun 2015 11:04:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53E80738-B5E7-4FF9-A37C-ADC545C52DC2@eircom.net> References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> <55828FB4.9000706@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 18 Jun 2015 10:04:48 -0000 > On 18 Jun 2015, at 10:30, Alexandru Petrescu = wrote: >=20 > Then is it using 64share? CLAT? >=20 > Alex I don=E2=80=99t see any mention of the 464xlat CLAT or 64share in their = presentation.=20 Single IPv6-only APN designs for handset and tethered IPv4 traffic = don=E2=80=99t seem to be supported yet.=20 Ross= From nobody Thu Jun 18 03:10:17 2015 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 F20ED1B3116 for ; Thu, 18 Jun 2015 03:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.035 X-Spam-Level: * X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 aw5DVjMLksHQ for ; Thu, 18 Jun 2015 03:10:14 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F224C1B3113 for ; Thu, 18 Jun 2015 03:10:13 -0700 (PDT) Received: from 10.236.62.152 (EHLO OPE10HT02.tp.gk.corp.tepenet) ([10.236.62.152]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DSO23171; Thu, 18 Jun 2015 12:10:06 +0200 (CEST) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: Ross Chandler , Alexandru Petrescu Thread-Topic: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post Thread-Index: AQHQqGWYlWpJDsMry0Cck6ahVOVCo52v54uAgADuYQCAAAB7AIABChkAgAAJeoCAACIDEA== Date: Thu, 18 Jun 2015 10:09:19 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745FC06CE@OPE10MB05.tp.gk.corp.tepenet> References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> <55828FB4.9000706@gmail.com> <53E80738-B5E7-4FF9-A37C-ADC545C52DC2@eircom.net> In-Reply-To: <53E80738-B5E7-4FF9-A37C-ADC545C52DC2@eircom.net> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2015.6.18.91215:17:7.944, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __HAS_APPLE_URI, __HTTPS_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, __CP_MEDIA_BODY, __SUBJ_ALPHA_NEGATE, __FORWARDED_MSG, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1400_1499, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, WEBMAIL_SOURCE, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0201.558298FE.0202, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0201.558298FE.0202, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 60cc2e6e17450ab81b6e66f1b3e0d282 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 18 Jun 2015 10:10:16 -0000 aHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL3ZpZGVvcy93d2RjLzIwMTUvP2lkPTcxOSAgIGFu ZCBnZXQgUERGDQoNCnNsaWRlIDI2DQoNCldoYXQgV29ya3M/DQpJUHY0IGFkZHJlc3MgbGl0ZXJh bHMsIGluIE5BVDY0ICsgRE5TNjQgbmV0d29ya3MNCk5ldyBmb3IgT1MgWCAxMC4xMSBhbmQgaU9T IDkNClVzZSBoaWdoZXItbGF5ZXIgbmV0d29ya2luZyBmcmFtZXdvcmtzDQrigKIgTlNVUkxTZXNz aW9uIGFuZCBDRk5ldHdvcmstbGF5ZXIgQVBJcw0KQ2xpZW50IHN1cHBsaWVzIElQdjQgYWRkcmVz cyBMaXRlcmFsDQrigKIgT1Mgc3ludGhlc2l6ZXMgSVB2NiBhZGRyZXNzDQoNCkJSLA0KTWN6DQoN Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NzIENoYW5kbGVyDQpTZW50OiBU aHVyc2RheSwgSnVuZSAxOCwgMjAxNSAxMjowNCBQTQ0KVG86IEFsZXhhbmRydSBQZXRyZXNjdQ0K Q2M6IElQdjYgT3BzIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY2ICYgaU9TOSAtIGludGVy ZXN0aW5nIGZhY3RvaWRzIGluIHRoaXMgQXJzIFRlY2huaWNhIHBvc3QNCg0KDQo+IE9uIDE4IEp1 biAyMDE1LCBhdCAxMDozMCwgQWxleGFuZHJ1IFBldHJlc2N1IDxhbGV4YW5kcnUucGV0cmVzY3VA Z21haWwuY29tPiB3cm90ZToNCj4gDQo+IFRoZW4gaXMgaXQgdXNpbmcgNjRzaGFyZT8gIENMQVQ/ DQo+IA0KPiBBbGV4DQoNCkkgZG9u4oCZdCBzZWUgYW55IG1lbnRpb24gb2YgdGhlIDQ2NHhsYXQg Q0xBVCBvciA2NHNoYXJlIGluIHRoZWlyIHByZXNlbnRhdGlvbi4gDQoNClNpbmdsZSBJUHY2LW9u bHkgQVBOIGRlc2lnbnMgZm9yIGhhbmRzZXQgYW5kIHRldGhlcmVkIElQdjQgdHJhZmZpYyBkb27i gJl0IHNlZW0gdG8gYmUgc3VwcG9ydGVkIHlldC4gDQoNClJvc3MNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3Bz QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu Jun 18 04:33:03 2015 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 87B5E1A02F1 for ; Thu, 18 Jun 2015 04:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 B-GccJBkE9AV for ; Thu, 18 Jun 2015 04:33:01 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5CC1A028A for ; Thu, 18 Jun 2015 04:33:01 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DA6CC880E2 for ; Thu, 18 Jun 2015 04:33:00 -0700 (PDT) Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7BCB771B0002 for ; Thu, 18 Jun 2015 04:33:00 -0700 (PDT) Message-ID: <5582AC60.7090304@innovationslab.net> Date: Thu, 18 Jun 2015 07:32:48 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IPv6 Operations References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L9Ig9dXVvRdXRCSaFCne4EMKTxurm0hoD" Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 18 Jun 2015 11:33:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L9Ig9dXVvRdXRCSaFCne4EMKTxurm0hoD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Warren, On 6/17/15 7:28 PM, Warren Kumari wrote: > On Wed, Jun 17, 2015 at 1:48 PM, Brian Haberman > wrote: >> >> >> On 6/17/15 1:43 PM, Enno Rey wrote: >> >>> >>> Let's put it slightly different: the intrusion detector is supposed >>> to detect/block certain application layer attacks. Which it does as >>> long as those come in/pass by without extension >> >> If the device is trying to inspect application-layer data, it might as= >> well act like the destination and re-assemble the fragments. Yes, this= >> is costly processing, but it mitigates this bypass mechanism. >=20 > It also: > A: assume that all the packets go through this device and > B: that the device has enough state space to store bits until the > fragments have all shown up (a standard attack against reassembling > firewalls / ALGs is to send a fragment with the attack, then a whole > heap-o-fragments that you never intend to complete (to starve buffer > space) and then the final attack fragment. > The FW can choose to A: fail open (allow the oldest uncompleted > fragment when the buffer fills up) or B: fail closed / DoS (drop > oldest fragments when the buffer fills). Neither is good. The attacker > gets to set how long they wait before sending the final bits... >=20 > I have some expense reports that I desperately don't want to do, so > I'll procrastinate and try figure out just if this is even build able, > regardless of cost... >=20 > Linux has 60s (http://www.cs.fsu.edu/~baker/devices/lxr/http/source/lin= ux/include/net/ipv6.h#L253 > ), but let's choose 10s for how long we expect to be able to > reassemble for - that's 125GB on a 100Gb interface. Unfortunately we So, just a push back on these two assumptions. Are they in conflict? Would you really buffer 10 seconds worth of data on a 100Gbps interface? But, that is beside the point... While the accompanying numbers are interesting (thanks for calculating them) and scary, they don't really address my point. These types of intermediate security devices will always be at a disadvantage since: 1) They need to inspect all the way to the application (or maybe transport) layer, 2) at line rate, and 3) protect orders of magnitude more end nodes= =2E Mark's later e-mail is more articulate in pointing out that there are three (or maybe more) distinct security issues being discussed here. These need to be teased apart rather than addressing them partially with short-term approaches. Regards, Brian --L9Ig9dXVvRdXRCSaFCne4EMKTxurm0hoD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVgqxmAAoJEBOZRqCi7goqMVkIAJvEUNMN/o8xcCCgPs3hlAke Q9RB+xKvAn10YRNFJxDx8DT4n3cM+En8MWs/F4CPD9/xF14/Wa6bqvcrL1MfTkOT byBip68eIdUGQYKLbk09ur8PtQCqz7HvEmzA+F1sFnLQJvPhemzj4g89Iy+Ysr1n /2Bncq55OPtvYgV6UmrhNEsmN7jUA9HtyoO7hiGhWY/mdXwF1GLAxx5hC1ND2LXd +ZwpRVkovlVUnL3+ugz1VsBNOQCD+fbtw5i0K5C/oVfF99GpVoyaISWc1d4RrvZy 0sroY4o4auISmMutJuY0ltOd1la9mL4VvXgxUgWwGP+QzTcdhNy0iLIh7CiHovY= =y82+ -----END PGP SIGNATURE----- --L9Ig9dXVvRdXRCSaFCne4EMKTxurm0hoD-- From nobody Thu Jun 18 10:26:15 2015 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 D2C8F1B2A6E for ; Thu, 18 Jun 2015 10:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 lg-e7Y7Hc2uv for ; Thu, 18 Jun 2015 10:26:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B771B2A45 for ; Thu, 18 Jun 2015 10:26:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5IHQ5Ul003571; Thu, 18 Jun 2015 19:26:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 931DF204829; Thu, 18 Jun 2015 19:28:52 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 845AE20426A; Thu, 18 Jun 2015 19:28:52 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5IHQ1Dw000871; Thu, 18 Jun 2015 19:26:05 +0200 Message-ID: <5582FF29.1050902@gmail.com> Date: Thu, 18 Jun 2015 19:26:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= , Ross Chandler References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> <55828FB4.9000706@gmail.com> <53E80738-B5E7-4FF9-A37C-ADC545C52DC2@eircom.net> <2D29C51862222E49B991EF64EEB0B5B745FC06CE@OPE10MB05.tp.gk.corp.tepenet> In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745FC06CE@OPE10MB05.tp.gk.corp.tepenet> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 18 Jun 2015 17:26:14 -0000 Right, thanks for the pdf method. Le 18/06/2015 12:09, Czerwonka Michał 1 - Hurt a écrit : > https://developer.apple.com/videos/wwdc/2015/?id=719 and get PDF > > slide 26 > > What Works? > IPv4 address literals, in NAT64 + DNS64 networks > New for OS X 10.11 and iOS 9 > Use higher-layer networking frameworks > • NSURLSession and CFNetwork-layer APIs > Client supplies IPv4 address Literal > • OS synthesizes IPv6 address looks like a method to make IPv4 work in the hotspot of a smartphone connected to an IPv6-only APN. Maybe we have to wait to see IPv6 work in the hotspot of a smartphone connected to an IPv6-only APN. Akex > > BR, > Mcz > > > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ross Chandler > Sent: Thursday, June 18, 2015 12:04 PM > To: Alexandru Petrescu > Cc: IPv6 Ops WG > Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post > > >> On 18 Jun 2015, at 10:30, Alexandru Petrescu wrote: >> >> Then is it using 64share? CLAT? >> >> Alex > > I don’t see any mention of the 464xlat CLAT or 64share in their presentation. > > Single IPv6-only APN designs for handset and tethered IPv4 traffic don’t seem to be supported yet. > > Ross > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jun 18 11:30:16 2015 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 779821B3347 for ; Thu, 18 Jun 2015 11:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 fUECYOeN7kzF for ; Thu, 18 Jun 2015 11:30:13 -0700 (PDT) Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by ietfa.amsl.com (Postfix) with SMTP id B154D1B3345 for ; Thu, 18 Jun 2015 11:30:12 -0700 (PDT) Received: (qmail 65597 messnum 5312791 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 18 Jun 2015 18:30:10 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail09.svc.cra.dublin.eircom.net (qp 65597) with SMTP; 18 Jun 2015 18:30:10 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id huW71q0024BK5ly01uWAwN; Thu, 18 Jun 2015 19:30:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: <5582FF29.1050902@gmail.com> Date: Thu, 18 Jun 2015 19:30:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <049CE597-4CDD-4F8C-AE70-D09EF9B5A524@eircom.net> References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> <55828FB4.9000706@gmail.com> <53E80738-B5E7-4FF9-A37C-ADC545C52DC2@eircom.net> <2D29C51862222E49B991EF64EEB0B5B745FC06CE@OPE10MB05.tp.gk.corp.tepenet> <5582FF29.1050902@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 18 Jun 2015 18:30:15 -0000 > On 18 Jun 2015, at 18:26, Alexandru Petrescu = wrote: >=20 > Right, thanks for the pdf method. >=20 > Le 18/06/2015 12:09, Czerwonka Micha=C5=82 1 - Hurt a =C3=A9crit : >> https://developer.apple.com/videos/wwdc/2015/?id=3D719 and get PDF >>=20 >> slide 26 >>=20 >> What Works? >> IPv4 address literals, in NAT64 + DNS64 networks >> New for OS X 10.11 and iOS 9 >> Use higher-layer networking frameworks >> =E2=80=A2 NSURLSession and CFNetwork-layer APIs >> Client supplies IPv4 address Literal >> =E2=80=A2 OS synthesizes IPv6 address >=20 > looks like a method to make IPv4 work in the hotspot of a smartphone = connected to an IPv6-only APN. >=20 > Maybe we have to wait to see IPv6 work in the hotspot of a smartphone = connected to an IPv6-only APN. >=20 > Akex It would be nice if anyone can clarify if =E2=80=9CClient supplies IPv4 = address Literal - OS synthesizes IPv6 address=E2=80=9D is Apple=E2=80=99s = way of saying they=E2=80=99ve implemented 464xlat. Ross= From nobody Thu Jun 18 11:33:44 2015 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 F2D641B2C75 for ; Thu, 18 Jun 2015 11:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 W2K7IUCHh8dR for ; Thu, 18 Jun 2015 11:33:41 -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 E8B361B2C5E for ; Thu, 18 Jun 2015 11:33:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id ECE53A2; Thu, 18 Jun 2015 20:33:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1434652418; bh=FswYyXau7KSBDMApoin1BvY1PuDJTq4szK9JS5uy7s0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fEVRkO6rzvAf86IK+P8JNBUJv/ekqhy+ZCUfOAkOOZmul6oAjqvdX/zY52OihUeLX xCrAPZgJdnGjoTF7sW/Ug9NqTnfrCJ7PZWqoDP4dW/afxBZPJ1aT4txFqsWENhCkit fMi7WsQpxrCYlqvIsDleEO6EgFnVSC9JQf0wuY4E= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E111CA1; Thu, 18 Jun 2015 20:33:38 +0200 (CEST) Date: Thu, 18 Jun 2015 20:33:38 +0200 (CEST) From: Mikael Abrahamsson To: Ross Chandler In-Reply-To: <049CE597-4CDD-4F8C-AE70-D09EF9B5A524@eircom.net> Message-ID: References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> <55828FB4.9000706@gmail.com> <53E80738-B5E7-4FF9-A37C-ADC545C52DC2@eircom.net> <2D29C51862222E49B991EF64EEB0B5B745FC06CE@OPE10MB05.tp.gk.corp.tepenet> <5582FF29.1050902@gmail.com> <049CE597-4CDD-4F8C-AE70-D09EF9B5A524@eircom.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1584808915-1434652418=:9487" Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 18 Jun 2015 18:33:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1584808915-1434652418=:9487 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 18 Jun 2015, Ross Chandler wrote: > It would be nice if anyone can clarify if “Client supplies IPv4 address > Literal - OS synthesizes IPv6 address†is Apple’s way of saying they’ve > implemented 464xlat. My take on this is "no". I believe they've implemented the heuristics of discovering the NAT64 prefix and do the "bump-in-the-API" approach to supporting IPv4 literals for their high-level APIs. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1584808915-1434652418=:9487-- From nobody Thu Jun 18 11:38:34 2015 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 D7A7A1B334B for ; Thu, 18 Jun 2015 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uWfGqse9Z_wp for ; Thu, 18 Jun 2015 11:38:32 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by ietfa.amsl.com (Postfix) with ESMTP id 362F81B3349 for ; Thu, 18 Jun 2015 11:38:32 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by elvis.mu.org (Postfix) with ESMTPSA id F3C4D341F925 for ; Thu, 18 Jun 2015 11:38:30 -0700 (PDT) Received: by igbiq7 with SMTP id iq7so1594588igb.1 for ; Thu, 18 Jun 2015 11:38:30 -0700 (PDT) X-Received: by 10.107.133.38 with SMTP id h38mr16754592iod.47.1434652710486; Thu, 18 Jun 2015 11:38:30 -0700 (PDT) MIME-Version: 1.0 References: <3A1298E7-8422-4C03-8DDD-FF728C22165B@cisco.com> <5581B014.8070601@gmail.com> <55828FB4.9000706@gmail.com> <53E80738-B5E7-4FF9-A37C-ADC545C52DC2@eircom.net> <2D29C51862222E49B991EF64EEB0B5B745FC06CE@OPE10MB05.tp.gk.corp.tepenet> <5582FF29.1050902@gmail.com> <049CE597-4CDD-4F8C-AE70-D09EF9B5A524@eircom.net> In-Reply-To: From: Paul Saab Date: Thu, 18 Jun 2015 18:38:20 +0000 Message-ID: To: Mikael Abrahamsson , Ross Chandler Content-Type: multipart/alternative; boundary=001a113ff67c2f4c2d0518cf1dd7 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 & iOS9 - interesting factoids in this Ars Technica post 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, 18 Jun 2015 18:38:33 -0000 --001a113ff67c2f4c2d0518cf1dd7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 18, 2015 at 11:33 AM Mikael Abrahamsson wrote: > On Thu, 18 Jun 2015, Ross Chandler wrote: > > > It would be nice if anyone can clarify if =E2=80=9CClient supplies IPv4= address > > Literal - OS synthesizes IPv6 address=E2=80=9D is Apple=E2=80=99s way o= f saying they=E2=80=99ve > > implemented 464xlat. > > My take on this is "no". I believe they've implemented the heuristics of > discovering the NAT64 prefix and do the "bump-in-the-API" approach to > supporting IPv4 literals for their high-level APIs. > It is a "bump-in-the-API" approach, not 464xlat --001a113ff67c2f4c2d0518cf1dd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 18, 2015 at 11:33 AM Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Thu, 18 Jun 2015, Ro= ss Chandler wrote:

> It would be nice if anyone can clarify if =E2=80=9CClient supplies IPv= 4 address
> Literal - OS synthesizes IPv6 address=E2=80=9D is Apple=E2=80=99s way = of saying they=E2=80=99ve
> implemented 464xlat.

My take on this is "no". I believe they've implemented the he= uristics of
discovering the NAT64 prefix and do the "bump-in-the-API" approac= h to
supporting IPv4 literals for their high-level APIs.
It is a "bump-in-the-API" approach, not 464xlat=C2= =A0
--001a113ff67c2f4c2d0518cf1dd7-- From nobody Thu Jun 18 15:01:20 2015 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 CFBB11A8881 for ; Thu, 18 Jun 2015 15:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 emBNcTDxAysQ for ; Thu, 18 Jun 2015 15:01:18 -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 DDA5B1A8830 for ; Thu, 18 Jun 2015 15:01:16 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C483D60A12 for ; Fri, 19 Jun 2015 00:01:14 +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 050726084C for ; Fri, 19 Jun 2015 00:00:58 +0200 (CEST) Received: (qmail 84726 invoked by uid 1007); 19 Jun 2015 00:00:58 +0200 Date: Fri, 19 Jun 2015 00:00:58 +0200 From: Gert Doering To: "Fred Baker \(fred\)" Message-ID: <20150618220058.GP67883@Space.Net> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R8CP7fzfAHpwDIZp" Content-Disposition: inline In-Reply-To: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 18 Jun 2015 22:01:20 -0000 --R8CP7fzfAHpwDIZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 17, 2015 at 04:46:03PM +0000, Fred Baker (fred) wrote: > Tell me this. Would you be happier if the fragmentation rule said that th= e first fragment had to contain the entire IPv6 header, plus the transport = layer header (for ACL support)? I think Fernando would support such a state= ment (I think I have "heard" him make such a statement). It would certainly make *me* happier... 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 --R8CP7fzfAHpwDIZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVYM/mt9WwGXkzn/FAQJlqg/9GENPhBgvHoOMEylacSimvqTntV2+Fels 35YMqtRUD8pDY5f2qS0D18IRpsNRdg7uOzsg/S9sH9u3ttpyWRswzFdF2BoRNGxb /r/8XVGDNThfJR0bCU8+MHTuys16O218vsSA8RGxoQOgJVHyUWwFXM0igte+cQg8 iiw03sx+1aBGNKm2MvJ2ulPWMZanH9qi4Qq2u7z7UoONjTk1pggx0nGWNDz7F6gF Zw/ihN6gCS61pRsuvNaL7Ev7lSiKq+4GZecNrz4cPT6RvNCZWOz/PD/ECnEHLRu8 fQ7yOhAQg47e1MEBbIRpDoFE5aOYT7Xi9iyS1QO8zV8wcRBEhBDFpCp27zrKN4zU X/UawNvwK44OUZiopp7YZoPTJxbpCN93cx5dGFkd/DNNcegm7TsxCzn4A/nz6LPJ 7T8j5toOMdD5mzD2r82lJJ4n5FJ+QE+R6QG1mT88tqhsVAXUkya/BLE/dRacUdBH Rp/pDl/8vPzeFFK5cfa+Zlnvmm9aW3F7c8gBnapVOfIz95b4kiQOUD5FY1EzRDVl mFs3yfOqXxzglae0z9BG2ETWuAIZFv71m+330BlDBc9RUMSnGWj0RuBbleplP6WB 8+ge63R/iObCWgSYhNdaq2mn3+IWTZz5S5JHJzj4g38kx2toCJrfEefEC8y4zO60 Pj1f54Y/x6Y= =CIoM -----END PGP SIGNATURE----- --R8CP7fzfAHpwDIZp-- From nobody Thu Jun 18 15:32:46 2015 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 1B4EA1A1AAD for ; Thu, 18 Jun 2015 15:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 pWiyu6N18sDa for ; Thu, 18 Jun 2015 15:32:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4631A00FD for ; Thu, 18 Jun 2015 15:32:44 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t5IMWJ2s011713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Jun 2015 15:32:22 -0700 (PDT) To: Gert Doering , "Fred Baker (fred)" References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> From: Joe Touch Message-ID: <558346F3.3050509@isi.edu> Date: Thu, 18 Jun 2015 15:32:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150618220058.GP67883@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: t5IMWJ2s011713 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 18 Jun 2015 22:32:45 -0000 On 6/18/2015 3:00 PM, Gert Doering wrote: > Hi, > > On Wed, Jun 17, 2015 at 04:46:03PM +0000, Fred Baker (fred) wrote: >> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement). It makes sense to require all of the HBH and routing headers in the first fragment. The rest is impossible to mandate and irrelevant. Anything that looks far enough into a packet to need to find the transport header might be looking several layers of encapsulation in; that's acting as an endpoint, and ought to reassemble the packet at that point. Joe From nobody Fri Jun 19 00:11:00 2015 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 640451A6FF7 for ; Fri, 19 Jun 2015 00:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zKT5_NOUrkr6 for ; Fri, 19 Jun 2015 00:10:57 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8ED1A6FEC for ; Fri, 19 Jun 2015 00:10:57 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id DA8F06312; Fri, 19 Jun 2015 00:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=LonU6z2PWShRvfckFHnOBIw5SfE=; b= IjwgiVXn28Fb6D4f6a8NRRmyV/ShoSfhHvhZJJghbPebNcI+ltQ+NMLyaQxpsKHN Q5xQ87X83ScvoBn4ab7nLVbERaviTbt9EZCTwDEMgqb69aUW7gIWnP0XexFFzZbi QsH0LAnfwWjH95kzkE/mZQQ+1zZWB5irW+m/0gdfxoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=aeSNngaDQfTp7Lm3zVDp1fEIG3 /Y8q4yjTBV5IFBSqbpKlPMDREnhZOIDYA7y1QzoZ3tDaRuhxBn4SPd4fa92dJ7se zqfminZssfrbTYv9IKcgMcU+li/2JPCnN/uoRDEnwSW8CRm8hS8Shs0W6EX/az1P nGRYEPi1WvgXknr2s= Received: from gomlefisk.localdomain (unknown [173.38.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 97A676310; Fri, 19 Jun 2015 00:10:55 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 07C2D4784459; Fri, 19 Jun 2015 09:10:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0102038C-2312-45F0-8103-C7112A646CA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Ole Troan In-Reply-To: <20150618220058.GP67883@Space.Net> Date: Fri, 19 Jun 2015 09:10:55 +0200 Message-Id: References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 19 Jun 2015 07:10:59 -0000 --Apple-Mail=_0102038C-2312-45F0-8103-C7112A646CA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> Tell me this. Would you be happier if the fragmentation rule said = that the first fragment had to contain the entire IPv6 header, plus the = transport layer header (for ACL support)? I think Fernando would support = such a statement (I think I have "heard" him make such a statement). >=20 > It would certainly make *me* happier=E2=80=A6 done. RFC7112. cheers, Ole --Apple-Mail=_0102038C-2312-45F0-8103-C7112A646CA3 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 - https://gpgtools.org iQIcBAEBCgAGBQJVg8B/AAoJEL7aWKiYQt922ywQAJOZYjwfI08Fo6wgCPRulRdm amkE4OK6a/7gy80O33ug5PZU7/ydTWW1pSXXHPrP//sek4io65eSddD9a990E8Zt KgMmYuwbuRj59MOqeH4vTG8G1+x+X2dH5O+5mRCFAE2itgc5STTkXmEqTwIa0R0p Z/U2blBLMF3Nl9NFw4PHcVYE7z736y5LuajbzifUlwIYweqcCwihfvzO3ogjG39V Uuu3pAVTqHRICUXCrs46sn+MID1sLSV5ICaAUzn3XlJrRbH2YDOj8xpx1g5rzjA3 4FyrN5CKlMAIUc+kgXXq0JnVAkVehyoC2RDufKPeNISdZG4ipF4qSAFiP8ImZ8fg d13zO5ATBkMQs8Y6NZj0UZD5xTIPivxgbFFrPaIkaZ2cQf1BkmtahsenAf3B2Nvc 1cg0Q+2ZUwkiZ9/9368ukOkcu1xwYUpy+wdAjhJsyIYlxNzhDBpxYTmgmITMue0U CbzalwQsaYWeFBRsSpb1mvXcNxpSiDGsN5SPnrJlP3XqP2Jtedoj6DxIVRopyLgP wgTMeWC268kYGYu9QykvYE8TA96fhMSXS7zPnocQUljUl9b23maWIqKAP5K1WKFf 7wY0ZiwZooVUUYF/zb+N6jqRsJ6m1kwRcwUChXGS2P0PKUk4exQ9L8CGzGfrJyP2 JC2y1lazn8Zd/McvD3/A =Reck -----END PGP SIGNATURE----- --Apple-Mail=_0102038C-2312-45F0-8103-C7112A646CA3-- From nobody Fri Jun 19 00:39:17 2015 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 C6D0B1A00EC for ; Fri, 19 Jun 2015 00:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OjMzR3p6CKc5 for ; Fri, 19 Jun 2015 00:39:13 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 54FE71A00E9 for ; Fri, 19 Jun 2015 00:39:12 -0700 (PDT) Received: (qmail 36071 invoked from network); 19 Jun 2015 07:39:11 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 19 Jun 2015 07:39:11 -0000 Date: Fri, 19 Jun 2015 09:39:11 +0200 (CEST) Message-Id: <20150619.093911.74722344.sthaug@nethelp.no> To: otroan@employees.org From: sthaug@nethelp.no In-Reply-To: References: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 19 Jun 2015 07:39:15 -0000 > >> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement). > > > > It would certainly make *me* happier$,1s&(B > > done. > RFC7112. As I wrote in another mail, > It may be relevant to ask for RFC 7112 support next time we're doing > an equipment RFQ (in a few years). ... > But until RFC 7112 support is available, I believe we will > see a significant amount of breakage for IPv6 extension headers - and > header chains will be limited to significantly less than 1280 bytes. And until such support is available, we have to deal with the current mess. Which may imply more filtering than some people would like. Steinar Haug, AS 2116 From nobody Fri Jun 19 00:56:26 2015 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 ACDB21A854D for ; Fri, 19 Jun 2015 00:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Hi92-PGMaJJI for ; Fri, 19 Jun 2015 00:56:22 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB301A86E0 for ; Fri, 19 Jun 2015 00:56:22 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 0A1406310; Fri, 19 Jun 2015 00:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=TY7ihp0bxUtspBgVzND4NtIU9WE=; b= VnBIrjVGdOOcS9tk03wcgJakhkYKlOM+dj7GXLmRZAabPAqlP1MxUODgcz3B9LyT Qxnyx1y8rXqCCUGuuarHPYAlAhTW9K8xNobfRxUeNJU2jCUIZczFDhW+I19QHghs VKHu50jY/W44A395WsBVFmv13raG2s4t+aHcFvycBBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=A6wOODeT3jDFaYHoXa96FWI1ID nv5hxAXgJtpo1ZxYFIZ7rQOIq8hNl9NkTBkUZD9fLkqDqb218bZP0sX5G8eTdG6R TI0w3KT2END7cPC3vvOKtxwFSjE695G5uX9QwVdc9yjTk+AvfRgJBq0bzLmDFjP4 mEw6EgEZz7pA+zxrI= Received: from gomlefisk.localdomain (unknown [173.38.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id BA1156240; Fri, 19 Jun 2015 00:56:20 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 2D7DF4784CA4; Fri, 19 Jun 2015 09:56:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_91E84A0C-FC13-4282-AE3D-2BFE9ED97AC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Ole Troan In-Reply-To: <20150619.093911.74722344.sthaug@nethelp.no> Date: Fri, 19 Jun 2015 09:56:20 +0200 Message-Id: <4B24F577-E5F1-4E44-95BA-AEFD502C6BC2@employees.org> References: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> <20150619.093911.74722344.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.2102) Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 19 Jun 2015 07:56:23 -0000 --Apple-Mail=_91E84A0C-FC13-4282-AE3D-2BFE9ED97AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>>> Tell me this. Would you be happier if the fragmentation rule said = that the first fragment had to contain the entire IPv6 header, plus the = transport layer header (for ACL support)? I think Fernando would support = such a statement (I think I have "heard" him make such a statement). >>>=20 >>> It would certainly make *me* happier=EF=BF=BD$,1s& >>=20 >> done. >> RFC7112. >=20 > As I wrote in another mail, >=20 >> It may be relevant to ask for RFC 7112 support next time we're doing >> an equipment RFQ (in a few years). > ... >> But until RFC 7112 support is available, I believe we will >> see a significant amount of breakage for IPv6 extension headers - and >> header chains will be limited to significantly less than 1280 bytes. >=20 > And until such support is available, we have to deal with the current > mess. Which may imply more filtering than some people would like. I don=E2=80=99t think that follows. cheers, Ole --Apple-Mail=_91E84A0C-FC13-4282-AE3D-2BFE9ED97AC1 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 - https://gpgtools.org iQIcBAEBCgAGBQJVg8skAAoJEL7aWKiYQt92FhkP+QGR7aDN7uHC3ij1+EW//5T6 BIrmL6FZryt/bBAgVkyX2f1PhSv5Jo2q+bzQl/doc9EwCj/pT5gWSsnAmAl5Q63B EKyZn2V+43YEZXuh7zmmJ9KAMVkppOkziUM7LbOQKNDu+H3tphhpyEnLa0qpwy5n e0sRtOpg9Tr9U92aJcmrSti8i55APl65J0HcGAaQV28AtsBBIfhM+CxYEHRawoOo zJjgMZPnav5Vh9j96cCVMkW7JQ7MnzV3XHvFd+IYC4DQPNEQsr8wYv2YRPG7anPf eFCG0dj9ESUfkwH3a21/SoxbHCUucOc3Xu1zQ2uqTCsz/uJ5ztddVgx5ja9O6pKd /SlyGGTpZq4lrV/+H7B2pobdw9Wv+5CnfpwngHRlmC8ys59lpGgxJjmI3mGj9sME stsQYwhEyq1tPU6cjI/6fGIVVY8Cfzrksk9Vq+2DA89QJVoW96L6BtqccA8HXi72 ZAdhwqYWIau7lTckCS93mF5Mldwq3pzBLw5tdlLUca4APDPsW2HpYxNas9Sq99Ca zqeIwkKSaOSlC3O/6MG+1rldmDc6jXc7IgH9WRwkoaPVYKZjvbtI6vSmlMOBWNIF uaZgZYVs8rNGEAhSri4QiSaaG59Ne6rk4ZRRzzzH+qwDMmIVvZztTGswbcBKkHGn QfOCuUmyAain2ryb4QtL =IwcL -----END PGP SIGNATURE----- --Apple-Mail=_91E84A0C-FC13-4282-AE3D-2BFE9ED97AC1-- From nobody Fri Jun 19 01:34:18 2015 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 0EA1F1A8742 for ; Fri, 19 Jun 2015 01:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKKUdw7Wr797 for ; Fri, 19 Jun 2015 01:34:15 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 E200D1A700F for ; Fri, 19 Jun 2015 01:34:14 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 8DA3B74F0E; Fri, 19 Jun 2015 10:34:10 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 4B922B49; Fri, 19 Jun 2015 10:34:10 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 26AF8C4936; Fri, 19 Jun 2015 10:34:10 +0200 (CEST) Date: Fri, 19 Jun 2015 10:34:10 +0200 From: Enno Rey To: Ole Troan Message-ID: <20150619083410.GC39902@ernw.de> References: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> <20150619.093911.74722344.sthaug@nethelp.no> <4B24F577-E5F1-4E44-95BA-AEFD502C6BC2@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B24F577-E5F1-4E44-95BA-AEFD502C6BC2@employees.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: v6ops@ietf.org, ipv6-wg@ripe.net Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 19 Jun 2015 08:34:17 -0000 Hi, On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote: > >>>> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement). > >>> > >>> It would certainly make *me* happier???$,1s& > >> > >> done. > >> RFC7112. > > > > As I wrote in another mail, > > > >> It may be relevant to ask for RFC 7112 support next time we're doing > >> an equipment RFQ (in a few years). > > ... > >> But until RFC 7112 support is available, I believe we will > >> see a significant amount of breakage for IPv6 extension headers - and > >> header chains will be limited to significantly less than 1280 bytes. > > > > And until such support is available, we have to deal with the current > > mess. Which may imply more filtering than some people would like. > > I don???t think that follows. I would second the observation that this (subsequent action) actually happens. Not least because many consider it a reasonable approach not to process and/or to drop something that induces complexity & insecurity and which at the same time is not needed by any service or application (read: all EHs except ESP and, maybe in some corner cases, AH+FH). thanks Enno > > cheers, > Ole -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Fri Jun 19 02:14:15 2015 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 3019A1A701E for ; Fri, 19 Jun 2015 02:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 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, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 f4V6LHJcLRzi for ; Fri, 19 Jun 2015 02:14:12 -0700 (PDT) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AAA1A87C0 for ; Fri, 19 Jun 2015 02:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1434705251; bh=py+zj0O9zHALc31DQFvEKGsqYCSFdARNmBCkcVyKy8k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=fL5P8Uk9uv+UoU7dMnd+JW4QwgCyiN4jsnGjMRcYfqDttDg0OHQV0M+aWWSas6EoUH0e7gQqDkTw7gl2AEiEKP56Aa9edZVjMB9GVrhdISrIPsv+7aSVLuwJY9I0He932hCNtbzOtwbncTRrYDQibHnecU30aaWDmBS1/p+s938TB+HJDDJBPPq9ryaDu7OBBqQUa8ag08hpHiKSFUx67/EPpR84LNK9q6OsZX+PblooNV1qntqsyxkQpxSoK+qLFOaJCMeHCUSV4v+eeGUMCIsz8Bc8dQpqfPzcgL0NHYjcLIzhVeQXzfpWnjUoZ54goP2xx1A35DamxNaGr72NKA== Received: from [98.139.214.32] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2015 09:14:11 -0000 Received: from [98.139.212.208] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2015 09:14:11 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 19 Jun 2015 09:14:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 229985.69187.bm@omp1017.mail.bf1.yahoo.com X-YMail-OSG: Xxs3ZUkVM1nbejBMVd6BGCEBZ0kH1oKdDrL0LAPcrLeTqrXEaSTe.2LUqk_feiO rpvGleKJeAYSDDgElnay_UiS7hsfuOFpGDUQerOuX_97pmiMpRY5WskOGOb0KUT7sfQXBXDXM_VJ wsGvCs2KqhYEbuR9FPvl2LSyhd1nwCKVjSOGP0_SSTFQkHf3CAx_O9Y3aqd1UMwoDgPJnieLRnO2 JrkDtICER4LImfxmQXfDlz7Q0dWEMSePIvega29sgYBb6AXmO69_OevfDiv_nvnOFzanCXNWHHtF 8H7aeJlQFJMwqkkl9ETOCT1l2hJSJatM8xMkHTXp0_7byPvrFNr5nPgLlq28vCAIZaz6oPylqbWq 7Z8o1gdDzxmEsaYnWOPCtrG3rx_9fN9vx34oJDjaZuWQhr5AHOesqWx1nG9V4G1SImqF9qmhzVq. USYSt3qMHE6Y9jFUrP7uFL3LVU2sYdpOyL8Bcw07vvXltqDpyfF.j0FlLZlV5RU1MQPgjkiamqq5 vEetUAU9LegyMb23svZQ- Received: by 66.196.81.104; Fri, 19 Jun 2015 09:14:10 +0000 Date: Fri, 19 Jun 2015 09:13:52 +0000 (UTC) From: Mark ZZZ Smith To: Enno Rey , Ole Troan Message-ID: <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150619083410.GC39902@ernw.de> References: <20150619083410.GC39902@ernw.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2069878_1986296535.1434705232338" Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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: Fri, 19 Jun 2015 09:14:14 -0000 ------=_Part_2069878_1986296535.1434705232338 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit From: Enno Rey To: Ole Troan Cc: v6ops@ietf.org; ipv6-wg@ripe.net Sent: Friday, 19 June 2015, 18:34 Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices Hi, On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote: > >>>> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement). > >>> > >>> It would certainly make *me* happier???$,1s& > >> > >> done. > >> RFC7112. > > > > As I wrote in another mail, > > > >> It may be relevant to ask for RFC 7112 support next time we're doing > >> an equipment RFQ (in a few years). > > ... > >> But until RFC 7112 support is available, I believe we will > >> see a significant amount of breakage for IPv6 extension headers - and > >> header chains will be limited to significantly less than 1280 bytes. > > > > And until such support is available, we have to deal with the current > > mess. Which may imply more filtering than some people would like. > > I don???t think that follows. I would second the observation that this (subsequent action) actually happens. Not least because many consider it a reasonable approach not to process and/or to drop something that induces complexity & insecurity and which at the same time is not needed by any service or application (read: all EHs except ESP and, maybe in some corner cases, AH+FH). / I think you're only expressing the view of many security engineers, not the many network engineers or the many more users of networks. At an ISP, if you block traffic your customer wants send, all you get is angry customers. They're paying you to deliver any and all of their packets as well as possible, with as minimum restrictions as possible, ideally none, rather than the opposite. This is why I don't think you'll ever get consensus on deprecating EHs, because I think you're only coming the position of trying to solve problem (3) I described in my last email. / I'd also observe that deprecating EHs, other than ESP, AH+FH, TCP and UDP, would also prevent them from being used behind the ESP EH - where you won't be able to see what is in them, so you won't be able to care what is in them. You'll also be preventing people from other transport layer protocols, such as SCTP and DCCP, that are feasible to deploy over the IPv6 Internet that couldn't be over the IPv4 network because of IPv4 NAT and other middle boxes. thanks Enno > > cheers, > Ole -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_2069878_1986296535.1434705232338 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From: Enno Rey <erey@ernw.de>
To: Ole Troan <otroan@employees.org&= gt;
Cc: v6ops@ietf.org= ; ipv6-wg@ripe.net
Sent:<= /b> Friday, 19 June 2015, 18:34
S= ubject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Secu= rity Devices

Hi,

On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote:
> >>>> Tell me this. Would you be happier if the= fragmentation rule said that the first fragment had to contain the entire = IPv6 header, plus the transport layer header (for ACL support)? I think Fer= nando would support such a statement (I think I have "heard" him make such = a statement).
> >>>
> &= gt;>> It would certainly make *me* happier???$,1s&
> >>
> >> done.
= > >> RFC7112.
> >
> = > As I wrote in another mail,
> >
> >> It may be relevant to ask for RFC 7112 support next time= we're doing
> >> an equipment RFQ (in a few yea= rs).
> > ...
> >> But un= til RFC 7112 support is available, I believe we will
>= >> see a significant amount of breakage for IPv6 extension headers -= and
> >> header chains will be limited to signi= ficantly less than 1280 bytes.
> >
> > And until such support is available, we have to deal with the = current
> > mess. Which may imply more filtering th= an some people would like.
>
> I= don???t think that follows.

I would s= econd the observation that this (subsequent action) actually happens.
Not least because many consider it a reasonable approach not t= o process and/or to drop something that induces complexity & insecurity= and which at the same time is not needed by any service or application (re= ad: all EHs except ESP and, maybe in some corner cases, AH+FH).

/ I think you're only expressing the view of many = security engineers, not the many network engineers or the many more users o= f networks. At an ISP, if you block traffic your customer wants send, all y= ou get is angry customers. They're paying you to deliver any and all of the= ir packets as well as possible, with as minimum restrictions as possible, i= deally none, rather than the opposite. This is why I don't think you'll eve= r get consensus on deprecating EHs, because I think you're only coming the = position of trying to solve problem (3) I described in my last email.
=

/ I'd also observe that deprecating EHs, other than ESP, AH+FH= , TCP and UDP, would also prevent them from being used behind the ESP EH - = where you won't be able to see what is in them, so you won't be able to car= e what is in them. You'll also be preventing people from other transport la= yer protocols, such as SCTP and DCCP, that are feasible to deploy over the = IPv6 Internet that couldn't be over the IPv4 network because of IPv4 NAT an= d other middle boxes.

thanks

Enno




>
>= ; cheers,
> Ole

<= br clear=3D"none">
--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelb= erg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 = - Cell +49 173 6745902

Handelsregiste= r Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=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=3D=3D=3D=3D=3D=3D=3D=3D
Blog: ww= w.insinuator.net || Conference: www.troopers.de
Twitter: = @Enno_Insinuator



=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=3D=3D=3D=3D=3D=3D=3D=3D

______________________________________________= _
v6ops mailing list
v6ops@ietf= .org
https://www.ietf.org/mailman/listi= nfo/v6ops


<= /body> ------=_Part_2069878_1986296535.1434705232338-- From nobody Fri Jun 19 13:18:32 2015 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 7D7181A1A07 for ; Fri, 19 Jun 2015 13:18:31 -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_22=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 ZZFBSPVt1rLX for ; Fri, 19 Jun 2015 13:18:30 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266711B29B9 for ; Fri, 19 Jun 2015 13:15:03 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so97396889pdb.1 for ; Fri, 19 Jun 2015 13:15:02 -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=HuLybM1ITB6TiZsKzYQzG0XIsO/BlJdnOoW4Kd+T+Ig=; b=mlC7DwlA8YipsWZij0SnaUnsNsDFfzYEVQ6OVdK6QSTfxc7R8gyvK9nEWzTM1Oo6dB jqF2XM74vBRFVlv4jdGtGIvKKJMibgyWguv3Ae7yITqim4EdzKzDQhMkm5jULPRHeNLF SN+aYteYWpnKEaNE2d5HTpFC1uu4hJXllfLgiRznV73n8/2N82pELazp0P8uKD9Caj4G PS/27YBpdu3X4DopSFvWmQkpefMCYi9T9ZXIqHR2FOnmE2RAKR2tKw2+0Ue7yxkM7CZd QnLsuZ7DHdx25sTfT5fEL6TwfRLe/m4P+X89gshvRTb2fkWcLDQATlE8AwN+27qfUS94 RHqg== X-Received: by 10.67.5.231 with SMTP id cp7mr35378171pad.36.1434744902724; Fri, 19 Jun 2015 13:15:02 -0700 (PDT) Received: from ?IPv6:2406:e007:618e:1:28cc:dc4c:9703:6781? ([2406:e007:618e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id mi1sm12088755pdb.17.2015.06.19.13.14.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 13:15:01 -0700 (PDT) Message-ID: <5584784C.1080606@gmail.com> Date: Sat, 20 Jun 2015 08:15:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Enno Rey , Ole Troan References: <20150619083410.GC39902@ernw.de> <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 19 Jun 2015 20:18:31 -0000 On 19/06/2015 21:13, Mark ZZZ Smith wrote: > > From: Enno Rey > To: Ole Troan > Cc: v6ops@ietf.org; ipv6-wg@ripe.net > Sent: Friday, 19 June 2015, 18:34 > Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices > > Hi, > > On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote: >>>>>> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement). >>>>> >>>>> It would certainly make *me* happier???$,1s& >>>> >>>> done. >>>> RFC7112. >>> >>> As I wrote in another mail, >>> >>>> It may be relevant to ask for RFC 7112 support next time we're doing >>>> an equipment RFQ (in a few years). >>> ... >>>> But until RFC 7112 support is available, I believe we will >>>> see a significant amount of breakage for IPv6 extension headers - and >>>> header chains will be limited to significantly less than 1280 bytes. >>> >>> And until such support is available, we have to deal with the current >>> mess. Which may imply more filtering than some people would like. >> >> I don???t think that follows. > > I would second the observation that this (subsequent action) actually happens. > Not least because many consider it a reasonable approach not to process and/or to drop something that induces complexity & insecurity and which at the same time is not needed by any service or application (read: all EHs except ESP and, maybe in some corner cases, AH+FH). > > / I think you're only expressing the view of many security engineers, not the many network engineers or the many more users of networks. At an ISP, if you block traffic your customer wants send, all you get is angry customers. They're paying you to deliver any and all of their packets as well as possible, with as minimum restrictions as possible, ideally none, rather than the opposite. This is why I don't think you'll ever get consensus on deprecating EHs, because I think you're only coming the position of trying to solve problem (3) I described in my last email. I don't think that's what he was saying. I think he was saying "enforce RFC 7112." Discarding packets whose headers exceed the first fragment strikes me as very reasonable, even before host stacks are updated to enforce RFC 7112 at the source. What isn't reasonable is to say "laugh at RFC 7045". Anybody who purports to sell IPv6 firewalls needs to support RFC 7045 in their next release. The next order of business in the IETF (6man, not here) is to decide whether we go further in fixing the standard, which I think you and Fred are both advocating. Brian > / I'd also observe that deprecating EHs, other than ESP, AH+FH, TCP and UDP, would also prevent them from being used behind the ESP EH - where you won't be able to see what is in them, so you won't be able to care what is in them. You'll also be preventing people from other transport layer protocols, such as SCTP and DCCP, that are feasible to deploy over the IPv6 Internet that couldn't be over the IPv4 network because of IPv4 NAT and other middle boxes. > thanks > > Enno > > > > >> >> cheers, >> Ole > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jun 19 13:19:48 2015 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 7AAF01A1A07 for ; Fri, 19 Jun 2015 13:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 S-EH82Y2e3Bl for ; Fri, 19 Jun 2015 13:19:46 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C091A1ABF for ; Fri, 19 Jun 2015 13:19:27 -0700 (PDT) Received: by oigb199 with SMTP id b199so46125758oig.3 for ; Fri, 19 Jun 2015 13:19:27 -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=o8Stjkg0VVTrcYJf+h39vdUGyB1L3vx2XWw5adTZiW4=; b=KDwmNYE4UR5UKQeQXKfMCPAjO7uWw3l1GId7Wi99OcSUBiKqKL5iZUCflj462+Kfiw qIw9QlnrS9vFuyddG2aE2EycqwCuyvAR5A3ghyQYUpo4TEUKe7yxfGVqHmKClgxfhxoH bWgQmoKqDtpIeD7c9Ob7Cj0FIVldUS/g7+b3IxUKfAOufnMEs74KY/QMS7gcj5EH6CpS 78jfFhY3DGGwrVkcRWDgwX6E/W3SrWD27HoHC8YcYjItffpofec3yl6inWQ9x+RI2nNq b/q22/XhWEgFzXNicjp2VnPvCsf9pMpF4ZFqKkAVOubXzsKUcnQu+4mtsnxcucgTZzux DdgA== X-Gm-Message-State: ALoCoQm6d2c5Uj4jPl7X5tNOYBAG8XvTuX132/mZ3e/29j2hNXqSrTe1CWKwAKVdv681xXWkocv6 MIME-Version: 1.0 X-Received: by 10.182.186.106 with SMTP id fj10mr14768062obc.54.1434745167151; Fri, 19 Jun 2015 13:19:27 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Fri, 19 Jun 2015 13:19:26 -0700 (PDT) In-Reply-To: <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com> References: <20150619083410.GC39902@ernw.de> <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 19 Jun 2015 16:19:26 -0400 Message-ID: From: Warren Kumari To: Mark ZZZ Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 19 Jun 2015 20:19:47 -0000 On Fri, Jun 19, 2015 at 5:13 AM, Mark ZZZ Smith wrote: > > ________________________________ > From: Enno Rey > To: Ole Troan > Cc: v6ops@ietf.org; ipv6-wg@ripe.net > Sent: Friday, 19 June 2015, 18:34 > Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security > Devices > > Hi, > > On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote: >> >>>> Tell me this. Would you be happier if the fragmentation rule said >> >>>> that the first fragment had to contain the entire IPv6 header, plus the >> >>>> transport layer header (for ACL support)? I think Fernando would support >> >>>> such a statement (I think I have "heard" him make such a statement). >> >>> >> >>> It would certainly make *me* happier???$,1s& >> >> >> >> done. >> >> RFC7112. >> > >> > As I wrote in another mail, >> > >> >> It may be relevant to ask for RFC 7112 support next time we're doing >> >> an equipment RFQ (in a few years). >> > ... >> >> But until RFC 7112 support is available, I believe we will >> >> see a significant amount of breakage for IPv6 extension headers - and >> >> header chains will be limited to significantly less than 1280 bytes. >> > >> > And until such support is available, we have to deal with the current >> > mess. Which may imply more filtering than some people would like. >> >> I don???t think that follows. > > I would second the observation that this (subsequent action) actually > happens. > Not least because many consider it a reasonable approach not to process > and/or to drop something that induces complexity & insecurity and which at > the same time is not needed by any service or application (read: all EHs > except ESP and, maybe in some corner cases, AH+FH). > > / I think you're only expressing the view of many security engineers, not > the many network engineers or the many more users of networks. At an ISP, if > you block traffic your customer wants send, all you get is angry customers. ... and at an ISP if your customer calls you up because they are being DDoSed out of existence with traffic at some port that they don't use, and you tell them at that you cannot filter UDP port 80 because, well, you cannot find it, you also end up with an angry customer. > They're paying you to deliver any and all of their packets as well as > possible, with as minimum restrictions as possible, ideally none, rather > than the opposite. Perhaps. I figure they are /actually/ paying you to provide them with good service. Sometimes that includes filtering for them, because you have bigger pipes than them... W > This is why I don't think you'll ever get consensus on > deprecating EHs, because I think you're only coming the position of trying > to solve problem (3) I described in my last email. > > / I'd also observe that deprecating EHs, other than ESP, AH+FH, TCP and UDP, > would also prevent them from being used behind the ESP EH - where you won't > be able to see what is in them, so you won't be able to care what is in > them. You'll also be preventing people from other transport layer protocols, > such as SCTP and DCCP, that are feasible to deploy over the IPv6 Internet > that couldn't be over the IPv4 network because of IPv4 NAT and other middle > boxes. > > thanks > > Enno > > > > >> >> cheers, >> Ole > > > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: || Conference: www.troopers.de > Twitter: @Enno_Insinuator > > > > ======================================================= > > _______________________________________________ > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Jun 19 14:36:17 2015 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 915631B2AF3 for ; Fri, 19 Jun 2015 14:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 uHAG4icDYlvm for ; Fri, 19 Jun 2015 14:36:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617031B2AF0 for ; Fri, 19 Jun 2015 14:36:14 -0700 (PDT) Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 19 Jun 2015 21:36:13 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0190.013; Fri, 19 Jun 2015 21:36:13 +0000 From: Ronald Bonica To: Enno Rey , Jen Linkova Thread-Topic: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices Thread-Index: AQHQqNEIg5ZU+gtmFE6PqXTscgbWoJ2wd4uAgAAh0YCAABZRgIAAAYEAgAABkwCAAAIcgIAABXMAgAOjZMA= Date: Fri, 19 Jun 2015 21:36:12 +0000 Message-ID: References: <20150617.140235.74748217.sthaug@nethelp.no> <20150617.152750.41635871.sthaug@nethelp.no> <20150617133328.GB16716@ernw.de> <20150617140032.GB16806@ernw.de> In-Reply-To: <20150617140032.GB16806@ernw.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ernw.de; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1985; 3:kngoAwaMVQEHtPiK59bvz6jWEhLrJhZtJk8wvfH62NFr4bBvoZAP3aUt/3+DIUOzkPOt2BJAPAzWI3MXi86mXUWAfz/kXqI2CB0BDAAdIM1Z/wNBGkt3emUYeq+XZ6VRTzi7QkkWMfu9LO0P3cjw3A==; 10:gVtPmCNnk5WgD1tDCAZrgMAE4DUm/3OWX4mZ/24OrjAbP/d6VS4dlEBmP/SLKOuX19m3biZDluiWki0vd/ASRtfV96NDQwL4dFa2Rf2f+xc=; 6:CynuC7BYMN5Zi4fCXGzOhbVzrSN4DBUaOIUNuOdDcNnHpdIlo/lqD2vYhZM8TAnQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1985; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB1985; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1985; x-forefront-prvs: 0612E553B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52044002)(66066001)(76176999)(50986999)(74316001)(5003600100002)(5001770100001)(46102003)(5001960100002)(102836002)(77096005)(189998001)(2950100001)(2900100001)(5002640100001)(33656002)(86362001)(106116001)(40100003)(122556002)(99286002)(62966003)(77156002)(2656002)(92566002)(54356999)(76576001)(558084003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1985; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2015 21:36:12.9151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1985 Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 19 Jun 2015 21:36:15 -0000 I am aware of one implementation that is almost RFC 7112 compliant. It drop= s the packet, but fails to send an ICMP message. = Ron > Yes, we're aware of RFC7112. It's just: no OS we know and no devices we'r= e > aware of (feel free to provide pointers) implement RFC 7112 as of today.= =20 From nobody Fri Jun 19 14:46:47 2015 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 267101B2B0F for ; Fri, 19 Jun 2015 14:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8oSxRxkeWdpG for ; Fri, 19 Jun 2015 14:46:41 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82631B2B10 for ; Fri, 19 Jun 2015 14:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1434750397; x=2298663997; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UzF+uoTnj7FNvS3uKha7TUs9OWhSHy4CgWyMtejperE=; b=03RQGse2e0vuNDX1MjbVKBeHu1QQWVbpz+MLCHwhVOMrWFDbGuCPx/S+J4wUuQg7 iO1zLae+6OJ6srjkzyjt17WjAMrbiZBZvoN/dh2XbID/zpuEVuK6SQMQHc0t8+S9 CeVNLr3UmBXFVEJKA8QOg0ntwXYrCGYdJPCGZxlfzk0xY6eqswvSI4p9ov9lMlfp +QR93aIGKNxA17Z673PoihqOYSgtPm1B0rnCoJ/vUmBVzHuhKLdjiyLsfKrLAbMW eEdRjj9oaEa8MEHUKJQ1oHiQHAaw8cEZ0tIaDN/PLIGw0TG9rBD4yUNbooy7YVMv tQ1LV+TWYKaiOBZjuKMYbg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 4A.67.12430.DBD84855; Fri, 19 Jun 2015 14:46:37 -0700 (PDT) X-AuditID: 11973e13-f79d56d00000308e-2f-55848dbd3a7d Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 3F.AF.00725.DBD84855; Fri, 19 Jun 2015 14:46:37 -0700 (PDT) Received: from [17.153.80.129] by kencur.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NQ7000KYOHODC30@kencur.apple.com> for v6ops@ietf.org; Fri, 19 Jun 2015 14:46:37 -0700 (PDT) From: David Schinazi Content-type: multipart/alternative; boundary="Apple-Mail=_036FD2A1-4B7E-411A-B8B8-DD5FAF0181C1" Date: Fri, 19 Jun 2015 14:46:36 -0700 Message-id: To: v6ops@ietf.org MIME-version: 1.0 (Mac OS X Mail 8.2 \(2101\)) X-Mailer: Apple Mail (2.2101) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FCYpru3tyXUYHu3rMXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXpaK1tBm1fFgbffWRoYb9p3MXJySAiYSGw50MgEYYtJXLi3 nq2LkYtDSGAfo8SOKV3MMEWdZ/oZIRLtTBKzZ19gh3C+MEqcbngA1M7BwSagJXFgjRFIA7NA ksSLi1/BpgoL6EqsuA5Sz8nBIqAqsfTuIlYQm1fARqLh5F1GiPpciTtbZoItExEQktjxrIkJ okZPYse186wg4yUEZCUWbOUCWSsh8JZV4sCLpawTGAVmIVk3C0kLRFxbYtnC18yzgNqZBXQk Ji9kRBWGsD+eP8K0gJFtFaNQbmJmjm5mnqleYkFBTqpecn7uJkZQEE+3E97BeHqV1SFGAQ5G JR7ejh/NoUKsiWXFlbmHGKU5WJTEee82tYQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOzO 5BIsvdY4KUnvtscGtxa75iPqqyM4rizu1am3eOsaHLFEYstzSfaNUT2LpqvdkD+XFbHzxWaF WzeD3+W5b9IyyXwUd7f5+vXtygHCDhIuJ8oncmx6N1Xk853jG17fYNtsPpHhWMXMLpvbHec2 nT+h+92/h6mhxujZoWuxtzpVVxgrN+xTvqPEUpyRaKjFXFScCACUexRcQwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUiON1OTXdvb0uowZJPkhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxupprWwFbV4VB95+Z2lgvGnfxcjJISFgItF5pp8RwhaTuHBv PVsXIxeHkEA7k8Ts2RfYIZwvjBKnGx4wdTFycLAJaEkcWGME0sAskCTx4uJXJhBbWEBXYsV1 kHpODhYBVYmldxexgti8AjYSDSfvMkLU50rc2TKTGcQWERCS2PGsiQmiRk9ix7XzrCDjJQRk JRZs5ZrAyDsLyYZZSKog4toSyxa+Zp4F1MEsoCMxeSEjqjCE/fH8EaYFjGyrGAWKUnMSKy30 EgsKclL1kvNzNzGCgq6hMG0HY9Nyq0OMAhyMSjy8Bt+aQ4VYE8uKK3MPMUpwMCuJ8H6pbgkV 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsbBpQSSE8sSc1OTS1ILYLJMnFwSjUw6vJxL3F/yRTC teX4BG7X9Z84y/gmWxizXHbe45a418M94ZuRaoPzUsf2DzasE1waT1mWfbZ7kTTT1t/o/ebj xxaViWT//+0nIq6263T/io2THn5K/XOe28bISWxNzvOnohs78uuObF1W+/hkNfODi6rTqg6H 3PnH+b3pWyr/dIf/UjL5uZ0OSizFGYmGWsxFxYkA901ffTYCAAA= Archived-At: Cc: Vividh Siddha , Tommy Pauly Subject: [v6ops] Apple and IPv6, a few clarifications 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, 19 Jun 2015 21:46:46 -0000 --Apple-Mail=_036FD2A1-4B7E-411A-B8B8-DD5FAF0181C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, I'd like to clarify a few points about Apple's IPv6 announcements during = WWDC 2015. The video (streaming with Safari or download with all browsers) and = slides of that talk are available at: https://developer.apple.com/videos/wwdc/2015/?id=3D719 = *) Personal hotspot on iOS If your iPhone has dual-stack connectivity on its cellular network, the = hotspot it creates will be dual-stack as well. The phone will share its prefix with Wi-Fi = clients. *) Internet Sharing on the Mac Today, regular internet sharing (from your ethernet to Wi-Fi for = example) does not support IPv6 because of the limited use cases, and the lack of demand = for it. *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 test mode was designed to help developers ensure that their = app can still function with IPv6-only NAT64+DNS64 connectivity and communicate with = their IPv4 server, even if the developer does not have access to the IPv6 internet. = That NAT64 network does not have IPv6 connectivity to the global IPv6 internet. As = such, the current version advertises addresses from 2001::/64 instead of ULAs to simulate = real IPv6 connectivity, as all IPv6 packets are terminated at the NAT64 server on = the Mac. This implementation detail could change in the future. *) Making IPv4 literals work on NAT64 networks when using high-level = APIs Starting with this year's versions, if you use NSURLSession to connect = to an IPv4 literal on an IPv6-only NAT64-DNS64 network, the API will bump in a IPv6 = literal synthesized using RFC 7050. Note that this will not happen when using = sockets directly. We do not support under-the-sockets bump-in-API (RFC 3338) and = we do not support 464XLAT. *) Happy Eyeballs We've heard feedback on our Happy Eyeballs implementation and are = investigating this topic. Note that this reflects how these technologies work in the current = versions of the 2015 betas, many of these details could change in future betas. Please = keep in mind that these betas are previews and we welcome feedback on improving them. Feel free to contact me if you have any questions, I will also attend = IETF93. Thanks, David Schinazi Apple CoreOS Networking Engineer= --Apple-Mail=_036FD2A1-4B7E-411A-B8B8-DD5FAF0181C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi everyone,

I'd like to clarify a few = points about Apple's IPv6 announcements during WWDC 2015.
The video (streaming with Safari or download with all = browsers) and slides of that talk
are available at: = https://developer.apple.com/videos/wwdc/2015/?id=3D719

*) Personal = hotspot on iOS
If your iPhone has dual-stack = connectivity on its cellular network, the hotspot it creates
will be dual-stack as well. The phone will share its prefix = with Wi-Fi clients.

*) Internet Sharing on the = Mac
Today, regular internet sharing (from your ethernet = to Wi-Fi for example) does not
support IPv6 = because of the limited use cases, and the lack of demand for = it.

*) Internet Sharing on the Mac - NAT64 testing mode
The NAT64 test mode was designed to help developers ensure = that their app can still
function with IPv6-only = NAT64+DNS64 connectivity and communicate with their IPv4
server, even if the developer does not have access to the = IPv6 internet. That NAT64
network does not have IPv6 = connectivity to the global IPv6 internet. As such, the current
version advertises addresses from 2001::/64 instead of ULAs = to simulate real IPv6
connectivity, as all IPv6 = packets are terminated at the NAT64 server on the Mac.
This implementation detail could change in the = future.

*) Making IPv4 literals work on NAT64 = networks when using high-level APIs
Starting with = this year's versions, if you use NSURLSession to connect to an = IPv4
literal on an IPv6-only NAT64-DNS64 network, the = API will bump in a IPv6 literal
synthesized using = RFC 7050. Note that this will not happen when using sockets
directly. We do not support under-the-sockets bump-in-API = (RFC 3338) and we
do not support 464XLAT.

*) Happy = Eyeballs
We've heard feedback on our Happy = Eyeballs implementation and are investigating
this = topic.

Note that this reflects how these technologies work in the = current versions of the
2015 betas, many of these = details could change in future betas. Please keep in mind
that these betas are previews and we welcome feedback on = improving them.

Feel free to contact me if you have = any questions, I will also attend IETF93.

Thanks,
David Schinazi
Apple CoreOS Networking = Engineer
= --Apple-Mail=_036FD2A1-4B7E-411A-B8B8-DD5FAF0181C1-- From nobody Fri Jun 19 15:10:20 2015 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 6E5771B2B66 for ; Fri, 19 Jun 2015 15:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 YL-iUgcE0X0l for ; Fri, 19 Jun 2015 15:10:17 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700DE1B2B63 for ; Fri, 19 Jun 2015 15:10:17 -0700 (PDT) Received: by wgfq1 with SMTP id q1so52960505wgf.1 for ; Fri, 19 Jun 2015 15:10: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:date:message-id:subject:from:to :cc:content-type; bh=4oymqIpflCymK22cLohOP3/2n+bvQAOLf3ilZD8+CCM=; b=EMzjvoI7vv8hZSyQ3e+afsNgcuxmo0Bz31fNMoBDiooQzNXCI/Lvhyqc83GYNJWwh7 r/rIYFgwcKn5+Oxf7Dk+hv0DU0SZPfckj4uhkPAdNDGreovgMixOxeKgm7uwfnKjrmx2 DQdA5iM/47gaSSJKY/KQ5kipKlVqTdGkwpy270HmSxpjk8MKFwLEobZYdKCgOP/M9AvZ cFIczJ9ZX2x66K7VPJw2OHA9JHkJEpsBWy8Q2XrPIFxCNlkuNmLQiY0aRfaRnsD6hIfC YpzGnfDMZPDRzZSFG8BbLHUS0Mf9ymZEsfjf98sQOslrDc4ka9Xqh9sifUp2+r4fSZcZ bDow== MIME-Version: 1.0 X-Received: by 10.180.95.10 with SMTP id dg10mr10554784wib.41.1434751816167; Fri, 19 Jun 2015 15:10:16 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Fri, 19 Jun 2015 15:10:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 15:10:16 -0700 Message-ID: From: Ca By To: David Schinazi Content-Type: multipart/alternative; boundary=f46d04447f8357f89d0518e630a6 Archived-At: Cc: "v6ops@ietf.org" , Vividh Siddha , Tommy Pauly Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 19 Jun 2015 22:10:19 -0000 --f46d04447f8357f89d0518e630a6 Content-Type: text/plain; charset=UTF-8 David, All of this is good news. Thank you. I assume the goal is for Apple users to have a good experience on production ipv6-only nat64/dns64 network. When do you expect mobile operators to be able to launch production quality ipv6-only? When should the apn config flip from ipv4 to ipv6? Finally, are you running your iPhone on ipv6-only LTE? I am. It is very important to eat the dog food. CB On Friday, June 19, 2015, David Schinazi wrote: > Hi everyone, > > I'd like to clarify a few points about Apple's IPv6 announcements during > WWDC 2015. > The video (streaming with Safari or download with all browsers) and slides > of that talk > are available at: https://developer.apple.com/videos/wwdc/2015/?id=719 > > *) Personal hotspot on iOS > If your iPhone has dual-stack connectivity on its cellular network, the > hotspot it creates > will be dual-stack as well. The phone will share its prefix with Wi-Fi > clients. > > *) Internet Sharing on the Mac > Today, regular internet sharing (from your ethernet to Wi-Fi for example) > does not > support IPv6 because of the limited use cases, and the lack of demand for > it. > > *) Internet Sharing on the Mac - NAT64 testing mode > The NAT64 test mode was designed to help developers ensure that their app > can still > function with IPv6-only NAT64+DNS64 connectivity and communicate with > their IPv4 > server, even if the developer does not have access to the IPv6 internet. > That NAT64 > network does not have IPv6 connectivity to the global IPv6 internet. As > such, the current > version advertises addresses from 2001::/64 instead of ULAs to simulate > real IPv6 > connectivity, as all IPv6 packets are terminated at the NAT64 server on > the Mac. > This implementation detail could change in the future. > > *) Making IPv4 literals work on NAT64 networks when using high-level APIs > Starting with this year's versions, if you use NSURLSession to connect to > an IPv4 > literal on an IPv6-only NAT64-DNS64 network, the API will bump in a IPv6 > literal > synthesized using RFC 7050. Note that this will not happen when using > sockets > directly. We do not support under-the-sockets bump-in-API (RFC 3338) and we > do not support 464XLAT. > > *) Happy Eyeballs > We've heard feedback on our Happy Eyeballs implementation and are > investigating > this topic. > > Note that this reflects how these technologies work in the current > versions of the > 2015 betas, many of these details could change in future betas. Please > keep in mind > that these betas are previews and we welcome feedback on improving them. > > Feel free to contact me if you have any questions, I will also attend > IETF93. > > Thanks, > David Schinazi > Apple CoreOS Networking Engineer > --f46d04447f8357f89d0518e630a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David,

All of this is good news.=C2=A0 Thank you.=C2=A0<= /div>

I assume the goal is for Apple users to have a goo= d experience on production ipv6-only nat64/dns64 network.=C2=A0
<= br>
When do you expect mobile operators to be able to launch prod= uction quality ipv6-only? When should the apn config flip from ipv4 to ipv6= ?

Finally, are you running your iPhone on ipv6-onl= y LTE?=C2=A0 I am. It is very important to eat the dog food.=C2=A0

CB



On Friday, June 19, 20= 15, David Schinazi <dschinazi@app= le.com> wrote:
Hi everyone,

I'd like to clarify a few points about A= pple's IPv6 announcements during WWDC 2015.
The video (streaming with Safari= or download with all browsers) and slides of that talk
<= br>
*= ) Personal hotspot on iOS
If your iPhone has dual-stack connectivity on its cell= ular network, the hotspot it creates
will be dual-stack as well. The phone will = share its prefix with Wi-Fi clients.

*) Internet Sharing on the = Mac
T= oday, regular internet sharing (from your ethernet to Wi-Fi for example) do= es not
support IPv6 because of the limited use cases, and the lack of demand for= it.

*) Internet Sharing on the Mac - NAT64 testing mode
The NAT64 te= st mode was designed to help developers ensure that their app can still
function= with IPv6-only NAT64+DNS64 connectivity and communicate with their IPv4
server,= even if the developer does not have access to the IPv6 internet. That NAT6= 4
net= work does not have IPv6 connectivity to the global IPv6 internet. As such, = the current
version advertises addresses from 2001::/64 instead of ULAs to simul= ate real IPv6
connectivity, as all IPv6 packets are terminated at the NAT64 serv= er on the Mac.
This implementation detail could change in the future.

*) Making IPv4 literals work on NAT64 networks when using high-level APIs<= /div>
Start= ing with this year's versions, if you use NSURLSession to connect to an= IPv4
literal on an IPv6-only NAT64-DNS64 network, the API will bump in a IPv6 l= iteral
synthesized using RFC 7050. Note that this will not happen when using soc= kets
= directly. We do not support under-the-sockets bump-in-API (RFC 3338) and we=
do n= ot support 464XLAT.

*) Happy Eyeballs
We've heard feedback on our= Happy Eyeballs implementation and are investigating
this topic.

=
Note= that this reflects how these technologies work in the current versions of = the
2= 015 betas, many of these details could change in future betas. Please keep = in mind
that these betas are previews and we welcome feedback on improving them.=

Feel free to contact me if you have any questions, I will also = attend IETF93.

Thanks,
David Schinazi
Apple CoreOS Networking Engineer
--f46d04447f8357f89d0518e630a6-- From nobody Fri Jun 19 18:16:05 2015 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 862B41B2C28; Fri, 19 Jun 2015 18:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 WaDTsFUoqmRk; Fri, 19 Jun 2015 18:16:03 -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 2D3F91B2C26; Fri, 19 Jun 2015 18:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2092; q=dns/txt; s=iport; t=1434762964; x=1435972564; h=from:to:subject:date:message-id:references:mime-version; bh=4e/nZkuhGimIrFG1c0HjqYfI3+YA7NN7S8novpaNwl8=; b=YRvfQdqn0W/lbFvwUQ23v+mLS7p4qvZNOuHZM2SRs4/5qDldPw8OqjnW x06xEQGTwCDSz2COUiyA06UvPM+G5fN00Gp+F8D8msA6YN89Pe5VXeVNI /HG/dfn7vAgU66AXGXe7nuNYFfIG82kK9/OXe49A/76CD1uygQGDoZBnI w=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBQCzvYRV/4MNJK1cgxBUXwa5UYQ0gWaFeAKBODoSAQEBAQEBAYEKhCIBAQEDAX4LAgEZAwECLzIUBwIIAgQBEg6IGQgNxhYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItFhHUTC4MRgRQFk3wBgiOBTmSGeJguJmODFm8BgUWBAgEBAQ X-IronPort-AV: E=Sophos; i="5.13,647,1427760000"; d="asc'?scan'208"; a="8813847" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jun 2015 01:16:03 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5K1G2kD026296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Jun 2015 01:16:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 19 Jun 2015 20:16:02 -0500 From: "Fred Baker (fred)" To: v6ops list , "sunset4@ietf.org" Thread-Topic: IETF 93 Preliminary Agenda Thread-Index: AQHQqug9kF2V6CVI/0u7TJir7BXpeA== Date: Sat, 20 Jun 2015 01:16:01 +0000 Message-ID: References: <20150619233211.968.38234.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.53.82] Content-Type: multipart/signed; boundary="Apple-Mail=_24A38179-3D32-4BFF-875E-89D344EC224C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: IETF 93 Preliminary Agenda 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, 20 Jun 2015 01:16:04 -0000 --Apple-Mail=_24A38179-3D32-4BFF-875E-89D344EC224C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The provisional agenda has been posted. > Begin forwarded message: >=20 > From: IETF Agenda > Subject: IETF 93 Preliminary Agenda > Date: June 19, 2015 at 4:32:11 PM PDT > To: IETF Announcement List > Cc: <93all@ietf.org>, > Reply-To: , IETF Agenda >=20 >=20 > The IETF 93 Preliminary Agenda has been posted. The final agenda will = be published on Friday, June 26th 2015. >=20 > https://datatracker.ietf.org/meeting/93/agenda.html > https://datatracker.ietf.org/meeting/93/agenda.txt >=20 > More information regarding IETF 93 in Prague is located here: = https://www.ietf.org/meeting/93/index.html >=20 > Thank you! >=20 > IETF Secretariat >=20 --Apple-Mail=_24A38179-3D32-4BFF-875E-89D344EC224C 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 iQIVAwUBVYS+z0ayAOS/EQ8MAQJ1tw//f1OOq6n3sgkw3QMTnGKQOLdgp+EWZBsa dwaAU+GFjSuKL5RyHfaQS5JibcqcjRZr0T/nVrEXB/Cd9io2G3EsPhNCaHDFKWw4 rQzx4554ykrkp73FkBiAHNL5bbZl95iPknUrP5jI3ghywlNHRZAU7DXVZOuoWp6s Eq1Cl6yVfVdd/FlunW5gyrx91xs4iaBofO6mDfA4xpmyaNjo2uBWVB8SF8n5rnjM 5/EOpRJUTY4PEzQmz79YpdZmIAWjwZamFBfSjJLMezZGGqQWVpaaddRE3AoRD2pA tPKBzl3ezjbZA+VGoJ+y5EWnvROrgfsVW4lC+ytxSLKhdChqSBklXjaM9qZZvqSj vs/ZRa0pv5ahmWQKzS53gl7xIjhiXHbqVwCfFG7JSLjtCzWBHA8kw2pNxCFi01j/ rswt6vQ6p8vZW19IeLFHh8eHtd21bkmzswOvlIvaRkm8Ni4PqfSOZF6nHmvGePAG 6kntpNpueJtCauQRHR97AwxG5NO68+vdmhIMtihU8njftjJUtMxEEtRZDPcVKR/7 3SMiYCddGqvE0JBmWJAMZWLoQJxagTR3ZTB/2vKgzX4YVS2AH76Fdeayr+Vc8G3N 7Gj4aQMdWLj//UNHWFQXa5K9q/+M4BgD0N8MWXxi2HluC/Olf/J9PRiXO1MGxdBX 7DiCdHEXmDI= =E2EI -----END PGP SIGNATURE----- --Apple-Mail=_24A38179-3D32-4BFF-875E-89D344EC224C-- From nobody Fri Jun 19 20:11:21 2015 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 81F3A1B2CD4 for ; Fri, 19 Jun 2015 20:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_20=-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, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 mR7RgLnDEwp8 for ; Fri, 19 Jun 2015 20:11:17 -0700 (PDT) Received: from nm40-vm2.bullet.mail.ne1.yahoo.com (nm40-vm2.bullet.mail.ne1.yahoo.com [98.138.229.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CDB1B2CD3 for ; Fri, 19 Jun 2015 20:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1434769875; bh=sid6FV+iqp4UsKlamWQLFw01jv3xQYpH6k9omhdXt78=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=K1zVPfPBifGRVQI0LYoOUkcjKCdV7MJkP7mSyPCVJsSM+Pcq+5OK3R1+ghdmBgiq+UK/AtWvUlDg+ga6nKsmSzH/r91Wv/9lCppmPmPSWe+1hkIC9orvD5wPRwTX9O/ylb8+Aa9oltxSFFBX4eRNIaBaZL38yp6S+1c7mBgjw8g0hoUtsTz+wuzpNPw63jdgjimestwvNQz/Uwplq41efg/+HRjGgpCuNgz4Jt1cAKRTnQprcoNXSZ5RUsrDR6ravWl+465+y/9b9Fu2BxOLyrs6/UbKYtyVyFebnmOCGw8jO2ULXdYOvmbpDFwXnE4kmxTunlDyTxqTw8+v6JJ/AA== Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jun 2015 03:11:15 -0000 Received: from [98.138.100.115] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jun 2015 03:08:22 -0000 Received: from [66.196.81.170] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jun 2015 03:08:22 -0000 Received: from [98.139.212.236] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jun 2015 03:08:22 -0000 Received: from [127.0.0.1] by omp1045.mail.bf1.yahoo.com with NNFMP; 20 Jun 2015 03:08:22 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 310745.42822.bm@omp1045.mail.bf1.yahoo.com X-YMail-OSG: hxwhDkgVM1n.jzKCGutfLczljyLwLPnryI5yL0y0CGaxp_bXq1Mck2xOV3WHPVd MfWVTUNAk1LlANa.T1a1YiCz.jD666toLYVzL.yWFhu3jI.Aepk0tiXzs.VSK4cD05cGxZsU6vZt oUtUPw.dLwZfoNG3UQrO_u9Bxke7l.sxKFz4yWKcOlL8XsOE_9uVg_GzW8MtGwxl9KSuE1PezXOw 7BuUgVKuahJBsfp2VLqKJ6xs7fkwRdIuWiJxkfyNtZYHT_OQUCalSG7GEo.Pa5uIsFIwWVsTRWcz xWMahbGDz9h7aftjEqFBRDxudUY7747D1vayU1hor1mpQHCUkWr6if_lNL8P4k5oJFVaUSmMohnh mnMKdRo5KPD7RqthWceAbsHCabs27_Hh9saF.2Jht6oZyeM._pgIKMjqHUkW.II14QX4_0V4b6CO nVRk_LZvQij32npLgeZc0veCQbKcX4Rsf.SoLMF8IhQ89FqKfF7jb4BvTMhNxE00DF98Nrsn6hzI quFA729VCUlbSp75qiup_Em5MBl.uqshyzZbDIGDMNFjkAXXr3Yj16pqoZVi3Uw-- Received: by 66.196.81.104; Sat, 20 Jun 2015 03:08:21 +0000 Date: Sat, 20 Jun 2015 03:07:56 +0000 (UTC) From: Mark ZZZ Smith To: Warren Kumari Message-ID: <80795428.2671239.1434769676085.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2671238_513756730.1434769676074" Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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: Sat, 20 Jun 2015 03:11:19 -0000 ------=_Part_2671238_513756730.1434769676074 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Warren, From: Warren Kumari To: Mark ZZZ Smith =20 Cc: Enno Rey ; Ole Troan ; "v6ops@ietf.= org" ; "ipv6-wg@ripe.net" =20 Sent: Saturday, 20 June 2015, 6:19 Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devi= ces =20 On Fri, Jun 19, 2015 at 5:13 AM, Mark ZZZ Smith wrote: > > ________________________________ > From: Enno Rey > To: Ole Troan > Cc: v6ops@ietf.org; ipv6-wg@ripe.net > Sent: Friday, 19 June 2015, 18:34 > Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security > Devices > > > / I think you're only expressing the view of many security engineers, not > the many network engineers or the many more users of networks. At an ISP,= if > you block traffic your customer wants send, all you get is angry customer= s. ... and at an ISP if your customer calls you up because they are being DDoSed out of existence with traffic at some port that they don't use, and you tell them at that you cannot filter UDP port 80 because, well, you cannot find it, you also end up with an angry customer. / If you can't find it, that may be because it isn't actually there. / Here's what I wrote in my earlier email what problem/problems being solve= d email about network capacity DoS: / =C2=A0"(1) I think TCP/UDP port level filtering for this purpose is certa= inly a nice to have but not a necessary to have, because network capacity D= oSs will use some other protocol for their DoS if mitigating DoSs using TCP= /UDP traffic becomes too effective. Completely dropping DoS traffic identif= ied just by src and/or dst address, or plonking that traffic into a scaveng= er QoS class for a while if complete dropping is too severe is a general so= lution that will work regardless of the type of DoS traffic. Using TCP/UDP = ports if they're easily available would allow the dropping to be more granu= lar, but is not required to mitigate the network capacity DoS." / although I'd reword that last sentence and say something like "Using TCP/= UDP ports if they're easily available would allow the dropping to be more g= ranular, but cannot be relied on to mitigate all network capacity DoSes." / If the motivation of the DoS attacker is to exhaust network capacity, the= n they don't really care what type of traffic it is. Using UDP or TCP is pr= obably convenient, but if that becomes too easy to block, they'll use somet= hing else. / OTOH, if their motivation is to DoS a particular application, then you're= going to have to let some of it through because some of it is legitimate v= ia something like the policed/shaped QoS class, as well as possibly by drop= ping traffic from a set of sources that appear to be DoS traffic origins ra= ther than legitimate sources. / Perhaps wanting the TCP and UDP headers in a known location in the packet= so that simple ACLs can filter them is a more specific case of being able = to filter packets using a bit mask in an arbitrary specified location withi= n the packet. I'm not aware of any routers where this is an option in ACLs = (although it is ringing a very small bell), so perhaps that is what is miss= ing from routers today (I don't know much about OpenFlow, although I'd have= expected OF switches to be able to do this. However, quickly downloading a= nd looking at the OF specs, it doesn't seem that specifying an arbitrary bi= t range and mask to match on is supported). Being able to do that would not= only make ACLs more general purpose, but would also allow more accurate fi= ltering on non-TCP/UDP packets too, rather than just using source and/or de= stination addresses for this traffic. I think that would better alleviate t= he desire of people to restrict transport layer protocols to only TCP/UDP. / A DoS attacker could overcome that by randomising packet contents, howeve= r that is more work for them, and I think would classify the DoS attack as = a network capacity exhaustion attack, meaning that the methods such as drop= ping or policing/shaping high volume sources using just IP addresses would = be more effective. > They're paying you to deliver any and all of their packets as well as > possible, with as minimum restrictions as possible, ideally none, rather > than the opposite. Perhaps. I figure they are /actually/ paying you to provide them with good service. Sometimes that includes filtering for them, because you have bigger pipes than them... / I think sanitising traffic is a different and much harder problem to solv= e than mitigating a DoS attack. I think mitigating DoSes is enough of a ser= vice to provide to customers as part of their Internet access, because goin= g any "deeper" means getting involved in what protocols and therefore what = applications the customer is choosing to use and may choose to use in the f= uture. That's a separate service. / Regards,/ Mark. W > This is why I don't think you'll ever get consensus on > deprecating EHs, because I think you're only coming the position of tryin= g > to solve problem (3) I described in my last email. > > / I'd also observe that deprecating EHs, other than ESP, AH+FH, TCP and U= DP, > would also prevent them from being used behind the ESP EH - where you won= 't > be able to see what is in them, so you won't be able to care what is in > them. You'll also be preventing people from other transport layer protoco= ls, > such as SCTP and DCCP, that are feasible to deploy over the IPv6 Internet > that couldn't be over the IPv4 network because of IPv4 NAT and other midd= le > boxes. > > thanks > > Enno > > > > >> >> cheers, >> Ole > > > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > =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=3D=3D= =3D=3D=3D=3D=3D=3D > Blog:=C2=A0 || Conference: www.troopers.de > Twitter: @Enno_Insinuator > > > > =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=3D=3D= =3D=3D=3D=3D=3D=3D > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. =C2=A0 ---maf ------=_Part_2671238_513756730.1434769676074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Warren,
From: Warren Kumari <warren@kumari.= net>
To: Mark ZZZ S= mith <markzzzsmith@yahoo.com.au>
Cc: Enno Rey <erey@ernw.de>; Ole Troan <otroan@em= ployees.org>; "v6ops@ietf.org" <v6ops@ietf.org>; "ipv6-wg@ripe.net= " <ipv6-wg@ripe.net>
Sent:= Saturday, 20 June 2015, 6:19
Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impac= t on Security Devices

On Fri, Jun 19, 2015 at 5:13 AM, Mark ZZZ Smith
<markzzzsmith@yahoo.com.au> wro= te:
>
> _________________________= _______
> From: Enno Rey <erey@ernw.de><= br clear=3D"none">> To: Ole Troan <otroan@employe= es.org>
> Cc: v6ops@ietf.org; ipv6-wg@ripe.net
> Sent: Friday, 19 June 2015, 18:34
> Sub= ject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security
> Devices
>
<snip>= ;

>
> / I think you're only expressing the view of many securi= ty engineers, not
> the many network engineers or the = many more users of networks. At an ISP, if
> you block= traffic your customer wants send, all you get is angry customers.

... and at an ISP if your customer calls you u= p because they are being
DDoSed out of existence with tra= ffic at some port that they don't use,
and you tell them = at that you cannot filter UDP port 80 because, well,
you = cannot find it, you also end up with an angry customer.

/ If you can't find it, that may be because it isn't actually there.
=

/ Here's what I wrote in my earlier email what problem/probl= ems being solved email about network capacity DoS:

/  "(1) I think TCP/UDP port le= vel filtering for this purpose is certainly a nice to have but not a necess= ary to have, because network capacity DoSs will use some other protocol for= their DoS if mitigating DoSs using TCP/UDP traffic becomes too effective. = Completely dropping DoS traffic identified just by src and/or dst address, = or plonking that traffic into a scavenger QoS class for a while if complete= dropping is too severe is a general solution that will work regardless of = the type of DoS traffic. Using TCP/UDP ports if they're easily available wo= uld allow the dropping to be more granular, but is not required to mitigate= the network capacity DoS."

/ al= though I'd reword that last sentence and say something like "Using TCP/UDP = ports if they're easily available would allow the dropping to be more granu= lar, but cannot be relied on to mitigate all network capacity DoSes."
=

/ If the motivation of the DoS attacker is to exhaust networ= k capacity, then they don't really care what type of traffic it is. Using U= DP or TCP is probably convenient, but if that becomes too easy to block, th= ey'll use something else.

=
/ OTOH, if their = motivation is to DoS a particular application, then you're going to have to= let some of it through because some of it is legitimate via something like= the policed/shaped QoS class, as well as possibly by dropping traffic from= a set of sources that appear to be DoS traffic origins rather than legitim= ate sources.

<= /div>
/ Perhaps wanting = the TCP and UDP headers in a known location in the packet so that simple AC= Ls can filter them is a more specific case of being able to filter packets = using a bit mask in an arbitrary specified location within the packet. I'm = not aware of any routers where this is an option in ACLs (although it is ri= nging a very small bell), so perhaps that is what is missing from routers t= oday (I don't know much about OpenFlow, although I'd have expected OF switc= hes to be able to do this. However, quickly downloading and looking at the = OF specs, it doesn't seem that specifying an arbitrary bit range and mask t= o match on is supported). Being able to do that would not only make ACLs mo= re general purpose, but would also allow more accurate filtering on non-TCP= /UDP packets too, rather than just using source and/or destination addresse= s for this traffic. I think that would better alleviate the desire of peopl= e to restrict transport layer protocols to only TCP/UDP.

/ A DoS attacker could overcome that by randomisi= ng packet contents, however that is more work for them, and I think would c= lassify the DoS attack as a network capacity exhaustion attack, meaning tha= t the methods such as dropping or policing/shaping high volume sources usin= g just IP addresses would be more effective.


> They're paying yo= u to deliver any and all of their packets as well as
>= possible, with as minimum restrictions as possible, ideally none, rather> than the opposite.

Perhaps. I figure they are /actually/ paying you to provide them withgood service. Sometimes that includes filtering for them, b= ecause you
have bigger pipes than them...

/ I think sanitising traffic is a different and much har= der problem to solve than mitigating a DoS attack. I think mitigating DoSes= is enough of a service to provide to customers as part of their Internet a= ccess, because going any "deeper" means getting involved in what protocols = and therefore what applications the customer is choosing to use and may cho= ose to use in the future. That's a separate service.

/ Regards,
/ Mark.


W

> = This is why I don't think you'll ever get consensus on
&g= t; deprecating EHs, because I think you're only coming the position of tryi= ng
> to solve problem (3) I described in my last email= .
>
> / I'd also observe that dep= recating EHs, other than ESP, AH+FH, TCP and UDP,
> wo= uld also prevent them from being used behind the ESP EH - where you won't> be able to see what is in them, so you won't be able = to care what is in
> them. You'll also be preventing p= eople from other transport layer protocols,
> such as = SCTP and DCCP, that are feasible to deploy over the IPv6 Internet
> that couldn't be over the IPv4 network because of IPv4 NAT a= nd other middle
> boxes.
>
> thanks
>
> Enno<= br clear=3D"none">>
>
>
>
>>
>> chee= rs,
>> Ole
>
>
>
> --
&g= t; Enno Rey
>
> ERNW GmbH - Carl-= Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. += 49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
&= gt;
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
>
> =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=3D=3D=3D=3D=3D=3D=3D=3D
> Blog:  || Conferen= ce: www.troopers.de



> Twitter: @Enno_In= sinuator
>
>
&g= t;
> =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=3D=3D=3D=3D=3D=3D=3D=3D
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/list= info/v6ops
>
>
>
> ___________________________________________= ____
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf= .org/mailman/listinfo/v6ops

>



--
I don't think the execution is relevant when it was obviously a b= ad
idea in the first place.
This is lik= e putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
  ---maf



=
------=_Part_2671238_513756730.1434769676074-- From nobody Sat Jun 20 02:21:41 2015 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 7E2641A007E for ; Sat, 20 Jun 2015 02:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] 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 wSMHcBq3OVBA for ; Sat, 20 Jun 2015 02:21:37 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6268E1A008B for ; Sat, 20 Jun 2015 02:21:37 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::1] (port=41190 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z6Exu-0001X8-TF; Sat, 20 Jun 2015 11:21:30 +0200 Date: Sat, 20 Jun 2015 11:21:30 +0200 From: Tore Anderson To: David Schinazi Message-ID: <20150620112130.42377dd1@envy.fud.no> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 20 Jun 2015 09:21:39 -0000 Hello David, First of all, let me say that the news from WWDC is very exciting, and I hope your strategy proves successful. With some luck, your approach of forcing app developers to write IPv6-capable code will also indirectly benefit the other platforms too. I have some follow-up questions though, see in-line: * David Schinazi > *) Personal hotspot on iOS > If your iPhone has dual-stack connectivity on its cellular network, > the hotspot it creates will be dual-stack as well. The phone will > share its prefix with Wi-Fi clients. And if the cellular network is IPv6-only? Does the tethered WLAN become IPv6-only too? If so, I can imagine that this would cause IPv4 compatibility issues for older Apple devices without the new Bump-in-the-API stuff, as well as for non-Apple devices attaching to the tethered WLAN. Hopefully this is not something that will put network operators off from provisioning IPv6(-only) connectivity to the Apple devices on their network... > *) Internet Sharing on the Mac - NAT64 testing mode > The NAT64 test mode was designed to help developers ensure that their > app can still function with IPv6-only NAT64+DNS64 connectivity and > communicate with their IPv4 server, even if the developer does not > have access to the IPv6 internet. That NAT64 network does not have > IPv6 connectivity to the global IPv6 internet. As such, the current > version advertises addresses from 2001::/64 instead of ULAs to > simulate real IPv6 connectivity, as all IPv6 packets are terminated > at the NAT64 server on the Mac. This implementation detail could > change in the future. One thing that is not clear to me, is if what happens if the app developer's server is dual-stacked. For example, if the DNS entries are as follows: www.example.com. IN A 192.0.2.1 www.example.com. IN AAAA 2001:db8::1 ...what exactly happens when the iOS node on the NAT64 testing WLAN attempts to access it? Obviously, as there is no connectivity to 2001:db8::1, native IPv6 towards the "IN AAAA" record cannot work. Does the DNS64 in the OS X host consider "::/0" as part of the Special Exclusion Set (cf. RFC6146 s5.1.4), causing it to ignore the upstream AAAA record and perform DNS64 synthesis instead, e.g., returning this to the tethered host: www.example.com. IN A 192.0.2.1 www.example.com. IN AAAA 2001::192.0.2.1 Or will it simply return the upstream DNS records verbatim (i.e., not performing any DNS64 synthesis), and rely on the Happy Eyeballs implementation in the iOS node to quickly figure out that the 2001:db8::1 address is unreachable and fail over to 192.0.2.1 (at which point the Bump-in-the-API can kick in and perform local translation to 2001::192.0.2.1)? Or perhaps something else entirely? > *) Making IPv4 literals work on NAT64 networks when using high-level > APIs Starting with this year's versions, if you use NSURLSession to > connect to an IPv4 literal on an IPv6-only NAT64-DNS64 network, the > API will bump in a IPv6 literal synthesized using RFC 7050. Note that > this will not happen when using sockets directly. We do not support > under-the-sockets bump-in-API (RFC 3338) and we do not support > 464XLAT. Does this mean that if the app is using socket directly, but in a correct and IPv6-supporting way, to either: 1) communicate with dual-stacked hostnames (assuming ::/0 is not in the DNS64's Special Exclusion Set as per what I wrote earlier), or 2) directly to an IPv6 literal address (think for example peer-to-peer applications/protocols that do not use DNS to begin with), ..will then any tests for correct IPv6-only app behaviour the developer performs on the NAT64 network fail, even though the app is doing everything right? A related question: Will the test system that validates App Store submissions for correct IPv6-only behaviour have full access to the entire IPv6 Internet, ensuring that apps such as the above will be approved, even though they might not work correctly behind an OS X NAT64-only test network? > *) Happy Eyeballs > We've heard feedback on our Happy Eyeballs implementation and are > investigating this topic. Great! Let me add my voice to this: Please ensure that IPv6 is consistently preferred over IPv4, if both protocols work equally well/fast (or roughly so). Only fall back on IPv4 it is clear that IPv6 is performing *significantly* worse than IPv4, or not at all. See RFC6555 s4.1. Tore From nobody Sat Jun 20 04:31:17 2015 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 D9C211A1B17 for ; Sat, 20 Jun 2015 04:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 qpIAFvZaFtnK for ; Sat, 20 Jun 2015 04:31:13 -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 A84F61A1B16 for ; Sat, 20 Jun 2015 04:31:12 -0700 (PDT) Received: (qmail 18857 messnum 383533 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 20 Jun 2015 11:31:10 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail19.svc.cra.dublin.eircom.net (qp 18857) with SMTP; 20 Jun 2015 11:31:10 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id ibX71q00B4BK5ly01bXA00; Sat, 20 Jun 2015 12:31:10 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_9F1C769E-03EA-49BA-A765-84BFF8FFBDCF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: Date: Sat, 20 Jun 2015 12:31:03 +0100 Message-Id: References: To: David Schinazi X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org, Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 20 Jun 2015 11:31:16 -0000 --Apple-Mail=_9F1C769E-03EA-49BA-A765-84BFF8FFBDCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David, Thanks for working towards supporting the IPv6-only carrier case! Not all visited operators can yet be relied on to allow dual-stack or = even IPv6-only bearers. Does it support fallback to an IPv4-only bearer when data roaming? Also could you clarify what the position will be with VPN support? Ross > On 19 Jun 2015, at 22:46, David Schinazi wrote: >=20 > Hi everyone, >=20 > I'd like to clarify a few points about Apple's IPv6 announcements = during WWDC 2015. > The video (streaming with Safari or download with all browsers) and = slides of that talk > are available at: https://developer.apple.com/videos/wwdc/2015/?id=3D719= >=20 > *) Personal hotspot on iOS > If your iPhone has dual-stack connectivity on its cellular network, = the hotspot it creates > will be dual-stack as well. The phone will share its prefix with Wi-Fi = clients. >=20 > *) Internet Sharing on the Mac > Today, regular internet sharing (from your ethernet to Wi-Fi for = example) does not > support IPv6 because of the limited use cases, and the lack of demand = for it. >=20 > *) Internet Sharing on the Mac - NAT64 testing mode > The NAT64 test mode was designed to help developers ensure that their = app can still > function with IPv6-only NAT64+DNS64 connectivity and communicate with = their IPv4 > server, even if the developer does not have access to the IPv6 = internet. That NAT64 > network does not have IPv6 connectivity to the global IPv6 internet. = As such, the current > version advertises addresses from 2001::/64 instead of ULAs to = simulate real IPv6 > connectivity, as all IPv6 packets are terminated at the NAT64 server = on the Mac. > This implementation detail could change in the future. >=20 > *) Making IPv4 literals work on NAT64 networks when using high-level = APIs > Starting with this year's versions, if you use NSURLSession to connect = to an IPv4 > literal on an IPv6-only NAT64-DNS64 network, the API will bump in a = IPv6 literal > synthesized using RFC 7050. Note that this will not happen when using = sockets > directly. We do not support under-the-sockets bump-in-API (RFC 3338) = and we > do not support 464XLAT. >=20 > *) Happy Eyeballs > We've heard feedback on our Happy Eyeballs implementation and are = investigating > this topic. >=20 > Note that this reflects how these technologies work in the current = versions of the > 2015 betas, many of these details could change in future betas. Please = keep in mind > that these betas are previews and we welcome feedback on improving = them. >=20 > Feel free to contact me if you have any questions, I will also attend = IETF93. >=20 > Thanks, > David Schinazi > Apple CoreOS Networking Engineer > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_9F1C769E-03EA-49BA-A765-84BFF8FFBDCF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi David,

Thanks for working towards supporting the IPv6-only = carrier case!

Not all visited operators can yet be = relied on to allow dual-stack or even IPv6-only bearers.
Does it support fallback to an IPv4-only bearer when data = roaming?

Also = could you clarify what the position will be with VPN support?

Ross



On 19 Jun 2015, at 22:46, David Schinazi <dschinazi@apple.com>= wrote:

Hi everyone,

I'd like to clarify a few points about = Apple's IPv6 announcements during WWDC 2015.
The video = (streaming with Safari or download with all browsers) and slides of that = talk
are available at: https://developer.apple.com/videos/wwdc/2015/?id=3D719

*) Personal = hotspot on iOS
If your iPhone has dual-stack = connectivity on its cellular network, the hotspot it creates
will be dual-stack as well. The phone will share its prefix = with Wi-Fi clients.

*) Internet Sharing on the = Mac
Today, regular internet sharing (from your ethernet = to Wi-Fi for example) does not
support IPv6 = because of the limited use cases, and the lack of demand for = it.

*) Internet Sharing on the Mac - NAT64 testing mode
The NAT64 test mode was designed to help developers ensure = that their app can still
function with IPv6-only = NAT64+DNS64 connectivity and communicate with their IPv4
server, even if the developer does not have access to the = IPv6 internet. That NAT64
network does not have IPv6 = connectivity to the global IPv6 internet. As such, the current
version advertises addresses from 2001::/64 instead of ULAs = to simulate real IPv6
connectivity, as all IPv6 = packets are terminated at the NAT64 server on the Mac.
This implementation detail could change in the = future.

*) Making IPv4 literals work on NAT64 = networks when using high-level APIs
Starting with = this year's versions, if you use NSURLSession to connect to an = IPv4
literal on an IPv6-only NAT64-DNS64 network, the = API will bump in a IPv6 literal
synthesized using = RFC 7050. Note that this will not happen when using sockets
directly. We do not support under-the-sockets bump-in-API = (RFC 3338) and we
do not support 464XLAT.

*) Happy = Eyeballs
We've heard feedback on our Happy = Eyeballs implementation and are investigating
this = topic.

Note that this reflects how these technologies work in the = current versions of the
2015 betas, many of these = details could change in future betas. Please keep in mind
that these betas are previews and we welcome feedback on = improving them.

Feel free to contact me if you have = any questions, I will also attend IETF93.

Thanks,
David Schinazi
Apple CoreOS Networking = Engineer
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_9F1C769E-03EA-49BA-A765-84BFF8FFBDCF-- From nobody Sun Jun 21 11:00:08 2015 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 482EF1AD373 for ; Sun, 21 Jun 2015 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.311 X-Spam-Level: X-Spam-Status: No, score=-110.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IXHASH_X1=1.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 F55gA8HgqV7y for ; Sun, 21 Jun 2015 11:00:05 -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 658161A896F for ; Sun, 21 Jun 2015 11:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1434909606; x=1436119206; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=NsWr2TTMqcPtCgNfEJ0Dbr7WpFmFN5UCwksDD/+DRm5a2Bn4Ds/7LMcR Vgr7WmElMD7E3mWPzY1HigFVcHkP1WFyw2F96V32MpjyrKhYHz6LNbKaC SNJXOCtQOWkko1Czp4S5+smE0Lbxrz1zmskGye4Ob0iGsVOy8IGtmSxbl I=; X-IronPort-AV: E=Sophos;i="5.13,655,1427760000"; d="scan'208";a="9082281" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jun 2015 18:00:06 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5LI04Yl013606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jun 2015 18:00:04 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 t5LI03B5008046; Sun, 21 Jun 2015 11:00:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t5LI03ux008043; Sun, 21 Jun 2015 11:00:03 -0700 Date: Sun, 21 Jun 2015 11:00:03 -0700 From: fred@cisco.com Message-Id: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-siit-eam 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, 21 Jun 2015 18:00:06 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From nobody Mon Jun 22 04:22:15 2015 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 1A8FF1B2F78 for ; Mon, 22 Jun 2015 04:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 G4TIm4W9O2IK for ; Mon, 22 Jun 2015 04:22:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48701ACE99 for ; Mon, 22 Jun 2015 04:22:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5MBM9Ax020645 for ; Mon, 22 Jun 2015 13:22:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3B3C9202A47 for ; Mon, 22 Jun 2015 13:25:02 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 31CF4202A82 for ; Mon, 22 Jun 2015 13:25:02 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5MBM5A8023656 for ; Mon, 22 Jun 2015 13:22:09 +0200 Message-ID: <5587EFDD.6030807@gmail.com> Date: Mon, 22 Jun 2015 13:22:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 11:22:14 -0000 Hi, Thanks for the report. I have a few comments. Le 19/06/2015 23:46, David Schinazi a écrit : [...] > *) Personal hotspot on iOS If your iPhone has dual-stack connectivity > on its cellular network, the hotspot it creates will be dual-stack as > well. The phone will share its prefix with Wi-Fi clients. The way of sharing a prefix with the Wi-Fi Clients is supposedly the one documented in RFC7278 "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link" https://tools.ietf.org/html/rfc7278 That is straightforward to implement yet it does have some drawbacks. The most important drawback of 64share IMHO is that the smartphone can not make two hotspots simultaneouly: one on WiFi and one on Bluetooth. Or otherwise one on WiFi5GHz and one on WiFi2.4GHz. Or several subnets in a car connected with an Apple phone to the Internet. Because it is impossible to share a unique /64 prefix to more than just one subnet. It is better to tell the operator to provide a /63 to smartphones (not a /64), with DHCPv6 Prefix Delegation. That will fix it. > *) Internet Sharing on the Mac Today, regular internet sharing (from > your ethernet to Wi-Fi for example) does not support IPv6 because of > the limited use cases, and the lack of demand for it. If you get done the above then you get Internet Sharing on the Mac Today as well, for free. > *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 test > mode was designed to help developers ensure that their app can still > function with IPv6-only NAT64+DNS64 connectivity and communicate with > their IPv4 server, even if the developer does not have access to the > IPv6 internet. That NAT64 network does not have IPv6 connectivity to > the global IPv6 internet. As such, the current version advertises > addresses from 2001::/64 instead of ULAs to simulate real IPv6 > connectivity, as all IPv6 packets are terminated at the NAT64 server > on the Mac. This implementation detail could change in the future. Makes sense. Alex > *) Making IPv4 literals work on NAT64 networks when using high-level > APIs Starting with this year's versions, if you use NSURLSession to > connect to an IPv4 literal on an IPv6-only NAT64-DNS64 network, the > API will bump in a IPv6 literal synthesized using RFC 7050. Note > that this will not happen when using sockets directly. We do not > support under-the-sockets bump-in-API (RFC 3338) and we do not > support 464XLAT. > > *) Happy Eyeballs We've heard feedback on our Happy Eyeballs > implementation and are investigating this topic. > > Note that this reflects how these technologies work in the current > versions of the 2015 betas, many of these details could change in > future betas. Please keep in mind that these betas are previews and > we welcome feedback on improving them. > > Feel free to contact me if you have any questions, I will also attend > IETF93. > > Thanks, David Schinazi Apple CoreOS Networking Engineer > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jun 22 04:45:21 2015 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 EA3AE1A00E0 for ; Mon, 22 Jun 2015 04:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IfOLioSCxdSz for ; Mon, 22 Jun 2015 04:45:18 -0700 (PDT) Received: from azaroth.sunriseroad.net (azaroth.sunriseroad.net [IPv6:2400:8900::f03c:91ff:fe96:40a4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67ADB1A00B5 for ; Mon, 22 Jun 2015 04:45:18 -0700 (PDT) Received: from rillian.sunriseroad.net (unknown [IPv6:2001:44b8:310c:a800:9957:e22a:c866:bc63]) by azaroth.sunriseroad.net (Postfix) with ESMTPSA id E68E8812A for ; Mon, 22 Jun 2015 21:45:16 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunriseroad.net; s=2015; t=1434973517; bh=ztKke1Mi1d99dDY1nvblJax21HLGuPdO2YyDUmc2yeY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=tRCXAR8Kqb9TihmJJUGHbnArjM1B8EjnEJvgTYqdEkPVqmfCN9oXAGwQk76uCdIT1 hf9tzm02iHU1EL2VHoS9cyhDoQk/LJff20SIjZh09f9qfRuLemNjriKiVzvRjfrlCW iD8wrNiPrNQf6S94/qgu/bOyS9ZaJZdKYk837B/4bX0hceyLIQW9bPhR35oAVBUkdS B042c2AqaSMcSyuhcFZ4xTwnesNJbDzGpIB62UYfSkKTgr5eNKdyBwKufIx49Ij+9K JJ0VKcRtqOCclxDHYUNvWvj3WpBPac9L0hyVEEXQIC6TLAQ4nkUCkPeo4qTq28Ap61 t5AiHZOf9iBuQ== Message-ID: <5587F54A.9050406@sunriseroad.net> Date: Mon, 22 Jun 2015 21:45:14 +1000 From: Jeremy Visser User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5587EFDD.6030807@gmail.com> In-Reply-To: <5587EFDD.6030807@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 11:45:20 -0000 On 22/06/15 21:22, Alexandru Petrescu wrote: > It is better to tell the operator to provide a /63 to smartphones (not a > /64), with DHCPv6 Prefix Delegation. That will fix it. Why stop at /63? If you can think of a use for two subnets, I can think of a use for three. Or four. Or sixteen. Or two hundred and fifty-six... From nobody Mon Jun 22 05:04:08 2015 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 2CC0D1A0199 for ; Mon, 22 Jun 2015 05:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 LxNB2ibzIHl9 for ; Mon, 22 Jun 2015 05:04:01 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 F13AF1A01CB for ; Mon, 22 Jun 2015 05:03:56 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 654516077C for ; Mon, 22 Jun 2015 14:03:54 +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 1EBC76029D for ; Mon, 22 Jun 2015 14:03:54 +0200 (CEST) Received: (qmail 4710 invoked by uid 1007); 22 Jun 2015 14:03:54 +0200 Date: Mon, 22 Jun 2015 14:03:54 +0200 From: Gert Doering To: Jeremy Visser Message-ID: <20150622120354.GG67883@Space.Net> References: <5587EFDD.6030807@gmail.com> <5587F54A.9050406@sunriseroad.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5587F54A.9050406@sunriseroad.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 12:04:07 -0000 Hi, On Mon, Jun 22, 2015 at 09:45:14PM +1000, Jeremy Visser wrote: > I can think of a use for three. [..] Or two hundred and fifty-six... You can? 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 Mon Jun 22 05:13:39 2015 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 648611A0368 for ; Mon, 22 Jun 2015 05:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.612 X-Spam-Level: X-Spam-Status: No, score=-12.612 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 c-umHRdlaQz7 for ; Mon, 22 Jun 2015 05:13:37 -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 425471A0358 for ; Mon, 22 Jun 2015 05:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1009; q=dns/txt; s=iport; t=1434975217; x=1436184817; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pnloHy6JDUfaXBpFfn18Dqxiaduwj+dpT1pACGtgidY=; b=JdyOQkIA0ly5ugLU3ZlEUMSetZ4/YCPVgeeExVx37EcuodjlmyL8L9Es TuXLvEh3A4II8F0sk9znEjdmOBRvTT2RQCnx7UAOW0G2Gwjlzp9dknGq8 4eiAo8aqf5dQ4iGEVSS9rCneuT3YWd0vunZmhnGMK/MZDyZoO9Uv8xwOX 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AvBAD1+odV/5xdJa1cgxCBMwa+AQmHXgKBMjgUAQEBAQEBAYEKhCIBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiIJ8k0AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tFhFU4BoMRgRQBBJN9AaN+JoN5b4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,659,1427760000"; d="scan'208";a="161459361" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 22 Jun 2015 12:13:36 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t5MCDaJf020192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jun 2015 12:13:36 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 07:13:36 -0500 From: "Hemant Singh (shemant)" To: Jeremy Visser , "v6ops@ietf.org" Thread-Topic: [v6ops] Apple and IPv6, a few clarifications - 64share Thread-Index: AQHQrN24pinb6cqb6Eq6EbqjHCiHuJ24u+QA//+yDjA= Date: Mon, 22 Jun 2015 12:13:35 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168A9D5E@xmb-rcd-x06.cisco.com> References: <5587EFDD.6030807@gmail.com> <5587F54A.9050406@sunriseroad.net> In-Reply-To: <5587F54A.9050406@sunriseroad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 12:13:38 -0000 -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeremy Visser Sent: Monday, June 22, 2015 7:45 AM To: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share >Why stop at /63? >If you can think of a use for two subnets, I can think of a use for three.= Or four. Or sixteen. Or two hundred and fifty-six... Also, if the phone uses DHCPv6 PD, then the phone's interface is a requesti= ng router as per RFC3633. Note, the IPv6 CE Router document in RFC7084 and= its WPD-2 bullet. One should round off prefix length to the nearest nibbl= e. Thus use a /60. Additionally, since the phone has disparate transpor= t interfaces in cellular and wifi to forward traffic between, it is best to= use routing between the two interfaces. See what subset of rfc7084 can be= used in the phone. Additionally, an IPv6 CE router implementation is avai= lable on Linux in OpenWRT for Linksys routers.=20 Thanks, Hemant From nobody Mon Jun 22 05:16:55 2015 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 498CA1A03F9 for ; Mon, 22 Jun 2015 05:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jEockLPXcHaO for ; Mon, 22 Jun 2015 05:16:52 -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 53B0B1A03A0 for ; Mon, 22 Jun 2015 05:16:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1A03EA3; Mon, 22 Jun 2015 14:16:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1434975410; bh=SB7GhuNlTiYMGQhUzxEZRj8b4K5cCMCx2/nZlOn13vU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=L+NFZJSigibrzaOtaaXSGDpjGWwzCdzKrVpCxEzh1K3SFh7SKsdpDNFkAGViPTpti vrZlyocOd+xLsKBB3dg7bzMYEKTUWNPngOLx2RYGpDycn63FvEvSMCz86Aw0jR5r67 1DGr5EUeYyd6DblKCCRjYX8C4t/XzhzFoKYIFBCM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0EC94A2; Mon, 22 Jun 2015 14:16:50 +0200 (CEST) Date: Mon, 22 Jun 2015 14:16:50 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <5587EFDD.6030807@gmail.com> Message-ID: References: <5587EFDD.6030807@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; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 12:16:54 -0000 On Mon, 22 Jun 2015, Alexandru Petrescu wrote: > It is better to tell the operator to provide a /63 to smartphones (not a > /64), with DHCPv6 Prefix Delegation. That will fix it. DHCPv6-PD exists in recent 3GPP documents, but vendor implementation of this is not wide-spread. We do *not* want to gate IPv6 rollout in mobile networks on this functionality. Yes, we want it, but we can't wait for it. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Jun 22 05:24:45 2015 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 38EBB1A1A8B for ; Mon, 22 Jun 2015 05:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 rrpQi2ZrYxNJ for ; Mon, 22 Jun 2015 05:24:43 -0700 (PDT) Received: from mail16.svc.cra.dublin.eircom.net (mail16.svc.cra.dublin.eircom.net [159.134.118.215]) by ietfa.amsl.com (Postfix) with SMTP id 2D63A1A1A76 for ; Mon, 22 Jun 2015 05:24:42 -0700 (PDT) Received: (qmail 17220 messnum 3238997 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 22 Jun 2015 12:24:42 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail16.svc.cra.dublin.eircom.net (qp 17220) with SMTP; 22 Jun 2015 12:24:42 -0000 Received: from [192.168.1.2] ([95.44.35.164]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id jQQb1q0023YUviP01QQef2; Mon, 22 Jun 2015 13:24:38 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: Date: Mon, 22 Jun 2015 13:24:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5587EFDD.6030807@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 12:24:45 -0000 > On 22 Jun 2015, at 13:16, Mikael Abrahamsson wrote: >=20 > On Mon, 22 Jun 2015, Alexandru Petrescu wrote: >=20 >> It is better to tell the operator to provide a /63 to smartphones = (not a /64), with DHCPv6 Prefix Delegation. That will fix it. >=20 > DHCPv6-PD exists in recent 3GPP documents, but vendor implementation = of this is not wide-spread. We do *not* want to gate IPv6 rollout in = mobile networks on this functionality. Yes, we want it, but we can=E2=80=99= t wait for it. Agreed. Also L2 bridging and 64share can be used to simultaneously = provide IPv6 over WiFi, Bluetooth, and wired Ethernet. Ross= From nobody Mon Jun 22 07:01:56 2015 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 845161A9150 for ; Mon, 22 Jun 2015 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 SNc1JXwg0yJa for ; Mon, 22 Jun 2015 07:01:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F8C1A9031 for ; Mon, 22 Jun 2015 07:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=966; q=dns/txt; s=iport; t=1434981714; x=1436191314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Fw1CT1B3z/iDMOIx9EKr05ba38EFxPowgIFtxlnG2Fs=; b=I5z+jXkQeM6X1j0/QCjq+0qoJqLzu4UJfjCcwsuugiQuEFAXc+lkLe53 sdOoBpO1zmlvFUlUE4Qsmo8vM47vuklP39w/KHE0H0CaZ0S4HgylkVJJC i9jCKYYwL974s2qrejrrzdghXhJEaL0qzH4L+JCvOjATxYP6NDwCIUwE3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmBQC2FIhV/4ENJK1cgxCBMwaDGLp1h14CHIEYORMBAQEBAQEBgQqEIgEBAQQjEUUMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQBDQUIiCezZ5YKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiSEVTEHBoJiL4EUAQSTfQGNB4QNkmomg3lvgUaBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,659,1427760000"; d="scan'208";a="5528759" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 22 Jun 2015 14:01:53 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5ME1qLo022054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jun 2015 14:01:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 09:01:52 -0500 From: "Hemant Singh (shemant)" To: Ross Chandler , Mikael Abrahamsson Thread-Topic: [v6ops] Apple and IPv6, a few clarifications - 64share Thread-Index: AQHQrN24pinb6cqb6Eq6EbqjHCiHuJ24xLgAgAACKoD//8a7cA== Date: Mon, 22 Jun 2015 14:01:52 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168A9E06@xmb-rcd-x06.cisco.com> References: <5587EFDD.6030807@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.110] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 14:01:54 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvc3MgQ2hhbmRsZXINClNlbnQ6IE1vbmRheSwg SnVuZSAyMiwgMjAxNSA4OjI1IEFNDQpUbzogTWlrYWVsIEFicmFoYW1zc29uDQpDYzogdjZvcHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEFwcGxlIGFuZCBJUHY2LCBhIGZldyBjbGFy aWZpY2F0aW9ucyAtIDY0c2hhcmUNCg0KPkFncmVlZC4gQWxzbyBMMiBicmlkZ2luZyBhbmQgNjRz aGFyZSBjYW4gYmUgdXNlZCB0byBzaW11bHRhbmVvdXNseSBwcm92aWRlIElQdjYgb3ZlciBXaUZp LCBCbHVldG9vdGgsIGFuZCB3aXJlZCBFdGhlcm5ldC4NCg0KUGxlYXNlIGdvIGJhY2sgdG8gdjZv cHMgbWFpbGVyIGFyY2hpdmUgYW5kIHNlZSBzb21ldGltZSBiZXR3ZWVuIDIwMDgtMjAxMCB3ZSBo YXZlIGFscmVhZHkgY29tbWVudGVkIG9uIGEgY2VsbHVsYXIgcGhvbmUgc3VwcG9ydGluZyBicmlk Z2luZy4gICBUaGVuIG9uZSdzIGhvbWUgVFYgc3VjaCBhcyBBcHBsZSBUViBwYWNrZXRzIGxlYWsg ZnJvbSB0aGUgd2lmaSB0byB0aGUgY2VsbHVsYXIgbmV0d29yayB2aWEgdGhlIGJyaWRnaW5nIG9u IHRoZSBwaG9uZS4gIE5vdyBvbmUganVzdCBjbG9nZ2VkIHRoZSBjZWxsdWxhciBuZXR3b3JrIHdp dGggdmlkZW8uDQoNCkhlbWFudA0K From nobody Mon Jun 22 07:28:19 2015 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 A63311ACD66 for ; Mon, 22 Jun 2015 07:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.337 X-Spam-Level: * X-Spam-Status: No, score=1.337 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 cYqfZ-Pi7Uu2 for ; Mon, 22 Jun 2015 07:28:14 -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 429A51AC3EF for ; Mon, 22 Jun 2015 07:28:13 -0700 (PDT) Received: (qmail 10182 messnum 310191 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 22 Jun 2015 14:28:12 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail19.svc.cra.dublin.eircom.net (qp 10182) with SMTP; 22 Jun 2015 14:28:12 -0000 Received: from [192.168.1.2] ([95.44.35.164]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id jSU81q0103YUviP01SUCsK; Mon, 22 Jun 2015 15:28:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89168A9E06@xmb-rcd-x06.cisco.com> Date: Mon, 22 Jun 2015 15:28:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E9A1FA2-6C5E-4526-8BDF-76AC5D9F3B3E@eircom.net> References: <5587EFDD.6030807@gmail.com> <75B6FA9F576969419E42BECB86CB1B89168A9E06@xmb-rcd-x06.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 14:28:16 -0000 > On 22 Jun 2015, at 15:01, Hemant Singh (shemant) = wrote: >=20 > Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share >=20 >> Agreed. Also L2 bridging and 64share can be used to simultaneously = provide IPv6 over WiFi, Bluetooth, and wired Ethernet. >=20 > Please go back to v6ops mailer archive and see sometime between = 2008-2010 we have already commented on a cellular phone supporting = bridging. Then one's home TV such as Apple TV packets leak from the = wifi to the cellular network via the bridging on the phone. Now one = just clogged the cellular network with video. >=20 Are you arguing for DHCPv6-PD prior to the stopgap of L2 bridging and = 64share? I=E2=80=99ve seen this implemented in UEs. Ross= From nobody Mon Jun 22 07:33:31 2015 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 469BC1ACD7A for ; Mon, 22 Jun 2015 07:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] 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 sNrxnu6oyHiU for ; Mon, 22 Jun 2015 07:33:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97D71ACD76 for ; Mon, 22 Jun 2015 07:33:27 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:1958:7c15:b74f:e647] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MEWDq6030165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2015 16:32:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 22 Jun 2015 16:33:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90744458-CA06-4347-A96B-D649800855D3@muada.com> References: To: David Schinazi X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org, Vividh Siddha Subject: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 14:33:29 -0000 On 19 Jun 2015, at 23:46, David Schinazi wrote: > *) Happy Eyeballs > We've heard feedback on our Happy Eyeballs implementation and are = investigating > this topic. > Note that this reflects how these technologies work in the current = versions of the > 2015 betas, many of these details could change in future betas. Please = keep in mind > that these betas are previews and we welcome feedback on improving = them. > Feel free to contact me if you have any questions, I will also attend = IETF93. Ok, here's some feedback on happy eyeballs, to the list so maybe others = can improve upon it. It would be extremely useful to be able to temporarily force IPv6 first = or IPv4 first rather than have happy eyeballs for testing purposes. At NANOG and the RIPE meeting recently, people have presented results = that show that IPv6 frequently performs better than IPv4, although the = RTT isn't better. It's unclear why this is, but my theory is that the = correlation between networks with good performance and networks with = IPv6 enabled is high and thus sometimes the IPv4 path goes through a = "bad" IPv4-only network which obviously isn't available to IPv6 packets, = which then flow through an alternative IPv6-enabled path over a "good" = network. The extra 20 bytes of IPv6 header add about 25% to a SYN while data = packets are the same 1500 bytes. So if you guys currently look at the = RTT for the three-way handshake, it would probably help if you could = look at the RTT for data packets instead. And maybe the RTT is the same but the (congestion) window is smaller on = IPv4. Perhaps a NAT messes with the window scale option? So maybe look = at the IPv4 vs IPv6 window sizes. I would suggest something along these = lines: if v4RTT < v6RTT - 25 then return IPv4 if v4window / v4RTT > v6window / v6RTT * 1.2 then return IPv4 return IPv6 About the test DNS64/NAT64 implementation: Obviously the test network isn't a "real" NAT64 test network when = there's no native IPv6 present. And obviously there's no easy way to = have native IPv6 materialize out of thin air. But someone who wants to = test more thoroughly may want to get native IPv6 or set up a tunnel = broker tunnel. It would be nice if the test NAT64 setup could work with = that, so the devices on the test network can connect to IPv6 = destinations over IPv6 and IPv4 destinations through the NAT64. Basically, what's needed for this is that if the interface in question = is configured with "real" IPv6 addresses, those are kept and the prefix = in question is advertised in RAs.= From nobody Mon Jun 22 07:47:42 2015 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 6C4211ACDB4 for ; Mon, 22 Jun 2015 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 n9zdh-lrMbdM for ; Mon, 22 Jun 2015 07:47:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599551ACDB6 for ; Mon, 22 Jun 2015 07:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1298; q=dns/txt; s=iport; t=1434984460; x=1436194060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kytHmJsoXNoSU5qLDRYmELlLUsWyczdNW93+1SSK8Wk=; b=Opt07VOT9lsKNmXG9l5fW+OHuZw8Uurl3EVZLex8mX/Hl5Cyr5uLrs/Z BTUs1rdEmGJMTdW08enPd6yUCDEhySsUD81PNKXWgeyhxQPRPEu0POr62 r7Tz/89xZSVyDD2vOQj236vux/KxjGIcTCR6n/gaZbFeI5x73hKvdkyP5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmBQBJH4hV/4UNJK1cgxCBMwaDGLp2h14CHIEcORMBAQEBAQEBgQqEIgEBAQQjEUUMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQOBQiIEgMSs3uQIgqFXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYokhFUWGwcGgmIvgRQBBJN9AaN+JoN5b4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,659,1427760000"; d="scan'208";a="161736163" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP; 22 Jun 2015 14:47:39 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5MEldWt005361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jun 2015 14:47:39 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 09:47:39 -0500 From: "Hemant Singh (shemant)" To: Ross Chandler Thread-Topic: [v6ops] Apple and IPv6, a few clarifications - 64share Thread-Index: AQHQrN24pinb6cqb6Eq6EbqjHCiHuJ24xLgAgAACKoD//8a7cIAAW8oA//+vDLA= Date: Mon, 22 Jun 2015 14:47:38 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168A9E9E@xmb-rcd-x06.cisco.com> References: <5587EFDD.6030807@gmail.com> <75B6FA9F576969419E42BECB86CB1B89168A9E06@xmb-rcd-x06.cisco.com> <0E9A1FA2-6C5E-4526-8BDF-76AC5D9F3B3E@eircom.net> In-Reply-To: <0E9A1FA2-6C5E-4526-8BDF-76AC5D9F3B3E@eircom.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.110] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 14:47:41 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvc3MgQ2hhbmRsZXIgW21haWx0bzpy b3NzQGVpcmNvbS5uZXRdIA0KU2VudDogTW9uZGF5LCBKdW5lIDIyLCAyMDE1IDEwOjI4IEFNDQpU bzogSGVtYW50IFNpbmdoIChzaGVtYW50KQ0KQ2M6IE1pa2FlbCBBYnJhaGFtc3NvbjsgdjZvcHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEFwcGxlIGFuZCBJUHY2LCBhIGZldyBjbGFy aWZpY2F0aW9ucyAtIDY0c2hhcmUNCg0KPkFyZSB5b3UgYXJndWluZyBmb3IgREhDUHY2LVBEIHBy aW9yIHRvIHRoZSBzdG9wZ2FwIG9mIEwyIGJyaWRnaW5nIGFuZCA2NHNoYXJlPyBJ4oCZdmUgc2Vl biB0aGlzIGltcGxlbWVudGVkIGluIFVFcy4NCg0KSXQncyB1cCB0byB0aGUgcHJvdmlkZXIgdG8g ZGVwbG95IHdoYXQgdGhleSBjaG9vc2UgdG8gZGVwbG95LiAgIEkgYW0gb25seSBkaXNjdXNzaW5n IHBpdGZhbGxzIHdpdGggZWFjaCB0ZWNoIGJlaW5nIGNvbnNpZGVyZWQgZm9yIGRlcGxveW1lbnQu ICBJIGRvIGhhdmUgYSBwcmVmZXJlbmNlIGZvciBESENQdjYgUEQgYW5kIHJvdXRpbmcuICBUaGUg cmVhc29uIGlzIERIQ1B2NiBQRCBhbmQgSVB2NiBDRSByb3V0ZXIgY2FuIHN1cHBvcnQgYWxsIG9m IHdpZmksIEJsdWV0b290aCwgZXRjLiAgQWRkaXRpb25hbGx5LCBkZXZpY2VzIHN1Y2ggYXMgQXBw bGUgVFYgaW4gdGhlIGhvbWUgY2FuIGJlIGFzc2lnbmVkIFVMQXMgd2hpY2ggdGhlIHJvdXRlciBv biB0aGUgcGhvbmUgd2lsbCBuZXZlciBmb3J3YXJkIHRvIHRoZSBXQU4gLSB0aHVzIG5vIHZpZGVv IGZyb20gdGhlIGhvbWUgbGVha3MgdG8gdGhlIGNlbGx1bGFyIG5ldHdvcmsuICBJIHdpbGwgbmV2 ZXIgY29uc2lkZXIgYSB0ZWNobm9sb2d5IHRoYXQgbGVha3MgYSBob21lJ3MgIFRWIHZpZGVvIHRv IHRoZSBjZWxsdWxhciBuZXR3b3JrLiAgDQoNCkhlbWFudA0K From nobody Mon Jun 22 08:11:29 2015 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 B0F481ACE27 for ; Mon, 22 Jun 2015 08:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 28JOOalAKoqr for ; Mon, 22 Jun 2015 08:11:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FB21ACE1B for ; Mon, 22 Jun 2015 08:11:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5MFB7Xs011310; Mon, 22 Jun 2015 17:11:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4D1A3202C37; Mon, 22 Jun 2015 17:14:00 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 35AFF202B33; Mon, 22 Jun 2015 17:14:00 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5MFB33O031222; Mon, 22 Jun 2015 17:11:07 +0200 Message-ID: <55882587.6030702@gmail.com> Date: Mon, 22 Jun 2015 17:11:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ross Chandler , Mikael Abrahamsson References: <5587EFDD.6030807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 15:11:22 -0000 Le 22/06/2015 14:24, Ross Chandler a écrit : > >> On 22 Jun 2015, at 13:16, Mikael Abrahamsson >> wrote: >> >> On Mon, 22 Jun 2015, Alexandru Petrescu wrote: >> >>> It is better to tell the operator to provide a /63 to >>> smartphones (not a /64), with DHCPv6 Prefix Delegation. That >>> will fix it. >> >> DHCPv6-PD exists in recent 3GPP documents, but vendor >> implementation of this is not wide-spread. We do *not* want to >> gate IPv6 rollout in mobile networks on this functionality. Yes, we >> want it, but we can’t wait for it. > > Agreed. Also L2 bridging and 64share can be used to simultaneously > provide IPv6 over WiFi, Bluetooth, and wired Ethernet. Yes, some can be bridged. But only the bridgeable links can be bridged (802) - serial, CAN, USB, wont bridge. Some subnets could bridge yet won't - in order to avoid noise (safety vs entertainment). Some subnets route (not bridge) for scalability reasons. Alex > > Ross > From nobody Mon Jun 22 08:21:20 2015 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 B96FF1ACE1A for ; Mon, 22 Jun 2015 08:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 fGs1CCDh08UA for ; Mon, 22 Jun 2015 08:21:13 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEC11ACE20 for ; Mon, 22 Jun 2015 08:21:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5MFLA3e024491 for ; Mon, 22 Jun 2015 17:21:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9168D202CD5 for ; Mon, 22 Jun 2015 17:24:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7F531202A54 for ; Mon, 22 Jun 2015 17:24:03 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5MFL7kQ008707 for ; Mon, 22 Jun 2015 17:21:10 +0200 Message-ID: <558827E2.9000104@gmail.com> Date: Mon, 22 Jun 2015 17:21:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5587EFDD.6030807@gmail.com> <5587F54A.9050406@sunriseroad.net> In-Reply-To: <5587F54A.9050406@sunriseroad.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 15:21:18 -0000 Le 22/06/2015 13:45, Jeremy Visser a écrit : > On 22/06/15 21:22, Alexandru Petrescu wrote: >> It is better to tell the operator to provide a /63 to smartphones >> (not a /64), with DHCPv6 Prefix Delegation. That will fix it. > > Why stop at /63? I think cellular network architects are reluctant to leap from 64 to 63. Once that leap is overcome the other prefix lenghs are just small steps. > If you can think of a use for two subnets, I can think of a use for > three. Or four. Or sixteen. Or two hundred and fifty-six... YEs, in a sense. Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Mon Jun 22 09:49:07 2015 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 88AEB1B304C for ; Mon, 22 Jun 2015 09:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.388 X-Spam-Level: * X-Spam-Status: No, score=1.388 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Nd34RsnB80cW for ; Mon, 22 Jun 2015 09:49:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0CE1B304D for ; Mon, 22 Jun 2015 09:49:03 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5MGn2hi031195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 09:49:02 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <90744458-CA06-4347-A96B-D649800855D3@muada.com> Date: Mon, 22 Jun 2015 09:49:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 09:49:02 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org, Vividh Siddha Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 16:49:06 -0000 > On Jun 22, 2015, at 07:33 , Iljitsch van Beijnum = wrote: >=20 > On 19 Jun 2015, at 23:46, David Schinazi wrote: >=20 >> *) Happy Eyeballs >> We've heard feedback on our Happy Eyeballs implementation and are = investigating >> this topic. >=20 >> Note that this reflects how these technologies work in the current = versions of the >> 2015 betas, many of these details could change in future betas. = Please keep in mind >> that these betas are previews and we welcome feedback on improving = them. >=20 >> Feel free to contact me if you have any questions, I will also attend = IETF93. >=20 > Ok, here's some feedback on happy eyeballs, to the list so maybe = others can improve upon it. >=20 > It would be extremely useful to be able to temporarily force IPv6 = first or IPv4 first rather than have happy eyeballs for testing = purposes. >=20 > At NANOG and the RIPE meeting recently, people have presented results = that show that IPv6 frequently performs better than IPv4, although the = RTT isn't better. It's unclear why this is, but my theory is that the = correlation between networks with good performance and networks with = IPv6 enabled is high and thus sometimes the IPv4 path goes through a = "bad" IPv4-only network which obviously isn't available to IPv6 packets, = which then flow through an alternative IPv6-enabled path over a "good" = network. >=20 > The extra 20 bytes of IPv6 header add about 25% to a SYN while data = packets are the same 1500 bytes. So if you guys currently look at the = RTT for the three-way handshake, it would probably help if you could = look at the RTT for data packets instead. Pretty hard to look at the data RTT when establishing a connection. How = do you see that working? > And maybe the RTT is the same but the (congestion) window is smaller = on IPv4. Perhaps a NAT messes with the window scale option? So maybe = look at the IPv4 vs IPv6 window sizes. I would suggest something along = these lines: >=20 > if v4RTT < v6RTT - 25 then return IPv4 > if v4window / v4RTT > v6window / v6RTT * 1.2 then return IPv4 > return IPv6 This may well have some merit. > About the test DNS64/NAT64 implementation: >=20 > Obviously the test network isn't a "real" NAT64 test network when = there's no native IPv6 present. And obviously there's no easy way to = have native IPv6 materialize out of thin air. But someone who wants to = test more thoroughly may want to get native IPv6 or set up a tunnel = broker tunnel. It would be nice if the test NAT64 setup could work with = that, so the devices on the test network can connect to IPv6 = destinations over IPv6 and IPv4 destinations through the NAT64. +1 > Basically, what's needed for this is that if the interface in question = is configured with "real" IPv6 addresses, those are kept and the prefix = in question is advertised in RAs. Wouldn=E2=80=99t that require bridging to between the real interface and = the test interface rather than routing? Perhaps that=E2=80=99s not a bad = idea, (the kernel already has the necessary bridging code), but a = consistent and deterministic way of selecting bridge vs. route would be = necessary to create a full test environment, IMHO. Owen From nobody Mon Jun 22 09:53:34 2015 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 8724D1B3060 for ; Mon, 22 Jun 2015 09:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 2KdnFWPf6v2c for ; Mon, 22 Jun 2015 09:53:31 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1B21AD2D9 for ; Mon, 22 Jun 2015 09:53:31 -0700 (PDT) Received: by iebrt9 with SMTP id rt9so8312728ieb.2 for ; Mon, 22 Jun 2015 09:53:30 -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; bh=2s45mn4ykd3maBZoNnPZQAHneZUNPr9QkddaCq0Ii0o=; b=lhUOFyCV+l2BxfFmF5fDcRCt65SGmdL6z2PKS/VsJrJIfK+2WMc0Rbt0Nbo7+4BIii wo21t1iTZiE5WETx75ZllqyMPcyXYQNAZhTK5NZifQdpJ1599k2F/u1LJoZLGwunzVk7 kkKRGpggMAVaB+mjIyIClEQ40se9e2koIKggHOycnQkbhzF3zbmckLzPGVEo5wtttysq 4qQ3RUWjQ063cEDOq3PbgWtAJgbEFbz0O2gO0SN6CBZ6qnlPP+G8T6YQOHOOSYOpqNxO 1CnUauwyiRt5wFR/Au14txy28qopCRQKL/M+6SnMF/5w5o2hO4TC67IZBT3icvTQRVLa G99w== MIME-Version: 1.0 X-Received: by 10.107.7.142 with SMTP id g14mr20455095ioi.21.1434992010582; Mon, 22 Jun 2015 09:53:30 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.79.68.66 with HTTP; Mon, 22 Jun 2015 09:53:30 -0700 (PDT) In-Reply-To: <90744458-CA06-4347-A96B-D649800855D3@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> Date: Mon, 22 Jun 2015 12:53:30 -0400 X-Google-Sender-Auth: LyLdyC6zuckvwaMFvBAXPaFxapQ Message-ID: From: Erik Nygren To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=001a113fb64e0be16d05191e1d20 Archived-At: Cc: "v6ops@ietf.org" , Vividh Siddha Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 16:53:32 -0000 --001a113fb64e0be16d05191e1d20 Content-Type: text/plain; charset=UTF-8 +1 to this Having the NAT64/DNS64 environment is great for IPv6-only testing, but if it doesn't provide the ability to get through to real IPv6 content/resources when the MacOS host has IPv6 connectivity (either natively or via a tunnel) then it could be counter-productive in some circumstances and could discourage app writers from developing their apps to work well in scenarios where true end-to-end IPv6 connectivity is possible. Engineering and QA teams may instead focus purely on playing well with NAT64/DNS64 than on also being able to avoid the NAT64 entirely (which is clearly desirable for end-user performance.) Erik On Mon, Jun 22, 2015 at 10:33 AM, Iljitsch van Beijnum wrote: > About the test DNS64/NAT64 implementation: > > Obviously the test network isn't a "real" NAT64 test network when there's > no native IPv6 present. And obviously there's no easy way to have native > IPv6 materialize out of thin air. But someone who wants to test more > thoroughly may want to get native IPv6 or set up a tunnel broker tunnel. It > would be nice if the test NAT64 setup could work with that, so the devices > on the test network can connect to IPv6 destinations over IPv6 and IPv4 > destinations through the NAT64. > > Basically, what's needed for this is that if the interface in question is > configured with "real" IPv6 addresses, those are kept and the prefix in > question is advertised in RAs. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113fb64e0be16d05191e1d20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to this

Having the NAT64/DNS64 e= nvironment is great for IPv6-only testing, but if it doesn't provide th= e ability to get through to real IPv6 content/resources when the MacOS host= has IPv6 connectivity (either natively or via a tunnel) then it could be c= ounter-productive in some circumstances and could discourage app writers fr= om developing their apps to work well in scenarios where true end-to-end IP= v6 connectivity is possible.=C2=A0 Engineering and QA teams may instead foc= us purely on playing well with NAT64/DNS64 than on also being able to avoid= the NAT64 entirely (which is clearly desirable for end-user performance.)<= br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


On Mon, Ju= n 22, 2015 at 10:33 AM, Iljitsch van Beijnum <iljitsch@muada.com>= wrote:
About the test DNS64/NAT64= implementation:

Obviously the test network isn't a "real" NAT64 test network = when there's no native IPv6 present. And obviously there's no easy = way to have native IPv6 materialize out of thin air. But someone who wants = to test more thoroughly may want to get native IPv6 or set up a tunnel brok= er tunnel. It would be nice if the test NAT64 setup could work with that, s= o the devices on the test network can connect to IPv6 destinations over IPv= 6 and IPv4 destinations through the NAT64.

Basically, what's needed for this is that if the interface in question = is configured with "real" IPv6 addresses, those are kept and the = prefix in question is advertised in RAs.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--001a113fb64e0be16d05191e1d20-- From nobody Mon Jun 22 10:01:28 2015 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 853DD1B304F for ; Mon, 22 Jun 2015 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.589 X-Spam-Level: * X-Spam-Status: No, score=1.589 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 y_WYOrNC6WGQ for ; Mon, 22 Jun 2015 10:01:26 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 19AEF1B29D4 for ; Mon, 22 Jun 2015 10:01:26 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5MH1Nb3000991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 10:01:24 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <5587EFDD.6030807@gmail.com> Date: Mon, 22 Jun 2015 10:01:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com> References: <5587EFDD.6030807@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 10:01:24 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 17:01:27 -0000 > On Jun 22, 2015, at 04:22 , Alexandru Petrescu = wrote: >=20 > Hi, >=20 > Thanks for the report. I have a few comments. >=20 > Le 19/06/2015 23:46, David Schinazi a =E9crit : > [...] >> *) Personal hotspot on iOS If your iPhone has dual-stack connectivity >> on its cellular network, the hotspot it creates will be dual-stack as >> well. The phone will share its prefix with Wi-Fi clients. >=20 > The way of sharing a prefix with the Wi-Fi Clients is supposedly the = one > documented in RFC7278 "Extending an IPv6 /64 Prefix from a Third > Generation Partnership Project (3GPP) Mobile Interface to a LAN Link" > https://tools.ietf.org/html/rfc7278 >=20 > That is straightforward to implement yet it does have some drawbacks. >=20 > The most important drawback of 64share IMHO is that the smartphone can = not make two hotspots simultaneouly: one on WiFi and one on Bluetooth. = Or otherwise one on WiFi5GHz and one on WiFi2.4GHz. Or several subnets = in a car connected with an Apple phone to the Internet. Because it is = impossible to share a unique /64 prefix to more than just one subnet. Not entirely true. True, you cannot have multiple subnets. This is true = in any situation where the device in question receives only one /64 = (unless you make absurd small subnets). However, in the case of hotspot on 5, 2.4, and BT, as long as the phone = can bridge them all together as a single subnet, that=92s perfectly = viable. If the phone wants to treat them as routed interfaces, then it = breaks. >=20 > It is better to tell the operator to provide a /63 to smartphones (not = a > /64), with DHCPv6 Prefix Delegation. That will fix it. No=85 If you=92re going to go to PD, a /63 is stupid. Ideally, use a = /48, but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz = plus some headroom for future applications. >> *) Internet Sharing on the Mac Today, regular internet sharing (from >> your ethernet to Wi-Fi for example) does not support IPv6 because of >> the limited use cases, and the lack of demand for it. >=20 > If you get done the above then you get Internet Sharing on the Mac = Today > as well, for free. Since iOS and OSX are separate code bases, I=92m not sure why you think = that. >> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 test >> mode was designed to help developers ensure that their app can still >> function with IPv6-only NAT64+DNS64 connectivity and communicate with >> their IPv4 server, even if the developer does not have access to the >> IPv6 internet. That NAT64 network does not have IPv6 connectivity to >> the global IPv6 internet. As such, the current version advertises >> addresses from 2001::/64 instead of ULAs to simulate real IPv6 >> connectivity, as all IPv6 packets are terminated at the NAT64 server >> on the Mac. This implementation detail could change in the future. >=20 > Makes sense. >=20 Not really=85 This address is currently in the IANA free pool. It could = be assigned to an RIR and then put on a real network at any point in the future. It would be much better to use a /64 Apple can set aside from their own = space or some other block of addresses registered for this purpose=85 Heck, = worst case, Apple could sign up for a free tunnel from HE and burn the /64 assigned to that tunnel. Ideally, the prefix should be user configurable as well. > Alex >=20 >> *) Making IPv4 literals work on NAT64 networks when using high-level >> APIs Starting with this year's versions, if you use NSURLSession to >> connect to an IPv4 literal on an IPv6-only NAT64-DNS64 network, the >> API will bump in a IPv6 literal synthesized using RFC 7050. Note >> that this will not happen when using sockets directly. We do not >> support under-the-sockets bump-in-API (RFC 3338) and we do not >> support 464XLAT. They really should support 464XLAT at this point IMHO, though some of what they are doing may obviate or lessen the need. It will be = interesting to see if this is sufficient for T-Mo to finally turn on IPv6 for my = phone. Ideally, T-Mo should pull their head out of their ass about dual-stack = and Apple should pull their head out of their ass about 464XLAT, but either one would meet my immediate needs. Unfortunately, they=92re both sitting there playing internet chicken waiting for the other one to blink. Given the number of other cellular networks that are following the same path as T-Mo, I think mass is on their side, but Apple may be too = stubborn to blink and a head-on may be inevitable. Unfortunately, it=92s the end-users that will be the victims in this = crash, not the drivers. Owen From nobody Mon Jun 22 10:06:35 2015 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 032551B307D for ; Mon, 22 Jun 2015 10:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.589 X-Spam-Level: * X-Spam-Status: No, score=1.589 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QzPJTuTHCtZc for ; Mon, 22 Jun 2015 10:06:33 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2501A1C03 for ; Mon, 22 Jun 2015 10:06:33 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5MH6N4P002092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 10:06:24 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89168A9E9E@xmb-rcd-x06.cisco.com> Date: Mon, 22 Jun 2015 10:06:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18D137E7-FC14-4547-A944-34099BC3C4C8@delong.com> References: <5587EFDD.6030807@gmail.com> <75B6FA9F576969419E42BECB86CB1B89168A9E06@xmb-rcd-x06.cisco.com> <0E9A1FA2-6C5E-4526-8BDF-76AC5D9F3B3E@eircom.net> <75B6FA9F576969419E42BECB86CB1B89168A9E9E@xmb-rcd-x06.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 10:06:24 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 17:06:34 -0000 > On Jun 22, 2015, at 07:47 , Hemant Singh (shemant) = wrote: >=20 > -----Original Message----- > From: Ross Chandler [mailto:ross@eircom.net]=20 > Sent: Monday, June 22, 2015 10:28 AM > To: Hemant Singh (shemant) > Cc: Mikael Abrahamsson; v6ops@ietf.org > Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share >=20 >> Are you arguing for DHCPv6-PD prior to the stopgap of L2 bridging and = 64share? I=E2=80=99ve seen this implemented in UEs. >=20 > It's up to the provider to deploy what they choose to deploy. I am = only discussing pitfalls with each tech being considered for deployment. = I do have a preference for DHCPv6 PD and routing. The reason is DHCPv6 = PD and IPv6 CE router can support all of wifi, Bluetooth, etc. = Additionally, devices such as Apple TV in the home can be assigned ULAs = which the router on the phone will never forward to the WAN - thus no = video from the home leaks to the cellular network. I will never = consider a technology that leaks a home's TV video to the cellular = network. =20 Why not? I=E2=80=99m pretty annoyed that I have to use the HTTP = interface and wifi hotspot on my phone rather than the iOS App to pull = video off of my TiVO when I=E2=80=99m not home. Mostly this is because TiVO has their head up their ass about thinking: 1. All homes have one and only one broadcast domain. 2. TiVO won=E2=80=99t use the cellular interface on an iOS = device. (It will connect over wifi just fine). Sometimes I use one iOS device in hotspot mode to watch video on another = which thinks it=E2=80=99s on wifi but is actually using the cellular = network from the first iOS device. All of these limitations on how I use the cellular bandwidth I pay for = are: 1) Silly 2) Annoying 3) Unnecessary Owen From nobody Mon Jun 22 13:08:06 2015 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 762AD1ACD24 for ; Mon, 22 Jun 2015 13:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.017 X-Spam-Level: ** X-Spam-Status: No, score=2.017 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 iVQt6p4IOZe6 for ; Mon, 22 Jun 2015 13:08:03 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA481ACDFA for ; Mon, 22 Jun 2015 13:08:03 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id C535E4C80E7; Mon, 22 Jun 2015 22:07:30 +0200 (CEST) From: Alexandru Petrescu To: Owen DeLong References: <5587EFDD.6030807@gmail.com> <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com> Message-ID: <55886B02.80604@gmail.com> Date: Mon, 22 Jun 2015 22:07:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 150501-0, 01/05/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 20:08:05 -0000 On 22/06/2015 19:01, Owen DeLong wrote: > >> On Jun 22, 2015, at 04:22 , Alexandru Petrescu >> wrote: >> >> Hi, >> >> Thanks for the report. I have a few comments. >> >> Le 19/06/2015 23:46, David Schinazi a écrit : [...] >>> *) Personal hotspot on iOS If your iPhone has dual-stack >>> connectivity on its cellular network, the hotspot it creates >>> will be dual-stack as well. The phone will share its prefix with >>> Wi-Fi clients. >> >> The way of sharing a prefix with the Wi-Fi Clients is supposedly >> the one documented in RFC7278 "Extending an IPv6 /64 Prefix from a >> Third Generation Partnership Project (3GPP) Mobile Interface to a >> LAN Link" https://tools.ietf.org/html/rfc7278 >> >> That is straightforward to implement yet it does have some >> drawbacks. >> >> The most important drawback of 64share IMHO is that the smartphone >> can not make two hotspots simultaneouly: one on WiFi and one on >> Bluetooth. Or otherwise one on WiFi5GHz and one on WiFi2.4GHz. Or >> several subnets in a car connected with an Apple phone to the >> Internet. Because it is impossible to share a unique /64 prefix >> to more than just one subnet. > > Not entirely true. True, you cannot have multiple subnets. This is > true in any situation where the device in question receives only one > /64 (unless you make absurd small subnets). > > However, in the case of hotspot on 5, 2.4, and BT, as long as the > phone can bridge them all together as a single subnet, that’s > perfectly viable. Yes. It can bridge those which are bridgeable. Bridging point-to-point bluetooth link to the dashboard and the broadcast WiFi car hotspot is not working. Safety and entertainment subnets in a car which must not be bridged for reliability reasons (don't noise the safety messages) - is not working either zith 64share. Bridging Bluetooth and WiFi ha no link-layer security. > If the phone wants to treat them as routed interfaces, then it > breaks. Yes, 64share breaks in routed subnets. >> It is better to tell the operator to provide a /63 to smartphones >> (not a /64), with DHCPv6 Prefix Delegation. That will fix it. > > No… If you’re going to go to PD, a /63 is stupid. Ideally, use a > /48, Well, one cellular network operator has a /47 to 'share' with all its customer UEs. If that operator gave a /48 to an UE it could satisfy only 2 such customers, not millions. > but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz > plus some headroom for future applications. I agree, headroom should be provided. >>> *) Internet Sharing on the Mac Today, regular internet sharing >>> (from your ethernet to Wi-Fi for example) does not support IPv6 >>> because of the limited use cases, and the lack of demand for it. >> >> If you get done the above then you get Internet Sharing on the Mac >> Today as well, for free. > > Since iOS and OSX are separate code bases, I’m not sure why you > think that. Because the DHCPv6 Prefix Delegation is a userspace application implementing a protocol - suffices it to compile on each of these code bases. It acts the same everywhere. It's not a GUI, or some kernel module, or some AF-dependent software. >>> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 >>> test mode was designed to help developers ensure that their app >>> can still function with IPv6-only NAT64+DNS64 connectivity and >>> communicate with their IPv4 server, even if the developer does >>> not have access to the IPv6 internet. That NAT64 network does >>> not have IPv6 connectivity to the global IPv6 internet. As such, >>> the current version advertises addresses from 2001::/64 instead >>> of ULAs to simulate real IPv6 connectivity, as all IPv6 packets >>> are terminated at the NAT64 server on the Mac. This >>> implementation detail could change in the future. >> >> Makes sense. >> > > Not really… This address is currently in the IANA free pool. It > could be assigned to an RIR and then put on a real network at any > point in the future. > > It would be much better to use a /64 Apple can set aside from their > own space or some other block of addresses registered for this > purpose… Heck, worst case, Apple could sign up for a free tunnel > from HE and burn the /64 assigned to that tunnel. > > Ideally, the prefix should be user configurable as well. I think I didnt read the message as you did. I assume by 2001::/64 is meant actually 2001::/3, or some other 2001:X:Y:U:Z::/64 that the operator prodived. I think it was said 2001::/3 to distiguish from ULA fd00::/something, and so I said it made sense. And, if what is said is really meaning 2001::/64 then I agree with you - that's at IANA and one wouldn't juggle with 2001::/64 just like that. If one wants to juggle with something then it's with fd00::/64 (ULA) and with 2001:db8::/32 (docu prefix). >>> *) Making IPv4 literals work on NAT64 networks when using >>> high-level APIs Starting with this year's versions, if you use >>> NSURLSession to connect to an IPv4 literal on an IPv6-only >>> NAT64-DNS64 network, the API will bump in a IPv6 literal >>> synthesized using RFC 7050. Note that this will not happen when >>> using sockets directly. We do not support under-the-sockets >>> bump-in-API (RFC 3338) and we do not support 464XLAT. > > They really should support 464XLAT at this point IMHO, though some of > what they are doing may obviate or lessen the need. It will be > interesting to see if this is sufficient for T-Mo to finally turn on > IPv6 for my phone. > > Ideally, T-Mo should pull their head out [...] about dual-stack and > Apple should pull their head out [...] about 464XLAT, but either one > would meet my immediate needs. I wouldnt put it that blunt. But I would agree that less transitioning be faster transition. > Unfortunately, they’re both sitting there playing internet chicken > waiting for the other one to blink. > > Given the number of other cellular networks that are following the > same path as T-Mo, I think mass is on their side, but Apple may be > too stubborn to blink and a head-on may be inevitable. I think I agree with you. I am very happy one particular operator leads with IPv6 deployment in a successful way. But I am very unhappy that operation is taken blindly as an example by other operators. It has drawbacks. > Unfortunately, it’s the end-users that will be the victims in this > crash, not the drivers. To be seen. Alex > > Owen > > --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com From nobody Mon Jun 22 13:50:32 2015 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 0B48E1A873B for ; Mon, 22 Jun 2015 13:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 M7jfXudbczRg for ; Mon, 22 Jun 2015 13:50:28 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C5C8A1A6F2D for ; Mon, 22 Jun 2015 13:50:28 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5MKoQG6003955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 13:50:26 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_FF09F927-ADEE-406B-9481-E67FB8BCEBAE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <55886B02.80604@gmail.com> Date: Mon, 22 Jun 2015 13:50:26 -0700 Message-Id: <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com> References: <5587EFDD.6030807@gmail.com> <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com> <55886B02.80604@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 13:50:26 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 20:50:31 -0000 --Apple-Mail=_FF09F927-ADEE-406B-9481-E67FB8BCEBAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >>> It is better to tell the operator to provide a /63 to smartphones >>> (not a /64), with DHCPv6 Prefix Delegation. That will fix it. >>=20 >> No=85 If you=92re going to go to PD, a /63 is stupid. Ideally, use a >> /48, >=20 > Well, one cellular network operator has a /47 to 'share' with all its > customer UEs. If that operator gave a /48 to an UE it could satisfy = only 2 such customers, not millions. That is a problem that is easy to solve with a simple interaction with = their RIR. Give me a break. We should not be designing around providers that didn=92t ask for enough = IPv6 space for their deployments. We should educate those providers. IPv6 space is = easy to get. A cellular network is an ISP almost by definition. There isn=92t a single RIR on the planet that won=92t grant you at least = a /32 if you walk up and say =93I=92m an ISP, /32 please=94 in any credible = way. (modulo payment of fees, etc., but you get the point) >> but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz >> plus some headroom for future applications. >=20 > I agree, headroom should be provided. >=20 >>>> *) Internet Sharing on the Mac Today, regular internet sharing >>>> (from your ethernet to Wi-Fi for example) does not support IPv6 >>>> because of the limited use cases, and the lack of demand for it. >>>=20 >>> If you get done the above then you get Internet Sharing on the Mac >>> Today as well, for free. >>=20 >> Since iOS and OSX are separate code bases, I=92m not sure why you >> think that. >=20 > Because the DHCPv6 Prefix Delegation is a userspace application > implementing a protocol - suffices it to compile on each of these > code bases. It acts the same everywhere. Yes and no. > It's not a GUI, or some kernel module, or some AF-dependent software. Well=85 It is actually AF-dependent. DHCPv6 will not work on IPv4 very = well at all. >>>> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 >>>> test mode was designed to help developers ensure that their app >>>> can still function with IPv6-only NAT64+DNS64 connectivity and >>>> communicate with their IPv4 server, even if the developer does >>>> not have access to the IPv6 internet. That NAT64 network does >>>> not have IPv6 connectivity to the global IPv6 internet. As such, >>>> the current version advertises addresses from 2001::/64 instead >>>> of ULAs to simulate real IPv6 connectivity, as all IPv6 packets >>>> are terminated at the NAT64 server on the Mac. This >>>> implementation detail could change in the future. >>>=20 >>> Makes sense. >>>=20 >>=20 >> Not really=85 This address is currently in the IANA free pool. It >> could be assigned to an RIR and then put on a real network at any >> point in the future. >>=20 >> It would be much better to use a /64 Apple can set aside from their >> own space or some other block of addresses registered for this >> purpose=85 Heck, worst case, Apple could sign up for a free tunnel >> from HE and burn the /64 assigned to that tunnel. >>=20 >> Ideally, the prefix should be user configurable as well. >=20 > I think I didnt read the message as you did. >=20 > I assume by 2001::/64 is meant actually 2001::/3, or some other > 2001:X:Y:U:Z::/64 that the operator prodived. I think it was said > 2001::/3 to distiguish from ULA fd00::/something, and so I said it = made > sense. I heard 2001::/64 and took them at their word. If 2001::/64 is a mistake = and they=92re using something legitimate, then no problem. If I misheard, then also no = problem. Either is possible. >=20 > And, if what is said is really meaning 2001::/64 then I agree with you = - > that's at IANA and one wouldn't juggle with 2001::/64 just like that. > If one wants to juggle with something then it's with fd00::/64 > (ULA) and with 2001:db8::/32 (docu prefix). I have a problem with putting 2001:db8::/32 on actual hardware=85 I = think that violates its intended purpose in the vast majority of cases, including = this one. It shouldn=92t be too hard for Apple to come up with a /64 they can = delegate to this safely. Beyond that, I still think that having it be user configurable is = desirable for a wider range of testing scenarios to be supported. >=20 >>>> *) Making IPv4 literals work on NAT64 networks when using >>>> high-level APIs Starting with this year's versions, if you use >>>> NSURLSession to connect to an IPv4 literal on an IPv6-only >>>> NAT64-DNS64 network, the API will bump in a IPv6 literal >>>> synthesized using RFC 7050. Note that this will not happen when >>>> using sockets directly. We do not support under-the-sockets >>>> bump-in-API (RFC 3338) and we do not support 464XLAT. >>=20 >> They really should support 464XLAT at this point IMHO, though some of >> what they are doing may obviate or lessen the need. It will be >> interesting to see if this is sufficient for T-Mo to finally turn on >> IPv6 for my phone. >>=20 >> Ideally, T-Mo should pull their head out [...] about dual-stack and >> Apple should pull their head out [...] about 464XLAT, but either one >> would meet my immediate needs. >=20 > I wouldnt put it that blunt. But I would agree that less = transitioning be faster transition. I=92ve tried polite=85 They haven=92t listened. Maybe if I=92m blunt it = will get their attention. If you have another alternative that might work, I=92m open to it. >=20 >> Unfortunately, they=92re both sitting there playing internet chicken >> waiting for the other one to blink. >>=20 >> Given the number of other cellular networks that are following the >> same path as T-Mo, I think mass is on their side, but Apple may be >> too stubborn to blink and a head-on may be inevitable. >=20 > I think I agree with you. I am very happy one particular operator = leads with IPv6 deployment in a successful way. But I am very unhappy = that operation is taken blindly as an example by other operators. It = has drawbacks. Actually, T-Mo DOES NOT LEAD. Verizon led and was _WAY_ ahead of T-Mo = and implemented dual-stack. Owen --Apple-Mail=_FF09F927-ADEE-406B-9481-E67FB8BCEBAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
It is better to = tell the operator to provide a /63 to smartphones
(not a = /64), with DHCPv6 Prefix Delegation.  That will fix it.

No=85 If you=92re going to go to = PD, a /63 is stupid. Ideally, use a
/48,

Well, one cellular network = operator has a /47 to 'share' with all its
customer UEs.  If that operator gave a /48 = to an UE it could satisfy only 2 such customers, not millions.

That is a = problem that is easy to solve with a simple interaction with their = RIR.

Give me a break.

We should not be designing around providers that = didn=92t ask for enough IPv6 space
for their deployments. We = should educate those providers. IPv6 space is easy
to get. A = cellular network is an ISP almost by definition.

There isn=92t a single RIR on the planet that = won=92t grant you at least a /32
if you walk up and say =93I=92m= an ISP, /32 please=94 in any credible way.

(modulo payment of fees, etc., but you get the = point)

but at least provide enough subnets to cover BT, USB, = 2.4, and 5Ghz
plus some headroom for future = applications.

I agree, headroom should be provided.

*) Internet Sharing on = the Mac Today, regular internet sharing
(from your = ethernet to Wi-Fi for example) does not support IPv6
because= of the limited use cases, and the lack of demand for it.

If you get done the above then = you get Internet Sharing on the Mac
Today as well, for = free.

Since iOS and OSX =  are separate code bases, I=92m not sure why you
think = that.

Because the DHCPv6 Prefix = Delegation is a userspace application
implementing a protocol - suffices it to compile = on each of these
code bases.  It acts = the same everywhere.

Yes and = no.

It's not a GUI, or some = kernel module, or some AF-dependent software.

Well=85 It is = actually AF-dependent. DHCPv6 will not work on IPv4 very well at = all.

*) Internet Sharing on the Mac - NAT64 testing = mode The NAT64
test mode was designed to help developers = ensure that their app
can still function with IPv6-only = NAT64+DNS64 connectivity and
communicate with their IPv4 = server, even if the developer does
not have access to the = IPv6 internet. That NAT64 network does
not have IPv6 = connectivity to the global IPv6 internet. As such,
the = current version advertises addresses from 2001::/64 instead
of ULAs to simulate real IPv6 connectivity, as all IPv6 = packets
are terminated at the NAT64 server on the Mac. = This
implementation detail could change in the future.

Makes sense.


Not really=85 This address is = currently in the IANA free pool. It
could be assigned to = an RIR and then put on a real network at any
point in the = future.

It would be much better to use a = /64 Apple can set aside from their
own space or some other = block of addresses registered for this
purpose=85 Heck, = worst case, Apple could sign up for a free tunnel
from HE = and burn the /64 assigned to that tunnel.

Ideally, the prefix should be user configurable as well.

I think I didnt read the = message as you did.

I assume by 2001::/64 is = meant actually 2001::/3, or some other
2001:X:Y:U:Z::/64 that the operator prodived. =  I think it was said
2001::/3 to distiguish = from ULA fd00::/something, and so I said it made
sense.

I heard = 2001::/64 and took them at their word. If 2001::/64 is a mistake and = they=92re
using something legitimate, then no problem. If I = misheard, then also no problem.

Either= is possible.


And, if what is said is = really meaning 2001::/64 then I agree with you -
that's at IANA and one wouldn't juggle with = 2001::/64 just like that.
If one wants to juggle = with something then it's with fd00::/64
(ULA) and with 2001:db8::/32 (docu = prefix).

I have a problem = with putting 2001:db8::/32 on actual hardware=85 I think = that
violates its intended purpose in the vast majority of = cases, including this one.

It = shouldn=92t be too hard for Apple to come up with a /64 they can = delegate to this
safely.

Beyond that, I still think that having it be user = configurable is desirable for a wider
range of testing = scenarios to be supported.


*) Making IPv4 literals = work on NAT64 networks when using
high-level APIs Starting = with this year's versions, if you use
NSURLSession to = connect to an IPv4 literal on an IPv6-only
NAT64-DNS64 = network, the API will bump in a IPv6 literal
synthesized = using RFC 7050. Note that this will not happen when
using = sockets directly. We do not support under-the-sockets
bump-in-API (RFC 3338) and we do not support 464XLAT.

They really should = support 464XLAT at this point IMHO, though some of
what = they are doing may obviate or lessen the need. It will be
interesting to see if this is sufficient for T-Mo to finally = turn on
IPv6 for my phone.

Ideally, T-Mo should pull their head out [...] about = dual-stack and
Apple should pull their head out [...] = about 464XLAT, but either one
would meet my immediate = needs.

I wouldnt put it that = blunt.  But I would agree that less transitioning be faster = transition.

I=92ve tried = polite=85 They haven=92t listened. Maybe if I=92m blunt it will get = their attention.

If you have another = alternative that might work, I=92m open to it.


Unfortunately, they=92re = both sitting there playing internet chicken
waiting for = the other one to blink.

Given the number of = other cellular networks that are following the
same path = as T-Mo, I think mass is on their side, but Apple may be
too= stubborn to blink and a head-on may be inevitable.

I think I agree with you. =  I am very happy one particular operator leads with IPv6 deployment = in a successful way.  But I am very unhappy that operation is taken = blindly as an example by other operators.  It has = drawbacks.

Actually, T-Mo = DOES NOT LEAD. Verizon led and was _WAY_ ahead of T-Mo and implemented = dual-stack.

Owen

= --Apple-Mail=_FF09F927-ADEE-406B-9481-E67FB8BCEBAE-- From nobody Mon Jun 22 13:50:54 2015 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 4D7DE1ACF54 for ; Mon, 22 Jun 2015 13:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] 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 79Pn5LMIkBjr for ; Mon, 22 Jun 2015 13:50:50 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDD91A6F2D for ; Mon, 22 Jun 2015 13:50:49 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:7964:27be:c625:11ee] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MKnhHU032932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2015 22:49:43 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com> Date: Mon, 22 Jun 2015 22:50:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <629902C3-6393-42DD-88E2-C72384EE8529@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org, Vividh Siddha Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 20:50:52 -0000 On 22 Jun 2015, at 18:49, Owen DeLong wrote: >> So if you guys currently look at the RTT for the three-way handshake, = it would probably help if you could look at the RTT for data packets = instead. > Pretty hard to look at the data RTT when establishing a connection. = How do you see that working? I don't know the details of Apple's (or anyone else's) happy eyeballs = implementation. If they set up connections, measure the RTT for the = three three-way handshake and then abandon the higher RTT session, or = initiate connections in parallel and only pursue the one that connects = first, then you're right, this would be a problem. On the other hand, if = they do an HTTP request over IPv4 and one over IPv6, then an RTT for = data segments would be available. >> Basically, what's needed for this is that if the interface in = question is configured with "real" IPv6 addresses, those are kept and = the prefix in question is advertised in RAs. > Wouldn=E2=80=99t that require bridging to between the real interface = and the test interface rather than routing? Perhaps that=E2=80=99s not a = bad idea, (the kernel already has the necessary bridging code), but a = consistent and deterministic way of selecting bridge vs. route would be = necessary to create a full test environment, IMHO. Hm, if native IPv6 is available on interface A but you want to run your = test NAT64 network on interface B and thus need to bridge A and B, why = wouldn't you just cut out the middleman and run your test NAT64 network = on interface B? Likely answer: because B is actually dual stack and you need to keep out = the IPv4. So then not only would you have to bridge the IPv6, you would = have to filter out the IPv4 while doing that. That seems a tall order. A much simpler solution is to simply route a /64 to the interface that = hosts the test NAT64 network. Obviously if you have consumer-level = native IPv6 that won't always be possible because you only get a /64 = and/or a way to route additional subnets through cascading DHCPv6 PD or = an IPv6 routing protocol isn't supported. But if all else fails you can terminate a tunnel broker (.net) tunnel on = your Mac and route a /64 to the desired interface and turn on IPv6 = forwarding in the kernel. If Apple is interested in solving more of this than just allowing us to = set up our own IPv6 addresses on the test NAT64 interface (which is the = only part we need Apple to make possible, we can do the rest ourselves) = then IPv6 bridging with IPv4 blocking would be a good choice because = then you can easily take advantage of native IPv6 on an interface = without automatically getting the IPv4 that virtually always comes with = it.= From nobody Mon Jun 22 13:52:15 2015 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 651D21AD087 for ; Mon, 22 Jun 2015 13:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 X-F0CFCTDb7b for ; Mon, 22 Jun 2015 13:52:04 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E464F1AD080 for ; Mon, 22 Jun 2015 13:52:03 -0700 (PDT) Received: from [192.168.178.11] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MKp0uC032961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2015 22:51:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 22 Jun 2015 22:51:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> To: Erik Nygren X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" , Vividh Siddha Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 20:52:05 -0000 On 22 Jun 2015, at 18:53, Erik Nygren wrote: > Having the NAT64/DNS64 environment is great for IPv6-only testing, but = if it doesn't provide the ability to get through to real IPv6 = content/resources when the MacOS host has IPv6 connectivity (either = natively or via a tunnel) then it could be counter-productive in some = circumstances and could discourage app writers from developing their = apps to work well in scenarios where true end-to-end IPv6 connectivity = is possible. Hm, what kind of stuff would work through NAT64 that wouldn't work with = real IPv6 connectivity? (Thinking of stuff that _would_ work with real IPv6 but not NAT64 is = easier.) From nobody Mon Jun 22 14:26:57 2015 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 941FF1AD2C0 for ; Mon, 22 Jun 2015 14:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 K_Pil1lRHFHk for ; Mon, 22 Jun 2015 14:26:54 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89311AC42D for ; Mon, 22 Jun 2015 14:26:53 -0700 (PDT) Received: by igbqq3 with SMTP id qq3so73791127igb.0 for ; Mon, 22 Jun 2015 14:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=m1VkqHc9DpdiZRRguiF3sOBBxCMWuC88UQj315C2qrE=; b=ZFiOdjv1UaUGfPUVx+muyOVO5mxWhx3+Z6nqftXLSA7kSVLyB3mBVtndk1woD+lgEM n2PiM7dl5whydhPXUUOJfT+nu4+/V5pBmlsvBz1277i4vpG1XfyM7jc5302A/3FfK130 Ben9oCjSdJPyGpn5lvsDHSuvYdBlYZqk699/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=m1VkqHc9DpdiZRRguiF3sOBBxCMWuC88UQj315C2qrE=; b=hdjzegpnDcdJUc6E5snnNxc0ooSIxVuV+kcmxOaGUDkYJG0FFGPcwzX9d2g51v4J0Y wPIYSKbCuRx6b7+Etyd8sK9IWAhQCxfezec/i9rDiqJX4ox5cf4tVjxc/dTybZnIgSCd 8uea9Ew7XiOLe9lj9G+Ebq3ZXhI/aADnZp9dhC8LTHBPc4N2yFHamKgPNRlkFk2R/WZW L5Jfsihu77kC3mTVML4MFiq7QZIQRuG49KTAIrBcVfjXXbk+JfZxWeVtN+Glx5pw7IPW jy5FD/ZazJfR8/oBbeq6rGTrsvU7HUR+pQgQ3GTidri7KdEzqoUsuU0QsksdGiLzCeqo OqsA== X-Gm-Message-State: ALoCoQmMNk0WOTSxTfzbaRirn0YVKJIMy7cD9HiGO1WjhzFY7RWIQ0jLPRmOq6t2pkj7iYzEC87M X-Received: by 10.107.138.87 with SMTP id m84mr41124178iod.80.1435008413264; Mon, 22 Jun 2015 14:26:53 -0700 (PDT) Received: from ?IPv6:2620:15c:1:101:28f0:8c61:3c32:31cc? ([2620:15c:1:101:28f0:8c61:3c32:31cc]) by mx.google.com with ESMTPSA id 77sm13591273ioi.20.2015.06.22.14.26.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 14:26:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: james woodyatt In-Reply-To: <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> Date: Mon, 22 Jun 2015 14:26:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> To: Iljitsch van Beijnum , "v6ops@ietf.org" X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 21:26:55 -0000 On Jun 22, 2015, at 13:51, Iljitsch van Beijnum = wrote: > On 22 Jun 2015, at 18:53, Erik Nygren wrote: >=20 >> Having the NAT64/DNS64 environment is great for IPv6-only testing, = but if it doesn't provide the ability to get through to real IPv6 = content/resources when the MacOS host has IPv6 connectivity (either = natively or via a tunnel) then it could be counter-productive in some = circumstances and could discourage app writers from developing their = apps to work well in scenarios where true end-to-end IPv6 connectivity = is possible. >=20 > Hm, what kind of stuff would work through NAT64 that wouldn't work = with real IPv6 connectivity? > (Thinking of stuff that _would_ work with real IPv6 but not NAT64 is = easier.) An obvious example would be a UDP application that depends on a 1500 = octet path MTU to all the IPv6 destinations it cares about. The NAT64 = will shave a 1500 octet packet down to 1480, which might make it = everywhere you want to go over IPv4 without needing to handle ICMPv6 = Packet Too Big Errors, leaving you to discover later that native IPv6 = destinations require you to deal with paths that are 1492 octets and not = 1500 octets. I=E2=80=99m sure if I think for a few minutes, I might be able to come = up with another one. There are probably TCP cases like this too given = the way ICMP6 filters seem to be so terribly popular despite the = guidance our humble working group tries to provide. =E2=80=94james From nobody Mon Jun 22 14:48:04 2015 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 4258D1A90E5 for ; Mon, 22 Jun 2015 14:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 OO78jl3Rvc9r for ; Mon, 22 Jun 2015 14:48:02 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47EF1A01FC for ; Mon, 22 Jun 2015 14:48:01 -0700 (PDT) Received: from [192.168.178.11] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MLl0pn033249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2015 23:47:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> Date: Mon, 22 Jun 2015 23:47:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> To: james woodyatt X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 21:48:03 -0000 On 22 Jun 2015, at 23:26, james woodyatt wrote: >> Hm, what kind of stuff would work through NAT64 that wouldn't work = with real IPv6 connectivity? > An obvious example would be a UDP application that depends on a 1500 = octet path MTU to all the IPv6 destinations it cares about. The NAT64 = will shave a 1500 octet packet down to 1480, which might make it = everywhere you want to go over IPv4 without needing to handle ICMPv6 = Packet Too Big Errors, leaving you to discover later that native IPv6 = destinations require you to deal with paths that are 1492 octets and not = 1500 octets. Sure. Except that the kernel will handle all your fragmentation needs = invisibly to the application (well, save for a retransmission or two). = And testing with native IPv6 won't catch this most of the time anyway, = as 65% of all paths (in my very limited measurements, but still) are = 1500-byte clean. Also, I certainly hope application writers aren't going to test their = applications for compatibility with networks that filter ICMPv6 too = bigs, that would be insanity.= From nobody Mon Jun 22 14:53:19 2015 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 2DF8F1AD36E for ; Mon, 22 Jun 2015 14:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 L55oqfLHEiET for ; Mon, 22 Jun 2015 14:53:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 64DEE1AD366 for ; Mon, 22 Jun 2015 14:53:17 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5MLrGr0009186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 14:53:16 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <629902C3-6393-42DD-88E2-C72384EE8529@muada.com> Date: Mon, 22 Jun 2015 14:53:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1116D021-72F6-418A-A430-4A911F05109B@delong.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com> <629902C3-6393-42DD-88E2-C72384EE8529@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 14:53:16 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org, Vividh Siddha Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 21:53:18 -0000 > On Jun 22, 2015, at 13:50 , Iljitsch van Beijnum = wrote: >=20 > On 22 Jun 2015, at 18:49, Owen DeLong wrote: >=20 >>> So if you guys currently look at the RTT for the three-way = handshake, it would probably help if you could look at the RTT for data = packets instead. >=20 >> Pretty hard to look at the data RTT when establishing a connection. = How do you see that working? >=20 > I don't know the details of Apple's (or anyone else's) happy eyeballs = implementation. If they set up connections, measure the RTT for the = three three-way handshake and then abandon the higher RTT session, or = initiate connections in parallel and only pursue the one that connects = first, then you're right, this would be a problem. On the other hand, if = they do an HTTP request over IPv4 and one over IPv6, then an RTT for = data segments would be available. The few tcpdump logs I=E2=80=99ve looked at would seem to indicate that = most (including Apple=E2=80=99s) HE implementations I=E2=80=99ve = encountered do the former rather than the latter. Also as near as I can = tell, state isn=E2=80=99t tracked from one connection to the next, each = new connect() loop sprays a new set of SYNs and then abandons all but = the one it selects. YMMV Owen From nobody Mon Jun 22 15:17:33 2015 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 935241B29E0 for ; Mon, 22 Jun 2015 15:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mSNtu6lLwM9v for ; Mon, 22 Jun 2015 15:17:30 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by ietfa.amsl.com (Postfix) with ESMTP id 736151B29E7 for ; Mon, 22 Jun 2015 15:17:29 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) by elvis.mu.org (Postfix) with ESMTPSA id 16C47341F92E for ; Mon, 22 Jun 2015 15:17:29 -0700 (PDT) Received: by igblr2 with SMTP id lr2so41572726igb.0 for ; Mon, 22 Jun 2015 15:17:28 -0700 (PDT) X-Received: by 10.50.50.175 with SMTP id d15mr24108470igo.28.1435011448374; Mon, 22 Jun 2015 15:17:28 -0700 (PDT) MIME-Version: 1.0 References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com> <629902C3-6393-42DD-88E2-C72384EE8529@muada.com> <1116D021-72F6-418A-A430-4A911F05109B@delong.com> In-Reply-To: <1116D021-72F6-418A-A430-4A911F05109B@delong.com> From: Paul Saab Date: Mon, 22 Jun 2015 22:17:19 +0000 Message-ID: To: Owen DeLong , Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=047d7b2e549ca115ac051922a305 Archived-At: Cc: v6ops@ietf.org, Vividh Siddha Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 22:17:31 -0000 --047d7b2e549ca115ac051922a305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 22, 2015 at 2:53 PM Owen DeLong wrote: > The few tcpdump logs I=E2=80=99ve looked at would seem to indicate that m= ost > (including Apple=E2=80=99s) HE implementations I=E2=80=99ve encountered d= o the former > rather than the latter. Also as near as I can tell, state isn=E2=80=99t t= racked > from one connection to the next, each new connect() loop sprays a new set > of SYNs and then abandons all but the one it selects. > With the help of Jason Fesler and his test-ipv6 infrastructure, Apple has a good way to validate that their HE will not penalize IPv6 any longer. Even in the first iOS9 release, the current HE still penalizes IPv6 when RTT is the same or within their "fudge factor", so thankfully we now have a good test for them to work against. Let's just wait for the seed that contains the changes and test again. --047d7b2e549ca115ac051922a305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 22, 2015 at 2:53 PM Owen DeLong <owen@delong.com> wrote:
The few tcpdump logs I=E2=80=99ve looked at would seem to indicate that mos= t (including Apple=E2=80=99s) HE implementations I=E2=80=99ve encountered d= o the former rather than the latter. Also as near as I can tell, state isn= =E2=80=99t tracked from one connection to the next, each new connect() loop= sprays a new set of SYNs and then abandons all but the one it selects.
=

With the help of Jason Fesler and his test= -ipv6 infrastructure, Apple has a good way to validate that their HE will n= ot penalize IPv6 any longer.=C2=A0 Even in the first iOS9 release, the curr= ent HE still penalizes IPv6 when RTT is the same or within their "fudg= e factor", so thankfully we now have a good test for them to work agai= nst.=C2=A0 Let's just wait for the seed that contains the changes and t= est again. =C2=A0
--047d7b2e549ca115ac051922a305-- From nobody Mon Jun 22 15:42:14 2015 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 1D7251A90EC for ; Mon, 22 Jun 2015 15:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Z00ukxqsh-a9 for ; Mon, 22 Jun 2015 15:42:09 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BCE1A8937 for ; Mon, 22 Jun 2015 15:42:09 -0700 (PDT) Received: by igboe5 with SMTP id oe5so75102485igb.1 for ; Mon, 22 Jun 2015 15:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K1Y1NFfa0v152HwWvTsVg3iu1g8g9dDXKF0lp/WvH6o=; b=fPH/VCCbJqQxWRLux8rk1yu6rRbIGiPo2GiM4p3V9nLOgSbmkB/JK16sSBKnzWhzLO NGm/pTKMwkggHTye0wGIPRxd165HGzZqNITlmbz+Q0l4vjB3A3N04pbSobbljZBGJ82K GudHU1fcy4GlBOTrdFtmmGCTLb2heFlGvhZaw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=K1Y1NFfa0v152HwWvTsVg3iu1g8g9dDXKF0lp/WvH6o=; b=UN6+aGkMcP/XOo1LIKQoPHGh7QBR11T28960baaqSTiF4grECgjDK9aTJ0G+i5mUj0 Iz3pdwdzeK+vL+tH1c26EPRI4mbYCYVPvNIAcWH4D5y6Vx//BiezjWFez2cVtwhY7UTo LCpdqTJLslk8bjUtSQh6xzIqMB5JXkdSun4xbspmBeFrC6lPPLV/lKTQiIbAo96DM57A b3VqqjkYBWDybaMR0TuGE0St4cPW+KlN5RBzgnM3zZvD5qnjuQujCUDULKKWzH6WIYRP mQRMpGCN0tm5k5n8eieNX30nTXLY2VHGEPhyhiV7HuyrW9EojHe/J84bm4iy6Dognf2o DxSA== X-Gm-Message-State: ALoCoQk97zIJZ+22eCvdlfTo6i5npo6rpIpIE7FVmXmiHueNgvT/NBL1OJ0c421pGewEs6CBQrl+ X-Received: by 10.50.114.40 with SMTP id jd8mr23969745igb.47.1435012928996; Mon, 22 Jun 2015 15:42:08 -0700 (PDT) Received: from dhcp-100-100-99-154.pao.corp.google.com ([100.100.99.154]) by mx.google.com with ESMTPSA id h128sm13734670ioh.38.2015.06.22.15.42.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 15:42:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: james woodyatt In-Reply-To: <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> Date: Mon, 22 Jun 2015 15:42:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 22:42:11 -0000 On Jun 22, 2015, at 14:47, Iljitsch van Beijnum = wrote: > On 22 Jun 2015, at 23:26, james woodyatt wrote: >=20 >>> Hm, what kind of stuff would work through NAT64 that wouldn't work = with real IPv6 connectivity? >=20 >> An obvious example would be a UDP application that depends on a 1500 = octet path MTU to all the IPv6 destinations it cares about. The NAT64 = will shave a 1500 octet packet down to 1480, which might make it = everywhere you want to go over IPv4 without needing to handle ICMPv6 = Packet Too Big Errors, leaving you to discover later that native IPv6 = destinations require you to deal with paths that are 1492 octets and not = 1500 octets. >=20 > Sure. Except that the kernel will handle all your fragmentation needs = invisibly to the application (well, save for a retransmission or two). = And testing with native IPv6 won't catch this most of the time anyway, = as 65% of all paths (in my very limited measurements, but still) are = 1500-byte clean. >=20 > Also, I certainly hope application writers aren't going to test their = applications for compatibility with networks that filter ICMPv6 too = bigs, that would be insanity. I think you might have overlooked where I wrote =E2=80=9CUDP=E2=80=9D = above instead of =E2=80=9CTCP=E2=80=9D which on iOS and OS X doesn=E2=80=99= t have any PMTUD support. The kernel will not do any fragmentation or = retransmission of UDP packets. A lot of applications are coded never to = process the error code at a socket if a Too Big error is received. They = either ignore the error and fail because packet size are never reduced, = or they fail inappropriately rather than reduce packet sizes. Developers = who only use the NAT64 environment without testing on a native IPv6 = network may never see the Too Big errors that would expose this problem, = and they won=E2=80=99t see it until their application is deployed for = reals. =E2=80=94james= From nobody Mon Jun 22 15:59:02 2015 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 E409F1B2A1A for ; Mon, 22 Jun 2015 15:58:59 -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 3y0l3A5XD0M6 for ; Mon, 22 Jun 2015 15:58:58 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EE81B2A15 for ; Mon, 22 Jun 2015 15:58:57 -0700 (PDT) Received: by wgqq4 with SMTP id q4so28552421wgq.1 for ; Mon, 22 Jun 2015 15:58:56 -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=viHe9jmkVj1W7pzncCvRnjXLK6RIZwsWE5vuZn98h+Q=; b=TJSrkNUJP8i5YofOsVlrYjHRwpidbdKYCGQLPaahhPS345zfDW0w6j9+vXMtB701fs Ohw/5CnH1JRhHxk43xtF+7cKIjMLZf+S9SdlP8/mkbpJj3ebeQOFpn5QlyvHkfarUb3W WNVdljylKKBjmppWeZHR/gjmGdUfd/Eed+zMwHak3aNlnTZS0Mo+sk0sn/Mn+KopKdwX CM7yG+0LKn3fc0e91/C+k8W/nqqHgMtT6k+aEWE5xqy4syMC2zkunU2QWnAkWHhNdfym xgT+gBqcar7nRZTmqqPVd5uGYXfcHR5iBUyDR1Tic6+3YuYsOX+N9MeTPmoyo/198pXT 0aog== MIME-Version: 1.0 X-Received: by 10.181.25.234 with SMTP id it10mr36619011wid.41.1435013936235; Mon, 22 Jun 2015 15:58:56 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Mon, 22 Jun 2015 15:58:56 -0700 (PDT) In-Reply-To: <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> Date: Mon, 22 Jun 2015 15:58:56 -0700 Message-ID: From: Ca By To: james woodyatt Content-Type: multipart/alternative; boundary=001a1136cbd8eac8cf0519233707 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 22:59:00 -0000 --001a1136cbd8eac8cf0519233707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, June 22, 2015, james woodyatt wrote: > On Jun 22, 2015, at 14:47, Iljitsch van Beijnum > wrote: > > On 22 Jun 2015, at 23:26, james woodyatt > wrote: > > > >>> Hm, what kind of stuff would work through NAT64 that wouldn't work > with real IPv6 connectivity? > > > >> An obvious example would be a UDP application that depends on a 1500 > octet path MTU to all the IPv6 destinations it cares about. The NAT64 wil= l > shave a 1500 octet packet down to 1480, which might make it everywhere yo= u > want to go over IPv4 without needing to handle ICMPv6 Packet Too Big > Errors, leaving you to discover later that native IPv6 destinations requi= re > you to deal with paths that are 1492 octets and not 1500 octets. > > > > Sure. Except that the kernel will handle all your fragmentation needs > invisibly to the application (well, save for a retransmission or two). An= d > testing with native IPv6 won't catch this most of the time anyway, as 65% > of all paths (in my very limited measurements, but still) are 1500-byte > clean. > > > > Also, I certainly hope application writers aren't going to test their > applications for compatibility with networks that filter ICMPv6 too bigs, > that would be insanity. > > I think you might have overlooked where I wrote =E2=80=9CUDP=E2=80=9D abo= ve instead of > =E2=80=9CTCP=E2=80=9D which on iOS and OS X doesn=E2=80=99t have any PMTU= D support. The kernel will > not do any fragmentation or retransmission of UDP packets. A lot of > applications are coded never to process the error code at a socket if a T= oo > Big error is received. They either ignore the error and fail because pack= et > size are never reduced, or they fail inappropriately rather than reduce > packet sizes. Developers who only use the NAT64 environment without testi= ng > on a native IPv6 network may never see the Too Big errors that would expo= se > this problem, and they won=E2=80=99t see it until their application is de= ployed for > reals. > > > =E2=80=94james For some subset of networks, devs can test the real production deal if apple could surface the apn setting in dev builds. It is hard to see the harm in this. Other OSs allow apn setting fiddling. Also, this allows an escape hatch for the inevitable user who cannot deal with ipv6-only in production... And opens the door for end user opt in trials of ipv6. It's really not a hard problem to solve for many situations (like tmus) but the some backwards place .... They may not have this luxury of proper ipv6 in mobile :/ CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1136cbd8eac8cf0519233707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, June 22, 2015, james woodyatt <jhw@nestlabs.com> wrote:
On Jun 22, 2015, at 14:47, Iljitsch van Beijnum <= iljitsch@muada.com> wrote:
> On 22 Jun 2015, at 23:26, james woodyatt <jhw@nestl= abs.com> wrote:
>
>>> Hm, what kind of stuff would work through NAT64 that wouldn= 9;t work with real IPv6 connectivity?
>
>> An obvious example would be a UDP application that depends on a 15= 00 octet path MTU to all the IPv6 destinations it cares about. The NAT64 wi= ll shave a 1500 octet packet down to 1480, which might make it everywhere y= ou want to go over IPv4 without needing to handle ICMPv6 Packet Too Big Err= ors, leaving you to discover later that native IPv6 destinations require yo= u to deal with paths that are 1492 octets and not 1500 octets.
>
> Sure. Except that the kernel will handle all your fragmentation needs = invisibly to the application (well, save for a retransmission or two). And = testing with native IPv6 won't catch this most of the time anyway, as 6= 5% of all paths (in my very limited measurements, but still) are 1500-byte = clean.
>
> Also, I certainly hope application writers aren't going to test th= eir applications for compatibility with networks that filter ICMPv6 too big= s, that would be insanity.

I think you might have overlooked where I wrote =E2=80=9CUDP=E2=80=9D above= instead of =E2=80=9CTCP=E2=80=9D which on iOS and OS X doesn=E2=80=99t hav= e any PMTUD support. The kernel will not do any fragmentation or retransmis= sion of UDP packets. A lot of applications are coded never to process the e= rror code at a socket if a Too Big error is received. They either ignore th= e error and fail because packet size are never reduced, or they fail inappr= opriately rather than reduce packet sizes. Developers who only use the NAT6= 4 environment without testing on a native IPv6 network may never see the To= o Big errors that would expose this problem, and they won=E2=80=99t see it = until their application is deployed for reals.


=E2=80=94james


For some subs= et of networks, devs can test the real production deal if apple could surfa= ce the apn setting in dev builds. It is hard to see the harm in this. Other= OSs allow apn setting fiddling. Also, this allows an escape hatch for the = inevitable user who cannot deal with ipv6-only in production... And opens t= he door for end user opt in trials of ipv6.=C2=A0

= It's really not a hard problem to solve for many situations (like tmus)= =C2=A0 but the some backwards place .... They may not have this luxury of p= roper ipv6 in mobile :/

CB=C2=A0
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--001a1136cbd8eac8cf0519233707-- From nobody Mon Jun 22 16:11:44 2015 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 3D2261B2A5B for ; Mon, 22 Jun 2015 16:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 L8YEgFXoMWB6 for ; Mon, 22 Jun 2015 16:11:41 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DD01A8AA5 for ; Mon, 22 Jun 2015 16:11:41 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 7142B1FCC83; Mon, 22 Jun 2015 23:11:37 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5956D160077; Mon, 22 Jun 2015 23:12:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3F534160076; Mon, 22 Jun 2015 23:12:16 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V-J8Zz3E5Csq; Mon, 22 Jun 2015 23:12:16 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 98677160041; Mon, 22 Jun 2015 23:12:15 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 10A42311C0A3; Tue, 23 Jun 2015 09:11:33 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <5587EFDD.6030807@gmail.com> <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com> <55886B02.80604@gmail.com> <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com> In-reply-to: Your message of "Mon, 22 Jun 2015 13:50:26 -0700." <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com> Date: Tue, 23 Jun 2015 09:11:33 +1000 Message-Id: <20150622231133.10A42311C0A3@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 22 Jun 2015 23:11:43 -0000 In message <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com>, Owen DeLong write s: > > >>> It is better to tell the operator to provide a /63 to smartphones > >>> (not a /64), with DHCPv6 Prefix Delegation. That will fix it. > >> > >> No... > >> If you're going to go to PD, a /63 is stupid. Ideally, use a /48, > > > > Well, one cellular network operator has a /47 to 'share' with all its > > customer UEs. If that operator gave a /48 to an UE it could satisfy > > only 2 such customers, not millions. > > That is a problem that is easy to solve with a simple interaction with > their RIR. > > Give me a break. > > We should not be designing around providers that didn't ask for enough > IPv6 space for their deployments. We should educate those providers. > IPv6 space is easy to get. A cellular network is an ISP almost by definition. > > There isn't a single RIR on the planet that won't grant you at least a /32 > if you walk up and say "I'm an ISP, /32 please" in any credible way. > > (modulo payment of fees, etc., but you get the point) > > >> but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz > >> plus some headroom for future applications. > > > > I agree, headroom should be provided. > > > >>>> *) Internet Sharing on the Mac Today, regular internet sharing > >>>> (from your ethernet to Wi-Fi for example) does not support IPv6 > >>>> because of the limited use cases, and the lack of demand for it. > >>> > >>> If you get done the above then you get Internet Sharing on the Mac > >>> Today as well, for free. > >> > >> Since iOS and OSX are separate code bases, I'm not sure why you > >> think that. > > > > Because the DHCPv6 Prefix Delegation is a userspace application > > implementing a protocol - suffices it to compile on each of these > > code bases. It acts the same everywhere. > > Yes and no. > > > It's not a GUI, or some kernel module, or some AF-dependent software. > > Well... > It is actually AF-dependent. DHCPv6 will not work on IPv4 very well at > all. > > >>>> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 > >>>> test mode was designed to help developers ensure that their app > >>>> can still function with IPv6-only NAT64+DNS64 connectivity and > >>>> communicate with their IPv4 server, even if the developer does > >>>> not have access to the IPv6 internet. That NAT64 network does > >>>> not have IPv6 connectivity to the global IPv6 internet. As such, > >>>> the current version advertises addresses from 2001::/64 instead > >>>> of ULAs to simulate real IPv6 connectivity, as all IPv6 packets > >>>> are terminated at the NAT64 server on the Mac. This > >>>> implementation detail could change in the future. > >>> > >>> Makes sense. > >>> > >> > >> Not really... > >> This address is currently in the IANA free pool. It > >> could be assigned to an RIR and then put on a real network at any > >> point in the future. > >> > >> It would be much better to use a /64 Apple can set aside from their > >> own space or some other block of addresses registered for this > >> purpose... > >> Heck, worst case, Apple could sign up for a free tunnel > >> from HE and burn the /64 assigned to that tunnel. > >> > >> Ideally, the prefix should be user configurable as well. > > > > I think I didnt read the message as you did. > > > > I assume by 2001::/64 is meant actually 2001::/3, or some other > > 2001:X:Y:U:Z::/64 that the operator prodived. I think it was said > > 2001::/3 to distiguish from ULA fd00::/something, and so I said it made > > sense. > > I heard 2001::/64 and took them at their word. If 2001::/64 is a mistake > and they're > using something legitimate, then no problem. If I misheard, then also no > problem. > > Either is possible. > > > > > And, if what is said is really meaning 2001::/64 then I agree with you - > > that's at IANA and one wouldn't juggle with 2001::/64 just like that. > > If one wants to juggle with something then it's with fd00::/64 > > (ULA) and with 2001:db8::/32 (docu prefix). > > I have a problem with putting 2001:db8::/32 on actual hardware... > I think that violates its intended purpose in the vast majority of > cases, including this one. > > It shouldn't be too hard for Apple to come up with a /64 they can > delegate to this safely. > > Beyond that, I still think that having it be user configurable is > desirable for a wider range of testing scenarios to be supported. > > > > >>>> *) Making IPv4 literals work on NAT64 networks when using > >>>> high-level APIs Starting with this year's versions, if you use > >>>> NSURLSession to connect to an IPv4 literal on an IPv6-only > >>>> NAT64-DNS64 network, the API will bump in a IPv6 literal > >>>> synthesized using RFC 7050. Note that this will not happen when > >>>> using sockets directly. We do not support under-the-sockets > >>>> bump-in-API (RFC 3338) and we do not support 464XLAT. > >> > >> They really should support 464XLAT at this point IMHO, though some of > >> what they are doing may obviate or lessen the need. It will be > >> interesting to see if this is sufficient for T-Mo to finally turn on > >> IPv6 for my phone. > >> > >> Ideally, T-Mo should pull their head out [...] about dual-stack and > >> Apple should pull their head out [...] about 464XLAT, but either one > >> would meet my immediate needs. > > > > I wouldnt put it that blunt. But I would agree that less transitioning > > be faster transition. > > I've tried polite... > They haven't listened. Maybe if I'm blunt it will get their attention. > > If you have another alternative that might work, I'm open to it. > > > > >> Unfortunately, they're both sitting there playing internet chicken > >> waiting for the other one to blink. > >> > >> Given the number of other cellular networks that are following the > >> same path as T-Mo, I think mass is on their side, but Apple may be > >> too stubborn to blink and a head-on may be inevitable. > > > > I think I agree with you. I am very happy one particular operator > > leads with IPv6 deployment in a successful way. But I am very unhappy > > that operation is taken blindly as an example by other operators. It has > > drawbacks. > > Actually, T-Mo DOES NOT LEAD. Verizon led and was _WAY_ ahead of T-Mo and > implemented dual-stack. > > Owen 464XLAT with DNS64 is a ABOMINATION. The sooner it is removed the better. It only APPEARS to work well at the moment because there is not a lot of validation happening in the application yet. It does not work with a validating recursive nameservers forwarding queries to a DNS64 recursive server. MAP and DS-Lite both do a better job and neither of them muck with packet payload. They also work with DNSSEC (464XLAT is usually deployed with DNS64 and DNS64 DOES NOT WORK WITH DNSSEC (CD=1 does NOT indicate validation is occuring despite what is written in RFC 6147, DO=1 is the ONLY indicatator that validation MAY be occuring.)). All three have PMTU issues. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 22 16:18:19 2015 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 EDF7C1B2A6B for ; Mon, 22 Jun 2015 16:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 fG2uuQVqLjTi for ; Mon, 22 Jun 2015 16:18:17 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C581B2A68 for ; Mon, 22 Jun 2015 16:18:17 -0700 (PDT) Received: by igbqq3 with SMTP id qq3so75532480igb.0 for ; Mon, 22 Jun 2015 16:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y37KdEqH4SLT3GMUVU2sn45fYPH70CRNzRrfp08e8nQ=; b=cnB/sqq2DkhHtRM6NpjX84BC+lsV8tX8ojsPwIgufpEcdW9E4BXFpmGjXoFNVLe6T1 Ma3hJTl2pDn4D5q6gAgNQPvjcRlywwXtmEvftbwBjOAEiNv3ijYI29yZWHfJtAqx4E9A EEELE2cidkKzWwUiwNnQqCx8q3o8CLTLfmb88= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Y37KdEqH4SLT3GMUVU2sn45fYPH70CRNzRrfp08e8nQ=; b=C60xxfXWWSxGYXnUiTVOq9eUJuKV+d9ze268YYbgKltEcaeJDWzAAT/e6SHakVJeKe xw4QXR+WV9aeyFree3C1kgwq/J6JdInx0B6EOxr7lOgtxGmT7CYUq82zbhzxHe7Q67SN ooDQiJJMfZik7QUIwcMLYdCOPHQxw/RW2YKhCIcVD7pfn0XaqFaTSzbVDxLa5fvee1yp gGbh5ivnLOn1palTwt5JSoi86FBp2Vq8RaPXMNH2mfbu8/k5Ce3iZ72kM8wqO3zjYHMZ AGwLmYrxIz+K0mEgXtnM8zDro3/q6mST0uqTbZkPJrgp5k00hfr1sxEl/TYZeWf1pNGC uP9Q== X-Gm-Message-State: ALoCoQmmFf/lqtyuwemLRwc7QJKCBTuTkKcuimOxdLNNGjJxUYUc8l4pKQZnYTfOI3jLZmAi3BXK X-Received: by 10.50.43.196 with SMTP id y4mr24236785igl.14.1435015096940; Mon, 22 Jun 2015 16:18:16 -0700 (PDT) Received: from dhcp-100-100-99-154.pao.corp.google.com ([100.100.99.154]) by mx.google.com with ESMTPSA id k74sm13797388iok.30.2015.06.22.16.18.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 16:18:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: james woodyatt In-Reply-To: Date: Mon, 22 Jun 2015 16:18:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 23:18:19 -0000 On Jun 22, 2015, at 15:57, Iljitsch van Beijnum = wrote: > On 23 Jun 2015, at 0:42, james woodyatt wrote: >=20 >> I think you might have overlooked where I wrote =E2=80=9CUDP=E2=80=9D = above instead of =E2=80=9CTCP=E2=80=9D which on iOS and OS X doesn=E2=80=99= t have any PMTUD support. The kernel will not do any fragmentation or = retransmission of UDP packets. >=20 > No, I didn't overlook that part. But let me return the favor: I think = you're confusing IPv6 with IPv4 here. In IPv6, fragmentation is an = IP-level function on the host. I=E2=80=99m not confused about that. > As such: [=E2=80=A6] I'm 99.9% sure this works the same way for UDP as = for ICMPv6; [=E2=80=A6] It does. > You're right about the retransmission part, though, the first packet = (the one that triggers the too big) is lost. If the return packet (for = the retransmission) is also large, that one will very likely also be = lost and cause the too big in the other direction, so it takes two = retransmissions to get a reply. The problem is that you can send those 1500 octet packets out your = Wi-fi, and the NAT64 will shorten them to 1480 when it replaces the IPv6 = header with an IPv4 header. Those 1480-octet IPv4 packets will then pass = straight through parts of the network with PMTU=3D1492 without = generating errors and therefore never exercising any application layer = logic needed to deal with UDP-PMTUD, which is typically not there at all = because developers are=E2=80=A6 well, they often don=E2=80=99t do it. = Hence, you have something that works on NAT64 that will fail when they = encounter native IPv6 and PMTU=3D1492, which is as we all know, not as = uncommon as we=E2=80=99d like it to be. =E2=80=94james= From nobody Mon Jun 22 16:31:51 2015 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 E1A751B2A2F for ; Mon, 22 Jun 2015 16:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 CiBZfr4RGHAs for ; Mon, 22 Jun 2015 16:31:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D25F1ACEF7 for ; Mon, 22 Jun 2015 16:31:38 -0700 (PDT) Received: from [192.168.178.11] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MNUaQk033784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2015 01:30:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 23 Jun 2015 01:31:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> To: james woodyatt X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 22 Jun 2015 23:31:43 -0000 On 23 Jun 2015, at 1:18, james woodyatt wrote: >> As such: [=E2=80=A6] I'm 99.9% sure this works the same way for UDP = as for ICMPv6; [=E2=80=A6] > It does. So then why would this be a problem: > pass straight through parts of the network with PMTU=3D1492 without = generating errors and therefore never exercising any application layer = logic needed to deal with UDP-PMTUD, which is typically not there at all = because developers are=E2=80=A6 well, they often don=E2=80=99t do it. What exactly are you objecting to? That the translated packets are too = small to trigger too bigs? That also happens with native IPv6 if the = path supports 1500 bytes. So if you want to test for paths with < 1500 = PMTUs, you will have to, you know, do the work to test with paths with < = 1500 PTMUs. If your problem is that applications don't handle incoming too bigs, = then be glad you're behind a NAT64 because this is indeed a problem with = IPv4 (but easily solved by simply setting the DF bit to 0!) but it isn't = for IPv6, as we just agreed that with IPv6, the IP layer catches too = bigs and fragments subsequent packets without involvement from the = application. From nobody Mon Jun 22 17:03:23 2015 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 21C9D1ACD4C for ; Mon, 22 Jun 2015 17:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zuhly0esPy0k for ; Mon, 22 Jun 2015 17:03:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 38B6F1ACD38 for ; Mon, 22 Jun 2015 17:03:20 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5N03JZv031679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 17:03:19 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> Date: Mon, 22 Jun 2015 17:03:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 17:03:19 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:03:22 -0000 > On Jun 22, 2015, at 16:31 , Iljitsch van Beijnum = wrote: >=20 > On 23 Jun 2015, at 1:18, james woodyatt wrote: >=20 >>> As such: [=E2=80=A6] I'm 99.9% sure this works the same way for UDP = as for ICMPv6; [=E2=80=A6] >=20 >> It does. >=20 > So then why would this be a problem: >=20 >> pass straight through parts of the network with PMTU=3D1492 without = generating errors and therefore never exercising any application layer = logic needed to deal with UDP-PMTUD, which is typically not there at all = because developers are=E2=80=A6 well, they often don=E2=80=99t do it. >=20 > What exactly are you objecting to? That the translated packets are too = small to trigger too bigs? That also happens with native IPv6 if the = path supports 1500 bytes. So if you want to test for paths with < 1500 = PMTUs, you will have to, you know, do the work to test with paths with < = 1500 PTMUs. >=20 > If your problem is that applications don't handle incoming too bigs, = then be glad you're behind a NAT64 because this is indeed a problem with = IPv4 (but easily solved by simply setting the DF bit to 0!) but it isn't = for IPv6, as we just agreed that with IPv6, the IP layer catches too = bigs and fragments subsequent packets without involvement from the = application. >=20 Let me try and get you guys to stop talking across each other=E2=80=A6 The issue James has (rightly, IMHO) raised is that at the application = developer level, you may or may not think to test for <1500 MTU. However, if you test your 1500-octet packet using application in a NAT64 = environment and it works (because you=E2=80=99re connecting to an IPv4 = server via a NAT that shortens your packets) and you think everything is = wonderful and ship your application, it could come as a rude shock to = your end-users who happen to have native IPv6 that wasn=E2=80=99t = available in your development environment because all of a sudden, the = 1500-octet packets you are sending are leaving the device as 1500-octet = packets and dying in the wild rather than getting artificially = shortened. Thus, you=E2=80=99ve got a scenario where NAT64 testing is inadequate = vs. NAT64 + Native V6 testing which was, in fact, the original question. Owen From nobody Mon Jun 22 17:06:55 2015 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 76EA61ACD6E for ; Mon, 22 Jun 2015 17:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KreCM0IQfhrR for ; Mon, 22 Jun 2015 17:06:52 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265501ACD59 for ; Mon, 22 Jun 2015 17:06:52 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id D5AF81FCB5A; Tue, 23 Jun 2015 00:06:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9BA21160041; Tue, 23 Jun 2015 00:07:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4D645160076; Tue, 23 Jun 2015 00:07:26 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Vk4FH6c7mv5o; Tue, 23 Jun 2015 00:07:26 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id C99AA160041; Tue, 23 Jun 2015 00:07:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 93C3C311CC30; Tue, 23 Jun 2015 10:06:43 +1000 (EST) To: Iljitsch van Beijnum From: Mark Andrews References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> In-reply-to: Your message of "Tue, 23 Jun 2015 01:31:30 +0200." <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> Date: Tue, 23 Jun 2015 10:06:43 +1000 Message-Id: <20150623000643.93C3C311CC30@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:06:54 -0000 In message <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com>, Iljitsch van Beijn um writes: > On 23 Jun 2015, at 1:18, james woodyatt wrote: > > >> As such: I'm 99.9% sure this works the same way for UDP as for > ICMPv6; > > > It does. > > So then why would this be a problem: > > > pass straight through parts of the network with PMTU=1492 without > generating errors and therefore never exercising any application layer > logic needed to deal with UDP-PMTUD, which is typically not there at all > because developers are well, they often dont do it. > > What exactly are you objecting to? That the translated packets are too > small to trigger too bigs? That also happens with native IPv6 if the path > supports 1500 bytes. So if you want to test for paths with < 1500 PMTUs, > you will have to, you know, do the work to test with paths with < 1500 > PTMUs. > > If your problem is that applications don't handle incoming too bigs, then > be glad you're behind a NAT64 because this is indeed a problem with IPv4 > (but easily solved by simply setting the DF bit to 0!) but it isn't for > IPv6, as we just agreed that with IPv6, the IP layer catches too bigs and > fragments subsequent packets without involvement from the application. For named (DNS) we just set IPV6_USE_MIN_MTU=1 for *both* TCP and UDP. PMTUD is a problem for TCP as well as UDP (load balancers / filters). We also send EDNS UDP requests with various response sizes in the requests and look at actual response sizes because there are idiots with firewalls that think dropping fragmented packets is a good thing to do. Unfortunately there are stacks that don't consider IPV6_USE_MIN_MTU when performing MSS negotiation which is really wrong because when it is set to 1 the MTU *is* 1280. One really shouldn't have to spell out the relationship. [rock:~/git/bind9.drugs] marka% grep srtt /var/named/named_dump.db | grep udpsize | grep : ; 2620:74:19::33 [srtt 379894] [flags 00006000] [edns 10/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218] ; 2610:a1:1014::78 [srtt 129911] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 444] ; 2001:502:cbe4::33 [srtt 163948] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218] ; 2001:503:83eb::2:31 [srtt 317999] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 333] ; 2607:f208:302::30 [srtt 126230] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 434] ; 2001:500:2c::254 [srtt 228230] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 1640] [ttl -116] ; 2001:67c:1010:13::53 [srtt 208027] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437] ; 2001:500:e::1 [srtt 257600] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266] ; 2a02:1788:0:600::c742:c805 [srtt 155908] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 444] ; 2001:500:71::30 [srtt 204866] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1652] ; 2001:500:90:1::27 [srtt 122709] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 268] ; 2001:500:7967::2:33 [srtt 120860] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218] ; 2606:2800:1::5 [srtt 173309] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 270] ; 2400:cb00:2049:1::adf5:3b1f [srtt 115518] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266] ; 2001:dcd:5::101 [srtt 462281] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 428] ; 2600:1401:1::41 [srtt 235626] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218] ; 2001:500:1b::1 [srtt 434090] [flags 00006000] [edns 3/1/1/1/1] [plain 0/0] [udpsize 512] [ttl 439] ; 2407:6e00:253:306::73 [srtt 73080] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 432] ; 2400:cb00:2049:1::c629:de1f [srtt 116161] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266] ; 2001:500:94:1::20 [srtt 159376] [flags 00006000] [edns 3/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 268] ; 2001:dce:2000:2::130 [srtt 134191] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437] ; 2600:1401:2::42 [srtt 176795] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 218] ; 2001:500:48::1 [srtt 180877] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266] ; 2001:a10:121:1::156 [srtt 318167] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 267] ; 2001:500:90:1::20 [srtt 198783] [flags 00006000] [edns 3/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 268] ; 2a01:8840:6::1 [srtt 170706] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1652] ; 2001:502:ad09::14 [srtt 219604] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437] ; 2600:1802:4::1 [srtt 174653] [flags 00006000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 436] ; 2620:0:150:4013::5 [srtt 298185] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 267] ; 2600:1401:2::ad [srtt 180765] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 436] ; 2001:500:94:1::34 [srtt 110366] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 269] ; 2606:2800:1::6 [srtt 116409] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 270] ; 2001:500:90::100 [srtt 215880] [flags 00006000] [edns 8/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 220] ; 2001:500:f::1 [srtt 133137] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266] ; 2001:503:a83e::2:31 [srtt 262167] [flags 00006000] [edns 18/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 333] ; 2001:dce:7000:2::130 [srtt 363522] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 437] ; 2001:4868:108:1:223:8bff:fea9:dbf8 [srtt 360151] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 260] ; 2001:502:ad09::3 [srtt 217370] [flags 00006000] [edns 2/1/0/0/0] [plain 0/0] [udpsize 512] [ttl 266] ; 2001:500:90:1::34 [srtt 118925] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 269] ; 2001:500:b::1 [srtt 146381] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 266] ; 2001:1a68:0:17::238 [srtt 496218] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 267] ; 2001:500:4431::2:30 [srtt 291357] [flags 00006000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 259] ; 2001:500:60::30 [srtt 187678] [flags 00006000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1652] ; 2001:dcd:6::101 [srtt 534725] [flags 00006000] [edns 5/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 428] [rock:~/git/bind9.drugs] marka% > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 22 17:11:41 2015 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 3D2F31B3057 for ; Mon, 22 Jun 2015 17:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 Gd6AvfiM9QfW for ; Mon, 22 Jun 2015 17:11:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DF51B303D for ; Mon, 22 Jun 2015 17:11:38 -0700 (PDT) Received: from [192.168.178.11] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5N0ARLg033991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2015 02:10:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_47A9A3D3-B332-4E10-A8A0-DAC02F56B6AE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 23 Jun 2015 02:11:15 +0200 Message-Id: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> To: Owen DeLong X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:11:40 -0000 --Apple-Mail=_47A9A3D3-B332-4E10-A8A0-DAC02F56B6AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 23 Jun 2015, at 2:03, Owen DeLong wrote: > Thus, you=E2=80=99ve got a scenario where NAT64 testing is inadequate = vs. NAT64 + Native V6 testing which was, in fact, the original question. Like I said, if you want to test for paths that don't support 1500 byte = path MTUs, please test with paths that don't support 1500 byte path MTUs = rather than make assumptions based on the presence or absence of a = packet size reducing apparatus. But IPv6 UDP applications shouldn't concern themselves with testing for = PMTUD black holes. This breaks TCP anyway, giving the user much bigger = fish to fry. And IPv4 UDP applications should leave the DF bit alone = because setting it to one can only end in tears.= --Apple-Mail=_47A9A3D3-B332-4E10-A8A0-DAC02F56B6AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 23 Jun 2015, at = 2:03, Owen DeLong <owen@delong.com> wrote:

Thus, you=E2=80=99ve got = a scenario where NAT64 testing is inadequate vs. NAT64 + Native V6 = testing which was, in fact, the original question.

Like I said, if = you want to test for paths that don't support 1500 byte path MTUs, please test with paths that don't support 1500 byte path = MTUs rather than make assumptions based on the presence or absence = of a packet size reducing apparatus.

But IPv6 UDP applications shouldn't = concern themselves with testing for PMTUD black holes. This breaks TCP = anyway, giving the user much bigger fish to fry. And IPv4 UDP = applications should leave the DF bit alone because setting it to one can = only end in tears.
= --Apple-Mail=_47A9A3D3-B332-4E10-A8A0-DAC02F56B6AE-- From nobody Mon Jun 22 17:12:49 2015 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 AB3231B3056 for ; Mon, 22 Jun 2015 17:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 JBti-PHxQRnf for ; Mon, 22 Jun 2015 17:12:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D55B1B303D for ; Mon, 22 Jun 2015 17:12:47 -0700 (PDT) Received: from [192.168.178.11] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5N0BlsI034021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2015 02:11:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <20150623000643.93C3C311CC30@rock.dv.isc.org> Date: Tue, 23 Jun 2015 02:12:35 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8A7D9143-A95E-4A54-A4E7-2D522EE4EEF2@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> <20150623000643.93C3C311CC30@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:12:48 -0000 On 23 Jun 2015, at 2:06, Mark Andrews wrote: > For named (DNS) we just set IPV6_USE_MIN_MTU=1 for *both* TCP and > UDP. So now application makers get to decide on TCP's segment size? Fuck that. From nobody Mon Jun 22 17:17:18 2015 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 191F91B306D for ; Mon, 22 Jun 2015 17:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iEzYkTpgVz9M for ; Mon, 22 Jun 2015 17:17:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 218651B3066 for ; Mon, 22 Jun 2015 17:17:15 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5N0HEpv000978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 17:17:14 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_3A066F7C-E63B-4313-8575-673DFD3AC042" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Mon, 22 Jun 2015 17:17:14 -0700 Message-Id: <14864C65-6802-469D-81E2-F8BEE876681E@delong.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 17:17:14 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:17:16 -0000 --Apple-Mail=_3A066F7C-E63B-4313-8575-673DFD3AC042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 22, 2015, at 17:11 , Iljitsch van Beijnum = wrote: >=20 > On 23 Jun 2015, at 2:03, Owen DeLong > wrote: >=20 >> Thus, you=E2=80=99ve got a scenario where NAT64 testing is inadequate = vs. NAT64 + Native V6 testing which was, in fact, the original question. >=20 > Like I said, if you want to test for paths that don't support 1500 = byte path MTUs, please test with paths that don't support 1500 byte path = MTUs rather than make assumptions based on the presence or absence of a = packet size reducing apparatus. >=20 > But IPv6 UDP applications shouldn't concern themselves with testing = for PMTUD black holes. This breaks TCP anyway, giving the user much = bigger fish to fry. And IPv4 UDP applications should leave the DF bit = alone because setting it to one can only end in tears. And once again, Iljitsch lets religion get in the way of understanding = the way the real world works=E2=80=A6 Meanwhile, the rest of us realize that this isn=E2=80=99t a matter of = someone who understands the issue deciding to test (or not) this = scenario, but an issue of the use of a particular technology in the test = environment obfuscating the issue in other environments thus calling for = an expansion of the capabilities of the test environment. Owen --Apple-Mail=_3A066F7C-E63B-4313-8575-673DFD3AC042 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 22, 2015, at 17:11 , Iljitsch van Beijnum <iljitsch@muada.com> = wrote:

On 23 Jun 2015, at = 2:03, Owen DeLong <owen@delong.com> wrote:

Thus, you=E2=80=99ve got = a scenario where NAT64 testing is inadequate vs. NAT64 + Native V6 = testing which was, in fact, the original question.

Like I said, if = you want to test for paths that don't support 1500 byte path MTUs, please test with paths that don't support 1500 byte path = MTUs rather than make assumptions based on the presence or absence = of a packet size reducing apparatus.

But IPv6 UDP applications shouldn't = concern themselves with testing for PMTUD black holes. This breaks TCP = anyway, giving the user much bigger fish to fry. And IPv4 UDP = applications should leave the DF bit alone because setting it to one can = only end in tears.

And once again, Iljitsch lets religion get in the way of = understanding the way the real world works=E2=80=A6

Meanwhile, the rest of = us realize that this isn=E2=80=99t a matter of someone who understands = the issue deciding to test (or not) this scenario, but an issue of the = use of a particular technology in the test environment obfuscating the = issue in other environments thus calling for an expansion of the = capabilities of the test environment.

Owen

= --Apple-Mail=_3A066F7C-E63B-4313-8575-673DFD3AC042-- From nobody Mon Jun 22 17:30:14 2015 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 05C6F1AD2AF for ; Mon, 22 Jun 2015 17:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 tDpEeHrLSK7T for ; Mon, 22 Jun 2015 17:30:11 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57931AD06B for ; Mon, 22 Jun 2015 17:30:10 -0700 (PDT) Received: from [192.168.178.11] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5N0Sxlj034095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2015 02:28:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <14864C65-6802-469D-81E2-F8BEE876681E@delong.com> Date: Tue, 23 Jun 2015 02:29:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52696645-3449-4AD4-8C80-1D17DFB52F2D@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> <14864C65-6802-469D-81E2-F8BEE876681E@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:30:13 -0000 On 23 Jun 2015, at 2:17, Owen DeLong wrote: >> But IPv6 UDP applications shouldn't concern themselves with testing = for PMTUD black holes. This breaks TCP anyway, giving the user much = bigger fish to fry. And IPv4 UDP applications should leave the DF bit = alone because setting it to one can only end in tears. > And once again, Iljitsch lets religion get in the way of understanding = the way the real world works=E2=80=A6 That would be true if I were talking about IPv4 UDP applications not = testing for PMTUD black holes. Which I also stand behind; the internet = needs larger packets, so any action to artificially limit packet sizes = is counterproductive. But my point about IPv6 UDP applications is not religious, it's just = simple common sense: if the protocol that occupies 85% of the internet's = packets is going to fail anyway, why bother doing extra work to keep one = particular application that occupies a small fraction of the remaining = 15% running? (I.e., with unlike with IPv4, with IPv6, TCP and UDP have = the same failure mode in the presence of PMTUD black holes. And if = depending on PMTUD is too deemed dangerous, then 1280 is the answer, = with no need for any testing.) From nobody Mon Jun 22 17:33:38 2015 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 DB8271B3103 for ; Mon, 22 Jun 2015 17:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vPG_fLxsm5gU for ; Mon, 22 Jun 2015 17:33:35 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7091B30AE for ; Mon, 22 Jun 2015 17:33:35 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.13,662,1427774400"; d="scan'208,217";a="320141143" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Jun 2015 20:31:56 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 22 Jun 2015 20:33:34 -0400 From: "Howard, Lee" To: Owen DeLong , Iljitsch van Beijnum Date: Mon, 22 Jun 2015 20:33:33 -0400 Thread-Topic: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications Thread-Index: AdCtTDwmjsailyfoTWWKdRf+uNsPBg== Message-ID: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> <14864C65-6802-469D-81E2-F8BEE876681E@delong.com> In-Reply-To: <14864C65-6802-469D-81E2-F8BEE876681E@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1ADF74EB50E2LeeHowardtwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:33:37 -0000 --_000_D1ADF74EB50E2LeeHowardtwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please remember to keep the tone professional. Thank you, Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D1ADF74EB50E2LeeHowardtwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please remember to keep the tone professional.

Thank you,

Lee

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_D1ADF74EB50E2LeeHowardtwcablecom_-- From nobody Mon Jun 22 17:33:47 2015 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 BEAAE1B3109 for ; Mon, 22 Jun 2015 17:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 f4HOx9KPi32K for ; Mon, 22 Jun 2015 17:33:44 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED901B3104 for ; Mon, 22 Jun 2015 17:33:44 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id BF28F34940D; Tue, 23 Jun 2015 00:33:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8A39C160077; Tue, 23 Jun 2015 00:34:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6BB99160076; Tue, 23 Jun 2015 00:34:22 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iKsaW4AsuK53; Tue, 23 Jun 2015 00:34:22 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 1F8CC160041; Tue, 23 Jun 2015 00:34:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C88C1311DE01; Tue, 23 Jun 2015 10:33:39 +1000 (EST) To: Iljitsch van Beijnum From: Mark Andrews References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> <20150623000643.93C3C311CC30@rock.dv.isc.org> <8A7D9143-A95E-4A54-A4E7-2D522EE4EEF2@muada.com> In-reply-to: Your message of "Tue, 23 Jun 2015 02:12:35 +0200." <8A7D9143-A95E-4A54-A4E7-2D522EE4EEF2@muada.com> Date: Tue, 23 Jun 2015 10:33:39 +1000 Message-Id: <20150623003339.C88C1311DE01@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:33:46 -0000 In message <8A7D9143-A95E-4A54-A4E7-2D522EE4EEF2@muada.com>, Iljitsch van Beijnum writes: > On 23 Jun 2015, at 2:06, Mark Andrews wrote: > > > For named (DNS) we just set IPV6_USE_MIN_MTU=1 for *both* TCP and > > UDP. > > So now application makers get to decide on TCP's segment size? > > Fuck that. Grow up. Yes, application developers have applications that just don't work with PMTUD. IPV6_USE_MIN_MTU was add back at the turn of the century for those applications. For the DNS, where unless you are pipelining DNS queries at a server or performing a zone transfer, all DNS transactions are less than 64K and 99.99999% are less than 4K the difference between 1280 and 1500 is a few of extra packets (for both UDP and TCP). DNS also has much tighter real life timing constraints than most applications. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 22 17:35:09 2015 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 309351B3123 for ; Mon, 22 Jun 2015 17:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GRicB1lSCCLG for ; Mon, 22 Jun 2015 17:35:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0871B3104 for ; Mon, 22 Jun 2015 17:34:40 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.4/8.14.2) with ESMTP id t5N0YdBa002457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 17:34:39 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <52696645-3449-4AD4-8C80-1D17DFB52F2D@muada.com> Date: Mon, 22 Jun 2015 17:34:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DCAFFCB-A668-41C4-9B11-7C8A8FBDB531@delong.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> <14864C65-6802-469D-81E2-F8BEE876681E@delong.com> <52696645-3449-4AD4-8C80-1D17DFB52F2D@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 17:34:39 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:35:07 -0000 > On Jun 22, 2015, at 17:29 , Iljitsch van Beijnum = wrote: >=20 > On 23 Jun 2015, at 2:17, Owen DeLong wrote: >=20 >>> But IPv6 UDP applications shouldn't concern themselves with testing = for PMTUD black holes. This breaks TCP anyway, giving the user much = bigger fish to fry. And IPv4 UDP applications should leave the DF bit = alone because setting it to one can only end in tears. >=20 >> And once again, Iljitsch lets religion get in the way of = understanding the way the real world works=E2=80=A6 >=20 > That would be true if I were talking about IPv4 UDP applications not = testing for PMTUD black holes. Which I also stand behind; the internet = needs larger packets, so any action to artificially limit packet sizes = is counterproductive. >=20 > But my point about IPv6 UDP applications is not religious, it's just = simple common sense: if the protocol that occupies 85% of the internet's = packets is going to fail anyway, why bother doing extra work to keep one = particular application that occupies a small fraction of the remaining = 15% running? (I.e., with unlike with IPv4, with IPv6, TCP and UDP have = the same failure mode in the presence of PMTUD black holes. And if = depending on PMTUD is too deemed dangerous, then 1280 is the answer, = with no need for any testing.) >=20 Because the tests against TCP are going to notice the problem where the = problem may get masked for UDP without the developer ever being the = wiser. Owen From nobody Mon Jun 22 17:59:09 2015 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 BA82C1B305E for ; Mon, 22 Jun 2015 17:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9FWR8l3DGM9j for ; Mon, 22 Jun 2015 17:59:07 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E601B313C for ; Mon, 22 Jun 2015 17:59:07 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 5C826349408; Tue, 23 Jun 2015 00:59:00 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3C625160041; Tue, 23 Jun 2015 00:59:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D164B160076; Tue, 23 Jun 2015 00:59:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XrnVXnucQeTz; Tue, 23 Jun 2015 00:59:39 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 7D18C160041; Tue, 23 Jun 2015 00:59:39 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 76B64311E0F3; Tue, 23 Jun 2015 10:58:56 +1000 (EST) To: Iljitsch van Beijnum From: Mark Andrews References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <6ACE98FF-8609-46B2-BD35-78D413BE6F0E@muada.com> <14864C65-6802-469D-81E2-F8BEE876681E@delong.com> <52696645-3449-4AD4-8C80-1D17DFB52F2D@muada.com> In-reply-to: Your message of "Tue, 23 Jun 2015 02:29:52 +0200." <52696645-3449-4AD4-8C80-1D17DFB52F2D@muada.com> Date: Tue, 23 Jun 2015 10:58:56 +1000 Message-Id: <20150623005856.76B64311E0F3@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 23 Jun 2015 00:59:08 -0000 In message <52696645-3449-4AD4-8C80-1D17DFB52F2D@muada.com>, Iljitsch van Beijnum writes: > On 23 Jun 2015, at 2:17, Owen DeLong wrote: > > >> But IPv6 UDP applications shouldn't concern themselves with testing > for PMTUD black holes. This breaks TCP anyway, giving the user much > bigger fish to fry. And IPv4 UDP applications should leave the DF bit > alone because setting it to one can only end in tears. > > > And once again, Iljitsch lets religion get in the way of understanding > the way the real world works > > That would be true if I were talking about IPv4 UDP applications not > testing for PMTUD black holes. Which I also stand behind; the internet > needs larger packets, so any action to artificially limit packet sizes is > counterproductive. > > But my point about IPv6 UDP applications is not religious, it's just > simple common sense: if the protocol that occupies 85% of the internet's > packets is going to fail anyway, why bother doing extra work to keep one > particular application that occupies a small fraction of the remaining > 15% running? (I.e., with unlike with IPv4, with IPv6, TCP and UDP have > the same failure mode in the presence of PMTUD black holes. And if > depending on PMTUD is too deemed dangerous, then 1280 is the answer, with > no need for any testing.) Actually the don't have the same failure modes. For UDP you send DNS request to a anycast cluster and you hits server A. It gets the PTB response which the kernel records but the DNS server can't do anything with it as the transaction state is gone. The client times out and sends a second UDP DNS request. This hits server B. The client times out and sends a third UDP DNS request. This hits server C. The client times out and sends a fourth UDP DNS request. This hits server A which may or may not still remember the PMTU from the PTB. For TCP the PTB should go to server A and TCP transaction should resume. If the PTB gets lost / misdirected then by the time server A notices it is too late. The client has given up. Add multiple drops in MTU along the path and it gets worse. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jun 23 04:28:15 2015 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 5F4041ACE6D for ; Tue, 23 Jun 2015 04:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 Py0IDoa8N1Jc for ; Tue, 23 Jun 2015 04:28:12 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4390E1ACE56 for ; Tue, 23 Jun 2015 04:28:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5NBS5Wr032762; Tue, 23 Jun 2015 13:28:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 01962204B47; Tue, 23 Jun 2015 13:30:59 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EA274201F23; Tue, 23 Jun 2015 13:30:58 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5NBS173005377; Tue, 23 Jun 2015 13:28:04 +0200 Message-ID: <558942C1.8020907@gmail.com> Date: Tue, 23 Jun 2015 13:28:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Owen DeLong References: <5587EFDD.6030807@gmail.com> <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com> <55886B02.80604@gmail.com> <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com> In-Reply-To: <5D096119-447C-4637-BE54-DD759CDA1EFF@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 23 Jun 2015 11:28:14 -0000 Le 22/06/2015 22:50, Owen DeLong a écrit : >>>> It is better to tell the operator to provide a /63 to >>>> smartphones (not a /64), with DHCPv6 Prefix Delegation. That >>>> will fix it. >>> >>> No… If you’re going to go to PD, a /63 is stupid. Ideally, use a >>> /48, >> >> Well, one cellular network operator has a /47 to 'share' with all >> its customer UEs. If that operator gave a /48 to an UE it could >> satisfy only 2 such customers, not millions. > > That is a problem that is easy to solve with a simple interaction > with their RIR. > > Give me a break. > > We should not be designing around providers that didn’t ask for > enough IPv6 space for their deployments. We should educate those > providers. IPv6 space is easy to get. A cellular network is an ISP > almost by definition. > > There isn’t a single RIR on the planet that won’t grant you at least > a /32 if you walk up and say “I’m an ISP, /32 please” in any credible > way. > > (modulo payment of fees, etc., but you get the point) So I looked at the RIR database. The RIR already allocated a /19 to that operator. But the operator fitted all its end users within a /47 (each getting a /64.) The operator should fit all its end users within a /39 (not a /47), and each end user must get a /63. At least. Is RIR to be questioned when the operator delivers only /64s to end users? Or the operator? >>> but at least provide enough subnets to cover BT, USB, 2.4, and >>> 5Ghz plus some headroom for future applications. >> >> I agree, headroom should be provided. >> >>>>> *) Internet Sharing on the Mac Today, regular internet >>>>> sharing (from your ethernet to Wi-Fi for example) does not >>>>> support IPv6 because of the limited use cases, and the lack >>>>> of demand for it. >>>> >>>> If you get done the above then you get Internet Sharing on the >>>> Mac Today as well, for free. >>> >>> Since iOS and OSX are separate code bases, I’m not sure why you >>> think that. >> >> Because the DHCPv6 Prefix Delegation is a userspace application >> implementing a protocol - suffices it to compile on each of these >> code bases. It acts the same everywhere. > > Yes and no. > >> It's not a GUI, or some kernel module, or some AF-dependent >> software. > > Well… It is actually AF-dependent. DHCPv6 will not work on IPv4 very > well at all. Right. I meant it's not an app supposed to work on both families. It is pure v6. [...] Alex From nobody Tue Jun 23 13:05:47 2015 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 5701E1A8AFC for ; Tue, 23 Jun 2015 13:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.08 X-Spam-Level: *** X-Spam-Status: No, score=3.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, 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 6iOfg2xDo-IU for ; Tue, 23 Jun 2015 13:05:44 -0700 (PDT) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 75FB91A8A01 for ; Tue, 23 Jun 2015 13:05:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0F3C7401FC for ; Tue, 23 Jun 2015 22:05:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V8WvRirM7LA for ; Tue, 23 Jun 2015 22:05:40 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id D9187401EA for ; Tue, 23 Jun 2015 22:05:40 +0200 (CEST) Message-ID: <5589BC13.6050507@globis.net> Date: Tue, 23 Jun 2015 22:05:39 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: v6ops@ietf.org References: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> In-Reply-To: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam 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, 23 Jun 2015 20:05:45 -0000 fred@cisco.com wrote: > The working group last call for this draft announced last week > continues for another week. Please feel free to comment on it. > I have read this draft. It is very well written, the intention is clear, and I support it. Three comments: Comment 1 Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that of the IPv4 address being translated." and "an IPv6 Prefix identical to that of the IPv6 address being translated" Surely that should be a "longest-matching-prefix based on CIDR [RFC4632]" Comment 2 Operational complexity: Suggest Adding at the end of this paragraph /Source address selection rules on hosts may not have enough information to be able to select the appropriate source address for outbound sessions in the presence of SIIT./ Comment 3 / Overlapping EAMs SHOULD be considered an error, and attempts to insert them into the EAMT SHOULD be blocked. The behaviour of an SIIT implementation when overlapping EAMs are present in the EAMT is left undefined./ I believe that this is an unnecessary restriction for correct specification/operation provided CIDR/longest-matching-prefix is specified. Nits s/The IPv4-translatable IPv6 addresses must not only be assigned to the IPv6 nodes participating in SIIT/ The IPv4-translatable IPv6 addresses not only has to be assigned to the IPv6 nodes participating in SIIT/ s/number his entire/number their entire/ s/addresses he assigns/addresses they assign/ s/are REQUIRED to/MUST/ regards, RayH From nobody Tue Jun 23 14:02:10 2015 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 8D59B1A00E1 for ; Tue, 23 Jun 2015 14:02:04 -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 RiceJg-JXqm0 for ; Tue, 23 Jun 2015 14:02:03 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A061A00E3 for ; Tue, 23 Jun 2015 14:02:03 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so117230033wic.1 for ; Tue, 23 Jun 2015 14:02: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; bh=tk/QJ4xI9UbUMD3o0hVDGIlwLc1oc3BunFPg126mvKY=; b=G6YwgLuqxqFpf/Cz1amJoTg6/L25Vxo3mpD2I3RJV91NUaUUk3kkWgTzUJ1JSUq7Xr fFDnMXejD4YJjg+YNewp8rcm/o5Nr6fTtMZyfVF4rLRSySex/jY43trTinlMvCnyLyrE dsdDkoQHwZYeumw1lEiGbyXe+50BEp1pggaezVrPHsAV8ecCeo2nqJN6hmqPc/x1gpxs iQ/PU+yKtoDJg4k+/UW2+q6S3W2i7bDfMLFyt0yYnk8zjPAC/G2an31o3q9lpvb28RAG 37JfeDjOf3aispCIemehJJYx7c2p9tMCRsOZqfIHsWD+2wnA8pz3Tr6IHde+sIbFyQY/ IFEA== MIME-Version: 1.0 X-Received: by 10.180.9.225 with SMTP id d1mr6767207wib.73.1435093322154; Tue, 23 Jun 2015 14:02:02 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Tue, 23 Jun 2015 14:02:02 -0700 (PDT) In-Reply-To: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> References: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> Date: Tue, 23 Jun 2015 14:02:02 -0700 Message-ID: From: Ca By To: Fred Baker Content-Type: multipart/alternative; boundary=001a11c2b2d6afc8ed051935b371 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam 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, 23 Jun 2015 21:02:04 -0000 --001a11c2b2d6afc8ed051935b371 Content-Type: text/plain; charset=UTF-8 I have read draft-ietf-v6ops-siit-eam WGLC and find it useful and mature enough to move forwards Regards, Cameron On Sun, Jun 21, 2015 at 11:00 AM, wrote: > The working group last call for this draft announced last week > continues for another week. Please feel free to comment on it. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c2b2d6afc8ed051935b371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read=C2=A0draft-ietf-v6ops-siit-eam WGLC=C2=A0and f= ind it useful and mature enough to move forwards

Regards= ,
Cameron

O= n Sun, Jun 21, 2015 at 11:00 AM, <fred@cisco.com> wrote:
The working group last call for this draft announced last we= ek
continues for another week.=C2=A0 Please feel free to comment on it.

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

--001a11c2b2d6afc8ed051935b371-- From nobody Wed Jun 24 00:15:50 2015 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 50CFB1B3057 for ; Wed, 24 Jun 2015 00:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wBB_6NXZBvJv for ; Wed, 24 Jun 2015 00:15:46 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E621A8898 for ; Wed, 24 Jun 2015 00:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1435130146; x=2299043746; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8CAfIQGH6EtnGRQB5uF+aSQoFYMMuyMi2qS2AMrOrA8=; b=3Y0IlW0JvA/aykjNKCofYRXRMIVa7Y7pP/HNSofYuMKzxZf0GzX7GMsMYv3jtmpB gaYfAmSoxdl0V2JDP3J/0zGhuYI5HssK2gmynOgB4PP3ggAJ1/neuy8op6VT1Cug zcMgNA7Hk+FB7i0nmT1MCYvSmZOu77ZrcvIXCP0QdoOe4pin5gbguyENYoVALo3M hbIReV2mCBvM/pfeHExBoy5ZclcWXVnEHpMUPGj4Rca4jx6HAd2pJ5NGZP63lOLH Z+pW8SEL3SmOT0nFNWHejkc6OxlQ2enyzevtoqP1Uoy1EVUCSFm6XHc1+y1rR5C/ LgV4fmzf+lvr5DY2oozknw==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 0D.84.18963.2295A855; Wed, 24 Jun 2015 00:15:46 -0700 (PDT) X-AuditID: 11973e12-f79456d000004a13-17-558a5922139f Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id C5.7B.32123.1295A855; Wed, 24 Jun 2015 00:15:46 -0700 (PDT) Received: from [17.153.36.231] by jimbu.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NQF008F0TI8PY20@jimbu.apple.com> for v6ops@ietf.org; Wed, 24 Jun 2015 00:15:45 -0700 (PDT) Content-type: multipart/alternative; boundary="Apple-Mail=_6E72A312-58BA-48DB-AF86-73B9467A48E9" MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: David Schinazi In-reply-to: Date: Wed, 24 Jun 2015 00:15:44 -0700 Message-id: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> References: To: v6ops@ietf.org X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FAYrKsU2RVqsH8Xq8XpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8frZfvaCz1MZK/ZcZmtgvFzXxcjBISFgIrGwPaGLkRPIFJO4 cG89WxcjF4eQwF5GiRML57BDJEwkTh2YxAxiCwm0MknsOOsIUfSJUeJtwxmwBLNAksS+J6dZ QIbyCuhJPOqUBQkLCxhKHLz9nQkkzCagJXFgjRFImFPAVqJ770tGkDCLgKrErG2VEENyJOau /ccEYvMK2EjMPTATaquNxJfdPawgtoiAkMSOZ01MEJfJSmx908oEco2EQAebxNPz25gmMArN QnLQLISDIMLaEssWvmYGCTML6EhMXsiIKgxhfzx/hGkBI9sqRqHcxMwc3cw8E73EgoKcVL3k /NxNjKBgn24ntIPx1CqrQ4wCHIxKPLwMnztDhVgTy4orcw8xSnOwKInzbv8DFBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cC4MFjuXYT7th6B66HSHqLl3K8qDq+UC7zgGnlC0Xz2s6g3z1Jk p75escd9+4Jv+sYO6v02L1h1X7I+fH9yyqd1HxY37tb5POvo9jmb9LO05Z/EhzPtMOuzn/kr 2Utz8nUx29UaIoau7t+TKr7sfF9tpzBBa4HA7CgekUXxnKyvy3JCk3ael5mmxFKckWioxVxU nAgA+1agLVcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUiON1OVVcpsivUYOlmRovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/Wz/ewFn6cyVuy5zNbAeLmui5GTQ0LAROLUgUnMELaYxIV7 69lAbCGBViaJHWcduxi5gOxPjBJvG86AFTELJEnse3KapYuRg4NXQE/iUacsSFhYwFDi4O3v TCBhNgEtiQNrjEDCnAK2Et17XzKChFkEVCVmbauEGJIjMXftPyYQm1fARmLugZnMEFttJL7s 7mEFsUUEhCR2PGtigrhMVmLrm1amCYz8s5DcMAvhBoiwtsSyha+ZQcLMAjoSkxcyogpD2B/P H2FawMi2ilGgKDUnsdJYL7GgICdVLzk/dxMjKDwbCoN3MP5ZZnWIUYCDUYmHd8WHzlAh1sSy 4srcQ4wSHMxKIrwM/l2hQrwpiZVVqUX58UWlOanFhxilOViUxHkXLG8JFRJITyxJzU5NLUgt gskycXBKNTDWOQuIT2boV136NPLBMckbZof4FjxcHDPne0TJJMNDU8oYfjg8ke8M7GORr9IJ 7ct+lMM1f3OfVcdx1XVv7vLuesn+f+/5zzuutq7ne7H2vppXedLZNPWTmiXyNxgdFme/Vrn1 jcnCp2KjTlvLbEZl+ScC95ZeDe5n7lz30vGcw6WgtUtKhXcqsRRnJBpqMRcVJwIACvoIiksC AAA= Archived-At: Cc: Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 24 Jun 2015 07:15:49 -0000 --Apple-Mail=_6E72A312-58BA-48DB-AF86-73B9467A48E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi again, First off, thanks everyone for the feedback and advice! Here's an attempt at answering the questions that arose since my last = post. *) Personal hotspot on iOS Currently the hotspot shares whatever address families it gets from the = cellular network. The current implementation broadcasts an IPv6-only network if the = cellular network is of that type, but I could imagine carriers bringing up IPv4 specifically when using = this feature. Our custom version of prefix sharing is described in more detail here: = https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prp= roxy.c = It supports creating multiple hotspots at the same time, such as Wi-FI = and Bluetooth and bridges them. *) iOS and cellular carrier networks I do not know if or when specific carriers plan to change their IPv6 = policies. That said, we do believe there is a growing trend towards IPv6. When roaming between carriers, = your device will get new addresses and could possibly switch between address families. *) VPN Our implementation of IKEv2, which is our current recommended VPN = protocol, supports IPv6 on both the inside and outside of the tunnel. Other protocols are currently not = guaranteed to be fully compatible. *) Internet Sharing on the Mac We agree that it would be nice to support IPv6, but the risk/reward = tradeoff isn't necessarily there yet. *) Internet Sharing on the Mac - NAT64 testing mode To reset expectations on this feature, it targets developers of = networked apps that are not knowledgeable in IPv6, most likely not anyone on this list. If you're writing your own = sockets code that works on dual-stack and have a dual-stacked server, you probably know what you're doing = already. The goal is really not performance optimization, simply checking that your app will manage to = connect to your server at all. Realistically, today any service accessible by apps over IPv6 is also = available over IPv4. Debugging path MTU issues is currently out of scope of this test network. The App Store = IPv6 compatibility requirement will not reject an app solely based on tests using the NAT64 test network. = The NAT64+DNS64 on the Mac will currently only query for A records and return synthesized AAAA records = to its clients, it effectively ignores any AAAA records it receives from the wide area. We're looking into = improving this feature, we agree that adding real IPv6 connectivity and using a different prefix would be better. *) Happy Eyeballs Thanks to everyone for the advice on this topic, we're looking into the = best compromise between providing our customers with good response times in the short term and helping = them in the long term by helping the deployment of IPv6. An issue with RFC 6555 is that it was designed in a = mindset where DNS resolution is provided by synchronous APIs such as getaddrinfo. In practice, your AAAA = and A records do not come back at the same time and if you receive the A record first, every = millisecond you wait before sending out a SYN is an IPv6 tax you're levying on your users. This being helpful in the long = term, there must be a sweet spot. To clarify our use of the RTT to prioritize addresses, we use historical = RTT measurements of all TCP packets on that route. If and when we release an updated implementation, I will = update this list. *) 464XLAT We've considered using this technology and decided that it was not the = best course of action. This doesn't mean we will never consider it and we're definitely interested in = discussing pros and cons but in my humble (personal) opinion, calling us names to "get our attention" is = not likely to convince us that 464XLAT is the One True Path to IPv6 deployment. As mentioned in my last message, all these details only reflect the = current betas and can change in the future. Thanks, David > On Jun 19, 2015, at 14:46, David Schinazi wrote: >=20 > Hi everyone, >=20 > I'd like to clarify a few points about Apple's IPv6 announcements = during WWDC 2015. > The video (streaming with Safari or download with all browsers) and = slides of that talk > are available at: https://developer.apple.com/videos/wwdc/2015/?id=3D719= >=20 > *) Personal hotspot on iOS > If your iPhone has dual-stack connectivity on its cellular network, = the hotspot it creates > will be dual-stack as well. The phone will share its prefix with Wi-Fi = clients. >=20 > *) Internet Sharing on the Mac > Today, regular internet sharing (from your ethernet to Wi-Fi for = example) does not > support IPv6 because of the limited use cases, and the lack of demand = for it. >=20 > *) Internet Sharing on the Mac - NAT64 testing mode > The NAT64 test mode was designed to help developers ensure that their = app can still > function with IPv6-only NAT64+DNS64 connectivity and communicate with = their IPv4 > server, even if the developer does not have access to the IPv6 = internet. That NAT64 > network does not have IPv6 connectivity to the global IPv6 internet. = As such, the current > version advertises addresses from 2001::/64 instead of ULAs to = simulate real IPv6 > connectivity, as all IPv6 packets are terminated at the NAT64 server = on the Mac. > This implementation detail could change in the future. >=20 > *) Making IPv4 literals work on NAT64 networks when using high-level = APIs > Starting with this year's versions, if you use NSURLSession to connect = to an IPv4 > literal on an IPv6-only NAT64-DNS64 network, the API will bump in a = IPv6 literal > synthesized using RFC 7050. Note that this will not happen when using = sockets > directly. We do not support under-the-sockets bump-in-API (RFC 3338) = and we > do not support 464XLAT. >=20 > *) Happy Eyeballs > We've heard feedback on our Happy Eyeballs implementation and are = investigating > this topic. >=20 > Note that this reflects how these technologies work in the current = versions of the > 2015 betas, many of these details could change in future betas. Please = keep in mind > that these betas are previews and we welcome feedback on improving = them. >=20 > Feel free to contact me if you have any questions, I will also attend = IETF93. >=20 > Thanks, > David Schinazi > Apple CoreOS Networking Engineer --Apple-Mail=_6E72A312-58BA-48DB-AF86-73B9467A48E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi again,

First off, thanks = everyone for the feedback and advice!
Here's an attempt at = answering the questions that arose since my last post.

*) Personal hotspot on iOS
Currently the = hotspot shares whatever address families it gets from the cellular = network.
The current implementation broadcasts an = IPv6-only network if the cellular network is of that type,
but I could imagine carriers bringing up IPv4 specifically = when using this feature. Our custom version
of prefix = sharing is described in more detail here:
https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netin= et6/nd6_prproxy.c
It supports creating multiple = hotspots at the same time, such as Wi-FI and Bluetooth and bridges = them.

*) iOS and cellular carrier = networks
I do not know if or when specific carriers plan = to change their IPv6 policies. That said, we do believe
there is a growing trend towards IPv6. When roaming between = carriers, your device will get new
addresses and could = possibly switch between address families.

*) = VPN
Our implementation of IKEv2, which is our current = recommended VPN protocol, supports IPv6 on both
the inside = and outside of the tunnel. Other protocols are currently not guaranteed = to be fully compatible.

*) Internet Sharing = on the Mac
We agree that it would be nice to support IPv6, = but the risk/reward tradeoff isn't necessarily there yet.

*) Internet Sharing on the Mac - NAT64 testing = mode
To reset expectations on this feature, it targets = developers of networked apps that are not knowledgeable
in = IPv6, most likely not anyone on this list. If you're writing your own = sockets code that works on dual-stack
and have a = dual-stacked server, you probably know what you're doing already. The = goal is really not
performance optimization, simply = checking that your app will manage to connect to your server at all.
Realistically, today any service accessible by apps over IPv6 = is also available over IPv4. Debugging path
MTU issues is = currently out of scope of this test network. The App Store IPv6 = compatibility requirement will
not reject an app solely = based on tests using the NAT64 test network. The NAT64+DNS64 on the Mac = will
currently only query for A records and return = synthesized AAAA records to its clients, it effectively ignores any
AAAA records it receives from the wide area. We're looking = into improving this feature, we agree that adding
real = IPv6 connectivity and using a different prefix would be better.

*) Happy Eyeballs
Thanks to = everyone for the advice on this topic, we're looking into the best = compromise between providing
our customers with good = response times in the short term and helping them in the long term by = helping the
deployment of IPv6. An issue with RFC 6555 is = that it was designed in a mindset where DNS resolution is
provided by synchronous APIs such as getaddrinfo. In = practice, your AAAA and A records do not come back
at the = same time and if you receive the A record first, every millisecond you = wait before sending out a SYN is
an IPv6 tax you're = levying on your users. This being helpful in the long term, there must = be a sweet spot. To
clarify our use of the RTT to = prioritize addresses, we use historical RTT measurements of all TCP = packets on
that route. If and when we release an updated = implementation, I will update this list.

*) = 464XLAT
We've considered using this technology and decided = that it was not the best course of action. This doesn't
mean= we will never consider it and we're definitely interested in discussing = pros and cons but in my
humble (personal) opinion, calling = us names to "get our attention" is not likely to convince us that = 464XLAT
is the One True Path to IPv6 deployment.

As mentioned in my last message, all these = details only reflect the current betas and can change in the future.

Thanks,
David


On Jun 19, 2015, at 14:46, = David Schinazi <dschinazi@apple.com> wrote:

Hi everyone,

I'd like to clarify a few points about = Apple's IPv6 announcements during WWDC 2015.
The video = (streaming with Safari or download with all browsers) and slides of that = talk
are available at: https://developer.apple.com/videos/wwdc/2015/?id=3D719

*) Personal = hotspot on iOS
If your iPhone has dual-stack = connectivity on its cellular network, the hotspot it creates
will be dual-stack as well. The phone will share its prefix = with Wi-Fi clients.

*) Internet Sharing on the = Mac
Today, regular internet sharing (from your ethernet = to Wi-Fi for example) does not
support IPv6 = because of the limited use cases, and the lack of demand for = it.

*) Internet Sharing on the Mac - NAT64 testing mode
The NAT64 test mode was designed to help developers ensure = that their app can still
function with IPv6-only = NAT64+DNS64 connectivity and communicate with their IPv4
server, even if the developer does not have access to the = IPv6 internet. That NAT64
network does not have IPv6 = connectivity to the global IPv6 internet. As such, the current
version advertises addresses from 2001::/64 instead of ULAs = to simulate real IPv6
connectivity, as all IPv6 = packets are terminated at the NAT64 server on the Mac.
This implementation detail could change in the = future.

*) Making IPv4 literals work on NAT64 = networks when using high-level APIs
Starting with = this year's versions, if you use NSURLSession to connect to an = IPv4
literal on an IPv6-only NAT64-DNS64 network, the = API will bump in a IPv6 literal
synthesized using = RFC 7050. Note that this will not happen when using sockets
directly. We do not support under-the-sockets bump-in-API = (RFC 3338) and we
do not support 464XLAT.

*) Happy = Eyeballs
We've heard feedback on our Happy = Eyeballs implementation and are investigating
this = topic.

Note that this reflects how these technologies work in the = current versions of the
2015 betas, many of these = details could change in future betas. Please keep in mind
that these betas are previews and we welcome feedback on = improving them.

Feel free to contact me if you have = any questions, I will also attend IETF93.

Thanks,
David Schinazi
Apple CoreOS Networking = Engineer

= --Apple-Mail=_6E72A312-58BA-48DB-AF86-73B9467A48E9-- From nobody Wed Jun 24 00:34:05 2015 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 BB9CF1B310A for ; Wed, 24 Jun 2015 00:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Z3pZzXhQ3cmD for ; Wed, 24 Jun 2015 00:34:02 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386211B3109 for ; Wed, 24 Jun 2015 00:34:02 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=60009 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z7fC3-0000Ea-Ir; Wed, 24 Jun 2015 09:33:59 +0200 Date: Wed, 24 Jun 2015 09:32:56 +0200 From: Tore Anderson To: Ray Hunter Message-ID: <20150624093256.0075867d@echo.ms.redpill-linpro.com> In-Reply-To: <5589BC13.6050507@globis.net> References: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> <5589BC13.6050507@globis.net> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam 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, 24 Jun 2015 07:34:03 -0000 * Ray Hunter > I have read this draft. It is very well written, the intention is > clear, and I support it. Hi Ray -- thank you! > Comment 1 > Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that > of the IPv4 address being translated." and "an IPv6 Prefix identical > to that of the IPv6 address being translated" > > Surely that should be a "longest-matching-prefix based on CIDR > [RFC4632]" > Comment 3 > / Overlapping EAMs SHOULD be considered an error, and attempts to > insert them into the EAMT SHOULD be blocked. The behaviour of an > SIIT implementation when overlapping EAMs are present in the EAMT > is left undefined./ > > I believe that this is an unnecessary restriction for correct > specification/operation provided CIDR/longest-matching-prefix is > specified. The reasoning behind this restiction was that it would otherwise be possible to create a situation that does not facilitate bi-directional communcation. For example: EAM #1: 192.0.2.1/32, 2001:db8::/32 EAM #2: 198.51.100.1/32, 2001:db8:c000:201::/128 This would cause 192.0.2.1 to be translated to 2001:db8:c000:201::, which in turn would be translated to 198.51.100.1. That will likely break whatever use-case was intended. Then again, I suppose it might as well be allowed. If the operator shoots himself in the foot he can deal with that himself...so, yeah, we'll lift the restriction and use CIDR. That said, do you think the draft should discuss what to do when multiple EAMs contain *identical* IPv4/IPv6 prefix values? For example: EAM #1: 192.0.2.0/24, 2001:db8:a::/48 EAM #2: 192.0.2.0/24, 2001:db8:b::/48 Or: EAM #1: 192.0.2.1/32, 2001:db8::/128 EAM #2: 198.51.100.1/32, 2001:db8::/128 Suggested text would of course be very welcome. > Comment 2 > Operational complexity: > > Suggest Adding at the end of this paragraph > /Source address selection rules on hosts may not have enough information > to be able to select the appropriate source address for outbound > sessions in the presence of SIIT./ Good idea, we'll add this. A reference to RFC6724 is probably appropriate here too. > Nits > [...] Will fix. Thanks again! Tore From nobody Wed Jun 24 00:53:15 2015 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 611391B3174 for ; Wed, 24 Jun 2015 00:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 YSOjBdwBivuQ for ; Wed, 24 Jun 2015 00:53:12 -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 8C37B1B3175 for ; Wed, 24 Jun 2015 00:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1647; q=dns/txt; s=iport; t=1435132376; x=1436341976; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iqubm691uS9eAIbUbr0owYQhH9THfp0u5iSoxahUeb8=; b=gcFXZNyimYNLhZKVWOImioGX1o5XZRJwG1LEAXw729s18Il3HwxL7Ynt mlZ+2bCmbhhbsnKupCxCaSVdtb7P/ebI8mYpcO5R/CgtjkwOO2q4VpxIt UtrSyjGqqdBM7nKNRJ/xV6OhNehZFa2pPWWOShPx+tcTYD+B845LyoL3v 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C4CAC1YIpV/4ENJK1bgxBUX4MeukEJgVwKhXgCgUg4FAEBAQEBAQGBCkEDg18BAQQBAiBWEAsYAgImAgIoLwYTiC8NtlGWTwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYophFMzB4JoL4EUBYx9hwKEWIQwgkmBfIY5kAAmgj2BXR4xAYJHAQEB X-IronPort-AV: E=Sophos;i="5.13,671,1427760000"; d="scan'208";a="162279890" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 24 Jun 2015 07:52:55 +0000 Received: from [10.24.206.20] ([10.24.206.20]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5O7qsDw026090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2015 07:52:55 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <1116D021-72F6-418A-A430-4A911F05109B@delong.com> Date: Wed, 24 Jun 2015 00:52:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1DD3B5D4-9F8B-4EE2-BC53-D840E9758FB9@delong.com> <629902C3-6393-42DD-88E2-C72384EE8529@muada.com> <1116D021-72F6-418A-A430-4A911F05109B@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Vividh Siddha , v6ops@ietf.org Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 24 Jun 2015 07:53:14 -0000 On 22-Jun-2015 02:53 pm, Owen DeLong wrote: >=20 >> On Jun 22, 2015, at 13:50 , Iljitsch van Beijnum = wrote: >>=20 >> On 22 Jun 2015, at 18:49, Owen DeLong wrote: >>=20 >>>> So if you guys currently look at the RTT for the three-way = handshake, it would probably help if you could look at the RTT for data = packets instead. >>=20 >>> Pretty hard to look at the data RTT when establishing a connection. = How do you see that working? >>=20 >> I don't know the details of Apple's (or anyone else's) happy eyeballs = implementation. If they set up connections, measure the RTT for the = three three-way handshake and then abandon the higher RTT session, or = initiate connections in parallel and only pursue the one that connects = first, then you're right, this would be a problem. On the other hand, if = they do an HTTP request over IPv4 and one over IPv6, then an RTT for = data segments would be available. >=20 > The few tcpdump logs I=E2=80=99ve looked at would seem to indicate = that most (including Apple=E2=80=99s) HE implementations I=E2=80=99ve = encountered do the former rather than the latter. Also as near as I can = tell, state isn=E2=80=99t tracked from one connection to the next, each = new connect() loop sprays a new set of SYNs and then abandons all but = the one it selects. >=20 > YMMV Best explanation of Apple's implementation is by Josh Graessley, who = designed (and I believe also coded) the algorithm, = http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00009.html. Things = have probably improved since 2011. -d From nobody Wed Jun 24 00:58:19 2015 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 76DEB1B319B for ; Wed, 24 Jun 2015 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 vHAo8ULMrsfJ for ; Wed, 24 Jun 2015 00:58:16 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) (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 C9D891B3191 for ; Wed, 24 Jun 2015 00:58:15 -0700 (PDT) Received: from [85.158.136.35] by server-4.bemta-5.messagelabs.com id FD/CE-21074-6136A855; Wed, 24 Jun 2015 07:58:14 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-7.tower-125.messagelabs.com!1435132692!41339514!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8492 invoked from network); 24 Jun 2015 07:58:12 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-7.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jun 2015 07:58:12 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Wed, 24 Jun 2015 08:58:08 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Wed, 24 Jun 2015 08:58:12 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Wed, 24 Jun 2015 08:58:11 +0100 From: "Heatley, Nick" To: David Schinazi , "v6ops@ietf.org" Thread-Topic: [v6ops] Apple and IPv6, a few clarifications Thread-Index: AQHQqtmCDp4NuF4LXEi+0Lv8nVYebZ27NLQAgAAYrgA= Date: Wed, 24 Jun 2015 07:58:11 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303ECB135@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> In-Reply-To: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303ECB135UK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 24 Jun 2015 07:58:18 -0000 --_000_6536E263028723489CCD5B6821D4B21303ECB135UK30S005EXS06EE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of David Schinazi Sent: 24 June 2015 08:16 To: v6ops@ietf.org Cc: Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications Hi again, First off, thanks everyone for the feedback and advice! Here's an attempt at answering the questions that arose since my last pos= t. *) Personal hotspot on iOS Currently the hotspot shares whatever address families it gets from the c= ellular network. The current implementation broadcasts an IPv6-only network if the cellula= r network is of that type, but I could imagine carriers bringing up IPv4 specifically when using thi= s feature. Our custom version of prefix sharing is described in more detail here: https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_pr= proxy.c It supports creating multiple hotspots at the same time, such as Wi-FI an= d Bluetooth and bridges them. [Heatley, Nick] Thanks for sharing the information, David. When you say you imagine carries bringing up IPv4 specifically for person= al hotspot, not sure what you mean - do you mean a parallel, dedicated "h= otspot APN"? Many carriers across the globe, for their own individual business reasons= , have a common APN approach for the mass consumer market, but neverthele= ss desire this common APN to go IPv6-only. So I am nervous about how to support *any* device on a personal hotspot f= rom an IPv6-only iOS handset in this way, do you have any more details on= =20your intentions here? Thanks for the discussion. Nick NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. --_000_6536E263028723489CCD5B6821D4B21303ECB135UK30S005EXS06EE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

 

 

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of David Schinazi
Sent: 24 June 2015 08:16
To: v6ops@ietf.org
Cc: Vividh Siddha
Subject: Re: [v6ops] Apple and IPv6, a few clarifications

 

Hi again,

First off, thanks everyone for the feedback and advice!
Here's an attempt at answering the questions that arose since my last pos= t.

*) Personal hotspot on iOS
Currently the hotspot shares whatever address families it gets from the c= ellular network.
The current implementation broadcasts an IPv6-only network if the cellula= r network is of that type,
but I could imagine carriers bringing up IPv4 specifically when using thi= s feature. Our custom version
of prefix sharing is described in more detail here:
https://opensource.apple.com/source/xnu/xnu-2782.1.97= /bsd/netinet6/nd6_prproxy.c

It supports creating multiple hotspots at the same= =20time, such as Wi-FI and Bluetooth and bridges them.

[Heatley, Nick] Thanks for sharing the information, David.

When you say you ima= gine carries bringing up IPv4 specifically for personal hotspot, not sure= =20what you mean - do you mean a parallel, dedicated “hotspot APN&#= 8221;?

Many carriers across= =20the globe, for their own individual business reasons, have a common AP= N approach for the mass consumer market, but nevertheless desire this com= mon APN to go IPv6-only.

 

So I am nervous abou= t how to support *any* device on a personal hotspot from an IPv6-o= nly iOS handset in this way, do you have any more details on your intenti= ons here?

Thanks for the discu= ssion. Nick

 





 

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is in= tended=20 for the above-named person(s).  If you are not the intended recipien= t,=20 notify the sender immediately, delete this email from your system and do = not=20 disclose or use for any purpose. 
 
We may monitor all i= ncoming=20 and outgoing emails in line with current legislation. We have taken steps= =20to=20 ensure that this email and attachments are free from any virus, but it re= mains=20 your responsibility to ensure that viruses do not adversely affect you. <= /P>

EE Limited
Registered in England and Wales
Company Registered Nu= mber:=20 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfi= eld,=20 Hertfordshire, AL10 9BW

 

--_000_6536E263028723489CCD5B6821D4B21303ECB135UK30S005EXS06EE_-- From nobody Wed Jun 24 01:08:14 2015 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 3F7941B31BF for ; Wed, 24 Jun 2015 01:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 A0FBWdGrUVWl for ; Wed, 24 Jun 2015 01:08:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1711B31CC for ; Wed, 24 Jun 2015 01:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22071; q=dns/txt; s=iport; t=1435133288; x=1436342888; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=I86SpnU8WZZxDcaoF43pV7OtVmASCE8DKb2Ek5lUkVs=; b=kQzHujPKtab9CS7U0pDWJNcJwa8hFcnixp9UarXkAnstpqM8fLtAHoOA uCK5sjFr2GfuGH3J9nOp848K24GaRrtDpNFgXhJtJC2k/DHkd1Wel2E+4 vgVyCx3B/efQChHEeVLXYx4OD1E+UWWxNPbHQQdg6pKwouss0h5fUfuf7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOAwD2ZIpV/5BdJa1bgxBUX70oCYFcAQuFdgKBSTgUAQEBAQEBAYEKhCMBAQQBAQEaSgcLEAsOCicHJx8RBhOILw3NKwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEikiBAoQtDkcEB4MXgRQFhRyHYYQngluEWIRbgh6BOoQQgmuHf4Qmg1smggwFF4FyHjEBAQGBAIFFAQEB X-IronPort-AV: E=Sophos;i="5.13,671,1427760000"; d="scan'208,217";a="4196749" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jun 2015 08:08:06 +0000 Received: from [10.24.206.20] ([10.24.206.20]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5O885mw020343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2015 08:08:06 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_45EAF800-424D-449C-BFE3-70BF300CA720" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> Date: Wed, 24 Jun 2015 01:08:06 -0700 Message-Id: <79C25286-FC91-490F-8323-9550EAC0911B@cisco.com> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Vividh Siddha , v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 24 Jun 2015 08:08:12 -0000 --Apple-Mail=_45EAF800-424D-449C-BFE3-70BF300CA720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24-Jun-2015 12:15 am, David Schinazi wrote:=20 > Hi again, >=20 > First off, thanks everyone for the feedback and advice! > Here's an attempt at answering the questions that arose since my last = post. >=20 > *) Personal hotspot on iOS > Currently the hotspot shares whatever address families it gets from = the cellular network. > The current implementation broadcasts an IPv6-only network if the = cellular network is of that type, > but I could imagine carriers bringing up IPv4 specifically when using = this feature. Our custom version > of prefix sharing is described in more detail here: > = https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prp= roxy.c = > It supports creating multiple hotspots at the same time, such as Wi-FI = and Bluetooth and bridges them. >=20 > *) iOS and cellular carrier networks > I do not know if or when specific carriers plan to change their IPv6 = policies. That said, we do believe > there is a growing trend towards IPv6. When roaming between carriers, = your device will get new > addresses and could possibly switch between address families. >=20 > *) VPN > Our implementation of IKEv2, which is our current recommended VPN = protocol, supports IPv6 on both > the inside and outside of the tunnel. Other protocols are currently = not guaranteed to be fully compatible. >=20 > *) Internet Sharing on the Mac > We agree that it would be nice to support IPv6, but the risk/reward = tradeoff isn't necessarily there yet. >=20 > *) Internet Sharing on the Mac - NAT64 testing mode > To reset expectations on this feature, it targets developers of = networked apps that are not knowledgeable > in IPv6, most likely not anyone on this list. If you're writing your = own sockets code that works on dual-stack > and have a dual-stacked server, you probably know what you're doing = already. The goal is really not > performance optimization, simply checking that your app will manage to = connect to your server at all. > Realistically, today any service accessible by apps over IPv6 is also = available over IPv4. Debugging path > MTU issues is currently out of scope of this test network. The App = Store IPv6 compatibility requirement will > not reject an app solely based on tests using the NAT64 test network. = The NAT64+DNS64 on the Mac will > currently only query for A records and return synthesized AAAA records = to its clients, it effectively ignores any > AAAA records it receives from the wide area. We're looking into = improving this feature, we agree that adding > real IPv6 connectivity and using a different prefix would be better. >=20 > *) Happy Eyeballs > Thanks to everyone for the advice on this topic, we're looking into = the best compromise between providing > our customers with good response times in the short term and helping = them in the long term by helping the > deployment of IPv6. An issue with RFC 6555 is that it was designed in = a mindset where DNS resolution is > provided by synchronous APIs such as getaddrinfo. In practice, your = AAAA and A records do not come back > at the same time and if you receive the A record first, every = millisecond you wait before sending out a SYN is > an IPv6 tax you're levying on your users. This being helpful in the = long term, there must be a sweet spot. To > clarify our use of the RTT to prioritize addresses, we use historical = RTT measurements of all TCP packets on > that route. If and when we release an updated implementation, I will = update this list. I have long thought Apple's implementation of Happy Eyeballs is awesome. = Tweaking the algorithm's built-in fudge factor to trend more towards = IPv6 would make it more consistent with other OSs and applications = (which give 200-300ms Happy Eyeballs head start to IPv6, which is = similar to the fudge factor done by Apple). Myself, I would like the = fudge factor to be configurable via sysctl or at least viewable via = netstat (or similar). As it is, it is difficult to understand why a = system is heavily preferring IPv4 or IPv6, and when it will give up; = disconnecting and reconnecting the network is a harsh troubleshooting = step for other traffic. -d >=20 > *) 464XLAT > We've considered using this technology and decided that it was not the = best course of action. This doesn't > mean we will never consider it and we're definitely interested in = discussing pros and cons but in my > humble (personal) opinion, calling us names to "get our attention" is = not likely to convince us that 464XLAT > is the One True Path to IPv6 deployment. >=20 > As mentioned in my last message, all these details only reflect the = current betas and can change in the future. >=20 > Thanks, > David >=20 >=20 >> On Jun 19, 2015, at 14:46, David Schinazi > wrote: >>=20 >> Hi everyone, >>=20 >> I'd like to clarify a few points about Apple's IPv6 announcements = during WWDC 2015. >> The video (streaming with Safari or download with all browsers) and = slides of that talk >> are available at: = https://developer.apple.com/videos/wwdc/2015/?id=3D719 = >>=20 >> *) Personal hotspot on iOS >> If your iPhone has dual-stack connectivity on its cellular network, = the hotspot it creates >> will be dual-stack as well. The phone will share its prefix with = Wi-Fi clients. >>=20 >> *) Internet Sharing on the Mac >> Today, regular internet sharing (from your ethernet to Wi-Fi for = example) does not >> support IPv6 because of the limited use cases, and the lack of demand = for it. >>=20 >> *) Internet Sharing on the Mac - NAT64 testing mode >> The NAT64 test mode was designed to help developers ensure that their = app can still >> function with IPv6-only NAT64+DNS64 connectivity and communicate with = their IPv4 >> server, even if the developer does not have access to the IPv6 = internet. That NAT64 >> network does not have IPv6 connectivity to the global IPv6 internet. = As such, the current >> version advertises addresses from 2001::/64 instead of ULAs to = simulate real IPv6 >> connectivity, as all IPv6 packets are terminated at the NAT64 server = on the Mac. >> This implementation detail could change in the future. >>=20 >> *) Making IPv4 literals work on NAT64 networks when using high-level = APIs >> Starting with this year's versions, if you use NSURLSession to = connect to an IPv4 >> literal on an IPv6-only NAT64-DNS64 network, the API will bump in a = IPv6 literal >> synthesized using RFC 7050. Note that this will not happen when using = sockets >> directly. We do not support under-the-sockets bump-in-API (RFC 3338) = and we >> do not support 464XLAT. >>=20 >> *) Happy Eyeballs >> We've heard feedback on our Happy Eyeballs implementation and are = investigating >> this topic. >>=20 >> Note that this reflects how these technologies work in the current = versions of the >> 2015 betas, many of these details could change in future betas. = Please keep in mind >> that these betas are previews and we welcome feedback on improving = them. >>=20 >> Feel free to contact me if you have any questions, I will also attend = IETF93. >>=20 >> Thanks, >> David Schinazi >> Apple CoreOS Networking Engineer >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_45EAF800-424D-449C-BFE3-70BF300CA720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 24-Jun-2015 12:15 am, David Schinazi <dschinazi@apple.com>= wrote:
Hi again,

First off, thanks = everyone for the feedback and advice!
Here's an attempt at = answering the questions that arose since my last post.

*) Personal hotspot on iOS
Currently the = hotspot shares whatever address families it gets from the cellular = network.
The current implementation broadcasts an = IPv6-only network if the cellular network is of that type,
but I could imagine carriers bringing up IPv4 specifically = when using this feature. Our custom version
of prefix = sharing is described in more detail here:
https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netin= et6/nd6_prproxy.c
It supports creating multiple = hotspots at the same time, such as Wi-FI and Bluetooth and bridges = them.

*) iOS and cellular carrier = networks
I do not know if or when specific carriers plan = to change their IPv6 policies. That said, we do believe
there is a growing trend towards IPv6. When roaming between = carriers, your device will get new
addresses and could = possibly switch between address families.

*) = VPN
Our implementation of IKEv2, which is our current = recommended VPN protocol, supports IPv6 on both
the inside = and outside of the tunnel. Other protocols are currently not guaranteed = to be fully compatible.

*) Internet Sharing = on the Mac
We agree that it would be nice to support IPv6, = but the risk/reward tradeoff isn't necessarily there yet.

*) Internet Sharing on the Mac - NAT64 testing = mode
To reset expectations on this feature, it targets = developers of networked apps that are not knowledgeable
in = IPv6, most likely not anyone on this list. If you're writing your own = sockets code that works on dual-stack
and have a = dual-stacked server, you probably know what you're doing already. The = goal is really not
performance optimization, simply = checking that your app will manage to connect to your server at all.
Realistically, today any service accessible by apps over IPv6 = is also available over IPv4. Debugging path
MTU issues is = currently out of scope of this test network. The App Store IPv6 = compatibility requirement will
not reject an app solely = based on tests using the NAT64 test network. The NAT64+DNS64 on the Mac = will
currently only query for A records and return = synthesized AAAA records to its clients, it effectively ignores any
AAAA records it receives from the wide area. We're looking = into improving this feature, we agree that adding
real = IPv6 connectivity and using a different prefix would be better.

*) Happy Eyeballs
Thanks to = everyone for the advice on this topic, we're looking into the best = compromise between providing
our customers with good = response times in the short term and helping them in the long term by = helping the
deployment of IPv6. An issue with RFC 6555 is = that it was designed in a mindset where DNS resolution is
provided by synchronous APIs such as getaddrinfo. In = practice, your AAAA and A records do not come back
at the = same time and if you receive the A record first, every millisecond you = wait before sending out a SYN is
an IPv6 tax you're = levying on your users. This being helpful in the long term, there must = be a sweet spot. To
clarify our use of the RTT to = prioritize addresses, we use historical RTT measurements of all TCP = packets on
that route. If and when we release an updated = implementation, I will update this list.

I= have long thought Apple's implementation of Happy Eyeballs is awesome. =  Tweaking the algorithm's built-in fudge factor to trend more = towards IPv6 would make it more consistent with other OSs and = applications (which give 200-300ms Happy Eyeballs head start to IPv6, = which is similar to the fudge factor done by Apple).  Myself, I = would like the fudge factor to be configurable via sysctl or at least = viewable via netstat (or similar).  As it is, it is difficult to = understand why a system is heavily preferring IPv4 or IPv6, and when it = will give up; disconnecting and reconnecting the network is a harsh = troubleshooting step for other traffic.

-d



*) 464XLAT
We've considered using this = technology and decided that it was not the best course of action. This = doesn't
mean we will never consider it and we're = definitely interested in discussing pros and cons but in my
humble (personal) opinion, calling us names to "get our = attention" is not likely to convince us that 464XLAT
is = the One True Path to IPv6 deployment.

As = mentioned in my last message, all these details only reflect the current = betas and can change in the future.

Thanks,
David


On Jun = 19, 2015, at 14:46, David Schinazi <dschinazi@apple.com>= wrote:

Hi = everyone,

I'd like to clarify a few points about = Apple's IPv6 announcements during WWDC 2015.
The video = (streaming with Safari or download with all browsers) and slides of that = talk
are available at: https://developer.apple.com/videos/wwdc/2015/?id=3D719

*) Personal = hotspot on iOS
If your iPhone has dual-stack = connectivity on its cellular network, the hotspot it creates
will be dual-stack as well. The phone will share its prefix = with Wi-Fi clients.

*) Internet Sharing on the = Mac
Today, regular internet sharing (from your ethernet = to Wi-Fi for example) does not
support IPv6 = because of the limited use cases, and the lack of demand for = it.

*) Internet Sharing on the Mac - NAT64 testing mode
The NAT64 test mode was designed to help developers ensure = that their app can still
function with IPv6-only = NAT64+DNS64 connectivity and communicate with their IPv4
server, even if the developer does not have access to the = IPv6 internet. That NAT64
network does not have IPv6 = connectivity to the global IPv6 internet. As such, the current
version advertises addresses from 2001::/64 instead of ULAs = to simulate real IPv6
connectivity, as all IPv6 = packets are terminated at the NAT64 server on the Mac.
This implementation detail could change in the = future.

*) Making IPv4 literals work on NAT64 = networks when using high-level APIs
Starting with = this year's versions, if you use NSURLSession to connect to an = IPv4
literal on an IPv6-only NAT64-DNS64 network, the = API will bump in a IPv6 literal
synthesized using = RFC 7050. Note that this will not happen when using sockets
directly. We do not support under-the-sockets bump-in-API = (RFC 3338) and we
do not support 464XLAT.

*) Happy = Eyeballs
We've heard feedback on our Happy = Eyeballs implementation and are investigating
this = topic.

Note that this reflects how these technologies work in the = current versions of the
2015 betas, many of these = details could change in future betas. Please keep in mind
that these betas are previews and we welcome feedback on = improving them.

Feel free to contact me if you have = any questions, I will also attend IETF93.

Thanks,
David Schinazi
Apple CoreOS Networking = Engineer

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


= --Apple-Mail=_45EAF800-424D-449C-BFE3-70BF300CA720-- From nobody Wed Jun 24 01:58:00 2015 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 581841B3248 for ; Wed, 24 Jun 2015 01:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, T_RP_MATCHES_RCVD=-0.01] 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 GciVY6cD56GE for ; Wed, 24 Jun 2015 01:57:58 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA141B320A for ; Wed, 24 Jun 2015 01:57:58 -0700 (PDT) Received: by wiga1 with SMTP id a1so128997496wig.0 for ; Wed, 24 Jun 2015 01:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fS2Pzh1khSWlx4jT7fEEfVLTbFKmYSZ8Cm36zHHk0Po=; b=eQuqGKF1GmIX80RElTDFHUflLA+B50vCwvKtjauB//wsoUk3AUflXD5QkRRJC6Bvx0 MNaptcG0pqkbB+xg7b3Q1TpH/MTKUR/CZ/6F7gJQ7ZrVmQB/GhesKaoD2tclViJm4R4w XPsv/y1nMsyiAOkbZgjdUtutpQTvir8xqXDBouWXVJuvnUupagMrowqowTKgHLXfEHsk MWu4aF/sUZnzP5RvK2fwyXCPJGL/6Iy/Q8KzO7wTalroDt9qC37TZz2rSMghVP4wZS7h xAjKFdZqayiiU/MTjKfQr79R+pEK2tOJGcM5GhEOqrRKCkMuIfmUKvWhBzMf1xnHqVIA V4Qg== 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:from:date :message-id:subject:to:cc:content-type; bh=fS2Pzh1khSWlx4jT7fEEfVLTbFKmYSZ8Cm36zHHk0Po=; b=CeEo6aecaY5bJkfw7YVef8shh8roF6T92UJDb6WFw9BobfVpGK+WeMLNhuJBnjTVyn 3CjQRduGbYhglvjlvsbOsF7S69SDtk1OLIE9Nc/OSePn7NIHF5cEtaI6mccl+p7Ps3av 4AX69gCkFBgifgUjOcqd09svcYCGjjDQVFEn+mBWw3pFV+FvHgDAJwe1BuCXer4K+8zN CZypV+1Qvj3EzKa3gtWpBKXwe84MWmp+bpttKrtjeKEM5hI+K3DMkvf3kfsZFrY5xnnc D17ZVuK4VQOXXT4oqxWu3Ky0U8xyNywFZwykUxjQ+nXrTBwm5ifsJkPzY1Hl5lBjFR1J LZiw== X-Gm-Message-State: ALoCoQnVS+Nr3LGp0MHuBbvi19d+xHfGXl3dtGAv4ZIh+IvUwwFX68eGS0RGZo3/fu/yrgY12V8t X-Received: by 10.194.175.65 with SMTP id by1mr8161010wjc.152.1435136277005; Wed, 24 Jun 2015 01:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Wed, 24 Jun 2015 01:57:37 -0700 (PDT) In-Reply-To: References: <5587EFDD.6030807@gmail.com> From: Erik Kline Date: Wed, 24 Jun 2015 17:57:37 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 08:57:59 -0000 On Mon, Jun 22, 2015 at 9:16 PM, Mikael Abrahamsson wrote: > On Mon, 22 Jun 2015, Alexandru Petrescu wrote: > >> It is better to tell the operator to provide a /63 to smartphones (not a >> /64), with DHCPv6 Prefix Delegation. That will fix it. > > > DHCPv6-PD exists in recent 3GPP documents, but vendor implementation of this > is not wide-spread. We do *not* want to gate IPv6 rollout in mobile networks > on this functionality. Yes, we want it, but we can't wait for it. (off-topic: So, are you saying that DT is most definitely not blocked on DHCPv6-PD as far as enabling IPv6 on LTE is concerned?) From nobody Wed Jun 24 02:41:20 2015 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 B11BE1B32CE for ; Wed, 24 Jun 2015 02:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zRU_ryYo4AvP for ; Wed, 24 Jun 2015 02:41:13 -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 B14371B325E for ; Wed, 24 Jun 2015 02:41:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 99B10A1; Wed, 24 Jun 2015 11:41:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1435138871; bh=m8wDenU7KL5rTbuw9wspup7SEU/vYkuZiFcdhVjZB+4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=KWMRjnz9311qLvpATjaUsiShBjG4qBtYLY25qsY+VO9pjy7oTy3o86pG3DVZzlTJj O2bLaI0L+hV/L3UISd6qWtpYqPbibKg1h7KwgxslzhKov3F8LAJExm1OCnnOJOsjqy 0hO+EIptwkPUI7zgGuEibRQiHwiYl6jNGQmlMWVU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 91A039F; Wed, 24 Jun 2015 11:41:11 +0200 (CEST) Date: Wed, 24 Jun 2015 11:41:11 +0200 (CEST) From: Mikael Abrahamsson To: Erik Kline In-Reply-To: Message-ID: References: <5587EFDD.6030807@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; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 09:41:19 -0000 On Wed, 24 Jun 2015, Erik Kline wrote: >> DHCPv6-PD exists in recent 3GPP documents, but vendor implementation of >> this is not wide-spread. We do *not* want to gate IPv6 rollout in >> mobile networks on this functionality. Yes, we want it, but we can't >> wait for it. > > (off-topic: So, are you saying that DT is most definitely not blocked > on DHCPv6-PD as far as enabling IPv6 on LTE is concerned?) Re-reading my sentence above I agree it can be interpreted as me speaking for DT as whole. That was not my intention. I have no recent information as to what the current state of IPv6 rollout is in DT Germany mobile network. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jun 24 03:38:31 2015 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 9EEDA1A1A67 for ; Wed, 24 Jun 2015 03:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 Qs7wNwS0jGuU for ; Wed, 24 Jun 2015 03:38:27 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0091A1A47 for ; Wed, 24 Jun 2015 03:38:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5OAcPE2012377 for ; Wed, 24 Jun 2015 12:38:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CE1A0202192 for ; Wed, 24 Jun 2015 12:41:20 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BC844200F68 for ; Wed, 24 Jun 2015 12:41:20 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5OAcL0M004482 for ; Wed, 24 Jun 2015 12:38:25 +0200 Message-ID: <558A889D.8030006@gmail.com> Date: Wed, 24 Jun 2015 12:38:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5587EFDD.6030807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 10:38:29 -0000 Le 24/06/2015 11:41, Mikael Abrahamsson a écrit : > On Wed, 24 Jun 2015, Erik Kline wrote: > >>> DHCPv6-PD exists in recent 3GPP documents, but vendor implementation >>> of this is not wide-spread. We do *not* want to gate IPv6 rollout in >>> mobile networks on this functionality. Yes, we want it, but we can't >>> wait for it. >> >> (off-topic: So, are you saying that DT is most definitely not blocked >> on DHCPv6-PD as far as enabling IPv6 on LTE is concerned?) > > Re-reading my sentence above I agree it can be interpreted as me > speaking for DT as whole. That was not my intention. I have no recent > information as to what the current state of IPv6 rollout is in DT > Germany mobile network. > DHCPv6-PD in recent 3GPP documents is between entities within the core network. The 3GPP specs dont tell DHCPv6 Prefix Delegation towards the UE. The UE in 3GPP specs does not implement DHCPv6 PD. What is the status of DT IPv6 trials - do they exist? Alex From nobody Wed Jun 24 04:38:48 2015 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 2B0FE1A88BD for ; Wed, 24 Jun 2015 04:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TCKgqNIVylwQ for ; Wed, 24 Jun 2015 04:38:45 -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 539691A88B0 for ; Wed, 24 Jun 2015 04:38:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0412CA1; Wed, 24 Jun 2015 13:38:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1435145923; bh=glV/JnVTrG/6m5VyjDu8x0p3C/ukvWO46KFWiCqX0ww=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=zN6HD7hbNzsgQeD3Xufa/nXQWgimds1v8zLjJxjVy+UmwpnBHFeZxtUPZWQsDvf8x XuTXoPiTCOET1iWOrpw/5LEmMckFtWX3yqc1r47kMH/U5wb152OXDWb0K7LgEV+Tpz w5NwWH78zf4u1IJhHpu3OaUumrEQB3qa7UyK1+vI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F27DF9F; Wed, 24 Jun 2015 13:38:42 +0200 (CEST) Date: Wed, 24 Jun 2015 13:38:42 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <558A889D.8030006@gmail.com> Message-ID: References: <5587EFDD.6030807@gmail.com> <558A889D.8030006@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; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 11:38:47 -0000 On Wed, 24 Jun 2015, Alexandru Petrescu wrote: > DHCPv6-PD in recent 3GPP documents is between entities within the core > network. The 3GPP specs dont tell DHCPv6 Prefix Delegation towards the > UE. The UE in 3GPP specs does not implement DHCPv6 PD. You are mistaken. http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/12.06.00_60/ts_123401v120600p.pdf Section 5.3.1.2.6. DHCPv6-PD towards the UE came into the 3GPP standards at least 3 years ago. Mobile core networks that implement this is another matter. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jun 24 05:13:35 2015 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 5FB4A1A8A15 for ; Wed, 24 Jun 2015 05:13:34 -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 w4KmlpNYrsMH for ; Wed, 24 Jun 2015 05:13:33 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA34A1A8A11 for ; Wed, 24 Jun 2015 05:13:32 -0700 (PDT) Received: by wiga1 with SMTP id a1so133785778wig.0 for ; Wed, 24 Jun 2015 05:13:31 -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=P3cdowdEUyAgfbIKujnt9zMY1jSSDyKJIaunV87qp/0=; b=eBR97NEOzVFMUSaRSjU7cki4EeQb6Jal1wvStjUofDZ1hyff3Z30JTX8/gnczbH4zt jVS/eN1rxo6Rplzep7UplyZlFqfbY7ByA8LauDz9rs+GuQQl3WP15aOmI3Ke11FqtNXx xxfZVYp+q4/+DFa7k4lw7gcHSuqOCwxVBfPm1/AhwahInZeHIfd+MRP2a1O3CuiiMiDp HL9o8/YVZTDbK3bnNLDWcFL0ErYfKLQpLMyEFixQHYMMVlJr9p7Oux1Vxycp/iu1boHz 7n9tgpGfYsZ4gyH2fee3OZpWpQq1jdHNsmSSSUe/JpN2bZm6QzHPLO1kPMFUcivW7X6z 3oWA== MIME-Version: 1.0 X-Received: by 10.180.72.145 with SMTP id d17mr4333766wiv.69.1435148011671; Wed, 24 Jun 2015 05:13:31 -0700 (PDT) Received: by 10.194.79.65 with HTTP; Wed, 24 Jun 2015 05:13:31 -0700 (PDT) In-Reply-To: References: <5587EFDD.6030807@gmail.com> Date: Wed, 24 Jun 2015 05:13:31 -0700 Message-ID: From: Ca By To: Erik Kline Content-Type: multipart/alternative; boundary=14dae9cc94926faa820519426fd6 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 12:13:34 -0000 --14dae9cc94926faa820519426fd6 Content-Type: text/plain; charset=UTF-8 On Wednesday, June 24, 2015, Erik Kline wrote: > On Mon, Jun 22, 2015 at 9:16 PM, Mikael Abrahamsson > wrote: > > On Mon, 22 Jun 2015, Alexandru Petrescu wrote: > > > >> It is better to tell the operator to provide a /63 to smartphones (not a > >> /64), with DHCPv6 Prefix Delegation. That will fix it. > > > > > > DHCPv6-PD exists in recent 3GPP documents, but vendor implementation of > this > > is not wide-spread. We do *not* want to gate IPv6 rollout in mobile > networks > > on this functionality. Yes, we want it, but we can't wait for it. > > (off-topic: So, are you saying that DT is most definitely not blocked > on DHCPv6-PD as far as enabling IPv6 on LTE is concerned?) > > Erik, Probably chicken and eggs with a side of customers dont care. Does Android suppot dhcp-pd ? CB _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --14dae9cc94926faa820519426fd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 24, 2015, Erik Kline <ek@google.com> wrote:
On= Mon, Jun 22, 2015 at 9:16 PM, Mikael Abrahamsson <swmik= e@swm.pp.se> wrote:
> On Mon, 22 Jun 2015, Alexandru Petrescu wrote:
>
>> It is better to tell the operator to provide a /63 to smartphones = (not a
>> /64), with DHCPv6 Prefix Delegation.=C2=A0 That will fix it.
>
>
> DHCPv6-PD exists in recent 3GPP documents, but vendor implementation o= f this
> is not wide-spread. We do *not* want to gate IPv6 rollout in mobile ne= tworks
> on this functionality. Yes, we want it, but we can't wait for it.<= br>
(off-topic: So, are you saying that DT is most definitely not blocked
on DHCPv6-PD as far as enabling IPv6 on LTE is concerned?)


Erik,

Probabl= y chicken and eggs=C2=A0with a side of=C2=A0=C2=A0customers dont care.=C2= =A0

Does Android suppot dhcp-pd ?

CB

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--14dae9cc94926faa820519426fd6-- From nobody Wed Jun 24 05:22:25 2015 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 868581A8A0F for ; Wed, 24 Jun 2015 05:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, 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 WHOpk46zLPU9 for ; Wed, 24 Jun 2015 05:22:22 -0700 (PDT) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id BC9131A8996 for ; Wed, 24 Jun 2015 05:22:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 19880401EE; Wed, 24 Jun 2015 14:22:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4lWByG_odMX; Wed, 24 Jun 2015 14:22:18 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 83085401B1; Wed, 24 Jun 2015 14:22:18 +0200 (CEST) Message-ID: <558AA0F9.9090103@globis.net> Date: Wed, 24 Jun 2015 14:22:17 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tore Anderson References: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> <5589BC13.6050507@globis.net> <20150624093256.0075867d@echo.ms.redpill-linpro.com> In-Reply-To: <20150624093256.0075867d@echo.ms.redpill-linpro.com> Content-Type: multipart/alternative; boundary="------------090001080404050003030109" Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam 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, 24 Jun 2015 12:22:24 -0000 This is a multi-part message in MIME format. --------------090001080404050003030109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit inline. > Tore Anderson > 24 June 2015 09:32 > * Ray Hunter > >> I have read this draft. It is very well written, the intention is >> clear, and I support it. > > Hi Ray -- thank you! > >> Comment 1 >> Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that >> of the IPv4 address being translated." and "an IPv6 Prefix identical >> to that of the IPv6 address being translated" >> >> Surely that should be a "longest-matching-prefix based on CIDR >> [RFC4632]" > >> Comment 3 >> / Overlapping EAMs SHOULD be considered an error, and attempts to >> insert them into the EAMT SHOULD be blocked. The behaviour of an >> SIIT implementation when overlapping EAMs are present in the EAMT >> is left undefined./ >> >> I believe that this is an unnecessary restriction for correct >> specification/operation provided CIDR/longest-matching-prefix is >> specified. > > The reasoning behind this restiction was that it would otherwise be > possible to create a situation that does not facilitate bi-directional > communcation. For example: > > EAM #1: 192.0.2.1/32, 2001:db8::/32 > EAM #2: 198.51.100.1/32, 2001:db8:c000:201::/128 Correct. Operators can shoot themselves in the foot. > > This would cause 192.0.2.1 to be translated to 2001:db8:c000:201::, > which in turn would be translated to 198.51.100.1. That will likely > break whatever use-case was intended. Then again, I suppose it might as > well be allowed. If the operator shoots himself in the foot he can deal > with that himself...so, yeah, we'll lift the restriction and use CIDR. I think it's fair to give a warning about the dangers of overlapping ranges, or different length suffixes, potentially leading to problems with two way communication, but I don't think that it constitutes a "SHOULD NOT" or "MUST NOT" in the specification. > > That said, do you think the draft should discuss what to do when > multiple EAMs contain *identical* IPv4/IPv6 prefix values? For example: yes. > > EAM #1: 192.0.2.0/24, 2001:db8:a::/48 > EAM #2: 192.0.2.0/24, 2001:db8:b::/48 > > Or: > > EAM #1: 192.0.2.1/32, 2001:db8::/128 > EAM #2: 198.51.100.1/32, 2001:db8::/128 > > Suggested text would of course be very welcome. Suggested text: / The translation algorithm specified in section 3.3 relies on longest-mask-matching of source and destination addresses to select the appropriate entry in the Explicit Address Mapping Table. Operators of SIIT devices should note that configuring overlapping or identical prefixes in the EAM table may create problematic cases where it is not possible to guarantee symmetric address translations, and thus two way communication may not be possible. In the first example EAM table below, where the IPv4 ranges do not overlap but the IPv6 ranges do: EAM #1: 192.0.2.1/32, 2001:db8::/32 EAM #2: 198.51.100.1/32, 2001:db8:c000:201::1/128 a packet with a source IPv4 address of 192.0.2.1 may possibly be translated to 2001:db8:c000:201::1. However, any return packets with IPv6 source address 2001:db8:c000:201::1 will trigger a longest prefix match with 2001:db8:c000:201::1/128, and will thus be translated to the incorrect IPv4 prefix (198.51.100.1/32). In the second example EAM table below, where the IPv6 ranges are identical but the IPv4 ranges do not overlap at all: EAM #1: 192.0.2.1/32, 2001:db8::/128 EAM #2: 198.51.100.1/32, 2001:db8::/128 packets with a source IPv4 address of 192.0.2.1 or 198.51.100.1will both be translated to 2001:db8::. Once again, SIIT will not be able to determine the correct IPv4 prefix to apply for translating return packets in a deterministic way (SIIT does not maintain state). The behaviour of SIIT is unspecified in this case. In the third example EAM table below, the IPv6 ranges and IPv4 ranges do not overlap with any other entries, but they potentially contain differing numbers of hosts: EAM #1: 192.0.2.0/24, 2001:db8::c000/48 packets with a source IPv6 address of 2001:db8::c000::0/128 to 2001:db8::c000::ff/128 may be translated to 192.0.2.0 to 192.0.2.255 respectively. But if packets arrive from an IPv6 source address of 2001:db8::c000::ffff, there may not be any IPv4 addresses available to perform the address translation in an unambiguous way. An implementation could theoretically determine which IPv6 hosts are actually active or visible on the IPv6 side of the SIIT over a longer time frame, and dynamically adjust the contents of the SIIT EAM table so that the SIIT maintains a one-to-one unambiguous symmetric mapping of IPv4 to IPv6 addresses, but that is outside the scope of this paper. Operators SHOULD avoid use of overlapping prefixes in the EAM table. Entries with different suffix lengths for IPv4 and IPv6 SHOULD also be avoided. Implementations MAY provide a warning if such ambiguous entries are detected in the EAM table. / > >> Comment 2 >> Operational complexity: >> >> Suggest Adding at the end of this paragraph >> /Source address selection rules on hosts may not have enough information >> to be able to select the appropriate source address for outbound >> sessions in the presence of SIIT./ > > Good idea, we'll add this. A reference to RFC6724 is probably > appropriate here too. Agreed. > >> Nits >> [...] > > Will fix. Thanks again! > > Tore > Ray Hunter > 23 June 2015 22:05 > > > > > I have read this draft. It is very well written, the intention is > clear, and I support it. > > > Three comments: > > Comment 1 > Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that of > the IPv4 address being translated." and "an IPv6 Prefix identical to > that of the IPv6 address being translated" > > Surely that should be a "longest-matching-prefix based on CIDR [RFC4632]" > > Comment 2 > Operational complexity: > > Suggest Adding at the end of this paragraph > /Source address selection rules on hosts may not have enough > information to be able to select the appropriate source address for > outbound sessions in the presence of SIIT./ > > > Comment 3 > / Overlapping EAMs SHOULD be considered an error, and attempts to > insert them into the EAMT SHOULD be blocked. The behaviour of an > SIIT implementation when overlapping EAMs are present in the EAMT is > left undefined./ > > I believe that this is an unnecessary restriction for correct > specification/operation provided CIDR/longest-matching-prefix is > specified. > > > > Nits > > s/The IPv4-translatable IPv6 addresses must not only be assigned to > the IPv6 nodes participating in SIIT/ > The IPv4-translatable IPv6 addresses not only has to be assigned to > the IPv6 nodes participating in SIIT/ > > > s/number his entire/number their entire/ > s/addresses he assigns/addresses they assign/ > > s/are REQUIRED to/MUST/ > > regards, > RayH > > --------------090001080404050003030109 Content-Type: multipart/related; boundary="------------050303010708050905040903" --------------050303010708050905040903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit inline.

24 June 2015 09:32
* Ray Hunter <v6ops@globis.net>


I have read this draft. It is very well written, the intention is
clear, and I support it.


Hi Ray -- thank you!


Comment 1
Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that
of the IPv4 address being translated." and "an IPv6 Prefix identical
to that of the IPv6 address being translated"

Surely that should be a "longest-matching-prefix based on CIDR
[RFC4632]"



Comment 3
/  Overlapping EAMs SHOULD be considered an error, and attempts to
   insert them into the EAMT SHOULD be blocked. The behaviour of an
   SIIT implementation when overlapping EAMs are present in the EAMT
   is left undefined./

I believe that this is an unnecessary restriction for correct 
specification/operation provided CIDR/longest-matching-prefix is
specified.


The reasoning behind this restiction was that it would otherwise be
possible to create a situation that does not facilitate bi-directional
communcation. For example:

EAM #1: 192.0.2.1/32,    2001:db8::/32
EAM #2: 198.51.100.1/32, 2001:db8:c000:201::/128
Correct. Operators can shoot themselves in the foot.

This would cause 192.0.2.1 to be translated to 2001:db8:c000:201::,
which in turn would be translated to 198.51.100.1. That will likely
break whatever use-case was intended. Then again, I suppose it might as
well be allowed. If the operator shoots himself in the foot he can deal
with that himself...so, yeah, we'll lift the restriction and use CIDR.
I think it's fair to give a warning about the dangers of overlapping ranges, or different length suffixes, potentially leading to problems with two way communication, but I don't think that it constitutes a "SHOULD NOT" or "MUST NOT" in the specification.

That said, do you think the draft should discuss what to do when
multiple EAMs contain *identical* IPv4/IPv6 prefix values? For example:
yes.

EAM #1: 192.0.2.0/24, 2001:db8:a::/48
EAM #2: 192.0.2.0/24, 2001:db8:b::/48

Or:

EAM #1: 192.0.2.1/32,    2001:db8::/128
EAM #2: 198.51.100.1/32, 2001:db8::/128

Suggested text would of course be very welcome.
Suggested text:
/
<t>The translation algorithm specified in section 3.3 relies on longest-mask-matching of source and destination addresses to select the appropriate entry in the Explicit Address Mapping Table. Operators of SIIT devices should note that configuring overlapping or identical prefixes in the EAM table may create problematic cases where it is not possible to guarantee symmetric address translations, and thus two way communication may not be possible.
</t> <t>
In the first example EAM table below, where the IPv4 ranges do not overlap but the IPv6 ranges do:
</t> <t>
EAM #1: 192.0.2.1/32, 2001:db8::/32
</t> <t> 
EAM #2: 198.51.100.1/32, 2001:db8:c000:201::1/128
a packet with a source IPv4 address of 192.0.2.1 may possibly be translated to 2001:db8:c000:201::1. However, any return packets with IPv6 source address 2001:db8:c000:201::1 will trigger a longest prefix match with 2001:db8:c000:201::1/128, and will thus be translated to the incorrect IPv4 prefix (198.51.100.1/32).
</t> <t>
In the second example EAM table below, where the IPv6 ranges are identical but the IPv4 ranges do not overlap at all:
</t> <t>
EAM #1: 192.0.2.1/32, 2001:db8::/128
</t> <t>
EAM #2: 198.51.100.1/32, 2001:db8::/128
</t> <t>   
packets with a source IPv4 address of 192.0.2.1 or 198.51.100.1 will both be translated to 2001:db8::. Once again, SIIT will not be able to determine the correct IPv4 prefix to apply for translating return packets in a deterministic way (SIIT does not maintain  state). The behaviour of SIIT is unspecified in this case.
</t> <t> 
In the third example EAM table below, the IPv6 ranges and IPv4 ranges do not overlap with any other entries, but they potentially contain differing numbers of hosts:
</t> <t>
EAM #1: 192.0.2.0/24, 2001:db8::c000/48
</t> <t>   
packets with a source IPv6 address of 2001:db8::c000::0/128 to 2001:db8::c000::ff/128 may be translated to 192.0.2.0 to 192.0.2.255 respectively.  But if packets arrive from an IPv6 source address of 2001:db8::c000::ffff, there may not be any IPv4 addresses available to perform the address translation in an unambiguous way. An implementation could theoretically determine which IPv6 hosts are actually active or visible on the IPv6 side of the SIIT over a longer time frame, and dynamically adjust the contents of the SIIT EAM table so that the SIIT maintains a one-to-one unambiguous symmetric mapping of IPv4 to IPv6 addresses, but that is outside the scope of this paper.
</t> <t>  
Operators SHOULD avoid use of overlapping prefixes in the EAM table. Entries with different suffix lengths for IPv4 and IPv6 SHOULD also be avoided. Implementations MAY provide a warning if such ambiguous entries are detected in the EAM table.
</t>
/





Comment 2
Operational complexity:

Suggest Adding at the end of this paragraph
/Source address selection rules on hosts may not have enough information 
to be able to select the appropriate source address for outbound 
sessions in the presence of SIIT./


Good idea, we'll add this. A reference to RFC6724 is probably
appropriate here too.
Agreed.


Nits
[...]


Will fix. Thanks again!

Tore
23 June 2015 22:05




I have read this draft. It is very well written, the intention is clear, and I support it.


Three comments:

Comment 1
Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that of the IPv4 address being translated." and "an IPv6 Prefix identical to that of the IPv6 address being translated"

Surely that should be a "longest-matching-prefix based on CIDR [RFC4632]"

Comment 2
Operational complexity:

Suggest Adding at the end of this paragraph
/Source address selection rules on hosts may not have enough information to be able to select the appropriate source address for outbound sessions in the presence of SIIT./


Comment 3
/  Overlapping EAMs SHOULD be considered an error, and attempts to
   insert them into the EAMT SHOULD be blocked. The behaviour of an
   SIIT implementation when overlapping EAMs are present in the EAMT is
   left undefined./

I believe that this is an unnecessary restriction for correct specification/operation provided CIDR/longest-matching-prefix is specified.



Nits

s/The IPv4-translatable IPv6 addresses must not only be assigned to
      the IPv6 nodes participating in SIIT/
The IPv4-translatable IPv6 addresses not only has to be assigned to
      the IPv6 nodes participating in SIIT/


s/number his entire/number their entire/
s/addresses he assigns/addresses they assign/

s/are REQUIRED to/MUST/

regards,
RayH


--------------050303010708050905040903 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------050303010708050905040903-- --------------090001080404050003030109-- From nobody Wed Jun 24 05:38:27 2015 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 3A03D1A8AA6 for ; Wed, 24 Jun 2015 05:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 wWnQ5Hl1ApL1 for ; Wed, 24 Jun 2015 05:38:24 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F841A8A82 for ; Wed, 24 Jun 2015 05:38:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5OCcGL9018271; Wed, 24 Jun 2015 14:38:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40B59200F68; Wed, 24 Jun 2015 14:41:12 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2B9CF2007FE; Wed, 24 Jun 2015 14:41:12 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5OCcD6o013966; Wed, 24 Jun 2015 14:38:16 +0200 Message-ID: <558AA4B5.7010709@gmail.com> Date: Wed, 24 Jun 2015 14:38:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <5587EFDD.6030807@gmail.com> <558A889D.8030006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 12:38:26 -0000 Le 24/06/2015 13:38, Mikael Abrahamsson a écrit : > On Wed, 24 Jun 2015, Alexandru Petrescu wrote: > >> DHCPv6-PD in recent 3GPP documents is between entities within the >> core network. The 3GPP specs dont tell DHCPv6 Prefix Delegation >> towards the UE. The UE in 3GPP specs does not implement DHCPv6 PD. > > You are mistaken. > > http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/12.06.00_60/ts_123401v120600p.pdf > > Section 5.3.1.2.6. Ok, thanks for the pointer. I checked that section and indeed it is specifying DHCPv6-PD towards the UE. That is encouraging. > DHCPv6-PD towards the UE came into the 3GPP standards at least 3 > years ago. I didnt know that. This document version is dated September 2014. > Mobile core networks that implement this is another matter. How long would it take to see it on operator networks? Because my UEs are ready to issue these DHCPv6 Prefix Delegation requests. Alex > From nobody Wed Jun 24 05:39:18 2015 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 854F71A8A82 for ; Wed, 24 Jun 2015 05:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 csegSlvN9LR2 for ; Wed, 24 Jun 2015 05:39:16 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EBF1A8A7E for ; Wed, 24 Jun 2015 05:39:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5OCdDxP018602 for ; Wed, 24 Jun 2015 14:39:13 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 91485200805 for ; Wed, 24 Jun 2015 14:42:08 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 88B472007FE for ; Wed, 24 Jun 2015 14:42:08 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5OCdC0K015063 for ; Wed, 24 Jun 2015 14:39:13 +0200 Message-ID: <558AA4F1.8080503@gmail.com> Date: Wed, 24 Jun 2015 14:39:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5587EFDD.6030807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 12:39:17 -0000 Le 24/06/2015 14:13, Ca By a écrit : > > > On Wednesday, June 24, 2015, Erik Kline > wrote: > > On Mon, Jun 22, 2015 at 9:16 PM, Mikael Abrahamsson > > wrote: > > On Mon, 22 Jun 2015, Alexandru Petrescu wrote: > > > >> It is better to tell the operator to provide a /63 to > smartphones (not a > >> /64), with DHCPv6 Prefix Delegation. That will fix it. > > > > > > DHCPv6-PD exists in recent 3GPP documents, but vendor > implementation of this > > is not wide-spread. We do *not* want to gate IPv6 rollout in > mobile networks > > on this functionality. Yes, we want it, but we can't wait for it. > > (off-topic: So, are you saying that DT is most definitely not blocked > on DHCPv6-PD as far as enabling IPv6 on LTE is concerned?) > > > Erik, > > Probably chicken and eggs with a side of customers dont care. > > Does Android suppot dhcp-pd ? Android is a linux based os, I dont see why it wouldnt support dhcp-pd? My linux based non-Android machines do dhcp-pd ok. Alex > > CB > > _______________________________________________ > 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 Jun 24 05:52:55 2015 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 BF0111A0130 for ; Wed, 24 Jun 2015 05:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 bIS-SbK7jkok for ; Wed, 24 Jun 2015 05:52:49 -0700 (PDT) Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id 96B861A8AC2 for ; Wed, 24 Jun 2015 05:52:44 -0700 (PDT) Received: (qmail 20743 messnum 12635849 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 24 Jun 2015 12:52:43 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail06.svc.cra.dublin.eircom.net (qp 20743) with SMTP; 24 Jun 2015 12:52:43 -0000 Received: from [192.168.1.2] ([95.44.35.164]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id kCsf1q00S3YUviP01Csixr; Wed, 24 Jun 2015 13:52:43 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_A9A3532A-31D8-4E59-ACA4-84560CC3817C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: Date: Wed, 24 Jun 2015 13:52:49 +0100 Message-Id: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> To: Ca By X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 24 Jun 2015 12:52:53 -0000 --Apple-Mail=_A9A3532A-31D8-4E59-ACA4-84560CC3817C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Jun 2015, at 23:58, Ca By wrote: >=20 > For some subset of networks, devs can test the real production deal if = apple could surface the apn setting in dev builds. It is hard to see the = harm in this. Other OSs allow apn setting fiddling. Also, this allows an = escape hatch for the inevitable user who cannot deal with ipv6-only in = production... And opens the door for end user opt in trials of ipv6.=20 >=20 > It's really not a hard problem to solve for many situations (like = tmus) but the some backwards place .... They may not have this luxury = of proper ipv6 in mobile :/ >=20 > CB=20 +1 At lot of people that could help with IPv6-only deployment lose interest = when they hear that they have to have an Android or Windows Phone to try = it. Ross --Apple-Mail=_A9A3532A-31D8-4E59-ACA4-84560CC3817C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 22 Jun 2015, at 23:58, Ca By <cb.list6@gmail.com> = wrote:

For some subset of networks, = devs can test the real production deal if apple could surface the apn = setting in dev builds. It is hard to see the harm in this. Other OSs = allow apn setting fiddling. Also, this allows an escape hatch for the = inevitable user who cannot deal with ipv6-only in production... And = opens the door for end user opt in trials of ipv6. 

It's really not a hard = problem to solve for many situations (like tmus)  but the some = backwards place .... They may not have this luxury of proper ipv6 in = mobile :/

CB 

+1

At lot of = people that could help with IPv6-only deployment lose interest when they = hear that they have to have an Android or Windows Phone to try = it.

Ross

= --Apple-Mail=_A9A3532A-31D8-4E59-ACA4-84560CC3817C-- From nobody Wed Jun 24 07:12:35 2015 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 769371ABD38 for ; Wed, 24 Jun 2015 07:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 8c0kTQxyB22q for ; Wed, 24 Jun 2015 07:12:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2001ABC10 for ; Wed, 24 Jun 2015 07:12:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5OECNlT029073 for ; Wed, 24 Jun 2015 16:12:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 84C812070DE for ; Wed, 24 Jun 2015 16:15:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7B774200F94 for ; Wed, 24 Jun 2015 16:15:18 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5OECJXk015776 for ; Wed, 24 Jun 2015 16:12:22 +0200 Message-ID: <558ABAC3.4010802@gmail.com> Date: Wed, 24 Jun 2015 16:12:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> In-Reply-To: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 24 Jun 2015 14:12:33 -0000 Hi, thanks for the reply. Le 24/06/2015 09:15, David Schinazi a écrit : > Hi again, > > First off, thanks everyone for the feedback and advice! Here's an > attempt at answering the questions that arose since my last post. > > *) Personal hotspot on iOS Currently the hotspot shares whatever > address families it gets from the cellular network. The current > implementation broadcasts an IPv6-only network if the cellular > network is of that type, but I could imagine carriers bringing up > IPv4 specifically when using this feature. Our custom version of > prefix sharing is described in more detail here: > https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c I looked at the file. It does proxy Neighbor Discovery in order to bridge. Proxy ND is an EXPERIMENTAL RFC4389. 64share is an INFORMATIONAL RFC7278. This means they are not the perfect way to aim for interoperability. An Apple smartphone could not talk to a GM car (just examples of brand names). In the car use-case the smartphone connects to the dashboard using a ptp link. And it's the car's dashboard which offers a WiFi hotspot. These couldn't be bridged (ND proxy) by the smartphone alone, it would need the dashboard router to participate in this ND proxy. What the smartphone needs is to route with longest-prefix matching and use different prefixes on each interface. That is an interoperable way to connecting different subnets, and the RFCs are typically on the Stds Track (not INFORMATIONAL, nor EXPERIMENTAL). Isn't the car use-case important for Apple smartphones? (I mention car use-case because I work on these these days, but the discussion of ND proxy is much older and it originated in a home context with cable ISP and IPv6). > It supports creating multiple hotspots at the same time, such as > Wi-FI and Bluetooth and bridges them. But insecurely. Bluetooth and WiFi have different security mechanisms. The security mechanisms wouldn't bridge. > *) iOS and cellular carrier networks I do not know if or when > specific carriers plan to change their IPv6 policies. That said, we > do believe there is a growing trend towards IPv6. When roaming > between carriers, your device will get new addresses and could > possibly switch between address families. I agree. Alex > > *) VPN Our implementation of IKEv2, which is our current recommended > VPN protocol, supports IPv6 on both the inside and outside of the > tunnel. Other protocols are currently not guaranteed to be fully > compatible. > > *) Internet Sharing on the Mac We agree that it would be nice to > support IPv6, but the risk/reward tradeoff isn't necessarily there > yet. > > *) Internet Sharing on the Mac - NAT64 testing mode To reset > expectations on this feature, it targets developers of networked apps > that are not knowledgeable in IPv6, most likely not anyone on this > list. If you're writing your own sockets code that works on > dual-stack and have a dual-stacked server, you probably know what > you're doing already. The goal is really not performance > optimization, simply checking that your app will manage to connect to > your server at all. Realistically, today any service accessible by > apps over IPv6 is also available over IPv4. Debugging path MTU issues > is currently out of scope of this test network. The App Store IPv6 > compatibility requirement will not reject an app solely based on > tests using the NAT64 test network. The NAT64+DNS64 on the Mac will > currently only query for A records and return synthesized AAAA > records to its clients, it effectively ignores any AAAA records it > receives from the wide area. We're looking into improving this > feature, we agree that adding real IPv6 connectivity and using a > different prefix would be better. > > *) Happy Eyeballs Thanks to everyone for the advice on this topic, > we're looking into the best compromise between providing our > customers with good response times in the short term and helping them > in the long term by helping the deployment of IPv6. An issue with RFC > 6555 is that it was designed in a mindset where DNS resolution is > provided by synchronous APIs such as getaddrinfo. In practice, your > AAAA and A records do not come back at the same time and if you > receive the A record first, every millisecond you wait before sending > out a SYN is an IPv6 tax you're levying on your users. This being > helpful in the long term, there must be a sweet spot. To clarify our > use of the RTT to prioritize addresses, we use historical RTT > measurements of all TCP packets on that route. If and when we release > an updated implementation, I will update this list. > > *) 464XLAT We've considered using this technology and decided that it > was not the best course of action. This doesn't mean we will never > consider it and we're definitely interested in discussing pros and > cons but in my humble (personal) opinion, calling us names to "get > our attention" is not likely to convince us that 464XLAT is the One > True Path to IPv6 deployment. > > As mentioned in my last message, all these details only reflect the > current betas and can change in the future. > > Thanks, David > > >> On Jun 19, 2015, at 14:46, David Schinazi > > wrote: >> >> Hi everyone, >> >> I'd like to clarify a few points about Apple's IPv6 announcements >> during WWDC 2015. The video (streaming with Safari or download with >> all browsers) and slides of that talk are available at: >> https://developer.apple.com/videos/wwdc/2015/?id=719 >> >> *) Personal hotspot on iOS If your iPhone has dual-stack >> connectivity on its cellular network, the hotspot it creates will >> be dual-stack as well. The phone will share its prefix with Wi-Fi >> clients. >> >> *) Internet Sharing on the Mac Today, regular internet sharing >> (from your ethernet to Wi-Fi for example) does not support IPv6 >> because of the limited use cases, and the lack of demand for it. >> >> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64 test >> mode was designed to help developers ensure that their app can >> still function with IPv6-only NAT64+DNS64 connectivity and >> communicate with their IPv4 server, even if the developer does not >> have access to the IPv6 internet. That NAT64 network does not have >> IPv6 connectivity to the global IPv6 internet. As such, the >> current version advertises addresses from 2001::/64 instead of ULAs >> to simulate real IPv6 connectivity, as all IPv6 packets are >> terminated at the NAT64 server on the Mac. This implementation >> detail could change in the future. >> >> *) Making IPv4 literals work on NAT64 networks when using >> high-level APIs Starting with this year's versions, if you use >> NSURLSession to connect to an IPv4 literal on an IPv6-only >> NAT64-DNS64 network, the API will bump in a IPv6 literal >> synthesized using RFC 7050. Note that this will not happen when >> using sockets directly. We do not support under-the-sockets >> bump-in-API (RFC 3338) and we do not support 464XLAT. >> >> *) Happy Eyeballs We've heard feedback on our Happy Eyeballs >> implementation and are investigating this topic. >> >> Note that this reflects how these technologies work in the current >> versions of the 2015 betas, many of these details could change in >> future betas. Please keep in mind that these betas are previews >> and we welcome feedback on improving them. >> >> Feel free to contact me if you have any questions, I will also >> attend IETF93. >> >> Thanks, David Schinazi Apple CoreOS Networking Engineer > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jun 24 07:35:17 2015 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 8DA3F1ACC8A for ; Wed, 24 Jun 2015 07:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 U5sKLalbLit1 for ; Wed, 24 Jun 2015 07:35:15 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A3B1ACC8D for ; Wed, 24 Jun 2015 07:35:12 -0700 (PDT) Received: by oiyy130 with SMTP id y130so31132356oiy.0 for ; Wed, 24 Jun 2015 07:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZknuTwDTIrbECkFA2tLxHdl/9AZwE5rs+jpx791Usb4=; b=kcd9K1bcUanufQ1NN0QtjgqxSZ/y0KMbhtfphhSU/gpFGJ9nZRUpSslFG2mrN8hRc8 +v9pHqenBUXpVzHmtxqiyjTuEjzc3rw0jtCrw02g8clEg082QJExmOrq+Us8663egQ8Q hW+uFQjWxebIf6Kdsm/9gctM7ULn3FodVBzbx0EMPeNX4uLuE+WuaQFk9WMnssnhVipw 3c5VLmWDxEK17Kr5w6saJHyLXh11epQoNkWGntgaC183zqBsJQhjEhX1wEy9wcRr/TpZ VZhnxMUZBVksBohie/xNHAKYkD5MAxeXA14cujyyvoE1fL+5FtIcOKIxzhOa7d/TlIHb mWEg== 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:from:date :message-id:subject:to:cc:content-type; bh=ZknuTwDTIrbECkFA2tLxHdl/9AZwE5rs+jpx791Usb4=; b=BIEoKle9KTT35IGrjRIWjQYKppILISbqDCYfClSV6rSe2Xu9lhAvykU5edsbwbplwh cBDpYGRS/AgOGWYW+RNdSQ+1BxYkLKQ9SLN/fV26gqmJ3dFvIAyKSxz3fbjPowHutuIU rR8VnTG/bN1w6Lyb/BH2XCuY7gn5NmSnbIi/+PBq3jOoCVzjdRdjwJORGt4FVq4dMxL3 MvfYscjRJKmJEOOlgrRIhVtzullcbtFZB5/FwV/Gze5VS1a6RShZBHLBG6+EussOqY5w XJDjKsZtGGh40u3KAmIVtynAGU+bxSAqNAYcvECt3HopbrnVfB0hdec8hhNgissWAs78 eVPw== X-Gm-Message-State: ALoCoQmjEzcuFhjMaCsdLabFNtRTckO93T4hCEizpt0Tivq5OdRb1nKI2cnGg8Sy4h/z1/7kTwPf X-Received: by 10.202.93.4 with SMTP id r4mr33578657oib.92.1435156511761; Wed, 24 Jun 2015 07:35:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.134.198 with HTTP; Wed, 24 Jun 2015 07:34:52 -0700 (PDT) In-Reply-To: References: <5587EFDD.6030807@gmail.com> From: Lorenzo Colitti Date: Wed, 24 Jun 2015 23:34:52 +0900 Message-ID: To: Ca By Content-Type: multipart/alternative; boundary=001a113d4a7414e2850519446a9e Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 24 Jun 2015 14:35:16 -0000 --001a113d4a7414e2850519446a9e Content-Type: text/plain; charset=UTF-8 On Wed, Jun 24, 2015 at 9:13 PM, Ca By wrote: > Does Android suppot dhcp-pd ? > :-) --001a113d4a7414e2850519446a9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 24, 2015 at 9:13 PM, Ca By <cb.list6@gmail.com> wro= te:
Does Android suppot dhcp-pd ?

:-)
--001a113d4a7414e2850519446a9e-- From nobody Wed Jun 24 08:10:22 2015 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 6B6031A8789 for ; Wed, 24 Jun 2015 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 sEgev1qFWiGs for ; Wed, 24 Jun 2015 08:10:18 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 69C6E1A871B for ; Wed, 24 Jun 2015 08:10:17 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8A34960173 for ; Wed, 24 Jun 2015 17:10:15 +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 481C96004D for ; Wed, 24 Jun 2015 17:10:15 +0200 (CEST) Received: (qmail 98666 invoked by uid 1007); 24 Jun 2015 17:10:15 +0200 Date: Wed, 24 Jun 2015 17:10:15 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150624151015.GN67883@Space.Net> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558ABAC3.4010802@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 24 Jun 2015 15:10:21 -0000 Hi, On Wed, Jun 24, 2015 at 04:12:19PM +0200, Alexandru Petrescu wrote: > I looked at the file. It does proxy Neighbor Discovery in order to > bridge. Proxy ND is an EXPERIMENTAL RFC4389. 64share is an > INFORMATIONAL RFC7278. This means they are not the perfect way to aim > for interoperability. An Apple smartphone could not talk to a GM car > (just examples of brand names). Crap. The devices on either sides will not see which method the device in the middle deploys to achieve reachability. 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 Jun 24 08:26:45 2015 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 2CD841A6EF2 for ; Wed, 24 Jun 2015 08:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 V4-s9C2WoV11 for ; Wed, 24 Jun 2015 08:26:42 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E493A1A0075 for ; Wed, 24 Jun 2015 08:26:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5OFQdqY030184; Wed, 24 Jun 2015 17:26:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EA96F2071A7; Wed, 24 Jun 2015 17:29:34 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D5AC1205C73; Wed, 24 Jun 2015 17:29:34 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5OFQce9030070; Wed, 24 Jun 2015 17:26:39 +0200 Message-ID: <558ACC2F.7060509@gmail.com> Date: Wed, 24 Jun 2015 17:26:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Gert Doering References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> In-Reply-To: <20150624151015.GN67883@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 24 Jun 2015 15:26:44 -0000 Le 24/06/2015 17:10, Gert Doering a écrit : > Hi, > > On Wed, Jun 24, 2015 at 04:12:19PM +0200, Alexandru Petrescu wrote: >> I looked at the file. It does proxy Neighbor Discovery in order to >> bridge. Proxy ND is an EXPERIMENTAL RFC4389. 64share is an >> INFORMATIONAL RFC7278. This means they are not the perfect way to aim >> for interoperability. An Apple smartphone could not talk to a GM car >> (just examples of brand names). > > Crap. The devices on either sides will not see which method the device > in the middle deploys to achieve reachability. Crap? The smartphone doing ND proxy is useless if the car's router is not doing the same. And currently car routers dont do ND proxy. ---------- --------- ------ 4G--|smartphone|-----BT-------|CarRouter|------hotspotWiFi------|tablet| ---------- --------- ------ Alex > > Gert Doering > -- NetMaster > From nobody Wed Jun 24 09:19:05 2015 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 596981B2AE7 for ; Wed, 24 Jun 2015 09:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 gvIPLjMJDye7 for ; Wed, 24 Jun 2015 09:19:01 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 4197F1B2AED for ; Wed, 24 Jun 2015 09:19:00 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F2FE662ED7 for ; Wed, 24 Jun 2015 18:18:58 +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 C02EF6087A for ; Wed, 24 Jun 2015 18:18:58 +0200 (CEST) Received: (qmail 2775 invoked by uid 1007); 24 Jun 2015 18:18:58 +0200 Date: Wed, 24 Jun 2015 18:18:58 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150624161858.GP67883@Space.Net> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YHX+EHVZpmeyURU8" Content-Disposition: inline In-Reply-To: <558ACC2F.7060509@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 24 Jun 2015 16:19:03 -0000 --YHX+EHVZpmeyURU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 24, 2015 at 05:26:39PM +0200, Alexandru Petrescu wrote: > > Crap. The devices on either sides will not see which method the device > > in the middle deploys to achieve reachability. >=20 > Crap? The smartphone doing ND proxy is useless if the car's router is=20 > not doing the same. And currently car routers dont do ND proxy. Crap. > ---------- --------- ------ > 4G--|smartphone|-----BT-------|CarRouter|------hotspotWiFi------|tablet| > ---------- --------- ------ So? What "smartphone" does is of no interest to "CarRouter". It ** WILL ** ** NOT ** ** SEE ** which method "smartphone" deploys to achieve reachability. 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 --YHX+EHVZpmeyURU8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVYrYct9WwGXkzn/FAQJIGA//fTwjHJCXQkyuOWoZnU65lVQnb8H+mvXA gZOTD/ciWOFb533Vm/K0Ba3XPscw3hxlSAfAFjwrCEBtYCQPXgXWWQZ0l9b3lVM6 JRwXS8/9YFHDU9REoUjxl3T6UphnaFWB8Innavd62FXCeG7xSVQ5ycylagY423r1 2b44OpClRq5wdlYux7M3zXh8MirHOtNgxrAePxBotbZT0kn0GmoyEKMpQgKqrC+v odxPoZNsZAH5vlbbfs1UuW5O8Tu83krFNFdBvaQ0usjQG2KBtzs/WduxJWofO49J etBI82akERuALds0Wx0O8hIYe3YJBx5PRmVNpk9YLhDO9fRnOfF+0st78v2U+O2n see1M5oU9ALgp3TDFqjBIHEpi0WX6EdTDTt6drSCCMqsLshYaDR8ISRP6Yv1aeRk MkMO+XuY48H2b43nTQo5HKoksEl8sQozEJjg6bM/NwamXpawRzaP+xbvX672PGoS Oa30RvNd2RGskSL++oACdgnC7jMbw6VbhdcGjb3iLWqGk94NgYWlWvOVi9+SRr6T PCYpV3OfNZ0SWjb+p/TU3jQmsOK+6r9Bm9QteSJ+34CEtTK+PMu86GA7B7h8+c2f 37viCisdOzASjdpNKgk5pquNvfJKflrZgc9815o8PO4kWJku7dGp9Tqn8i7Pr+0T 5sV1dhXktZ8= =TNqd -----END PGP SIGNATURE----- --YHX+EHVZpmeyURU8-- From nobody Wed Jun 24 11:27:38 2015 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 C8CF91ACE84 for ; Wed, 24 Jun 2015 11:27:36 -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, 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 UBWEC0IbWGco for ; Wed, 24 Jun 2015 11:27:35 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118931ACE74 for ; Wed, 24 Jun 2015 11:27:34 -0700 (PDT) Received: by igin14 with SMTP id n14so39790242igi.1 for ; Wed, 24 Jun 2015 11:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vZGSwncwWMboammYoCI3s83Oqdv/0vJWWZzWVGF8WE4=; b=D7u07qGmgb5UK+q8fMcBqLMedvu2Trk/718EoHPFRzvGUqY48QT0MER/2YHgPH4xT2 jioEBdRZWeD/pPll/YhwRf0M37uZIwZXhbsXAEQeMT9XMOgZqHqpIHrFMckiXE0DHItc H7qAvidhue0mteR7CE37bo27EhuUATmGlR/sI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vZGSwncwWMboammYoCI3s83Oqdv/0vJWWZzWVGF8WE4=; b=BNna4Hqe5GWI0SeaLQpTkdcULmg4PNdy71HYXUXGFxx8IHSTT4sgtrocGpacnzM7yI 9pVQvZ+HkNudH+x4lS7DkYJPvDsCt/LMaPJFnV5PSW0XVphGm0yFyasioHXiGVgWTlD8 Zry2ca6QsK7GELCJkE6kArPC1uc5MKHNbnpax/WH688BIuwdFRmZcz9tJX4zqFNFhIGt zVGi7hBtkouWW7FmAfEw2/Ngvi+IvaSby3NNfJH6rWcVU1rCz9qLZS9Y/wDXvWvrqHo8 QMAj8NTu1Attu6eU6bsRUaZSivKNSSYgZPwNbbqptcLLkhQj4QbEongqk7oTHO/SpBMD 3IlQ== X-Gm-Message-State: ALoCoQkOmLsGIO5Ne1rRipbQ7Bhow0E51qS1nmxZXsYp+ojfHOnNyhuLXn0YE+r5vGbKSR0+X7Cs X-Received: by 10.43.39.208 with SMTP id tn16mr38215430icb.27.1435170454351; Wed, 24 Jun 2015 11:27:34 -0700 (PDT) Received: from dhcp-100-100-99-154.pao.corp.google.com ([100.100.99.154]) by mx.google.com with ESMTPSA id n15sm3592088ioi.9.2015.06.24.11.27.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 11:27:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6835E72B-D204-4C37-8EF6-04C96A477359" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: james woodyatt In-Reply-To: Date: Wed, 24 Jun 2015 11:27:31 -0700 Message-Id: <272BEF29-C175-4889-8119-8544084E9C1F@nestlabs.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> To: Ca By X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 24 Jun 2015 18:27:37 -0000 --Apple-Mail=_6835E72B-D204-4C37-8EF6-04C96A477359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 24, 2015, at 05:52, Ross Chandler wrote: >> On 22 Jun 2015, at 23:58, Ca By > wrote: >>=20 >> For some subset of networks, devs can test the real production deal = if apple could surface the apn setting in dev builds. It is hard to see = the harm in this. Other OSs allow apn setting fiddling. Also, this = allows an escape hatch for the inevitable user who cannot deal with = ipv6-only in production... And opens the door for end user opt in trials = of ipv6.=20 >>=20 >> It's really not a hard problem to solve for many situations (like = tmus) but the some backwards place .... They may not have this luxury = of proper ipv6 in mobile :/ >>=20 >> CB=20 >=20 > +1 >=20 > At lot of people that could help with IPv6-only deployment lose = interest when they hear that they have to have an Android or Windows = Phone to try it. Another aggravation regarding IPv6-only APNs on iOS is that an unlocked = iPhone is unable to use an IPv6-only APN. The only way in iOS to control = the type of the APN is with a provisioning profile, and these are not = used on unlocked phones. Maybe one of the carriers with sufficient = influence with Apple Core OS Engineering that their demands have some = hope of sticking could complain to them about this? It=E2=80=99s the = reason I can=E2=80=99t use IPv6 APNs when I=E2=80=99m traveling on a = foreign SIM card. I know, I know, like there is such a carrier who has = any interest in seeing unlocked phones have any more useful features. =E2=80=94james --Apple-Mail=_6835E72B-D204-4C37-8EF6-04C96A477359 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 24, 2015, at 05:52, Ross Chandler <ross@eircom.net> = wrote:
On 22 = Jun 2015, at 23:58, Ca By <cb.list6@gmail.com> wrote:

For some subset of = networks, devs can test the real production deal if apple could surface = the apn setting in dev builds. It is hard to see the harm in this. Other = OSs allow apn setting fiddling. Also, this allows an escape hatch for = the inevitable user who cannot deal with ipv6-only in production... And = opens the door for end user opt in trials of ipv6. 

It's really not a hard = problem to solve for many situations (like tmus)  but the some = backwards place .... They may not have this luxury of proper ipv6 in = mobile :/

CB 

+1

At = lot of people that could help with IPv6-only deployment lose interest = when they hear that they have to have an Android or Windows Phone to try = it.

Another = aggravation regarding IPv6-only APNs on iOS is that an unlocked iPhone = is unable to use an IPv6-only APN. The only way in iOS to control the = type of the APN is with a provisioning profile, and these are not used = on unlocked phones. Maybe one of the carriers with sufficient influence = with Apple Core OS Engineering that their demands have some hope of = sticking could complain to them about this? It=E2=80=99s the reason I = can=E2=80=99t use IPv6 APNs when I=E2=80=99m traveling on a foreign SIM = card. I know, I know, like there is such a carrier who has any interest = in seeing unlocked phones have any more useful features.


=E2=80=94james

= --Apple-Mail=_6835E72B-D204-4C37-8EF6-04C96A477359-- From nobody Wed Jun 24 11:38:13 2015 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 610821ACEDC for ; Wed, 24 Jun 2015 11:38:10 -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, 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 nl9fIUAvUfXQ for ; Wed, 24 Jun 2015 11:38:09 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97691ACED8 for ; Wed, 24 Jun 2015 11:38:08 -0700 (PDT) Received: by igbqq3 with SMTP id qq3so121099936igb.0 for ; Wed, 24 Jun 2015 11:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4uKSU/spXdXmTU9z4+85Ha5Y6sjqtFj4DekrLUApg2A=; b=GVfOQ/YfVlUDir3ZFiVpDGJWxnQ6aYz0wc8oYT3aMtq2qrodeKkgK5wmDtOCXKR1pp 9Mj+g9QGYS6gIYohMeo+8H1Qvm/i374x0fiohcU429XARtL2EdYQG1q24fjVsQ+9T02N ll/7ryQug+Pt3wC7pZh7eTUvHv2ntj3yrksrY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4uKSU/spXdXmTU9z4+85Ha5Y6sjqtFj4DekrLUApg2A=; b=X6vGARBHkpBX9OvkjaBKJvNiFt17ttj/U2/qR6FgAHA0QNA+HO7wAkZE21y8BkVXpm eZ+dgwVMOvOBc3PXAtctVWpZaoIm1VQ9yUDUMrdHRxQMDtEMnMrxxwRf1vU0w0XrVdI5 OklO8zfPsc5RRDVyPDy80B1Ic9utyrKyakDTAMN2n2W3q2mrmwgeXy/tKTUFaEmvPhkz 7RSpojFgIfgg3jRUn3hH270or2V36CFCerh89db8bYwQF9nbZDGKXbLQfL/pTTNnX4qN R3pv2BJn7WAAFdntq7t34RH8wnFZUBgn8+pAcWHLrGxf+J6xojfZqpJSoYJ2EhSNBzAy WX4w== X-Gm-Message-State: ALoCoQkMGCRy9XsNVm5qkdBj4O71+ToPAwIzkpWxby64ofKM/zzhfnt4KMAi+z8DqyWYW6v9xpMe X-Received: by 10.42.88.197 with SMTP id d5mr39300645icm.44.1435171088399; Wed, 24 Jun 2015 11:38:08 -0700 (PDT) Received: from dhcp-100-100-99-154.pao.corp.google.com ([100.100.99.154]) by mx.google.com with ESMTPSA id p39sm17829774ioi.5.2015.06.24.11.38.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 11:38:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_673B5579-61FF-4A7A-88AE-CE9EC196336E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: james woodyatt In-Reply-To: <558ABAC3.4010802@gmail.com> Date: Wed, 24 Jun 2015 11:38:06 -0700 Message-Id: <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 24 Jun 2015 18:38:10 -0000 --Apple-Mail=_673B5579-61FF-4A7A-88AE-CE9EC196336E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 24, 2015, at 07:12, Alexandru Petrescu = wrote: >=20 > [=85] In the car use-case the smartphone connects to the dashboard = using a ptp > link. And it's the car's dashboard which offers a WiFi hotspot. = These > couldn't be bridged (ND proxy) by the smartphone alone, it would need > the dashboard router to participate in this ND proxy. [=85] I suspect the point you may be missing here is the logic encoded = elsewhere in iOS that restricts the use of Mobile Internet Sharing to = the telephony uplink. It is not possible with iOS to share Internet = access over the Wi-fi (or other interfaces) with tethered devices. Only = the telephony data service is eligible for Mobile Internet Sharing. Shorter james: the automotive Wi-fi hotspot use case is like every other = Wi-fi hotspot as far as iOS is concerned, i.e. every phone on Wi-fi is = an ordinary host and not a ND proxy or a router. =97james= --Apple-Mail=_673B5579-61FF-4A7A-88AE-CE9EC196336E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Jun 24, 2015, at 07:12, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

[=85] In the car use-case = the smartphone connects to the dashboard using a ptp
link.  And it's the car's dashboard which = offers a WiFi hotspot.  These
couldn't be bridged (ND proxy) by the smartphone = alone, it would need
the dashboard router to = participate in this ND proxy. [=85]

I suspect the point you may be missing here is the = logic encoded elsewhere in iOS that restricts the use of Mobile Internet = Sharing to the telephony uplink. It is not possible with iOS to share = Internet access over the Wi-fi (or other interfaces) with tethered = devices. Only the telephony data service is eligible for Mobile Internet = Sharing.

Shorter james: the = automotive Wi-fi hotspot use case is like every other Wi-fi hotspot as = far as iOS is concerned, i.e. every phone on Wi-fi is an ordinary host = and not a ND proxy or a router.

=97james
= --Apple-Mail=_673B5579-61FF-4A7A-88AE-CE9EC196336E-- From nobody Wed Jun 24 16:41:37 2015 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 862CC1ACD93 for ; Wed, 24 Jun 2015 16:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QeIk9EBurFQy for ; Wed, 24 Jun 2015 16:41:35 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864A81ACD22 for ; Wed, 24 Jun 2015 16:41:35 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 31BB23493BE; Wed, 24 Jun 2015 23:41:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 27213160048; Wed, 24 Jun 2015 23:42:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0C53216004F; Wed, 24 Jun 2015 23:42:14 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yzm0MypCQLeA; Wed, 24 Jun 2015 23:42:13 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 95173160048; Wed, 24 Jun 2015 23:42:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 47252313E1E5; Thu, 25 Jun 2015 09:41:29 +1000 (EST) To: Gert Doering From: Mark Andrews References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> In-reply-to: Your message of "Wed, 24 Jun 2015 18:18:58 +0200." <20150624161858.GP67883@Space.Net> Date: Thu, 25 Jun 2015 09:41:29 +1000 Message-Id: <20150624234129.47252313E1E5@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 24 Jun 2015 23:41:36 -0000 In message <20150624161858.GP67883@Space.Net>, Gert Doering writes: > Hi, > > On Wed, Jun 24, 2015 at 05:26:39PM +0200, Alexandru Petrescu wrote: > > > Crap. The devices on either sides will not see which method the > device > > > in the middle deploys to achieve reachability. > > > > Crap? The smartphone doing ND proxy is useless if the car's router is > > not doing the same. And currently car routers dont do ND proxy. > > Crap. > > > ---------- --------- ------ > > 4G--|smartphone|-----BT-------|CarRouter|------hotspotWiFi------|tablet| > > ---------- --------- ------ > > So? What "smartphone" does is of no interest to "CarRouter". It > > ** WILL ** > ** NOT ** > ** SEE ** > > which method "smartphone" deploys to achieve reachability. If the smart phones in doing ND proxy then there is no PD therefore the hotspotWiFi won't have a GUA prefix. This we will kludge cellphones instead of just doing it right in the first place is coming back to bite us. > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 24 19:59:07 2015 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 127BC1A903C for ; Wed, 24 Jun 2015 19:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rjVkhXO0U67A for ; Wed, 24 Jun 2015 19:59:04 -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 0F3691A8FD5 for ; Wed, 24 Jun 2015 19:59:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 476EEA1; Thu, 25 Jun 2015 04:59:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1435201142; bh=szoXJe6ecea8ykG9/VOVeWIB0H75wbP++z4uS3IABt0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CoJA8a+AUp5UgcGWiKg1H6D/ZhSCYx7cYKcbVj+Mlqznm8ClX/KofSELajsH1bNzd 8UdseNQOY5M/krp757hdlc20dFFtGvgFhXtTZYIvG9/qGMIArGVCabIbA67ZNEDEfn UgtbNG1xQqRYZk8e54Qb98olh5GsGLinvw7pqn/0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3D2249F; Thu, 25 Jun 2015 04:59:02 +0200 (CEST) Date: Thu, 25 Jun 2015 04:59:02 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: <272BEF29-C175-4889-8119-8544084E9C1F@nestlabs.com> Message-ID: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <272BEF29-C175-4889-8119-8544084E9C1F@nestlabs.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1404771655-1435201142=:9487" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 25 Jun 2015 02:59:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1404771655-1435201142=:9487 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 24 Jun 2015, james woodyatt wrote: > Another aggravation regarding IPv6-only APNs on iOS is that an unlocked > iPhone is unable to use an IPv6-only APN. The only way in iOS to control > the type of the APN is with a provisioning profile, and these are not > used on unlocked phones. I don't know what you mean by "provisioning profile", but my wifes unlocked iPhone6+ received an update to her carrier profile with iOS 8.3 and it used the IPv4v6 APN just fine without any kind of user intervention. > influence with Apple Core OS Engineering that their demands have some > hope of sticking could complain to them about this? It’s the reason I > can’t use IPv6 APNs when I’m traveling on a foreign SIM card. I know, I > know, like there is such a carrier who has any interest in seeing > unlocked phones have any more useful features. Well, the major thing here is Apple controls and approves the profile, not the carrier. There are plenty of carriers who are interested but who have to convince Apple to get changes done. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1404771655-1435201142=:9487-- From nobody Thu Jun 25 00:13:42 2015 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 C10481B2A93 for ; Thu, 25 Jun 2015 00:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 HBsM01O21DOG for ; Thu, 25 Jun 2015 00:13:39 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 DF7671B2A82 for ; Thu, 25 Jun 2015 00:13:37 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 38C8C62D87 for ; Thu, 25 Jun 2015 09:13:36 +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 0B3F160821 for ; Thu, 25 Jun 2015 09:13:36 +0200 (CEST) Received: (qmail 53442 invoked by uid 1007); 25 Jun 2015 09:13:35 +0200 Date: Thu, 25 Jun 2015 09:13:35 +0200 From: Gert Doering To: Mark Andrews Message-ID: <20150625071335.GQ67883@Space.Net> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TVvFCdSJ1YJh/5iY" Content-Disposition: inline In-Reply-To: <20150624234129.47252313E1E5@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 07:13:40 -0000 --TVvFCdSJ1YJh/5iY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jun 25, 2015 at 09:41:29AM +1000, Mark Andrews wrote: > If the smart phones in doing ND proxy then there is no PD therefore > the hotspotWiFi won't have a GUA prefix. >=20 > This we will kludge cellphones instead of just doing it right in > the first place is coming back to bite us. Smartphones can do PD all they want - if the mobile operator isn't *offering* PD, there's not very much they can do. "Offer no IPv6 for tethered clients" or "do proxy ND / bridge the /64". Pick your poison. 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 --TVvFCdSJ1YJh/5iY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVYuqH99WwGXkzn/FAQKuNw//QmOUHazx2uKodAoARV8IXMYL6jRXQt0L EEUWWKlvaOpDrmnf4DEpfUpGvgB7Ner6STH5ccUxHFJ+dt72Flwg22vborGSytax M5aC/MkJn8PuTku1YSPudMZUG5Yfpc5nufgFBlpxKkp7HoQY/Gx9lTZosf+XILQj GO8V9UtvekDJiEjL4zBb08MrYiiQWGkt2YR057gWusXj34fpkTHmpMGHo1t/4SJN rHtAd4Nf5D5Kk9I0o691MJgdrUh3Gqt35XIiJNTeNgzB/bfOCk++EA1BxDVXSF7n j7gE1yZE4cpHN1/LgMuQWOH0u0ILivZRiy0BVNHDYx0V11z9D2YeNKGDppV5bQu1 w+T3iZXYKc2rZaKZvIy4EkF2xlwfo5unlTbyBYyHltddpUoDoRgApe/mQtoBoS6r 0RfDbi/VZP0Z3qQpvUINHcsGhMiYU1H6WjU5ao3FaQHRL4fOyfMZ/cAr7NsLK7DS mVpq943aOxpvNYkgv6y+t5fWV8vZaBm9dMP1HnpvzzXE8j0/As0urzPWjNyds7du z5Ccj5SQH2xNwz5twabVP13iO9Fn1TEPVZGnHtNyzp1bZ0rJUq9s2qEOwHwiVGLX UoN50K+3VsP18AEOXcTii08ApixC8Z4MvSkaZ5+JLV3ApzL+pxTtdTTJbD1kISgX 8+Y1Q+2EEvg= =noIL -----END PGP SIGNATURE----- --TVvFCdSJ1YJh/5iY-- From nobody Thu Jun 25 01:59:49 2015 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 7C97E1B335F for ; Thu, 25 Jun 2015 01:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 kuxqNhJejYsJ for ; Thu, 25 Jun 2015 01:59:47 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FC61B335D for ; Thu, 25 Jun 2015 01:59:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5P8xiAf012482; Thu, 25 Jun 2015 10:59:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0CB29203072; Thu, 25 Jun 2015 11:02:41 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E846D200CD9; Thu, 25 Jun 2015 11:02:40 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5P8xdDJ015074; Thu, 25 Jun 2015 10:59:44 +0200 Message-ID: <558BC2FB.3020801@gmail.com> Date: Thu, 25 Jun 2015 10:59:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Gert Doering , Mark Andrews References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> In-Reply-To: <20150625071335.GQ67883@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 08:59:48 -0000 Le 25/06/2015 09:13, Gert Doering a écrit : > Hi, > > On Thu, Jun 25, 2015 at 09:41:29AM +1000, Mark Andrews wrote: >> If the smart phones in doing ND proxy then there is no PD >> therefore the hotspotWiFi won't have a GUA prefix. >> >> This we will kludge cellphones instead of just doing it right in >> the first place is coming back to bite us. > > Smartphones can do PD all they want - if the mobile operator isn't > *offering* PD, there's not very much they can do. After reading Mikael's email pointing to a 3gpp spec of late 2014 mandating DHCPv6-PD to both UE and core network - I must say I am optimistic about the arrival of DHCPv6-PD to cellular network operators. Currently, some cellular networks already offer DHCPv6 together with SLAAC. Technically that DHCPv6 is extremely simple to upgrade to DHCPv6-PD. My question is when? I can speculate it will be in late 2016. Because 4G was in specs 2 years before trial deployments. > "Offer no IPv6 for tethered clients" or "do proxy ND / bridge the > /64". > > Pick your poison. Good if it were that simple. But I am afraid there's a 3rd choice more poisonous than you present. Alex > > Gert Doering -- NetMaster > From nobody Thu Jun 25 02:11:19 2015 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 83EF11B3200 for ; Thu, 25 Jun 2015 02:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 3lNJNBsDetXc for ; Thu, 25 Jun 2015 02:11:17 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECE51B31F4 for ; Thu, 25 Jun 2015 02:11:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5P9BEhI019992; Thu, 25 Jun 2015 11:11:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 838652030BD; Thu, 25 Jun 2015 11:14:11 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 76FFE202EBA; Thu, 25 Jun 2015 11:14:11 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5P9BBPj008673; Thu, 25 Jun 2015 11:11:14 +0200 Message-ID: <558BC5AF.3060406@gmail.com> Date: Thu, 25 Jun 2015 11:11:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: james woodyatt References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> In-Reply-To: <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 09:11:18 -0000 Le 24/06/2015 20:38, james woodyatt a écrit : > On Jun 24, 2015, at 07:12, Alexandru Petrescu > > > wrote: >> >> […] In the car use-case the smartphone connects to the dashboard >> using a ptp link. And it's the car's dashboard which offers a >> WiFi hotspot. These couldn't be bridged (ND proxy) by the >> smartphone alone, it would need the dashboard router to participate >> in this ND proxy. […] > > I suspect the point you may be missing here is the logic encoded > elsewhere in iOS that restricts the use of Mobile Internet Sharing > to the telephony uplink. It is not possible with iOS to share > Internet access over the Wi-fi (or other interfaces) with tethered > devices. Only the telephony data service is eligible for Mobile > Internet Sharing. That is a good point. There is an ongoing technical debate in the car comm community - should the smartphone provide Internet connectivity to the car? Or should the smartphone use the Internet connectivity offered by the car. Right now where I live a large number of marketed cars are on the first option. It is on that option that I think smartphone's iOS Mobile Internet Sharing can help, provided it does more than NDproxy. > Shorter james: the automotive Wi-fi hotspot use case is like every > other Wi-fi hotspot as far as iOS is concerned, i.e. every phone on > Wi-fi is an ordinary host and not a ND proxy or a router. Well I did not mean the smartphones using car's hotspots. That's for WiFi-only tablets. The NDproxy problem in iOS is in the case where cars create hotspots by their own means, but disconnected from the Internet. All they need is to reach the Internet somehow without having to put a SIMcard in the car. And that's where cars connect to the smartphone with Bluetooth. (cars already connect to smartphone with bluetooth for Audio-Video screen replication and phone calls (although phone calls are going to be completely forbidden soon even for handsfree)). Alex > > —james From nobody Thu Jun 25 02:14:05 2015 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 E247C1B3395 for ; Thu, 25 Jun 2015 02:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 J1rGO-Iuio9X for ; Thu, 25 Jun 2015 02:14:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA691B3200 for ; Thu, 25 Jun 2015 02:14:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5P9Dxke020135; Thu, 25 Jun 2015 11:13:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5E81A203103; Thu, 25 Jun 2015 11:16:56 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 56E1A2030A3; Thu, 25 Jun 2015 11:16:56 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5P9DxQR012406; Thu, 25 Jun 2015 11:13:59 +0200 Message-ID: <558BC657.2030802@gmail.com> Date: Thu, 25 Jun 2015 11:13:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mark Andrews , Gert Doering References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> In-Reply-To: <20150624234129.47252313E1E5@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 09:14:04 -0000 Le 25/06/2015 01:41, Mark Andrews a écrit : > > In message <20150624161858.GP67883@Space.Net>, Gert Doering writes: >> Hi, >> >> On Wed, Jun 24, 2015 at 05:26:39PM +0200, Alexandru Petrescu wrote: >>>> Crap. The devices on either sides will not see which method the >> device >>>> in the middle deploys to achieve reachability. >>> >>> Crap? The smartphone doing ND proxy is useless if the car's router is >>> not doing the same. And currently car routers dont do ND proxy. >> >> Crap. >> >>> ---------- --------- ------ >>> 4G--|smartphone|-----BT-------|CarRouter|------hotspotWiFi------|tablet| >>> ---------- --------- ------ >> >> So? What "smartphone" does is of no interest to "CarRouter". It >> >> ** WILL ** >> ** NOT ** >> ** SEE ** >> >> which method "smartphone" deploys to achieve reachability. > > If the smart phones in doing ND proxy then there is no PD therefore > the hotspotWiFi won't have a GUA prefix. > > This we will kludge cellphones instead of just doing it right in > the first place is coming back to bite us. I agree. We have already seen this with cable boxes at home: the first IPv6 cable boxes ten years ago were also doing ND proxy. Not any longer - the now-classic home boxes have several /64s to deliver how they like to the home's subnets. Alex > >> 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 From nobody Thu Jun 25 02:15:21 2015 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 7DA651B321C for ; Thu, 25 Jun 2015 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 vqRqtInIn-UN for ; Thu, 25 Jun 2015 02:15:18 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B6F1B2C4A for ; Thu, 25 Jun 2015 02:15:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5P9FG7Q003412; Thu, 25 Jun 2015 11:15:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1E3912030C9; Thu, 25 Jun 2015 11:18:13 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 09FFC200D12; Thu, 25 Jun 2015 11:18:13 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5P9FFew014150; Thu, 25 Jun 2015 11:15:16 +0200 Message-ID: <558BC6A3.8030700@gmail.com> Date: Thu, 25 Jun 2015 11:15:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Gert Doering References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> In-Reply-To: <20150624161858.GP67883@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 09:15:20 -0000 Le 24/06/2015 18:18, Gert Doering a écrit : > Hi, > > On Wed, Jun 24, 2015 at 05:26:39PM +0200, Alexandru Petrescu wrote: >>> Crap. The devices on either sides will not see which method the device >>> in the middle deploys to achieve reachability. >> >> Crap? The smartphone doing ND proxy is useless if the car's router is >> not doing the same. And currently car routers dont do ND proxy. > > Crap. > >> ---------- --------- ------ >> 4G--|smartphone|-----BT-------|CarRouter|------hotspotWiFi------|tablet| >> ---------- --------- ------ > > So? What "smartphone" does is of no interest to "CarRouter". It > > ** WILL ** > ** NOT ** > ** SEE ** > > which method "smartphone" deploys to achieve reachability. That's why the CarRouters are pure routers and dont do NDproxy. And that's why CarRouters need the smartphones to provide them DHCPv6 Prefix Delegation in return. Alex > > Gert Doering > -- NetMaster > From nobody Thu Jun 25 02:29:04 2015 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 4D9901B33E0 for ; Thu, 25 Jun 2015 02:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qvPTJ_ovFWnJ for ; Thu, 25 Jun 2015 02:29:01 -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 343791B340F for ; Thu, 25 Jun 2015 02:28:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D16BAA1; Thu, 25 Jun 2015 11:28:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1435224528; bh=TvME6BLuiwGorfvj5AO5aHaha3anw3c0OuRuq6ztFak=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nT+BTa0PHEJBaeM6/6L9CiN46rs8HEV5yjh9kw5NqPStZ3hTuFwWvcUdQQX+hJ/Qw Yv7sD9Rmac7auIISZZpCRxJnpmYFHTlg04/P+Dichzw4YZe3lG0j5yFIUwZN8AqVTo MpsGAZybGqJkVbUlbW75gjpYk/V6jesJBlunGXM8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CC3BD9F; Thu, 25 Jun 2015 11:28:48 +0200 (CEST) Date: Thu, 25 Jun 2015 11:28:48 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <558BC2FB.3020801@gmail.com> Message-ID: References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@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; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 09:29:03 -0000 On Thu, 25 Jun 2015, Alexandru Petrescu wrote: > After reading Mikael's email pointing to a 3gpp spec of late 2014 > mandating DHCPv6-PD to both UE and core network - I must say I am > optimistic about the arrival of DHCPv6-PD to cellular network operators. > > Currently, some cellular networks already offer DHCPv6 together with > SLAAC. Technically that DHCPv6 is extremely simple to upgrade to DHCPv6-PD. > > My question is when? > > I can speculate it will be in late 2016. Because 4G was in specs 2 > years before trial deployments. To repeat myself: DHCPv6-PD requirement didn't appear in 2014. http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts_123401v100300p.pdf from 2011-MARCH contains prefix delegation, and since it's not available in release 9, it seems this is indeed a LTE release 10 feature that is more than 4 years old, and still there isn't widespread implementation of it that I am aware of. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jun 25 02:54:56 2015 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 0B2001B3500 for ; Thu, 25 Jun 2015 02:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 xp6v6S-f26v1 for ; Thu, 25 Jun 2015 02:54:53 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EE01B34F8 for ; Thu, 25 Jun 2015 02:54:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5P9spb1021700; Thu, 25 Jun 2015 11:54:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 11BA02031A0; Thu, 25 Jun 2015 11:57:48 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 059AA203109; Thu, 25 Jun 2015 11:57:48 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5P9so28016071; Thu, 25 Jun 2015 11:54:51 +0200 Message-ID: <558BCFEA.8000009@gmail.com> Date: Thu, 25 Jun 2015 11:54:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 09:54:55 -0000 Le 25/06/2015 11:28, Mikael Abrahamsson a écrit : > On Thu, 25 Jun 2015, Alexandru Petrescu wrote: > >> After reading Mikael's email pointing to a 3gpp spec of late 2014 >> mandating DHCPv6-PD to both UE and core network - I must say I am >> optimistic about the arrival of DHCPv6-PD to cellular network operators. >> >> Currently, some cellular networks already offer DHCPv6 together with >> SLAAC. Technically that DHCPv6 is extremely simple to upgrade to >> DHCPv6-PD. >> >> My question is when? >> >> I can speculate it will be in late 2016. Because 4G was in specs 2 >> years before trial deployments. > > To repeat myself: > > DHCPv6-PD requirement didn't appear in 2014. > > http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts_123401v100300p.pdf > from 2011-MARCH contains prefix delegation, and since it's not available > in release 9, it seems this is indeed a LTE release 10 feature that is > more than 4 years old, and still there isn't widespread implementation > of it that I am aware of. This makes either the specs irrelevant or the products on the market non-conformant. An UE implements DHCPv6-PD and the core network does not reply to PD requests although it replies to DHCPv6 address requests) is a violation of specification. Alex > From nobody Thu Jun 25 02:57:54 2015 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 70AA61B3503 for ; Thu, 25 Jun 2015 02:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhBeScyXxBuW for ; Thu, 25 Jun 2015 02:57:50 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A13C1B3501 for ; Thu, 25 Jun 2015 02:57:50 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t5P9vm3l042734 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Jun 2015 10:57:48 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local To: v6ops@ietf.org References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@gmail.com> <558BCFEA.8000009@gmail.com> From: Nick Hilliard Message-ID: <558BD09C.9030104@foobar.org> Date: Thu, 25 Jun 2015 10:57:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <558BCFEA.8000009@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 09:57:52 -0000 On 25/06/2015 10:54, Alexandru Petrescu wrote: > An UE implements DHCPv6-PD and the core network does not reply to PD > requests although it replies to DHCPv6 address requests) is a violation of > specification. Do you have names and addresses and we'll set the protocol police on the immediately? Nick From nobody Thu Jun 25 04:02:21 2015 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 0EFB51B3534 for ; Thu, 25 Jun 2015 04:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 sIxCtezgb04l for ; Thu, 25 Jun 2015 04:02:18 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 E01621A01AE for ; Thu, 25 Jun 2015 04:02:17 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0939B62ED6 for ; Thu, 25 Jun 2015 13:02:14 +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 C1ADE60152 for ; Thu, 25 Jun 2015 13:02:13 +0200 (CEST) Received: (qmail 72884 invoked by uid 1007); 25 Jun 2015 13:02:13 +0200 Date: Thu, 25 Jun 2015 13:02:13 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150625110213.GB67883@Space.Net> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@gmail.com> <558BCFEA.8000009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558BCFEA.8000009@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 11:02:20 -0000 Hi, On Thu, Jun 25, 2015 at 11:54:50AM +0200, Alexandru Petrescu wrote: > This makes either the specs irrelevant or the products on the market > non-conformant. Good morning. So you finally start seeing the light. 3G mandated(!) IPv6 over 10 years ago. Conclusions left as homework for the interested reader. 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 Thu Jun 25 04:21:54 2015 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 66CE31B3543 for ; Thu, 25 Jun 2015 04:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 IasF8OoXGjcS for ; Thu, 25 Jun 2015 04:21:46 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1EA1B3318 for ; Thu, 25 Jun 2015 04:21:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5PBLi4E020082 for ; Thu, 25 Jun 2015 13:21:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 31D31203202 for ; Thu, 25 Jun 2015 13:24:41 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 206A3203201 for ; Thu, 25 Jun 2015 13:24:41 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5PBLeiC002628 for ; Thu, 25 Jun 2015 13:21:44 +0200 Message-ID: <558BE444.9050007@gmail.com> Date: Thu, 25 Jun 2015 13:21:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@gmail.com> <558BCFEA.8000009@gmail.com> <558BD09C.9030104@foobar.org> In-Reply-To: <558BD09C.9030104@foobar.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 11:21:48 -0000 Le 25/06/2015 11:57, Nick Hilliard a écrit : > On 25/06/2015 10:54, Alexandru Petrescu wrote: >> An UE implements DHCPv6-PD and the core network does not reply to >> PD requests although it replies to DHCPv6 address requests) is a >> violation of specification. > > Do you have names and addresses and we'll set the protocol police on > the immediately? :-) ok police is about human behaviour. But specs (especially 3gpp specs) are spread throughout procurement contracts. If these specifications can not be trusted then all clauses break. One doesnt like to pay amount but get less. Alex > > Nick > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Jun 25 04:28:31 2015 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 701911B353C for ; Thu, 25 Jun 2015 04:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 exO-vxO0dgHw for ; Thu, 25 Jun 2015 04:28:29 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA7A1A1B18 for ; Thu, 25 Jun 2015 04:28:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5PBSQe1012521; Thu, 25 Jun 2015 13:28:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 424BF203202; Thu, 25 Jun 2015 13:31:23 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 307FF203201; Thu, 25 Jun 2015 13:31:23 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5PBSMeW008831; Thu, 25 Jun 2015 13:28:26 +0200 Message-ID: <558BE5D7.7080108@gmail.com> Date: Thu, 25 Jun 2015 13:28:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Gert Doering References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@gmail.com> <558BCFEA.8000009@gmail.com> <20150625110213.GB67883@Space.Net> In-Reply-To: <20150625110213.GB67883@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 11:28:30 -0000 Le 25/06/2015 13:02, Gert Doering a écrit : > Hi, > > On Thu, Jun 25, 2015 at 11:54:50AM +0200, Alexandru Petrescu wrote: >> This makes either the specs irrelevant or the products on the >> market non-conformant. > > Good morning. So you finally start seeing the light. > > 3G mandated(!) IPv6 over 10 years ago. Conclusions left as homework > for the interested reader. The interested reader should look at the evolution too. When IPv6/3gpp was mandated there was no operator offering IPv6 - the only method to have IPv6 on a cellular link was to tunnel through IPv4. Then came one or two operators in northern Europe proposing IPv6 for trials on cellular. Today there are several cellular operators offering native IPv6 to the public, and some trials. Some even propose IPv6-only (i.e. no IPv4). But IPv6 is a large replacement. DHCPv6-PD is just a simple upgrade to DHCPv6-for-addresses. That's why I think it would be less than 2 years before we see DHCPv6-PD at the cellular operator. Alex > > Gert Doering -- NetMaster > From nobody Thu Jun 25 06:04:56 2015 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 93ACB1A8756; Thu, 25 Jun 2015 06:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MyPXDuoLauYR; Thu, 25 Jun 2015 06:04:50 -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 5404B1A6FE7; Thu, 25 Jun 2015 06:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2615; q=dns/txt; s=iport; t=1435237490; x=1436447090; h=from:to:subject:date:message-id:mime-version; bh=LWkTWKV3AM+ro/i0rKZ9J0d4byirDuxgqHN/r52UgtU=; b=UbPwwiUesmOpRPxI57dluev2OzBx/qsNr5A1Ml1NeN0SThpQe5rsVSXY Zt9XFlas7yqjFJlvLEs+a7gfJ5iEZH7wgMzN59vN6mttVhNN2GnsNdMPR pPo/fewXg7WKvZJYJvVgo3w7nc/7XUMh8okN95821PF+k1N8ynFrVe1JE E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C4AwAr+4tV/4UNJK1bgxFUZb0MCYFmhzk4FAEBAQEBAQGBCoQpgQsBgQAnBAEgiCENzhQBAQEBAQEBAQIBAQEBAQEBAQEVBJNugRQFlAUBgiOBUIddmDgmg3qCNYECAQEB X-IronPort-AV: E=Sophos;i="5.13,677,1427760000"; d="asc'?scan'208";a="162730406" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP; 25 Jun 2015 13:04:49 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5PD4ngS018022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 13:04:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 08:04:49 -0500 From: "Fred Baker (fred)" To: "sunset4@ietf.org" , v6ops list Thread-Topic: Joint meeting of sunset4 and v6ops Thread-Index: AQHQr0eE1uVq+d5bDkODMombi+a8Sg== Date: Thu, 25 Jun 2015 13:04:49 +0000 Message-ID: <8ECE38A2-71FE-4C33-A573-BBF5DFAB1CD9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.244.209] Content-Type: multipart/signed; boundary="Apple-Mail=_72FD86AA-85FD-49B2-8A48-DBB3B4E2E8B1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Joint meeting of sunset4 and v6ops 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, 25 Jun 2015 13:04:54 -0000 --Apple-Mail=_72FD86AA-85FD-49B2-8A48-DBB3B4E2E8B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The chairs of sunset4 and v6ops have been discussing our work plans, and = feel it would be useful to meet jointly at IETF 93. I have just posted a = preliminary agenda, for working group comment, at = https://www.ietf.org/proceedings/93/agenda/agenda-93-v6ops. That agenda basically breaks two 2-hour slots into four one-hour slots. = One such slot will be used by each working group to discuss documents = currently on the table, which are a total of five documents - two in = sunset4 and three in v6ops. We would like to invite two or three = European ISPs to discuss their IPv6 deployments (which we have not lined = up - any volunteers?), and we would like to spend an hour on charter = discussions. At this point, neither v6ops nor sunset4 have new drafts. I am expecting = a respin of draft-ietf-v6ops-siit-dc and draft-ietf-v6ops-siit-dc-2xlat, = which we should finalize at this meeting, and I am expecting a respin of = draft-ietf-v6ops-ipv6-ehs-in-real-world responding to the "next steps" = thread of May 6-7. If new drafts come in for v6ops, we will likely = either find a way for a different working group to look at them (one = draft I have heard proposed probably belongs in 6man), discuss them if = we have time, or discuss on-list for the present. --Apple-Mail=_72FD86AA-85FD-49B2-8A48-DBB3B4E2E8B1 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 iQIVAwUBVYv8b0ayAOS/EQ8MAQIkVQ/6A3Dxvle9tI/qN/s/o8P8DZZ0ylT6MpLu neF2hNxDbItVvnzghXJp8LFVWfK6mv6HyrMxKJ+S95+jc3RtXWkfMFEFknzKjD+7 iZ45ZFQjGMuzwO/sVONvEK9vIuvP7eYyYFgk+4RpGXegxg2pUlDorUSzqbULrUof Y23a1m5OUtHo8lwRmdGF/hyui/Hn8REYXDzzKYZv1JaWYrppzyQHQt801RusfECP vNw6krKcD8TQnrtrQ1NUGkQGrkWwVCtoSoQ+1KyxP8hmRp6RuO1sb8Tcemf8vbRW 3DPb2EpKSbYqnaS0+jC+iH1op51wyma+Wq3FXbZv5DOrY6lJiLRFt+9ApWyrA67S iWJtvgC8aRO2gtYBOH0GYGDDwE+ZRe/SpYSkx9JxwqepZQ29tXmXu6UDJZRSlWuL 8DC6Ra0XtWmyh007q3t86CR891tg8LHyY+yhx/zAmyX22gTt4rFyoPgRNHGF1K0C vey8I0VBTg31WC0hGq1r9swp2prO6M4TbV6NTn44sQhIdhT3o8fVKCixYijqDXU3 l8m3BHrMBEUkOIeWbzI5Yf7ZEUjKxgj9qD7MW7w+D7xQGtp20xDc5L1SXsgP4fRY YEz7EUkAXTFy9VuY2fDw7X0f/fwuA+U3GDmyT4bhF3XZT7LE1tLM8oFX4Hwulaq+ C4qNG53Yw4w= =pZsw -----END PGP SIGNATURE----- --Apple-Mail=_72FD86AA-85FD-49B2-8A48-DBB3B4E2E8B1-- From nobody Thu Jun 25 09:59:17 2015 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 BEA1E1A916B for ; Thu, 25 Jun 2015 09:59:15 -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 CelPAaEAwsbQ for ; Thu, 25 Jun 2015 09:59:14 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B92C1A9145 for ; Thu, 25 Jun 2015 09:59:14 -0700 (PDT) Received: by pactm7 with SMTP id tm7so52910572pac.2 for ; Thu, 25 Jun 2015 09:59:13 -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=fEpGphUaIomJ6KatuGxjZyoO3KabfD1lpsEe8Qnx+PQ=; b=P5U6NeMemnjzFWLevDDhiCEqNzmzotoPbRu+Je9IxeAYoYBSPJz+7oEdW7t/Bc2egG Vnyp/pU02E2jROECNL/laNjuSkuDyGs9xle+aa8mY+dG5dOqmmHsXAegOeRfnCVt31tG 42I2ugFTjwfK2tiSdjCffo7ABeiak7gtBoDopzF4JDtmC30YlnorJrrf/a/chwrkm1wa 7M9Esu9gZNI3znoZJ5IW4hiAaK4MXrWejrapVoxy+X6FDsGORIRgFB2Mqezx8QF5sWau PVTWnw0JGLRVRqkEBLj6I2vMvsrrOzIRISP3Sw+df0hF1463NaksOpGBAoe4+WxJrgSP kTsw== X-Received: by 10.69.26.4 with SMTP id iu4mr1590458pbd.140.1435251553768; Thu, 25 Jun 2015 09:59:13 -0700 (PDT) Received: from [10.16.11.88] ([216.31.219.19]) by mx.google.com with ESMTPSA id pj4sm30588373pbb.29.2015.06.25.09.59.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 09:59:13 -0700 (PDT) Message-ID: <558C3360.3000806@gmail.com> Date: Thu, 25 Jun 2015 09:59:12 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Alexandru Petrescu References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 16:59:15 -0000 6/25/2015, 2:28 AM, Mikael Abrahamsson kirjoitti: > On Thu, 25 Jun 2015, Alexandru Petrescu wrote: > >> After reading Mikael's email pointing to a 3gpp spec of late 2014 >> mandating DHCPv6-PD to both UE and core network - I must say I am >> optimistic about the arrival of DHCPv6-PD to cellular network operators. >> >> Currently, some cellular networks already offer DHCPv6 together with >> SLAAC. Technically that DHCPv6 is extremely simple to upgrade to >> DHCPv6-PD. >> >> My question is when? >> >> I can speculate it will be in late 2016. Because 4G was in specs 2 >> years before trial deployments. > > To repeat myself: > > DHCPv6-PD requirement didn't appear in 2014. > > http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts_123401v100300p.pdf > from 2011-MARCH contains prefix delegation, and since it's not available > in release 9, it seems this is indeed a LTE release 10 feature that is > more than 4 years old, and still there isn't widespread implementation > of it that I am aware of. Yes, we put PD into Rel-10 around mid/late 2010. The CRs to 23.060 and 23.401 that then added prefix exclusion (RFC6603) were in Nov 2010. - Jouni > From nobody Thu Jun 25 10:35:08 2015 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 37D881A0199 for ; Thu, 25 Jun 2015 10:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 kBMP47y2MVRo for ; Thu, 25 Jun 2015 10:35:05 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA2A1A00E7 for ; Thu, 25 Jun 2015 10:35:04 -0700 (PDT) Received: by igin14 with SMTP id n14so60495421igi.1 for ; Thu, 25 Jun 2015 10:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ik7Tsy14dinQguoWrITEemHB1VVndz4P6fAVR/joQk=; b=V0OyB0yZscZTm81OuUE0S4B0aDpsvcgHbh4d7HtqOVtpAnL1LW87Nn91ZlPhPLHO9K vbV97fzCM6nGRNc6JMLctafAVbG+gLjUjgMP/c6v3Wd/zAco4aJ7Zyc2zaCytBuJwfii Ytk0HMW6fZFzmylIDDWpF97spZC+AxywIbhxw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/ik7Tsy14dinQguoWrITEemHB1VVndz4P6fAVR/joQk=; b=gESszp9k2UCfFK/3bhjaZ5hCKI9WKkK1JprdQX7MePHcivR1DDGv0/0krrsl5LYiBG zbe09/0r0b9/DJa+oZfAJMQlPie615dmvtmWnppyxpIH9W2+JnjKot8AdCmhrqB0VHms LWVt+InEnLV+dkZrJ6x87su55xLgwpXrvRKmff4EZzjJikpUvJg2rqyKZTT8vtG9o98q LegDKYEVqz1SWSXcIa8R7a007e4GmYt/7cRHVCQZEy0dXro9JSaGIgKANgUOzAe0vNBg tciBWUJVgGwpFwalWdV+N61fd+DCqu75cz5KCk34X16k9DZnM2qZgF+wBrj7w++9MJ2T qzyw== X-Gm-Message-State: ALoCoQkIEiGl97iT998zYs5wZJG1nP7otqIV8reyaH849yPHdQPWEjh7KCYyKSzLSKQbvlO0Kzxu X-Received: by 10.107.168.150 with SMTP id e22mr57383590ioj.9.1435253704381; Thu, 25 Jun 2015 10:35:04 -0700 (PDT) Received: from ?IPv6:2620:15c:1:101:9c44:bd2a:733f:2561? ([2620:15c:1:101:9c44:bd2a:733f:2561]) by mx.google.com with ESMTPSA id x83sm283190ioi.6.2015.06.25.10.35.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jun 2015 10:35:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: james woodyatt In-Reply-To: Date: Thu, 25 Jun 2015 10:35:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <272BEF29-C175-4889-8119-8544084E9C1F@nestlabs.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 25 Jun 2015 17:35:06 -0000 On Jun 24, 2015, at 19:59, Mikael Abrahamsson wrote: >=20 > I don't know what you mean by "provisioning profile", but my wifes = unlocked iPhone6+ received an update to her carrier profile with iOS 8.3 = and it used the IPv4v6 APN just fine without any kind of user = intervention. Yes, I forgot. The carrier profile can do this too. Either way, there = isn=E2=80=99t a way for an ordinary user with an unlocked phone to pick = the APN type on whatever service they are using. Apple and the carrier = must conspire to make IPv6 happen automatically or it doesn=E2=80=99t = happen. Because Core Telephony. Grumble grumble grumble. =E2=80=94james= From nobody Thu Jun 25 10:45:09 2015 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 870621A6EF2 for ; Thu, 25 Jun 2015 10:45: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, 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 63Euv-j_NURs for ; Thu, 25 Jun 2015 10:45:04 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387711A0011 for ; Thu, 25 Jun 2015 10:45:04 -0700 (PDT) Received: by iebrt9 with SMTP id rt9so59609948ieb.2 for ; Thu, 25 Jun 2015 10:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HPMh8U36HKjr8Tlhqhw/XpoRd+sd2AsNuwQUqDJWDIs=; b=TiRThd9To7yJFhY9a/aoQpXUZ47WNEmS0BDF14KvQlb90LVAornhODoygN9Q8NIDZv +f3/nMkAn7MwZ0D/Y3SOtnXaEs4TrLK8/ccyNkS1kUmEVP2nPeiuRG1KEX9k6pKDeUeF wkwsdcifKwPLkNjZi38jG/ui6KxoO2E+mTaIw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=HPMh8U36HKjr8Tlhqhw/XpoRd+sd2AsNuwQUqDJWDIs=; b=mMEfYe5kBt2wuAd9kMUFEgnC72pgypvii+XxqY6hQlKxnKtaI5hfMDsKIitCAvppwR 9Zj4F1hMVlLQCfOm4j5GYublDT3F8sj2HFSDDXeZJGxrpcBeIX+8Qz1j9eUnTHGDBB5J i13r7eBmfnxqeBImzpEg6/v8xyoPaQfnU/QXQXUHLahPM9uBalJ1Z4rq1K+SORsCuH9I wkSfwfxkg5aL8sroF8qS+7tDdvgcf396MwjJSxC5JQYcw2Dku2Ghj+eaA3x59P3zSLNU Z3ptaeI6ueRK29wcV/CVa99hjWh6nxQW8DMyxzQqLqZOQse7d5qtQHY8vYL8Mt9sFVKr 999g== X-Gm-Message-State: ALoCoQnWsKBEZPLROCaGoroEwg9Pmq5aWX0Hz4yBEiM7dX7B/sufFtByggIrE8nfAkGvCCysckjR X-Received: by 10.107.26.207 with SMTP id a198mr61080726ioa.5.1435254303683; Thu, 25 Jun 2015 10:45:03 -0700 (PDT) Received: from dhcp-100-100-99-154.pao.corp.google.com ([100.100.99.154]) by mx.google.com with ESMTPSA id qh9sm3744769igb.20.2015.06.25.10.45.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jun 2015 10:45:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_28F6EE26-6307-4D43-BEE5-8117CEFA56F5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: james woodyatt In-Reply-To: <558BC6A3.8030700@gmail.com> Date: Thu, 25 Jun 2015 10:45:01 -0700 Message-Id: References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <558BC6A3.8030700@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 17:45:06 -0000 --Apple-Mail=_28F6EE26-6307-4D43-BEE5-8117CEFA56F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 25, 2015, at 02:15, Alexandru Petrescu = wrote: >=20 > That's why the CarRouters are pure routers and dont do NDproxy. > And that's why CarRouters need the smartphones to provide them DHCPv6 = Prefix Delegation in return. Hierarchical prefix delegation. (Again. What a great idea. Face palm.) I = think what Mr. Petrescu meant to say is that CarRouters need smartphones = to offer HNCP services. Who will be brave enough to set that standard? =97james here= --Apple-Mail=_28F6EE26-6307-4D43-BEE5-8117CEFA56F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Jun 25, 2015, at 02:15, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

That's why the CarRouters = are pure routers and dont do NDproxy.
And that's why CarRouters need the smartphones = to provide them DHCPv6 Prefix Delegation in = return.

Hierarchical = prefix delegation. (Again. What a great idea. Face palm.) I think what = Mr. Petrescu meant to say is that CarRouters need smartphones to offer = HNCP services. Who will be brave enough to set that = standard?


=97james here
= --Apple-Mail=_28F6EE26-6307-4D43-BEE5-8117CEFA56F5-- From nobody Thu Jun 25 11:31:03 2015 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 39AA01A8765 for ; Thu, 25 Jun 2015 11:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 PV_rBk9d3niK for ; Thu, 25 Jun 2015 11:31:00 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 45B021A875D for ; Thu, 25 Jun 2015 11:30:59 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C8E8362ED7 for ; Thu, 25 Jun 2015 20:30:57 +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 82F2E608A5 for ; Thu, 25 Jun 2015 20:30:57 +0200 (CEST) Received: (qmail 5430 invoked by uid 1007); 25 Jun 2015 20:30:57 +0200 Date: Thu, 25 Jun 2015 20:30:57 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150625183057.GG67883@Space.Net> References: <20150624151015.GN67883@Space.Net> <558ACC2F.7060509@gmail.com> <20150624161858.GP67883@Space.Net> <20150624234129.47252313E1E5@rock.dv.isc.org> <20150625071335.GQ67883@Space.Net> <558BC2FB.3020801@gmail.com> <558BCFEA.8000009@gmail.com> <20150625110213.GB67883@Space.Net> <558BE5D7.7080108@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GMAK4tsM7WHnyxbM" Content-Disposition: inline In-Reply-To: <558BE5D7.7080108@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 18:31:02 -0000 --GMAK4tsM7WHnyxbM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jun 25, 2015 at 01:28:23PM +0200, Alexandru Petrescu wrote: > > 3G mandated(!) IPv6 over 10 years ago. Conclusions left as homework > > for the interested reader. >=20 > The interested reader should look at the evolution too. When IPv6/3gpp > was mandated there was no operator offering IPv6 - the only method to > have IPv6 on a cellular link was to tunnel through IPv4. =20 Of course there was no operator before it was mandated in the standard -=20 didn't stop the operators from still not offering *when* it was. (As for upstream connectivity: ISPs were offering commercial IPv6 service 15 years ago already - not all of them, but if you *wanted*, you could get it. So that's all a very lame excuse to just ignoring the mandatory bit of the standard for 10+ years) 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 --GMAK4tsM7WHnyxbM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVYxI4d9WwGXkzn/FAQIGjw//bVcXd/IGrK1cIopDc88A8ufQGWw0iRKc 2GwqIG91dvEd9h4C6MdCcvhFFNSCnXdGdJblXJgZ2WsfMaM7n0Lfd5ElcVxyUbgt H/fwYbQTMuxbIyHXtacDqs2MgyDYSZRu0wSWBRYwTO+Zhgao9NX+uH4iCMnaorsJ LhqHOsINv+3LCelkQpbRY2w4ChEfUHjqw2bcolzhx2d7qlFXmcvB3SXVomAz2NZq azmwc+hLabUGEzH2g22Ho/pVI51DMfr78F9SAddG7chzOffCQFTTrX/xbwbNh948 tOM0b5uY7AoJww7Cqj3WIZHZbbIFjBBk+67qZlb4uZsJUOLqTwuxqzFbZAOhnKhk V4oAR648+RaS5Zl3u9ezZz8bDaxtLJcs7ovctefxANjrFk0GRL5GC4J5pojqdvDn gCnktQRGfEN3UK05P6XwDnAoXjW7/gJIynLSzWM4ClBAztieawhFasIiO5deV+In TFOKacLdizuO2YXyrEm2gKGtDuitMvHzP2whkRBIV4Noc5i1EeqSYtPT4kwvi+r3 aOc21KWbD0oNpumk5jwXUVXVatMag7rhpiGWzIM0l1jPQoesJPZW7na8gBx4SXyU vMWSUuCFkyqgChfceIJhPvRcJirCvuq6kn0R9UVDNOwCwlhU6KyWHnN6ANfCvLMG GTWFi00k7QQ= =mGwo -----END PGP SIGNATURE----- --GMAK4tsM7WHnyxbM-- From nobody Thu Jun 25 11:45:08 2015 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 A073E1A8AE4 for ; Thu, 25 Jun 2015 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VpW-4rHuZO9D for ; Thu, 25 Jun 2015 11:45:06 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D1EF71A8AC9 for ; Thu, 25 Jun 2015 11:45:05 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 629195407E5; Thu, 25 Jun 2015 14:45:04 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Jared Mauch In-Reply-To: Date: Thu, 25 Jun 2015 14:45:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <272BEF29-C175-4889-8119-8544084E9C1F@nestlabs.com> To: james woodyatt X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 25 Jun 2015 18:45:07 -0000 > On Jun 25, 2015, at 1:35 PM, james woodyatt wrote: >=20 > Yes, I forgot. The carrier profile can do this too. Either way, there = isn=E2=80=99t a way for an ordinary user with an unlocked phone to pick = the APN type on whatever service they are using. Apple and the carrier = must conspire to make IPv6 happen automatically or it doesn=E2=80=99t = happen. Because Core Telephony. Grumble grumble grumble. Yes, this is something I saw with Verizon and my iPad, I was getting = IPv6 then some carrier update made it go away and it=E2=80=99s not come = back since. I just got a USA T-Mobile SIM and it does IPv6 properly in a $30 GSM/LTE = <-> WIFI and I can get v6 on any device connected. Quite a stark difference in =E2=80=9Cdoes it right=E2=80=9D vs =E2=80=9Cdo= es it wrong=E2=80=9D. I periodically have issues with comcast changing my prefix and hosts not = picking them up right, but that=E2=80=99s a bit harder to trace as it = happens so infrequently. - jared= From nobody Thu Jun 25 12:02:55 2015 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 8B3BC1ACC92 for ; Thu, 25 Jun 2015 12:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 it4aGSuRxIgB for ; Thu, 25 Jun 2015 12:02:52 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 7DF6B1ACD15 for ; Thu, 25 Jun 2015 12:01:52 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8BC7D608A5 for ; Thu, 25 Jun 2015 21:01:49 +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 481A460798 for ; Thu, 25 Jun 2015 21:01:49 +0200 (CEST) Received: (qmail 6764 invoked by uid 1007); 25 Jun 2015 21:01:49 +0200 Date: Thu, 25 Jun 2015 21:01:49 +0200 From: Gert Doering To: Jared Mauch Message-ID: <20150625190149.GI67883@Space.Net> References: <1068D9DB-4300-473F-B511-880C1E9FB73D@muada.com> <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <272BEF29-C175-4889-8119-8544084E9C1F@nestlabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 25 Jun 2015 19:02:54 -0000 Hi, On Thu, Jun 25, 2015 at 02:45:10PM -0400, Jared Mauch wrote: > I just got a USA T-Mobile SIM and it does IPv6 properly in a $30 GSM/LTE <-> WIFI and I can get v6 on any device connected. What device are you using for this? "Mobile 3G/Wifi router thingies" that support IPv6 are not exactly easy to find on the market, let alone "properly!"... (Have a TP-Link M5350 here which is a very very nice 3G/Wifi thingie, but alas, no v6 and no plans to ever support it "because nobody is using IPv6 on 3G" - yes, that's why, thanksverymuch) gert -- 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 Thu Jun 25 12:09:46 2015 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 80F421ACD09 for ; Thu, 25 Jun 2015 12:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BqZWx5nqihBD for ; Thu, 25 Jun 2015 12:09:44 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 844161ACCD8 for ; Thu, 25 Jun 2015 12:09:44 -0700 (PDT) Received: from delong-dhcp203.delong.com (delong-dhcp3 [192.159.10.203]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t5PJ8EwH010114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Jun 2015 12:09:41 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <558BC5AF.3060406@gmail.com> Date: Thu, 25 Jun 2015 12:08:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 19:09:45 -0000 > On Jun 25, 2015, at 02:11 , Alexandru Petrescu = wrote: >=20 >=20 >=20 > Le 24/06/2015 20:38, james woodyatt a =E9crit : >> On Jun 24, 2015, at 07:12, Alexandru Petrescu >> > >> wrote: >>>=20 >>> [=85] In the car use-case the smartphone connects to the dashboard >>> using a ptp link. And it's the car's dashboard which offers a >>> WiFi hotspot. These couldn't be bridged (ND proxy) by the >>> smartphone alone, it would need the dashboard router to participate >>> in this ND proxy. [=85] >>=20 >> I suspect the point you may be missing here is the logic encoded >> elsewhere in iOS that restricts the use of Mobile Internet Sharing >> to the telephony uplink. It is not possible with iOS to share >> Internet access over the Wi-fi (or other interfaces) with tethered >> devices. Only the telephony data service is eligible for Mobile >> Internet Sharing. >=20 > That is a good point. >=20 > There is an ongoing technical debate in the car comm community - = should > the smartphone provide Internet connectivity to the car? Or should = the > smartphone use the Internet connectivity offered by the car. The car community should not be making this decision. The car _AND_ the smartphone should be delivered in such a way that the end user can choose whichever plan best suits his needs and offers him = the best set of tradeoffs between features, price, and whatever else the end = user chooses to care about. If I want the phone to provide the connectivity to the car, I should be = able to do that. If I want the car to provide connectivity and have the phone use that, I = should be able to do that. I should be able to choose and I should be able to change my decision = whenever it suits me. >=20 > Right now where I live a large number of marketed cars are on the = first > option. It is on that option that I think smartphone's iOS Mobile > Internet Sharing can help, provided it does more than NDproxy. For most of the marketed cars I am aware of in the US where that is the case, it is largely because the car doesn=92t really know what a network = is in any meaningful way, or, because the car maker didn=92t want to think = about solving the connectivity problem in a useful way. I do not know of a case where it is a well thought out decision by the manufacturer to have that as a deliberate architecture rather than just laziness at best. Owen From nobody Thu Jun 25 12:14:32 2015 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 31D691A1BFF for ; Thu, 25 Jun 2015 12:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 4TmS7t8sshCB for ; Thu, 25 Jun 2015 12:14:30 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 2E6AF1ACCE9 for ; Thu, 25 Jun 2015 12:14:30 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CB9BC62ED6 for ; Thu, 25 Jun 2015 21:14: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 86D9660152 for ; Thu, 25 Jun 2015 21:14:28 +0200 (CEST) Received: (qmail 7132 invoked by uid 1007); 25 Jun 2015 21:14:28 +0200 Date: Thu, 25 Jun 2015 21:14:28 +0200 From: Gert Doering To: Owen DeLong Message-ID: <20150625191428.GJ67883@Space.Net> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 19:14:31 -0000 Hi, On Thu, Jun 25, 2015 at 12:08:14PM -0700, Owen DeLong wrote: > If I want the phone to provide the connectivity to the car, I should be able > to do that. > > If I want the car to provide connectivity and have the phone use that, I should > be able to do that. > > I should be able to choose and I should be able to change my decision whenever > it suits me. No. For *you* this might make sense and be a useful feature. For me, I might like it, but will never actually use it (because I'm way too lazy to be interested in multiple possible Internet uplinks for my car - and why I should bother to trade the nice *external* antenna of the car with the great reception of a typical smartphone inside a large moving metal box). For the typical driver who is already challenged pairing his mobile via BT with his car's handsfree? No go. Do one thing, do it well, and NEVER ask a car owner (or any normal Internet user) about technical decisions. 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 Thu Jun 25 12:24:54 2015 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 F37B21ACCFC for ; Thu, 25 Jun 2015 12:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 bn7Hv0XknmoY for ; Thu, 25 Jun 2015 12:24:51 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6791ACD03 for ; Thu, 25 Jun 2015 12:24:50 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t5PJOmb4010471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Jun 2015 12:24:48 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <20150625191428.GJ67883@Space.Net> Date: Thu, 25 Jun 2015 12:24:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> <20150625191428.GJ67883@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 25 Jun 2015 19:24:52 -0000 > For the typical driver who is already challenged pairing his mobile = via > BT with his car's handsfree? No go. Do one thing, do it well, and = NEVER > ask a car owner (or any normal Internet user) about technical = decisions. We can agree to disagree. IMHO, this should be as simple as two = settings. One on the phone: Provide Internet Access to Car: ON/OFF One in the car: Get internet access from: CAR <-> PHONE As to the typical driver being challenged pairing his mobile, frankly, = I=E2=80=99m challenged with that on many occasions, not because I don=E2=80=99t know how to do = it and not because I don=E2=80=99t understand what is involved or can=E2=80=99t follow = directions, but because BlueTooth pairing implementation on most cars and most devices is a steaming pile = of poorly written and even less well tested code that is fragile, buggy, and = unreliable. Assuming that the underlying connectivity code works, the above two = settings should not be difficult to implement correctly. They are far less = complex than Bluetooth. Owen From nobody Thu Jun 25 12:55:10 2015 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 4824C1ACDE2 for ; Thu, 25 Jun 2015 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8cET7Sp-G3rw for ; Thu, 25 Jun 2015 12:55:07 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id C94361ACDD6 for ; Thu, 25 Jun 2015 12:55:07 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 79FC85408A0; Thu, 25 Jun 2015 15:55:07 -0400 (EDT) Date: Thu, 25 Jun 2015 15:55:07 -0400 From: Jared Mauch To: Gert Doering Message-ID: <20150625195507.GA10976@puck.nether.net> References: <78ABF014-6E93-40B8-8ABC-5BAF8AF96A47@nestlabs.com> <27D48517-5882-4E0A-9288-814D07C607C0@muada.com> <9AFFDD3E-4D15-45CC-A80A-C87A671F0D2E@nestlabs.com> <272BEF29-C175-4889-8119-8544084E9C1F@nestlabs.com> <20150625190149.GI67883@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150625190149.GI67883@Space.Net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 25 Jun 2015 19:55:09 -0000 On Thu, Jun 25, 2015 at 09:01:49PM +0200, Gert Doering wrote: > Hi, > > On Thu, Jun 25, 2015 at 02:45:10PM -0400, Jared Mauch wrote: > > I just got a USA T-Mobile SIM and it does IPv6 properly in a $30 GSM/LTE <-> WIFI and I can get v6 on any device connected. > > What device are you using for this? "Mobile 3G/Wifi router thingies" > that support IPv6 are not exactly easy to find on the market, let alone > "properly!"... > > (Have a TP-Link M5350 here which is a very very nice 3G/Wifi thingie, > but alas, no v6 and no plans to ever support it "because nobody is using > IPv6 on 3G" - yes, that's why, thanksverymuch) Ok since more than one person asked me: ZTE MF96 4G LTE Wireless Mobile Hotspot Router Sonic http://www.ebay.com/itm/ZTE-MF96-4G-LTE-Wireless-Mobile-Hotspot-Router-Sonic-2-0-WiFi-T-Mobile-USB/181704373447 with this sim card: https://www.sparkfun.com/products/13186 The one I received had an OTA software update available and I applied it. Don't know if that was required to make it work for v6 but being an avid software beta tester, i always update firmware. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Thu Jun 25 23:48:09 2015 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 6016C1B2FC7 for ; Thu, 25 Jun 2015 23:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.202 X-Spam-Level: *** X-Spam-Status: No, score=3.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, HTML_MESSAGE=0.001, 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 F-1I_gy2fNnx for ; Thu, 25 Jun 2015 23:48:03 -0700 (PDT) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F7F1B2FC6 for ; Thu, 25 Jun 2015 23:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1435301282; bh=ZpYby8N6G4HjKh+jeSwVyYe4xA+29fa68i1r5h+5p8A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=a3p5cBNhw+b7F2Ko7aFoulAP3k1QnyZkE6usILfGxZKJOsAS1HCsExO+xC/pUNCQ+y1Bke0/70bizUiYt228ljJOvDNGZgrkys9WD/VXDX/q42t5czyogJYPFu3B7tFtxtoVuck/kocgiWFXxFjI3YeLYlJMnk3UzrzglJFXAAurStpyXcJaEuPZ7B+wCAEH5KDp2vnOEjMXkJZKTZVCTYotQR+b60LTt4uR7fPiNVUqPgnpZxlMDB0SKICrlkOqBKiRWstmbaCCu6aNdbsIKRSYbiAK0nAS5F1mfVaqAoh5yabHPEZfMXy2/FoYG7To9VSHcMa0rxCgUyKIOiaK7g== Received: from [66.196.81.173] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2015 06:48:02 -0000 Received: from [98.139.212.232] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2015 06:48:02 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 26 Jun 2015 06:48:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 775765.60774.bm@omp1041.mail.bf1.yahoo.com X-YMail-OSG: BkP2R0gVM1kC3oMqndnD9pfWS4VgV3sbahNUUNm6MOjQ80mEdU7YCM6Zae9CnjP fstj8vvL3ssT.diSNZCEQnz69pEum4ZD_Ax0O9LmmRNdFjlAdMKld8ZfzDRSaIO1VGXqyRVsHTBc DPEaaa7eVQxJNymyQxvwu5N4CbvHyLvjDC5.C5B.sDFZSCiymbIAH8XTpOJP7d.pRzN.OCJA9Aaf ejAbfcTTPKbk_jOisKmMQDPSpyUxSh2p9dY8psbAJuQxEor6Zfa.EsacAOJghhfvJMR36Ld_LRrL PlBZqiZX0h1c1SMVOylFST652DoReXlEYpm49RPH41YnFHJ2jK4SI2at8bX7pgfwY7BbYFtgM7gs CVTkEdPXimgV8LkC7VOwg1GXa8kypsm97.bWfgSckgY7SzAqkRe6.4AzmMHNYFk7Wtg0jlZM4e2a WibIc1nBRjgfuJpWc57d679RXhVmKhPa70fkXkFC.7TyKhrsALUqtqnnV8G7t1YuJhSog8jntnkN PYSCDteM2bwrcf7qlb1TlZQxgOw1WxtGiWkz797IpQqXcVI7gmw-- Received: by 76.13.27.196; Fri, 26 Jun 2015 06:48:02 +0000 Date: Fri, 26 Jun 2015 06:48:01 +0000 (UTC) From: Mark ZZZ Smith To: Owen DeLong , Gert Doering Message-ID: <2031204131.175399.1435301281824.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_175398_289016600.1435301281821" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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: Fri, 26 Jun 2015 06:48:07 -0000 ------=_Part_175398_289016600.1435301281821 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Owen DeLong To: Gert Doering =20 Cc: v6ops@ietf.org=20 Sent: Friday, 26 June 2015, 5:24 Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for b= ridging hotspots =20 > For the typical driver who is already challenged pairing his mobile via > BT with his car's handsfree?=C2=A0 No go.=C2=A0 Do one thing, do it well,= and NEVER > ask a car owner (or any normal Internet user) about technical decisions. We can agree to disagree. IMHO, this should be as simple as two settings. One on the phone: Provide Internet Access to Car: ON/OFF One in the car: Get internet access from: CAR <-> PHONE As to the typical driver being challenged pairing his mobile, frankly, I=E2= =80=99m challenged with that on many occasions, not because I don=E2=80=99t know how to do it = and not because I don=E2=80=99t understand what is involved or can=E2=80=99t follow directi= ons, but because BlueTooth pairing implementation on most cars and most devices is a steaming pile of = poorly written and even less well tested code that is fragile, buggy, and unreliab= le. Assuming that the underlying connectivity code works, the above two setting= s should not be difficult to implement correctly. They are far less complex t= han Bluetooth. / I think another thing to remember is that "enablement" can imply a defaul= t. For example, if my car comes with a SIM slot, and I choose to put one on= in it, then I've implicitly chosen that the car should by default use the = connectivity provided by its own 3/4G connectivity. I'm also have likely to= have chosen the particular SIM and its associated usage plan based on my e= xpected usage of the Internet by and possibly in the car. If the car also h= as a Wifi hotspot in it, I'll likely associate my phone with it once, so th= at from then on my phone will automatically use the car's connectivity ever= y time I get in it, without any intervention on my part at all. That would = be much more convenient than having to switch on and off hotspot support on= my phone each and every time I get in the car - and it is likely people wi= ll sometimes forget, and then try to do that while they're driving, which w= ill be as or more dangerous than sending text messages while driving. / Having choice can be good, but you want to try to minimise both the amoun= t of choices and how often people have to make them - too much choice can l= ead to paralysis, such that making no choice becomes the safest "choice". = =C2=A0I think when it comes to usability, predictable and expected defaults= , and matching peoples' existing conceptual and mental models are much bett= er. The book "The Design of Every Day Things" is an excellent book on makin= g things easier to use. / Regards,/ Mark. =C2=A0 Owen _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_175398_289016600.1435301281821 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From: Owen DeLong = <owen@delong.com>
To: Gert Doering <gert@space.net>
Cc: v6ops@ietf.org
Sent: Friday, 26 June 2015, 5:24
Subject: Re: [v6ops] Apple and IPv6, a few cla= rifications - ND proxy for bridging hotspots


> For the typical driver who is already challenged pairing his= mobile via
> BT with his car's handsfree?  No go= .  Do one thing, do it well, and NEVER
> ask a ca= r owner (or any normal Internet user) about technical decisions.

We can agree to disagree. IMHO, this should be= as simple as two settings.

One on the= phone: Provide Internet Access to Car: ON/OFF

One in the car: Get internet access from: CAR <-> PHONE
=

As to the typical driver being challenged pairing hi= s mobile, frankly, I=E2=80=99m challenged
with that on ma= ny occasions, not because I don=E2=80=99t know how to do it and not because=
I don=E2=80=99t understand what is involved or can=E2=80= =99t follow directions, but because BlueTooth
pairing imp= lementation on most cars and most devices is a steaming pile of poorly
written and even less well tested code that is fragile, buggy= , and unreliable.

Assuming that the un= derlying connectivity code works, the above two settings
= should not be difficult to implement correctly. They are far less complex t= han
Bluetooth.


=

/ I think another thing to remember is that "enablement" can imply a def= ault. For example, if my car comes with a SIM slot, and I choose to put one= on in it, then I've implicitly chosen that the car should by default use t= he connectivity provided by its own 3/4G connectivity. I'm also have likely= to have chosen the particular SIM and its associated usage plan based on m= y expected usage of the Internet by and possibly in the car. If the car als= o has a Wifi hotspot in it, I'll likely associate my phone with it once, so= that from then on my phone will automatically use the car's connectivity e= very time I get in it, without any intervention on my part at all. That wou= ld be much more convenient than having to switch on and off hotspot support= on my phone each and every time I get in the car - and it is likely people= will sometimes forget, and then try to do that while they're driving, whic= h will be as or more dangerous than sending text messages while driving.

/ Having choice can= be good, but you want to try to minimise both the amount of choices and ho= w often people have to make them - too much choice can lead to paralysis, s= uch that making no choice becomes the safest "choice".  I think when i= t comes to usability, predictable and expected defaults, and matching peopl= es' existing conceptual and mental models are much better. The book "The De= sign of Every Day Things" is an excellent book on making things easier to u= se.

/ Regards,
/ Mark.
=

 


Owe= n

____________________________________= ___________
v6ops mailing list
= v6ops@ietf.org
https://www.ietf.org/mai= lman/listinfo/v6ops


------=_Part_175398_289016600.1435301281821-- From nobody Fri Jun 26 00:50:33 2015 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 399161A1A8C for ; Fri, 26 Jun 2015 00:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sXlLPGmri53B for ; Fri, 26 Jun 2015 00:50:29 -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 E83061A1A4C for ; Fri, 26 Jun 2015 00:50:28 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Z8OP3-0001RM-B7; Fri, 26 Jun 2015 09:50:25 +0200 Message-ID: <558D00A0.1090406@si6networks.com> Date: Fri, 26 Jun 2015 04:34:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Brian E Carpenter References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150611165858.GT39827@ernw.de> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> In-Reply-To: <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" , "ipv6-wg@ripe.net IPv6" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices 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, 26 Jun 2015 07:50:32 -0000 On 06/17/2015 01:45 AM, Fred Baker (fred) wrote: > >> On Jun 16, 2015, at 6:24 PM, Brian E Carpenter >> wrote: >> >> Personally I still think RFC 7045 is the most realistic on this >> point, but Fred would like things to get better ;-). > > And I haven't finished with Dennis Ferguson's comment. > > Bottom line, if one accepts the present status quo as the state > forever, then we should stop with RFC 7045, and (with Fernando) agree > to deprecate all extension headers. I'd like to not do that, and the > only way I see to not do that is to not accept the status quo. Not sure if that's simply a matter of an error in punctuation (or in my interpretation)... but for the record, I'm not arguing in favor of deprecating IPv6 EHs. Actually, I've worked to figured out what's the status quo, and working on stuff that may help to change that (e.g., RFC7112). 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 Jun 26 00:58:23 2015 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 C43C41B3597 for ; Fri, 26 Jun 2015 00:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QeGaUcxYCoqM for ; Fri, 26 Jun 2015 00:58:20 -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 562631B3599 for ; Fri, 26 Jun 2015 00:58:20 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Z8OWg-0001Sm-JC; Fri, 26 Jun 2015 09:58:18 +0200 Message-ID: <558D051E.1040405@si6networks.com> Date: Fri, 26 Jun 2015 04:54:06 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian Haberman , v6ops@ietf.org References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net> <20150617180409.GA17739@ernw.de> <5581BAE9.3060205@innovationslab.net> In-Reply-To: <5581BAE9.3060205@innovationslab.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 26 Jun 2015 07:58:21 -0000 On 06/17/2015 03:22 PM, Brian Haberman wrote: >> fragment" of a single datagram coming in, this is probably not an >> option for all those types of security controls (intrusion detectors, >> First Hop Security mechanisms, Infrastructure ACLs) expected to work >> mostly in wire speed. It is hence not an option for a number of >> networks using such techniques which is why they usually drop all >> extension headers except for AH, ESP and (in a few cases) FH. Doing >> so is a reasonable decision from their side and will not exactly >> encourage widespread development of new services using extension >> headers. Which then raises the question: what's the benefit of this >> thing called extension headers which do not provide much use today >> and might - given there's a growing number of networks acting as >> described - not provide much use tomorrow? This thing then seems to >> add an undesirable layer of complexity. > > Hmm... The old NFR platform, which I think got purchased by Checkpoint, > performed fragmentation re-assembly prior to doing its analysis. So, at > least some products close that hole. ... for IPv6 traffic? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 26 02:20:21 2015 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 CE6351A1B34 for ; Fri, 26 Jun 2015 02:20:19 -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_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] 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 PrKy4KvFF1j8 for ; Fri, 26 Jun 2015 02:20:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D10F21A1B2C for ; Fri, 26 Jun 2015 02:20:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Z8Pnq-0000HRC; Fri, 26 Jun 2015 11:20:06 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> <20150625191428.GJ67883@Space.Net> In-reply-to: Your message of "Thu, 25 Jun 2015 21:14:28 +0200 ." <20150625191428.GJ67883@Space.Net> Date: Fri, 26 Jun 2015 11:20:05 +0200 Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 09:20:20 -0000 In your letter dated Thu, 25 Jun 2015 21:14:28 +0200 you wrote: >No. > >For *you* this might make sense and be a useful feature. For me, I might >like it, but will never actually use it (because I'm way too lazy to be >interested in multiple possible Internet uplinks for my car - and why I >should bother to trade the nice *external* antenna of the car with the >great reception of a typical smartphone inside a large moving metal box). I hope that car manufacturers will find their way back into modular electronics, just like car radios ages ago. With he current rate of development, car electronics are obsolete for most of the car's lifetime. A good example is built-in navigation systems, where car manufactures have a hard time understanding what to charge for updating maps, so people just use a standalone device next to the built-in one. Android devices typically receive their last update 1.5 years after the devices were last sold. Nice driving around with an unpatched, internet connected car entertainment system. With modular electronics, those who want their pi powered hadoop cluster can just by an aftermarket upgrade. From nobody Fri Jun 26 05:55:08 2015 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 7F7201B2DAB for ; Fri, 26 Jun 2015 05:55:06 -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 B5cDNmG72SzT for ; Fri, 26 Jun 2015 05:55:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA4A1B2DAA for ; Fri, 26 Jun 2015 05:55:05 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0864F880D1; Fri, 26 Jun 2015 05:55:05 -0700 (PDT) Received: from brians-mbp.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9B52013693E8; Fri, 26 Jun 2015 05:55:04 -0700 (PDT) Message-ID: <558D4BA2.4060608@innovationslab.net> Date: Fri, 26 Jun 2015 08:54:58 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Fernando Gont , v6ops@ietf.org References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net> <20150617180409.GA17739@ernw.de> <5581BAE9.3060205@innovationslab.net> <558D051E.1040405@si6networks.com> In-Reply-To: <558D051E.1040405@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LUUMlOQkBac76JxSPfh3A5IUEXrj8xMEa" Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices 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, 26 Jun 2015 12:55:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LUUMlOQkBac76JxSPfh3A5IUEXrj8xMEa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/26/15 3:54 AM, Fernando Gont wrote: > On 06/17/2015 03:22 PM, Brian Haberman wrote: >=20 >>> fragment" of a single datagram coming in, this is probably not an >>> option for all those types of security controls (intrusion detectors,= >>> First Hop Security mechanisms, Infrastructure ACLs) expected to work >>> mostly in wire speed. It is hence not an option for a number of >>> networks using such techniques which is why they usually drop all >>> extension headers except for AH, ESP and (in a few cases) FH. Doing >>> so is a reasonable decision from their side and will not exactly >>> encourage widespread development of new services using extension >>> headers. Which then raises the question: what's the benefit of this >>> thing called extension headers which do not provide much use today >>> and might - given there's a growing number of networks acting as >>> described - not provide much use tomorrow? This thing then seems to >>> add an undesirable layer of complexity. >> >> Hmm... The old NFR platform, which I think got purchased by Checkpoint= , >> performed fragmentation re-assembly prior to doing its analysis. So, = at >> least some products close that hole. >=20 > ... for IPv6 traffic? >=20 I believe so from what I remember (but I can't find documentation right off). The NFR was purchased by Checkpoint and became the IPS-1 and the IPs-1 supports IPv6. Regards, Brian --LUUMlOQkBac76JxSPfh3A5IUEXrj8xMEa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVjUunAAoJEBOZRqCi7goqRogH/3JsQvganWXodYdolL9Nvl+8 L9VxL9d3H5hJTrhnRKyN6hmjZeygWp/COL0AGzSJVBUN9k0CX3mXxwkhm4pdQPRb OxRvsSowuMoulujUKHHcF6pvtinSxF5wQCBG7vPJJ7YuzLRZ6Mq6k3vzQJ81BQ1R xFuzYkt2sJFqcxSi5lIgjCbQpxkTRvARUaRtvzOGj9ZqEOY9QiFlC4jM8gUquavT fw3Qe4QOQzlhC4yud9pHceweqdL9Je/7hnV87RpYE7K0FXbIdxw4RioJCW10G4QO wXuplS80wVDA3B5HDWXXjLEb5e5J9htTMLiNFybhKp2vuJaP96PxoVbKa01YiAQ= =zQ1K -----END PGP SIGNATURE----- --LUUMlOQkBac76JxSPfh3A5IUEXrj8xMEa-- From nobody Fri Jun 26 07:11:37 2015 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 026611B2F57 for ; Fri, 26 Jun 2015 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JJ4-dT4L44v5 for ; Fri, 26 Jun 2015 07:11:32 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id F1CA11B2F55 for ; Fri, 26 Jun 2015 07:11:31 -0700 (PDT) Received: from delong-dhcp203.delong.com (delong-dhcp3 [192.159.10.203]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t5QEBUHB017977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Jun 2015 07:11:30 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E22B204A-B83F-4A5E-A271-594096401BEA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <2031204131.175399.1435301281824.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 26 Jun 2015 07:11:26 -0700 Message-Id: <9E11DA5A-30AA-4FBB-8148-61B22347F5BF@delong.com> References: <2031204131.175399.1435301281824.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 14:11:35 -0000 --Apple-Mail=_E22B204A-B83F-4A5E-A271-594096401BEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 25, 2015, at 23:48 , Mark ZZZ Smith > wrote: >=20 >=20 > From: Owen DeLong > > To: Gert Doering >=20 > Cc: v6ops@ietf.org =20 > Sent: Friday, 26 June 2015, 5:24 > Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy = for bridging hotspots >=20 >=20 > > For the typical driver who is already challenged pairing his mobile = via > > BT with his car's handsfree? No go. Do one thing, do it well, and = NEVER > > ask a car owner (or any normal Internet user) about technical = decisions. >=20 > We can agree to disagree. IMHO, this should be as simple as two = settings. >=20 > One on the phone: Provide Internet Access to Car: ON/OFF >=20 > One in the car: Get internet access from: CAR <-> PHONE >=20 >=20 > As to the typical driver being challenged pairing his mobile, frankly, = I=E2=80=99m challenged > with that on many occasions, not because I don=E2=80=99t know how to = do it and not because > I don=E2=80=99t understand what is involved or can=E2=80=99t follow = directions, but because BlueTooth > pairing implementation on most cars and most devices is a steaming = pile of poorly > written and even less well tested code that is fragile, buggy, and = unreliable. >=20 > Assuming that the underlying connectivity code works, the above two = settings > should not be difficult to implement correctly. They are far less = complex than > Bluetooth. >=20 >=20 >=20 > / I think another thing to remember is that "enablement" can imply a = default. For example, if my car comes with a SIM slot, and I choose to = put one on in it, then I've implicitly chosen that the car should by = default use the connectivity provided by its own 3/4G connectivity. I'm = also have likely to have chosen the particular SIM and its associated = usage plan based on my expected usage of the Internet by and possibly in = the car. If the car also has a Wifi hotspot in it, I'll likely associate = my phone with it once, so that from then on my phone will automatically = use the car's connectivity every time I get in it, without any = intervention on my part at all. That would be much more convenient than = having to switch on and off hotspot support on my phone each and every = time I get in the car - and it is likely people will sometimes forget, = and then try to do that while they're driving, which will be as or more = dangerous than sending text messages while driving. >=20 I=E2=80=99m all for intelligent defaults in the settings in question, = but I want the ability to make those choices without having to = plug/unplug hardware. Cars are mobile. Phones are mobile. Carrier policies less so. It may = well be that I have different phones for different localities. When = I=E2=80=99m home, I want to use the SIM I put in the car. When I drive = somewhere else I may well want to switch off of using that SIM onto = using a phone which I maintain for that locality. I don=E2=80=99t want = to have to make hardware changes to facilitate this. Until you can get carriers to offer reasonable roaming prices (along the = lines of current T-Mo free international data or better), these kinds of = needs will persist. If you want examples of just how bad this is, single-SIM phones are the = exception rather than the rule if you shop for a phone in Hong Kong. = Most have dual-SIM capability and some even take 3 last I looked. I don=E2=80=99t hold T-Mo up as any sort of shining example in general, = but their pricing plan is the one and only one reason I=E2=80=99m using = them for now. Other carriers should take note of this if they want my = business. Owen --Apple-Mail=_E22B204A-B83F-4A5E-A271-594096401BEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 25, 2015, at 23:48 , Mark ZZZ Smith = <markzzzsmith@yahoo.com.au> wrote:


From: Owen DeLong <owen@delong.com>
To: Gert Doering <gert@space.net> 
Cc: v6ops@ietf.org 
Sent: Friday, 26 June 2015, = 5:24
Subject: Re: [v6ops] Apple and IPv6, = a few clarifications - ND proxy for bridging hotspots


> For the typical driver who is already challenged pairing = his mobile via
> BT with his car's = handsfree?  No go.  Do one thing, do it well, and NEVER
> ask a car owner (or any normal Internet = user) about technical decisions.

We can agree to disagree. IMHO, this should be = as simple as two settings.

One on the phone: Provide Internet Access to Car: ON/OFF

One in the car: = Get internet access from: CAR <-> PHONE


As to the typical driver being = challenged pairing his mobile, frankly, I=E2=80=99m challenged
with that on many occasions, not because I = don=E2=80=99t know how to do it and not because
I don=E2=80=99t understand what is involved or can=E2=80=99t = follow directions, but because BlueTooth
pairing implementation on most cars and most devices is a = steaming pile of poorly
written and even = less well tested code that is fragile, buggy, and unreliable.

Assuming that = the underlying connectivity code works, the above two settings
should not be difficult to implement = correctly. They are far less complex than
Bluetooth.



/ I think another thing to = remember is that "enablement" can imply a default. For example, if my = car comes with a SIM slot, and I choose to put one on in it, then I've = implicitly chosen that the car should by default use the connectivity = provided by its own 3/4G connectivity. I'm also have likely to have = chosen the particular SIM and its associated usage plan based on my = expected usage of the Internet by and possibly in the car. If the car = also has a Wifi hotspot in it, I'll likely associate my phone with it = once, so that from then on my phone will automatically use the car's = connectivity every time I get in it, without any intervention on my part = at all. That would be much more convenient than having to switch on and = off hotspot support on my phone each and every time I get in the car - = and it is likely people will sometimes forget, and then try to do that = while they're driving, which will be as or more dangerous than sending = text messages while driving.


I=E2=80=99m all for intelligent defaults in the = settings in question, but I want the ability to make those choices = without having to plug/unplug hardware.

Cars are mobile. Phones are mobile. = Carrier policies less so. It may well be that I have different phones = for different localities. When I=E2=80=99m home, I want to use the SIM I = put in the car. When I drive somewhere else I may well want to switch = off of using that SIM onto using a phone which I maintain for that = locality. I don=E2=80=99t want to have to make hardware changes to = facilitate this.

Until you can get carriers to offer reasonable roaming prices = (along the lines of current T-Mo free international data or better), = these kinds of needs will persist.

If you want examples of just how bad = this is, single-SIM phones are the exception rather than the rule if you = shop for a phone in Hong Kong. Most have dual-SIM capability and some = even take 3 last I looked.

I don=E2=80=99t hold T-Mo up as any sort of shining example = in general, but their pricing plan is the one and only one reason I=E2=80=99= m using them for now. Other carriers should take note of this if they = want my business.

Owen

= --Apple-Mail=_E22B204A-B83F-4A5E-A271-594096401BEA-- From nobody Fri Jun 26 08:01:23 2015 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 6DE311B3087 for ; Fri, 26 Jun 2015 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 3QYhui3fecRO for ; Fri, 26 Jun 2015 08:01:20 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9551B307C for ; Fri, 26 Jun 2015 08:01:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5QF1ALW003544; Fri, 26 Jun 2015 17:01:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8E530204D7C; Fri, 26 Jun 2015 17:04:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7F498204B9E; Fri, 26 Jun 2015 17:04:08 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5QF18nq001537; Fri, 26 Jun 2015 17:01:10 +0200 Message-ID: <558D6934.5010608@gmail.com> Date: Fri, 26 Jun 2015 17:01:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Owen DeLong References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> In-Reply-To: <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 15:01:22 -0000 Le 25/06/2015 21:08, Owen DeLong a écrit : > >> On Jun 25, 2015, at 02:11 , Alexandru Petrescu wrote: >> >> >> >> Le 24/06/2015 20:38, james woodyatt a écrit : >>> On Jun 24, 2015, at 07:12, Alexandru Petrescu >>> > >>> wrote: >>>> >>>> […] In the car use-case the smartphone connects to the dashboard >>>> using a ptp link. And it's the car's dashboard which offers a >>>> WiFi hotspot. These couldn't be bridged (ND proxy) by the >>>> smartphone alone, it would need the dashboard router to participate >>>> in this ND proxy. […] >>> >>> I suspect the point you may be missing here is the logic encoded >>> elsewhere in iOS that restricts the use of Mobile Internet Sharing >>> to the telephony uplink. It is not possible with iOS to share >>> Internet access over the Wi-fi (or other interfaces) with tethered >>> devices. Only the telephony data service is eligible for Mobile >>> Internet Sharing. >> >> That is a good point. >> >> There is an ongoing technical debate in the car comm community - should >> the smartphone provide Internet connectivity to the car? Or should the >> smartphone use the Internet connectivity offered by the car. > > The car community should not be making this decision. > > The car _AND_ the smartphone should be delivered in such a way that the > end user can choose whichever plan best suits his needs and offers him the > best set of tradeoffs between features, price, and whatever else the end user > chooses to care about. This is a great formulation of requirements but there is nothing else outside the car industry that did this kind of behaviour in the past. So it's not that easy to implement. (typically a automated configuration is using RA/DHCP/NAT and these have a strong notion of directivity - client and server, provider and consumer; in the car setting you have two strongly opposed interests smartphone's and car's). You dont have one protocol that can change roles dynamically. A DHCP Server is a Server can't dynamically become a Client. A NAT is in one direction cant dynamically change direction. Worse - Internet addresses are centrally assigned and distributed, one can't make IP addresses out of nothing and reach the Internet bidirectionally. That's why it's easier if a decision were made (one of the two provides Internet to the other). > If I want the phone to provide the connectivity to the car, I should be able > to do that. > > If I want the car to provide connectivity and have the phone use that, I should > be able to do that. > > I should be able to choose and I should be able to change my decision whenever > it suits me. This is very strong requirements and difficult to meet. > >> >> Right now where I live a large number of marketed cars are on the first >> option. It is on that option that I think smartphone's iOS Mobile >> Internet Sharing can help, provided it does more than NDproxy. > > For most of the marketed cars I am aware of in the US where that is the > case, it is largely because the car doesn’t really know what a network is > in any meaningful way, or, because the car maker didn’t want to think about > solving the connectivity problem in a useful way. > > I do not know of a case where it is a well thought out decision by the > manufacturer to have that as a deliberate architecture rather than just > laziness at best. I wouldnt say laziness, some work hard at it, but it's not easy. Alex > > Owen > > > From nobody Fri Jun 26 08:05:17 2015 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 3642F1B3097 for ; Fri, 26 Jun 2015 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 WzfxPaWd0j_h for ; Fri, 26 Jun 2015 08:05:08 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C291E1B3098 for ; Fri, 26 Jun 2015 08:05:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5QF53QW002083; Fri, 26 Jun 2015 17:05:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5DAF0203F2F; Fri, 26 Jun 2015 17:08:01 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4FDC4203891; Fri, 26 Jun 2015 17:08:01 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5QF52Dx005407; Fri, 26 Jun 2015 17:05:02 +0200 Message-ID: <558D6A1E.8@gmail.com> Date: Fri, 26 Jun 2015 17:05:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Gert Doering , Owen DeLong References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> <20150625191428.GJ67883@Space.Net> In-Reply-To: <20150625191428.GJ67883@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 15:05:15 -0000 Le 25/06/2015 21:14, Gert Doering a écrit : > Hi, > > On Thu, Jun 25, 2015 at 12:08:14PM -0700, Owen DeLong wrote: >> If I want the phone to provide the connectivity to the car, I should be able >> to do that. >> >> If I want the car to provide connectivity and have the phone use that, I should >> be able to do that. >> >> I should be able to choose and I should be able to change my decision whenever >> it suits me. > > No. > > For *you* this might make sense and be a useful feature. For me, I might > like it, but will never actually use it (because I'm way too lazy to be > interested in multiple possible Internet uplinks for my car - and why I > should bother to trade the nice *external* antenna of the car with the > great reception of a typical smartphone inside a large moving metal box). Well recent 5-way extra-small antennas are getting better signal if sitting on roof rather than on the smartphone. BEsides, they catch not only 4G but also GPS and 802.11p. The reception of a typical smartphone inside the car is great some times, but less so other times. If just some little browsing then reception is not a problem. But a 24/7 audio/video stream is improved by better antennas in certain areas and with thermally-thick windows. Alex > For the typical driver who is already challenged pairing his mobile via > BT with his car's handsfree? No go. Do one thing, do it well, and NEVER > ask a car owner (or any normal Internet user) about technical decisions. > > Gert Doering > -- NetMaster > From nobody Fri Jun 26 08:07:16 2015 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 2181B1B3098 for ; Fri, 26 Jun 2015 08:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 GFHoemMxMeny for ; Fri, 26 Jun 2015 08:07:13 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799861B3096 for ; Fri, 26 Jun 2015 08:07:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5QF79i1002954; Fri, 26 Jun 2015 17:07:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 72781203F2F; Fri, 26 Jun 2015 17:10:07 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 63EBA203891; Fri, 26 Jun 2015 17:10:07 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5QF78hN008103; Fri, 26 Jun 2015 17:07:08 +0200 Message-ID: <558D6A9C.6070206@gmail.com> Date: Fri, 26 Jun 2015 17:07:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Owen DeLong , Gert Doering References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> <20150625191428.GJ67883@Space.Net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 15:07:15 -0000 Le 25/06/2015 21:24, Owen DeLong a écrit : > >> For the typical driver who is already challenged pairing his mobile via >> BT with his car's handsfree? No go. Do one thing, do it well, and NEVER >> ask a car owner (or any normal Internet user) about technical decisions. > > We can agree to disagree. IMHO, this should be as simple as two settings. > > One on the phone: Provide Internet Access to Car: ON/OFF > > One in the car: Get internet access from: CAR <-> PHONE Except that one wants the car to get Internet access from the passenger's smartphone, and other times from in-house hotspot, from the PLC-enabled-charging-station at home, from the WiFi or 802.11p hotspots in some areas like Parking or gas station. Alex > > As to the typical driver being challenged pairing his mobile, frankly, I’m challenged > with that on many occasions, not because I don’t know how to do it and not because > I don’t understand what is involved or can’t follow directions, but because BlueTooth > pairing implementation on most cars and most devices is a steaming pile of poorly > written and even less well tested code that is fragile, buggy, and unreliable. > > Assuming that the underlying connectivity code works, the above two settings > should not be difficult to implement correctly. They are far less complex than > Bluetooth. > > Owen > > > From nobody Fri Jun 26 08:11:06 2015 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 44C841B3042 for ; Fri, 26 Jun 2015 08:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 R7os6YizMV6Q for ; Fri, 26 Jun 2015 08:10:58 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D031A8931 for ; Fri, 26 Jun 2015 08:10:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5QFAurn015864 for ; Fri, 26 Jun 2015 17:10:56 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 751AD204E30 for ; Fri, 26 Jun 2015 17:13:54 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D37A2047A3 for ; Fri, 26 Jun 2015 17:13:54 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5QFAtbS011759 for ; Fri, 26 Jun 2015 17:10:55 +0200 Message-ID: <558D6B7F.60202@gmail.com> Date: Fri, 26 Jun 2015 17:10:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <2031204131.175399.1435301281824.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <2031204131.175399.1435301281824.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 15:11:04 -0000 Le 26/06/2015 08:48, Mark ZZZ Smith a écrit : > > ------------------------------------------------------------------------ > *From:* Owen DeLong > *To:* Gert Doering > *Cc:* v6ops@ietf.org > *Sent:* Friday, 26 June 2015, 5:24 > *Subject:* Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy > for bridging hotspots > > > > For the typical driver who is already challenged pairing his mobile via > > BT with his car's handsfree? No go. Do one thing, do it well, and NEVER > > ask a car owner (or any normal Internet user) about technical decisions. > > We can agree to disagree. IMHO, this should be as simple as two settings. > > One on the phone: Provide Internet Access to Car: ON/OFF > > One in the car: Get internet access from: CAR <-> PHONE > > > As to the typical driver being challenged pairing his mobile, frankly, > I’m challenged > with that on many occasions, not because I don’t know how to do it and > not because > I don’t understand what is involved or can’t follow directions, but > because BlueTooth > pairing implementation on most cars and most devices is a steaming pile > of poorly > written and even less well tested code that is fragile, buggy, and > unreliable. > > Assuming that the underlying connectivity code works, the above two settings > should not be difficult to implement correctly. They are far less > complex than > Bluetooth. > > > > / I think another thing to remember is that "enablement" can imply a > default. For example, if my car comes with a SIM slot, and I choose to > put one on in it, then I've implicitly chosen that the car should by > default use the connectivity provided by its own 3/4G connectivity. I'm > also have likely to have chosen the particular SIM and its associated > usage plan based on my expected usage of the Internet by and possibly in > the car. If the car also has a Wifi hotspot in it, I'll likely associate > my phone with it once, so that from then on my phone will automatically > use the car's connectivity every time I get in it, without any > intervention on my part at all. That would be much more convenient than > having to switch on and off hotspot support on my phone each and every > time I get in the car - and it is likely people will sometimes forget, > and then try to do that while they're driving, which will be as or more > dangerous than sending text messages while driving. > > / Having choice can be good, but you want to try to minimise both the > amount of choices and how often people have to make them - too much > choice can lead to paralysis, such that making no choice becomes the > safest "choice". I think when it comes to usability, predictable and > expected defaults, and matching peoples' existing conceptual and mental > models are much better. The book "The Design of Every Day Things" is an > excellent book on making things easier to use. I agree having choice is good. Some cars already feature a 3-option menu where the car should get its Internet from. That is good, but it is bad because the driver has to concentrate on it. So some people came up with automating that choice. That's not in the cars but maybe in the future. The problem is that future will be very remote because there are so many choices of connectivity for the car, for the passengers. Doesnt look simple to list all the choices, and to automate them. And, worse, the protocols are not made to work in that dynamic way. Alex > > / Regards, > / Mark. > > > > Owen > > _______________________________________________ > 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 Fri Jun 26 08:15:30 2015 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 60A101A007F for ; Fri, 26 Jun 2015 08:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.084 X-Spam-Level: X-Spam-Status: No, score=-5.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 QYn5IGWvBBzZ for ; Fri, 26 Jun 2015 08:15:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0D71A0064 for ; Fri, 26 Jun 2015 08:15:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5QFFQBe005813 for ; Fri, 26 Jun 2015 17:15:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 62A5E204E14 for ; Fri, 26 Jun 2015 17:18:24 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5A99A203F2F for ; Fri, 26 Jun 2015 17:18:24 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5QFFPF3017453 for ; Fri, 26 Jun 2015 17:15:25 +0200 Message-ID: <558D6C8D.6080603@gmail.com> Date: Fri, 26 Jun 2015 17:15:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> <20150625191428.GJ67883@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 15:15:29 -0000 Le 26/06/2015 11:20, Philip Homburg a écrit : > In your letter dated Thu, 25 Jun 2015 21:14:28 +0200 you wrote: >> No. >> >> For *you* this might make sense and be a useful feature. For me, I >> might like it, but will never actually use it (because I'm way too >> lazy to be interested in multiple possible Internet uplinks for my >> car - and why I should bother to trade the nice *external* antenna >> of the car with the great reception of a typical smartphone inside >> a large moving metal box). > > I hope that car manufacturers will find their way back into modular > electronics, just like car radios ages ago. > > With he current rate of development, car electronics are obsolete for > most of the car's lifetime. > > A good example is built-in navigation systems, where car manufactures > have a hard time understanding what to charge for updating maps, so > people just use a standalone device next to the built-in one. I fully agree. NAvigation systems continue to be a large fiasco since they first appeared on the market. There is still no easy way to update them - IMHO the reason has to do with policy: who controls the car, who writes the software, wo controls the communication system... these are typically very different industries. > Android devices typically receive their last update 1.5 years after > the devices were last sold. Nice driving around with an unpatched, > internet connected car entertainment system. :-) There is another tendency here: car manufacturers consider TomTom, google and a few others to be the best source of information on geography. Whereas the best source of information comes from the authority who controls these roads. > With modular electronics, those who want their pi powered hadoop > cluster can just by an aftermarket upgrade. YEs, but car manufacturers dont want the same aftermarket upgrade to work on their cars as simply as it works on competition's cars, and that's a problem. Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Jun 26 09:17:34 2015 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 60F661A00E8 for ; Fri, 26 Jun 2015 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SkVSNDj63W2W for ; Fri, 26 Jun 2015 09:17:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3679D1A00B1 for ; Fri, 26 Jun 2015 09:17:28 -0700 (PDT) Received: from delong-dhcp203.delong.com (delong-dhcp3 [192.159.10.203]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t5QGHO6D029623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Jun 2015 09:17:24 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A63EAAE4-8330-43ED-8B70-40785EC53DA8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <558D6934.5010608@gmail.com> Date: Fri, 26 Jun 2015 09:17:23 -0700 Message-Id: <7702B51F-ADBA-40B9-8CA8-4F4E38D39C82@delong.com> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com> <558D6934.5010608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots 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, 26 Jun 2015 16:17:33 -0000 --Apple-Mail=_A63EAAE4-8330-43ED-8B70-40785EC53DA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jun 26, 2015, at 08:01 , Alexandru Petrescu = wrote: >=20 >=20 >=20 > Le 25/06/2015 21:08, Owen DeLong a =E9crit : >>=20 >>> On Jun 25, 2015, at 02:11 , Alexandru Petrescu = wrote: >>>=20 >>>=20 >>>=20 >>> Le 24/06/2015 20:38, james woodyatt a =E9crit : >>>> On Jun 24, 2015, at 07:12, Alexandru Petrescu >>>> > >>>> wrote: >>>>>=20 >>>>> [=85] In the car use-case the smartphone connects to the dashboard >>>>> using a ptp link. And it's the car's dashboard which offers a >>>>> WiFi hotspot. These couldn't be bridged (ND proxy) by the >>>>> smartphone alone, it would need the dashboard router to = participate >>>>> in this ND proxy. [=85] >>>>=20 >>>> I suspect the point you may be missing here is the logic encoded >>>> elsewhere in iOS that restricts the use of Mobile Internet Sharing >>>> to the telephony uplink. It is not possible with iOS to share >>>> Internet access over the Wi-fi (or other interfaces) with tethered >>>> devices. Only the telephony data service is eligible for Mobile >>>> Internet Sharing. >>>=20 >>> That is a good point. >>>=20 >>> There is an ongoing technical debate in the car comm community - = should >>> the smartphone provide Internet connectivity to the car? Or should = the >>> smartphone use the Internet connectivity offered by the car. >>=20 >> The car community should not be making this decision. >>=20 >> The car _AND_ the smartphone should be delivered in such a way that = the >> end user can choose whichever plan best suits his needs and offers = him the >> best set of tradeoffs between features, price, and whatever else the = end user >> chooses to care about. >=20 > This is a great formulation of requirements but there is nothing else = outside the car industry that did this kind of behaviour in the past. So = it's not that easy to implement. (typically a automated configuration = is using RA/DHCP/NAT and these have a strong notion of directivity - = client and server, provider and consumer; in the car setting you have = two strongly opposed interests smartphone's and car's). I disagree=85 HDMI provides some similar functionalities. Many portable routers provide similar functionality in hotel rooms all = over the place. Apple=92s airport products provide similar functionality. There are MANY examples of similar functionality (albeit with a coarser = UI) that abound. For that matter, Internet Connection Sharing on MacOS X and Windows = provides similar functionality. > You dont have one protocol that can change roles dynamically. A DHCP = Server is a Server can't dynamically become a Client. A NAT is in one = direction cant dynamically change direction. You don=92t need it. It=92s a very simple independent selection in two = devices worst case: Phone: Internet Source: [Carrier [|Wifi = 1[|Wifi2=85]]] [share internet with optional menu of = wifi and/or other networks, possibly allowing multi-select] Car: Internet Source: [Carrier [|Phone = 1[|Phone 2=85]]] [share internet with optional menu of = wifi and/or other networks, possibly allowing multi-select] If you choose Carrier in both cases, then both will independently access = the internet via their respective carriers. If you choose the Car=92s wifi on the phone and the phone=92s wifi on = the car, then you get what you would expect =97 a disconnected LAN. Not rocket science to configure and not hard for the end user to = understand IMHO. >=20 > Worse - Internet addresses are centrally assigned and distributed, one = can't make IP addresses out of nothing and reach the Internet = bidirectionally. Why is that a problem? That=92s what DHCP-PD is for. >=20 > That's why it's easier if a decision were made (one of the two = provides Internet to the other). It=92s a little bit (very tiny fraction) easier because one gets to = implement a host instead of a router, but really not enough easier to be = worth the loss in user functionality. Heck, I can put everything needed together on a Raspberry PI for under = $100 without writing any software of my own.=20 >=20 >> If I want the phone to provide the connectivity to the car, I should = be able >> to do that. >>=20 >> If I want the car to provide connectivity and have the phone use = that, I should >> be able to do that. >>=20 >> I should be able to choose and I should be able to change my decision = whenever >> it suits me. >=20 > This is very strong requirements and difficult to meet. See above=85 It=92s already been met in the phone. The phone already has = all the required functionality. Why can=92t the same functionality be implemented in a car with a larger = form factor and greater power resources with the ability to potentially support a larger codebase? When did a more capable system become a bigger development challenge for = basic functionality than an embedded system? Somehow I missed the memo when that flip occurred. >=20 >>=20 >>>=20 >>> Right now where I live a large number of marketed cars are on the = first >>> option. It is on that option that I think smartphone's iOS Mobile >>> Internet Sharing can help, provided it does more than NDproxy. >>=20 >> For most of the marketed cars I am aware of in the US where that is = the >> case, it is largely because the car doesn=92t really know what a = network is >> in any meaningful way, or, because the car maker didn=92t want to = think about >> solving the connectivity problem in a useful way. >>=20 >> I do not know of a case where it is a well thought out decision by = the >> manufacturer to have that as a deliberate architecture rather than = just >> laziness at best. >=20 > I wouldnt say laziness, some work hard at it, but it's not easy. See above=85 It=92s not hard, it=92s been done, there=92s open source = code to do it. Owen --Apple-Mail=_A63EAAE4-8330-43ED-8B70-40785EC53DA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 26, 2015, at 08:01 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:



Le 25/06/2015 21:08, Owen DeLong a =E9crit = :

On = Jun 25, 2015, at 02:11 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:



Le 24/06/2015 20:38, james = woodyatt a =E9crit :
On= Jun 24, 2015, at 07:12, Alexandru Petrescu
<alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>>
wrote:

[=85] In the car use-case the smartphone connects to the = dashboard
using a ptp link.  And it's the car's = dashboard which offers a
WiFi hotspot.  These = couldn't be bridged (ND proxy) by the
smartphone alone, it = would need the dashboard router to participate
in this ND = proxy. [=85]

I suspect the = point you may be missing here is the logic encoded
elsewhere= in iOS that restricts the use of Mobile Internet Sharing
to= the telephony uplink. It is not possible with iOS to share
Internet access over the Wi-fi (or other interfaces) with = tethered
devices. Only the telephony data service is = eligible for Mobile
Internet Sharing.

That is a good point.

There is an ongoing technical debate in the = car comm community - should
the smartphone provide = Internet connectivity to the car?  Or should the
smartphone use the Internet connectivity offered by the = car.

The car community should = not be making this decision.

The car _AND_ = the smartphone should be delivered in such a way that the
end user can choose whichever plan best suits his needs and = offers him the
best set of tradeoffs between features, = price, and whatever else the end user
chooses to care = about.

This is a great = formulation of requirements but there is nothing else outside the car = industry that did this kind of behaviour in the past. So it's not that = easy to implement.  (typically a automated configuration is using = RA/DHCP/NAT and these have a strong notion of directivity - client and = server, provider and consumer; in the car setting you have two strongly = opposed interests smartphone's and car's).

I disagree=85 HDMI provides some similar = functionalities.

Many portable = routers provide similar functionality in hotel rooms all over the = place.

Apple=92s airport products = provide similar functionality.

There = are MANY examples of similar functionality (albeit with a coarser UI) = that abound.

For that matter, = Internet Connection Sharing on MacOS X and Windows provides similar = functionality.

You dont have one = protocol that can change roles dynamically.  A DHCP Server is a = Server can't dynamically become a Client.  A NAT is in one = direction cant dynamically change direction.

You don=92t need = it. It=92s a very simple independent selection in two devices worst = case:

Phone:
= Internet Source: [Carrier [|Wifi = 1[|Wifi2=85]]]
[share internet with = optional menu of wifi and/or other networks, possibly allowing = multi-select]

= Car:
Internet Source: = [Carrier [|Phone 1[|Phone 2=85]]]
= [share internet with optional menu of = wifi and/or other networks, possibly allowing = multi-select]

If you choose Carrier = in both cases, then both will independently access the internet via = their respective carriers.

If you = choose the Car=92s wifi on the phone and the phone=92s wifi on the car, = then you get what you would expect =97 a disconnected LAN.

Not rocket science to configure and not hard for = the end user to understand IMHO.


Worse - Internet addresses = are centrally assigned and distributed, one can't make IP addresses out = of nothing and reach the Internet bidirectionally.

Why is that a = problem? That=92s what DHCP-PD is for.


That's why it's easier if a decision were made = (one of the two provides Internet to the other).

It=92s a little = bit (very tiny fraction) easier because one gets to implement a host = instead of a router, but really not enough easier to be worth the loss = in user functionality.

Heck, I can = put everything needed together on a Raspberry PI for under $100 without = writing any software of my own. 


If I want the phone to = provide the connectivity to the car, I should be able
to = do that.

If I want the car to provide = connectivity and have the phone use that, I should
be able = to do that.

I should be able to choose and = I should be able to change my decision whenever
it suits = me.

This is very strong = requirements and difficult to meet.

See above=85 It=92s already been met in the phone. The = phone already has all the required functionality.
Why can=92t = the same functionality be implemented in a car with a larger form factor = and greater power resources
with the ability to potentially = support a larger codebase?

When did = a more capable system become a bigger development challenge for basic = functionality than
an embedded system? Somehow I missed the = memo when that flip occurred.




Right now = where I live a large number of marketed cars are on the first
option.  It is on that option that I think smartphone's = iOS Mobile
Internet Sharing can help, provided it does = more than NDproxy.

For most of = the marketed cars I am aware of in the US where that is the
case, it is largely because the car doesn=92t really know = what a network is
in any meaningful way, or, because the = car maker didn=92t want to think about
solving the = connectivity problem in a useful way.

I do = not know of a case where it is a well thought out decision by the
manufacturer to have that as a deliberate architecture rather = than just
laziness at best.

I wouldnt say laziness, some work hard at it, = but it's not easy.

See above=85 = It=92s not hard, it=92s been done, there=92s open source code to do = it.

Owen

= --Apple-Mail=_A63EAAE4-8330-43ED-8B70-40785EC53DA8-- From nobody Fri Jun 26 11:40:40 2015 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 465031A92E0 for ; Fri, 26 Jun 2015 11:40:38 -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_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 Q2v8P8q8gP4X for ; Fri, 26 Jun 2015 11:40:36 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B761A90E2 for ; Fri, 26 Jun 2015 11:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1435344036; x=2299257636; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FXvqJhaT4sTZU86XRnzZb4IhWFYxW6brUY8gPnqdNww=; b=dKUBr41kuZCcZ556VRsvk5+d24f13kmqfc5hgG/QmqlcAx/uVIRJaoueSfw09MqW D0oOsdT/h0sGlfQAA3lqctMX+glr0i8r3px04iIDkI4okwz9Tt7iAsL8bLuo3D1n dDemqVZYZs3qh3LjsdXMVAZvPDbpXZume8+AbIf95gt+HG293PRK4kst8apd8r6+ 5A9J06JmsmgM4WWoogaxheXL6hF/Z+IYpXedYXMyX7ctdKXHk1cQ8GTGJeWW8hRb wAERCXKsuWngdU6fnkD/6lmpBClw+laN0u9fa+bAvmcfLVeNNLVob5FgFkmRvyEX 1WPLlvXiijgYx6DsTZ/7ig==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 53.CB.18963.3AC9D855; Fri, 26 Jun 2015 11:40:35 -0700 (PDT) X-AuditID: 11973e12-f79456d000004a13-6d-558d9ca35ae2 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 1D.E4.32123.3AC9D855; Fri, 26 Jun 2015 11:40:35 -0700 (PDT) Received: from [17.153.52.250] by jimbu.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NQK00CRGEJN8050@jimbu.apple.com> for v6ops@ietf.org; Fri, 26 Jun 2015 11:40:35 -0700 (PDT) Content-type: multipart/alternative; boundary="Apple-Mail=_3F1A2525-B61C-4A04-9F9A-DF2F92347372" MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: David Schinazi In-reply-to: <6536E263028723489CCD5B6821D4B21303ECB135@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Fri, 26 Jun 2015 11:40:34 -0700 Message-id: <30B46C6D-5676-4E12-88FE-D6EBFA0D6793@apple.com> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <6536E263028723489CCD5B6821D4B21303ECB135@UK30S005EXS06.EEAD.EEINT.CO.UK> To: "Heatley, Nick" X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUi2FAYrLt4Tm+owa0vNhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrXzFQW/0iquzXzC3sDYEdnFyMkhIWAicW5zAzOELSZx4d56 ti5GLg4hgb2MEg+ajzHBFP1te8QKkWhlkrjy4DEbSEJI4BOjRP9SVxCbWSBJomvLUaAGDg5e AT2JR52yIGFhAUuJf2tOM4OE2QS0JA6sMQIJcwpESFzZ948VxGYRUJX4eWguO8QUE4ndnzrA pvMK2Eg8v/eTEWLtbkaJkzcngSVEBLQlmuf8YoS4TVZi65tWqDs72CS2nheZwCg0C8lFsxAu gghrSyxb+JoZwtaU2N+9nAVTXEOi89tE1gWMbKsYhXITM3N0M/NM9BILCnJS9ZLzczcxggJ+ up3QDsZTq6wOMQpwMCrx8Do094QKsSaWFVfmHmKU5mBREue9Vd8bKiSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoGRaWt4wfdDqYXH4p/syY1Tm98fGW2ebLLJTWnVgWUlPyr444ye2PC9TNC6 3vqoY1q2R6TR/5QZ61z1lcL/u9m7bjl8JWm6KfelPZWP215N+1cgNtv7aVp4rr6klfDt5Yr/ Cpcvm7S0eMPCpuIKn8VR6WtLJvhcCX71LFS/VeFKT4PSnHvn985UYinOSDTUYi4qTgQAE584 bFkCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUiON1OVXfxnN5Qgx1nLC1OH9vL7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGvnKwp+pVVcm/mEvYGxI7KLkZNDQsBE4m/bI1YIW0ziwr31 bF2MXBxCAq1MElcePGYDSQgJfGKU6F/qCmIzCyRJdG05ytTFyMHBK6An8ahTFiQsLGAp8W/N aWaQMJuAlsSBNUYgYU6BCIkr+/6BjWcRUJX4eWguO8QUE4ndnzrApvMK2Eg8v/eTEWLtbkaJ kzcngSVEBLQlmuf8YoS4TVZi65tWpgmM/LOQXDEL4QqIsLbEsoWvmSFsTYn93ctZMMU1JDq/ TWRdwMi2ilGgKDUnsdJYL7GgICdVLzk/dxMjKEQbCoN3MP5ZZnWIUYCDUYmHd0ZrT6gQa2JZ cWXuIUYJDmYlEV7Ort5QId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwLlreECgmkJ5akZqemFqQW wWSZODilGhi5+64wy91s++K5ZsWBr+xeUSXnI6ezb/p0UXVbm8/UkPCD+2YWpjEm21Rm1gpv kEvu2hfmzNpx+SlH5m2L7bODd7ZMsZAQvVS9Z2rZ6/OeXJc+7326KOHOpnTfhIQAxqWZce8l uQz/nWO9LM724PCfHg4pj8M1l2o1+e7sNov6YMhv+XP+cg4lluKMREMt5qLiRADnzdd2TQIA AA== Archived-At: Cc: Vividh Siddha , v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 26 Jun 2015 18:40:38 -0000 --Apple-Mail=_3F1A2525-B61C-4A04-9F9A-DF2F92347372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Nick, Sorry about the confusion, "bringing up IPv4 specifically" was = speculation on my end. I did mean a separate APN that could be used for hotspots and/or systems = that do not support IPv6. To support an IPv4-only device on a personal hotspot from an IPv6-only = iOS handset, we would need some type of translation from v4 to v6 on the iOS device. We currently do not = provide that. Thanks, David > On Jun 24, 2015, at 00:58, Heatley, Nick = wrote: >=20 > =20 > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org = ] On Behalf Of David Schinazi > Sent: 24 June 2015 08:16 > To: v6ops@ietf.org > Cc: Vividh Siddha > Subject: Re: [v6ops] Apple and IPv6, a few clarifications > =20 > Hi again, >=20 > First off, thanks everyone for the feedback and advice! > Here's an attempt at answering the questions that arose since my last = post. >=20 > *) Personal hotspot on iOS > Currently the hotspot shares whatever address families it gets from = the cellular network. > The current implementation broadcasts an IPv6-only network if the = cellular network is of that type, > but I could imagine carriers bringing up IPv4 specifically when using = this feature. Our custom version > of prefix sharing is described in more detail here: > = https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prp= roxy.c = > It supports creating multiple hotspots at the same time, such as Wi-FI = and Bluetooth and bridges them. >=20 > [Heatley, Nick] Thanks for sharing the information, David. > When you say you imagine carries bringing up IPv4 specifically for = personal hotspot, not sure what you mean - do you mean a parallel, = dedicated =E2=80=9Chotspot APN=E2=80=9D? > Many carriers across the globe, for their own individual business = reasons, have a common APN approach for the mass consumer market, but = nevertheless desire this common APN to go IPv6-only. > =20 > So I am nervous about how to support *any* device on a personal = hotspot from an IPv6-only iOS handset in this way, do you have any more = details on your intentions here? > Thanks for the discussion. Nick > =20 >=20 >=20 >=20 >=20 > =20 > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the = above-named person(s). If you are not the intended recipient, notify = the sender immediately, delete this email from your system and do not = disclose or use for any purpose. =20 > =20 > We may monitor all incoming and outgoing emails in line with current = legislation. We have taken steps to ensure that this email and = attachments are free from any virus, but it remains your responsibility = to ensure that viruses do not adversely affect you.=20 >=20 > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW >=20 > =20 --Apple-Mail=_3F1A2525-B61C-4A04-9F9A-DF2F92347372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Nick,

Sorry= about the confusion, "bringing up IPv4 specifically" was speculation on = my end.
I did mean a separate APN that could be = used for hotspots and/or systems that do not support IPv6.
To support an IPv4-only device on a personal hotspot from an = IPv6-only iOS handset, we would need some
type of = translation from v4 to v6 on the iOS device. We currently do not provide = that.

Thanks,
David


On Jun 24, 2015, at 00:58, = Heatley, Nick <nick.heatley@ee.co.uk> wrote:

 
 
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf = Of David = Schinazi
Sent: 24 June 2015 08:16
To: v6ops@ietf.org
Cc: Vividh Siddha
Subject: Re: [v6ops] Apple and IPv6, = a few clarifications
 
Hi again,

First off, thanks everyone for the feedback and advice!
Here's an attempt at answering the questions that arose since = my last post.

*) Personal hotspot on iOS
Currently the hotspot shares whatever address families it = gets from the cellular network.
The current implementation = broadcasts an IPv6-only network if the cellular network is of that = type,
but I could imagine carriers bringing up IPv4 = specifically when using this feature. Our custom version
of = prefix sharing is described in more detail here:
https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netin= et6/nd6_prproxy.c
It supports creating multiple hotspots at = the same time, such as Wi-FI and Bluetooth and bridges them.

[Heatley, Nick] Thanks for sharing the = information, David.
When you say you imagine carries bringing up IPv4 = specifically for personal hotspot, not sure what you mean - do you mean = a parallel, dedicated =E2=80=9Chotspot APN=E2=80=9D?
Many carriers across the = globe, for their own individual business reasons, have a common APN = approach for the mass consumer market, but nevertheless desire this = common APN to go IPv6-only.
 
So I am nervous about how = to support *any* device on a personal hotspot from an = IPv6-only iOS handset in this way, do you have any more details on your = intentions here?
Thanks for the discussion. Nick
 




 

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the = above-named person(s).  If you are not the intended recipient, = notify the sender immediately, delete this email from your system and do = not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with = current legislation. We have taken steps to ensure that this email and = attachments are free from any virus, but it remains your responsibility = to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company = Registered Number: 02382161
Registered Office Address: = Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

 

= --Apple-Mail=_3F1A2525-B61C-4A04-9F9A-DF2F92347372-- From nobody Fri Jun 26 18:08:46 2015 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 76DD31A6F3B; Fri, 26 Jun 2015 18:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UCxoBwCvB2p2; Fri, 26 Jun 2015 18:08:43 -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 D91651A1B81; Fri, 26 Jun 2015 18:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2863; q=dns/txt; s=iport; t=1435367323; x=1436576923; h=from:to:subject:date:message-id:references:mime-version; bh=BOnts8LsglKxl11rvA+kAF2hjENma4VkB7mLvgL5CdA=; b=mX9JTc7DUm5LYJ15kDlWeKUiYWzyDAERNE8FqhHY+Kwr9LNWP2+1BqRx hAXEEYQ6JCyarFX3NPzw4yKhOxKPcmjkpvR6KFNiFGCDkHoJI6al7Rwsf GRI5eLtknTbUKy90NcOEZYXxQX7nBL9n+LRCAEMm6YjCS2iOTo6kN0KSh U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DCAwBe9o1V/4wNJK1bgxGBMwa4fYQiCYdeAoE9OBQBAQEBAQEBgQqEIgEBAQMBfgsCARkDAQIvMhsCCAIEARIOiBkIzxIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qEdR6DEYEUBYcDhQ+HcgGCI4FQh16YNyZjgxdvgUaBAgEBAQ X-IronPort-AV: E=Sophos; i="5.13,687,1427760000"; d="asc'?scan'208"; a="6999700" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jun 2015 01:08:42 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5R18grg002339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jun 2015 01:08:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 26 Jun 2015 20:08:41 -0500 From: "Fred Baker (fred)" To: v6ops list , "sunset4@ietf.org" Thread-Topic: v6ops - Requested sessions have been scheduled for IETF 93 Thread-Index: AQHQsHXOuAEYxu7W0UO//22b5k6Pmg== Date: Sat, 27 Jun 2015 01:08:41 +0000 Message-ID: <911E3AC3-6955-4554-8249-228F23F8675F@cisco.com> References: <20150626235510.5508.8278.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_2500BB4E-64A3-46DF-8DFC-47B37A56580E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: v6ops - Requested sessions have been scheduled for IETF 93 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, 27 Jun 2015 01:08:44 -0000 --Apple-Mail=_2500BB4E-64A3-46DF-8DFC-47B37A56580E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI - timing for the joint meeting between v6ops and sunset4. > Begin forwarded message: > > From: "\"IETF Secretariat\"" > Subject: v6ops - Requested sessions have been scheduled for IETF 93 > Date: June 26, 2015 at 4:55:10 PM PDT > To: > Cc: , , > > Dear Fred Baker, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > v6ops Session 1 (2:00:00) > Friday, Morning Session I 0900-1130 > Room Name: Grand Hilton Ballroom size: 300 > --------------------------------------------- > v6ops Session 2 (2:00:00) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Congress Hall II size: 400 > --------------------------------------------- > > > Special Note: Joint Session with SUNSET4 > > > Request Information: > > > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker > > Number of Sessions: 2 > Length of Session(s): 2 Hours, 2 Hours > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: opsec softwire homenet pcp 6man aqm dclcrg sunset4 nvo3 > Second Priority: tsvwg tsvarea intarea mif lmap > Third Priority: ospf rtgwg isis opsawg > > > Special Requests: > > --------------------------------------------------------- > --Apple-Mail=_2500BB4E-64A3-46DF-8DFC-47B37A56580E 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 iQIVAwUBVY33l0ayAOS/EQ8MAQLoJxAAjQzLpqmefCBMRA8GQcmQGaPhCmYu2Gph UAnab26UCfHxGK2/TumybBrLaZTiRB5UT5ziPFbvShq67pwtOgCanLAX09TgYKOr MBWC87n60R0aqSKRXxIsWdK3fPrpAlv478wWbhmO2fn+jZzK6Hq2phFVMz+X0JD6 U99Mg/mkXNlstukSm/i/YQ0xCuGXIF7FneFFtBTaSLh1uMLVZpcAxW1zKulvKIHH BgoxG5eOjEQNoQzWzLi+3Zlq2/wecn99I1YqOGB4pwkGj2JdVHyh646SCsut1XdX TDWA34ID8WnXwDuHbQDOGxlgon/FBNvtqxifclt669A8JpgnlXbLt0bdLbNqJKRy 9pw6lJREMuQkpRh/8sZ+aPeX8rFZcM+y3p8P8ew0oP1sjRk20+D0XvN1e6zPxdUF D4FBVpycFl5OkdTKJnVjGdMcgU9VdOJYcavjZJYrjui6zdseaTx/b+tIHnod03Ml vwkRux2TrCtlTDwLS+mhwYGQl/EmDFOhSoX7ASa22DuafEDO2BUPpoC2vrgVErw1 4SDd5qrKQFzIaMPNVGr9Ph8HUSbJvCcda5GIz3J/24SntbpQEvYaXcdkLPMOJNSv hFc0T0OkAuo0/0CLUx9i0GRzSgVxmRIdb7tjtZLfuat9NHL+WFfPlN7GLCgosOMt e14UC3eYios= =lnpO -----END PGP SIGNATURE----- --Apple-Mail=_2500BB4E-64A3-46DF-8DFC-47B37A56580E-- From nobody Sat Jun 27 01:35:14 2015 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 CD2441B325C for ; Sat, 27 Jun 2015 01:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 AzJV3sD6jS3S for ; Sat, 27 Jun 2015 01:35:11 -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 E40EE1B2A07 for ; Sat, 27 Jun 2015 01:35:10 -0700 (PDT) Received: (qmail 46199 messnum 6080532 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 27 Jun 2015 08:35:09 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail04.svc.cra.dublin.eircom.net (qp 46199) with SMTP; 27 Jun 2015 08:35:09 -0000 Received: from [192.168.1.2] ([86.43.35.194]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id lLb51q00J4BK5ly01Lb9QF; Sat, 27 Jun 2015 09:35:09 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: <30B46C6D-5676-4E12-88FE-D6EBFA0D6793@apple.com> Date: Sat, 27 Jun 2015 09:35:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <378DC402-7760-4846-8AA5-D3D88339FB30@eircom.net> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <6536E263028723489CCD5B6821D4B21303ECB135@UK30S005EXS06.EEAD.EEINT.CO.UK> <30B46C6D-5676-4E12-88FE-D6EBFA0D6793@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Vividh Siddha , v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 27 Jun 2015 08:35:13 -0000 > On 26 Jun 2015, at 19:40, David Schinazi wrote: >=20 > Nick, >=20 > Sorry about the confusion, "bringing up IPv4 specifically" was = speculation on my end. > I did mean a separate APN that could be used for hotspots and/or = systems that do not support IPv6. > To support an IPv4-only device on a personal hotspot from an IPv6-only = iOS handset, we would need some > type of translation from v4 to v6 on the iOS device. We currently do = not provide that. >=20 > Thanks, > David David, Does/could iOS allow this? Handset APN name =3D Hotspot APN name but with Handset APN protocol =3D IPv6-only & Hotspot APN protocol =3D IPv4-only Best regards, Ross= From nobody Sat Jun 27 02:40:26 2015 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 8EF131B3316 for ; Sat, 27 Jun 2015 02:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pr3X7ddn-c55 for ; Sat, 27 Jun 2015 02:40:23 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569771AC439 for ; Sat, 27 Jun 2015 02:40:23 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so62489948wic.1 for ; Sat, 27 Jun 2015 02:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RGlJhmfQQ02ZEtXF56kPG6rehSyIe0Uj7qvGw2vzUU8=; b=FuPsGrVLPOk/mF618L4f9vAIJ1oXyyXXlIWo+6YdrtjcMcyhNAyolTIiGRhISWAtld fworktY1DaTzJatIX4lz8HrWAxI0SELVgonF09Zaot0wVNOm1ShvE9LcdBUQD8+9wn9u iO+5bAP9RWqTybRiqPnAplD1Xk1x34EzuXtHr4INP7jwD41oS3Tsdg8TDT8i9ZEcx1Uk uWaash33ACsEpJl+BxX3+SmmX+iCHiicUaVpeDERhYJfCWyd7xItksQFx0hl/WB+I1yI IPmf7HDbmy+zR/8fwawfyQIkwlOcv2pv3QE9nmh8TU2471KLoV7iEcKmR+n17Y8pznww bVJA== 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:from:date :message-id:subject:to:cc:content-type; bh=RGlJhmfQQ02ZEtXF56kPG6rehSyIe0Uj7qvGw2vzUU8=; b=OTWNuXPDvzZDfBqPtqH/aiLWr90xVRxgXjM9+aLDVZekp2NRuV6as4L6sDFVGJj6J8 JSzS7cG8gqaBDkT3yyj6qJyIM2ONvpovJbrWnMBp7w5zdqATzbq0dZ/LKP05Pl/fhfdY o6pMoeU19KOZyZPMV3rkYXHFZjv+L8FvMcXPmZ7sa/sM4UIfO5x1TdEXw4xdnZKkGpWn z3S95UqNZ9iQVyiGCQSl9zzX9BT6XDUoHfacYK39fqEnA+qYeQtIJK/V2BKR3YT8C5w5 qmDXjzOW4UXz7oGwA7NndCuU7e2Una4IWrkbVzUTAGV2SPVZFV+kOlGc0FN7hOzIwD4o 4eXg== X-Gm-Message-State: ALoCoQmrhZ4xBYiHKRKg01naSKZ77jyDgrq4jXKMDlhJzKCtFqvuEw6oB886nxsp5gt3jJJiEce8 X-Received: by 10.194.11.73 with SMTP id o9mr10883689wjb.116.1435398022042; Sat, 27 Jun 2015 02:40:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Sat, 27 Jun 2015 02:40:02 -0700 (PDT) In-Reply-To: <79C25286-FC91-490F-8323-9550EAC0911B@cisco.com> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <79C25286-FC91-490F-8323-9550EAC0911B@cisco.com> From: Erik Kline Date: Sat, 27 Jun 2015 18:40:02 +0900 Message-ID: To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Vividh Siddha , "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 27 Jun 2015 09:40:24 -0000 > I have long thought Apple's implementation of Happy Eyeballs is awesome. > Tweaking the algorithm's built-in fudge factor to trend more towards IPv6 > would make it more consistent with other OSs and applications (which give > 200-300ms Happy Eyeballs head start to IPv6, which is similar to the fudge > factor done by Apple). Myself, I would like the fudge factor to be > configurable via sysctl or at least viewable via netstat (or similar). As > it is, it is difficult to understand why a system is heavily preferring IPv4 > or IPv6, and when it will give up; disconnecting and reconnecting the > network is a harsh troubleshooting step for other traffic. I *think* I've been having some moderate success with "route change -inet 0.0.0.0 -rtt 5000000", but it's very hard to be sure...maybe I've been lucky enough to be on really good IPv6 networks. :) From nobody Sat Jun 27 04:47:11 2015 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 0A6621ACEEC for ; Sat, 27 Jun 2015 04:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 g0ZlzyQp2fXa for ; Sat, 27 Jun 2015 04:47:07 -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 E65DC1ACEEF for ; Sat, 27 Jun 2015 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=141; q=dns/txt; s=iport; t=1435405623; x=1436615223; h=date:from:message-id:to:subject:cc; bh=p9yCtOp3DGgO6m/emrO/beMqOchI9W+hfY31rz8MY+E=; b=DRUejnbf3jUu6Cf4z3otFIbulOGxRc2Z5NWjl1k+Z6P4GgFF2CAa8TJe 88Q8+5h90/qotiKp+zu6XP8NjQMKTUksRxWB71l4OvK6hS3JIB86+pehC wZMeaAurhAOfhlEAYQr+u2k3+rr95F3xSueKEW06aVwXSsQw+U8hH6U5m 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWPACHjI5V/4kNJK1bgxFUYK5TAY5UCYFmhW8JgTQ4FAEBAQEBAQGBCkEBAgEBg199PDSJDwENzksBAQEHAQEBAQEdi0qFBh2EFQWNAIcEhFmINkKDT5JwJoQagxcBAQE X-IronPort-AV: E=Sophos;i="5.13,689,1427760000"; d="scan'208";a="10795904" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jun 2015 11:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5RBl2Vc024553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jun 2015 11:47:03 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 t5RBl1Qf016486; Sat, 27 Jun 2015 04:47:01 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t5RBl19P016483; Sat, 27 Jun 2015 04:47:01 -0700 Date: Sat, 27 Jun 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-vyncke-v6ops-ipv6-only-thin-clients@tools.ietf.org Subject: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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, 27 Jun 2015 11:47:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-ipv6-only-thin-clients. Please take a look at it and comment. From nobody Sat Jun 27 13:00:34 2015 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 A2CBD1A893F for ; Sat, 27 Jun 2015 13:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 asKI92nunQ9t for ; Sat, 27 Jun 2015 13:00:30 -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 628A71A8943 for ; Sat, 27 Jun 2015 12:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2362; q=dns/txt; s=iport; t=1435435153; x=1436644753; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NP7byn+svlvL5Kq22AW9eK2MN7wvuACPcJdmWfvsLNQ=; b=MFyyXOt8aoZn3c9YkgqJgGVm/4esBHAQaTUExCPSukZAboX6GOfEU4gL vWhR7mpfvwTDnp2Hs8pVsMDnC6ZE5bk9zW7qAyPRhuWzpMPNT40cj1KcS DV8cDu1cwCVcKMYtmr3BJgnZz9RFHVBhfDvCfIhEEVw3V3EaIm7DJabmy c=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ClAwAiAI9V/4wNJK1bgxFUXwa9JgmBZoV4AoEpOBQBAQEBAQEBgQqEIgEBAQMBeQULAgEIGC4yJQIEDgUOiBkIDc5PAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhQYHgxeBFAWUBAGCJIFQZIZ8gTpCg0+DDYwGg10mg3pvgUaBAgEBAQ X-IronPort-AV: E=Sophos; i="5.13,690,1427760000"; d="asc'?scan'208"; a="5205711" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jun 2015 19:59:12 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5RJxC7J001622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jun 2015 19:59:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sat, 27 Jun 2015 14:59:12 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients Thread-Index: AQHQsRO8zVJQgUZZwUaDPU5uUlzYjw== Date: Sat, 27 Jun 2015 19:59:11 +0000 Message-ID: <4C545B41-FE57-4B99-9635-B02BE22CC1BA@cisco.com> References: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> In-Reply-To: <201506271147.t5RBl19P016483@irp-lnx1.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.123] Content-Type: multipart/signed; boundary="Apple-Mail=_F84B8BFA-0F63-46ED-8277-11B737D7C52D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-vyncke-v6ops-ipv6-only-thin-clients@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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, 27 Jun 2015 20:00:32 -0000 --Apple-Mail=_F84B8BFA-0F63-46ED-8277-11B737D7C52D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 27, 2015, at 4:47 AM, Fred Baker (fred) wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/html/draft-vyncke-v6ops-ipv6-only-thin-clients. = Please take a look at it and comment. You have seen my comments about the developing agenda for IETF 93. This = is a draft that I'm specifically looking for feedback on. If there is = interest in the working group, we may have a few minutes to discuss it = f2f; in any event, I think it needs discussion on the list, and I'd be = happy to see it discussed somewhere else if that works better. The draft is a quick read, and I suspect covers only the most glaring = issues in IPv6-only networks. Folks that are running IPv6-only handsets = in mobile networks are dealing with various issues, no doubt, and we = have several wireline networks that are experimenting with IPv6-only = with an IPv4 overlay. What are the IPv6 issues (not IPv4 issues) that we = are seeing with hosts in IPv6-only networks? Your comments please... --Apple-Mail=_F84B8BFA-0F63-46ED-8277-11B737D7C52D 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 iQIVAwUBVY8AjkayAOS/EQ8MAQIBZQ//emF5aLHvs558IYHsECR11B3qarGkgnmo Jb+Qo6Wr5qj+/HlBOFvXwl49K1WhOl3ZjQ8Uf2YNRMbB3H0HHLcZ/dkXYSO3uC/R jNKxW6fqQAj3mgYpFAZ/hCLRGEFni1CDhd+gM53gDtiZHKLDtyXUxdhHhXAELbX8 g8OXDfQSJ3mI6+eaGaUw0JaHSYSeTXdbe9DbUMjwDQ+DUTyFj9TjPyk2/20zc399 hayrODCzN6EnjmEgHR3J5Q10YBIc9OPDbJdTj03w2VoiBjfCZvKgs+2fL6eOY0R0 VHAcKf7Y1aW57CoJih8A2Od6nNUW9ZvmuljJZS1IJl0JT3yZqyIrdGneiWuyvJF4 xCoN0TSoavJirPSTucue0OCr0yxOlsqTglwNiMOm6ZT3bCNi6c28sv6oocNcG348 yZMAcl7StksScgw9q91wirn5DW+lEC6x9IGqJxM8IVdfbv5Mt13ocSB7RbGiOQPy QGoSgsZYvd3a8PXk3F7Df8G9ObfbGUzx016w1lCOG9oNfBOnN6WNt4eLegSi6MGc jC4MFr8ytLOfZgWuMhrNc7bz0EmeWHz0NSEDbpWFPY0R0y8jBD3a3Uu/8z/NNfhh QIKcp0poqt2Kxpr3ABTnJwQBC2qOR9PNPFkGgUdXcaQCKHi04KrvMjn+toavKfUu lvjnPvwtR20= =nWhg -----END PGP SIGNATURE----- --Apple-Mail=_F84B8BFA-0F63-46ED-8277-11B737D7C52D-- From nobody Sat Jun 27 16:20:54 2015 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 8E0701ACC89 for ; Sat, 27 Jun 2015 16:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vRnwdDGkq7se for ; Sat, 27 Jun 2015 16:20:50 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD1C1AC3FB for ; Sat, 27 Jun 2015 16:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1843; q=dns/txt; s=iport; t=1435447249; x=1436656849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QJKkQp3Sl1FJa1IzpQzGnijF9/cU+mSHJWmAIcvzURk=; b=dq7Cz1LF4nmqq/yr89755WivcusbHjQ5EUTk/2OOgRAkIbNvBdZQuq+J 1T1cG8VktL3e8VqknnBQax2Sa/T2i4wbOwMOiPNygXv+9FmT6ntwvCeSr o4TNPacF+2+4FmJpKnagrPaKn9lKnRv9K+xC7Gi1fSFLYOkFtSd/RpuvS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmAwA1L49V/5BdJa1bgxFUXwa9JgmBZoV4AoElOBQBAQEBAQEBgQqEIgEBAQMBOj8FBwQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIiB8IDc4pAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhFUxBwaDEYEUBZQEAYRYiDZCg0+DDYwGg10mg3pvgUaBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,691,1427760000"; d="scan'208";a="163533426" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 27 Jun 2015 23:20:49 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5RNKnMi028253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jun 2015 23:20:49 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 27 Jun 2015 18:20:48 -0500 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , v6ops list Thread-Topic: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients Thread-Index: AQHQsM8JGymCZ6zFa0y/8W6u8YSFe53BGauA///e0rA= Date: Sat, 27 Jun 2015 23:20:47 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168AC6EE@xmb-rcd-x06.cisco.com> References: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> <4C545B41-FE57-4B99-9635-B02BE22CC1BA@cisco.com> In-Reply-To: <4C545B41-FE57-4B99-9635-B02BE22CC1BA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-vyncke-v6ops-ipv6-only-thin-clients@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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, 27 Jun 2015 23:20:53 -0000 The Preboot section needs more work. Only if the deployment does not inclu= de a router which sends an RA, does the preboot use DHCPv6. Magically, th= e node would know to initiate DHCPv6 and preboot... If the deployment incl= udes a router, the node can generate a global IPv6 address using SLAAC and = then use tftpv6 to fetch its OS tar ball and be done. =20 Maybe when we have at least 5-6 serious issues collected we can consider th= e document for v6ops WG adoption. Thanks, Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Saturday, June 27, 2015 3:59 PM To: v6ops list Cc: draft-vyncke-v6ops-ipv6-only-thin-clients@tools.ietf.org Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients > On Jun 27, 2015, at 4:47 AM, Fred Baker (fred) wrote: >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v= 6ops-ipv6-only-thin-clients. Please take a look at it and comment. You have seen my comments about the developing agenda for IETF 93. This is = a draft that I'm specifically looking for feedback on. If there is interest= in the working group, we may have a few minutes to discuss it f2f; in any = event, I think it needs discussion on the list, and I'd be happy to see it = discussed somewhere else if that works better. The draft is a quick read, and I suspect covers only the most glaring issue= s in IPv6-only networks. Folks that are running IPv6-only handsets in mobil= e networks are dealing with various issues, no doubt, and we have several w= ireline networks that are experimenting with IPv6-only with an IPv4 overlay= . What are the IPv6 issues (not IPv4 issues) that we are seeing with hosts = in IPv6-only networks? Your comments please... From nobody Sat Jun 27 16:54:18 2015 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 F02441ACDEB for ; Sat, 27 Jun 2015 16:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hnaVtI7wpOOU for ; Sat, 27 Jun 2015 16:54:15 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833D71ACDF1 for ; Sat, 27 Jun 2015 16:54:15 -0700 (PDT) Received: by paceq1 with SMTP id eq1so86159515pac.3 for ; Sat, 27 Jun 2015 16:54:15 -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=wuNCPBKzw+VNRkkODj1bZBLcjI3ONHLS58gQpErJyks=; b=rejaVd2x1lsMirF+ClYKIlc86nQWcON4C7+UC/mgt/v3eX5ntJ+Ep8cFMJboiEL3fj Id1H0czLbJYI8ai5R1sjoum7ObCXCfNI4oOm5AWZdV0SOJFqz38cid3xjtH9RSGk1UT8 GYB4WUk2odm1MUr5sOI/0KVwbUr9Umzus1/klVke0YZ8wNiBp+vjIL39lbMEVhtM8W5J 9bsaS4qQbjJcPQqHcOTlD5wLPgjCnEkQ/Yf1wLT5fYD+BheH2HzvYbGWoOI0l9LqYzzy 3dCe/QliMdiUHN62E1sEmi52p7Zf3m9f7gN+8JVgr9LTIid1Y8pWSB9ZDsL2tQcrpGIP 88Lg== X-Received: by 10.70.129.73 with SMTP id nu9mr17232655pdb.166.1435449255235; Sat, 27 Jun 2015 16:54:15 -0700 (PDT) Received: from ?IPv6:2406:e007:7d57:1:28cc:dc4c:9703:6781? ([2406:e007:7d57:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id cz1sm1369120pdb.44.2015.06.27.16.54.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2015 16:54:13 -0700 (PDT) Message-ID: <558F37A1.101@gmail.com> Date: Sun, 28 Jun 2015 11:54:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops list References: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> <4C545B41-FE57-4B99-9635-B02BE22CC1BA@cisco.com> <75B6FA9F576969419E42BECB86CB1B89168AC6EE@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89168AC6EE@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-vyncke-v6ops-ipv6-only-thin-clients@.ietf.org Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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, 27 Jun 2015 23:54:17 -0000 > 1. Wake-on-Lan ... > for a specific host. This is called the magic packet: with the > Ethernet payload having somewhere 6 bytes containing 0xFF followed by > 16 times the network interface datalink-layer address. How is this going to work with surveillance-averse clients that change their MAC address from time to time? I think wake-on-lan is going to need a complete rethink (including IPv6, of course) because of this. It seems to me that to solve this *and* the PXE issue, there's going to end up being some requirement for the thin client to wake itself up periodically and execute some sort of discovery process. (Something we are going to need in the Anima WG, too, IMHO.) Regards Brian From nobody Sun Jun 28 06:11:20 2015 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 D7E401B2CD3; Sun, 28 Jun 2015 06:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sUyAkm1lzaVZ; Sun, 28 Jun 2015 06:11:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0331C1B2CCF; Sun, 28 Jun 2015 06:11:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150628131116.4388.94905.idtracker@ietfa.amsl.com> Date: Sun, 28 Jun 2015 06:11:16 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-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: Sun, 28 Jun 2015 13:11:18 -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 : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments Author : Tore Anderson Filename : draft-ietf-v6ops-siit-dc-01.txt Pages : 23 Date : 2015-06-28 Abstract: This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 when reaches the IDC operator's network infrastructure. From that point on, it is treated just as if it was traffic from any other IPv6-capable end user. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-siit-dc-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 Sun Jun 28 06:11:38 2015 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 704DC1B2CDF; Sun, 28 Jun 2015 06:11:34 -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 9y63lmZ1Vn2P; Sun, 28 Jun 2015 06:11:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C78A1B2CE0; Sun, 28 Jun 2015 06:11:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150628131128.4388.53653.idtracker@ietfa.amsl.com> Date: Sun, 28 Jun 2015 06:11:28 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-2xlat-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: Sun, 28 Jun 2015 13:11:34 -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 : SIIT-DC: Dual Translation Mode Authors : Tore Anderson S.J.M. Steffann Filename : draft-ietf-v6ops-siit-dc-2xlat-01.txt Pages : 17 Date : 2015-06-28 Abstract: This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Centre Environments architecture (SIIT-DC), which allows applications, protocols, or nodes that are incompatible with IPv6, and/or Network Address Translation to operate correctly in an SIIT-DC environment. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency. The reader is expected to be familiar with the SIIT-DC architecture described in I-D.ietf-v6ops-siit-dc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-siit-dc-2xlat-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 Sun Jun 28 12:50:26 2015 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 6BBED1A219F; Sun, 28 Jun 2015 12:50:25 -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 yLkvA9Raoimz; Sun, 28 Jun 2015 12:50:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E911A21A1; Sun, 28 Jun 2015 12:50:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150628195023.4505.51892.idtracker@ietfa.amsl.com> Date: Sun, 28 Jun 2015 12:50:23 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-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: Sun, 28 Jun 2015 19:50:25 -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 : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) Authors : Matt Byerly Matt Hite Joel Jaeggli Filename : draft-ietf-v6ops-pmtud-ecmp-problem-03.txt Pages : 8 Date : 2015-06-28 Abstract: This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-pmtud-ecmp-problem-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 Sun Jun 28 19:22:02 2015 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 17AD41B2E40 for ; Sun, 28 Jun 2015 19:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.802 X-Spam-Level: *** X-Spam-Status: No, score=3.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 mkQqojl_mU8R for ; Sun, 28 Jun 2015 19:22:00 -0700 (PDT) Received: from nm45-vm0.bullet.mail.ne1.yahoo.com (nm45-vm0.bullet.mail.ne1.yahoo.com [98.138.121.64]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71271B2E3D for ; Sun, 28 Jun 2015 19:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1435544519; bh=nPwvn3NyT5yrW/hByUXno9DQfZcF6sCkz8/xQzeVBEA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=F1XACoutjSJJJh24OGD5OEtRwJxYQXUPPb0r0HjZesoV67MN2GZhkqeBU7nZOTbD4sTRkokIOmftIhK/5g7UiMzhwb7Ik2dBhwtPK2BqYvEHDMra7KUq5VQ1fyYZUFZA4CFHmnNZiDF4P/BSGtBMowUQLMlVCHyHByDKds7BTrEU/18t+a+nYVEulr41RWQ6enzA0nyKEiGtcroPh50ndB2O8kTb5rXrc2mOUz8QUQLMMm98H3HdM17VyqXFik2v8QF4YTPMDhrheuc2t69plmfZwjjryL9HsLqe4lseDXOoc93nlxuDjx8xfQrSgBWFt0Mxr4+U0lsuo2O/Kqa1qw== Received: from [127.0.0.1] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2015 02:21:59 -0000 Received: from [98.138.100.115] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2015 02:19:10 -0000 Received: from [98.139.170.180] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2015 02:19:10 -0000 Received: from [98.139.212.227] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 29 Jun 2015 02:19:10 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 29 Jun 2015 02:19:10 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 630298.60058.bm@omp1036.mail.bf1.yahoo.com X-YMail-OSG: QyaSgvIVM1kD1Jp.bBpZGjl2EsG_aDRL4B7umhizuR01m3BQZY2.RQysGcyYeUI 3jVpgxYu2HjYawRymjrCyaMQWwu7850eo2ko..H9OVLQpkabEpbVi.IP0TJX3FCfUocXWKQMz77w jQzXWLDk0Gz3eWX_bpi8kAreLRmR52DSCajj0iaE63awMvY1nmqUFbJhjs7p.4OyYq_t52.uuT0V eNbnb0KmLvwDugHj60p2l8nvubJpVD7L3X2Qc5wGymo5fcQ.n_W0XQkoDOt._c.whoZZq7b.xTG2 xWNZ8CnWEH.MnZU.FAamG0pg_KXCUa_nZIa15H4tEawbPja2bGlZXAoRAvNzsEi9nTVXZDHzom6P 54hwUU4.Qf1t_LdZkZK9VeI9ujV0leOMDxgeudnEZAPtCZjwodkihEV0jxEBCXXT6FUCWzrAklox pjktsTtrE9kSdA3VYnC1yaMltMTUcuG5t8mqzg1V6Qpkb_lw6xPhWUWcSPtWUS4wBwdM94LevxRR r1xXiJhqGww.QbZlPAYYBJVlVbEwx Received: by 66.196.80.147; Mon, 29 Jun 2015 02:19:10 +0000 Date: Mon, 29 Jun 2015 02:19:09 +0000 (UTC) From: Mark ZZZ Smith To: "v6ops@ietf.org" Message-ID: <521433567.1631702.1435544349087.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> References: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1631701_176801018.1435544349083" Archived-At: Cc: "draft-vyncke-v6ops-ipv6-only-thin-clients@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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: Mon, 29 Jun 2015 02:22:01 -0000 ------=_Part_1631701_176801018.1435544349083 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Some thoughts/comments: Regarding WoL, at least one of my Wifi NICs supports it, so it isn't exclus= ive to wired links. I don't know much about it, I've discovered it because = I've wanted to save device power and therefore switch it off. According to = some Internet searching it is more generally known as "Wake on Wireless LAN= " or "WoWLAN". "1.3. =C2=A0Mitigation" "For example, to reach all nodes in 2001:db8::/64, let's =C2=A0 =C2=A0configure a static Neighbor Cache entry for 2001:db8::cafe:c0:= ffee as=C2=A0 =C2=A0ff-ff-ff-ff-ff-ff." I think it would be better to use the IPv6 link-layer "all nodes" multicast= address of 33:33:00:00:00:01 for this. Ideally, in an IPv6 only network, N= ICs could drop link-layer broadcasts and perform an amount of multicast add= ress filtering. ... "2. =C2=A0opening a door to a denial of service attack: a remote hostile=C2= =A0 =C2=A0 =C2=A0 =C2=A0party could keep sending packets this is specific u= nicast address=C2=A0 =C2=A0 =C2=A0 =C2=A0forcing all hosts to stay awake, h= ence wasting electrical energy.=C2=A0 =C2=A0 =C2=A0 =C2=A0As this address i= s a unicast address which does not belong to any=C2=A0 =C2=A0 =C2=A0 =C2=A0= physical host on the layer-2 domain, then all nodes will silently=C2=A0 =C2= =A0 =C2=A0 =C2=A0discard this packet at the layer-3." This reads to me as though it is being seen as an IPv6 specific threat, whe= re as I'd consider it to also be a threat in an IPv4 network. If it is not = seen as an IPv4 threat because of RFC1918 addresses, then I think the equiv= alent mitigation for IPv6 would be to limit the ability to wake devices by = only allowing/using ULA addresses for WoL magic destinations (i.e., devices= would still have global addresses, but a global address would not be a mag= ic WoL address.) Regards,Mark. ------=_Part_1631701_176801018.1435544349083 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Some thoughts/comments:



Regarding WoL,= at least one of my Wifi NICs supports it, so it isn't exclusive to wired l= inks. I don't know much about it, I've discovered it because I've wanted to= save device power and therefore switch it off. According to some Internet = searching it is more generally known as "Wake on Wireless LAN" or "WoWLAN".=


"1.3.  Mitigation"

"For example, to reach all nodes in 2001:db8::/64, let's
   configure= a static Neighbor Cache entry for 2001:db8::cafe:c0:ffee as
   f= f-ff-ff-ff-ff-ff."

I think it would be better to use the IPv6 link-layer "= all nodes" multicast address of 33:33:00:00:00:01 for this. Ideally, in an = IPv6 only network, NICs could drop link-layer broadcasts and perform an amo= unt of multicast address filtering.

...

"2.  opening a door to a= denial of service attack: a remote hostile
       party = could keep sending packets this is specific unicast address
    &nb= sp;  forcing all hosts to stay awake, hence wasting electrical energy.=
&= nbsp;      As this address is a unicast address which does n= ot belong to any
       physical host on the layer-2 doma= in, then all nodes will silently
       discard this pack= et at the layer-3."

This reads to me as though it is being seen as an IP= v6 specific threat, where as I'd consider it to also be a threat in an IPv4= network. If it is not seen as an IPv4 threat because of RFC1918 addresses,= then I think the equivalent mitigation for IPv6 would be to limit the abil= ity to wake devices by only allowing/using ULA addresses for WoL magic dest= inations (i.e., devices would still have global addresses, but a global add= ress would not be a magic WoL address.)

Regards,
Mark.



<= /div> ------=_Part_1631701_176801018.1435544349083-- From nobody Sun Jun 28 19:35:11 2015 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 36C9A1B2E79 for ; Sun, 28 Jun 2015 19:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.202 X-Spam-Level: *** X-Spam-Status: No, score=3.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, HTML_MESSAGE=0.001, 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 sxvaa1h7eOmz for ; Sun, 28 Jun 2015 19:35:08 -0700 (PDT) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897091B2E78 for ; Sun, 28 Jun 2015 19:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1435545307; bh=ftzhlXUVckEnSAxCKqpUUmvwgOM8on819M8WJlrm6tQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=uAw5SeKJoHO0nL+KOFui/dH42d75ljnEomOWXBxNPzEdkmvul1oFHn+iFLP1tc2zdw4muv5rhEGv1BkASeATelYwsAXb1yoDGKlsYUE1CHurYmfvMUgNtYkS2Ju6OsFjI80kvaX1yh6N3taf8FHhXIu6eEC20CbL5K/owqN5TGK4q7N7SNjWXgk/LQTjTL5+yB0eq2CHqLAWkv7TpI5l5b8uBsRnNkYN5JtmUOzJ6Xcce4MJwxaq9yeuFKOAlbRtBiCVcbDjGfTTAxmCN4igKz25OZRN0yxNLkKxJyrKls+MAnTSnBPV7GNbvWwZpAVxDgM5Rqc8I3/4LGGDUIjUxg== Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2015 02:35:07 -0000 Received: from [98.138.101.128] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2015 02:32:07 -0000 Received: from [98.139.170.178] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2015 02:32:07 -0000 Received: from [98.139.212.233] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 29 Jun 2015 02:32:07 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 29 Jun 2015 02:32:07 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 308838.91488.bm@omp1042.mail.bf1.yahoo.com X-YMail-OSG: xp8v560VM1ntSNIoDj9TmPIaxKcQJ4JeKy9imD99zn2WCeTPNF46i.FwpJT2kLY ntDECtnTXby4vnwJfkkDpGP0m9KR9YZrHhup4TQTMrWMIV4G8P_sDnqpZAXCYeLz0MqIL6tu.Zf_ Q05.E5gaBubd91RWJwF1AkRDtwKECy5Qh3OBsYWfxoH_C1Brqo7PwwN_AEe5CBgi08ugThuyP_IM z6rybuOHXaqYMYIKALXD1Uc7oznEL935RtOqVyqJj2MibEX7pH6Lac.oF.KW9fM.R0H6Pfd_90tk jPkmtejpJKyEqi3ipBNi8_s_BDsriRGg7hHUhJWQFpaA8O2nXThQVvSOpwbXgPl0PSfVKrnYYf0u S8Z4FTHoQqIiyUy9Dhpml5tqRLLMpXlsc3dNJjIb5eqV7FyntRNk6Vsc15T7o61dttdZVW08ulyn RpfH5AmqwZz2LOxRWtdJ0yrRL9YnCSE4LXsqFnB0x03V73vvJk5qPniVSzQlbSYWaAsy9gIg6o55 Rygmip3N0VcJdkhbql9OE2B_28oqWiwgpm2Mmm6D4Vh0fZhy.RGy3b_QDfpg. Received: by 66.196.80.147; Mon, 29 Jun 2015 02:32:06 +0000 Date: Mon, 29 Jun 2015 02:32:06 +0000 (UTC) From: Mark ZZZ Smith To: Brian E Carpenter , v6ops list Message-ID: <1909036931.1601696.1435545126216.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <558F37A1.101@gmail.com> References: <558F37A1.101@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1601695_284066729.1435545126209" Archived-At: Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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: Mon, 29 Jun 2015 02:35:10 -0000 ------=_Part_1601695_284066729.1435545126209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Brian E Carpenter To: v6ops list =20 Cc: draft-vyncke-v6ops-ipv6-only-thin-clients@.ietf.org=20 Sent: Sunday, 28 June 2015, 9:54 Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients =20 > 1.=C2=A0 Wake-on-Lan ... >=C2=A0 =C2=A0 for a specific host.=C2=A0 This is called the magic packet: = with the >=C2=A0 =C2=A0 Ethernet payload having somewhere 6 bytes containing 0xFF fo= llowed by >=C2=A0 =C2=A0 16 times the network interface datalink-layer address. How is this going to work with surveillance-averse clients that change their MAC address from time to time? I think wake-on-lan is going to need a complete rethink (including IPv6, of course) because of this. / As I haven't worked on a network that uses WoL, I was thinking that it mu= st already be pretty onerous to be maintaining a list of devices and their = MAC addresses for WoL purposes.=C2=A0 / There seem to be a number of other WoL methods; here are the list of WoL = packet types/events that can be set using the Linux 'ethtool' utility for a= NIC: --=C2=A0 =C2=A0 =C2=A0 =C2=A0wol p|u|m|b|a|g|s|d...=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Sets Wake-on-LAN options. =C2=A0Not all devices = =C2=A0support =C2=A0this. =C2=A0 The=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 argument =C2=A0to =C2=A0this =C2=A0option =C2=A0is a string of c= haracters specifying=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which = options to enable. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p =C2=A0 Wake on PHY activ= ity=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u =C2=A0 Wake on unicas= t messages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m =C2=A0 Wake on= multicast messages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b =C2= =A0 Wake on broadcast messages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 a =C2=A0 Wake on ARP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 g = =C2=A0 Wake on MagicPacket=E2=84=A2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 s =C2=A0 Enable SecureOn=E2=84=A2 password for MagicPacket=E2=84= =A2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 d =C2=A0 Disable (wake = on =C2=A0nothing). =C2=A0 This =C2=A0option=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clears all previous options. =C2=A0 =C2=A0 =C2=A0 =C2=A0sopass xx:yy:zz:aa:bb:cc=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Sets =C2=A0the =C2=A0SecureOn=E2=84=A2 password. = =C2=A0The argument to this option must=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 be 6 bytes in Ethernet MAC hex format (xx:yy:zz:aa:bb:cc).-- / Looking at the WoL spec referenced, that looks to be the MagicPacket opti= on mentioned above. Perhaps networks using WoL are using more coarse method= s which would continue to work even with changing MAC addresses. / Regards,/ Mark. It seems to me that to solve this *and* the PXE issue, there's going to end up being some requirement for the thin client to wake itself up periodically and execute some sort of discovery process. (Something we are going to need in the Anima WG, too, IMHO.) Regards =C2=A0 Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_1601695_284066729.1435545126209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From: Bri= an E Carpenter <brian.e.carpenter@gmail.com>
To: v6ops list <v6ops@ietf.org>
<= span style=3D"font-weight: bold;">Cc: draft-vyncke-v6ops-ipv6-on= ly-thin-clients@.ietf.org
Sent:<= /span> Sunday, 28 June 2015, 9:54
Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-onl= y-thin-clients

> 1.  Wake-on-Lan
...
>    for a specific host.  This is called the magi= c packet: with the
>    Ethernet payload hav= ing somewhere 6 bytes containing 0xFF followed by
>&nb= sp;   16 times the network interface datalink-layer address.

How is this going to work with surveillance-av= erse clients that change
their MAC address from time to t= ime? I think wake-on-lan is going to
need a complete reth= ink (including IPv6, of course) because of this.

/ As= I haven't worked on a network that uses WoL, I was thinking that it must a= lready be pretty onerous to be maintaining a list of devices and their MAC = addresses for WoL purposes. 

/ There seem to be a number of other WoL methods; here are the list of= WoL packet types/events that can be set using the Linux 'ethtool' utility = for a NIC:
--
    =    wol p|u|m|b|a|g|s|d...
            &= nbsp; Sets Wake-on-LAN options.  Not all devices  support  t= his.   The
              argument  = ;to  this  option  is a string of characters specifying
  &= nbsp;           which options to enable.

           =   p   Wake on PHY activity
           =   u   Wake on unicast messages
          &n= bsp;   m   Wake on multicast messages
              b   Wake on bro= adcast messages
        =       a   Wake on ARP
&n= bsp;             g   Wake on MagicPacket= =E2=84=A2
         =     s   Enable SecureOn=E2=84=A2 password for MagicPacket= =E2=84=A2
              d   Disable (wa= ke on  nothing).   This  option
                  clears al= l previous options.

       sopass xx:yy:zz:aa:bb:cc<= /font>
&nbs= p;             Sets  the  SecureOn= =E2=84=A2 password.  The argument to this option must
     = ;         be 6 bytes in Ethernet MAC hex format (xx:yy:= zz:aa:bb:cc).
--

/ Looking at th= e WoL spec referenced, that looks to be the MagicPacket option mentioned ab= ove. Perhaps networks using WoL are using more coarse methods which would c= ontinue to work even with changing MAC addresses.

/ Regards,
/ Mark.


It seems to me that to solve this *and* the PXE issue, there's go= ing
to end up being some requirement for the thin client = to wake itself
up periodically and execute some sort of d= iscovery process. (Something
we are going to need in the = Anima WG, too, IMHO.)

Regards
  Brian




_______________________________________________
v6ops ma= iling list
v6ops@ietf.org
<= a shape=3D"rect" href=3D"https://www.ietf.org/mailman/listinfo/v6ops" targe= t=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops


------=_Part_1601695_284066729.1435545126209-- From nobody Mon Jun 29 01:32:04 2015 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 10C9C1A8838 for ; Mon, 29 Jun 2015 01:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 bmmCE2awkhUM for ; Mon, 29 Jun 2015 01:32:02 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA881A883C for ; Mon, 29 Jun 2015 01:32:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5T8W0YC011320 for ; Mon, 29 Jun 2015 10:32:00 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6E449201620 for ; Mon, 29 Jun 2015 10:35:02 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 63C762015FA for ; Mon, 29 Jun 2015 10:35:02 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5T8Vwf0007365 for ; Mon, 29 Jun 2015 10:31:59 +0200 Message-ID: <5591027E.5040005@gmail.com> Date: Mon, 29 Jun 2015 10:31:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> In-Reply-To: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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, 29 Jun 2015 08:32:04 -0000 > IPv6-Only for Wired Thin-Clients Examples of recent wired thin clients please? I am left at the point where HP's Apollo workstation and Sun's network computers disappeared from the market? The initial issues presented - "Wake-on-LAN" and "PXE" - are valid in my thick laptop as well. draft says: > In IPv6, there is no directed broadcast for good reason. Only a > link-local multicast group such as ff02::1 for all link-local hosts. > So, the magic packet for a single host could be sent to this > multicast group, reaching all link-local hosts (as switches and > routers will forward this packet to all ports/interfaces) and waking > up the sleeping node. But, there is no solution for a remote > operator to send this magic packet... A 'directed broadcast' in IPv4 parlance RFC2644, that needs to reach across-the-subnet groups, would mean a classical IPv6 multicast group with global scope. The thin clients on a subnet would join this multicast group before going to sleep. I guess this would work. I guess this would benefit from a registration of particular multicast group. Or otherwise is there a problem in that the magic packet is a non-IP packet? If yes then either we make the magic packet an IP packet (IPv4 and IPv6) or we request IEEE to implement link-layer across-the-subnet multicast, if such a thing could exist. Other issues to be suggested to an IPv6-only draft: a recent SDN implementation absolutely needs IPv4 to make IPv6 work, details on the web. But this may be too high level? Alex Le 27/06/2015 13:47, fred@cisco.com a écrit : > A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-ipv6-only-thin-clients. Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jun 29 01:34:00 2015 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 EFC401A883D for ; Mon, 29 Jun 2015 01:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 A1tlWRbSe-4s for ; Mon, 29 Jun 2015 01:33:56 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7781A8838 for ; Mon, 29 Jun 2015 01:33:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5T8Xrln026973 for ; Mon, 29 Jun 2015 10:33:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 18F80201622 for ; Mon, 29 Jun 2015 10:36:56 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 10A0A200C20 for ; Mon, 29 Jun 2015 10:36:56 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5T8XrAd009709 for ; Mon, 29 Jun 2015 10:33:53 +0200 Message-ID: <559102F1.7090708@gmail.com> Date: Mon, 29 Jun 2015 10:33:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <558F37A1.101@gmail.com> <1909036931.1601696.1435545126216.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1909036931.1601696.1435545126216.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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, 29 Jun 2015 08:33:59 -0000 Le 29/06/2015 04:32, Mark ZZZ Smith a écrit : > > ------------------------------------------------------------------------ > *From:* Brian E Carpenter > *To:* v6ops list > *Cc:* draft-vyncke-v6ops-ipv6-only-thin-clients@.ietf.org > *Sent:* Sunday, 28 June 2015, 9:54 > *Subject:* Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients > > > 1. Wake-on-Lan > ... > > for a specific host. This is called the magic packet: with the > > Ethernet payload having somewhere 6 bytes containing 0xFF followed by > > 16 times the network interface datalink-layer address. > > How is this going to work with surveillance-averse clients that change > their MAC address from time to time? I think wake-on-lan is going to > need a complete rethink (including IPv6, of course) because of this. > > / As I haven't worked on a network that uses WoL, I was thinking that it > must already be pretty onerous to be maintaining a list of devices and > their MAC addresses for WoL purposes. > > / There seem to be a number of other WoL methods; here are the list of > WoL packet types/events that can be set using the Linux 'ethtool' > utility for a NIC: > > -- > wol p|u|m|b|a|g|s|d... > Sets Wake-on-LAN options. Not all devices support > this. The > argument to this option is a string of characters > specifying > which options to enable. > > p Wake on PHY activity > u Wake on unicast messages > m Wake on multicast messages > b Wake on broadcast messages > a Wake on ARP > g Wake on MagicPacket™ > s Enable SecureOn™ password for MagicPacket™ > d Disable (wake on nothing). This option > clears all previous options. That begs for an option 'n' Wake on ND. Alex > > sopass xx:yy:zz:aa:bb:cc > Sets the SecureOn™ password. The argument to this > option must > be 6 bytes in Ethernet MAC hex format (xx:yy:zz:aa:bb:cc). > -- > > / Looking at the WoL spec referenced, that looks to be the MagicPacket > option mentioned above. Perhaps networks using WoL are using more coarse > methods which would continue to work even with changing MAC addresses. > > / Regards, > / Mark. > > > It seems to me that to solve this *and* the PXE issue, there's going > to end up being some requirement for the thin client to wake itself > up periodically and execute some sort of discovery process. (Something > we are going to need in the Anima WG, too, IMHO.) > > Regards > Brian > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jun 29 05:52:03 2015 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 537881A6F38 for ; Mon, 29 Jun 2015 05:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 uN7EFLr8wEbj for ; Mon, 29 Jun 2015 05:52:00 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006781A7028 for ; Mon, 29 Jun 2015 05:51:59 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail11.telekom.de with ESMTP; 29 Jun 2015 14:51:58 +0200 X-IronPort-AV: E=Sophos;i="5.13,698,1427752800"; d="scan'208";a="859392212" Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 29 Jun 2015 14:51:51 +0200 Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 29 Jun 2015 14:51:50 +0200 From: To: , Date: Mon, 29 Jun 2015 14:51:49 +0200 Thread-Topic: [v6ops] Apple and IPv6, a few clarifications - 64share Thread-Index: AdCuetXfuz01EaIrTuunbqkm188AyAD7yryg Message-ID: <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> References: <5587EFDD.6030807@gmail.com> <558AA4F1.8080503@gmail.com> In-Reply-To: <558AA4F1.8080503@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 29 Jun 2015 12:52:02 -0000 Hi, > Android is a linux based os, I dont see why it wouldnt support dhcp-pd? > My linux based non-Android machines do dhcp-pd ok. Have you tried to run DHCP-PD via IPv6-capable USB dongles? The ones that I= know of don't forward DHCPv6 requests to the network. So even if your OS s= upports it, it's most likely that you modem (or its chipset) does not suppo= rt it. --=20 Holger Metschulat=20 Deutsche Telekom Technik GmbH=20 E-Mail: holger.metschulat@telekom.de=20 http://www.telekom.de=20 Erleben, was verbindet.=A0=20 Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtang= aben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken.=20 From nobody Mon Jun 29 06:16:29 2015 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 D0CDA1A9112 for ; Mon, 29 Jun 2015 06:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 gMcYqSYl1pDt for ; Mon, 29 Jun 2015 06:16:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA55F1A9127 for ; Mon, 29 Jun 2015 06:16:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5TDG9Bo013145; Mon, 29 Jun 2015 15:16:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1A6EA202D26; Mon, 29 Jun 2015 15:19:12 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 04885202E20; Mon, 29 Jun 2015 15:19:12 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5TDG7m3009453; Mon, 29 Jun 2015 15:16:09 +0200 To: holger.metschulat@telekom.de, v6ops@ietf.org References: <5587EFDD.6030807@gmail.com> <558AA4F1.8080503@gmail.com> <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> From: Alexandru Petrescu Message-ID: <55914517.4050602@gmail.com> Date: Mon, 29 Jun 2015 15:16:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 29 Jun 2015 13:16:28 -0000 Le 29/06/2015 14:51, holger.metschulat@telekom.de a écrit : > Hi, > >> Android is a linux based os, I dont see why it wouldnt support >> dhcp-pd? > >> My linux based non-Android machines do dhcp-pd ok. > > Have you tried to run DHCP-PD via IPv6-capable USB dongles? The ones > that I know of don't forward DHCPv6 requests to the network. So even > if your OS supports it, it's most likely that you modem (or its > chipset) does not support it. Do you mean USB-Ethernet dongles? No, I have not tried DHCPv6-PD on USB-Ethernet dongles. The modem and chipsets on LTE that I have tried do forward DHCPv6 requests. For example it transmits the DHCPv6 Request and then receives an DHCPv6 Ack from the cellular network containing an IPv6 address. But if I make a DHCPv6 Prefix Delegation request then that is not answered. I guess that hardware which blocks DHCPv6-PD also blocks DHCPv6. Otherwise it would be an intentional blocking of DHCPv6-PD... Alex > From nobody Tue Jun 30 10:07:40 2015 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 C2D091B320E; Tue, 30 Jun 2015 10:07:37 -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 fUbnpYIAC3sb; Tue, 30 Jun 2015 10:07:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 497C41B3212; Tue, 30 Jun 2015 10:07:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150630170735.10187.94327.idtracker@ietfa.amsl.com> Date: Tue, 30 Jun 2015 10:07:35 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-eam-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: Tue, 30 Jun 2015 17:07:37 -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 : Explicit Address Mappings for Stateless IP/ICMP Translation Authors : Tore Anderson Alberto Leiva Popper Filename : draft-ietf-v6ops-siit-eam-01.txt Pages : 18 Date : 2015-06-30 Abstract: This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-eam-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-siit-eam-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/