Network Working Group P. Pillay-Esnault, Ed.
Internet-Draft Huawei
Intended status: Informational M. Boucadair
Expires: September 13, 2017 C. Jacquenet
Orange
M. Fioccola
Telecom Italia
A. Nennker
Deutsche Telekom
March 12, 2017
Problem Statement for Identity Enabled Networks
draft-padma-ideas-problem-statement-01
Abstract
The forthcoming deployment of 5G coupled with emerging applications
such as augmented reality, virtual reality and 8k videos are likely
to raise more stringent requirements in terms of ultra-low latency
while ensuring session continuity. The emergence of IoT services
also raises new challenges (with respect to their interoperability,
discovery, naming and addressing) which may lead to identity-based
designs. This problem statement examines how the existing solutions
for networks whose forwarding scheme assumes the decoupling between
the identifier and the locator information (called Identity Enabled
Networks) will struggle to meet such requirements. It advocates for
a standardized, secured common control plane with data integrity for
Identity Services such as identifier registration, mapping and
resolution. This memo also identifies several key areas to be
further investigated for the architecture design of these services.
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 Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 13, 2017.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 1]
Internet-Draft March 2017
Copyright Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Brief Overview of ID Enabled Networks . . . . . . . . . . . . 5
4.1. Identifiers Role in a Communication Session . . . . . . . 6
4.2. Mapping/Resolution Services in GRIDS differ from Domain
Name Service (DNS) . . . . . . . . . . . . . . . . . . . 7
5. Key Problems . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Common Control Plane Infrastructure . . . . . . . . . . . 8
5.2. Identifier Lifecycle . . . . . . . . . . . . . . . . . . 9
5.3. Security of Mapping Systems . . . . . . . . . . . . . . . 9
5.4. Distributed Denial of Service Attack Prone . . . . . . . 9
6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Relationship between IDEAS and other IETF Working Groups . . 10
7.1. LISP WG . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. HIP WG . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The current Internet architecture was designed for an environment
very different from today's networks. The October 2006 IAB Routing
and Addressing Workshop [RFC4984] identified several future trends
Pillay-Esnault, et al. Expires September 13, 2017 [Page 2]
Internet-Draft March 2017
and challenges. [RFC4984] suggests that a generic identifier-
locator separation would be a possible solution to support billions
of mobile devices without "bringing undue impact on global routing
scalability and stability". Indeed, the concept of identifier-
locator separation is key to meeting future trends and challenges.
At the same time, proposed solutions in this space do not currently
address all requirements.
The Routing Research Group (RRG) identified several identifier-based
solutions in [RFC6115]. The technique relies upon the decoupling of
the identifier from the locator and therefore the change of location
is transparent to higher layers. The changes of LOC are handled by
an infrastructure that maps the ID to the LOC.
As Machine to Machine (M2M) communications become more pervasive, IoT
devices are slated to be highly interconnected and unsupervised. As
these communications will most likely be unmonitored, there are
concerns regarding their discovery (privacy) , accessibility
(possible breach) and data integrity (confidentiality). Furthermore,
the multitude of diverse IoT devices using different communication
protocols may create siloed communications. The sheer number of IoT
devices expected to be deployed by 2020 will introduce new challenges
that may be overcome by using the infrastructure of Identifier-based
solutions.
The deployment of 5G network infrastructures coupled with
applications (such as augmented reality, virtual reality, 8k videos)
are also putting more constraints, such as ultra-low latency with
session continuity, on the underlying connectivity infrastructures
[GSMA1] [GSMA2]. Identifier-based protocols can support mobility
provided they have an efficient mapping service.
Furthermore the vision of Network Slicing, that is a fundamental
feature of the 5G systems, has evolved from a simple network overlay
concept to enabling dynamic multi-service and multi-tenancy support,
that transforms the networking perspective by abstracting, isolating
and separating logical network behaviors from the underlying physical
network resources. The generic architecture proposed by IDEAS
facilitates these applications, in particular the decoupling of the
entity identifier from the locator can also help to select the
optimal control plane and user plane as well as compose and allocate
virtualized network functions inside the core or radio access network
depending on the service requirements. In the same way, the
dynamically and on-demand virtual slices creation need an efficient
mapping service between entity identifier and locator.
This document examines the possible changes and improvements needed
to address these challenges in Identity Enabled Networks (IDEAS).
Pillay-Esnault, et al. Expires September 13, 2017 [Page 3]
Internet-Draft March 2017
To provide some background, this memo gives a brief overview of what
are Identity Enabled Networks. Next, it describes the problem
statement and advocates for a standardized common control plane for
identity services, including identifier registration, mapping, and
resolution services.
Several key areas that should be investigated for the architecture
design of these services and how they interface with current and
future Identifier-aware protocols are listed.
The goal of the work proposed by this IDEAS initiative is to provide
a generic architecture that is scalable, extensible, robust, secure,
and flexible for future networks.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Definition of Terms
Entity : An entity is a communication endpoint. It can be a
device, a node, or a (software) process, that needs to be
identified. An entity may have one or multiple identifiers
simultaneously. An entity is reached by the resolution of one or
more of its identifiers to one or more locators.
Entity Collection: A set of entities with its own identifier,
e.g., a multicast group, or an ad-hoc vehicular network that needs
to be uniquely identified (e.g., a train entity may represent a
Closed User Group (CUG) and may contain all the passengers'
devices that share the same fate for connectivity).
Identifier (ID): denotes information to unambiguously identify an
entity within a given scope. There is no constraint on the
format, obfuscation or routability of an ID. The ID may or may
not be present in the packet whose format is defined by ID-based
protocols.
Locator (LOC): denotes information that is topology-dependent and
which is used to forward packets to a given entity attached to a
network. An entity can be reached using one or multiple locators;
these locators may have a limited validity lifetime.
Identity: the essence of "being" of a specific entity. An
identity is not to be confused with an identifier: while an
identifier may be used to refer to an entity, an identifier's
Pillay-Esnault, et al. Expires September 13, 2017 [Page 4]
Internet-Draft March 2017
lifecycle is not necessarily tied to the lifecycle of the identity
it is referencing. On the other hand, the identity's lifecycle is
inherently tied to the lifecycle of the entity itself.
IDentity Enabled Networks (IDEAS): IDEAS are networks that support
the identifier/locator decoupling. Reaching an entity is achieved
by the resolution of identifier(s) to locator(s).
Identifier-based (ID-based): When an entity is only reachable
through one or more communication access then a protocol or a
solution is said to be ID-based if it uses an ID-LOC decoupling
and a mapping system (MS) as base components of the architecture.
Identity-capable (ID-capable): An application is said to be ID-
capable if it makes use of an Identifier of an entity to establish
communication. For example, an application that initiates its
sessions using an ID. An application may use an IP-address as a
proxy for an ID if the network resolves this ambiguity. We regard
such an application as being ID-capable.
Generic Resilient Identity Services (GRIDS): GRIDS is a set of
services to manage the lifecycle of IDs, to map and resolve
identifiers and locators, and to associate metadata (META) with
entities and entity collections. It is a distributed system that
stores the ID, the associated LOC(s), and metadata (META) in the
form of tuples (ID, LOC, and META).
Metadata (META): is data associated with an Identity. The
metadata may contain information such as the nature of the entity
for example.
5G: Fifth generation wireless broadband technology [NEWS-3GPP].
Scope: denotes the domain of applicability or usability of an ID.
A scope may be limited (e.g., considered local with geographic
proximity, or private within an administrative domain) or be
global.
4. Brief Overview of ID Enabled Networks
The proposals of separating the ID from the LOC are not new.
Location/Identifier Separation Protocol (LISP) [RFC6830] and
Identifier Locator Addressing [ILA] solutions have been deployed in
data centers (DC). Host Identity Protocol (HIP) [RFC7401] has been
deployed as a host-based solution.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 5]
Internet-Draft March 2017
The use of mobile devices with critical applications and fast
mobility introduce additional constraints to address the combination
of the following requirements:
a. Ultra-low latency [GSMA1][GSMA2]
b. Session continuity
c. Mobility across heterogeneous multi-access networks
d. Network Slicing
IoT device technologies introduce other constraints such as battery
life (up to ten year battery life for low power devices [GSMA2]) may
not allow connected devices to constantly signal their position or
limit the way they communicate. For example, in order to save energy
a pet tracker may have intermittent one-way communication just to
signal periodically its location.
As the number of personal devices increases, they may be grouped in a
cluster belonging to a closed user group or perhaps a class of
devices. There will be a need to identify such groups and register
them for multicasting or broadcasting. As the number of personal
devices increases, they may be grouped in various clusters or closed
user groups (depending on the nature of the IoT service and the need
to manage small communities on the fly) or perhaps a service-inferred
class of Devices (e.g., healthcare bracelets, heat sensors, infrared
CCTV, etc.). There will be a need to identify such groups and
clusters, and register them for multicasting or broadcasting purposes
(e.g., to optimize resource management when sending a set of
commands). Another example Energy management in smart cities may
send commands to all lampposts that belong to different groupings
(street or neighborhood).
Therefore, any ID/LOC separation solution will require an
infrastructure that secures registration, efficient discovery, and
can manage complex lookups(e.g. all cameras of a brand in a factory
floor) as well mapping/resolution services.
4.1. Identifiers Role in a Communication Session
The IDentity Enabled networkS (IDEAS) intend to define the use of
Identifiers (ID) as follows:
o An ID is a way to identify communication endpoints of an entity.
The ID of an entity abstracts its communication endpoints from its
location. There is a distinction as well that the ID to a locator
Pillay-Esnault, et al. Expires September 13, 2017 [Page 6]
Internet-Draft March 2017
address mapping is a way to reach the entity but not tied to a
specific interface address on the device itself.
o Even though IDs may be sent inside a packet, they may be encrypted
(or not) and may not be globally routable.
o A single entity may have multiple IDs, and IDs of the same entity
may have different life spans that are different from the lifespan
of the entity. Furthermore, it is understood that IDs may have
different lifecycles, which may be permanent or ephemeral by
choice or design.
o Ephemeral (temporary) IDs may be used as a short-lived pseudonym
for a permanent ID to protect the privacy of the related entity.
o Involved entities may have multiple IDs that are used to initiate
a communication . Specifically, they are not just passive objects
that need to be referenced and located in the Internet, but are
live endpoints that may initiate a session while in motion or not.
o Finally, entities with these IDs may be moving over large
geographical distances and across multiple administrative domains.
Therefore, there is no guarantee that they will retain their IP
address.
4.2. Mapping/Resolution Services in GRIDS differ from Domain Name
Service (DNS)
The resolution of the ID into a locator is often mistaken as a NAT-
like translation or even a DNS type of indirection. Since the 1980s,
DNS has been pivotal to translate human readable names that are easy
to remember into hard-to-remember IP addresses. It provides a global
distributed directory service and is a very powerful and useful
technology to translate the domain name hierarchy to IP address
space. ]. The use of DNS, as is, is therefore unlikely to meet the
challenges posed to GRIDS.
Even though the DNS was designed to be resilient, it is prone to DDOS
attacks as discussed extensively in the Technical Plenary of IETF97.
Furthermore, some studies have also described challenges in the
response time and caching techniques and latency in the Internet
[DNS1] [DNS2] [DNS3]. The use of a mapping system rather than using
DNS system has been discussed extensively in [IVIP], [RFC6115] and on
the lisp-wg mailing list [LISP-DIS].
Pillay-Esnault, et al. Expires September 13, 2017 [Page 7]
Internet-Draft March 2017
5. Key Problems
5.1. Common Control Plane Infrastructure
Today, most locator/identifier separation solutions rely on a control
plane that resolves an ID to one or multiple locators. Eventually,
the control plane may be used to define other policies that are
enforced by the devices that participate to the delivery and the
operation of a connectivity service. These solutions implement their
own resolution methods. The resolution service may leverage push-
based protocols (traditional routing protocols and [LISP-SUBS]),
pull-based control planes (DNS and LISP), third party software, or
any combination thereof.
Currently, each of the ID-based protocols uses its own specific
mapping databases. While ID-enabled data plane mechanisms may serve
fundamentally different objectives and may not need to interoperate
in the past, there is a potential benefit in providing them with a
common interface for services such as registration, discovery, update
and resolution and new services such as security or access control
policy. Furthermore, the lack of a mapping system with standardized
invocation interfaces has the following downsides:
a. An impediment for the deployment of ID-enabled solutions.
Indeed, it would be inefficient to deploy several specialized
mapping/resolution network databases within the same
administrative domain. Furthermore, there will be additional
expense and overhead to administer multiple proprietary mapping
systems.
b. Difficulty to have an overall view of the network. If multiple
ID-enabled solutions with distinct mapping systems are deployed,
troubleshooting may be difficult as the information may be
located in different places.
c. Complex Management due to disjoint information spread over
several mapping systems. Operations such as merging networks are
error prone and more challenging to detect and fix.
Additionally, there will be considerable management overhead
whenever devices migrate.
d. Barriers to the application of common and consistent policies.
For example, in cross-platform IoT networking, brokering services
may be needed to enforce routing/security/QoS/TE policies on
behalf of partnering structures - service provider, energy
provider, content provider, etc.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 8]
Internet-Draft March 2017
e. Risk for fragmented connectivity. A high diversity of mapping
system variants will create silos of communications.
f. Complex cross-MS communications. A common resolution system
infrastructure may facilitate cross-MS communications. Today it
is difficult to communicate with multiple customized ID mapping
systems with distinct interfaces.
The common control plane may support limited or private scopes. In
addition support of private instances provides the necessary
separation for specific users or applications.
The emergence of dynamic (small-sized) communities or closed, on-the-
fly, user groups puts additional pressure on the mapping system, from
several standpoints that include robustness, availability,
scalability and reliability.
5.2. Identifier Lifecycle
Currently, there is no guidance or allocation scheme for public IDs.
Each protocol has historically assigned their ID independently, be it
structured or not. An agreed upon ID format and scope may facilitate
cross-domain communication and simplify the implementation of some
use cases to facilitate cross-silo communications or to better
address the merging of networks
The support of several allocation schemes by carving specific ranges
within a name space and recycling should be explored for the future
mapping systems. The operations and ease of deployment should also
be considered as they may influence policy enforcement schemes
related to the allocation of IDs of the use of relevant metadata.
5.3. Security of Mapping Systems
As access to a mapping system may reveal the location and other
sensitive information about an ID, any breach is therefore considered
a security risk.
Secured access and data integrity to current mapping systems may not
be guaranteed. It is possible to register erroneous information in
some cases if the system is under attack [LISP-SEC]. Similarly, in
the absence of DNSSEC, HIP RR is vulnerable [RFC8005].
5.4. Distributed Denial of Service Attack Prone
The DNS system is vulnerable to DDOS attacks. The HIP protocol
relies on DNS for the publication of public Host Identifier
[HIP-ARCH].
Pillay-Esnault, et al. Expires September 13, 2017 [Page 9]
Internet-Draft March 2017
The other current mapping systems are not specifically designed to be
protected against a DDOS attack. This is a potential issue as they
have well-known IP addresses and registration depends on their
reachability.
6. Use Cases
The use cases are discussed in detail in [IDEAS-USE].
7. Relationship between IDEAS and other IETF Working Groups
This document is meant to encourage the IETF community to investigate
the opportunity of a new specification effort to address some
specific problems from an ID Enabled Networks standpoint in general.
The focus is to find a common solution and infrastructure that can be
shared by current protocols and facilitate the introduction of new
ID-based services while avoiding rehashing the same problems again
each time a new service pops up.
It proposes to address these problems with a Generic Resilient ID
Services infrastructure which includes standardized access and
multiple services. The services include secured registration,
discovery, updates with data integrity, mapping and resolution
capabilities, define relationships between IDs or group of IDs,
access control policy and security.
Some other working groups are already working to address some
specific limitations or enhancement of ID-capable protocols. These
working groups include LISP, HIP and NVO3.
Protocols and architectures defined by these WGs may assume a mapping
system or other resolution techniques, but they are not currently
covering the other services mentioned in this document.
7.1. LISP WG
The LISP WG has been working on multiple mapping systems (ALT, DDT)
for the LISP control plane and the primary function of this mapping
system is to map and resolve the ID to IP addresses (EID/RLOC
mapping). Though some requirements are common, GRIDS has new
specific requirements that are described in [IDEAS-REQ].
7.2. HIP WG
The HIP WG has based its resolution service on DNS and sections 4.2,
5.3 and 5.4 of this document describe some of the vulnerabilities of
this solution to address the requirement for fast mobility with low
latency.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 10]
Internet-Draft March 2017
7.3. NVO3 WG
The NV03 WG has been working on a mapping of VN names to VN IDs in
the network virtualization space and their requirements differ from
the wireless broadband requirements and cross-silo communications
that have been mentioned in this document.
8. Security Considerations
Due to the sensitivity of Identity tied to identifier and locator,
there is a need to pay attention to security ramifications. In
particular, the security goals should include confidentiality,
possible encryption for integrity of sensitive data and privacy.
Various aspects of security and the security requirements for IDEAS
are discussed in TBD document.
9. IANA Considerations
This document has no actions for IANA.
10. Contributors
This present document is based on an extract of the first version of
the draft. The authors and their affiliations on the original
document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D.
Lake (Cisco Systems), T. Herbert (Facebook), M. Menthe (University
of Tuebingen), Dipenkar Raychaudhuri (Rutgers University), Julius
Mueller (ATT) and Padma Pillay-Esnault (Huawei).
There are two companion documents also extracted from the -00 version
of this document: Problem Statement in IDEAS [IDEAS-USE] and GRIDS
Requirements [IDEAS-REQ].
The following individuals substantially contributed to this document:
o Georgios Karagiannis
o Alex Clemm
o Uma Chunduri
11. Acknowledgments
The authors would like to thank Alex Clemm, Uma Chunduri, Georgios
Karagiannis, Stewart Bryant, Michael Menth, Liu Bingyang, Yingzhen Qu
and Onur Ozan Koyluoglu for their review and input on this document.
The authors would like to thank Renwei Li, Jeff Tansura, Burjiz
Pillay-Esnault, et al. Expires September 13, 2017 [Page 11]
Internet-Draft March 2017
Pithawala, Lin Han and Kiran Makhijani and Jean-Michel Esnault who
participated in numerous discussions.
This document was produced using Marshall Rose's xml2rfc tool.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References
[DNS1] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
Performance and the Effectiveness of Caching", 2002,
<http://nms.lcs.mit.edu/papers/dns-ton2002.ps>.
[DNS2] Liston, R., Srinivasan, S., and E. Zegura, "DNS
Performance and the Effectiveness of Caching", 2002,
<http://www.cc.gatech.edu/fac/Ellen.Zegura/papers/
dnsdiversity.pdf>.
[DNS3] Briscoe, B., Anna Brunstrom, A., Andreas Petlund, A.,
David Hayes, D., David Ros, D., Ing-Jyh Tsang, I., Stein
Gjessing, S., Gorry Fairhurst, G., Carsten Griwodz, C.,
and M. Michael Welzl, "Reducing Internet Latency: A Survey
of Techniques and their Merits", November 2014,
<http://ieeexplore.ieee.org/document/6967689/>.
[GSMA1] GSMA, "Unlocking Commercial Opportunities From 4G
Evolution to 5G", February 2016,
<http://www.gsma.com/network2020/wp-content/uploads/2016/0
3/704_GSMA_unlocking_comm_opp_report_v6.pdf>.
[GSMA2] GSMA, "Understanding 5G: Perspectives on future
technological advancements in mobile", December 2014,
<https://www.gsmaintelligence.com/
research/?file=141208-5g.pdf>.
[HIP-ARCH]
Moskowitz, R. and M. Komu, "An Architectural Introduction
to the Locator/ID Separation Protocol", November 2016,
<https://datatracker.ietf.org/doc/draft-ietf-hip-
rfc4423-bis/>.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 12]
Internet-Draft March 2017
[IDEAS-REQ]
Pillay-Esnault, P., Clemm, A., Farinacci, D., and D.
Meyer, "Requirements for Generic Resilient Identity
Services in Identity Enabled Networks", March 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas-req-
grids/>.
[IDEAS-USE]
Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet,
C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri,
"Use Cases for Identity Enabled Networks", March 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas-use-
cases-00/>.
[ILA] Herbert, T., "Identifier-locator addressing for network
virtualization", March 2016,
<https://datatracker.ietf.org/doc/draft-herbert-
nvo3-ila/>.
[IVIP] Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
Architecture", September 2010,
<https://tools.ietf.org/html/draft-whittle-ivip-arch-04>.
[LISP-DIS]
"LISP Discussion", <https://www.ietf.org/mail-
archive/web/lisp/current/msg03733.html>.
[LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"LISP-Security", November 2016,
<https://tools.ietf.org/html/draft-ietf-lisp-sec-12/>.
[LISP-SUBS]
Boucadair, M. and C. Jacquenet, "LISP Subscription",
February 2017, <https://tools.ietf.org/html/draft-
boucadair-lisp-subscribe-04/>.
[NEWS-3GPP]
3GPP, "3GPP News",
<http://www.3gpp.org/news-events/3gpp-news>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007,
<http://www.rfc-editor.org/info/rfc4984>.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 13]
Internet-Draft March 2017
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture",
RFC 6115, DOI 10.17487/RFC6115, February 2011,
<http://www.rfc-editor.org/info/rfc6115>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <http://www.rfc-editor.org/info/rfc8005>.
Authors' Addresses
Padma Pillay-Esnault (editor)
Huawei
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: padma.ietf@gmail.com
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Pillay-Esnault, et al. Expires September 13, 2017 [Page 14]
Internet-Draft March 2017
Giuseppe Fioccola
Telecom Italia
Email: giuseppe.fioccola@telecomitalia.it
Axel Nennker
Deutsche Telekom
Email: Axel.Nennker@telekom.de
Pillay-Esnault, et al. Expires September 13, 2017 [Page 15]