APNIC gih@apnic.net Internet Shim6 I-D Internet-Draft This document provides an architectural description of the level 3 shim approach to site Multi-homing in IPv6 as described in , , , and , using as a framework for this analysis the approach described in . This initial draft has been prepared as a commentary on the Shim6 proposal as originally developed by a design team of the Multi6 Working Group, currently being further developed by the Shim6 Working Group. The document provides am architectural description of the approach, using the framework described in the multi-homing architecture document. The Shim6 specification is at an initial state, and there are areas where the documentation is incomplete. This architectural description is also incomplete at this stage, and will require further revision as the Shim6 approach is refined by the Shim6 Working Group. In addition, this initial draft does not analyze the properties of the HBA and CGA address types, and their role in providing some resilience against various forms of third party attacks. This analysis will be included in future revisions of this document.

As noted in the general architectural overview of approached to Multi-homing in IPv6 document, there are a number of general approaches to supporting site Multi-homing. These include the use of the routing system, use of mobility mechanisms, modification of existing elements in the protocol stack, or the introduction of a new protocol stack element, and the modification of behaviours of hosts and site-exit routers. This document provides an commentary of the Level 3 Shim approach to site Multi-homing (Shim6) as described in , , , and , using as a framework for this analysis the approach as described in .

The approach used by "Level 3 Shim for IPv6" (Shim6) is, as the name suggests, one that is based on the modification of the Internet Protocol stack element within the protocol stack of the endpoint. The modification is in the form of an additional functionality block, as indicated in .

+-----------------------------------------------------------------+ | Transport Protocols | +-----------------------------------------------------------------+ +-----------------------------------------------------------------+ | IP Protocol | | | | IP Endpoint ------ ------- -------------- ------------- | | sub-layer | AH | | ESP | | Frag/reass | | Dest opts | | | ------ ------- -------------- ------------- | | | | | Multi6 ===================== | | sub-layer ========> || shim6 insert || | | ===================== | | | | | IP Routing ------- | | sub-layer | IP | | | ------- | | | +-----------------------------------------------------------------+ Shim6 Protocol Stack (From )

Above the Shim6 protocol element the protocol stack uses constant endpoint identities to refer to both itself and to the remote protocol stack. The shim layer provider a set of associations between endpoint identity pairs and locator sets. As packets are passed from the IP Endpoint sub-layer to the IP Routing sub-layer, the endpoint identities are mapped to a current pair of locators. The reverse mapping is applied to incoming packets, where the incoming locator pair is stripped off the packet, and the associated endpoint identity pair is associated with the packet which is then passed to the IP Endpoint sub-layer. Demultiplexing the IP packet to the appropriate transport session is based on the endpoint identities. In this Shim6 approach the endpoint identities and the locators are both IP addresses. The endpoint identities are the initial addresses used between the two hosts. The locators are the set of IP addresses that are associated with the endpoint. The intention of this approach is to minimise the amount of change required to support dynamic locator agility in the protocol stack, and support dynamic locator agility as a negotiated endpoint-to-endpoint capability. An application can initiate a session with a remote host by using an entirely conventional lookup of the host's domain name in the DNS, and open up a session with the remote endpoint using one of its addresses as the destination address. The application can continue to exchange packets with this remote host for the duration of the session by continuing to use this destination address. If the local host subsequently opens up a new session with the same remote host, the same destination address may be used, or if the local host passes a reference to a third party as a referral, the same destination address may be used. In terms of semantics and functionality this represented no change to the use of addresses as endpoint identifiers in the IPv6 architecture. Shim6 operates as a per-host header address mapping function. When the Shim6 locator mapping function is activated for a remote endpoint packets passed from the IP endpoint sub-layer to the shim sub-layer have the packet's headers source and destination addresses rewritten with the currently selected locator pair. Incoming packets passed from the IP Routing sub-layer undergo a similar lookup using the locator pair. The packet header is rewritten with the mapped endpoint identifier pair is there is an active mapping entry. This functionality is indicated in . Here the endpoint identities are referred to as Upper Layer Identifiers (ULIDs), and the packet header addresses are referred to as Locators (L). The Shim6 element contains a context state, associating a ULID pair (in this case the pair [ULID(A),ULID(B)] with a set of locators for A and a set of locators for B. The shim elements are synchronised such that complementary mappings are performed at each end of the connection.

---------------------------- ---------------------------- | Sender A | | Receiver B | | | | | | ULP | | ULP | | | | | ^ | | | src ULID(A) | | | src ULID(A) | | | dst ULID(B) | | | dst ULID(B) | | v | | | | |---Shim6-----------------| |---Shim6-----------------| | | | | ^ | | | src L(A) | | | src L(A) | | | dst L(B) | | | dst L(A) | | v | | | | | IP | | IP | ---------------------------- ---------------------------- | ^ --------------- network path -- ------- Mapping with changed locators.(From )

The implication of the decision to place the endpoint identity-to-locator mapping protocol element within the IP element is that this mapping function is not implicitly aware of session start and tear down. At this level of the protocol stack there is no information to indicate wither this packet is a single datagram, or the start of an extended packet exchange with a remote entity. Similarly there is no explicit information provided to the shim protocol element to indicate when a session is complete, at which point the mapping state information could be discarded and the associated host resources reclaimed. This is offset by the advantages of this approach in that there is no explicit need to alter the function of any transport protocol, as the shim element continues to present constant endpoint identities to the upper protocol levels, irrespective of the current endpoint/locator mapping being used between the two hosts. Assuming that the initial choice of a ULID corresponds to a viable network path, the initial state of the Shim6 is a null mapping, as the ULID is also a viable locator. The use of alternate locators by the Shim6 is a triggered response, based on a network path unreachability signal.

There are a number of options in the choice of an endpoint identity realm, including the use of existing addresses as an identity tokens, the use of distinguished (possibly non-routeable) addresses as tokens, or the use of tokens drawn from a different realm (such as use of a fully qualified domain name). Shim6 uses the first of these options, and the endpoint identity for a host is one of the locator addresses that are normally associated with the host. The particular locator address selected to be the endpoint identity (or ULID) is specified in . Shim6 does not mandate the use of distinguished addresses as identities, although the use non-routeable distinguished addresses in this context is described as an option in this approach. The Shim6 approach defines the initial selector of the locator addresses pair is to be the same as the ULID pair. Accordingly, the initial state of the multi6 shim element is a null transform. This allows the initial establishment of a transport session without the requirement to perform a multi6 capability negotiation. The choice of a locator as the endpoint identity for the upper protocol layers implies there is no impact in terms of implied changes to transport protocols or the upper level applications. Applications can continue to resolve fully qualified domain names to a set of addresses, and then open a session with the remote party specifying a selected address as the address of the remote party. The addresses used as source and destination identifiers can continue to be used in the context of pseudo-header checksums, session demultiplexing, packet reassembly contexts following fragmentation, IPSEC security associations, callbacks and referrals, all without alteration. The use in callbacks and referrals can be further generalised to the use of these address in the application payload. Irrespective of any subsequent change in the locator pair, the protocol stack above the Level 3 shim element will continue to use the original ULID pair, and any use of these values in payloads will continue to match the endpoint identities.

What form of token is passed to the IP layer from the upper level protocol element as an identification of the local protocol stack? There is no requirement to change the conventional behaviour of the protocol stack. The upper protocol level may use a specified address as a source address, or the upper level may explicitly defer the selection of a source address to the IP level. Conventionally, the selected source address is the IP address of the outbound interface that the IP protocol will use to send the packet towards the destination address. In the case of an Shim6-enabled stack, the source address selection function would need to consult a local state as to whether the destination address is associated with a currently active M6 state (interpreting the destination address as a ULID). In this case the selected source address, as seen by the upper level protocol stack element is the ULID of the stored state associated with the destination ULID. Otherwise the selected source address is a selected IP address from the set of addresses associated with the particular host interface that will be used to send the packet, as happens in a conventional IPv6 protocol stack. What form of token is passed to the IP layer from the upper level protocol element as an identification of the remote session target? The token passed to the IP layer as the ULID of the destination is the address of the destination host. If the initial identification of the remote host is via a domain name, then this approach assumes that there are a one or more locators held in the DNS. The local host to performs a name-to-address DNS lookup to obtain a set of locators (recorded in the DNS using AAAA resource records). The host then performs a selection from this set of locators and uses the selected address as the identification of the remote host. This implies no change to the conventional behaviour of the IP protocol stack element. What form of token is used by the upper level protocol element as a endpoint identification mechanism for use within the application payload? There is no change to the existing behaviour in this approach. The upper level protocol element may use a domain name, or an IP address as an identification token. Does the identity protocol element need to create a mapping from the upper level protocol's local and remote identity tokens into an identity token that identifies the session? If so, then is this translation performed before or after the initial session packet exchange handshake? In looking at the interface between the application level and the transport level of the protocol stack, there is no requirement to create a mapping between the upper level identifiers and the session identifiers, as the session identifiers are the same upper level identifiers. In looking at the interface between the transport and internet protocol stack elements, then the Shim6 element has to check if there is an already established Shim6 state that is associated with the ULIDs of the packet being sent. If so, then the translation from the ULID pair to the currently active locator pair is performed by the Shim6 protocol element. If not, then no state is created and no mapping is performed. This infers that an initial session packet exchange handshake is supported without the requirement to establish an identity to locator mapping state. How does the session initiator establish that the remote end of the session can support the multi-homing capabilities in its protocol stack? If not, does the multi-homing capable protocol element report a session establishment failure to the upper level protocol, or silently fall back to a non-multi-homed protocol operation? The session initiator determines the ability of the remote end to support the Shim6 protocol via explicit negotiation. The Shim6 protocol will continue to operate in a conventional mode if the capability negotiation fails for Shim6 support. The nature of the communication exchange to determine the capability to use Shim6 support is not described in . How do the endpoints discover the locator set available for each other endpoint (locator discovery)? The mechanism is by explicit exchange of locator sets between the hosts. The Shim6 description does not describe the precise mechanism. Section 6 of notes that once the initial capability exchange has completed "both ends know a set of locators for the peer that are acceptable as the source in received packets." This explicit exchange of locators is not necessarily aligned to multiple AAAA Resource records in the DNS. What mechanisms are used to perform locator selection at each end for the local selection of source and destination locators? The initial choice of source and destination locators matches the initial choice of upper level identifiers, namely the initial addresses used as the upper level identifiers. The remote address is obtained using conventional DNS lookup. The local address is based on an address selection from the addresses associated with the outbound interface, using the procedure described in . What form of mechanism is used to ensure that the selected site exit path matches the selected packet source locator? This is not described in the current Shim6 description.

What triggers are used to identify that a switch of locators is desirable? The Shim6 documentation covers a number of options, but does not provide definitive answers to this question. The notes four approaches: namely positive feedback from the upper level sessions, negative feedback from the upper level sessions, explicit reachability tests and ICMP error messages. From the discussion in this draft it appears that negative feedback from upper layer transport sessions in the form of ACK timeouts is the preferred locator change trigger mechanism. Are the triggers based on the end-to-end transport session and/or on notification of state changes within the network path from the network? argues that network path-based triggers, in the form of received ICMP errors messages are prone to spoofing, and should only be used "as a hint to perform an explicit reachability test". Triggers are based on explicit negative information being passed from an active transport session (ACK timeouts). There is also the possibility of using positive feedback from the transport sessions, where a timeout of positive indication is an indication of a reachability problem. In this case, as with ICMP, an explicit reachability test is required to confirm the indication of locator failure. What triggers can be used to indicate the direction of the failed path in order to trigger the appropriate locator repair function? The description does not provide a description of detection of the failed path. The Shim6 approach attempts to treat path failure as a failure of the locator pair, rather than failure of a single locator, so the direction of the failure is not necessarily critical information in the search for a new functional pair.

What parameters are used to determine the selection of a locator to use to reference the local endpoint? The selection of a locator is based on the application of the tables as described in RFC 3484 . The approach also allows local policy settings to place a preference for particular locator pairs. Selection of a specific locator pair is based on the successful outcome of a return reachability test between the two endpoints. If the remote endpoint is multi-homed, what parameters are used to determine the selection of a locator to use to reference the remote endpoint? Same as the previous response. Must a change of an egress site exit router be accompanied by a change in source and / or destination locators? This appears to be an area for further study. The situation is not explicitly addressed in the Shim6 documentation. How can new locators be added to the locator pool of an existing session? The explicit Shim6 capability negotiation allows the two endpoints to exchange a set of locators as part of the initial setup. This set is then tested, as required, using explicitly reachability tests when the endpoints are searching for a viable locator pair. The outcome of locator pair reachability tests are stored in an ageing local cache. This allows recently tested pairs that passed the reachability test to be used in preference to untested locator pairs. describes a set of abstract message exchanges for Shim6 locator set maintenance that includes explicit "add" and Delete" commands to allow a host to instruct the remote end to add or remove locators from its locator set.

What are the preconditions that are necessary for a locator change? The preconditions necessary is that there has been a successful establishment of packets between the two hosts, Shim6 capabilities have been successfully negotiated and locator sets have been exchanged, and there is an explicit trigger for a locator change that has been generated by an active transport session. IN addition reception of a packet where the locator par is a member of the locator set for this host pair implies a remotely-triggered locator change. How can the locator change be confirmed by both ends? The approach proposed here is by using a return reachability test, where a host searches through locator pair selections until it receives an explicit acknowledgement of a poll. What interactions are necessary for synchronisation of locator change and transport session behaviour? As noted in , there is consideration that any locator change in the Shim6 state should trigger a notification to the transport layer protocol. In the case of TCP this notification would be used to trigger a resetting of the TCP congestion state to slow start, corresponding to the selection of a new network path.

How is identity / locator binding state removal synchronised with session closure? As this is a layer 3 function there is no explicit concept of sessions. A Shim6 mapping state needs to be maintained for as long as there is packet activity in either direction. The removal of state would most likely be associated with a removal eligibility condition associated with a packet activity timeout, and an eligible state removal pass being undertaken by the Shim6 statement management module. What binding information is cached for possible future use? The Shim6 state information is the association of a ULID pair with a set of local and remote locators. This information may require periodic refreshing with the exchange of locator sets with the remote host in order to ensure that the remote host is also maintaining a Shim6 state, and the locator sets are synchronised.

The approach of using a IP layer mapping between upper level endpoint identity and lower level locators has a number of specific issues that have yet to be fully specified in the Shim6 documentation. Some of these are listed here. The signalling interface between the Shim6 and the upper layers pf the protocol stack requires further consideration. The decision to initiate a Shim6 capability negotiation with a remote host may benefit from an explicit upper layer signal to the shim protocol element. In turn this could allow applications to signal a desire to initiate this capability negotiation at the start of an extended communication session. Equally, it may be of benefit for the upper level protocol to be able to query the L3 state for a particular remote host, to establish whether there has been a capability negotiation performed, and if successful, the current active locator and the full locator set. It may also be useful to allow the upper level protocol to explicitly indicate that any form of L3 functionality should not be applied to this session. The implication of this functionality is that incoming packets need to provide some form of positive indication that the incoming locator pair should be mapped to an equivalent ULID pair, while packets without this indication should be processed in a conventional fashion with any Shim6 packet header mapping. The Shim6 documentation suggests that some form of explicit tagging should be performed in the IPv6 Flow Id field, but further details have not been provided. The potential use of unreachable ULIDs as the initial choice of ULIDs and the consequent requirement to undertake a reachable locator search, capability negotiation and establishment of a Shim6 mapping state is mentioned in the Shim6 documents, but at a relatively abstract level. This requires further consideration in terms of the potential failures, and the appropriate signalling to be passed back to the ULP in such cases. The issue of ambiguity of demultiplexing may require further consideration. If there are multiple AAAA resource records in the DNS, or the resource records change over the lifetime of active communication, it is possible to have multiple Shim6 states set up for the same remote host, with distinct ULIDs for the remote host. An incoming packet with a given locator pair will, according to the Shim6 documentation, need to use the locator pair as a lookup key into the Shim6 state information to establish the associated ULID pair. In the case of multiple active ULIDs for the same remote host this lookup will result in multiple ULIDs. The treatment of trigger conditions for locator change also requires further consideration. As noted in , different upper level transports may have different sensitivity requirements to locator triggers. When the mapping is performed on a host-by-host basis rather than per transport session, there is a consequent requirement to balance the relative levels of sensitivity to locator change across all concurrently active transport session. It may be necessary to explore the concept of associating a Shim6 state to particular transport sessions, allowing each session to establish its preferred level of sensitivity to network events that may trigger a locator change. The interaction between locator pair selection, local forwarding decision, site exit routers and packet ingress filters on the immediately adjacent upstream provider routers does not appear to be considered in the current Shim6 documentation.