Rémi Després - Academia.edu (original) (raw)

Papers by Rémi Després

As each global IPv4 address will be shared among more and more customers, and as more and more NA... more As each global IPv4 address will be shared among more and more customers, and as more and more NATs will be deployed in ISP infrastructures, the lack of end-to-end transparency and the limited scalability of some NATs are likely to cause increasing difficulties to customers and to ISPs. This document introduces IPv4-IPv6 coexistence scenarios where IPv4 addresses are shared with good scalability and, in favorable configurations, with full IPv4 end-to- end transparency. For this, the key tool is the Stateless Address Mapping (SAM) of draft-despres-SAM-00, with in particular its extended IPv4 addressing (IPv4E) in which port prefixes are used as IPv4 address extensions. For each considered scenario, Static Address Mappers (SAMs) are deployed at scenario specific places.

This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service ... more This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network infrastructure. During the long transition period from IPv4-only to IPv6-only, a service provider's network infrastructure will have to deploy IPv6. But it will also have to maintain some IPv4 connectivity for a number of customers, for both outgoing and incoming connections, and for both customer-individual and shared IPv4 addresses. The 4rd solution (IPv4 Residual Deployment) is designed as a lightweight solution for this. In some scenarios, 4rd can dispense ISPs from supporting any NAT in their infrastructures. In some others it can be used in parallel with NAT-based solutions such as DS-lite and/or NAT64/DNS4.

Stateless Local Address Mapping (SAM) is a generic tool for global- address packets to traverse t... more Stateless Local Address Mapping (SAM) is a generic tool for global- address packets to traverse transit domains where routing is performed in different address spaces. To share IPv4 global addresses among several CPEs and/or hosts, port prefixes can be used as extensions of IPv4 global addresses. In this space (IPv4E), a node having an n-bits IPv4E prefix with n>32 may only use or delegate ports having its port prefix of length /32-n. Static Address Mappers can be placed in CPEs, in hosts, and/or in ISP Internet gateways. Applications include various IPv6 in IPv4 and IPv4E in IPv6 encapsulations.

This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1)... more This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1) legacy IPv4 hosts can establish IPv4 transport connections from customer sites having IPv6-only permanent addresses; (2) for good scalability, no network address translations (NATs), and a fortiori no application level gateways (ALGs), need to be supported within network infrastructures. To satisfy this requirement, it is concluded that an address-port-borrowing-protocol (APBP) is needed.

Entreprises Et Histoire, 2002

US 7,773,619 B2 patent, Aug 28, 2010

The invention relates to the allotting of a computer resource Such as a data transmission link or... more The invention relates to the allotting of a computer resource Such as a data transmission link or a processing unit. More particularly, it relates to a device for managing the sharing of this resource between several users. The function of a device of this type is in particular to select one user from among at least some of the using users. The resource then provides a predetermined service amount for this user. In practice, the service amount is allotted Succes sively to the selected users, in limited service slices (or quanta), for example, by timesharing processing or by packet transmission.

Stateless Address Mapping (SAM) is a generic mechanism which permits, in a number of new scenario... more Stateless Address Mapping (SAM) is a generic mechanism which permits, in a number of new scenarios, to easily establish tunnels for packets of some address family to traverse domains where this family is not directly routed (softwires). It generalizes address mapping principles of already deployed technologies such as 6to4, ISATAP, and 6rd, where encapsulations of IP over IP are used for point-to- multipoint tunnels (mesh softwires). Identified use cases of SAM include native IPv6 across IPv4 NATs, IPv6 multihoming with provider-aggregatable prefixes, public IPv4 across IPv6-only domains and, to mitigate consequences of the IPv4 address shortage, extended IPv4 prefixes for statically shared IPv4 public addresses.

In this interview, Rémi Després, who was the main architect of the Transpac network, describes th... more In this interview, Rémi Després, who was the main architect of the Transpac network, describes the context in which the first packet-switching networks began in France in the 70's. He also describes his role in European data networking history and the birth of the X.25 recommendation at CCITT in 1976.

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity ... more The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6930.

The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks w... more The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79 . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current InternetDrafts is at http://datatracker.ietf.org/drafts/current/ . Internet-Drafts are draft documents valid for a maximum of six months and may be updated, re...

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity ... more The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the

In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991,... more In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. Despres, et al. Experimental [Page 1] RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012 Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6751.

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a se... more IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5569.

As each global IPv4 address will be shared among more and more customers, and as more and more NA... more As each global IPv4 address will be shared among more and more customers, and as more and more NATs will be deployed in ISP infrastructures, the lack of end-to-end transparency and the limited scalability of some NATs are likely to cause increasing difficulties to customers and to ISPs. This document introduces IPv4-IPv6 coexistence scenarios where IPv4 addresses are shared with good scalability and, in favorable configurations, with full IPv4 end-to- end transparency. For this, the key tool is the Stateless Address Mapping (SAM) of draft-despres-SAM-00, with in particular its extended IPv4 addressing (IPv4E) in which port prefixes are used as IPv4 address extensions. For each considered scenario, Static Address Mappers (SAMs) are deployed at scenario specific places.

This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service ... more This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network infrastructure. During the long transition period from IPv4-only to IPv6-only, a service provider's network infrastructure will have to deploy IPv6. But it will also have to maintain some IPv4 connectivity for a number of customers, for both outgoing and incoming connections, and for both customer-individual and shared IPv4 addresses. The 4rd solution (IPv4 Residual Deployment) is designed as a lightweight solution for this. In some scenarios, 4rd can dispense ISPs from supporting any NAT in their infrastructures. In some others it can be used in parallel with NAT-based solutions such as DS-lite and/or NAT64/DNS4.

Stateless Local Address Mapping (SAM) is a generic tool for global- address packets to traverse t... more Stateless Local Address Mapping (SAM) is a generic tool for global- address packets to traverse transit domains where routing is performed in different address spaces. To share IPv4 global addresses among several CPEs and/or hosts, port prefixes can be used as extensions of IPv4 global addresses. In this space (IPv4E), a node having an n-bits IPv4E prefix with n>32 may only use or delegate ports having its port prefix of length /32-n. Static Address Mappers can be placed in CPEs, in hosts, and/or in ISP Internet gateways. Applications include various IPv6 in IPv4 and IPv4E in IPv6 encapsulations.

This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1)... more This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1) legacy IPv4 hosts can establish IPv4 transport connections from customer sites having IPv6-only permanent addresses; (2) for good scalability, no network address translations (NATs), and a fortiori no application level gateways (ALGs), need to be supported within network infrastructures. To satisfy this requirement, it is concluded that an address-port-borrowing-protocol (APBP) is needed.

Entreprises Et Histoire, 2002

US 7,773,619 B2 patent, Aug 28, 2010

The invention relates to the allotting of a computer resource Such as a data transmission link or... more The invention relates to the allotting of a computer resource Such as a data transmission link or a processing unit. More particularly, it relates to a device for managing the sharing of this resource between several users. The function of a device of this type is in particular to select one user from among at least some of the using users. The resource then provides a predetermined service amount for this user. In practice, the service amount is allotted Succes sively to the selected users, in limited service slices (or quanta), for example, by timesharing processing or by packet transmission.

Stateless Address Mapping (SAM) is a generic mechanism which permits, in a number of new scenario... more Stateless Address Mapping (SAM) is a generic mechanism which permits, in a number of new scenarios, to easily establish tunnels for packets of some address family to traverse domains where this family is not directly routed (softwires). It generalizes address mapping principles of already deployed technologies such as 6to4, ISATAP, and 6rd, where encapsulations of IP over IP are used for point-to- multipoint tunnels (mesh softwires). Identified use cases of SAM include native IPv6 across IPv4 NATs, IPv6 multihoming with provider-aggregatable prefixes, public IPv4 across IPv6-only domains and, to mitigate consequences of the IPv4 address shortage, extended IPv4 prefixes for statically shared IPv4 public addresses.

In this interview, Rémi Després, who was the main architect of the Transpac network, describes th... more In this interview, Rémi Després, who was the main architect of the Transpac network, describes the context in which the first packet-switching networks began in France in the 70's. He also describes his role in European data networking history and the birth of the X.25 recommendation at CCITT in 1976.

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity ... more The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6930.

The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks w... more The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79 . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current InternetDrafts is at http://datatracker.ietf.org/drafts/current/ . Internet-Drafts are draft documents valid for a maximum of six months and may be updated, re...

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity ... more The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the

In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991,... more In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. Despres, et al. Experimental [Page 1] RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012 Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6751.

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a se... more IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5569.