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

[Ballot discuss]
[Taking Sam's discuss]

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.

[additional comments by Pasi]

IPsec policies can be about identifiers visible to ULP (e.g.,
if you configure a client application to talk to server at
particular IP address, you'd also configure the SPD to require
ESP for that traffic), or it can be about locators used for
delivering packets (e.g., some traffic might be going over a
leased line that's considered OK enough without ESP). RFC 4301
didn't have to make this distinction, but it seems that simply
putting shim6 below IPsec works better for former kind of
policies, and less well for the latter kind.

[Ballot comment]
* 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.

[Ballot discuss]
I see this work as a stage along the way to having a full solution and worth publishing but only as experimental because I believe it would cause harm to a significant set of applications if widely deployed as currently specified.

* This breaks applications that use MIDCOM style architectures and would be harmful to these applications if it saw widespread deployment. I'm glad to provide more details about this but many applications want to be able to tell things like logging and recording systems what flows they are using and this will break them without the applications being able to even know when or why their flow changed.

* It's dramatically changes the underlying model of timing of failover which will interact very poorly with timers in layer 3 and above protocols. This is part of the reason for example that the drafts say it should not be used with SCTP. But what about other applications that have the same type of behavior as SCTP at the application layer? How would shim6 know what applications it was safe for and which ones were not.

Application are not in total control of the host and their is not a single application per host. This may work for some environments but we can not expect end users to know if it would be safe to use SHIM6 for all of their applications or not.

I have entered this as a discuss simply for logging and tracking purposes of my abstain position. I am happy to discuss my concerns but I don't think this is a particularly actionable discuss.

[Ballot comment]
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.

[Ballot comment]
> 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?

[Ballot discuss]
Having thought about this, I think that the issue that I mentioned in a comment earlier really needs to be fixed, and thus raised to the level of a discuss. This refers to the 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.

If shim6 depends upon source-and-destination based forwarding to be deployed in routers within each multi-homed site, then it is not likely to go anywhere (or at least this would be a significant barrier to deployment). However, I don't think that it needs source based routing. The normal operation of routing within a site should allow an egress that works to be selected for outgoing traffic. For example, in may cases a default route would be injected into the site for each CE router that has a link to a service provider. If one of the CE to PE links goes down, and the associated CE no longer has a link to a public service provider, than it can withdraw the default route that it injects to the site, causing outgoing traffic to choose a different egress point.

Now, the failure of a CE to PE link, if it disconnects the site from a particular service provider, might mean that return traffic coming back to that site needs to use a different address for the destination address. If changing the source address on outgoing traffic causes the remote system to change the corresponding destination address on return traffic, then there might be some reason for a host to change the source address that it uses. Otherwise normal routing should find a workable egress point for traffic leaving this site, and the remote system will need to find an approprite destination address to use for traffic returning to the site.

The authors, WG chairs, and/or shepherding AD should feel free to contact me if they need help in putting together appropriate text to correct this point.

[Ballot comment]
I would have no problem with experimental. Many serious issues have been bought up in the discusses. It is not clear that these can all be fixed in any way where the protocol can still be useful in general circumstances.

[Ballot discuss]
A side effect of shim6 is that it moves control wrt TE from the SP to the sending customer. This may or may not be a good thing. Maybe we could add a small discussion of the pros and cons.

[Ballot comment]
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.

[Ballot discuss]
Section 8.

To me it appears that not all type of ICMP error messages should be forward to the ULP. Instead the SHIM should intercept them and use them as a basis for a failover. I think some explicit consideration of the different types of ICMP errors and which should translated and which shouldn't. And if you have considered why also these two:

      0 = net unreachable;

      1 = host unreachable;

shouldn't be used by SHIM6 rather than being forwarded please explain the reasoning.

[Ballot comment]
Unfortunately, I came across this document too late to do the level of
review necessary to verify it meets the goal "Have minimal impact on
upper layer protocols in general and on transport protocols and
applications in particular" prior to the IESG call.  My suspicion is
it can not without suggesting an API for accessing endpoint IP addresses.

My main concern with that claim is the level of transparency available
to applications.  Specifically, if this protocol is in use, then most
applications need the ability to discover the set of valid interface
addresses.  While it is unusual for applications to actually transfer
IP addresses across the wire, it is common practice for applications to
make heavy use of IP addresses in server configuration and operation
for functions such as inter-server access control, authorization, TLS
session caching, connection throttling, DOS-protection, etc.

[Ballot comment]
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).

[Ballot discuss]
3.  Assumptions
  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.

The opening assumption says that the resulting protocol will not be useful in real life. Fundamentally to make that work the local routers would have to do source based routing to avoid exiting into the wrong ISP ingress filter.

4.  Protocol Overview
  The purpose of this heuristic is to avoid setting up a shim context when  only a small number of packets is exchanged between two hosts.

The follow-on assumption seems to say that the mechanism will never be used for the vast majority of the existing short-burst application traffic.


I have no problem with publishing the set as Experimental, but any other status may be causing a lot of heartache for the authors. If this goes on standards track all of the firewalls would have to implement an undefined host-firewall signaling protocol, then the firewalls would have to implement a state transfer between all the site boundaries. All the intra-site routers would have to implement source prefix based routing to get the packet to its proper exist point. Then even if they did all that work, the number of flows where this would get used are very, very small.

[Ballot discuss]
3.  Assumptions
  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.

The opening assumption says that the resulting protocol will not be useful in real life. Fundamentally to make that work the local routers would have to do source based routing to avoid exiting into the wrong ISP ingress filter.

4.  Protocol Overview
  The purpose of this heuristic is to avoid setting up a shim context when  only a small number of packets is exchanged between two hosts.

The follow-on assumption seems to say that the mechanism will never be used for the vast majority of the existing short-burst application traffic.

[Ballot comment]
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.

[Ballot discuss]
[This is a resend... I munged the cut-paste of Magnus' review]

This is a placeholder DISCUSS for the issues raised in Magnus Nystrom's secdir review from
December 10.  I may add additional issues upon completion of my own review, but the key
length and flooding attack points should.

I have appended Magnus' review below:

- Section 7.10.1, 2nd paragraph is confusing and needs to be
  re-written.

- Section 7.20, last paragraph: "... the host updates the context
  information...The context state remains unchanged." This seems
  contradictory and it would be good with a clarification. Also, the
  English in this whole bullet (starting "If the state is ESTABLISHED
  ...") should be reviewed.

Section 16, General:

- Missing discussion around premeditated redirection attacks

- It would be good to refer back to RFC 4218, i.e. to replicate the
  systematic treatment of threats in that RFC and explain how each
  threat is handled in Shim6.

Section 16, Specific:

- First bullet: "The minimum acceptable key length for public
  keys... SHOULD be 1024 bits" - Firstly, there is no identification
  of the key algorithm (RFC 3972 does not seem to require
  RSA). Secondly, the statement does not clarify what the minimum
  (absolute) requirement is. I would recommend MUST be at least 1024
  and SHOULD be longer.

- Both the first and second bullet text needs rewriting for clarity,
  e.g. for the second bullet to something like: "3rd party flooding
  attacks are prevented by requiring a Shim6 peer to perform a
  successful Reachability probe + reply exchange as defined in [5]
  before accepting a new locator for use as a packet destination."

[Ballot discuss]
This is a placeholder DISCUSS for the issues raised in Magnus Nystrom's secdir review from
December 10.  I may add additional issues upon completion of my own review, but the key
length and flooding attack points should.

I have appended Magnus' review below:

- Section 7.10.1, 2nd paragraph is confusing and needs to be
  re-written.

- Section 7.20, last paragraph: "... the host updates the context
  information...The context state remains unchanged." This seems
  contradictory and it would be good with a clarification. Also, the
  English in this whole bullet (starting "If the state is ESTABLISHED
  ...") should be reviewed.

General:

- Missing discussion around premeditated redirection attacks

- It would be good to refer back to RFC 4218, i.e. to replicate the
  systematic treatment of threats in that RFC and explain how each
  threat is handled in Shim6.

Specific:

- First bullet: "The minimum acceptable key length for public
  keys... SHOULD be 1024 bits" - Firstly, there is no identification
  of the key algorithm (RFC 3972 does not seem to require
  RSA). Secondly, the statement does not clarify what the minimum
  (absolute) requirement is. I would recommend MUST be at least 1024
  and SHOULD be longer.

- Both the first and second bullet text needs rewriting for clarity,
  e.g. for the second bullet to something like: "3rd party flooding
  attacks are prevented by requiring a Shim6 peer to perform a
  successful Reachability probe + reply exchange as defined in [5]
  before accepting a new locator for use as a packet destination."

[Ballot discuss]
Part of the issues raised by this DISCUSS have been raised in the DNS-DIR review by Peter Koch.

1. This new protocol specification is missing any information concerning operational and manageability issues. I would have expected at least that section 15 Implications Elsewhere would include a subsection concerning the operational aspects related to the introduction of the protocol like impact on the traffic level, strategy of deployment, are configuration operations expected on hosts runing the protocol, etc.

2. The basic shim6 protocol specification mentions DNS SRV quite a lot (in section 5.15.3), but only to borrow priority/weight interaction definition.

No DNS SRV RRs are involved explicitly, but the section 1.7 on traffic engineering reads:

  identical to the DNS SRV [6] specification of priority and weight, so
  that DNS SRV records can be used for initial contact and the shim for
  failover, and they can use the same way to describe the preferences.

How would the SRV RR be used in this case?  SRV is service specific, not to control preference levels for multiple addresses of the same host, primarily.

3. Appendix A also mentions the DNS SRV:

  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.

Shim use is already recommended against for name servers, but if a single host provides DNS and other services, conflicts might arise.
For example, (some) name servers' addresses need to be stable for reasons of glue maintenance.
This might encourage use of 'service based' IPv6 addresses.

[Ballot discuss]
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.

[Ballot comment]
Treat these as late last call comments ....

I think that the applicability statement is an important part of this standard and really should be normatively references or directly included in the main document. But if others disagree, I'm fine with it as it is.

I hope the WG very quickly produces an API document that allows the upper levels to be notified of changes - most the important RAI applications I can think of would have weird failure cases if they were no API to do this and they wanted to use SHIM6.

[Ballot discuss]
This is a placeholder DISCUSS until we're clear that the issues from Bernard Abobas tsv-dir review have been addressed: http://www1.ietf.org/mail-archive/web/ietf/current/msg49109.html

(I may add to this DISCUSS based on my own IESG review.)

IANA Last Call comments:

IANA has questions.

Action #1:
Upon approval of this document, the IANA will assign an IP Protocol
Number for Shim6.

**QUESTION: In which registry should this assignment be made? Possibilities appear to include
http://www.iana.org/assignments/version-numbers
http://www.iana.org/assignments/ipv6-parameters, sub-registry 5.a
http://www.iana.org/assignments/ip-parameters


Action #2:
Upon approval of this document, the IANA will make the following
assignment in the "CGA Message Type Name Space" registry at
http://www.iana.org/assignments/cga-message-types
sub-registry "CGA Extension Type Tags"

Registry:
CGA Type Tag Reference
---------------------------------------------+-----------
0x4A30 5662 4858 574B 3655 416F 506A 6D48. | [RFC-shim6-proto-09]


Action #3
Upon approval of this document, the IANA will create a
registry called "Shim6 Parameters," to be located at
http://www.iana.org/assignments/TBD
Initial contents are defined in Actions 4-6.


Action #4
Upon approval of this document, the IANA will create a
sub-registry called "Sim6 Types" in "Shim6 Parameters."
Registration Procedure: Standards Action
Initial contents of this sub-registry will be:

Type Value | Message | Reference
------------+-----------------------------------------------------+-----------
+
0 | RESERVED |[RFC-shim6-proto-09]
| |
1 | I1 (first establishment message from the initiator) |[RFC-shim6-proto-09]
| |
2 | R1 (first establishment message from the responder) |[RFC-shim6-proto-09]
| |
3 | I2 (2nd establishment message from the initiator) |[RFC-shim6-proto-09]
| |
4 | R2 (2nd establishment message from the responder) |[RFC-shim6-proto-09]
| |
5 | R1bis (Reply to reference to non-existent context) |[RFC-shim6-proto-09]
| |
6 | I2bis (Reply to a R1bis message) |[RFC-shim6-proto-09]
| |
7-59 | Can be allocated using Standards Action |[RFC-shim6-proto-09]
| |
60-63 | For Experimental use |[RFC-shim6-proto-09]
| |
64 | Update Request |[RFC-shim6-proto-09]
| |
65 | Update Acknowledgement |[RFC-shim6-proto-09]
| |
66 | Keepalive |[RFC-shim6-proto-09]
| |
67 | Probe Message |[RFC-shim6-proto-09]
| |
68 | Error Message |[RFC-shim6-proto-09]
| |
69-123 | Can be allocated using Standards Action |[RFC-shim6-proto-09]
| |
124-127 | For Experimental use |[RFC-shim6-proto-09]

**QUESTION: Type 68 was listed in section 5.3, but not in the IANA
Considerations. Should this type be assigned?


Action #5
Upon approval of this document, the IANA will create a sub-registry called "Sim6 Options" in "Shim6 Parameters."
Registration Procedure: Standards Action
Initial contents of this sub-registry will be:

| Type | Option Name |
+-------------+----------------------------------+-------------------
| 0 | RESERVED | [RFC-shim6-proto-09]
| | |
| 1 | Responder Validator | [RFC-shim6-proto-09]
| | |
| 2 | Locator List | [RFC-shim6-proto-09]
| | |
| 3 | Locator Preferences | [RFC-shim6-proto-09]
| | |
| 4 | CGA Parameter Data Structure | [RFC-shim6-proto-09]
| | |
| 5 | CGA Signature | [RFC-shim6-proto-09]
| | |
| 6 | ULID Pair | [RFC-shim6-proto-09]
| | |
| 7 | Forked Instance Identifier | [RFC-shim6-proto-09]
| | |
| 8-9 | Allocated using Standards action | [RFC-shim6-proto-09]
| | |
| 10 | Keepalive Timeout Option | [RFC-shim6-proto-09]
| | |
| 11-16383 | Allocated using Standards action | [RFC-shim6-proto-09]
| | |
| 16384-32767 | For Experimental use | [RFC-shim6-proto-09]


Action #6
Upon approval of this document, the IANA will create a sub-
registry called "Sim6 Error Messages" in "Shim6 Parameters."
Initial contents of this sub-registry will be:

| Code Value | Description |
+------------+--------------------------------------------+----------------
---
| 0 | Unknown Shim6 message type | [RFC-shim6-proto-09]
| | |
| 1 | Critical Option not recognized | [RFC-shim6-proto-09]
| | |
| 2 | Locator verification method failed | [RFC-shim6-proto-09]
| | |
| 3 | Locator List Generation number out of sync | [RFC-shim6-proto-09]
| | |
| 4 | Error in the number of locators | [RFC-shim6-proto-09]
| | |
| 120-127 | Reserved for debugging pruposes | [RFC-shim6-proto-09]

**QUESTION: Are values 5-119 available for allocation? If so, are they allocated by Standards Action, or according to another policy?


We understand the above to be the only IANA Actions for this
document.

Last piece of AD review (appendixes skipped though):

Continuing with the review. This goes right to the end,
and I have set the state of the document to Revised ID
Needed. I will still send some summary conclusions
after thinking about the results of the review. But
overall I'm relatively happy, almost everything that
I found was just minor issues. Its a tough document
to read given its size, but very well written and
there was a very small number of obvious problems.

Substantial:

> >    The Shim6 sub-layer is implemented below the IPSec layer within the
> >    IP layer.  This deserves some additional considerations for a couple
> >    of specific cases: First, it should be noted that the Shim6 approach
> >    does not preclude using IPSEC tunnels on Shim6 packets within the
> >    network transit path.  Second, in case that IPSec is implemented as
> >    Bump-In-The-Wire (BITW) [7], either the shim MUST be disabled, or the
> >    shim MUST also be implemented as Bump-In-The-Wire, in order to
> >    satisfy the requirement that IPsec is layered above the shim.

Presumably the BITW implementation could also itself
filter out Shim6 control packets, in which case the
shim is never turned on.

> >    o  An attacker which is present on the path so that it can find out
> >      the context tags, can generate a R1bis message after it has moved
> >      off the path.  For this packet to be effective it needs to have a
> >      source locator which belongs to the context,

Really? What if CGA is used, must the R1bis even then come from a
previously known address?

Editorial:

> > In this case, it reccomended that the
...
> >    Shim6 follows the reccomendation defined in [28] and it informs the

Typos.

> > in order to allow the congestion
> > control mechanisms of the upper layers can react accordingly.

s/can/to/

> >    The Shim6 sub-layer is implemented below the IPSec layer within the
> >    IP layer.  This deserves some additional considerations for a couple
> >    of specific cases: First, it should be noted that the Shim6 approach
> >    does not preclude using IPSEC tunnels on Shim6 packets within the

Different capitalizations of IPsec, none correct.

Still continuing with the review. Sigh, its
a long document... I also noticed a few
things that forced me to go back in the document,
so don't be surprised about Section numbers
below 7.18.

Substantial:

(From Section 5.10)
> >  CGA Parameter Data Structure (PDS):  Included when the locator list
> >  is included and the PDS was not included in the I2/
> >  I2bis/R2 messages, so the receiver can verify the
> >  locator list.
(From Section 7.10)
> >  In
> >  particular, the R2 message includes the Responder's locator list and
> >  the PDS option.
(From Section 7.16)
> >  If a CGA Parameter Data Structure (PDS) is
> >  included in the message, then the host MUST verify that the actual
> >  PDS contained in the message corresponds to the ULID(peer) as
> >  specified in Section 7.2.

I am getting confused about when the PDS appears in the
message when not. 7.10 seems to say its always there;
7.16 allows it to not be there; 5.10 explains some
of the thinking. I think we need to be consistent with
these recommendations, perhaps fixing Section 7.10
language.

Same with Section 7.11 (sending I2) vs. Section
7.13 (receiving I2).

And 7.14 vs. 7.16 (for R2).

> > 7.18. Receiving R1bis messages and sending I2bis messages
> > (nothing about PDS)
> > ...
> > 7.20. Receiving I2bis messages and sending R2 messages
> >    ...
> >    If a CGA Parameter Data Structure (PDS) is included in the message,
> >    then the host MUST verify if the actual PDS contained in the message
> >    corresponds to the ULID(peer).

Inconsistent here, too.

> > 10.1. Sending Update Request messages
> >
> >
> >    When a host has a change in the locator set, then it can communicate
> >    this to the peer by sending an Update Request.  When a host has a
> >    change in the preferences for its locator set, it can also
> >    communicate this to the peer.  The Update Request message can include
> >    just a Locator List option, to convey the new set of locators (which
> >    requires a CGA signature option as well), just a Locator Preferences
> >    option, or both a new Locator List and new Locator Preferences.
> >
> > ...
> >
> > 10.4. Receiving Update Request messages
> >
> >    ...
> >    If a CGA Parameter Data Structure (PDS) is included in the message,
> >    then the host MUST verify if the actual PDS contained in the packet
> >    corresponds to the ULID(peer).  If this verification fails, the
> >    message is silently discarded.

Again, the text about sending the Update does not talk
about the PDS, while the receiving side does. This
needs to be consistent.

> > CGA Parameter Data Structure:  Included when the locator list is
> > included so the receiver can verify the locator list.

There should be some discussion in the introductory
parts of the document about the (non-)requirements to
use HBA/CGA addresses on both sides. My understanding
is that its OK for my multihomed host to have such
addresses and that Shim6 still works with a host on
the other side that only has one address. Right?

> >    A shim control message has the checksum field verified.  The Shim
> >    header length field is also verified against the length of the IPv6
> >    packet to make sure that the shim message doesn't claim to end past
> >    the end of the IPv6 packet.  Finally, it checks that the neither the
> >    IPv6 destination field nor the IPv6 source field is a multicast
> >    address.  If any of those checks fail, the packet is silently
> >    dropped.

Are multicast addresses only ones that need to be prohibited?
What about unspecified, link local unicast?

Section 10:

> >    If a CGA Parameter Data Structure (PDS) is included in the message,
> >    then the host MUST verify if the actual PDS contained in the packet
> >    corresponds to the ULID(peer).  If this verification fails, the
> >    message is silently discarded.

This is probably explained in more detail elsewhere, but the
above statement "correspond to the ULID(peer)" seems incorrect.
Lets assume we have locators L1, L2, L3, L4. Lets further assume
that ULID=L4. Now, we indeed need to verify that, e.g., the
HBA equations prove L1, L2, L3, and L4 are related. I guess
this can be stated as "PDS corresponds to the ULID(peer)".
But how does this work for CGAs? Lets assume for the sake
of argument that the CGA address = L1 and ULID is still L4.
This seems possible, but it no longer holds that "PDS
corresponds to ULID(peer)". Instead, you need to show
one of the two: each address in the list is either hash(key)
or the key has been used to sign the entire Update message,
showing willingness of the key owner to use these other
addresses.

Reformulation of this text is probably needed. It appears
in multiple places in the document, so make sure you fix
all places.

> > The host uses the Probe message in [9] to verify
> > that the new locator is reachable before changing Lp(peer).

The host uses the specific message, or runs the
entire protocol? If the former, please specify in
more detail the contents of the message.

> >    o  Other control messages (Update, Keepalive, Probe): Deliver to the
> >      context with CT(local) equal to the Receiver Context Tag included
> >      in the packet.  Verify that the IPv6 source address field is part
> >      of Ls(peer) and that the IPv6 destination address field is part of
> >      Ls(local).  If not, send a R1bis message.

Does this prevent properly handling a Probe if the peer
did not bother to / did not have time to report the
address as its own? I would expect that hosts might not
report all addresses, if they have many, and if there's
a sudden rehoming to a previously unknown prefix,
the host HAS to send a Probe from this previously
unknown address. This appears OK from a security
perspective, at least if we are using CGAs and not
HBAs.

Continuing with the review, Sections 6 - 7.17:

Substantial:

> >    o  For each peer locator, a flag whether it has been verified using
> >      HBA or CGA, and a bit whether the locator has been probed to
> >      verify that the ULID is present at that location.

Is there a need to remember *when* such probing has last
happened? If not, why not?

> >    o  The preferred peer locator - used as destination; Lp(peer)

First, this sentence was hard to parse. Second, preferred != the
one we are using as a destination. Please explain or
modify. Did you mean the current locator that we are using?
The failure-detection draft uses the term "current address
pair", so it would be good to align with that. I'm reading
on...

> >    o  The preferred local locator - used as source; Lp(local)

As above.

Continuing with the review, Section 5:

Substantial:

> >    o  For each peer locator, a flag whether it has been verified using
> >      HBA or CGA, and a bit whether the locator has been probed to
> >      verify that the ULID is present at that location.

Is there a need to remember *when* such probing has last
happened? If not, why not?

> >    o  The preferred peer locator - used as destination; Lp(peer)

First, this sentence was hard to parse. Second, preferred != the
one we are using as a destination. Please explain or
modify. Did you mean the current locator that we are using?
The failure-detection draft uses the term "current address
pair", so it would be good to align with that. I'm reading
on...

> >    o  The preferred local locator - used as source; Lp(local)

As above.

Continuing with the review:

Substantial:

>    The following options are defined for this message:
>
>    Responder Validator:  Variable length option.  Typically a hash
>                  generated by the responder, which the responder uses
>                  together with the Responder Nonce value to verify that
>                  an I2 message is indeed sent in response to a R1
>                  message, and that the parameters in the I2 message are
>                  the same as those in the I1 message.

(Appears in multiple places in the document).

Is the use of this option mandatory? What about its copying
on the other side, if it is present? Please clarify.

> Locator List Generation:  32-bit unsigned integer.  Indicates a
> generation number which is increased by one for each
> new locator list.  This is used to ensure that the
> index in the Locator Preferences refer to the right
> version of the locator list.

Are there requirements on keeping this generation counter
unique across reboots, or would rolling back not cause
a problem? Is there a window that one should be following?
Are generation counters unique per context tag?

>                            +-------+----------+
>                            | Value |  Method  |
>                            +-------+----------+
>                            |  0  | Reserved |
>                            |      |          |
>                            |  1  |    HBA  |
>                            |      |          |
>                            |  2  |    CGA  |
>                            |      |          |
>                            | 3-255 | Reserved |
>                            +-------+----------+

I'm reading on, but what if it is the kind of
a combined HBA and CGA as described in the shim6-hba
draft? Presumably you indicate HBA if the locator
is in the fixed set and CGA if its in the dynamic,
but it would be good to clarify this.

>    This option contains the CGA Parameter Data Structure (PDS).  When
>    HBA is used to verify the locators, the PDS contains the HBA
>    multiprefix extension.  When CGA is used to verify the locators, in
>    addition to the PDS option, the host also needs to include the
>    signature in the form of a CGA Signature option.

The Parameter Data Structure contains more than the
multiprefix extension, e.g., the public key, the
random bits instead of a public key for HBAs, and
any options unrelated to Shim6 that the CGA might
have. I would remove the second sentence above or
reword it to make sure that you really do include
the FULL CGA Parameter Data Structure.

Editorial:

>    included, the packet would become larger than 1280 bytes.Another

s/[.]/. /

>    0                  1                  2                  3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Next Header  |  Hdr Ext Len  |0|    Type    |Type-specific|0|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Checksum          |                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |
>    |                    Type-specific format                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Fields:
>
>    Next Header:  8-bit selector.  Normally set to NO_NXT_HDR (59).
>
>    Hdr Ext Len:  8-bit unsigned integer.  Length of the Shim6 header in
>                  8-octet units, not including the first 8 octets.
>
>    P:            Set to zero.  A single bit to distinguish this from
>                  the Shim6 payload extension header.
>
>    Type:          7-bit unsigned integer.  Identifies the actual message
>                  from the table below.  Type codes 0-63 will not
>                  trigger R1bis messages on a missing context, while 64-
>                  127 will trigger R1bis.
>
>    0:            A single bit (set to zero) which allows Shim6 and HIP
>                  to have a common header format yet telling Shim6 and
>                  HIP messages apart.

Here I got confused about the two 0's. The first one is P in the list,
the other one is "0". Maybe you need to set one of the zeroes in the
picture to something else (P or R), or add some text to make this
clearer.

I have started my AD review of this document. Please
find comments relating to Sections 1 through 4 below,
along with some tool-generated editorial issues.

Substantial:

Generally speaking I'm happy with the parts that I have
read so far. The text is easy to read and the reader
gets an accurate understanding of the Shim6 protocol,
its capabilities and limitations.

The only substantial question mark that I had was
here:

> > However, the precise
> > interaction between Mobile IPv6 and Shim6 is for further study, but
> > it might make sense to have Mobile IPv6 operate on locators as well,
> > meaning that the shim would be layered on top of the MIPv6 mechanism.
> > 
I worry that there's a circular dependency somewhere between
IPsec, Shim6, and MIPv6 if they all require something about
the placement of other layers on top or under them. Or is
Shim6 capable to be configured to run in different places
in the stack, e.g., inside and outside a tunnel, depending on
what the network manager wants?

This may be explained somewhere else...

Editorial:
> >        Figure 31: ICMP error handling with payload  extension header

Extra space.

> >  == Unused Reference: '4' is defined on line 5394, but no explicit reference
> >      was found in the text
> >
> >  == Unused Reference: '5' is defined on line 5397, but no explicit reference
> >      was found in the text
> >
> >  == Unused Reference: '12' is defined on line 5425, but no explicit
> >      reference was found in the text
> >
> >  == Unused Reference: '24' is defined on line 5464, but no explicit
> >      reference was found in the text
> >
> >  == Unused Reference: '25' is defined on line 5469, but no explicit
> >      reference was found in the text
> >
> >  == Unused Reference: '27' is defined on line 5476, but no explicit
> >      reference was found in the text
Please add references or remove the documents.

> >  ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443)
> >
> >  == Outdated reference: A later version (-03) exists of
> >      draft-ietf-shim6-hba-02
> >
> >  == Outdated reference: A later version (-08) exists of
> >      draft-ietf-shim6-failure-detection-07
> >
> >  == Outdated reference: A later version (-03) exists of
> >      draft-ietf-shim6-applicability-02
> >
> >  == Outdated reference: A later version (-08) exists of
> >      draft-ietf-hip-base-07
> >
> >  == Outdated reference: draft-ietf-mobike-protocol has been published as RFC
> >      4555
> > 
Please use the updated references.

> >                        was computed.  See [6]., [8].
Extra "."

> >    A, B, and C are hosts.  X is a potentially malicious host.
> >
> >    ...
> >
> >    CT(X) is a context tag assigned by X.

Wouldn't CT(A) be a more appropriate notation? Or are you
specifically saying that its the malicious host?

(1.a)  Who is the Document Shepherd for this document?
 
          Geoff Huston
         
      Has the Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this version is
      ready for forwarding to the IESG for publication?
     
          Yes

(1.b) Has the document had adequate review both from key members of
      the interested community and others? 
     
        Yes, the document has been explicitly called to the attention of
the Working Group on a number of occasions, and review comments
have been incorporated into the document.
                 
      Does the Document Shepherd have any concerns about the depth or
      breadth of the reviews that have been performed?
     
        The Document Shepherd is comfortable with the level of review of
this document.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective, e.g.,
      security, operational complexity, someone familiar with AAA,
      internationalization or XML?
     
        The document has been reviewed extensively over the past 15
months and the Document Shepherd is comfortable with the
competence and breadth of review of this document.
       
(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he or
      she is uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it.  In any event, if
      the interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.
     
        I do not have specific concerns, but I would like to highlight a
number of matters that have arisen in the Working Group and
elsewhere relating to SHIM6, and the manner of their resolution in
this protocol specification.
     
        The document has attracted comment over middleware checking the
integrity of the TCP header checksum. The Working Group consensus
was to recommend that middleware behaviour take into account the
presence of a shim6 payload header and modify their behaviour
accordingly. It was not established to what extent this is an
issue. Other alternatives relating to detection of middleware that
performs TCP/UDP checksum validation and additional flags in the
chim6 payload header were canvassed by the Working Group, but
recieved no clear support.

Working Group review noted that Bump-In-The-Wire (BITW) IPSEC is
incompatible with the default placement of the shim6 element in
the packet processing path. The Working Group position is that in
the case of BITW IPSEC it is mandated that shim6 must either be
disabled or implemented using the same BITW approach to preserve
the logival ordering of placing IPSEC processing immediately
"above" SHIM6 in the logical protocol stack flow.

Review of SHIM6 in other forums, noteably in the NANOG forum has
attracted the comment that there is no mechanism in SHIM6 for
site-based control, and placing this functionality in end hosts
rather than site edges was considered to be a sub-optimal
approach. The response to this is 2-fold: firstly the SHIM6 WG is
not chartered to develop a generic architecture for multi-homing,
but to work specifically on the architecure developed by the
Multi6 Working Group. Secondly, the Working Group has informally
explored extensions to the shim6 approach that may include
interaction with site edge routers, but at this stage the Working
Group sees this initial approach as being within its charter, and
that re-chartering the Working Group to explore such extenxions
may be appropriate once this initial "base" specification of the
shim6 approach has been completed.

A similar approach of deferring working on extensions to SHIM6
until the completion of this "base" specification also applies to
the consideration raised about interaction between upper level
protocol behaviour and SHIM6. The base specification has the
capability for context forking for individual connections in order
to permit individual connections to function with different
preferences for locator pairs. The manner of interaction between
the upper level protocol and SHIM6 is regarded as an extension to
the "base" specification.


(1.e) How solid is the consensus of the interested community behind
      this document?  Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

        The document has been reviewed from a range of perspectives and
has generated review comment from these perspectives. The
consensus behind this document appears to be well-founded.
       
(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)
     
        No

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
      enough; this check needs to be thorough.  Has the document met all
      formal review criteria it needs to, such as the MIB Doctor, media
      type and URI type reviews?
     
        Yes
       
        Reference [5] (RFC2463) now refers to an obsoleted spec - it
should be replaced with a reference to RFC4443 The update to this
document can be undertaken in the form of a note to the RFC
Editor.

There are a number of document typos. The list is:

page 14: s"[6]."[6]"
page 24: s"bytes.Another"bytes. Another"
page 40: s"field.Identifies"field. Identifies"
page 41: s"pruposes"purposes"
page 54: s"unstrucutred "unstructured"
page 64: s"recieve"receive"
page 70: s"The the"The"
page 72: s"The the"The"
page 82: s"extenson"extension"
page 82: s"porpuses"purposes"
page 88: s"reccomended"recommended"
page 88: s"reccomendation"recommendation"
page 88: s"presudoheader"pseudoheader"
page 88: s"header header"header"
page 92: s"the the"the"
page 94: s"[CGA] namespace registry"CGA Extension Type Values registry"
page 95: s"pruposes"purposes"
page 105: s"Tiemout"Timeout"
page 105: s"Tiemout"Timeout"
page 121: s"crtical"critical"
page 121: s"estbalishment"establishment"
page 121: s"recgnized"recognized"
page 121: s"strcuture"structure"
page 121: s"commnets"comments"
page 121: s"reccomendation"recommendation"
page 122: s"meesages"messages"
page 122: s"retransmision"retransmission"
page 122: s"respon der"responder"
page 122: s"renumberin"renumbering"
page 122: s"synchonized"synchronized"


        Additional changes to refer to related shim6 documents in an
informative manner have been proposed in the form of an RFC Editor
Note:
       
        Add the paragraph at the end of section 1 (and immediately before
section 1.1)

            "The applicability of the Shim6 protocol is considered in [24]. The
            architecture of this approach is described in [25]."
           
           
       
           
(1.h) Has the document split its references into normative and
      informative? 
     
        Yes
       
      Are there normative references to documents that are
      not ready for advancement or are otherwise in an unclear state?
     
        No
       
      If such normative references exist, what is the strategy for their
      completion?
     
        Reference [8] is being submitted to the IESG for publication with
this document.

        Reference [9] is being submitted to the IESG for publication with
this document.
       
      Are there normative references that are downward
      references, as described in [RFC3967]?  If so, list these downward
      references to support the Area Director in the Last Call procedure
      for them [RFC3967].
     
        No
         
(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document? 
     
        Yes
       
      If the document specifies protocol extensions, are reservations
      requested in appropriate IANA registries?
     
        Yes
       
      Are the IANA registries clearly identified?
     
        Yes
       
      If the document creates a new registry, does it define the proposed
      initial contents of the registry and an allocation procedure for
      future registrations?
     
        Yes
       
        Future registrations are allocated via "Standards Action"
       
        ** Code values 5 through 119 of the Shim6 Error Code registry
            are undefined. It is suggested that the following additon be made to the
            document on page 95:
           
            5 - 119    Allocated using Standards action
       
      Does it suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis]. 
     
        Yes
       
      If the document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG can
      appoint the needed Expert during the IESG Evaluation?
     
        N/A
       
(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML code,
      BNF rules, MIB definitions, etc., validate correctly in an
      automated checker?

        N/A
       

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

      Technical Summary

        This document defines the Shim6 protocol, a layer 3 shim for IPv6
that provides locator agility below the transport protocols. Shim6
provides IPv6 hosts in a multihomed site with failover and load
sharing properties, without assuming that a multihomed site will
have a provider independent IPv6 address prefix which is announced
in the global IPv6 routing table.  Shim6-enabled hosts in a
multihomed site will use the Shim6 protocol specified in this
document to setup state with peer hosts, so that the state can
later be used to failover to a different locator pair, should the
original pair stop working, while preserving the integrity of
active transport layer sessions.

      Working Group Summary

        The document has extensively reviewed by the Working Group. The
Working Group consensus was to recommend publication of this
document as a Proposed Standard.
       
      Document Quality

        There are known implementations of this specification, and there
have been no implementation experiences that have implied any
further revision to this specification is required.

Additional note:

        The document is being passed to the IESG as part of a set of three
documents that the Working Group has determined by consensus in
the WG Last Calls has requested to be published as Proposed
Standards. The Document Shepherd is aware that there have been
suggestions to publish initially as Experimental, and notes that
the Working Group Last Call specifically noted the intended
request to publish as a Proposed Standard, and this request is
based on that Working Group consensus position.
       
        The specification meets all the criteria of section 4.1.1 of RFC
2026, in that the specification is stable, has resolved design
choices, is believed to be well understood and has received
considerable community interest. The specification has no known
technical omissions.
       
        In addition, there are a number of implementations of the
specification, but little in the way of operational experience,
interoperability between implementations and interaction with
application behavior to report on at this stage.