Shim6: Level 3 Multihoming Shim Protocol for IPv6
RFC 5533

Note: This ballot was opened for revision 12 and is now closed.

(Sam Hartman) Discuss

Discuss (2007-12-19 for -)
Overall this is a well written document and I appreciate the work that
has gone into it.

First, I'm trying to figure out if someone with HBA locators can use
the update message to update their locator set.  I am probably just
missing it, but is there text in this spec (as apposed to the HBA
spec) that requires if HBA verification is used, all the locators are
HBAs?  Presumably this requirement is intended to exist?


Unfortunately, there is a significant conflict between this document
and RFC 4301.This document has an architecture of the IP layer where
there is a sub-layer responsible for routing and a sub-layer
responsible for ULP interactions, fragmentation, etc.  The shim is
inserted between these two layers.  The document assumes that IPsec
processing happens in the layer that does fragmentation--above the
shim.

RFC 4301 also has a detailed architecture of IP and in particular
IPsec processing.  They aren't the same.

RFC 4301 divides interfaces into protected and unprotected interfaces.
IPsec processing and the SPD are consulted when a packet crosses from
a protected interface to an unprotected interface.
In the RFC 4301 model you need to understand  what interface a packet will be routed out on  before making a decision about IPsec processing.

This is an important part of the IPsec model.  I may have two paths
out of my system.  One over a trusted network and one over an
untrusted network.  If a link or path fails and the trusted network is
no longer available IPsec processing may suddenly be required.


However the reasoning in the shim6 draft about why you may want the
shim below IPsec also applies in some configurations.

What is clear to me is we have significantly more work to do on this
issue.  It is also clear that if shim6 is going to change the IPsec
processing model, RFC 4301 must be updated either by this spec or by
some document normatively referenced by this spec.  Finally, shim6 may
not change the IPsec processing model without involving the security
community and getting appropriate review.

(Jari Arkko) Yes

(Ron Bonica) (was Discuss) No Objection

(Ross Callon) (was Discuss) No Objection

Comment (2007-12-20)
No email
send info
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).

(Lars Eggert) (was Discuss) No Objection

Comment (2008-01-10)
No email
send info
> 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?

(Pasi Eronen) (was Discuss) No Objection

(Russ Housley) No Objection

(Chris Newman) (was Abstain) No Objection

Comment (2008-01-24 for -)
No email
send info
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.

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Mark Townsley) No Objection

(Magnus Westerlund) (was Discuss) No Objection

Comment (2007-12-20)
No email
send info
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.

(Lisa Dusseault) (was No Objection, Discuss) Abstain

Comment (2007-12-19 for -)
No email
send info
I appreciate the Assumptions section, but for this reader, it didn't go far enough.

It's not clear up front how SHIM6 support is advertised and discovered.  It's not clear why a host that isn't multi-homed would support it.  I don't understand if this has to be deployed across an entire site to be useful, or just one node can go SHIM6.  It's not clear what intermediary support is required.

(Cullen Jennings) (was Discuss, Abstain, No Record, No Objection) Abstain

Comment (2008-02-16)
No email
send info
* Many of the mechanisms that are required to make this safe to use are not specified enough to be implementable and simply place holders for future work. Forking for example.

* Most of the problems with NATs arise out of the application using an address  identifier which is not the one some parts of  the network are using and in the process break the end to end principal. SHIM6 will have very similar properties and problems.

* The deployment model requires both ends to support SHIM6 but offer little or no incentive for either end to deploy first.

* It's unclear how it will interact with say firewalls that time out alternative path. I understand the arguments that firewalls may not allow unknown protocols to flow through them but initial deployment of ipsec showed that at least for some firewalls this is allowed.

* The scope of applicability is very narrow. If the goal is only keep long lived sessions up during multihomed cutover, most applications don't need to do this and just form new connections. The ones that do need this would likely be better served by something like SCTP which did not have the NAT characteristics.

* The lack of a mandatory way for upper level protocols to be able to control and understand what is going on at this level will make it hard for applications to understand why things are failing. An example of this is how SHIM6 eats some but not all of the ICMP messages. I look forward to debugging and trying to figure out why I see ICMP message on the wire and some times the message is delivered to the apps (if shim6 has not started) and some times it is not.

* Requires unspecified heuristics to decide when to use it. This is not a problem so much as the heuristics are clearly application dependent yet have to be implemented at more the kernel level.

* It moves traffic engineering decisions to an end host that has no idea of the global information needed to make reasonable TE decisions. I understand argument that DNS round robin does the same thing but even DNS servers some times looked at global state to decide what to return. Note I am not complaining that it moves what TE from operators to users - I am worried about moving it from a place where the information to do it exists to a place where the information is unlikely to exist.

It is possible that over time people will find solutions to the above problems and develop a better understanding of which of these do not impact other protocols in a negative way. At that point I'd be fine to move to PS but right now I believe this is better as experimental.

(David Ward) (was Discuss) Abstain

Comment (2008-06-18)
No email
send info
I support Cullen's list of issues and will let him hold them. These need to be answered/solved.