Internet DRAFT - draft-irtf-rrg-ilnp-adv
draft-irtf-rrg-ilnp-adv
Internet Draft RJ Atkinson
draft-irtf-rrg-ilnp-adv-06.txt Consultant
Expires: 10 Jan 2013 SN Bhatti
Category: Experimental U. St Andrews
10 July 2012
Optional Advanced Deployment Scenarios for ILNP
draft-irtf-rrg-ilnp-adv-06.txt
Status of this Memo
Distribution of this memo is unlimited.
Copyright (c) 2012 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.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or
IETF Contributions published or made publicly available
before November 10, 2008. The person(s) controlling the copyright
in some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the IETF
Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process,
and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.
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
Atkinson & Bhatti Expires in 6 months [Page 1]
Internet Draft ILNP ADV 10 JUL 2012
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is not on the IETF standards-track and does not
specify any level of standard. This document merely provides
information for the Internet community.
Abstract
This document provides an Architectural description and the
Concept of Operations of some optional advanced deployment
scenarios for the Identifier-Locator Network Protocol (ILNP),
which is an evolutionary enhancement to IP. None of the functions
described here is required for the use or deployment of ILNP.
Instead, it offers descriptions of engineering and deployment
options that might provide either enhanced capability or
convenience in administration or management of ILNP-based
systems.
Table of Contents
1. Introduction......................................?
2. Localised Numbering...............................?
3. An Alternative For Site Multi-Homing..............?
4. An Alternative For Site (Network) Mobility........?
5. Traffic Engineering Options.......................?
6. ILNP in Datacentres ..............................?
7. Location Privacy..................................?
8. Identity Privacy..................................?
9. Security Considerations...........................?
10. IANA Considerations...............................?
11. References........................................?
1. INTRODUCTION
At present, the Internet research and development community are
exploring various approaches to evolving the Internet
Architecture to solve a variety of issues including, but not
limited to, scalability of inter-domain routing [RFC4984]. A wide
Atkinson & Bhatti Expires in 6 months [Page 2]
Internet Draft ILNP ADV 10 JUL 2012
range of other issues (e.g. site multi-homing, node multi-homing,
site/subnet mobility, node mobility) are also active concerns at
present. Several different classes of evolution are being
considered by the Internet research & development community. One
class is often called "Map and Encapsulate", where traffic would
be mapped and then tunnelled through the inter-domain core of the
Internet. Another class being considered is sometimes known as
"Identifier/Locator Split". This document relates to a proposal
that is in the latter class of evolutionary approaches.
ILNP is, in essence, an end-to-end architecture: the
functions required for ILNP are implemented in, and controlled
by, only those end-systems that wish to use ILNP, as described
in [ILNP-ARCH]. Other nodes, such as Site Border Routers (SBRs)
need only support IP to allow operation of ILNP, e.g. an SBR
should support IPv6 in order to enable end-systems to operate
ILNPv6 within the site network for which an SBR provides a
service [ILNP-ENG].
However, some features of ILNP could be optimised, from an
engineering perspective, by the use of an intermediate system (a
router, security gateway or "middlebox") that modifies (rewrites)
Locator values of transit ILNP packets. It would also perform
other control functions for an entire site, as an administrative
convenience, such as providing a centralised point of management
for a site. For example, an SBR might manipulate the topological
presence of the packet, providing an elegant solution to the
provision of functions such as site (network) mobility for an
entire end site [ABH09a].
This document discusses several such optional advanced deployment
scenarios for ILNP. These typically use an ILNP-capable Site
Border Router (SBR).
Nothing in this document is a requirement for any ILNP
implementation or any ILNP deployment.
Readers are strongly advised to first read the ILNP Architecture
Description [ILNP-ARCH], as this document uses the notation and
terminology described or referenced in that document.
1.1 Document roadmap
This document describes engineering and implementation
considerations that are common to both ILNPv4 and ILNPv6.
The ILNP architecture can have more than one engineering
instantiation. For example, one can imagine a "clean-slate"
Atkinson & Bhatti Expires in 6 months [Page 3]
Internet Draft ILNP ADV 10 JUL 2012
engineering design based on the ILNP architecture. In separate
documents, we describe two specific engineering instances of
ILNP. The term ILNPv6 refers precisely to an instance of ILNP that
is based upon, and backwards compatible with, IPv6. The term ILNPv4
refers precisely to an instance of ILNP that is based upon, and
backwards compatible with, IPv4.
Many engineering aspects common to both ILNPv4 and ILNPv6 are
described in [ILNP-ENG]. A full engineering specification for
either ILNPv6 or ILNPv4 is beyond the scope of this document.
Readers are referred to other related ILNP documents for details
not described here:
a) [ILNP-ARCH] is the main architectural description of ILNP,
including the concept of operations.
b) [ILNP-ENG] describes engineering and implementation
considerations that are common to both ILNPv4 and ILNPv6.
c) [ILNP-DNS] defines additional DNS resource records that
support ILNP.
d) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message
used by an ILNP node to inform its correspondent nodes
of any changes to its set of valid Locators.
e) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option
used by ILNPv6 nodes (1) to indicate to ILNP correspondent
nodes (by inclusion within the initial packets of an ILNP
session) that the node is operating in the ILNP mode and
(2) to prevent off-path attacks against ILNP ICMP messages.
This Nonce is used, for example, with all ILNP ICMPv6
Locator Update messages that are exchanged among ILNP
correspondent nodes.
f) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message
used by an ILNP node to inform its correspondent nodes
of any changes to its set of valid Locators.
g) [ILNP-v4OPTS] defines a new IPv4 Nonce Option used by ILNPv4
nodes to carry a security nonce to prevent off-path attacks
against ILNP ICMP messages and also defines a new IPv4
Identifier Option used by ILNPv4 nodes.
h) [ILNP-ARP] describes extensions to ARP for use with ILNPv4.
Atkinson & Bhatti Expires in 6 months [Page 4]
Internet Draft ILNP ADV 10 JUL 2012
1.2 Terminology
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 RFC 2119
[RFC2119].
2. LOCALISED NUMBERING
Today, Network Address Translation [RFC3022] is used for a number
of purposes. Whilst one of the original intentions of NAT was to
reduce the rate of use of global IPv4 addresses, through use of
IPv4 private address space [RFC1918], NAT also offers to site
administrators a convenient localised address management
capability combined with a local-scope/private address space,
for example [RFC1918] for IPv4.
For IPv6, NAT would not necessarily be required to reduce the
rate of IPv6 address depletion, because the availability of
addresses is not such an issue as for IPv4. The IETF has
standardised Unique Local IPv6 Unicast Addresses [RFC4193],
which provide local-scope IPv6 unicast address space that can be
used by end sites. However, localised address management, in a
manner similar to that provided by IPv4 NAT and private address
space [RFC1918], is still desirable for IPv6 [RFC5902], even
though there is debate about the efficacy of such an approach
[RFC4864].
One of the major concerns that many have had with NAT is the loss
of end-to-end transport-layer and network-layer session state
invariance, which is still considered an important architectural
principle by the IAB [RFC4924]. Nevertheless, the use of
localised addressing remains in wide use and there is interest in
its continued use in IPv6, e.g. proposals such as [RFC6296].
It is possible to have the benefits of NAT-like functions for
ILNP without losing end-to-end state. Indeed, such a mechanism -
the use of Locator re-writing in ILNP - forms the basis of many
of the optional functions described in this document. In ILNP,
we call this feature "localised numbering".
Recall, that a Locator value in ILNP has the same semantics as a
routing prefix in IP: indeed, in ILNPv4 and ILNPv6 [ILNP-ENG],
routing prefixes from IPv4 and IPv6, respectively, are used as
Locator values.
We note that a deployment using private/local numbering can also
Atkinson & Bhatti Expires in 6 months [Page 5]
Internet Draft ILNP ADV 10 JUL 2012
provide a convenient solution to centralised management of site
multi-homing and network mobility by deploying SBRs in this manner
- this is described below.
Please note that with this proposal, localised numbering (e.g.
using the equivalent of IP NAT on the ILNP Locator bits) would
work in harmony with multihoming, mobility (for individual hosts
and whole networks), and IP Security, plus the other advanced
functions described in this document [BA11] [LABH06] [ABH07a]
[ABH07b] [ABH08a] [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10]
[ABH10] [BAK11].
2.1 Localised Locators
For ILNP, the NAT-like function can best be descried by using a
simple example, based on Figure 2.1.
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node
H = Host
L_1 = global Locator value
L_L = local Locator value
SBR = Site Border Router
Figure 2.1: A simple localised numbering example for ILNP.
In this scenario, the SBR is allocated global locator value L_1
from the upstream provider. However, the SBR advertises internally
a "local" Locator value L_L. By "local" we mean that the Locator
value only has significance within the site network, and any
packets that have L_L as a source Locator cannot be forwarded
beyond the SBR with value L_L as the source Locator. In
engineering terms, L_L would, for example in ILNPv6, be an IPv6
prefix based on the assignments possible according to IPv6 Unique
Local Addresses (ULA) [RFC4193].
Atkinson & Bhatti Expires in 6 months [Page 6]
Internet Draft ILNP ADV 10 JUL 2012
We assume that H uses Identifier I_H then it will use
Identifier-Locator Vector (IL-V) [I_H, L_L], and that the
correspondent node (CN) uses IL-V [I_CN, L_CN]. If we consider
that H will send a UDP packet from its port P_H to CN's port P_CN,
then, H could send a UDP/ILNP packet with the tuple expression:
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN> --- (1a)
When this packet reaches the SBR, it knows that L_L is a local
Locator value and so re-writes the source Locator on the egress
packet to L_1, and forwards that out onto its external-facing
interface. The value L_1 is a global prefix, which allows the
packet to be routed globally:
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (1b)
This packet reaches CN using normal routing based on the Locator
value L_1, as it is a routing prefix.
Note that from expressions (1a) and (1b), the end-to-end state (in
the UDP tuple) remains unchanged - end-to-end state invariance is
honoured, for UDP. CN would send a UDP packet to H as:
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (2a)
and the SBR would re-write the Locator value on the ingress packet
before forwarding the packet on its internal interface:
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L> --- (2b)
Again, this preserves the end-to-end transport-layer session
state invariance.
As the Locator values are not used in the transport layer pseudo
header for ILNP [ILNP-ENG], the checksum would not have to be
re-written. That is, the Locator re-writing function is stateless
and has low overhead.
(A discussion on the generation of Identifier values for initial
use is presented in [ILNP-ENG].)
2.2 Mixed local/global numbering
It is possible for the SBR to advertise both L_1 and L_L within
the site, and for hosts within the site to have IL-Vs using both
L_1 and L_L. For example, host H may have IL-Vs [I_H, L_1] and
[I_H, L_L]. The configuration and use of such a mechanism can be
controlled through local policy.
Atkinson & Bhatti Expires in 6 months [Page 7]
Internet Draft ILNP ADV 10 JUL 2012
2.3 Dealing with internal subnets with Locator re-writing
Where the site network uses subnets, packets will need to be
routed correctly, internally. That is, the site network may have
several internal Locator values, e.g. L_La, L_Lb, and L_Lc. When
an ingress packet has I-LV [I_H, L_1], it is expected that the
SBR is capable of identifying the correct internal network for
I_H, and so the correct Locator value to re-write for the ingress
packet. This is not obvious as the I value and the L value are
not related in any way.
There are numerous ways the SBR could facilitate the correct
lookup of the internal Locator value. This document does not
prescribe any specific method. Of course, we do not preclude
mappings directly from Identifier values to internal Locator
values.
Of course, such a "flat" mapping (between Identifier values and
Locators) would serve, but maintaining such a mapping would be
impractical for a large site. So, we propose the following
solution.
Consider that the Locator value, L_x consists of two parts, L_pp
and L_ss, where L_pp is a network prefix and L_ss is a subnet
selector. Also, consider that this structure is true for both
the local identifier, L_L, as well as the global Identifier, L_1.
Then an SBR need only to know the mapping from the values of L_ss
as visible in L_1 and the values of L_ss used locally.
Such a mapping could be mechanical, e.g. the L_ss part of L_L and
L_1 are the same and it is only the L_pp part which is different.
Where this is not desirable (e.g. for obfuscation of interior
topology), an administrator would need to configure a suitable
mapping policy in the SBR, which could be realised as a simple
lookup table. Note that with such a policy, the L_pp for L_L and
L_1 do not need to be of the same size.
From a practical perspective, this is possible for both ILNPv6
[RFC6177] and ILNPv4 [RFC4632]. For ILNPv6, recall that the
Locator value is encoded to be syntactically similar to an IPv6
address prefix, as shown in Figure 2.2, taken from [ILNP-ENG].
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
Atkinson & Bhatti Expires in 6 months [Page 8]
Internet Draft ILNP ADV 10 JUL 2012
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
L_pp = Locator prefix part (assigned IPv6 prefix)
L_ss = Locator subnet selector (locally managed subnet ID)
Figure 2.2: IPv6 address format [RFC3587] as used in ILNPv6,
showing how subnets can be identified.
Note that the subnet ID forms part of the Locator value. Note
also that [RFC6177] allows the global routing prefix to be more
than 45 bits, and for the subnet ID to be smaller, but still
preserving the 64-bit size of the Locator overall.
For ILNPv4, the L_pp value overall is an IPv4 routing prefix,
which is typically less than 32 bits. However, the ILNPv4 Locator
value is carried in the 32-bit IP address space, so the bits not
used for the routing prefix could be used for L_ss, e.g. for a
/24 IPv4 prefix, the situation would be as shown in Fig 2.3, and
L_ss could use any of the remaining 8-bits as required.
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
L_pp = Locator prefix (assigned IPv4 prefix)
L_ss = Locator subnet selector (locally managed subnet ID)
Figure 2.3: IPv4 address format for /24 IPv4 prefix, as used in
ILNPv4, showing how subnets can be identified.
As an example, for the case where the interior topology is not
obfuscated, an interior "engineering" node might have an LP
record pointing to eng.example.com and eng.example.com might have
L32/L64 records for a specific subnet inside the site. Meanwhile,
an interior "operations" node might have an LP record pointing at
"ops.example.com" which might have different L32/L64 records for
that specific subnet within the site. That is, eng.example.com
might have Locator value L_pp_1:L_ss_1 and ops.example.com might
have Locator value L_pp_1:L_ss_2. However, just as for IPv6 or
IPv4 routing today, the routing for the site would only need to
use L_pp_1, which is a routing prefix in either IPv6 (for ILNPv6)
Atkinson & Bhatti Expires in 6 months [Page 9]
Internet Draft ILNP ADV 10 JUL 2012
or IPv4 (for ILNPv4).
2.4 Localised name resolution with DNS
To support private numbering with IPv4 and IPv6 today, some sites
use a split-horizon DNS service for the site [ID-appDNS].
If a site using localised numbering chooses to deploy a
split-horizon DNS server, then the DNS server would return the
global-scope Locator(s) (L_1 in our example above) of the SBR to
DNS clients outside the site, and would advertise the local-scope
Locator(s) (L_L in our example above) specific to that internal
node to DNS clients inside the site. Such deployments of
split-horizon DNS servers are not unusual in the IPv4 Internet
today. If an internal node (e.g. portable computer) moves outside
the site, it would follow the normal ILNP methods to update its
authoritative DNS server with its current Locator set. In this
deployment model, the authoritative DNS server for that mobile
device will be either the split-horizon DNS server itself or the
master DNS server providing data to the split-horizon DNS server.
If a site using localised numbering chooses not to deploy a
split-horizon DNS server, then each internal nodes would
advertise the global-scope Locator(s) of the site border routers
in its respective DNS entries. To deliver packets from one
internal node to another internal node, the site would either
choose to use layer-2 bridging (e.g. IEEE Spanning Tree or IEEE
Rapid Spanning Tree [IEEE04], or a link- state layer-2 algorithm
such as the IETF TRILL group or IEEE 802.1 are developing), or
the interior routers would forward packets up to the nearest site
border router, which in turn would then rewrite the Locators to
appropriate local-scope values, and forward the packet towards
the interior destination node.
Alternately, for sites using localised numbering but not
deploying a split-horizon DNS server, the DNS server could return
all global-scope and local-scope Locators to all queriers, and
assume that nodes would use normal, local address/route selection
criteria to choose the best Locator to use to reach a given
remote node [RFC3484]. Hosts within the same site as the
correspondent node would only have a ULA configured, and hence
would select the ULA destination Locator for the correspondent
(L_L in our example). Hosts outside the site would not have the
same ULA configured (L_CN for the CN in our example). Note that
RFC3484 probably needs to be updated to indicate that the
longest-prefix matching rule is inadequate when comparing ULA-
based Locators with global-scope Locators: to choose a ULA for a
correspondent, a node must have a Locator that matches all ULA
Atkinson & Bhatti Expires in 6 months [Page 10]
Internet Draft ILNP ADV 10 JUL 2012
bits of the target Locator value.
Note that for split-horizon operation, there needs to be a DNS
management policy for mobile hosts, as when such hosts are away
from their "home" network, they will need to update DNS entries
so that the global-scope Locator(s) only is (are) used, and these
are consistent with the current topological position of the
mobile host. Such updates would need to be done using Secure
Dynamic DNS Update.
For an ILNP mobile network using LP records, there are likely to
separate LP records for internal and external use.
2.5 Use of mDNS
Multicast DNS (mDNS) [ID-mDNS11] is popularly used in many end-
system OSs today, especially desktop OSs (such as Windows, MacOSX
and Linux). It is used for localised name resolution using names
with a ".local" suffix, for both IPv4 and IPv6. This protocol
would need to be modified so that when an ILNP-capable node
advertises its ".local" name, another ILNP-capable node would be
able to see that it is an ILNP-capable, but other, non-ILNP nodes
would not be perturbed in operation. The details of a mechanism
for using mDNS to enable such a feature are not defined here.
2.6 Site Network Name in DNS
In this scenario, if H expects incoming ILNP session requests,
for example, then remote nodes normally will need to look up
appropriate Identifier and Locator information in the DNS. Just
as for IP, and as already described in [ILNP-ARCH], a Fully
Qualified Domain Name (FQDN) lookup for H should resolve to the
correct NID and L32/L64 records. If there are many hosts like H
that need to keep DNS records (for any reason, including to allow
incoming ILNP session requests), then, potentially, there are
many such DNS Resource Records.
As an optimisation, the network as a whole may be configured with
one or more L32 and L64 records (to store the value L_1 from our
example) that are resolved from an FQDN. At the same time,
individual hosts now have an FQDN that returns one or more LP
record entries [ILNP-DNS] as well as NID records. The LP record
points to the L32 or L64 records for the site. A multi-homed
site normally will have at least one L32 or L64 record for each
distinct uplink (i.e. link from a Site Border Router towards the
global Internet), because ILNP uses provider-aggregatable
Atkinson & Bhatti Expires in 6 months [Page 11]
Internet Draft ILNP ADV 10 JUL 2012
addressing.
More than one L32 or L64 will be required if multiple Locator
values are in use. For example, if an ILNPv6 site has multiple
links for multi-homing, it will use one L64 record for each
Locator value it is using on each link.
2.7 Site Interior Topology Obfuscation
In some situations, it can be desirable to obfuscate the details
of the interior topology of an end site. Alternately, in some
situations, local site policy requires that local-scope routing
prefixes be used within the local site. ILNP can provide these
capabilities through the ILNP local addressing capability
described here, under the control of the SBR.
As described in Sec. 2.3 above, locator re-writing can be used to
hid the internal structure of the network with respect to the
sub-netting arrangement of the site network. Specifically, the
procedure described in Sec 2.3 would be followed, with the
following additional modification of the use of Locator values:
(1) only the aggregated Locator value, i.e. L_pp, is advertised
outside the site (e.g. in an L32 or L64 record), and L_ss is
zeroed in that advertisement.
(2) the SBR needs to maintain a mapping table to restore the
interior topology information for received packets, for
example by using a mapping table from I values to either
L_ss values or to internal Locator values.
(3) the SBR needs to zero the L_ss values for all Source Locators
of egress packets, as well as performing an Locator re-writing
effecting the L_pp bits of the Locator value.
Of course, this only obscures the interior topology of the site,
not the exterior connectivity of the site. In order for the site
to be reachable from the global Internet, the site's DNS entries
need to advertise Locator values for the site to the global
Internet (e.g. in L32, L64 records).
2.8 Other SBR considerations
For backwards compatibility, for ILNP, the ICMP checksum is
always calculated identically as for IPv6 or IPv4. For ILNPv6,
this means that the SBR need not be aware if ILNPv6 is operating
Atkinson & Bhatti Expires in 6 months [Page 12]
Internet Draft ILNP ADV 10 JUL 2012
as described in [ILNP-ARCH] and [ILNP-ENG]. For ILNPv4, again,
the SBR need not be aware of the operation if ILNPv4 is operating
as it will not need to inspect the extension header carrying the
I value.
In order to support communication between two internal nodes that
happen to be using global-scope addresses (for whatever reason),
the SBR MUST support the "hair pinning" behaviour commonly used
in existing NAT/NAPT devices. (This behaviour is described in
Section 6 of RFC4787 [RFC4787].)
In the near-term, a more common deployment scenario will be to
deploy ILNP incrementally, with some ordinary classic IP traffic
still existing. In this case, the SBR should maintain flow state
that contains a flag for each flow indicating whether that flow
is using ILNP or not. If that flag indicated ILNP were enabled
for a given flow, and ILNP local numbering were also enabled,
then the SBR would know that it should perform the simpler ILNP
Locator re-writing mapping. If that flag indicated ILNP were not
enabled for a given flow and IP NAT or IP NAPT were also enabled,
then the SBR would know that it should perform the more complex
NAT/NAPT translation (e.g. including TCP or UDP checksum
recalculation).
NOTE: Existing commercial security-aware routers
(e.g. Juniper SRX routers) already can maintain flow state
for millions of concurrent IP flows. This feature would add
one flag to each flow's state, so this approach is believed
scalable today using existing commercial technology.
Those applications that do not use IP address values in
application state or configuration data are considered to be
"well-behaved". For well-behaved applications, no further
enhancements are required. Where application-layer protocols are
not well-behaved, for example the File Transfer Protocol (FTP),
then the SBR might need to perform additional stateful processing
-- just as NAT and NAPT equipment needs to do today for FTP. See
the description in Section 7.6 of [ILNP-ENG].
When the SBR rewrites a Locator in an ILNP packet, that obscures
information about how well a particular path is working between
the sender and the receiver of that ILNP packet. So, the SBR that
rewrites Locator values needs to include mechanisms to ensure
that any packet with a new Destination Locator will travel along
a valid path to the intended destination node. For ILNPv4, the
path liveness will be no worse than IPv4, and mechanisms already
in use for IPv4 can be re-used. For ILNPv6, the path liveness
will be no worse than for IPv6, and mechanisms already in use for
Atkinson & Bhatti Expires in 6 months [Page 13]
Internet Draft ILNP ADV 10 JUL 2012
IPv6 can be re-used.
In the future, the Border Router Discovery Protocol (BRDP) also
might be used in some deployments to indicate which routing
prefixes are currently valid and which site border routers
currently have a working uplink [ID-BRDP11].
3. AN ALTERNATIVE FOR SITE MULTI-HOMING
The ILNP Architectural Description [ILNP-ARCH] describes the
basic approach to enabling site multi-homing (S-MH) with ILNP.
However, as an option, it is possible to leave the control of
S-MH to an ILNP-enabled SBR. This alternative is based on the use
of the Localised Numbering function described in Section 2 of
this document.
3.1 Site multi-homing (S-MH) connectivity using an SBR
The approach to Site Multi-Homing (S-MH) using an SBR is best
illustrated through an example, as shown in Figure 3.1.
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | sbr1+------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
CN = Correspondent Node
H = Host
L_1 = global Locator value 1
L_2 = global Locator value 2
L_L = local Locator value
SBR = Site Border Router
sbrN = interface N on SBR
Figure 3.1: Alternative site multi-homing example with an SBR.
The situation here is similar to the localised numbering example,
except that the SBR now has two external links, with using
locator value L_1 and another using Locator value L_2. These
could, e.g. for ILNPv6, be separate, provider aggregated (PA)
Atkinson & Bhatti Expires in 6 months [Page 14]
Internet Draft ILNP ADV 10 JUL 2012
IPv6 prefixes from two different ISPs. H has IL-V [I_H, L_L], and
will forward a packet to CN as given in expression (1a). However,
when the packet reaches the SBR, local policy will decide whether
the packet is forwarded on the link sbr1 using L_1 or on sbr2
using L_2. Of course, the correct Locator value will be re-
written into the egress packet in place of L_L.
If only local numbering is being used, then the SBR need never
advertise any global Locator values. However, it could do, as
described in Section 2.2.
3.2 Dealing with link/connectivity changes
One of the key uses for multi-homing is providing resilience to
link failure. If either link breaks, then the SBR can manage the
change in connectivity locally. For example, assume SBR has been
configured to use sbr1 for all traffic, and sbr2 only as backup
link. So, SBR directs packets from H to communicate with CN using
sbr1, and CN will receive packets as in expression (1b) and
respond with packets as in expression (2a).
However, if sbr1 goes down then SBR will move the communication
to interface sbr2. As H is not aware of the actions of the SBR,
the SBR must maintain some state about IL-V "pairs" in order
hand-off the connectivity from sbr1 to sbr2. So, when moving the
the communication to sbr2, the SBR would firstly send a Locator
Update (LU) message [ILNP-ICMPv4] [ILNP-ICMPv6], to CN informing
it that L_2 is now the valid Locator for the communication. This
operation would not be visible to H, although there might be some
disruption to transmission, e.g. packets being sent from CN to H
that are in flight when sbr1 goes down may be lost. The SBR might
also need to update DNS entries (see Section 3.3). Since ILNP
requires that all Locator Update messages be authenticated by the
ILNP Nonce, the SBR will need to include the appropriate Nonce
values as part of its cache of information about ILNP sessions
traversing the SBR. (NOTE: Since commercial security gateways
available as of this writing reportedly can handle full stateful
packet inspection for millions of flows at multi-gigabit speeds,
it should be practical for such devices to cache the ILNP flow
information, including Nonce values.)
This approach has some efficiency gains over the approach for
multi-homing described in [ILNP-ARCH], where each hosts manages
its own connectivity.
If sbr1 was to be re-instated, now with Locator value L_3, then
local policy would determine if the communication should be moved
back to sbr1, with appropriate additional actions, such as
Atkinson & Bhatti Expires in 6 months [Page 15]
Internet Draft ILNP ADV 10 JUL 2012
transmission of LU messages with the new Locator values and also
the updates to DNS.
Note that in such movement of an ILNP session across interfaces
at the SBR, only Locator values in ILNP packets are changed. As
already noted in [ILNP-ARCH], end-to-end transport-layer session
state invariance is maintained.
3.3 SBR updates to DNS
When the SBR manages connectivity as described above, the internal
hosts, such as H, are not necessarily aware of any connectivity
changes. Indeed, there is certainly no requirement for them to be
aware. So, if H was a server expecting incoming connections, the
SBR must update the relevant DNS entries when the site
connectivity changes.
There are two possibilities: each host could have its own L32
or L64 records; or the site might use a combination of LP and
L32/L64 records (see Section 2.4). Either way, the SBR would need
to update the relevant DNS entries. For our example, with ILNPv6
and LP records in use, the SBR would need to manage two L64
records (one for each uplink) which would resolve from
a FQDN, for example, site.example.com. Meanwhile, individual
hosts, such as H, have an FQDN which resolves to an NID value and
an LP record that would contain the value site.example.com, which
then would be used to lookup the two L64 records.
If the SBR is multi-homed, as in Fig 3.1, then it will have (at
least) two Locator values, one for each link, and local policy
will need to be used to determine how preference values are
applied in the relevant L32 and L64 records.
3.4 DNS TTL values for L32 and L64 records
Imagine that in the scenario described above, there was a link
failure that resulted in sbr1 going down and sbr2 was used.
Existing ILNP sessions in progress would move to sbr2 as
described above. However, new incoming ILNP sessions to the site
would need to know to use L_2 and not L_1. L_1 and L_2 would be
stored in DNS records (e.g. L32 for ILNPv4 or L64 for ILNPv6).
If a remote host has already resolved from DNS that L_1 is the
correct Locator for sending packets to the site, then that host
might be holding stale information.
DNS allows values returned to be aged using Time-To-Live (TTL)
which is specified in the time unit of seconds. So that remote
Atkinson & Bhatti Expires in 6 months [Page 16]
Internet Draft ILNP ADV 10 JUL 2012
nodes do not hold on to stale values from DNS, the L64 records for
our site should have low TTL values. An appropriate value must be
considered carefully. For example, let us assume that the site
administrator knows that when sbr1 fails, it takes 20 seconds to
failover to sbr2. Then, 20s would seem to be an appropriate time
to use for the TTL value of an L64 for the site: if a remote node
had just resolved the value L_1 for the site, and the link to sbr1
went down, that remote node would not hold the stale value of L_1
for any longer than it takes the site to failover to sbr2 and use
L_2.
Our studies for a university School site network show that low TTL
values, as low as zero, are feasible for operational use [BA11].
NOTE: From 01 Nov 2010, the site network of the School of Computer
Science, University of St Andrews, UK, has been running
operational DNS with DNS A records that have TTL of zero.
At the time of writing of this note (05 Jan 2011),
a zero DNS TTL was still in use at the school.
3.5 Multiple SBRs
For site multi-homing, with multiple SBRs, a situation may be as
follows (see also Sec 5.3.1 in [ILNP-ARCH]).
site . . . .
network . .
. . . . +-------+ L_1 . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. . | | . .
. . +-------+ . .
. . ^ . .
. . | CP . Internet .
. . v . .
. . +-------+ L_2 . .
. . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
. .
. . . .
Atkinson & Bhatti Expires in 6 months [Page 17]
Internet Draft ILNP ADV 10 JUL 2012
CP = coordination protocol
L_1 = global Locator value 1
L_2 = global Locator value 2
SBR_A = Site Border Router A
SBR_B = Site Border Router P
Figure 3.2: A dual-router multi-homing scenario for ILNP.
The use of two physical routers provides an extra level of
resilience compared to the scenario of Fig 3.1. The coordination
protocol (CP) between the two routers keeps their actions in
synchronisation according to whatever management policy is in
place for the site network. Such functions are available today in
some commercial network security products. Note that, logically,
there is little difference between Fig 5.1 and Fig 3.2, but with
two distinct routers in Fig 3.2, the interaction using CP is
required. Of course, it is also possible to have multiple
interfaces in each router and more than two routers.
4. AN ALTERNATIVE FOR SITE (NETWORK) MOBILITY
The ILNP Architectural Description [ILNP-ARCH] describes the basic
approach to enabling site (network) mobility with ILNP. However,
as an option, it is possible to leave the control of site mobility
to an ILNP-enabled SBR by exploiting the alternative site
multi-homing feature described in Section 3 of this document.
Again, as described in [ILNP-ARCH], we exploit the duality between
mobility and multi-homing for ILNP.
4.1 Site (network) mobility
Let us consider the mobile network in Figure 4.2, which is taken
from [ILNP-ARCH].
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 4.1a: ILNP mobile network before handover.
site ISP_1
Atkinson & Bhatti Expires in 6 months [Page 18]
Internet Draft ILNP ADV 10 JUL 2012
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 4.1b: ILNP mobile network during handover.
site ISP_2
network SBR . . .
. . . . +------+ . .
. . L_L | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . .
. . .
Figure 4.1c: ILNP mobile network after handover.
H = host
L_1 = global Locator value 1
L_2 = global Locator value 2
L_L = local Locator value
raN = radio interface N
SBR = Site Border Router
Figure 4.1: An alternative mobile network scenario with an SBR.
We assume that the site (network) is mobile, and the SBR has two
radio interfaces ra1 and ra2. In the figure, ISP_1 and ISP_2 are
separate, radio-based service providers, accessible via interfaces
ra1 and ra2.
While the SBR makes the transition from using a single link (Fig.
4.1a) to the hand-over overlap on both links (Fig 4.1b), to only
using a single link again (Fig 4.1c), the host H continues to use
only Locator value L_L, as already described for site multi-homing
(S-MH). During this time the actions taken by the SBR are the same
as already described in [ILNP-ARCH], except that the SBR:
a) also performs that ILNP localised numbering function
described in Section 2.
b) does not need to advertise L_1 and L_2 internally if only
local numbering is being used.
Atkinson & Bhatti Expires in 6 months [Page 19]
Internet Draft ILNP ADV 10 JUL 2012
As for the case of S-MH above, H need not be aware of the change
in connectivity for the SBR if it is only using local numbering,
and the SBR would send LU messages for H (for any correspondent
nodes, not shown in Fig 4.1), and would update DNS entries as
required.
The difference to the S-MH scenario described earlier in this
document is that in the situation of Fig 4.1b, the SBR can opt to
use soft handover has previously described in [ILNP-ARCH].
Again, there is an efficiency gain compared to the situation
described in [ILNP-ARCH]: the SBR provides a convenient point at
which to centrally manage the movement of the site as a whole.
Note that in Fig 4.1b, the site is multi-homed.
As for S-MH, L_1 and L_2 could be advertised internally, as a
local policy decision, for those hosts that require direct control
of their connectivity.
Note that for handover, immediate handover will have a similar
behaviour to a link outage as described for S-MH. However, as ILNP
allows soft-handover, during the handover period, this should help
to reduce (perhaps even remove) packet loss.
4.3 SBR updates to DNS
As for S-MH, a similar discussion to Section 3.3 applies for
mobile networks with respect to the updates to DNS. As a mobile
network is likely to have more frequent changes to its
connectivity than a multi-homed network would due to connectivity
changes, the use of LP DNS records is likely to be particularly
advantageous here.
4.4 DNS TTL values for L32 and L64 records
As for S-MH, a similar discussion to Section 3.4 applies for
mobile networks with respect to the TTL of L32 and/or L64 records
that are used for the name of the mobile network. In the case of
the mobile network, it makes sense for the TTL to be aligned to
the time for handover.
5. TRAFFIC ENGINEERING OPTIONS
The use of Locator re-writing provides some simple yet useful
options for traffic engineering (TE) controlled from the edge-site
via the SBR, requiring no cooperation from the service provider
Atkinson & Bhatti Expires in 6 months [Page 20]
Internet Draft ILNP ADV 10 JUL 2012
other than the provision of basic connectivity services, e.g.
physical connectivity, allocation of IP address prefixes and
packet forwarding. This does not preclude other TE options that
are already in use, such as use of MPLS, but we choose to
highlight here the specific options available and controllable
solely through the use of ILNP.
When a site network is multi-homed, we have seen that the use of
the Locator re-writing function permits the SBR to have
packet-by-packet control when forwarding on external links.
Various configuration and policies could be applied at the SBR in
order to control the egress and ingress traffic to the site
network.
5.1 Load balancing
Let us consider Figure 5.1, and assume ILNP local numbering is in
use; that H1, H2 and H3 use, respectively, Identifier values, I_1,
I_2 and I_3; and all of them use Locator value L_L.
site . . . .
network SBR . .
. . . . +------+ L_1 . .
. . | sbr1+------. .
. H2 .L_L | | . .
. H3 .----+ | . Internet .
. . | | . .
. H1 . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
HN = host N
L_1 = global Locator value 1
L_2 = global Locator value 2
L_L = local Locator value
SBR = Site Border Router
sbrN = interface N on sbr
Figure 5.1: A site multi-homing scenario for traffic control.
The SBR could be configured, subject to local policy, to try to
control load across the external links. For example, it could be
configured initially with the following mappings:
srcI=I_1, sbr1 --- (3a)
srcI=I_2, sbr2 --- (3b)
Atkinson & Bhatti Expires in 6 months [Page 21]
Internet Draft ILNP ADV 10 JUL 2012
srcI=I_3, sbr1 --- (3c)
These mappings direct packets matching course Identifier values
to particular outgoing interfaces. As load changes, these
mappings could be changed. For example, expression (3c) could be
changed to:
srcI=I_3, sbr2 --- (4)
and the SBR would need to send LU message to the correspondents of
H3 (sbr to uses L_2 while sbr1 uses L_1). The egress connectivity
is totally within control of the SBR under administrative policy,
as already seen in the descriptions of multi-homing and mobility
in this document.
Of course, more complex policies are possible, based on:
- whether ILNP sessions are incoming or outgoing
- time of day
- internal subnets
and any number of criteria already in use for control of traffic.
In expressions (3a,b,c) above, source I values are used. However:
- destination I values could be used
- source or destination L values could be used
- mappings could be to L values, not to specific interfaces
and, again, any number of criteria could be used to manipulate
the packet path, based on filtering of values in header fields
and local policy.
With ILNP, hosts do not need to be aware of the operation of the
SBR in this manner.
Note, again, that in this scenario, there is nothing to prevent
SBR from also advertising L_1 and L_2 into the site network. If
required, administrative controls could be used to enable
selective hosts in the site network to use L_1 and L_2 directly as
described in [ILNP-ARCH].
5.2 Control of egress traffic paths
Extending the scenario for load-balancing described above, it is
also be possible for the ILNP-capable SBR to direct traffic along
specific network paths based on the use of different L values,
i.e. by using multiple prefixes assigned from upstream providers.
Atkinson & Bhatti Expires in 6 months [Page 22]
Internet Draft ILNP ADV 10 JUL 2012
Of course, as previously discussed, these prefixes can be Provider
Aggregated (PA) and need not be Provider Independent (PI).
Let us consider Figure 5.2, and assume ILNP local numbering is in
use; that H1, H2 and H3 use, respectively, Identifier values, I_1,
I_2 and I_3; and all of them use Locator value L_L. Let us also
assume that the node CN uses IL-V [I_CN, L_CN].
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L1,L2 . . +----+
. . | sbr1+--------. .
. H2 .L_L | | . .
. H3 .----+ sbr2+--------. Internet .
. . | | L3,L4 . .
. . | | . .
. H1 . | sbr3+--------. .
. . . . +------+ L5,L6 . .
. .
. . . .
CN = correspondent node
HN = host N
LN = global Locator value N
L_L = local Locator value
SBR = Site Border Router
sbrN = interface N on sbr
Figure 5.2: A site multi-homing scenario for traffic control.
Here, many configurations are possible. For example, for egress
traffic:
srcI=I_2, L2 --- (5a)
srcI=I_3, L3 --- (5b)
dstI=I_CN, L6 --- (5c)
srcI=I_1 dstI=I_CN, L1 --- (5d)
Expression (5a) maps all egress packets from H2 to have their
source Locator value re-written to L2 (and implicitly to use
interface sbr1). Expression (5b) maps all egress packets from H3
to have their source Locator value re-written to L3 (and
implicitly to use interface sbr2). Expression (5c) directs ay
traffic to CN to use Locator value L6 as the source Locator (and
implicitly to use interface sbr3), and may override (5a) and (5b),
subject to local policy, when packets to CN are from H2 or H3.
Meanwhile, in expression (5d), we see a further, more specific
Atkinson & Bhatti Expires in 6 months [Page 23]
Internet Draft ILNP ADV 10 JUL 2012
rule, in that packets from H1 destined to CN should use Locator
value L1 (and implicitly to use interface sbr1).
Note the implicit bindings to interfaces in expressions
(5a,b,c,d), compared to the explicit bindings in expressions
(3a,b,c). ILNP only requires that the Locator values are correctly
re-written and packets forwarded in conformance with the routing
already configured for the Locator values.
Of course, these rules can be changed dynamically at the SBR, and
the SBR will migrate ILNP sessions across Locator values, as
already described above for mobility.
6. ILNP IN DATACENTRES
As ILNP has first class support for mobility and multi-homing,
and supports flexible options for localised addressing, there is
great potential for it to be used in datacentre scenarios. Further
details of possibilities are in [BA12], with a summary presented
here.
There are several scenarios that could be beneficial to
datacentres, in order to provide functions such as load
balancing, resilience and fault tolerance, and resource
management:
- Same datacentre, internal VM mobility: This could be beneficial
in load balancing, dynamically, where load changes are taking
place. The remote user does not see the VM has moved.
- Different datacentres, transparent mobility: This is where the
datacentre resources may be geographically distributed, but
the geographical movement is transparent to the remote user.
- Different datacentres, mobility is visible: This is where the
datacentre resources may be geographically distributed, but
the geographical movement is visible to the remote user.
These are three situations which may be supported by ILNP, but
they are not the only ones: we provide these here as examples,
and they are not intended to be prescriptive. The intention is
only to show the flexibility that is possible through the use of
ILNP.
This section describes some Virtual Machine (VM) mobility
capabilities that are possible with ILNP. Depending on the
internal details and virtualisation model provided by a VM
Atkinson & Bhatti Expires in 6 months [Page 24]
Internet Draft ILNP ADV 10 JUL 2012
platform, it might be sufficient for the guest operating system
to support ILNP. In a some cases, again depending on the internal
details and virtualisation model provided by a VM platform, the
VM platform itself also might need to include support for ILNP.
Details of how a particular VM platform works, and which
virtualisation model(s) a VM platform supports, are beyond the
scope of this document. Internal implementation details of VM
platform support for ILNP are also beyond the scope of this
document, just as internal implementation details for any other
networked system supporting ILNP are beyond the scope of this
document.
6.1 Virtual image mobility within a single datacentre
Let us consider first the scenario of Figure 6.1, noting its
similarity to Figure 2.1 for use of localised numbering.
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. H2 .L_L | | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node
V = Virtual machine image
Hx = Host x
L_1 = global Locator value
L_L = local Locator value
SBR = Site Border Router
Figure 6.1: A simple virtual image mobility example for ILNP.
L_L is a Locator value used for the ILNP hosts H1 an H2. Here,
the "V*H1" signifies that the virtual machine image V is
currently resident on H1. Let us assume that V has Identifier
I_V. Note that as H1 and H2 have the same Locator value (L_1), as
far as CN is concerned, it does not matter if V is resident on H1
or H2, all transport packets between V and CN will have the same
signature as far as CN is concerned, e.g. for a UDP flow (in
analogy to (1a)):
Atkinson & Bhatti Expires in 6 months [Page 25]
Internet Draft ILNP ADV 10 JUL 2012
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_1, L_CN> --- (6a)
Now, if V was to migrate to H2, the migration would be an issue
purely local to the site-network, and the end-to-end integrity of
the transport flow would be maintained.
Of course, there are practical operating systems issues in
enabling such a migration locally, but products exist today that
could be modified and made ILNP-aware in order to enable such VM
image mobility.
Note that for convenience, above, we have used localised
numbering for ILNP, but if local Locator values were not used and
the whole site simply used L_1, the principle would be the same.
6.2 Virtual image mobility between data centres - invisible
Let us now consider an extended version of the scenario above in
Fig. 6.2, where we see that there is a second site network, which
is geographically distant to the first site network, and the two
site networks are interconnected via their respective SBRs.
site . . . . +----+
network 1 SBR1 . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L1| | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +---+--+ . .
: . .
: . .
. . . . +---+--+ L_2 . .
. . | +------. .
. H2 .L_L2| | . .
. .----+ | . .
. . | | . .
. . | | . .
. . . . +------+ . .
site SBR2 . .
network 2 . . . .
: = logical inter-router link and coordination
CN = Correspondent Node
V = Virtual machine image
Hx = Host x
Atkinson & Bhatti Expires in 6 months [Page 26]
Internet Draft ILNP ADV 10 JUL 2012
L_y = global Locator value y
L_Lz = local Locator value z
SBR = Site Border Router
Figure 6.2: A simple localised numbering example for ILNP.
Note that the logical inter-router link between SBR1 and SBR2
could be realised physically in many different ways that are
available today and are not ILNP specific, e.g. leased line,
secure IP-layer or layer-2 tunnel, etc. We assume that this link
also allows coordination between the two SBRs. For now, we ignore
external link L_2 on SBR2, and assume that the remote node, CN,
is in communication with V through SBR1.
When in initial communication, the packets have the signature is
given in expression (6a). When V moves to H2, it now uses Locator
value L_L2, but all communication between V and CN is still
routed via SBR1. So, the remote CN still sees that same packet
signature as given in expression (6a). L_L1 and L_L2 are,
effectively, two internal (private) subnetworks, and are not
visible to CN.
However, SBR2 and SBR1 must coordinate so that any further
communication to V via SBR1 is routed across the inter-router
link. Again, there are commercial products today that could be
adapted to manage such shared state.
6.3 Virtual image mobility between data centres - visible
Clearly, in the scenario of the section above, once V has moved
to site network 2, it may be beneficial, for a number of reasons,
for communication to V to be routed via SBR2 rather than SBR1.
When V moves from site network 1 to site network 2, this
visibility of mobility could be by V sending ILNP Locator Update
messages to the CN during the mobility process. Also, V would
update any relevant ILNP DNS records, such as L64 records, for
new ILNP session requests to be routed via SBR2.
Indeed, let us now consider again Fig 6.2, and assume now that
Local locators L_L1 and L_L2 are not in use on either site
network, and each site networks uses its own global Locator
value, L_1 and L_2, respectively, internally. In that case, the
packet flow signature for V when it is in site network 1 as
viewed from CN is, again as given in expression (6a). However,
when V moves to site network 2, it would simply use L_2 as its
new Locator, send Locator Update messages to CN as would a normal
mobile node for ILNP, and complete its migration to H2. Then, CN
Atkinson & Bhatti Expires in 6 months [Page 27]
Internet Draft ILNP ADV 10 JUL 2012
would see the packet signatures as in expression (6b).
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_2, L_CN> --- (6b)
In this case, no "special" inter-router link is required for
mobility - the normal Internet connectivity between SBR1 and SBR2
would suffice. However, it is quite likely that some sort of
tunnelled link would still be desirable to offer protection of
the VM image as it migrates.
6.4 ILNP capability in the remote host for VM image mobility
For the remote host - the correspondent node (CN) - the
availability of ILNP would be beneficial. However, for the first
two scenarios listed above, as the packet signature of the
transport flows remains fixed from the viewpoint of the CN, it
seems possible that the benefits of ILNP VM mobility could be
used for datacentres even while CNs remain as normal IP hosts.
Of course, a major caveat here is that the application level
protocols should be "well-behaved": that is, the application
protocol or configuration should not rely on the use of IP
addresses.
7. LOCATION PRIVACY
Extending the Locator re-writing paradigm, it is possible to also
enable Location privacy for ILNP by a modified version of the
"onion routing" paradigm that is used for Tor [DMS04] [RSG98].
7.1 Locator Re-writing Relay (LRR)
To enable this function, we use a middlebox which we call the the
Locator Re-writing Relay. The function of this unit is described
by the use of Figure 7.1.
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (7a)
v
|
+--+--+
| | src=[I_H, L_1], L_X --- (7b)
| LRR | dst=[I_H, L_X], L_1 --- (7c)
| |
+--+--+
|
v
Atkinson & Bhatti Expires in 6 months [Page 28]
Internet Draft ILNP ADV 10 JUL 2012
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN> --- (7d)
LRR = Locator Re-writing Relay
Figure 7.1: Locator Re-Writing Relay (LRR) example
The operation of the LRR is conceptually very simple. We assume
that the LRR first has mappings as given in expressions (7b) and
(7c) (see next sub-section). Expression (7b) says that for
packets with src IL-V [I_H, L_1], the packet's source Locator
value should be re-written to value L_X and then forwarded.
Expression (7c) has the complimentary mapping for packets with
destination IL-V [I_H, L_1] (for the reverse direction).
Expression (6a) is a UDP/ILNP packet as might be sent in Figure
2.1 from H to CN. However, instead of going directly to L_CN, the
packet with destination Locator L_1 goes to a LRR. Expression
(7d) is the result of the mapping of packet (7a) using expression
(7b).
Note that it is entirely possible that the packet of expression
(7d) then is processed by another LRR for source Locator value
L_X. Effectively, this creates and LRR path for the packet, as an
overlay path on top of the normal IP routing.
In this way, there is a level of protection, without the need for
cryptographic techniques, for the (topological) Location of the
packet. Of course, an extremely well-resourced adversary could,
potentially, backtrack the LRR path, but, depending on the LRR
overlay path that is created, could be very difficult to trace in
reality. For example, the mechanism will protect against off-path
attacks, but where the threat regime includes the potential for
on-path attacks, cryptographically protected tunnels between H
and LRR might be required.
Again, as the Locator value is not part of the end-to-end state,
this mechanism is very general and has a low overhead.
7.2 Options for installing LRR packet forwarding state
There are many options for managing the "network" of LRRs that
could be in place if such a system was used on a large scale,
including the setting up and removal of LRR state for packet
relaying, as for expressions (7b) and (7c). We consider this
function to be outside the scope of these ILNP specifications,
but note that there are many existing mechanisms that could
modified for use, and also many possibilities for new mechanisms
that would be specific to the use of ILNP LRRs.
Atkinson & Bhatti Expires in 6 months [Page 29]
Internet Draft ILNP ADV 10 JUL 2012
(Note also that the control/management communication with the LRR
does not need to use ILNP: IPv4 or IPv6 could be used.)
The host, H, by itself could install the required state, assuming
it was aware of suitable information to contact the LRR. The
first packet in an ILNP session might contain a header option
called a Locator Redirection Option (LRO). The LRO would contain
the Locator value that should be re-written into the source
Locator of the packet. When a LRR receives such a packet, it
would install the required state. Such a mechanism could be soft-
state, requiring periodic use of the LRO in order to maintain the
state in the LRR. The LRO could also be delivered using an ICMP
ECHO packet sent from H to the LRR, periodically, again to
maintain a soft-state update.
It would, of course, be prudent to protect the LRR state control
packets with some sort of authentication token, to prevent an
adversary from easily installing false LRR state and causing packets
from H or its correspondent to be subject to man-in-the-middle
attacks, or black-holing. Again, such attacks are not specific
to ILNP or new to ILNP.
It would also be possible to use proprietary application level
protocols, with strong authentication for the control of the LRR
state. For example, an application level protocol based on XMPP
(http://xmpp.org/) operating over SSL.
Above, we have offered very brief and incomplete descriptions of
some possibilities, and we do not necessarily mandate any one of
them: they serve only as examples.
8. IDENTITY PRIVACY
For the sake of completeness, and in complement to Section 6, it
should be noted that ILNP can use either cryptographically
verifiable Identifier values, or use Identifier values that
provide a level of anonymity to protect a user's privacy. More
details are given in Section 2 and 11 of [ILNP-ENG].
9. SECURITY CONSIDERATIONS
The relevant security considerations to this document are
the same as for the main ILNP Architectural Description
[ILNP-ARCH]. The one additional point to note is that this
document describes ILNP capability in the SBR and so those
adversaries wishing to subvert the operation of ILNP
Atkinson & Bhatti Expires in 6 months [Page 30]
Internet Draft ILNP ADV 10 JUL 2012
specifically, have a target that would, potentially, disable
an entire site. However, this is not an attack vector that is
specific to ILNP: today, disruption of an IPv4 or IPv6 SBR
would have the same impact.
The security considerations for Section 7 (Location Privacy) are
already documented in [DMS04] and [RSG98]. One possibility is
that the LRR mechanism itself could be used by an adversary to
launch an attack and hide his own (topological) Location, for
example. This is already possible for IPv4 and IPv4 with a
Tor-like system today, so is not new to ILNP.
10. IANA Considerations
There are no IANA considerations for this document.
(Note to RFC Editor: please remove this section
prior to publication.)
11. REFERENCES
11.1. Normative References
[RFC1918] Y. Rekther, B. Moskowitz, D. Karrenberg & G. J.
de Groot,
"Address Allocation for Private Internets",
RFC1918, Feb 1996
[RFC2119] S. Bradner, "Key Words for Use in RFCs to
Indicate Requirement Levels", RFC2119,
March 1997.
[RFC3022] P. Srisuresh & K. Egevang,
"Traditional IP Network Address Translator
(Traditional NAT)",
RFC3022, Jan 2011.
[RFC3484] R. Draves, "Default Address Selection for IPv6",
RFC3484, Feb 2003.
[RFC4193] R. Hinden and B. Haberman, "Unique Local IPv6
Unicast Addresses", RFC4193, October 2005.
[RFC4632] V. Fuller and T. Li, "Classless Inter-domain
Routing (CIDR): The Internet Address Assignment and
Aggregation Plan", RFC4632, August 2006.
[RFC4787] F. Audet & C. Jennings, "NAT Behavioural
Atkinson & Bhatti Expires in 6 months [Page 31]
Internet Draft ILNP ADV 10 JUL 2012
Requirements for Unicast UDP", RFC4787,
January 2007.
[RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter &
E. Klein,
"Local Network Protection for IPv6",
RFC4864, May 2007
[RFC4924] B. Adoba & E. Davbies (eds),
"Reflections on Internet Transparency",
RFC4924, Jul 2007
[RFC5902] D. Thaler, L. Zhang & G. Lebovitz,
"IAB Thoughts on IPv6 Network Address Translation",
RFC5902, Jul 2010
[RFC6177] T. Narten, G. Huston, L. Roberts, "IPv6 Address
Assignment to End Sites", RFC6177 (BCP157), March
2011.
[ILNP-ARCH] R.J. Atkinson & S.N. Bhatti,
"ILNP Architectural Description",
draft-irtf-rrg-ilnp-arch, 10 July 2012.
[ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for
ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012.
[ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose,
"DNS Resource Records for ILNP",
draft-irtf-rrg-ilnp-dns, 10 July 2012.
[ILNP-ENG] R.J. Atkinson & S.N. Bhatti,
"ILNP Engineering and Implementation Considerations",
draft-irtf-rrg-ilnp-eng, 10 July 2012.
[ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti,
"ICMPv4 Locator Update message"
draft-irtf-rrg-ilnp-icmpv4, 10 July 2012.
[ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti,
"ICMPv6 Locator Update message"
draft-irtf-rrg-ilnp-icmpv6, 10 July 2012.
[ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti,
"IPv6 Nonce Destination Option for ILNPv6",
draft-irtf-rrg-ilnp-noncev6, 10 July 2012.
[ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti,
Atkinson & Bhatti Expires in 6 months [Page 32]
Internet Draft ILNP ADV 10 JUL 2012
"IPv4 Options for ILNP",
draft-irtf-rrg-ilnp-v4opts, 10 July 2012.
11.2. Informative References
[ABH07a] R. Atkinson, S. Bhatti, & S. Hailes,
"Mobility as an Integrated Service Through the Use of
Naming", Proceedings of ACM Workshop on Mobility
in the Evolving Internet Architecture (MobiArch),
ACM SIGCOMM, Kyoto, Japan. 27 Aug 2007.
[ABH07b] R. Atkinson, S. Bhatti, & S. Hailes,
"A Proposal for Unifying Mobility with Multi-Homing,
NAT, & Security", Proceedings of 2nd ACM Workshop on
Mobility Management and Wireless Access (MobiWAC),
ACM, Chania, Crete. Oct 2007.
ISBN: 978-1-59593-809-1
[ABH08a] R. Atkinson, S. Bhatti, & S. Hailes,
"Mobility Through Naming: Impact on DNS", Proceedings
of 3rd ACM Workshop on Mobility in the Evolving
Internet Architecture (MobiArch), ACM SIGCOMM,
Seattle, WA, USA. Aug 2008.
[ABH08b] R. Atkinson, S. Bhatti, & S. Hailes,
"Harmonised Resilience, Security, and Mobility
Capability for IP", Proceedings of the IEEE
Military Communications Conference (MILCOM),
IEEE, San Diego, CA, USA. Nov 2008.
[ABH09a] R. Atkinson, S. Bhatti, & S. Hailes,
"Site-Controlled Secure Multi-Homing and Traffic
Engineering For IP", Proceedings of IEEE
Military Communications Conference (MILCOM), IEEE,
Boston, MA, USA. Oct 2009.
[ABH09b] R. Atkinson, S. Bhatti, S. Hailes,
"ILNP: Mobility, Multi-Homing, Localised Addressing and
Security Through Naming"", Telecommunication Systems,
vol. 42, no. 3-4, pp273-291, Springer-Verlag, Dec 2009.
[ABH10] R. Atkinson, S. Bhatti, S. Hailes,
"Evolving the Internet Architecture Through Naming",
IEEE Journal on Selected Areas in Communication
(JSAC), vol. 28, no. 8, pp1319-1325, IEEE, Oct 2010.
[BA11] S. Bhatti & R. Atkinson,
"Reducing DNS Caching", Proceedings of IEEE
Atkinson & Bhatti Expires in 6 months [Page 33]
Internet Draft ILNP ADV 10 JUL 2012
Global Internet Symposium (GI2011), Shanghai,
P.R. China. 15 Apr 2011.
[BA12] S. N. Bhatti & R. Atkinson,
"Secure & Agile Wide-area Virtual Machine Mobility",
Proceedings of IEEE Military Communications
Conference (MILCOM), Orlando, FL, USA. Oct 2012.
[BAK11] S. N. Bhatti, R. Atkinson, J. Klemets,
"Integrating Challenged Networks", Proceedings of
IEEE Military Communications Conference (MILCOM),
IEEE, Baltimore, MD, USA. Nov 2011.
[DMS04] R. Dingledine, N. Mathewson, & P. Syverson,
"Tor: the second-generation onion router",
Proceedings of 13th USENIX Security Symposium, USENIX
Association, San Diego, CA, USA. 2004.
[ID-appDNS] O. Kolman, J. Peterson, H. Tschofenig & B. Aboba,
"Architectural Considerations on Application Features
in the DNS", draft-iab-dns-applications, March 2012.
[ID-BRDP11] T. Boot & A. Holtzer, "Border Router Discovery
Protocol (BRDP) Framework",
draft-boot-brdp-framework-00, Internet-Draft,
31 Jan 2011.
[ID-mDNS11] S. Cheshire, M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-15, 09 Dec 2011.
[IEEE04] "IEEE 802.1D - IEEE Standard for Local and Metropolitan
Area Networks, Media Access Control (MAC) Bridges",
IEEE Standards Association, New York, NY, USA, 9 June
2004.
Print: ISBN 0-7381-3881-5 SH95213
PDF: ISBN 0-7381-3982-3 SS95213
[LABH06] R. Atkinson, M. Lad, S. Bhatti, and S. Hailes,
"A Proposal for Coalition Networking in Dynamic
Operational Environments", Proceedings of IEEE
Military Communications Conference (MILCOM),
IEEE, Washington, DC, USA. Nov 2006.
[RAB09] D. Rehunthan, R. Atkinson, S. Bhatti,
"Enabling Mobile Networks Through Secure Naming",
Proceedings of IEEE Military Communications
Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009
Atkinson & Bhatti Expires in 6 months [Page 34]
Internet Draft ILNP ADV 10 JUL 2012
[RB10] D. Rehunathan, S. Bhatti,
"A Comparative Assessment of Routing for Mobile
Networks", Procedings of 6th IEEE International
Conference on Wireless and Mobile Computing
Networking and Communications (WiMob), IEEE, Niagara
Falls, ON, Canada. Oct 2010.
[RSG98] Michael G. Reed, Paul F. Syverson, and David
M. Goldschlag, "Anonymous Connections and
Onion Routing", IEEE Journal on Selected Areas
in Communications, Vol. 16, No. 4, IEEE,
Piscataway, NJ, USA, May 1998.
[RFC4193] R. Hinden and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC4193, October 2005.
[RFC6296] W. Wasserman, F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC6296, June 2011.
ACKNOWLEDGEMENTS
Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel
Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley,
Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter,
Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical
order) provided review and feedback on earlier versions of this
document. Steve Blake provided an especially thorough review of
an early version of the entire ILNP document set, which was
extremely helpful. We also wish to thank the anonymous reviewers
of the various ILNP papers for their feedback.
Roy Arends provided expert guidance on technical and procedural
aspects of DNS issues.
RFC EDITOR NOTE
This section is to be removed prior to publication.
Please note that this document is written in British English, so
British English spelling is used throughout. This is consistent
with existing practice in several other RFCs, for example
RFC-5887.
This document tries to be very careful with history, in the
interest of correctly crediting ideas to their earliest
identifiable author(s). So in several places the first published
RFC about a topic is cited rather than the most recent published
RFC about that topic.
Atkinson & Bhatti Expires in 6 months [Page 35]
Internet Draft ILNP ADV 10 JUL 2012
Author's Address
RJ Atkinson
Consultant
San Jose, CA
95125 USA
Email: rja.lists@gmail.com
SN Bhatti
School of Computer Science
University of St Andrews
North Haugh, St Andrews
Fife, Scotland
KY16 9SX, UK
Email: saleem@cs.st-andrews.ac.uk
Expires: 10 JAN 2013
Atkinson & Bhatti Expires in 6 months [Page 36]
