Article

Implementation and evaluation of the Shim6 protocol in the Linux kernel

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

In the changing landscape of the todays Internet, several solutions are under investigation to allow efficient, flexible and scalable multihoming. One of the proposals is shim6, a host-based multihoming solution based on the use of multiple IPv6 addresses on each host. In this work, we first describe the main features of this protocol, then we explain our implementation of shim6, along with the associated security mechanisms in the Linux kernel and, finally, we evaluate its performance. In particular, we analyse the performance impact of the security mechanisms used by shim6 and the impact of shim6 on the performance of end-host systems, especially heavily loaded servers. We conclude by discussing the remaining open issues for a widespread deployment of host-based multihoming techniques such as shim6.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... The implementation feature indicates whether or not some real prototype implementation is available. Implementations or descriptions of implementation can be found for the following systems: ABPS [11]; DCCP [81]; FLowMob [82]; Hi3 [83]; Hidden Proxy [66]; HIP [84,85]; I-TCP [15]; LIN6 [61,75]; LISP [86,87]; MCoA (monami6) and NEMO [88,89,90]; MIPv6 [80,88,89,90]; MMUSE [91]; MPTCP [17,18]; MSOCKS [20]; NIIA [92]; Shim6 [93,85]; SIP-IAPP [13]; TCPmigrate [94]; TMSP [59]; UPMT [67,95]. ...
... LinShim6 (and its variant, MipShim6) is another project that implements Shim6 [93]. ...
Preprint
This work presents a comprehensive and structured taxonomy of available techniques for managing the handover process in mobility architectures. Representative works from the existing literature have been divided into appropriate categories, based on their ability to support horizontal handovers, vertical handovers and multihoming. We describe approaches designed to work on the current Internet (i.e. IPv4-based networks), as well as those that have been devised for the "future" Internet (e.g. IPv6-based networks and extensions). Quantitative measures and qualitative indicators are also presented and used to evaluate and compare the examined approaches. This critical review provides some valuable guidelines and suggestions for designing and developing mobility architectures, including some practical expedients (e.g. those required in the current Internet environment), aimed to cope with the presence of NAT/firewalls and to provide support to legacy systems and several communication protocols working at the application layer.
... Na ocorrência de falha na conexão ou congestionamento, a camada SHIM6 fica responsável pela comutação do tráfego para um novo par localizador (contexto). Este processo ocorre sobre a camada IP e todo o processo é absolutamente transparente para aplicações das camadas superiores Ronan;Bonaventure, 2011]. Estes e outros trabalhos demonstram o anseio pela comparação entre os protocolos de mobilidade a fim de demonstrar suas funcionalidades e aplicabilidades sobre o mesmo viés. ...
... Na ocorrência de falha na conexão ou congestionamento, a camada SHIM6 fica responsável pela comutação do tráfego para um novo par localizador (contexto). Este processo ocorre sobre a camada IP e todo o processo é absolutamente transparente para aplicações das camadas superiores Ronan;Bonaventure, 2011]. Estes e outros trabalhos demonstram o anseio pela comparação entre os protocolos de mobilidade a fim de demonstrar suas funcionalidades e aplicabilidades sobre o mesmo viés. ...
Article
Resumo. O uso crescente de dispositivos móveis sem fio, associado ao esgotamento de endereços IPv4, nos levou a pensar que a mobilidade em redes IP será feita apenas utilizando o protocolo IPv6. No entanto, a diversidade de protocolos de mobilidade, pode ser interpretada como um indício de que as soluções de mobilidade utilizando IPv6 não estão maduras o suficiente para serem implantadas em larga escala. Neste artigo vamos analisar, testar e avaliar algumas implementações usadas no provimento de mobilidade em IPv6, analisando o desempenho, dificuldade de implantação e estabilidade destas implementações. Abstract. The growing use of mobile wireless devices, associated with the depletion of IPv4 addresses, led us to think that mobility in IP networks will be done just by using the protocol IPv6. However, the diversity of mobile protocols in existence can be interpreted like a symptom that mobility´s solution using IPv6 are not mature enough to deploy on a large scale. In this paper we will review, test and evaluate several implementations used to provide mobility over IPv6, analyzing its performance, level of difficulty to deploy and stability of the solution. 1. Introdução A proliferação dos dispositivos móveis sem fio, associado ao esgotamento de endereços IPv4, levou-nos ao pensamento natural que a implementação da mobilidade nas redes IP ocorrerá apenas usando o protocolo IPv6. Este pensamento pode ser sentido no esforço realizado pelas operadoras de telefonia celular, em preparação para o novo padrão "4G", que em um futuro não muito distante, provavelmente terá que lidar com dispositivos IPv6-only [Limoncelli; Cerf, 2011] [Morr, 2010]. Além disso, IPv6 e seus protocolos de configuração de endereços (Neighbor Discovery e Stateless Address Configuration) formam uma base de protocolo apropriada para redes móveis [Perkins, 2002]. Por outro lado, existem vários protocolos propostos para lidar com a mobilidade, como: [Johnson; Perkins; Arkko, 2004] [Koodli, 2009], [Soliman; et al., 2008], [Leung; et al., 2008] [Menth; Klein; Hartmann, 2010] [Moskowitz; et al., 2008] e [Nordmark; Bagnulo, 2009]. Essa diversidade de protocolos pode ser interpretada como um indício que as soluções de mobilidade não estão maduras o suficiente para ser implantadas em redes IP, e que pesquisas ainda são necessárias.
... Na ocorrência de falha na conexão ou congestionamento, a camada SHIM6 fica responsável pela comutação do tráfego para um novo par localizador (contexto). Este processo ocorre sobre a camada IP e todo o processo é absolutamente transparente para aplicações das camadas superiores Ronan;Bonaventure, 2011]. Estes e outros trabalhos demonstram o anseio pela comparação entre os protocolos de mobilidade a fim de demonstrar suas funcionalidades e aplicabilidades sobre o mesmo viés. ...
... Na ocorrência de falha na conexão ou congestionamento, a camada SHIM6 fica responsável pela comutação do tráfego para um novo par localizador (contexto). Este processo ocorre sobre a camada IP e todo o processo é absolutamente transparente para aplicações das camadas superiores Ronan;Bonaventure, 2011]. Estes e outros trabalhos demonstram o anseio pela comparação entre os protocolos de mobilidade a fim de demonstrar suas funcionalidades e aplicabilidades sobre o mesmo viés. ...
... The implementation feature indicates whether or not some real prototype implementation is available. Implementations or descriptions of implementation can be found for the following systems: ABPS [11]; DCCP [81]; FLowMob [82]; Hi3 [83]; Hidden Proxy [66]; HIP [84,85]; I-TCP [15]; LIN6 [61,75]; LISP [86,87]; MCoA (monami6) and NEMO [88,89,90]; MIPv6 [80,88,89,90]; MMUSE [91]; MPTCP [17,18]; MSOCKS [20]; NIIA [92]; Shim6 [93,85]; SIP-IAPP [13]; TCPmigrate [94]; TMSP [59]; UPMT [67,95]. ...
... LinShim6 (and its variant, MipShim6) is another project that implements Shim6 [93]. ...
Article
This work presents a comprehensive and structured taxonomy of available techniques for managing the handover process in mobility architectures. Representative works from the existing literature have been divided into appropriate categories, based on their ability to support horizontal handovers, vertical handovers and multihoming. We describe approaches designed to work on the current Internet (i.e. IPv4-based networks), as well as those that have been devised for the "future" Internet (e.g. IPv6-based networks and extensions). Quantitative measures and qualitative indicators are also presented and used to evaluate and compare the examined approaches. This critical review provides some valuable guidelines and suggestions for designing and developing mobility architectures, including some practical expedients (e.g. those required in the current Internet environment), aimed to cope with the presence of NAT/firewalls and to provide support to legacy systems and several communication protocols working at the application layer.
... The SHIM6 [9] is a host multi-homing method and supports multicast. It uses IPv6 address space to build Locator and Identifier without importing new address space. ...
Article
Full-text available
Multi-homing is one of the effective ways to defeat path failure and increase the reliability of site network service. However, limited by the TCP/IP architecture, multi-homing has not been well deployment. In this paper, we proposed a sit multi-homing path failure recovery method based on “Locator/Identifier Split” by adding mapping service and RTT cooperative detection mechanism to the edge router. In order to reduce the probing’s cost of the router’s resource and link bandwidth, we also optimized the probing algorithm by reducing unnecessary active probing. The results of simulation test proved that this method could effectively detect the path failure and performance drop including packets delay and packets loss, and made a fast path switch to ensure the normal running of the upper application services (e.g., FTP). We also gave a theory analysis of the overhead brought by the sit multi-homing path failure recovery method. It shows that the addition bandwidth cost is 0.036% of the simulation link bandwidth and our approach is practicable.
... It can provide more than one IPv6 addresses for each host. A host employs Shim6 can use more than one prefix of IPv6 addresses if the host has more than one interface for networks attachment points [20]. The HIP protocol proposed a new layer called the host identity layer. ...
Article
Full-text available
Keeping a connection continuity during the movement of a mobile node (MN) between access points without any suspension of provided services is one of the most pressing issues should be solved. Long handover processing causes interruptions in session connection, high rate of data loss, and long end-to-end delay time. Smart virtualization means the cooperation of different virtualization technologies with novel ideas. In this paper, we proposed a mobile network architecture compatible with cloud computing of 5G and beyond networks. We invented a new idea to create a tag to be used as an MN's identity, which consists of the standard E.164 numbering and MAC address. Based on the uniqueness of E.164 numbering and MAC which are processed together to generate the MN tag (T H ). T H is used to handle the packets inside the mobile networks. The software-defined networking (SDN) provides a capability of separating the control plane from the data plane. This decoupling is a suitable candidate to exploit it in our proposed system that uses the SDN and other virtualization technologies. The requirements of the 5G and beyond for future mobile communications encouraged us to think in a novel packet forwarding during the handover to keep real-time connection continuity for an MN. Our proposed system has been simulated and performed by MATLAB and Mininet platforms. The results showed that the packet loss rate decreased to 4% of the date that was lost during the handover delay time or packets re-direction mechanism. At the same time, the MN could receive 96.4% of the data that were lost during the handover process.
... Without clear evidence, the authors' claim that the FPF scheduler can fully eliminate packet reordering is questionable. As an alternative to HIP, the Shim6 protocol was enhanced to handle several paths simultaneously and published by Barré et al. [17] under the name Multipath LinShim6. However, the authors only present implementation details without any results about multipath aggregation. ...
Article
Full-text available
The explosive deployment of wired and wireless communication infrastructure has recently enabled many novel applications and sparked new research problems. One of the unsolved issues in today's Internet - the main topic of this thesis - is the goal of increasing data transfer speeds of end hosts by aggregating and simultaneously using multiple network interfaces. This objective is most interesting when the Internet is accessible through several, relatively slow and variable (typically wireless) networks, which are unable to single-handedly provide the required data rate for resource-intensive applications, such as bulk file transfers and high-definition multimedia streaming.
Article
SHIM6 is a host-centric solution for multihoming in IPv6 networks. It is fully implemented in hosts and does not affect the Internet routing system. We present the results of experiments with SHIM6 in the lab and over the Internet. The aim is to evaluate the behaviour of SHIM6 in case of link failure. We tried two transport protocols, TCP and DCCP, measuring traffic and recovery time, two important performance metrics. In addition, the experiments revealed some operational issues which must be addressed before SHIM6 can be deployed world-wide.
Article
IP-based Internet of Things (IoT) needs a lot of fixed and mobile nodes, and the existing IP has overload problem. In order to separate Identifier and Locator, the Host Identity Protocol (HIP) and Level 3 Multi-homing Shim Protocol for IPv6 (Shim6) that are based on Addressing Rewriting, and the Locator/Identifier Separation Protocol (LISP) that is based on Map-and-Encapsulate, are studied, and a new Identifier/Locator Separation Protocol based on IPv6 address (ILSP6) is proposed. Analysis and simulation handover delay and packet loss of ILSP6, Mobile IPv6 (MIPv6), HIP and LISP are done; simulation results show that ISLP6 has better performance.
Conference Paper
Full-text available
The Host Identity Protocol (HIP) is being standardized by the IETF as a new solution for host mobility and multihoming in the Internet. HIP uses self-certifying public-private key pairs in combination with IPsec to authenticate hosts and protect user data. While there are three open-source HIP implementations, no experience is available with running HIP on lightweight hardware such as a PDA or a mobile phone. Limited computational power and battery lifetime of lightweight devices raises concerns if HIP can be used there at all. This paper presents performance measurements of HIP over WLAN on Nokia 770 Internet Tablet. It also provides comprehensive analysis of the results and makes suggestions on HIP suitability for lightweight clients.
Article
Full-text available
SUMMARY IPv6 is realized as the next generation internet platform, succeeding the current IPv4 internet environment. Linux, one of the major operating systems, has supported IPv6 since 1996, however, the quality of the protocol stack has not been good enough for professional operation. In this paper, we show our IPv6 stack implementation design regarding the neighbor management in Neighbor Discovery Protocol (NDP), the rout- ing table management and the packet processing using XFRM architecture. The implementation is designed based on the Serialized Data State Pro- cessing, which aims at simpler object management so as to achieve stable, flexible and extensible IPv6 stack. According to the TAHI IPv6 Protocol Conformance Test Suite, we can show our implementation achieves enough
Article
Full-text available
Theshim6 host-based solution to IPv6 multihoming was designed within the IETF to provide a solution to the multihoming problem by using several IPv6 addresses per host. In this paper, we briefly describe our Linux implementation of shim6. One of the novel mechanisms introduced by shim6 is the REAchability Protocol (REAP) that allows multihomed hosts to switch to an alternate path when a failure occurs. We evaluate the performance of this protocol in a lab environment and show that it performs well in the case of unidirectional or bidirectional failures. We also show that the recovery time can be reduced by allowing REAP to send multiple probes upon failure detection.
Article
Full-text available
There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems.
Article
Full-text available
Peer-to-peer (P2P) systems, which are realized as overlays on top of the underlying Internet routing architecture, contribute a significant portion of today's Internet traffic. While the P2P users are a good source of revenue for the Internet Service Providers (ISPs), the immense P2P traffic also poses a significant traffic engineering challenge to the ISPs. This is because P2P systems either implement their own routing in the overlay topology or may use a P2P routing underlay [1], both of which are largely independent of the Internet routing, and thus impedes the ISP's traffic engineering capabilities. On the other hand, P2P users are primarily interested in finding their desired content quickly, with good performance. But as the P2P system has no access to the underlying network, it either has to measure the path performance itself or build its overlay topology agnostic of the underlay. This situation is disadvantageous for both the ISPs and the P2P users. To overcome this, we propose and evaluate the feasibility of a solution where the ISP offers an "oracle" to the P2P users. When the P2P user supplies the oracle with a list of possible P2P neighbors, the oracle ranks them according to certain criteria, like their proximity to the user or higher bandwidth links. This can be used by the P2P user to choose appropriate neighbors, and therefore improve its performance. The ISP can use this mechanism to better manage the immense P2P traffic, e.g., to keep it inside its network, or to direct it along a desired path. The improved network utilization will also enable the ISP to provide better service to its customers.
Conference Paper
Full-text available
Layer-three SHIM (L3SHIM) protocol is designed to support site multihoming in IPv6 network and now being standardized at SHIM6 working group in IETF. A host or router can have more than two egress interfaces which are connected to a different ISP and configured by distinct IPv6 network prefixes. By using L3SHIM, when an interface is down, another interface can backup for the ongoing connections as it adopts identifier/locator decoupling architecture. Our team is implementing the L3SHIM protocol on Linux based PC using netfilter hooks in the network kernel. We implemented L3SHIM core and REAP component, and verified the feasibility and usefulness of L3SHIM in multi-homed environment by an experiment. We reported the implementation progress to SHIM6 working group in IETF 67th meeting.
Conference Paper
Full-text available
Several solutions are proposed to enable scalable multihoming over IPv6. One of these proposals is Shim6, a host-based multihoming solution based on the modification of the Internet Protocol stack of the host. This modification adds a layer below the transport protocols but above the forwarding layer. As this approach makes the modifications to the network stack transparent, existing applications automatically benefit from Shim6 functionality. In this paper we investigated aspects of the performance of the Lin- Shim6 implementation from Université Catholique de Louvain. We also outline our modifications of the LinShim6 implementation to allow external software to control the locators used between hosts.
Conference Paper
Full-text available
There is ongoing work on the IETF aimed to provide sup- port for dierent flavors of multihoming configurations, such as SHIM6 for multihomed sites, multiple CoAs support in MIP for multihomed mo- bile nodes and HIP for multihomed nodes and sites. A critical aspect for all the resulting multihoming protocols is to detect failures and gain in- formation related with the paths available between two hosts. The Failure Detection and Locator Path Exploration Protocol (in short REAchabil- ity Protocol, REAP) being defined in the SHIM6 WG of the IETF is a good candidate to be included as a reachability detection component on protocols requiring this functionality. Performance study is performed by combining analytical estimations and simulations to evaluate its behavior and tune its main parameters.
Article
Full-text available
Abstract— Multihoming, the practice of connecting to multiple providers, is becoming highly popular. Due to the growth of the BGP routing tables in the Internet, the way to get multihomed,in IPv6 is required to allow route aggregation in order to preserve the scalability of the interdomain routing system. After several years of development, the IETF and the research community propose drastic changes in how site multihoming shall be achieved in IPv6. Those changes will potentially affect the fundamental multihoming mechanism, as well as intradomain routing, traffic engineering and even the behaviour of hosts within the multihomed,site. This paper presents the required functionalities and the constraints imposed to the solutions to the IPv6 multihoming problem. It surveys the main multihoming approaches that have been proposed to the IETF over the period 2000 - 2005. It proposes a taxonomy, and compares the solutions according to their mechanisms, benefits and drawbacks. This survey also outlines the major steps that have led to a new multihoming architecture for IPv6.
Article
Full-text available
Since the ARPAnet, network designers have built localized mechanisms for statistical multiplexing, load balancing, and failure resilience, often without understanding the broader implications. These mechanisms are all types of resource pooling, which means making a collection of resources behave like a single pooled resource. We believe that the natural evo- lution of the Internet is that it should achieve resource pool- ing by harnessing the responsiveness of multipath-capable end systems. We argue that this approach will solve the problems and limitations of the current piecemeal approaches.
Article
Full-text available
Les supports de la mobilité et la multi-domiciliation dans IPv6 ont jusqu'à présent été considérés de manière indépendante et ont notamment résulté dans la publication des standards Mobile IPv6 et SHIM6 respectivement. Or, plusieurs cas d'usage que nous soulevons démontrent qu'il y a un intérêt fort pour l'utilisa- tion simultanée de ces deux protocoles. En particulier, la solution combinée permet de remplacer le mécanisme d'optimisation de routage de Mobile IPv6 par une technique plus légère et équivalente en fonctionnalité, sans besoin d'extension des protocoles déjà définis. Nous présentons également une évaluation de notre architecture, sur base de notre implémentation pour Linux, disponible publiquement.
Conference Paper
Full-text available
It is expected that IPv6 multihomed sites will obtain as many global prefixes as direct providers they have, so traffic engineering techniques currently used in IPv4 multihomed sites is no longer suitable. However, traffic engineering is required for several reasons, and in particular, for being able to properly support multimedia communications. In this paper we present a framework for traffic engineering in IPv6 multihomed sites with multiple global prefixes. Within this framework, we have included several tools such as DNS record manipulation and proper configuration of the policy table defined in RFC 3484. To provide automation in the management of traffic engineering, we analyzed the usage of two mechanisms to configure the policy table.
Article
Full-text available
Traffic engineering is performed by means of a set of techniques that can be used to better control the flow of packets inside an IP network. We discuss the utilization of these techniques across interdomain boundaries in the global Internet. We first analyze the characteristics of interdomain traffic on the basis of measurements from three different Internet service providers and show that a small number of sources are responsible for a large fraction of the traffic. Across interdomain boundaries, traffic engineering relies on a careful tuning of the route advertisements sent via the border gateway protocol. We explain how this tuning can be used to control the flow of incoming and outgoing traffic, and identify its limitations.
Article
Full-text available
Network operators must have control over the flow of traffic into, out of, and across their networks. However, the Border Gateway Protocol (BGP) does not facilitate common traffic engineering tasks, such as balancing load across multiple links to a neighboring AS or directing traffic to a different neighbor. Solving these problems is difficult because the number of possible changes to routing policies is too large to exhaustively test all possibilities, some changes in routing policy can have an unpredictable effect on the flow of traffic, and the BGP decision process implemented by router vendors limits an operator's control over path selection.
Article
BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827.
Article
This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.
Article
A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes.
Article
This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.
Article
The scalability of the Internet routing system suffers from an increasing demand for provider-independent, non-aggregatable IP addresses in networks at the Internet edge. New routing architectures have been proposed that mitigate this problem through indirection between provider-independent addresses at the edge and aggregatable, provider-allocated addresses in the core of the Internet. A major challenge in these architectures is backwards compatibility. Address indirection requires support at the sender and the receiver, so without appropriate backwards compatibility support, it defeats communications between the upgraded and the legacy Internet. This paper proposes an address-indirection-based solution that is backwards compatible. The solution is shown to offer the benefits of provider-independent addressing in a scalable and backwards compatible manner, and to provide the incentives necessary to foster its early deployment.
Conference Paper
Cryptographically generated addresses (CGA) are IPv6 addresses some address bits are generated by hashing the address owner’s public key. The address owner uses the corresponding private key to assert address ownership and to sign messages sent from the address without a PKI or other security infrastructure. This paper describes a generic CGA format that can be used in multiple applications. Our focus is on removing weaknesses of earlier proposals and on the ease of implementation. A major contribution of this paper is a hash extension technique that increases the effective hash length beyond the 64-bit limit of earlier proposals.
Conference Paper
The future of network communications is moving towards deployment of an all-IP core network. This has given rise to many devices hitting the market equipped with multiple network interfaces. However, in order to really benefit from such a heterogeneous network environment, applications must experience minimum disruption as they roam from one network to another, which requires seamless mobility support. Although, some mobility proposals have emerged (Mobile IPv6, and its extensions), none of them give satisfactory performance in terms of handover between different networks. In addition, they require infrastructural changes to the network and give poor performance in case of a failure. In this paper, we propose a mechanism to support mobility through a multi homing SHIM6 layer. The results show that our proposed mechanism outperforms Route Optimized Mobile IPv6.
Conference Paper
Address proxying is a process by which one IP node acts as an endpoint intermediary for an IP address that actually belongs to another IP node. Address proxying serves many useful functions in IP networks. In IPv6, the Secure Neighbor Discovery Protocol (SEND) provides powerful tools for securing the mapping between the IP address and the link address which is the basis of local link address proxying; however, these tools don’t work for address proxies. In this paper, we present an extension to SEND for secure proxying. As an example of how secure address proxying can be used, we propose a minor extension of the Mobile IPv6 protocol to allow secure proxying by the home agent. We then present measurements comparing SEND with and without the address proxying extensions.
Article
SUMMARY The diffi culty of renumbering a network—i.e., adding and removing an Internet Protocol (IP) prefi x due to a provider change or a network merger—is a real issue for most network administrators. In this paper, we propose a set of macros that can be used in confi guration fi les. These allow network administrators to write generic confi gurations that are independent of the public IPv6 prefi xes allocated to their network. We explain how to apply our macros to key confi guration fi les, namely fi rewall access lists, Domain Name Service and Dynamic Host Confi guration Protocol, and how to use this mechanism in a full renumbering process. Copyright © 2009 John Wiley & Sons, Ltd.
Article
Fourth-generation mobile devices incorporate multiple interfaces with diverse access technologies. The current Mobile IPv6 protocol fails to support the enhanced fault tolerance capabilities that are enabled by the availability of multiple interfaces. In particular, established MIPv6 communications cannot be preserved through outages affecting the home address. In this article, we describe an architecture for IPv6 mobile host multihoming that enables transport layer survivability through multiple failure modes. The proposed approach relies on the cooperation between the MIPv6 and the SHIM6 protocols.
Socket application program interface (API) for multihoming shim, Internet draft, draft-ietf-shim6-multihome-shim-api-16
  • M Komu
  • M Bagnulo
  • K Slavov
  • S Sugimoto
M. Komu, M. Bagnulo, K. Slavov, S. Sugimoto, Socket application program interface (API) for multihoming shim, Internet draft, draft-ietf-shim6-multihome-shim-api-16.txt, 2011, in preparation.
Inter-as traffic engineering case studies as requirements for ipv6 multihoming solutions. NANOG 34 presentation
  • J Schiller
J. Schiller. Inter-as traffic engineering case studies as requirements for ipv6 multihoming solutions. NANOG 34 presentation, may 2005.
Provider Independent (PI) IPv6 Assignments for End User Organisations. Ripe Policy Proposal
  • J P Martinez
J. P. Martinez. Provider Independent (PI) IPv6 Assignments for End User Organisations. Ripe Policy Proposal 2006-01, February 2009.
Architectural guidelines for multipath TCP development, RFC 6182
  • A Ford
  • C Raiciu
  • S Barré
  • J Iyengar
  • B Ford
A. Ford, C. Raiciu, S. Barré, J. Iyengar, B. Ford, Architectural guidelines for multipath TCP development, RFC 6182, 2011.
Threats relating to IPv6 multihoming solutions, RFC 4218
  • E Nordmark
  • T Li
E. Nordmark, T. Li, Threats relating to IPv6 multihoming solutions, RFC 4218, 2005.
Linux multipath tcp implementation
  • S Barré
S. Barré. Linux multipath tcp implementation. available from http://inl.info.ucl.ac.be/mptcp, Dec. 2010.
TCP Extensions for multipath operation with multiple addresses, Internet draft, draft-ietf-mptcp-multiaddressed-03.txt
  • A Ford
  • C Raiciu
  • M Handley
  • O Bonventure
A. Ford, C. Raiciu, M. Handley, O. Bonventure, TCP Extensions for multipath operation with multiple addresses, Internet draft, draft-ietf-mptcp-multiaddressed-03.txt, 2011, in preparation.
Hash-Based Addresses (HBA). RFC 5535
  • M Bagnulo
M. Bagnulo. Hash-Based Addresses (HBA). RFC 5535, June 2009.
ILNP concept of operations, Internet draft, draft-rja-ilnp-intro-10
  • R Atkinson
R. Atkinson, ILNP concept of operations, Internet draft, draft-rja-ilnp-intro-10.txt, 2011, in preparation.
Internet draft, draft-ietf-lisp-10.txt
  • D Farinacci
  • V Fuller
  • D Meyer
  • D Lewis
D. Farinacci, V. Fuller, D. Meyer, D. Lewis, Locator/ID Separation Protocol (LISP), Internet draft, draft-ietf-lisp-10.txt, 2011, in preparation.
Print ISSN: 1055-7148, DOI: 10.1002/ nem
  • Online
  • Issn
Online ISSN: 1099-1190, Print ISSN: 1055-7148, DOI: 10.1002/ nem.717, Copyright 2009 John Wiley & Sons, Ltd..
Application-layer traffic optimization (ALTO) problem statement, RFC 5693
  • J Seedorf
  • E Burger
J. Seedorf, E. Burger, Application-layer traffic optimization (ALTO) problem statement, RFC 5693, 2009.
ILNP Concept of Operations. Internet draft, draft-rja-ilnpintro-06.txt, work in progress
  • R Atkinson
R. Atkinson. ILNP Concept of Operations. Internet draft, draft-rja-ilnpintro-06.txt, work in progress, August 2010.
Socket Application Program Interface (API) for Multihoming Shim. Internet draft, draft-ietf-shim6-multihome-shim-api-15.txt, work in progress
  • M Komu
  • M Bagnulo
  • K Slavov
  • S Sugimoto
M. Komu, M. Bagnulo, K. Slavov, and S. Sugimoto. Socket Application Program Interface (API) for Multihoming Shim. Internet draft, draft-ietf-shim6-multihome-shim-api-15.txt, work in progress, Oct. 2010.
TCP Extensions for Multipath Operation with Multiple Addresses. Internet draft, draft-ietf-mptcpmultiaddressed-02.txt, work in progress
  • A Ford
  • C Raiciu
  • M Handley
A. Ford, C. Raiciu, and M. Handley. TCP Extensions for Multipath Operation with Multiple Addresses. Internet draft, draft-ietf-mptcpmultiaddressed-02.txt, work in progress, October 2010.
  • R Moskowitz
  • P Nikander
  • P Jokela
  • T Henderson
R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson. Host Identity Protocol. RFC 5201, Apr. 2008.
Locator/ID Separation Protocol (LISP) Internet draft, draft-ietf-lisp-09.txt, work in progress
  • D Farinacci
  • V Fuller
  • D Meyer
  • D Lewis
D. Farinacci, V. Fuller, D. Meyer, and D. Lewis. Locator/ID Separation Protocol (LISP). Internet draft, draft-ietf-lisp-09.txt, work in progress, Oct. 2010.