Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt
Jari Arkko <jari.arkko@piuha.net> Fri, 10 February 2012 07:45 UTC
Return-Path: <jari.arkko@piuha.net>
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 <shim6@ietfa.amsl.com>; 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 <shim6@ietfa.amsl.com>; 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 <shim6@ietf.org>; 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 <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Alberto García <alberto@it.uc3m.es>
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' <marcelo@bagnulo.net>, 'shim6' <shim6@ietf.org>, 'Joe Abley' <joe.abley@icann.org>
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 <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=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 > >
- [shim6] AD review of draft-garcia-shim6-applicabi… Jari Arkko
- Re: [shim6] AD review of draft-garcia-shim6-appli… Alberto García
- Re: [shim6] AD review of draft-garcia-shim6-appli… Jari Arkko
- Re: [shim6] AD review of draft-garcia-shim6-appli… Alberto García
- Re: [shim6] AD review of draft-garcia-shim6-appli… Brian E Carpenter
- Re: [shim6] AD review of draft-garcia-shim6-appli… Jari Arkko
- Re: [shim6] AD review of draft-garcia-shim6-appli… Alberto García
- Re: [shim6] AD review of draft-garcia-shim6-appli… Jari Arkko