TOC 
Network Working GroupS. Barré
Internet-DraftO. Bonaventure
Expires: August 14, 2009UCLouvain, Belgium
 February 10, 2009


Shim6 Implementation Report : LinShim6
draft-barre-shim6-impl-02

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 14, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts.



Table of Contents

1.  Introduction
2.  General architecture
    2.1.  Kernel patch
    2.2.  LinShim6 daemon
        2.2.1.  Random number generation
        2.2.2.  HBA/CGA support
    2.3.  Locator updates
    2.4.  Context removal
3.  RFC 2119 evaluation
    3.1.  Checks common to all control messages
    3.2.  I1 Message
    3.3.  R1 Message
    3.4.  I2 Message
    3.5.  R2 Message
    3.6.  R1bis, I2bis
    3.7.  Update Request(UR)/Acknowledgement(UA) messages
    3.8.  Keepalive and Probe Messages
    3.9.  Keepalive Timeout Option
    3.10.  Error messages
    3.11.  Message Options
    3.12.  Payload data
    3.13.  General requirements of the Shim6 draft
    3.14.  General requirements of the REAP draft
4.  Protocol conformance by feature
5.  Conclusion and further work
6.  Acknowledgments
7.  References
§  Authors' Addresses




 TOC 

1.  Introduction

The Shim6 protocol [I‑D.ietf‑shim6‑proto] (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” Feb 2009.) has been designed to add multihoming capabilities to IPv6, while avoiding the drawbacks of current IPv4 multihoming practice (prefix announcements in BGP), and giving more control to the end host (through locator selection).

Together with the Shim6 protocol, the working group has designed a failure detection mechanism, called REAP [I‑D.ietf‑shim6‑failure‑detection] (Arkko, J. and I. van Beijnum, “Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming,” Jun 2008.), that allows hosts to detect and recover from failures, thanks to a combination of traffic monitoring and active probing.

Implementing such new protocols is crucial to allow tracking errors or weaknesses in the overall design, as well as evaluating protocol behaviour in the real world. We developped an implementation of Shim6 and REAP, available from http://inl.info.ucl.ac.be/LinShim6. LinShim6 has been used to evaluate the performance of REAP path exploration [BARRE07] (Barré, S. and O. Bonaventure, “Improved Path Exploration in shim6-based Multihoming,” Aug 2007.).

This draft is aimed at describing the challenges of a proper integration of Shim6 in a protocol stack while preserving its efficiency. LinShim6 supports the base Shim6 protocol (negotiation and address rewriting) as well as failure detection and recovery (REAP). To our knowledge LinShim6 is also the first publicly available implementation that supports both the HBA and CGA mechanisms for securing the locator set exchange (the CGA/HBA code is derived mostly from the DoCoMo SEND project).

In this draft, we present a detailed report of the supported parts of the protocol, in terms of the terminology defined in section 2 of [I‑D.ietf‑shim6‑proto] (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” Feb 2009.). Some non critical features for the current application of LinShim6 have not been implemented yet. They will be added as soon as a need for them arises. For instance, the Forked Instance Identifier is only useful if a socket API is implemented (such as the API defined in [I‑D.ietf‑shim6‑multihome‑shim‑api] (Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, “Socket Application Program Interface (API) for Multihoming Shim,” Nov 2008.)). The Locator Preference Option may only be used if the corresponding tuning capability is provided, either by the user or by an automated technique.

Other features will be supported in a future version of the implementation. These are detailed in Section 4 (Protocol conformance by feature).

This draft describes version 0.9 of LinShim6.



 TOC 

2.  General architecture

The LinShim6 implementation is composed of two parts. First, a kernel patch adds support for shim6 negotiation trigger, address rewriting and failure detection. Second, a daemon is responsible for the management of the Shim6 control plane (negotiation, path exploration). The kernel communicates with the user space daemon through the Netlink interface [RFC3549] (Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, “Linux Netlink as an IP Services Protocol,” Jul 2003.).

Hereafter we briefly describe the kernel and user level part of LinShim6. A more extensive description can be found in [BARRE07b] (Barré, S. and O. Bonaventure, “Implementing SHIM6 using the Linux XFRM framework,” Dec 2007.) or [BARRE08] (Barré, S., “LinShim6 - Implementation of the Shim6 protocol,” Feb 2008.).



 TOC 

2.1.  Kernel patch

The default negotiation trigger makes use of the NF_IP6_LOCAL_IN and NF_IP6_LOCAL_OUT netfilter hooks to listen to the packets travelling through the networking stack. A Shim6 negotiation is triggered by default when either 2 KB of data have been seen for a given address pair or the flow exists for one minute. Those values have been chosen through observation of netflow traces, showing that more than 80% of the observed traffic last less than 1 minute, and also 80% is less than 2 KB in size. This default heuristic thus appeared as a reasonable discriminator to avoid starting a Shim6 negotiation when it is not needed. In some cases (e.g. heavily loaded servers), one may want to never trigger a Shim6 context establishment, except if it is explicitly requested by the peer. This is possible by simply not loading the heuristic module. One can also define its own heuristic, by designing a customized module.

Address rewriting is implemented as an extension to the XFRM framework, originally designed for IPsec [KANDA04] (Kanda, M., Miyazawa, K., and H. Esaki, “USAGI IPv6 IPsec development for Linux,” Jan 2004.). The XFRM framework allows for dynamically adding a new sublayer in the Networking stack for some flows, according to a policy. Examples of already defined sublayers are the AH sublayer (Authentication Header) or the ESP sublayer (Encapsulating Security Payload). Similarly, we define a new sublayer for Shim6. The policies responsible for directing packets to this new module are communicated from the daemon to the kernel through Netlink, when a change in the locators is needed or a new Shim6 context is created. For outgoing packets, the policy takes the form of a matching rule with the ULIDs (Upper Layer IDentifiers, defined in [I‑D.ietf‑shim6‑proto] (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” Feb 2009.)). For incoming packets that do not have the Shim6 extension header, the same kind of matching rule is used. We also defined a matching rule based on the context tag, in order to be able to demultiplex tagged incoming packets.

Failure detection is performed inside the kernel for efficiency reasons: a timer must be started or stopped for each incoming or outgoing packet. We maintain REAP failure detection timers inside the XFRM states, so that the daemon is notified (through Netlink) when a keepalive must be sent or an exploration is to be started.



 TOC 

2.2.  LinShim6 daemon

The daemon continuously listens to three types of events. First, Shim6 and REAP control messages are received through a raw socket. Second, Netlink messages provide information from the kernel, for example whether a context must be created, a keepalive must be sent or an exploration must be started. Finally, messages can be received through a pipe where the other threads may write commands. Four threads are currently defined:



 TOC 

2.2.1.  Random number generation

We generate random numbers based on the Linux random() function, with a seed taken from /dev/random when the daemon starts, and every 1000 generation.



 TOC 

2.2.2.  HBA/CGA support

The user is able to set HBA and CGA parameters thanks to a configuration file. A tool (cgatool), derived from the DoCoMo SEND project, allows for manual generation of CGA keys, CGA addresses and HBA addresses. Four types of addresses can coexist in an end-system: unsecured, HBA, CGA and CGA-compatible HBA. It is up to the applications to decide which address is used as ULID for a given communication. If the application chooses the unspecified source address, then the kernel applies RFC3484[RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” Feb 2003.) rules to pick a suitable source address from the available set. When performing the locator set exchange, LinShim6 decides what locators to use in the local locator set based on the ULID type:



 TOC 

2.3.  Locator updates

During the lifetime of a Shim6 context, locators may appear or disappear. If a new locator becomes available in the system, all peers are updated (except if the new address cannot be added to some of the contexts, according to the rules described in Section 2.2.2 (HBA/CGA support)). As required by [I‑D.ietf‑shim6‑proto] (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” Feb 2009.), the new locator starts being actually part of a Shim6 context only when the new locator set has been aknowledged by the peer.

On the other hand, when a locator disappears, it is immediately removed from all contexts and a locator update is sent to the peer. It does not make sense to wait for the acknowledgement in that case, since the locator is not reachable anymore. Moreover, if the removed locator is current for any context (that is, actually used for sending packets), a REAP path exploration is triggered.



 TOC 

2.4.  Context removal

As mentioned in the previous section, a context is removed upon reception of an XFRM event from the kernel, indicating that no traffic has been seen for that context during at least 10 minutes. The daemon then cleans up all data related to the expired context, both in the daemon and in the kernel. Shim6 kernel state is also cleaned everytime the daemon is started to avoid inconsistency.

In the future, we will also check if no opened socked is using the context before removing it. This will avoid the current possibility that a context gets stalled, if it remains idle during more than 10 minutes and then tries to send data again.



 TOC 

3.  RFC 2119 evaluation

In this section we detail the conformance of the LinShim6 implementation in terms of the RFC2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” Mar 1997.) terminology. Additionally, we define hereafter the keywords that are used to describe the level of support for the different features.



 TOC 

3.1.  Checks common to all control messages

A host MUST silently discard any received control message that does not statisfy all of the following validity checks:



 TOC 

3.2.  I1 Message



 TOC 

3.3.  R1 Message



 TOC 

3.4.  I2 Message



 TOC 

3.5.  R2 Message



 TOC 

3.6.  R1bis, I2bis

Those messages are not supported yet. They are ignored on receipt.



 TOC 

3.7.  Update Request(UR)/Acknowledgement(UA) messages



 TOC 

3.8.  Keepalive and Probe Messages



 TOC 

3.9.  Keepalive Timeout Option



 TOC 

3.10.  Error messages

FEATURE NOT SUPPORTED



 TOC 

3.11.  Message Options



 TOC 

3.12.  Payload data



 TOC 

3.13.  General requirements of the Shim6 draft



 TOC 

3.14.  General requirements of the REAP draft



 TOC 

4.  Protocol conformance by feature

In the following list we make a division of the Shim6 specification into several features, in order to easily identify which of them are supported and which are not.



 TOC 

5.  Conclusion and further work

This draft describes the current state of the LinShim6 implementation, version 0.9. It uses a heuristic to decide whether to trigger a Shim6 negotiation, and it is able to monitor the state of the communication thanks to the REAP state machine. It has been shown to successfully support the switch to an alternative locator pair, and it is the first known Shim6 implementation that supports HBA and CGA. LinShim6 is still under development. We aim at finally providing the complete set of features. In the near future we will work on context recovery and error messages. Other missing features seem to have a lower priority and are left for later.

We have established an exhaustive listing of supported and unsupported elements of the protocols, which appears as making much easier to verify the level of support and security of the protocol.



 TOC 

6.  Acknowledgments

Sébastien Barré is funded by Trilogy, a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document.

Part of this work has been supported by a grant from FRIA (Fonds pour la Formation à la Recherche dans l’Industrie et dans l’Agriculture, rue d’Egmont 5 - 1000 Bruxelles, Belgium).

John Ronan reviewed this document and provided comments. He also spent many hours testing the code in many different scenarios, giving valuable feedback and helping in several tricky bug fixes. His help has been very invaluable to improve LinShim6 overall stability.

Matthijs Mekking has written a wireshark patch for Shim6, that has been very helpful in testing the implementation, and also used LinShim6 himself and provided feedback.

The CGA/HBA support, cgad and cgatool benefitted from much code from the DoCoMo SEND implementaion, the clarity of the code made extension and adaptation for LinShim6 very effective.

Francis Dupont has written the very first known implementation of HBA. Although we have written a second one based on DoCoMo SEND project, Francis Dupont's work, and especially his test suite, has been used to validate our HBA module.

Other people has helped getting things better by comments, bug reports, or discussions: Lu Junxiu, Martin Kulas, Aaron Kunde, Sazzadur Rahman, Iljitsch van Beijnum, Marcelo Bagnulo, James Swan, Shinta Sugimoto, Masahide Nakamura, the INL team.



 TOC 

7. References

[I-D.ietf-shim6-proto] Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” draft-ietf-shim6-proto-12 (work in progress), Feb 2009.
[I-D.ietf-shim6-failure-detection] Arkko, J. and I. van Beijnum, “Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming,” draft-ietf-shim6-failure-detection-13 (work in progress), Jun 2008.
[I-D.ietf-shim6-multihome-shim-api] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, “Socket Application Program Interface (API) for Multihoming Shim,” draft-ietf-shim6-multihome-shim-api-07 (work in progress), Nov 2008.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, Mar 1997.
[RFC3484] Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” RFC 3484, Feb 2003.
[RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, “Linux Netlink as an IP Services Protocol,” RFC 3549, Jul 2003.
[KANDA04] Kanda, M., Miyazawa, K., and H. Esaki, “USAGI IPv6 IPsec development for Linux,” in International Symposium on Applications and the Internet,  pp. 159-163, Jan 2004.
[BARRE07] Barré, S. and O. Bonaventure, “Improved Path Exploration in shim6-based Multihoming,” in SIGCOMM 2007 Workshop "IPv6 and the Future of the Internet", Kyoto, Japan, Aug 2007.
[BARRE07b] Barré, S. and O. Bonaventure, “Implementing SHIM6 using the Linux XFRM framework,” in Routing In Next Generation workshop, Madrid, Spain, Dec 2007.
[BARRE08] Barré, S., “LinShim6 - Implementation of the Shim6 protocol,” Feb 2008.


 TOC 

Authors' Addresses

  Sébastien Barré
  Université catholique de Louvain
  Place Ste Barbe, 2
  Louvain-la-Neuve 1348
  BE
Email:  sebastien.barre@uclouvain.be
URI:  http://inl.info.ucl.ac.be/sbarre
  
  Olivier Bonaventure
  Université catholique de Louvain
  Place Ste Barbe, 2
  Louvain-la-Neuve 1348
  BE
URI:  http://inl.info.ucl.ac.be/obo