Network Working Group B. Carpenter
Internet-Draft IBM
Expires: October 19, 2007 April 17, 2007
General Identifier-Locator Mapping Considerations
draft-carpenter-idloc-map-cons-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 19, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document presents various general considerations about the
mapping between identifiers and locators at the network and routing
level in the Internet.
Carpenter Expires October 19, 2007 [Page 1]
Internet-Draft Identifier-Locator Mapping April 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definition of terms . . . . . . . . . . . . . . . . . . . 3
1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5
2. Identifier and Locator Behaviour Today . . . . . . . . . . . . 5
3. Is a Split the Solution? . . . . . . . . . . . . . . . . . . . 8
4. Mapping Goals . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Many Locator Namespaces . . . . . . . . . . . . . . . . . 9
4.2. One Identifier Namespace . . . . . . . . . . . . . . . . . 10
4.3. Two-Faced Maps? . . . . . . . . . . . . . . . . . . . . . 10
4.4. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. What Does an Identifier Look Like? . . . . . . . . . . . . 10
4.6. Do Identifiers have Useful Properties? . . . . . . . . . . 10
4.7. What Does a Locator Look Like? . . . . . . . . . . . . . . 11
4.8. Who Needs the Map? . . . . . . . . . . . . . . . . . . . . 11
4.9. What is the lifetime of a mapping? . . . . . . . . . . . . 12
4.10. How Does the Map Relate to Mobility? . . . . . . . . . . . 12
4.11. Who chooses the Locator? . . . . . . . . . . . . . . . . . 12
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Carpenter Expires October 19, 2007 [Page 2]
Internet-Draft Identifier-Locator Mapping April 2007
1. Introduction
In the discussions following the IAB Routing and Addressing workshop
[I-D.iab-raws-report], a common observation is that a key issue in
today's Internet is the overlapping semantics of IP addresses used as
'locators' and as 'identifiers.' A rather hasty conclusion from this
is that the architectural solution is a 'identifier-locator split.'
This conclusion is discussed below. However, if we accept that
locators and identifiers have different (if overlapping) semantics,
the question immediately arises of how they can be mapped onto one
another. Given a locator, which identifier(s) refer to the same
entity? Given an identifier, which locator(s) refer to the same
enity? The main part of this document discusses the considerations
raised by these questions.
1.1. Definition of terms
IP Address: an IPv4 or IPv6 address, viewed as an opaque 32 or 128
bit quantity.
Stack: An active instantiation of the TCP/IP model; one participant
or the process on one side of an end-to-end communication. That
participant may move and may be represented by multiple hosts.
Quoting from an unpublished document produced within the former
Namespace Research Group [NSRG]:
------------Start Quotation------------
Carpenter Expires October 19, 2007 [Page 3]
Internet-Draft Identifier-Locator Mapping April 2007
Today, a host may represent multiple entities. This happens when a
service provider hosts many web sites on one server. Similarly, a
single entity may be represented by multiple hosts. Replicated web
servers are just such an example. These entities are "protocol
stacks" or simply "stacks", instantiations of the TCP/IP model, be
they across one or many hosts. A stack is defined as one
participant or the process on one side of an end-to-end
communication. That participant may move and may be represented by
multiple hosts.
__________________ ________________________
| | | |
| _______________| |____________________ |
| /_______________| |___________________ /| |
| | A P P L I| |C A T I O N |f| |
| |----------------| |-------------------|o| |
| | T R A N | | P O R T |o| |
| |----------------| |-------------------|.| |
| | I N T E| |R N E T |c| |
| |----------------| |-------------------|o| |
| | F R A M| | I N G |m| |
| |----------------| |-------------------| / |
| |________________| |___________________|/ |
| | | |
|__________________| |________________________|
Figure 4: Another application: single stack represented by multiple
hosts
Each instance of a stack has a name, a "stack name". At an
architectural level the Name Space Research Group debated the value
of such names, and their associated costs. Forms of this name are
used in numerous places today. SSH uses public/private key pairs to
identify end points. An HTTP cookie anonymously identifies one end
of a communication, in such a manner that both the connection and the
IP address of the other end point may change many times. Stack names
are intended to identify mobile nodes, devices behind NATs, and
participants in a content delivery or overlay network.
------------End Quotation------------
Locator: A binary quantity (not necessarily an IP Address) that can
be used by a routing or forwarding device to decide where to send a
packet.
Identifier: A binary quantity (not necessarily an IP Address) that
can be used by a Stack "A" to uniquely identify another Stack "B"
Carpenter Expires October 19, 2007 [Page 4]
Internet-Draft Identifier-Locator Mapping April 2007
both for bilateral communication and for informing a third Stack "C"
that it should communicate with stack "B".
Namespace: a set of natural numbers, each of which is referred to as
a name. Since it is a set, by definition each name is unique and
thus the namespace is unambiguous. Locators and Identifiers must
belong to specific namespaces.
Namespace Context: the context within which a given namespace retains
its uniqueness property. (For example, the Namespace Context of the
Namespace created by [RFC1918] is a single Internet site.)
1.2. Related Work
[I-D.nikander-ram-ilse] discusses the design space for Identifier-
Locator Separation and contains excellent background references.
[I-D.farinacci-lisp], [I-D.wang-ietf-efit], and [I-D.templin-ipvlx]
discuss solutions along the encapsulation axis. SHIM6
[I-D.ietf-shim6-proto] is a host-based solution along the dynamic
translation axis. [GSE] was a router-based solution along the
dynamic translation axis. HIP [RFC4423] is a real new namespace.
Early thinking on this whole topic should be credited to Noel Chiappa
[ENDPOINTS], who in turn cites related work back to 1978.
2. Identifier and Locator Behaviour Today
[RFC2101] discussed "IPv4 Address Behaviour Today" (where "today" was
February 1997). It focused on the then new issues caused by private
addresses [RFC1918], dynamic address allocation, and network address
translation. Its fundamental observations remain true:
------------Start Quotation------------
Carpenter Expires October 19, 2007 [Page 5]
Internet-Draft Identifier-Locator Mapping April 2007
Due to dynamic address allocation and increasingly frequent
network renumbering, temporal uniqueness of IPv4 addresses is no
longer globally guaranteed, which puts their use as identifiers
into severe question. Due to the proliferation of Intranets,
spatial uniqueness is also no longer guaranteed across routing
realms; interconnecting routing realms could be accomplished via
either ALGs or NATs. In principle such interconnection will have
less functionality than if those Intranets were directly
connected. In practice the difference in functionality may or may
not matter, depending on individual circumstances.
...
As far as temporal uniqueness (identifier-like behaviour) is
concerned, the IPv6 model [RFC 1884] is very similar to the current
state of the IPv4 model, only more so. IPv6 will provide mechanisms
to autoconfigure IPv6 addresses on IPv6 hosts. Prefix changes,
requiring the global IPv6 addresses of all hosts under a given prefix
to change, are to be expected. Thus, IPv6 will amplify the existing
problem of finding stable identifiers to be used for end-to-end
security and for session bindings such as TCP state.
The IAB feels that this is unfortunate, and that the transition to
IPv6 would be an ideal occasion to provide upper layer end-to-end
protocols with temporally unique identifiers. The exact nature of
these identifiers requires further study.
------------End Quotation------------
So here we are. How is the discrepancy between identifier and
locator namespaces handled today (2007)?
The discrepancy can be summarised as follows: the progressive
shortage of IPv4 addresses, coupled with the lack of economic
incentive to deploy IPv6, have led to generalised use of private
addresses within enterprise and home networks. Thus, we have
disjoint Locator Namespaces - roughly speaking, one very large
Locator Namespace commonly referred to as the Internet, and a
separate Locator Namespace for every network "behind" a NAT.
However, much software, and many protocols, have been designed on the
assumption that we have a single Identifier Namespace, which is
furthermore assumed to be identical to the Internet Locator
Namespace. Neither of these assumptions is true.
We should also note that with IPv6 partially deployed, we already
have two distinct Locator Namespaces. Mathematically, we could deem
them to be a single Locator Namespace - but little existing software
is prepared to treat IPv4 and IPv6 as a single Identifier Namespace,
even though IPv6 does not suffer from IPv4's problem of ambiguous
addresses.
Carpenter Expires October 19, 2007 [Page 6]
Internet-Draft Identifier-Locator Mapping April 2007
To work around these false assumptions, several measures have been
taken, none of them as a result of architectural design:
o Network Address Translation. Effectively, a NAT creates a dynamic
mapping between two Locator Namespace Contexts (sometimes using a
port number to tag the mapping). The focus of a NAT is to enable
packet delivery; but it inserts a context boundary in the
Identifier Namespace. NATs and their associated ALGs make a
clumsy attempt to fix this by (for example) recomputing TCP
checksums. However, it is a fundamental fact that the NATs and
ALGs cannot know how the two ends of a communication use the
Identifier Namespace, and therefore it is logically impossible for
them to fix up the Identifier Namespace in general. Furthermore,
NATs do not publish the Identifier/Locator mappings they have
created, so the affected Stacks have no sure way to discover it.
o Kludge it up. For a specific application or set of applications,
a way round the namespace discrepancy can be constructed,
essentially by deducing from external evidence the Identifier/
Locator mapping that a NAT has created, and signalling that
mapping to all interested Stacks. The best known examples are
STUN [RFC3489] and ICE [I-D.ietf-mmusic-ice].
o Build your own namespace. Fortunately for people wishing to
construct novel Internet applications, there is a very convenient
way to ignore the whole problem: make use of the fact that every
NAT has an associated ALG that translates HTTP/TCP packets
appropriately, and incidentally that HTTP passes through most
security checks. Similarly, an HTTP proxy can hide an IPv4/IPv6
boundary. Thus, despite the strong recommendation to the contrary
in [RFC3205], many application suites have been built to run over
HTTP, rooting their own Identifier Namespace in some way in the
DNS. An interesting example is the massive Web Services suite,
whose XML-based namespace derives its uniqueness from the
uniqueness of DNS names. It is clear that if this technique were
not available, we would have confronted the network's Identifier
Namespace problem years ago, or all innovation would have stopped.
A separate observation about today's situation is that we can loosely
divide upper layer implementations (transport layer and above) into
two classes:
1. Those that use a socket API, or the equivalent, on the
traditional assumption that an IP Address is simultaneously a
unique Locator and a unique Identifier. These are automatically
subject to unpredictable problems when they encounter Identifier/
Locator ambiguity.
2. Those that avoid this assumption, for example by creating their
own namespace or relying completely on the DNS.
Confusion can nevertheless occur, for example in an application that
believes that using a URL-based namespace protects it from ambiguity,
Carpenter Expires October 19, 2007 [Page 7]
Internet-Draft Identifier-Locator Mapping April 2007
but encounters a URL containing a literal Net 10 address.
A related issue is the way network elements are monitored and
managed. The predominant assumption is that the IP Address of a
network element (router, switch, bridge, server or user device) both
identifies and locates it. In a network of any size, the IP
Addresses of network elements are embedded in network configuration
and monitoring systems in many ways. The assumption generally made
by operations staff is that there is a single namespace; the notion
of an identifier-locator split is unknown. An illustration of this
is that many MIBs include IP Addresses; the contents of such MIBs
cannot readily be used outside their original Namespace Context.
3. Is a Split the Solution?
Given that our problem is overlapping namespaces, it's tempting to
conclude that splitting them is the solution. But what does this
mean, and is it practical?
As implied by the previous section, there are cases where a split
would increase rather than decrease confusion. Enterprise network
operations would be turned upside down. Firewalls would have to deal
with fundamental change, since identifiers rather than locators would
be the focus of many attacks. The way the DNS and the socket API are
related to each other might change. Any upper layer implementation
that believes that an IP Address is both a Locator and an Identifier
would be in even greater trouble than today. And of course the
fragile superstructure built on NATs and ALGs would be severely
challenged.
This is, no doubt, why the IAB's suggestion in [RFC2101], quoted
above, has borne no fruit, except for HIP [RFC4423], which still
remains R&D.
It is this author's contention that no solution which removes the
ability of upper layers and management systems to treat the
Identifier and Locator Namespaces as identical within some well
defined context is deployable in practice. That is not to say there
will be no upper layer Namespaces, very likely rooted in DNS as
today. But at the level of packet transmission, and the network
elements and Stacks that handle them, we need unified Namespaces
within certain Namespace Contexts. In practice this means that
network elements and Stacks need to be able to treat things that look
like an IP Address as they do today, but with a clear definition of
the context within which Identifiers and Locators are the same thing,
and of the contexts in which they are not.
Carpenter Expires October 19, 2007 [Page 8]
Internet-Draft Identifier-Locator Mapping April 2007
To be concrete, consider three Stacks A, B and C in three
adminstratively separate sites. What Locator and Identitfier
properties do they require?
Within its site, A must have an Identifier and Locator that match 1:1
for the convenience of operational staff, and do not vary in a way
unexpected by those operational staff. The same is true for B and C
respectively. In this context there is no advantage in an id-loc
split; in fact it would introduce operational confusion.
When communicating with B, A must provide an Identifier that B can
rely on, and conversely. To send its packets, A must either know a
Locator for B that is valid in the context of site A, or send the
packet to a router that knows such a Locator (given B's Identifier).
The same is true in the reverse direction.
It is irrelevant to A and B if the Locator used by A (or A's router)
is only valid locally at site A, i.e. if the locator changes once or
several times along the way. All that matters is that the packet be
delivered to B, still carrying A's Identifier.
A must also be able to communicate with C on the same basis, and
furthermore tell C that it may communicate with B as part of the same
application. Since we have admitted that the locator that A (or A's
router) knows for B may only be valid locally, it is required that A
only needs to communicate B's Identifier to C.
We conclude that:
o On-site, Identifiers and Locators should not be split.
o To go off-site, it is necessary to know which Locator leads
towards a given Identifier. Either the sending Stack or its
router could know this.
o The Identifier of the sending Stack must be delivered unchanged to
the receiving Stack.
o It must be possible to refer third party Stacks to a remote
Stack's Identifier.
4. Mapping Goals
With the above as background we can consider the goals of a mapping
mechanism between Identifier Namespace and Locator Namespaces (note
the plural).
4.1. Many Locator Namespaces
Every site using [RFC1918] has its own Locator Namespace. The IPv4
Internet constitutes another Locator Namespace, and IPv6 constitutes
Carpenter Expires October 19, 2007 [Page 9]
Internet-Draft Identifier-Locator Mapping April 2007
a Locator Namespace. We cannot exclude the existence of additional
(possibly secret) Locator Namespaces.
4.2. One Identifier Namespace
Going forward, we should aim to have exactly one Identifier Namespace
at network level. In different contexts, it will be mapped to
different Locator Namespaces.
4.3. Two-Faced Maps?
Since the Locator Namespace within a site is in the general case
different from the Internet Locator Namespace, there could in theory
be a need for two maps at a given site: Identifier Namespace to the
site's Locator Namespace, and Identifier Namespace to the Internet
Locator Namespace (plus some complications due to IPv4 and IPv6 being
different Internet Locator Namespaces). Two-faced maps can be
avoided only if we deem that on-site, Identifier equals Locator.
4.4. Scale
We want no arbitrary scaling limits. However, proposed scaling
targets are 10 to 100 billion Stacks (which scales the Identifier
Namespace), and 10 million sites. Although the latter does not
directly scale the Internet's Locator Namespace, it indicates the
worst-case granularity of the routing table for that Locator
Namespace. If we don't do better than random allocation of address
blocks to sites, we will end up with 10 million routing table
entries.
4.5. What Does an Identifier Look Like?
This is of course a question that HIP [RFC4423] has looked at,
although focussed on "hosts" rather than Stacks. In practice, the
difference is probably not so important - a Stack can be viewed as a
virtual host - and HIP in fact settled on using a HIT (Host Identity
Tag) as a 128-bit representation for a Host Identity in actual
packets. HIP further posits that "a HIT should be unique in the
whole IP universe as long as it is being used." Whether or not we
accept the HIP/HIT model in detail, choosing 128 bit opaque binary
objects as the baseline for Stack Identifiers seems like the obvious
conclusion, and can easily be rendered compatible with IPv6 or
embedded IPv4 addresses.
4.6. Do Identifiers have Useful Properties?
Thus far we assumed that Identifiers are opaque binary objects. Is
this a correct assumption? If they are truly opaque (e.g., HITs)
Carpenter Expires October 19, 2007 [Page 10]
Internet-Draft Identifier-Locator Mapping April 2007
they have no structure, cannot be aggregated in any sort of
hierarchy, and cannot be used for any kind of structured lookup. If
used on-site as Locators, they force use of flat routing. If they
are (for example) IPv6 Unique Local Addresses (ULA) [RFC4193], they
can be organized to match a site's subnet infrastructure and be used
in a convenient way in on-site routing and in reverse DNS. Both
architectural and design decisions need to be taken on this point.
4.7. What Does a Locator Look Like?
Unless we plan to destroy the Internet and build a new one, this is
pretty easy: it will look like an IPv4 or IPv6 prefix. Note that it
doesn't need to be a full address: routing an IPv4 packet to the site
border router handling a given /24 may be necessary and sufficient,
if that border router knows how to resolve the Identifier to a local
Stack Locator. So it is suggested that Locators in the map look
like:
Address type:Prefix/MaskLength
and of course it is legitimate to use /32 or /128 masks.
4.8. Who Needs the Map?
The minimal model is that the map is needed at every border router
that connects a customer site (or a local ISP) to one or more transit
providers. In that case, Stack A will simply send a packet to Stack
Identifier B in care of its default router, and the border router
will invoke the map to forward the packet to a Locator for B's site.
B's border router will remap, if necessary, to B's local Locator.
(However, that remapping will be a no-operation if, as suggested
above, on-site, Identifier equals Locator.)
In more complex scenarios, a Locator remapping could occur in
transit. In other words, in addition to A's and B's border routers,
which both sit at a point where the Locator Namespace Context
changes, the packet flows through another router at which such a
change occurs. Although this would represent a discontinuity in the
Internet Locator Namespace, it would not break the Locator mapping
model.
Note that if sites A and B were actually interconnected by an IP-
level VPN rather than by the Internet, this could readily be
represented in the map held by the two border routers. It's really
just a different way of representing a specific route.
Finally, the map could be held by the sending hosts. In a sense this
is what SHIM6 [I-D.ietf-shim6-proto] proposes, except that SHIM6
derives its map session-by-session without directly involving the
Carpenter Expires October 19, 2007 [Page 11]
Internet-Draft Identifier-Locator Mapping April 2007
routing system. But SHIM6 could certainly work equally well if it
acquired the map globally from some source, and moving SHIM6
functionality from the host to a proxy is being studied.
4.9. What is the lifetime of a mapping?
At a given instant in time, an Identifier will correspond to one or
more Locators. The mapping between a given Identifier and a given
Locator must have some valid lifetime, which is unlikely to be
infinite. For example, imagine a server with an assigned ULA
[RFC4193] or 6to4 address [RFC3056] as its Identifier. Assume it has
four corresponding Locators, the IPv6 and IPv4 addresses of the
site's border routers, which are connected to two different ISPs.
When the site decides to cancel one of its ISPs, the two
corresponding locators become invalid.
Lifetime could be much shorter for client machines configured
dynamically each time they connect to a site network, using DHCP or
IPv6 Neighbor Discovery. When such a machine boots up, it acquires
an Identifier, presumed to be equal to its Locator in the site
context. This will need to be mapped to all external Locators valid
for the site. That mapping will be valid only until the client
machine is removed from the site network.
How quickly will such changes in the map be propagated through the
Internet? Will old mappings be deleted from cache when a lifetime
expires, or will there be an explicit delete?
4.10. How Does the Map Relate to Mobility?
Is it correct, and sufficient, to say that whatever IP Address a
mobile system is currently using belongs to some site or other, and
the Identifier/Locator mapping for that site applies? In other
words, can we deem that id-loc mapping is orthogonal to mobility?
Alternatively, should we consider that dynamic id-loc mapping is
itself a mobility mechanism? What lessons can we learn from Mobile
IP? In fact, is Mobile IP anything other than an id-loc mapping
system?
4.11. Who chooses the Locator?
Because of multihoming, it's likely that the map will contain more
than one Locator for a given Identifier. An important consideration
is that the choice of locator should be under policy control, in
order that traffic should flow along the paths preferred by site or
ISP managers. The map needs to provide for some elementary policy
constructs such as precedence.
Carpenter Expires October 19, 2007 [Page 12]
Internet-Draft Identifier-Locator Mapping April 2007
5. Conclusion
This document doesn't analyze map distribution mechanisms in detail.
On the RAM mailing list, several alternatives have been listed, which
could be loosely classified as push, pull or discovery models, based
on either existing protocols and directory mechanisms, or something
new. It is hoped the foregoing discussion will provide background
for the choices to be made.
6. Security Considerations
An important decision must be made whether the mapping mechanism will
exist only in boxes deemed to be intrinsically trusted (i.e. routers
accessible exclusively by trusted personnel) or whether it will also
exist in boxes liable to general attack threats (i.e. hosts
accessible to a wide variety of users and not necessarily maintained
professionally). The threat analysis for a solution will be
significantly different in the two cases.
This document does not attempt a threat analysis in a vacuum. It is
clear that if Internet routing comes to depend on an Identifier to
Locator mapping service, that service could become an attack vector
for either packet diversion or denial of service unless adequately
protected. The threat analyses for MULTI6 [RFC4218], SHIM6 (see
Security Considerations in [I-D.ietf-shim6-proto]) and LISP
[I-D.bagnulo-lisp-threat] are illustrative.
7. IANA Considerations
This document requests no action by the IANA.
8. Acknowledgements
There are years of previous thinking and writing on this topic in the
Internet technical community. No claim to originality is made, and
overlooked references will be gladly added.
Contributions and comments by Eliot Lear, , and TBD are gratefully
acknowledged.
This document was produced using the xml2rfc tool [RFC2629].
Carpenter Expires October 19, 2007 [Page 13]
Internet-Draft Identifier-Locator Mapping April 2007
9. Informative References
[ENDPOINTS]
Chiappa, N., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture [unpublished]",
June 1995.
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture
for IPv6 [unpublished]", February 1997.
[I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis",
draft-bagnulo-lisp-threat-00 (work in progress),
March 2007.
[I-D.farinacci-lisp]
Farinacci, D., "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-00 (work in progress), January 2007.
[I-D.iab-raws-report]
Meyers, D., "Report from the IAB Workshop on Routing and
Addressing", draft-iab-raws-report-01 (work in progress),
March 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-15 (work in progress), March 2007.
[I-D.ietf-shim6-proto]
Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-07 (work in progress),
December 2006.
[I-D.nikander-ram-ilse]
Nikander, P., "Identifier / Locator Separation:
Exploration of the Design Space (ILSE)",
draft-nikander-ram-ilse-00 (work in progress),
February 2007.
[I-D.templin-ipvlx]
Templin, F., "IPvLX - IP with virtual Link eXtension",
draft-templin-ipvlx-06 (work in progress), October 2006.
[I-D.wang-ietf-efit]
Massey, D., "A Proposal for Scalable Internet Routing &
Addressing", draft-wang-ietf-efit-00 (work in progress),
Carpenter Expires October 19, 2007 [Page 14]
Internet-Draft Identifier-Locator Mapping April 2007
February 2007.
[NSRG] Lear, E. and R. Droms, "What's In A Name: Thoughts from
the NSRG [unpublished]", September 2003.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, February 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
Author's Address
Brian Carpenter
IBM
8 Chemin de Blandonnet
1214 Vernier,
Switzerland
Email: brc@zurich.ibm.com
Carpenter Expires October 19, 2007 [Page 15]
Internet-Draft Identifier-Locator Mapping April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Carpenter Expires October 19, 2007 [Page 16]