From jari.arkko@piuha.net Thu Feb 9 23:45:07 2012 Return-Path: X-Original-To: shim6@ietfa.amsl.com Delivered-To: shim6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909E21F86F6 for ; Thu, 9 Feb 2012 23:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlTdOi8xWuXi for ; Thu, 9 Feb 2012 23:45:06 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC521F86F0 for ; Thu, 9 Feb 2012 23:45:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A01402CDC4; Fri, 10 Feb 2012 09:45:04 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKDzW-pIiTkZ; Fri, 10 Feb 2012 09:45:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id F0F1A2CC39; Fri, 10 Feb 2012 09:45:02 +0200 (EET) Message-ID: <4F34CAFE.4030703@piuha.net> Date: Fri, 10 Feb 2012 09:45:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= References: <4EF089CF.5070300@piuha.net> <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es> <4EF33EDB.5010806@piuha.net> <011901ccc0d0$467030f0$d35092d0$@it.uc3m.es> In-Reply-To: <011901ccc0d0$467030f0$d35092d0$@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'marcelo bagnulo braun' , 'shim6' , 'Joe Abley' Subject: Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt X-BeenThere: shim6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SHIM6 Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 07:45:07 -0000 Alberto, I'm returning back to this thread... we should progress the document. Can you provide a revision? I've included some additional answers to your questions below. > Hi Jari, > > [Trimming out all the issues already agreed] > > |> | The source address problem discussed in one paragraph in Section 4 > |> | should be highlighted much earlier. It is a key missing pieces for > |> | Shim6 to > |> work, and > |> | it would be honest to tell this to the reader. Similarly, the > |> | initial > |> contact > |> | issue from Section 5.1.1 should also be highlighted up front. > |> > |> To address this, I suggest moving the current section '3. Addresses > |> and Shim6' after 'Shim6 capabilities'. The result would be: > |> 1. Introduction > |> 2. Deployment Scenarios<- this is a short section which define the > |> topology... which is convenient before discussing all the problems > |> related with the attachment to different providers. > |> 3. Shim6 in Multihomed Nodes<- source address problem 4. Shim6 > |> Capabilities<-- initial contact issue 5. Addresses and Shim6 > |> > |> The 'addresses and Shim6' section does not include problematic issues, > |> so I think there is no problem in placing it later. > |> Do you think this solves the issue? > | > | Perhaps you could solve it in a simpler way, without this much surgery to > | the structure of the document. Just mention the things we need to > highlight > | in the introduction, and you should be fine. > > OK. I undo the position change of the 'address' section. > > I have added some text to the 4th paragraph of the 'introduction': > > " Shim6 provides layer-3 support for making re-homing events > transparent to the transport layer by means of a shim approach. > NEW TEXT ----> > Once > a Shim6 session has been established, the failure detection mechanism > defined for Shim6 allows finding new valid locator combinations in > case of failure, and using these locators to continue the > communication. However, Shim6 does not provide failure protection to > the communication establishment, so if a host within a multihomed > site attempts to establish a communication with a remote host and > selects an address which corresponds to a failed transit path, the > communication will fail. > <--- END OF NEW TEXT > State information relating to the > multihoming of two endpoints exchanging unicast traffic is retained > on the endpoints themselves, rather than in the network. > Communications between Shim6-capable hosts and Shim6-incapable hosts > proceed as normal, but without the benefit of transport-layer > stability. The Shim6 approach is thought to have better scaling > properties with respect to the state held in the DFZ than the IPv4 > approach. > NEW TEXT ----> > In order to successfully deploy Shim6 in a multihomed site, additional > mechanism may be required to solve issues such as selecting the source > address appropriate to the destination and to the outgoing provider, or to > allow the network manager to perform traffic engineering. Such problems are > not specific of Shim6, but are suffered by the hosts of any site which is > connected to multiple transit providers, and which receives an IPv6 prefix > from each of them. Some of these mechanisms are not defined today. > <--- END OF NEW TEXT" > > Do you think this is enough? Fine for me. Modulo Brian's comments (he had a point, maybe you want to revise the above a bit). > | > |> > |> | > |> | Section 5.2 should highlight the fact that transport-layer > |> | solutions are > |> much > |> | more amenable for load balancing solutions, and that work for such > |> | solutions is already ongoing at MP-TCP WG. > |> > |> OK. I add a paragraph at the end of 5.2 saying: > |> "It is worth to note that the use of transport-layer solutions > |> enhanced with mechanisms to allow the use of multiple paths for a > |> transport session are more amenable for achieving load-balancing. One > |> such solution is being developed at the MP-TCP Working Group." > | > | OK. (Maybe "It is worth noting that ...") > > Sure. Changed. > > | > |> > |> | > |> | Section 5.3 should highlight that it is the hosts, not the site > |> | admin > |> that get to > |> | set these bits. In general, the document should highlight more of > |> | the > |> issues > |> | from the perspective of a site admin. Not that that is the only > |> | relevant viewpoint, but the reader should get a balanced view of > |> | the benefits and disadvantages of Shim6. > |> > |> To address this, I have added the following text: > |> At the end of the 5th paragraph of section '2 Deployment Scenarios': > |> " As discussed in > |> Section 4, the site should deliver outgoing packets having a source > |> address derived from the prefix of ISP[i] to that particular > |> provider, in order to prevent those packets to be filtered due to > |> Ingress Filtering [RFC2827] being applied by the providers. It is > |> worth to note that in an scenario such as the one depicted in > |> Figure 1, the paths followed by inbound and outbound traffic are > |> determined to a large extent by the locators in use for the > |> communication. This is not a particular issue of Shim6, but it is > |> common to any deployment in which hosts are configured with > | addresses > |> received from different providers. Traffic Engineering in such > sites > |> will likely involve proper configuration of address selection > |> policies in the hosts, by means of mechanisms such as the ones > |> discussed in Section 4." > |> I think the previous text is early enough to provide a clear > |> indication of the limitations of Shim6 regarding to this. > | > | The text above is fine, but I'm hoping that you do have somewhere other > | text that explains that in Shim6, operator control of hosts does require > extra > | mechanisms that do not currently exist. > > Ummm. The problem related above is common to IPv6 nodes connecting to > multiple providers. Yes > We have a section for this, 'Shim6 in Multihomed Nodes', > in which we comment (following > draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat) that RFC3484-related > configuration should be defined, the possibility of using Extensions to > Router Advertisements through Default Router Preference and More-Specific > Routes to specify the next hop router to use for a given set of > destinations, etc. > I think your comment is addressed in this section. OK > > | > |> > |> At the end of section '3.4. Use of CGA vs. HBA' > |> " There is no current mechanism designed to allow an administrator to > |> enforce the configuration of a CGA or an HBA in a host." > |> > |> Regarding to your comment specific for section 5.3, I have rewritten it > to: > |> > |> "5.3. Traffic Engineering > |> > |> For sites with prefixes obtained from different providers, the > paths > |> followed by inbound and outbound traffic are determined to a large > |> extent by the locators selected for each communication. This is > not > |> a particular issue of Shim6, but it is common to any deployment in > |> which hosts are configured with addresses received from different > |> providers. Traffic Engineering in such sites will likely involve > |> proper configuration of the address selection policies defined by > |> [RFC3484]. > |> > |> Besides, the Shim6 protocol provides some lightweight traffic > |> engineering capabilities in the form of the Locator Preferences > |> option, which allows a host to inform a remote host of local > |> preferences for locator selection. In this way, the host can > |> influence in the incoming path for the communication. This > mechanism > |> is only available after a Shim6 context has been established, and > it > |> is a host-based capability rather than a site-based capability. > |> There is no defined mechanism which would allow use of the Locator > |> Preferences option amongst a site full of hosts to be managed > |> centrally by the administrator of the site." > |> > |> I've checked the rest of the document with 'site admin' hat on, but I > |> did not find a clear target to add more comments. > | > | See above. If all else fails, you could add this somewhere in the > | introduction: > | > | "Also, Shim6 is inherently a host-centric approach. In situations where > there > | is a need for the network manager to control the multihoming behavior for > | traffic engineering reasons, additional mechanisms are needed to > | implement such control from the network manager to the hosts. No such > | mechanisms are defined today." > | > | Or words to that effect. > > One piece of text added to the introduction, included in a comment above, > included this idea: > > "In order to successfully deploy Shim6 in a multihomed site, additional > mechanism may be required to solve issues such as selecting the source > address appropriate to the destination and to the outgoing provider, or to > allow the network manager to perform traffic engineering. Such problems are > not specific of Shim6, but are suffered by the hosts of any site which is > connected to multiple transit providers, and which receives an IPv6 prefix > from each of them. Some of these mechanisms are not defined today." OK > > |> > |> | > |> | Section 7 should indicate if there is any implementation of > |> | deployment experience with these combinations. I'm doubtful on > |> | whether all the ipsec layering mechanisms and so on would actually > |> | work in real implementations without someone having tested such > | combinations. > |> > |> I assume you are referring specifically to discuss deployment > |> experience for the 'Shim6 and Mobile IPv6' subsection, aren't you? > | > | No, I was thinking of all the combinations listed in Section 7. > > I think there are two different cases for this. Some combinations are NOT > RECOMMENDED by the draft. These are > - shim6 and SCTP. > - shim6 and HIP. > - shim6 and NATs: since shim6 security is end-to-end, NATs break Shim6 as > currently defined. > Although it would be nice to have some experimental proof of this... I think > it is easier to accept that, if the analysis is ok, no further experiment is > required. > > The rest combinations are assumed to work. However, since IFAIK there is no > production deployment of Shim6, most of them have not been tested. And even > those tested, have not been tested in 'real' conditions. For this, we have > - shim6 and IPsec and shim6 and MIPv6 (and the three of them). Barre's > implementation to check > - shim6 and SEND. It seems there should be no problem in the interaction, > since both protocols deal with different issues. I'm not aware of any > combined test for them. > - shim6 and NEMO. I'm not aware of any implementation/test of NEMO with > Shim6 > - shim6 and firewalls. There is an implementation (a modification to Linux > netfilter) developed for a Master Thesis from U. of Lovaina: > http://inl.info.ucl.ac.be/system/files/memoire_0.pdf. They analyze several > possible issues that may arise with firewalling shim6 traffic, although all > of them seem to be solved without requiring any protocol modification. The > main problem seems to be the large amount of state that the firewall is > required to store (the locators, context tag, etc. for each shim6 session). > Of course, there is lack of real-world experience, so this conclusions may > not be close to reality. > > So, it is very likely that we could not find info for real tests on many of > these combinations. Would it suffice to write a disclaimer for this section > saying that there is a lack of real experience with most of these > combinations?. Yes, stating lack of information would be fine. Jari > > Regards, > Alberto > > | > |> I will ask Sebastien Barre, which had a MipShim6 implementation, with > |> which I think he successfully tested some of the configurations > |> discussed in the draft, although I'm not sure if IPsec was involved in > the > | tests. > |> > | OK > | > | Jari > > From alberto@it.uc3m.es Fri Feb 10 06:17:12 2012 Return-Path: X-Original-To: shim6@ietfa.amsl.com Delivered-To: shim6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83E721F86F1 for ; Fri, 10 Feb 2012 06:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etnXOFKEx8Z6 for ; Fri, 10 Feb 2012 06:17:11 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2841A21F86D6 for ; Fri, 10 Feb 2012 06:17:10 -0800 (PST) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E696EC2F870; Fri, 10 Feb 2012 15:17:08 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Jari Arkko'" References: <4EF089CF.5070300@piuha.net> <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es> <4EF33EDB.5010806@piuha.net> <011901ccc0d0$467030f0$d35092d0$@it.uc3m.es> <4F34CAFE.4030703@piuha.net> In-Reply-To: <4F34CAFE.4030703@piuha.net> Date: Fri, 10 Feb 2012 15:17:23 +0100 Message-ID: <007301cce7fe$b553f6f0$1ffbe4d0$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQGDOZmzRYcIB0SkvRGwi/BNWMGwMgCBFVc7AUaz2k4Cfcj+iADaULDylqA7pgA= Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18666.006 Cc: 'marcelo bagnulo braun' , 'shim6' , 'Joe Abley' Subject: Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt X-BeenThere: shim6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SHIM6 Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:17:13 -0000 Hi Jari | -----Mensaje original----- | De: Jari Arkko [mailto:jari.arkko@piuha.net] | Enviado el: viernes, 10 de febrero de 2012 8:45 | Para: Alberto Garc=EDa | CC: 'shim6'; 'marcelo bagnulo braun'; 'Joe Abley' | Asunto: Re: AD review of draft-garcia-shim6-applicability-00.txt | =20 | Alberto, | =20 | I'm returning back to this thread... we should progress the document. = Can | you provide a revision? I've included some additional answers to your | questions below. I have just uploaded a new version for the draft, to move it forward: ----- http://www.ietf.org/internet-drafts/draft-garcia-shim6-applicability-03.t= xt A new version of I-D, draft-garcia-shim6-applicability-03.txt has been successfully submitted by Alberto Garcia-Martinez and posted to the IETF repository. Filename: draft-garcia-shim6-applicability Revision: 03 Title: Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6) Creation date: 2012-02-10 WG ID: Individual Submission Number of pages: 26 ----- Some responses inline | =20 | > Hi Jari, | > | > [Trimming out all the issues already agreed] | > | > |> | The source address problem discussed in one paragraph in | > |> Section 4 | should be highlighted much earlier. It is a key | > |> missing pieces for | Shim6 to work, and | it would be honest = to | > |> tell this to the reader. Similarly, the | initial contact | | > |> issue from Section 5.1.1 should also be highlighted up front. | > |> | > |> To address this, I suggest moving the current section '3. | > |> Addresses and Shim6' after 'Shim6 capabilities'. The result = would be: | > |> 1. Introduction | > |> 2. Deployment Scenarios<- this is a short section which define | > |> the topology... which is convenient before discussing all the | > |> problems related with the attachment to different providers. | > |> 3. Shim6 in Multihomed Nodes<- source address problem 4. = Shim6 | > |> Capabilities<-- initial contact issue 5. Addresses and Shim6 | > |> | > |> The 'addresses and Shim6' section does not include problematic | > |> issues, so I think there is no problem in placing it later. | > |> Do you think this solves the issue? | > | | > | Perhaps you could solve it in a simpler way, without this much | > | surgery to the structure of the document. Just mention the = things | > | we need to | > highlight | > | in the introduction, and you should be fine. | > | > OK. I undo the position change of the 'address' section. | > | > I have added some text to the 4th paragraph of the 'introduction': | > | > " Shim6 provides layer-3 support for making re-homing events | > transparent to the transport layer by means of a shim approach. | > NEW TEXT ----> | > Once | > a Shim6 session has been established, the failure detection mechanism | > defined for Shim6 allows finding new valid locator combinations = in | > case of failure, and using these locators to continue the | > communication. However, Shim6 does not provide failure = protection to | > the communication establishment, so if a host within a = multihomed | > site attempts to establish a communication with a remote host = and | > selects an address which corresponds to a failed transit path, = the | > communication will fail. | > <--- END OF NEW TEXT | > State information relating to the | > multihoming of two endpoints exchanging unicast traffic is = retained | > on the endpoints themselves, rather than in the network. | > Communications between Shim6-capable hosts and Shim6-incapable | hosts | > proceed as normal, but without the benefit of transport-layer | > stability. The Shim6 approach is thought to have better = scaling | > properties with respect to the state held in the DFZ than the = IPv4 | > approach. | > NEW TEXT ----> | > In order to successfully deploy Shim6 in a multihomed site, = additional | > mechanism may be required to solve issues such as selecting the = source | > address appropriate to the destination and to the outgoing = provider, | > or to allow the network manager to perform traffic engineering. = Such | > problems are not specific of Shim6, but are suffered by the hosts = of | > any site which is connected to multiple transit providers, and = which | > receives an IPv6 prefix from each of them. Some of these mechanisms = are | not defined today. | > <--- END OF NEW TEXT" | > | > Do you think this is enough? | =20 | Fine for me. Modulo Brian's comments (he had a point, maybe you want = to | revise the above a bit). OK. To address Brian's comment, I have added a new line to the end of = the previous paragraph, which says 'However, note that once a Shim6 session has been established, Shim6 = reduces the impact of these problems, because if a working path exists, Shim6 = will find it.' [Trimming out agreed parts] | =20 | > | > |> | > |> | | > |> | Section 7 should indicate if there is any implementation of = | | > |> deployment experience with these combinations. I'm doubtful on = | | > |> whether all the ipsec layering mechanisms and so on would = actually | > |> | work in real implementations without someone having tested = such | > | combinations. | > |> | > |> I assume you are referring specifically to discuss deployment | > |> experience for the 'Shim6 and Mobile IPv6' subsection, aren't = you? | > | | > | No, I was thinking of all the combinations listed in Section 7. | > | > I think there are two different cases for this. Some combinations = are | > NOT RECOMMENDED by the draft. These are | > - shim6 and SCTP. | > - shim6 and HIP. | > - shim6 and NATs: since shim6 security is end-to-end, NATs break = Shim6 | > as currently defined. | > Although it would be nice to have some experimental proof of = this... I | > think it is easier to accept that, if the analysis is ok, no = further | > experiment is required. | > | > The rest combinations are assumed to work. However, since IFAIK = there | > is no production deployment of Shim6, most of them have not been | > tested. And even those tested, have not been tested in 'real' | > conditions. For this, we have | > - shim6 and IPsec and shim6 and MIPv6 (and the three of them). = Barre's | > implementation to check | > - shim6 and SEND. It seems there should be no problem in the | > interaction, since both protocols deal with different issues. I'm = not | > aware of any combined test for them. | > - shim6 and NEMO. I'm not aware of any implementation/test of NEMO | > with | > Shim6 | > - shim6 and firewalls. There is an implementation (a modification = to | > Linux | > netfilter) developed for a Master Thesis from U. of Lovaina: | > http://inl.info.ucl.ac.be/system/files/memoire_0.pdf. They analyze | > several possible issues that may arise with firewalling shim6 = traffic, | > although all of them seem to be solved without requiring any = protocol | > modification. The main problem seems to be the large amount of = state | > that the firewall is required to store (the locators, context tag, = etc. for each | shim6 session). | > Of course, there is lack of real-world experience, so this = conclusions | > may not be close to reality. | > | > So, it is very likely that we could not find info for real tests on | > many of these combinations. Would it suffice to write a disclaimer = for | > this section saying that there is a lack of real experience with = most | > of these combinations?. | =20 | Yes, stating lack of information would be fine. | =20 OK. I've added the following text: "7. Interaction with Other Protocols and Mechanisms NEW TEXT ----> In this section we discuss the interaction between Shim6 and other protocols and mechanisms. Before starting the discussion, it is worth noting that at the time of this writing there is a lack of experience with the combination of Shim6 and these protocols and mechanisms. Therefore, the conclusions stated should be review as real experience is gained in the use of Shim6. <--- END OF NEW TEXT 7.1. Shim6 and Mobile IPv6 " Regards, Alberto | Jari | > | > Regards, | > Alberto | > | > | | > |> I will ask Sebastien Barre, which had a MipShim6 = implementation, | > |> with which I think he successfully tested some of the | > |> configurations discussed in the draft, although I'm not sure if | > |> IPsec was involved in | > the | > | tests. | > |> | > | OK | > | | > | Jari | > | > From jari.arkko@piuha.net Wed Feb 15 05:06:21 2012 Return-Path: X-Original-To: shim6@ietfa.amsl.com Delivered-To: shim6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0576921F8768 for ; Wed, 15 Feb 2012 05:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTL2eO96nYnL for ; Wed, 15 Feb 2012 05:06:16 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 02A7621F8720 for ; Wed, 15 Feb 2012 05:06:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 51A472D35A; Wed, 15 Feb 2012 15:06:15 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoNs_rXrkU99; Wed, 15 Feb 2012 15:06:07 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 4F9362CC3C; Wed, 15 Feb 2012 15:06:07 +0200 (EET) Message-ID: <4F3BADBF.4000308@piuha.net> Date: Wed, 15 Feb 2012 15:06:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= References: <4EF089CF.5070300@piuha.net> <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es> <4EF33EDB.5010806@piuha.net> <011901ccc0d0$467030f0$d35092d0$@it.uc3m.es> <4F34CAFE.4030703@piuha.net> <007301cce7fe$b553f6f0$1ffbe4d0$@it.uc3m.es> In-Reply-To: <007301cce7fe$b553f6f0$1ffbe4d0$@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'marcelo bagnulo braun' , 'shim6' , 'Joe Abley' Subject: Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt X-BeenThere: shim6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SHIM6 Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:06:21 -0000 Thanks. I sent the document for last call. Jari On 10.02.2012 16:17, Alberto García wrote: > Hi Jari > > | -----Mensaje original----- > | De: Jari Arkko [mailto:jari.arkko@piuha.net] > | Enviado el: viernes, 10 de febrero de 2012 8:45 > | Para: Alberto García > | CC: 'shim6'; 'marcelo bagnulo braun'; 'Joe Abley' > | Asunto: Re: AD review of draft-garcia-shim6-applicability-00.txt > | > | Alberto, > | > | I'm returning back to this thread... we should progress the document. Can > | you provide a revision? I've included some additional answers to your > | questions below. > > I have just uploaded a new version for the draft, to move it forward: > ----- > http://www.ietf.org/internet-drafts/draft-garcia-shim6-applicability-03.txt > A new version of I-D, draft-garcia-shim6-applicability-03.txt has been > successfully submitted by Alberto Garcia-Martinez and posted to the IETF > repository. > > Filename: draft-garcia-shim6-applicability > Revision: 03 > Title: Applicability Statement for the Level 3 Multihoming Shim > Protocol (Shim6) > Creation date: 2012-02-10 > WG ID: Individual Submission > Number of pages: 26 > ----- > > Some responses inline > > | > |> Hi Jari, > |> > |> [Trimming out all the issues already agreed] > |> > |> |> | The source address problem discussed in one paragraph in > |> |> Section 4 | should be highlighted much earlier. It is a key > |> |> missing pieces for | Shim6 to work, and | it would be honest to > |> |> tell this to the reader. Similarly, the | initial contact | > |> |> issue from Section 5.1.1 should also be highlighted up front. > |> |> > |> |> To address this, I suggest moving the current section '3. > |> |> Addresses and Shim6' after 'Shim6 capabilities'. The result would > be: > |> |> 1. Introduction > |> |> 2. Deployment Scenarios<- this is a short section which define > |> |> the topology... which is convenient before discussing all the > |> |> problems related with the attachment to different providers. > |> |> 3. Shim6 in Multihomed Nodes<- source address problem 4. Shim6 > |> |> Capabilities<-- initial contact issue 5. Addresses and Shim6 > |> |> > |> |> The 'addresses and Shim6' section does not include problematic > |> |> issues, so I think there is no problem in placing it later. > |> |> Do you think this solves the issue? > |> | > |> | Perhaps you could solve it in a simpler way, without this much > |> | surgery to the structure of the document. Just mention the things > |> | we need to > |> highlight > |> | in the introduction, and you should be fine. > |> > |> OK. I undo the position change of the 'address' section. > |> > |> I have added some text to the 4th paragraph of the 'introduction': > |> > |> " Shim6 provides layer-3 support for making re-homing events > |> transparent to the transport layer by means of a shim approach. > |> NEW TEXT ----> > |> Once > |> a Shim6 session has been established, the failure detection > mechanism > |> defined for Shim6 allows finding new valid locator combinations in > |> case of failure, and using these locators to continue the > |> communication. However, Shim6 does not provide failure protection > to > |> the communication establishment, so if a host within a multihomed > |> site attempts to establish a communication with a remote host and > |> selects an address which corresponds to a failed transit path, the > |> communication will fail. > |> <--- END OF NEW TEXT > |> State information relating to the > |> multihoming of two endpoints exchanging unicast traffic is retained > |> on the endpoints themselves, rather than in the network. > |> Communications between Shim6-capable hosts and Shim6-incapable > | hosts > |> proceed as normal, but without the benefit of transport-layer > |> stability. The Shim6 approach is thought to have better scaling > |> properties with respect to the state held in the DFZ than the IPv4 > |> approach. > |> NEW TEXT ----> > |> In order to successfully deploy Shim6 in a multihomed site, additional > |> mechanism may be required to solve issues such as selecting the source > |> address appropriate to the destination and to the outgoing provider, > |> or to allow the network manager to perform traffic engineering. Such > |> problems are not specific of Shim6, but are suffered by the hosts of > |> any site which is connected to multiple transit providers, and which > |> receives an IPv6 prefix from each of them. Some of these mechanisms are > | not defined today. > |> <--- END OF NEW TEXT" > |> > |> Do you think this is enough? > | > | Fine for me. Modulo Brian's comments (he had a point, maybe you want to > | revise the above a bit). > > OK. To address Brian's comment, I have added a new line to the end of the > previous paragraph, which says > 'However, note that once a Shim6 session has been established, Shim6 reduces > the impact of these problems, because if a working path exists, Shim6 will > find it.' > > [Trimming out agreed parts] > > | > |> > |> |> > |> |> | > |> |> | Section 7 should indicate if there is any implementation of | > |> |> deployment experience with these combinations. I'm doubtful on | > |> |> whether all the ipsec layering mechanisms and so on would actually > |> |> | work in real implementations without someone having tested such > |> | combinations. > |> |> > |> |> I assume you are referring specifically to discuss deployment > |> |> experience for the 'Shim6 and Mobile IPv6' subsection, aren't you? > |> | > |> | No, I was thinking of all the combinations listed in Section 7. > |> > |> I think there are two different cases for this. Some combinations are > |> NOT RECOMMENDED by the draft. These are > |> - shim6 and SCTP. > |> - shim6 and HIP. > |> - shim6 and NATs: since shim6 security is end-to-end, NATs break Shim6 > |> as currently defined. > |> Although it would be nice to have some experimental proof of this... I > |> think it is easier to accept that, if the analysis is ok, no further > |> experiment is required. > |> > |> The rest combinations are assumed to work. However, since IFAIK there > |> is no production deployment of Shim6, most of them have not been > |> tested. And even those tested, have not been tested in 'real' > |> conditions. For this, we have > |> - shim6 and IPsec and shim6 and MIPv6 (and the three of them). Barre's > |> implementation to check > |> - shim6 and SEND. It seems there should be no problem in the > |> interaction, since both protocols deal with different issues. I'm not > |> aware of any combined test for them. > |> - shim6 and NEMO. I'm not aware of any implementation/test of NEMO > |> with > |> Shim6 > |> - shim6 and firewalls. There is an implementation (a modification to > |> Linux > |> netfilter) developed for a Master Thesis from U. of Lovaina: > |> http://inl.info.ucl.ac.be/system/files/memoire_0.pdf. They analyze > |> several possible issues that may arise with firewalling shim6 traffic, > |> although all of them seem to be solved without requiring any protocol > |> modification. The main problem seems to be the large amount of state > |> that the firewall is required to store (the locators, context tag, etc. > for each > | shim6 session). > |> Of course, there is lack of real-world experience, so this conclusions > |> may not be close to reality. > |> > |> So, it is very likely that we could not find info for real tests on > |> many of these combinations. Would it suffice to write a disclaimer for > |> this section saying that there is a lack of real experience with most > |> of these combinations?. > | > | Yes, stating lack of information would be fine. > | > > OK. I've added the following text: > > "7. Interaction with Other Protocols and Mechanisms > NEW TEXT ----> > In this section we discuss the interaction between Shim6 and other > protocols and mechanisms. Before starting the discussion, it is > worth noting that at the time of this writing there is a lack of > experience with the combination of Shim6 and these protocols and > mechanisms. Therefore, the conclusions stated should be review as > real experience is gained in the use of Shim6. > <--- END OF NEW TEXT > 7.1. Shim6 and Mobile IPv6 > " > > Regards, > Alberto > > | Jari > |> > |> Regards, > |> Alberto > |> > |> | > |> |> I will ask Sebastien Barre, which had a MipShim6 implementation, > |> |> with which I think he successfully tested some of the > |> |> configurations discussed in the draft, although I'm not sure if > |> |> IPsec was involved in > |> the > |> | tests. > |> |> > |> | OK > |> | > |> | Jari > |> > |> > > From cabo@tzi.org Wed Feb 29 14:13:30 2012 Return-Path: X-Original-To: shim6@ietfa.amsl.com Delivered-To: shim6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D5521E809F; Wed, 29 Feb 2012 14:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT9cVCqTWX7E; Wed, 29 Feb 2012 14:13:29 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBF21E809E; Wed, 29 Feb 2012 14:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q1TMDI2v002565; Wed, 29 Feb 2012 23:13:18 +0100 (CET) Received: from [192.168.217.103] (p5B3E6294.dip.t-dialin.net [91.62.98.148]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 24709F8C; Wed, 29 Feb 2012 23:13:18 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1257) From: Carsten Bormann Date: Wed, 29 Feb 2012 23:13:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: To: IETF Apps Discuss , draft-garcia-shim6-applicability.all@tools.ietf.org, shim6@ietf.org X-Mailer: Apple Mail (2.1257) Cc: The IESG Subject: [shim6] APPSDIR review of draft-garcia-shim6-applicability-03 X-BeenThere: shim6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SHIM6 Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 22:13:30 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Gruesse, Carsten --------------------------------- Document: draft-garcia-shim6-applicability-03.txt Title: Applicability Statement for the Level 3 Multihoming Shim Protocol = (Shim6) Reviewer: Carsten Bormann IETF Last Call Date: 2012-02-15 Review Date: 2012-02-29 ** Summary: This draft is ready for publication as an Informational RFC with small changes, but maybe requires a better title. Note: I reviewed this with the expectation that the intended audience will read this *before* looking at RFC5533=965535 in detail. ** Major Issues: General: The document provides useful discussion of considerations around the usage of Shim6. At the end, it leaves the reader confused: What *is* the applicability/area of application of Shim6? Who should decide whether Shim6 is activated for a specific connection? (There is an API in RFC 6316, but clearly that is meant for advanced applications.) While the document successfully relates Shim6 to SCTP and HIP, what about other approaches to multi-addressing? When is happy-eyeballs enough? When should MPTCP be used? (The introduction to 7 then goes ahead and destroys any remaining hope that this document provides the answers -- maybe this should be split into "Open Issues" and the solid information about where Shim6 is not needed.) The document may have started out as an applicability statement half a decade ago, but maybe renaming it to "Considerations on the Application of Shim6" provides a more appropriate title now. Again, this is meant as a comment on the expectations raised by the title and abstract, not as an attempt to belittle the usefulness of the document's content. ** Minor Issues: (1) I'm not so fond of the DHCP speculation in 3.3. An applicability statement should talk about what is, not what could be. As of today, DHCP is not applicable, and that should be clearly stated. (Work in progress can, of course, be pointed to, but it is not clear there is much more than a problem statement.) (2) This sentence in 3.4 is opaque, unless it is talking about the state of implementations (or is this another piece of DHCP speculation?): There is no current mechanism designed to allow an = administrator to enforce the configuration of a CGA or an HBA in a host. (3) Section 3.4, 7.2: The term "hybrid" does not occur in RFC 5535. Adapt the terminology. (4) Section 5.2: One such solution is being developed at the MP-TCP Working = Group. That is not the name of the WG, and referring to ephemeral IETF WGs is not very useful in an archival document such as an RFC. It is probably most appropriate to reference RFC 6182. More generally speaking, one would expect some more guidance when MPTCP is appropriate and when Shim6 is appropriate. Oddly, RFC 6181 seems to provide more information about Shim6 on this point than the present document. (5) (On a related note, avoid discussion of the Shim6 WG's charter in 7.5.) ** Nits: [I-D.ietf-mif-problem-statement] is now RFC 6418. The document will benefit from some micro-editing, e.g. s/different to/different from/g s/specific of/specific to/g s/associated to/associated with/g s/is developed/has been developed/ The usage of "suffer" in several places (in particular, should "These problems are suffered by other solutions supporting multihoming such as SCTP [RFC4960] or HIP [RFC4423]." in section 4 not be "relevant to" instead?) "Shim6 has no means to enforce neither host nor network forwarding..." "does not require also" s/should be review/should be reviewed/ "...which security features can expect applications and users of the = Shim6 protocol." As this is typically done by the RFC editor, I'm not providing a detailed list here. Section 4: s/not being used/not be used/ Define "REAP" (I know, RFC5533 doesn't, either). Section 6: This sentence is hard to read: "As long as the address exchanged, IP_A is the ULID..."