Subject: Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Feb 2012 09:45:02 +0200

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 García <[email-masked]>
Date: Fri, 10 Feb 2012 15:17:23 +0100

Hi Jari

|  -----Mensaje original-----
|  De: Jari Arkko [mailto:[email-masked]]
|  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: Jari Arkko <[email-masked]>
Date: Wed, 15 Feb 2012 15:06:07 +0200

Thanks. I sent the document for last call.

Jari

On 10.02.2012 16:17, Alberto García wrote:
> |>  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?
> |
> |>  |>
> |>  |>   |
> |>  |>   |  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?.
> |
> |>  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
> |>
> |>
>
>