Shim6: Level 3 Multihoming Shim Protocol for IPv6
draft-ietf-shim6-proto-12

After reviewing draft-ietf-shim6-app-refer, it's clear the application
issues have been considered appropriately, although it's unfortunate that
draft has expired.  If this were to deploy widely, I suspect applications
(particularly servers) would need to use OS APIs for this information at
least for logging if not for other functions.

> 1.  Introduction

  Assume that a SHIM6 host has multiple network interfaces, each of
  which has multiple IP addresses out of different prefixes. Assume this
  host is communicating with another such host. Is SHIM6 limited to
  failing over connections between those hosts between IP addresses that
  are associated with a network single interface pair only, or is SHIM6
  providing a mechanism for connections to fail over from one network
  interface pair to another? (I re-read the intro three times, but this
  isn't clear to me. I believe the intent is the latter?)


Section 2.2., paragraph 1:
>  A, B, and C are hosts.  X is a potentially malicious host.
>  FQDN(A) is the Fully qualified Domain Name for A.
>  Ls(A) is the locator set for A, which consists of the locators L1(A),
>  L2(A), ...  Ln(A).

  A host A can have multiple FQDNs, each of which maps into some subset
  of Ls(A). Also, MUST Ls(A) always contain *all* addresses of the host,
  including link-local and other special-case addresses? Is it allowed
  to eliminate some addresses from Ls(A), e.g., due to management or
  local policy?


Section 2.2., paragraph 2:
> The locator set in not ordered in any particular
> way other than maybe what is returned by the DNS.

  So is the set ordered, or is it not ordered? (Unclear what "other than
  maybe" tries to say here.) Also, as stated above, there may be multiple
  FQDNs for A, and they may not include all of its locators.


Section 4., paragraph 11:
>  o  In addition to failures detected based on end-to-end observations,
>     one endpoint might know for certain that one or more of its
>     locators is not working.  For instance, the network interface
>     might have failed or gone down (at layer 2), or an IPv6 address
>     might have become deprecated or invalid.  In such cases the host
>     can signal its peer that this address is no longer recommended to
>     try.  This triggers something similar to a failure handling and a
>     new working locator pair must be found.

  From Bernard's tsv-dir review: In general, it would not be desirable
  for SHIM6 to initiate the re-homing of a TCP connection due to a
  transient failure.  Link layer "down" indications or resulting address
  deprecations are examples of this. SCTP (RFC 4960) contains no
  equivalent advice.


Section 5.12., paragraph 0:
> 5.12.  Keepalive Message Format
>    This message format is defined in [5].

  From Bernard's tsv-dir review: Although I understand that the details
  of Keepalive algorithms might belong in a separate document, support
  for Keepalive appears to be required, so that the message format needs
  to be defined in the protocol document, and I would also like to see a
  discussion of the philosophy of Failure Detection in Section 1.


Section 5.13., paragraph 0:
> 5.13.  Probe Message Format
>    This message and its semantics are defined in [5].

  Similar to above, because this is required, the format should be
  defined here, and the basics of probing should be outlined.


Section 8., paragraph 6:
>  But when the shim on the transmitting side inserts the payload
>  extension header and replaces the ULIDs in the IP address fields with
>  some other locators, then an ICMP error coming back will have a
>  "packet in error" which is not a packet that the ULP sent.  Thus the
>  implementation will have to apply the reverse mapping to the "packet
>  in error" before passing the ICMP error up to the ULP.  See
>  Figure 31.

  Please explicitly state that this translation process needs to
  correctly handle RFC4884 ICMP extensions. Since this is a recent PS,
  not all implementors may be aware of it.


Section 15.3., paragraph 4:
>  o  MTU implications.  The path MTU mechanisms we use are robust
>     against different packets taking different paths through the
>     Internet, by computing a minimum over the recently observed path
>     MTUs.  When Shim6 fails over from using one locator pair to
>     another pair, this means that packets might travel over a
>     different path through the Internet, hence the path MTU might be
>     quite different.  Perhaps such a path change would be a good hint
>     to the path MTU mechanism to try a larger MTU?

  From Bernard's tsv-dir review: MTU discovery/MSS negotiation.  This is
  briefly discussed in Section 15.3 of the protocol document.  As noted
  there, SHIM6 failover may result in a change in MTU.  Some specific
  recommendations might be helpful here (such as a recommendation to use
  Packetization Layer Path MTU discovery)


Section 15.3., paragraph 5:
>     The fact that the shim will add an 8 octet Payload Extension
>     header to the ULP packets after a locator switch, can also affect
>     the usable path MTU for the ULPs.  In this case the MTU change is
>     local to the sending host, thus conveying the change to the ULPs
>     is an implementation matter.

  From Bernard's tsv-dir review: The insertion of a Payload Extension
  (or common shim control message) header may also result in an MTU
  change in mid-connection; however, this seems easier to handle
  assuming that the transport layer is made aware of it and can reduce
  the MSS accordingly.


Appendix A., paragraph 6:
>  o  Potentially recommend that more application protocols use DNS SRV
>     records to allow a site some influence on load spreading for the
>     initial contact (before the Shim6 context establishment) as well
>     as for traffic which does not use the shim.

  From Bernard's tsv-dir review:  Appendix A recognizes that DNS SRV RR
  usage is not common today and that changes to applications would be
  necessary to make full use of this feature.  Is this really something
  that we want to recommend within the protocol document?

I definitely would like to see work continue on the notification between the shim and the transport protocol. This clearly is needed to ensure good performance and avoid some failure cases for the transport protocol. 

I also think the authors needs to address the Transport directorate review comments from Bernard Aboba. They need to be addressed and support holding a discuss based on it.

Third paragraph of section 3:

   The above scenario leads to the assumption that a host should be able
   to cause different egress paths from its site to be used.  The most
   reasonable approach to accomplish this is to have the host use
   different source addresses and have the source address affect the
   selection of the site egress.  The details of how this can be
   accomplished is beyond the scope of this document, but without this
   capability the ability of the shim to try different "paths" by trying
   different locator pairs will have limited utility.

I don't think that this (having source address effect egress selection) is really the best way to handle this scenario. If one of the addresses for a given site is not working, then one likely cause is that the connectivity from the site to the associated ISP is down. On egress, this might for example be better fixed by having the route that is being advertised into the site from that ISP (for example, possibly a default route advertised by a CE router into a site) no longer advertised, so that the outgoing packet from the site would go via a different egress. This implies that normal application of IP routing would solve the problem in the outgoing direction. It is the return direction that would need to be solved by selecting a different address (which might be a different source address for traffic from the site to elsewhere, but would turn into a different destination address for return traffic).