IETF News

IETF64 Review: SHIM6

By: Geoff Huston

Date: December 7, 2005

line break image

It’s always handy in a working group to have had some other working group do all the heavy lifting in terms of defining the problem, sorting out requirements, looking at the threats and documenting the basic architectural issues. In the case of SHIM6 this includes working through a relatively hefty collection of candidate proposals and identifying an approach that appears to offer the most promise. In the case of SHIM6, much of the work was already undertaken by its predecessor, the MULTI6 working group, which looked at the more general topic of multi-homing in IPv6.

So to briefly recap here over some well covered territory, when the scaling issues with the Internet were examined in the early 1990′s, two basic problems were identified. The first was that the IP environment was indeed running out of addresses, and secondly that the routing space was running out of capacity. The interim approach was to adopt a new address architecture in IPv4 that removed the ‘class-based’ semantics of an address, and instead used an explicitly specified prefix length for all address prefixes. The longer term approach was to work on a protocol specification that extended the address space significantly. The approach adopted by the IETF in this new protocol was a relatively conservative one that extended the address space from 32 to 128 bits, but made no other basic changes to the IP architecture. So the question remained on the table: how do you solve the routing capacity problem in IPv6?

The response to this open question has been to devise address allocation policies that lean very heavily towards provider-based address aggregation. In other words the response to the routing capacity problem has been to attempt to adopt strict policies that suppress the advertisement of more specific prefixes in the inter-domain routing space and instead attempt to work from the basic premise that the inter-domain routing space will be populated exclusively by Internet service provider aggregate prefix advertisements.

This approach raises a number of issues around the concepts of protocol support for services that support mobility, nomadism and multi-homing. Indeed these topics are all artefacts of a more basic and long-standing issue in the IP architecture: IP managed to combine the concepts of network level identity, network level location and network level packet forwarding into one object, namely that of an IP address. In other words the basic concepts of who, where and how are all encompassed in a single IP address. When you need to split these concepts apart and separate the ‘who’ from the ‘how” or the ‘where’, then the work gets quite challenging. So far we’ve managed to put a name to the general class of the problem, and these days when you hear the term ‘id/loc split’, you’ve just heard a reference to this issue of the overloaded semantics of an IP address.

SHIM6 is concerned with a particular aspect of this more general topic of the disambiguation of identity and network location, namely that of a collection of inter-connected hosts, or a ‘site’, that uses multiple service providers for connectivity services, and where the site exclusively uses address prefixes drawn from these upstream providers. In other words the ‘site’ is ‘homed’ with multiple service providers.

The approach used in IPv4 was that of using a unique address prefix for the site (preferably an address that is not part of any provider’s address prefix), and announcing reachability to this address prefix to all upstream providers simultaneously. The global inter-domain routing system is used to stitch all this together, and provide, hopefully, seamless and reliable connectivity such that even when there is a failure in the services provided by one or more of the upstream providers, basic connectivity is maintained, and application level connectivity is maintained and no application needs to be aware that there are multiple upstream providers, or even when the underlying network paths switch between these providers. This works relatively well, but at the expense of the scalability of the routing system. While the global routing system today can support some tens of thousands of multi-homed end-sites, most folk would agree that current technologies and deployed equipment would be incapable of scaling this to numbers of the order of tens of millions of such multi-homed sites, and some folk would be worried even at numbers in the hundreds of thousands.

So is there a way in IPv6 to avoid overloading the routing system with provider-independent address prefixes, and still preserve the essential functionality of multi-homing? To enter into one level of further detail, the objective can be phrased as how to support IPv6 end-site configurations that have multiple external connections to support application-level session resiliency across connectivity failure events, and how to use IPv6 multi-addressing and connection-based address aggregates to avoid overloading the routing system with site-based specific address advertisements.

It was this general question that was studied in the multi6 working group, and a very wide diversity of approaches was evaluated by the working group. The approach selected by the multi6 working group, the so-called “Level 3 Shim” is the approach that the SHIM6 Working Group is tasked to complete.

The major aspect of this approach is that no provider-independent address is assumed, and each host within the site obtains an address from the router advertisements corresponding to each upstream provider’s address prefix. Each host will use one of these addresses as its source address, and when it is talking to a remote host who also has multiple address prefixes, it will chose the first ‘working’ address as the chosen destination address, where ‘working’ is interpreted as an address that elicits a response. The basic approach of initial contact in a multi-addressed configuration is documented in RFC 3484.

The challenge here is not in the initial contact, but further on, when there are one or more active application sessions using a particular provider’s address prefix, and the network path of that provider fails. How is this failure detected? How is a ‘working’ prefix identified? And how can the local host switch across to working addresses without disrupting the operation of any of the active upper level sessions? And how can this address agility functionality be provided in a secure fashion that is resilient to various forms of hostile attack?

The approach, like most other approaches to this problem space, uses a rewriting of the protocol header part of the protocol data unit (PDU), substituting a ‘working’ address in place of the upper level address in a manner that is not directly visible to the upper level protocol state. In other words the upper level protocols perform a rendezvous using an ‘identity’ which is preserved across the life of the protocol session, while the lower level of the protocol stack substitutes a ‘locator’ in place of this identity before passing the packet into the network, and perform a reverse substitution when receiving a packet from the network.

The SHIM6 approach has made a number of specific design decisions in order to devise a prototype model. The identity/locator substitution is performed within the host’s own protocol stack, rather than remotely in an edge router or in some other remote network-level agent. Secondly, this mapping between identities and locators, and associated state information, is maintained at the IP level of the protocol stack in the host, implementing a host-to-host context of this mapping, in preference to a transport-level mapping. Thirdly this is a dynamically negotiated capability, and is only activated after a certain threshold of time or quantity of packet exchange has already taken place. And, finally, there is no new identifier space associated with this design – the addresses used to make initial contact with the remote host are nominated as the persistent identity tokens once the SHIM module is activated.

The basic operation of SHIM6 is that of a functional module located at the IP level of the protocol stack, where there is no explicit knowledge of transport level session establishment or tear-down. At this level there are simply packets being passed between the local host and remote hosts, where the remote host is identified by the destination address in the PDU passed through the SHIM6 module. Initial contact with a remote host elicits no particular SHIM6 response. The application is expected to undertake a pass through all address pairs in order to achieve confirmed contact, in the manner specified by RFC 3484. Only when a certain communication threshold has been achieved with the remote host (by time, packet counters or some combination) will the local shim module attempt to establish a shared state with the remote host. This entails an initial handshake with the remote host to confirm that the remote host is also equipped with this model and is prepared to activate it on this host-pair. The modules then exchange a currently active set of locators or each host, and then drop into a passive failure detection mode. In the event of a detected failure of the current locator pair the shim6 modules will test the locator pool in order to establish a new working locator pair. Once this is confirmed the shim6 module is now activated, and all subsequent packets sent to the remote host will have a shim context packet header added to the packet, and the source and destination addresses of the packet altered by the shim module to the value of the currently active locator pair.

At some future point, using a local trigger based on an inactivity timer, or some other local condition, the local host will garbage collect the shim context for a remote host, and any subsequent locally-initiated contact will follow the same process.

SHIM6 is chartered to complete the specification of this particular protocol to a level of a Proposed Standard, such that independently developed implementations of the specification interoperate in an acceptable fashion. It is also chartered to complete an architectural description of the technology, as well as documenting the anticipated applicability of the approach.

The approach taken by the working group is to make a number of very conservative design decisions in order to complete an initial base protocol specification, and once this is complete to then explore a number of refinements that may include areas of support for a richer bi-directional signalling path between the shim module and cooperating upper level protocols, particularly including considerations of the transport-level session interaction with the shim module, support for site-based traffic engineering directives or preferences, support for initial contact-less SHIM6 (i.e. allow the upper level protocol to use identifiers from the outset where the identifiers do not also function as working locators) , support for various refinements in failure detection, support for rapid locator failover, and explore the space associated with the problems of source address-based ingress filtering and the associated issue of source address selection by the host.

As can be seen by the length of this supposedly short introduction to SHIM6, this is a relatively rich area of study, with both a long history, reaching back to proposals such as ’8+8′ and ‘GSE’, and a diverse current activity profile today with efforts including MobileIPv6, MANET, SCTP and HIP. This is perhaps to be expected, as the original binding of identity and location within the semantics of an IP address was indeed a fundamental part of the IP architecture. When we explore ways in which to uncouple this tight association of identify and location in an IP address it’s not clear that any of these approaches, either currently or previously studied, will turn out to be the uniquely ‘right’ approach. There are a set of constraints that are proving challenging to reconcile, including security, resilience against hostile attack, simplicity in host stacks, uniformity of routing, host agility, site policies, traffic engineering, service performance, adaptive responses to various transport and application profiles, to name but a few.

As we progress in SHIM6 to complete the base protocol specification and then as we explore various forms of refinements and extensions to this approach, I’m sure that there will be much more to learn here about what is possible with an IP architecture that makes a clearer distinction between the ‘who’, the ‘where’ and the ‘how’ of networking.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *