Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt
Jari Arkko <jari.arkko@piuha.net> Wed, 15 February 2012 13:06 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 0576921F8768 for <shim6@ietfa.amsl.com>; 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 <shim6@ietfa.amsl.com>; 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 <shim6@ietf.org>; 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 <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.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> <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' <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: 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 > |> > |> > >
- [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