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

[Jari Arkko <[e-mail]>]

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
>
>