Le travail consiste :
Planning :
Pointeurs :
Choix :
2-Mobile Ipv4 Traversal/IPSEC : S. Ferjani
3-bootstrapping MIP6 : F. Cazenave, Y. Bourgeois
4-Mip6 and firewalls : J. Fournier
6-Hierarchical MIPv6 : M. Souabni
8-Nemo : G. Ferrin
11-Manet : E.Troche, A.Sinnah
12-PWE3 architecture : E. Lavanant
14-L2VPN-LAN : V.Arod
17-L3VPN : T. Emereau
21-MultiHoming IPv6 : Q.Turbiez, J.Cabrolier
22-IPv6-NAP : A. Al Habobi
Deploying Mobile-IP v4 in networks which are connected to the Internet through a VPN (Virtual Private Network) gateway presents some problems which do not currently have well-described solutions. This document aims to describe and illustrate these problems, and propose some guidelines for possible solutions.
This document outlines the proposed solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec are not required.
A mobile node needs at least the following information: a home address, home agent address and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discuss the issues involved with how the mobile node can be bootstrapped for Mobile IPv6 and various potential deployment scenarios for bootstrapping the mobile node.
Firewalls are an integral aspect of a majority of IP networks today given the state of security in the Internet, threats and vulnerabilities to data networks. IP networks today are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development.
This document is a succint account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization Security Design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 Security Design in 2001-2002. The document has two target audiences: (1) MIPv6 implementors so that they can better understand the design choices in MIPv6 security procedures; and (2) people dealing with mobility or multi-homing so that they can avoid a number of potential security pitfalls in their design.
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes and its Home Agent. The Mobility Anchor Point described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.
Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from an Access Router to another, a process referred to as handover. During handover, there is a period when the Mobile Node is unable to send or receive packets both due to link switching delay and IP protocol operations. This ``handover latency'' resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. This document specifies enhancements to reduce the handover latency due to standard Mobile IPv6 procedures. This document does not address improving the link switching latency.
This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network.
Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later. This document outlines the goals expected from network mobility support and defines the requirements that must be met by NEMO Basic Support solutions.
This document is an analysis of multihoming in the context of network mobility (NEMO). As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. We also describe possible deployment scenarios and we attempt to identify issues that arise when mobile networks are multihomed while mobility supports is taken care by NEMO Basic Support.
This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations.
This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.
This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves.
Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint network, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network.
This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (PPVPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint to multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective.
This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.
This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP- based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider.
In any Layer-3 and Layer-2 VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for layer-2 VPN architectures and Virtual router-based layer-3 VPNs [VPN-VR]. This mechanism is based on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for distributing VPN routing information within the service provider(s). In the context of L2VPNs, an auto-discovery mechanism enables a PE to determine the set of other PEs having VPN members in common along with information relative to each specific L2VPN endpoints such as attachment circuit identifier, topology information, etc. Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme.
As the Internet has grown, and as systems and networked services within enterprises have been more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.
This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original CIDR spec [RFC 1519], with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.
This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.
Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT.