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

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Dec 2011 15:12:47 +0200

This document has been revived from an expired status, and I was told that it should be ready enough to be published. I have therefore reviewed it.

The document is in relatively good shape and can progress forward, but first we have to make sure that it properly highlights the major issues with Shim6 usage (ingress filtering, lack of initial contact support, lack of firewall implementations with Shim6 support, on/off vs. load balanced multihoming) as well as talk about the needs for site network admins to control the behaviour of Shim6.

I'm expecting a revised draft. How soon can you make one, Alberto?

My detailed comments follow.

>     The Shim6 protocol is defined only for IPv6.  However, there is no
>     fundamental reason why a Shim6-like approach could not support IPv4
>     addresses as locators, either to provide multihoming support to IPv4-
>     numbered sites, or as part of an IPv4/IPv6 transition strategy.  Some
>     extensions to the Shim6 protocol for supporting IPv4 locators have
>     been proposed in [I-D.nordmark-shim6-esd  <http://tools.ietf.org/html/draft-garcia-shim6-applicability-02#ref-I-D.nordmark-shim6-esd>].
>
>     The Shim6 protocol, as specified for IPv6, incorporates cryptographic
>     elements in the construction of locators (see [RFC3972  <http://tools.ietf.org/html/rfc3972>], [RFC5535  <http://tools.ietf.org/html/rfc5535>]).
>     Since IPv4 addresses are insufficiently large to contain addresses
>     constructed in this fashion, direct implementation of Shim6 as
>     specified for IPv6 for use with IPv4 addresses might require protocol
>     modifications.

I think this is too optimistic. The devil is in the details, and I'm not sure how the security would actually work in this case.

Suggested edit:

    The Shim6 protocol is defined only for IPv6.  While some Shim6-like
    approaches have been suggested to support IPv4 addresses as locator
    [I-D.nordmark-shim6-esd], at this time it is not clear if such extensions
    are feasible.
    The Shim6 protocol, as specified for IPv6, incorporates cryptographic
    elements in the construction of locators (see [RFC3972], [RFC5535]).
    Since IPv4 addresses are insufficiently large to contain addresses
    constructed in this fashion, direct implementation of Shim6 as
    specified for IPv6 for use with IPv4 addresses is not possible.

> which with the current rate of IPv4 addresses
>     would be problematic.

which would obviously be problematic given that IPv4 addresses are not easily available any more.

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.

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.

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.

>     In order to identify the DNS server most appropriate to resolve a
>     particular query, nodes can be configured with policy information.
>     [RFC3484  <http://tools.ietf.org/html/rfc3484>] policy information needs be configured in such way that
>     only source addresses of the node could be used by Shim6 to establish
>     the communication with the DNS if Shim6 could be used for accessing
>     to the DNS.

The "mif" style issues take perhaps a too big of a role here. You should indicate that these issues exist and that they exist independent of Shim6. Also, only certain configurations exhibit the above problems, e.g., walled garden situations. Normal Internet access through ISP would not be affected, and it would not be a problem to use just a regular DNS.

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.

Jari

---

From: Alberto García <[email-masked]>
Date: Thu, 22 Dec 2011 13:18:12 +0100

Hi
Thanks for your review, Jari.

|  -----Mensaje original-----
|  De: Jari Arkko [mailto:[email-masked]]
|  Enviado el: martes, 20 de diciembre de 2011 14:13
|  Para: shim6; Alberto García; marcelo bagnulo braun; Joe Abley
|  Asunto: AD review of draft-garcia-shim6-applicability-00.txt
|  
|  This document has been revived from an expired status, and I was told
that
|  it should be ready enough to be published. I have therefore reviewed it.

Well, actually the last version submitted is -02, expiring on April 2012. 
Although you refer in the subject of this email to -00, I see by your
comments that you refer to text that was included in version 01 and 02... so
it seems that regarding to the text we are synchronized.

|  
|  The document is in relatively good shape and can progress forward, but
first
|  we have to make sure that it properly highlights the major issues with
Shim6
|  usage (ingress filtering, lack of initial contact support, lack of
firewall
|  implementations with Shim6 support, on/off vs. load balanced
|  multihoming) as well as talk about the needs for site network admins to
|  control the behaviour of Shim6.
|  
|  I'm expecting a revised draft. How soon can you make one, Alberto?

Very soon. I would wait for finishing this discussion to generate a new
version,.
  
|  My detailed comments follow.
|  
|  >     The Shim6 protocol is defined only for IPv6.  However, there is no
|  >     fundamental reason why a Shim6-like approach could not support IPv4
|  >     addresses as locators, either to provide multihoming support to
IPv4-
|  >     numbered sites, or as part of an IPv4/IPv6 transition strategy.
Some
|  >     extensions to the Shim6 protocol for supporting IPv4 locators have
|  >     been proposed in [I-D.nordmark-shim6-esd
|  <http://tools.ietf.org/html/draft-garcia-shim6-applicability-02#ref-I-
|  D.nordmark-shim6-esd>].
|  >
|  >     The Shim6 protocol, as specified for IPv6, incorporates
cryptographic
|  >     elements in the construction of locators (see [RFC3972
|  <http://tools.ietf.org/html/rfc3972>], [RFC5535
|  <http://tools.ietf.org/html/rfc5535>]).
|  >     Since IPv4 addresses are insufficiently large to contain addresses
|  >     constructed in this fashion, direct implementation of Shim6 as
|  >     specified for IPv6 for use with IPv4 addresses might require
protocol
|  >     modifications.
|  
|  I think this is too optimistic. The devil is in the details, and I'm not
sure how
|  the security would actually work in this case.
|  
|  Suggested edit:
|  
|      The Shim6 protocol is defined only for IPv6.  While some Shim6-like
|      approaches have been suggested to support IPv4 addresses as locator
|      [I-D.nordmark-shim6-esd], at this time it is not clear if such
extensions
|      are feasible.
|      The Shim6 protocol, as specified for IPv6, incorporates cryptographic
|      elements in the construction of locators (see [RFC3972], [RFC5535]).
|      Since IPv4 addresses are insufficiently large to contain addresses
|      constructed in this fashion, direct implementation of Shim6 as
|      specified for IPv6 for use with IPv4 addresses is not possible.

Agreed

|  
|  > which with the current rate of IPv4 addresses
|  >     would be problematic.
|  
|  which would obviously be problematic given that IPv4 addresses are not
|  easily available any more.

Well, do you think it could be improved by updating the text if changed
to...
'[...]  which would be problematic considering the current situation in
which IPv4 address space has been exhausted.'

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

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

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

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.

|  
|  >     In order to identify the DNS server most appropriate to resolve a
|  >     particular query, nodes can be configured with policy information.
|  >     [RFC3484  <http://tools.ietf.org/html/rfc3484>] policy information
|  needs be configured in such way that
|  >     only source addresses of the node could be used by Shim6 to
establish
|  >     the communication with the DNS if Shim6 could be used for accessing
|  >     to the DNS.
|  
|  The "mif" style issues take perhaps a too big of a role here. You should
|  indicate that these issues exist and that they exist independent of
Shim6.

I've added a new sentence at the beginning of the first paragraph of the
section:
"[OLD:]Shim6 multihomed nodes are likely to suffer problems related to the
attachment to different provision domains. 
[NEW:] Note that these problems are not specific of Shim6."

|  Also, only certain configurations exhibit the above problems, e.g.,
walled
|  garden situations. Normal Internet access through ISP would not be
|  affected, and it would not be a problem to use just a regular DNS.

I have shortened the DNS paragraph. Now it says:
"For some particular configurations, i.e. for a walled-garden or closed
service, the node may need to identify the most appropriate DNS server to
resolve a particular query. For an analysis of this problem, the reader is
referred to [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]."

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

Regards,
Alberto

|  
|  Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Dec 2011 16:29:47 +0200

Alberto,

> Very soon. I would wait for finishing this discussion to generate a new

OK

> |>      The Shim6 protocol is defined only for IPv6.  However, there is no
> |>      fundamental reason why a Shim6-like approach could not support IPv4
> |>      addresses as locators, either to provide multihoming support to
> IPv4-
> |>      numbered sites, or as part of an IPv4/IPv6 transition strategy.
> Some
> |>      extensions to the Shim6 protocol for supporting IPv4 locators have
> |>      been proposed in [I-D.nordmark-shim6-esd
> |<http://tools.ietf.org/html/draft-garcia-shim6-applicability-02#ref-I-
> |>
> |>      The Shim6 protocol, as specified for IPv6, incorporates
> cryptographic
> |>      elements in the construction of locators (see [RFC3972
> |<http://tools.ietf.org/html/rfc3972>], [RFC5535
> |<http://tools.ietf.org/html/rfc5535>]).
> |>      Since IPv4 addresses are insufficiently large to contain addresses
> |>      constructed in this fashion, direct implementation of Shim6 as
> |>      specified for IPv6 for use with IPv4 addresses might require
> protocol
> |>      modifications.
> |
> |>  which with the current rate of IPv4 addresses
> |>      would be problematic.
> |

OK

> 2.  Deployment Scenarios<- this is a short section which define the
> 3.  Shim6 in Multihomed Nodes<- source address problem
> 4.  Shim6 Capabilities<-- initial contact issue
> 5. Addresses and Shim6
>

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.

> developed at the MP-TCP Working Group."

OK. (Maybe "It is worth noting that ...")

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

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

>
> |
> |>      In order to identify the DNS server most appropriate to resolve a
> |>      particular query, nodes can be configured with policy information.
> |>      [RFC3484<http://tools.ietf.org/html/rfc3484>] policy information
> |>      only source addresses of the node could be used by Shim6 to
> establish
> |>      the communication with the DNS if Shim6 could be used for accessing
> |>      to the DNS.
> |

OK

> the 'Shim6 and Mobile IPv6' subsection, aren't you?

No, I was thinking of all the combinations listed in Section 7.

> draft, although I'm not sure if IPsec was involved in the tests.
OK

Jari

---

From: Alberto García <[email-masked]>
Date: Thu, 22 Dec 2011 18:36:45 +0100

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

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Dec 2011 11:04:53 +1300

> from each of them. Some of these mechanisms are not defined today."

I fully agree with this text, but if possible can you emphasise even more
that these problems are problems of sites with multiple prefixes and *in
no way* caused by shim6? Actually shim6 reduces the impact of these problems,
because if there is a working path shim6 will find it, which is also true
for MPTCP and happy-eyeballs, but *not* true for vanilla IPv6.

Regards
   Brian