Choix des sujets :
| num | titre | Eleve |
| 2 | Operation of Anycast Services | Julien Petit |
| 6 | Virtual Private LAN Service | geoffroy Du Bouays De Couesbouc |
| 12 | Problem Statement for bootstrapping Mobile IPv6 | Ael Breton |
| 13 | Mobile IPv6 and Firewalls: Problem statement | Germain Piveteau |
| 17 | Rbridges: Base Protocol Specification | Francois NET |
| 19 | Softwire Problem Statement | Sylvia Leprettre |
This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. Additional goals may be found necessary over time and may be added to this document.
As the Internet has grown, and as systems and networked services within enterprises have become 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. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast.
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 [RFC1519], 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.
There are many protocols designed and deployed on the Internet today which do not naturally traverse Network Address Translators (NAT). In order to allow these protocols to work in the presence of NAT, additional logic needs to be added to the network. This logic modifies the behavior of the protocol in some way. There are choices where this logic can be placed in the network. It can reside in the NATs themselves, transparently altering the protocol; when this occurs, it is called an Application Layer Gateway (ALG). It can reside in server components, hiding the changes from NATs and clients alike, it can reside in the clients, or it can reside in a combination thereof. The choice of the placement of this logic typically has implications on many aspects of the protocol, including security, deployability, manageability and availability. This document provides a set of considerations that should be taken into account by protocol and network designers when making this choice.
This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). 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.
Virtual Private LAN (Local Area Network) 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 Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.
A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service.
This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines.
This document describes a solution for overcoming the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the backbone can be used to carry traffic belonging only to a specified set of one or more multicast groups from one or more VPLSs are also described.
This document describes a network-based Virtual Private Network (VPN) architecture using the virtual router (VR) concept. Multiple VRs can exist in a single physical device. A VR emulates all the functionality of a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Any routing protocol can be used to distribute VPN reachability information among VRs, and no VPN- related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Direct VR-to-VR connectivity may be configured through layer-2 links or through IP- or MPLS-based tunnels. Traffic from VRs belonging to different VPNs may be aggregated over a "backbone VR" network, which greatly simplifies VPN provisioning. This architecture accommodates various backbone deployment scenarios, both where the VPN service provider owns the backbone, and where the VPN service provider obtains backbone service from one or more other service providers.
This document outlines a 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 protocols, the VPN gateway, or the home agent are 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 mobile node bootstrapping.
Network elements such as 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. Current IP networks 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. Mobility support for IPv6 has been standardized as specified in RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere in the smooth operation of the protocol and can be a detriment to deployment. This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as GPRS/ UMTS and CDMA 2000 networks. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG.
The use of multiple interfaces is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks support for such multihomed nodes. The purpose of this document is to detail all the issues arising through the operation of Mobile IPv6 on multihomed mobile nodes. A taxonmy is used to describe the different situations where a mobile node is multihomed. Issues are explained for each multihomed configuration (number of interfaces, number of Home Addresses or number of Care-of Addresses), and classified into general IPv6 issues, issues pertaining to the specification of Mobile IPv6, and issues related to the implementation of Mobile IPv6. It is not the intention of this document to imply that all issues must be solved in the short term.
In this document, multihoming is investigated from a node point of view, and not from a site point of view as the term "multihoming" is commonly understood so far. The purpose of this document is to explain the motivations for fixed and mobile nodes (hosts and routers) using multiple interfaces and the scenarios where this may end up using multiple global addresses on their interfaces. Such multihoming configurations can bring a number of benefits once appropriate support mechanisms are put in place. Interestingly, this analysis is generic, i.e. motivations and benefits of node multihoming apply to both fixed end nodes and mobile end nodes.
Current Ethernet (802.1) link layers use custom routing protocols that have a number of challenges. The routing protocols need to strictly avoid loops, even temporary loops during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non- overlapping pairwise paths (in the case of spanning trees). The convergence of these routing protocols and stability under link changes and failures is also of concern. This document addresses these concerns and suggests that they are related to the need to be able to apply network layer routing (e.g., link state or distance vector) protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing bridged (802.1D) links, but that a solution would be backward compatible with 802.1D, including hubs, bridges, and their existing plug-and-play capabilities. This document is a work in progress; we invite you to participate on the mailing list at http://www.postel.org/rbridge
RBridges provide the ability to have an entire campus, with multiple physical links, look to IP like a single subnet. The design allows for zero configuration of switches within a campus, optimal pair-wise routing, safe forwarding even during periods of temporary loops, and the ability to cut down on ARP/ND traffic. The design also supports VLANs, and allows forwarding tables to be based on RBridge destinations (rather than endnode destinations), which allows internal routing tables to be substantially smaller than in conventional bridge systems.
RBridges are link layer (L2) devices that use routing protocols as a control plane. They combine the link layer ability to allow hosts to reattach without renumbering with network layer routing benefits. RBridges use existing link state routing to provide higher RBridge to RBridge cross-section bandwidth, fast convergence on reconfiguration, and more robust under link interruption than an equivalent set of conventional bridges using existing spanning tree forwarding. They are intended to apply to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also attempt to retain as much 'plug and play' as is already available in existing bridges. This document proposes an RBridge system as a solution to the TRILL problem. It also defines the RBridge architecture, defines its terminology, and describes basic components and desired behavior. One or more separate documents specify the protocols and mechanisms that satisfy the architecture presented herein.
The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6-only networks and IPv6 networks across IPv4-only networks in a way that will encourage multiple, inter-operable vendor implementations. At the highest level, the Softwires Working Group is tasked to identify, and extend where necessary, standard protocols to support a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved as part of a solution phase following the completion of this document, within a relatively tight "time-to-market" as requested by operators at IETF 63. Some individual requirements (and non-requirements) are also identified in this document at times in order to better describe the specific scope for a given problem definition.
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.