Short version: The current 2 level Internet naming model:
Role Level
Text name <---- FQDN
Identifier <---] IP address
Locator <---]
is superior for supporting host communications and
should be retained. Core-Edge Separation (CES)
architectures such as LISP, APT and Ivip retain
this model. (CES architectures separate "edge"
addresses from the remaining "core" subset - they
do not separate Identifiers from Locators.)
Core-Edge Elimination (CEE) architectures AKA
"Locater / Identifier separation" (not the
LISP CES protocol, which is confusingly named)
remove the linkage and provide separate objects,
in separate namespaces, to perform the roles of
Identifier and Locator.
The CEE approach is widely regarded as
"architecturally cleaner" - but the most open-
ended, generalised, approach is not always the one
which leads to the best overall system performance.
Please see the companion message:
CES & CEE are completely different (graphs)
for why I believe CES to be superior to CEE. This
is primarily because CES allows the current IP
naming model to remain, and secondarily due to CES
being much easier to introduce, with immediate
compelling benefits for adoptors and for routing
scalability.
Hi Joel,
In "Re: [rrg] Multiple critiques, choice of single proposal, ..."
(msg05846) you wrote:
> If someone wants to add text on Identifier / Locator separation as
> a useful architectural principle, I guess I can't object.
Do you mean Core-Edge Elimination (CEE) or Core-Edge Separation
(CES)? Please see this recent message for my concerns about how this
term may mean different things to different people:
Terminology: Loc/Id sep., LISP, CEE & CES, namespace
http://www.ietf.org/mail-archive/web/rrg/current/msg05858.html
I assume you mean that you support changing the IP protocols so hosts
use separate things for Identifier and Locator. I assume you do not
mean the LISP CES protocol, which does not involve "Locator /
Identifier separation".
CES architectures retain the current 2 level IP naming structure
where the FQDN performs the "Text name" role and the Identifier and
Locator roles are both performed by the IP address.
Role Level Conventional IP & with CES
Text name <---- FQDN
Identifier <---] IP address
Locator <---]
CEE architecture such as HIP, ILNP, GLI-split, Name Based Sockets
etc. involve Locator / Identifier Separation.
There are several naming models, but what they have in common is that
the Identifier and Locator roles are performed by different levels of
the model, with the Identifier object being interpreted according to
a different namespace from the Locator object.
I think most CEE approaches use 3 levels - FQDNs for the "Text
names", and separate levels to perform the Identifier and Locator
roles. In some CEE architectures such as ILNP, the lower part of the
IPv6 address performs the Identifier role and the upper part of
performs the Locator role.
Role Level Some CEE architectures
such as HIP
Text name <---- FQDN
Identifier <---- HIT
Locator <---- IPv6 address
Role Level Some CEE architectures
such as ILNP
Text name <---- FQDN
Identifier <---- IIII IIII } Combined into
Locator <---- LLLL LLLL } one IPv6 address
(Actually, the LLLL LLLL 64 bits are a locator within
the DFZ - enough to get the packet to the right ISP, and
probably further within the ISP to the correct end-user
network. IIII IIII is both the [usually globally unique]
Identifier of the host, and also may be used as a Locator
within the end-user network. Or perhaps some of the least
significant bits in IIII IIII function as a Locator within
the end-user network, and the remaining bits in IIII IIII
function as a Locator sufficient to get the packet across
the DFZ, to the correct ISP, and then within that ISP's
network to the correct end-user network.)
As best I understand Name Based Sockets, its naming model resembles:
Role Level Name Based Sockets?
Text name <---] FQDN
Identifier <---]
Locator <---- IPv6 address
However, if Name Based Sockets is to support a single Text name
enabling a host to get a list of multiple separate hosts, any one of
which can be used (as with "round-robin DNS) then the model must be
somewhat different. Name Based Sockets is intended to do this, and I
am seeking guidance from Christian Vogt on how it does so. My best
guess is that the Identifier role must be performed by some kind of
combination of FQDN and IP address.
Anyway, in all CEE architectures, the roles of Identifier and Locator
are performed by separate levels of the naming structure.
This is good if you want to have a simple routing system - because
you can have hosts be more responsible for routing and addressing
than they are today. Then, Portability, multihoming, TE and perhaps
mobility can be achieved as I describe in the companion message.
All these benefits can be achieved without PI space - so this solves
the routing scaling problem. The only thing which needs to be added
to the network is a mapping system so any host can look up an
Identifier and securely receive the current Locators which the host
with that Identity might be using. This is usually done with a
DNS-like arrangement or with extensions to the existing DNS system.
In the case of Name Based Sockets, the existing DNS is used. In all
these CEE proposals I know of, this mapping system is a global query
server system, like DNS. This means it tends to be slow and may be
unreliable due to packet losses.
Also, the mapping systems for CEE architectures frequently require
multiple lookups to find an authoritative server. The mapping system
for Identifier -> Locator lookups may not be suitable for caching.
So these CEE mapping systems cannot be as fast and reliable as those
for CES schemes (APT and Ivip) which use local full-database query
servers.
This Loc/ID split arrangement will delay the establishment of most
communication sessions, and create further burdens in terms of:
a - Extra management information to be included in some
host-to-host packets.
b - Perhaps extra packets flowing between the hosts.
c - Extra packets flowing between hosts and the mapping system.
d - Extra complexity and state in each host.
Here are my arguments for why the current 2 level IP naming model is
superior to the 3 level "Loc/ID split" model:
While CEE does involve a simpler network, this benefit is far
too slight to make up for greater effort hosts must make when
beginning new sessions and the delay this introduces. This
delay is typically forced on both the Initiating Host (IH) and
the Responding Host (RH).
There are delays in the Identifier -> Locators lookup which
both hosts typically have to do.
With today's IP naming structure - which remains unaltered with
a CES architecture - the IH may do a DNS lookup, if it starts
with a Text Name but this is not always required. If the IH
starts with an IP address (which is also the Identifier of the
RH) then there is no need to do a lookup.
With the Loc/ID split CEE naming structure, the IH always has to
do a lookup to get the one or more Locator addresses of the RH.
So, sometimes, this involves the same sorts of delays as is
currently the case. But in every case where the current 2 level
IP naming structure enables the direct use of an IP address,
the Loc/ID spit CEE system would be slower.
With the Loc/ID split CEE approach, if the RH should only reply
to packets after it establishes that the host it is going to
send the reply to really is the one whose Identifier is in the
request packet, then the RH needs to do an Identifier -> Locator
mapping lookup before sending the reply packet.
(This is not always the case. For instance a DNS server
might not need to know the Identity of the host to which
it will send the reply - so as long as the query packet
supplies a Locator which the DNS server can use to send
the reply to, then there's no need for the DNS server to
do a Identifier -> Locator(s) lookup to find the one or
more Locators which the host with this Identifier
currently has.)
(Neither an ordinary IP host or a CEE host can be sure
the request packet was sent by the host which has
the Identifier specified in the source field of the
packet.)
So there are at least one and frequently two extra lookup
delays before the IH gets the reply packet.
With today's 2 level IP naming structure, the RH knows the
Identifier of the host which will (probably) get its reply
packet - the Identifier is the IP address.
More particularly, while a host using today's 2 level IP
naming structure doesn't know for sure that the host with the
Identity signified by the destination address will get the
packet, it knows for sure that no other host will get it.
========
Without doing a lookup, the CEE host can't be sure that a
packet it sends with Identifier = X, Locator = 123 will not
be delivered to a host with an Identifier other than X.
* The basic problem with the CEE Loc/ID split naming model is
* that every host, when it wants to send a packet to host with
* Identifier = X needs to look up X in the mapping system to
* securely find the one or more Locators X has at present. Then
* it can send a packet to X using any one of these Identifiers, and
* know the packet will firstly probably get to X, and perhaps more
* importantly definitely will not go to any host other than X.
Typical conventional IP communication session establishment
protocols work like this. I am using the first two packets of
TCP as an example, but almost all protocols involve sending at
least a packet in one direction and getting a reply before
anything much can be achieved. IH and RH are the Initiating and
Responding hosts.
1 - IH has FQDN of RH.
IH sends DNS query.
\
\
\ DNS server replies (perhaps there
/ are two or more lookups by the
/ IH, or the resolver).
IH gets IP address /
of the RH.
IH sends SYN to IP
address of RH. \
\
\ RH receives SYN.
/ RH sends back SYN-ACK
/
IH gets SYN-ACK. /
This is 2 host-to-host packets and 1 global DNS lookup,
which may take a while, since it often involves long
distances, may involve packet loss and may require more
further lookups to find an authoritative DNS server.
2 - IH has IP address of RH.
IH sends SYN to IP
address of RH.
\
\
\ RH receives SYN.
/ RH sends back SYN-ACK
/
IH gets SYN-ACK. /
This is 2 host-to-host packets.
With the Loc/ID split CEE arrangement, assuming the RH only wants
to send the SYN-ACK packet once it knows that the packet will go
only to the host whose Identifier was in the SYN request packet,
here is what must occur. This is assuming the DNS lookup provides
not just the Identifier, but also the currently valid Locators.
It would be worse if the DNS only returned an Identifier and the
IH had to do a further Identifier -> Locator lookup.
3 - IH has FQDN of RH.
IH sends DNS query.
\
\
\ DNS server replies (perhaps there
/ are two or more lookups by the
/ IH, or the resolver).
IH gets Identifier /
and one or more
Locators of RH.
IH sends a SYN to
one of these Locators
and includes the
Identifier of RH in
the packet. It also
includes in the source
fields its own
Identifier and at
least one Locator.
\
\
\ RH receives the SYN packet.
RH initiates a mapping lookup
using RH's Identifier, to find
securely what one or more Locators
the IH can be reached on.
/
/
/
/
Mapping server gets
request and sends
reply. \
\
(This may involve \
more than one \ RH receives one or more Locators
lookup.) for IH. If the SYN packet's
source Locator matches one of
the Locators in the mapping reply,
then RH will proceed with a reply.
If not, RH will take no further
action.
RH sends SYN-ACK packet with IH in
the destination Identifier field
and the Locator from the SYN
packet in the destination Locator
/ field.
/
/
IH gets SYN-ACK.
This is 2 host-to-host packets and 2 global DNS or DNS-like
lookups.
So Loc/ID split frequently, typically or perhaps always involves
extra traffic and extra delays due to the lookups in one or two
global query server systems - before the IH gets a response.
There are workarounds for these problems. The RH could send the
SYN-ACK packet anyway, while waiting for the lookup of IH's
Identifier - and then close or ignore the session if it found
that the SYN packet's Locator did not match one of those returned
by looking up the Identifier in that packet. This is more complex
and wasteful than waiting for the mapping lookup, but it is
faster.
CEE architectures typically require sending extra stuff with
initial packets. However, for those which put both the Identifier
and Locator in the IPv6 address, there is no extra effort to
communicate both the Identifier and Locator of the host which
sent the packet.
There may also be exchanges during the session when one host
tells the other either that it has a new Locator, or that it
is no longer using a Locator it previously told the other
host about. Also, one host may tell the other host to send
packets to itself on another Locator from now on - either one
which it had previously told the other host about, or perhaps
another one.
Such communications need to be securely protected, such as with
a nonces which were exchanged during or shortly after the
session establishment. I have not shown this, or an initial
exchange of Locators (those to be used, which are a subset of
those to returned by DNS or the Identifier -> Locator mapping
lookup) in the diagrams above.
Without a nonce or some other form of protection, for any
host-to-host message regarding the use of Locators outside the
set returned from DNS or the mapping system, then an off-path
attacker could spoof such a request would be able to divert the
session to his or her own host. These extra exchanges of
new Locators to use may need to be sent to many correspondent
hosts, each of which has previously sent a different nonce during
session establishment. Perhaps these "new Locator(s)" messages
can be sent in traffic packets - but most likely they need to be
sent in special packets. Furthermore, there needs to be an
acknowledgement that the message has been received, with retries
if no Ack arrives.
For mobility in a CEE architecture, a Mobile Node (MN) which
has just gained a new Locator (a new IP address) needs to tell
all its correspondent hosts about this, and whether or not to
start using it in preference to the currently used Locator.
This may be done securely between the hosts, and there is
typically a need for the mobile host to securely update its
entry in the DNS and in whatever mapping system is used by
hosts to securely determine the one or more Locators which a
host with a given Identifier may be using.
The burden of all this on a MN is heavy. All these packets
need to flow in and out of its links, while the link is
likely to be busy with ordinary user traffic. Any lost
packets due to link congestion, or wireless reception
problems, will slow down the process and burden the MN with
waiting longer, sending more packets etc.
With the TTR Mobility architecture - which is based on CES -
the MN only needs to establish new tunnels to its one or
more TTRs (Translating Tunnel Routers) which are usually
nearby. Corresponding hosts are unaware of the changed
Locators, since they send packets to the MN's SPI address -
and the ITRs tunnel these to the currently chosen TTR.
So the CEE architecture always involves extra work for hosts
and almost always further delays.
Its bad enough having to depend more on global query server
systems such as DNS, but it is worse having each session
establishment typically involve two such lookups.
Any delays or packet losses on the wireless link to a
mobile node will make the whole process slower still.
> And I don't the the RG has a clear agreement on this at all.
Not yet.
We have just over four weeks to get this right - which involves going
against many years of widely held beliefs about the superiority of
Loc/ID separation.
Whether by accident or design, I think the current 2 layer IP naming
structure is the best.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
