Short version: CES's "core" and "edge" subsets of the global
unicast address space should not be given
inappropriate names such as "RLOC", "EID",
"Global Locator", "Local Locator".
Why the IP addresses in both the "core" and
"edge" subsets are still functioning as both
Identifiers and Locators.
Hi patte,
In "Re: SIP will work fine with CES, CEE won't work with NAT", you
wrote, in a different order:
>> My recent message
>>
>> Today's "IP addr. = ID = Loc" naming model should be retained
>> http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html
>>
>> will be heresy to many RRG folks.
>
> Here I get confused again about the usage of the identifier term.
> If you split up the addresses into two parts as in CES ...
I wouldn't express it this way. I would say the global unicast
address space has a subset of its addresses "separated" from the
remainder. The new subset is known as "edge" addresses and the
remainder is known as "core".
I am being pernickety about expression. I think am sure you mean the
same thing as I mean, but your phrase "split up the addresses into
two parts" could be interpreted as getting each individual address, a
set of bits, and using some bits for one thing and some for another,
as is done with ILNP and some other CEEs. "Subsets" is better than
"parts". "Separate" is probably better than "split".
> ... you will have an IP address block that is visible in the DFZ
> (in LISP that is RLOC) so why not give it the name e.g. Global
> Locator. Then the edge IP address space is only visible inside the
> local network (in LISP that is EID) so why not give it the name
> e.g. Local Locator - both are used for routing purposes anyway and
> resides in the IP header. But let us not start an argument about
> this, it is like it is - but it is very confusing for beginners
> (like me) on the list.
I think we need to be very careful with terminology.
> you will have an IP address block that is visible in the DFZ (in
> LISP that is RLOC) so why not give it the name e.g. Global Locator.
"Visible in the DFZ" is not a very clear expression.
Both the "core" and "edge" subsets of the global unicast address
space are covered by prefixes which are advertised in the DFZ.
These prefixes which enclose the "edge" space are known as MABs
(Mapped Address Blocks) in Ivip. They are advertised by multiple
DITRs (Default ITRs in the DFZ). The same things exist in LISP, but
there is no LISP-specific name for them. Multiple LISP PTRs
advertise them.
I can't think of any reason to refer to the "core" addresses as
"Global Locators" or any other such thing. These are ordinary,
conventional, global unicast addresses exactly like we use today.
The subset of the "core" address space which is advertised in the DFZ
can be classified into two types of usage:
1 - ISP prefixes. These are few enough in number to be regarded
as "scalable". Routing scalability is not aimed at reducing
their number, and we assume they are reasonably well managed
so as not to burden the DFZ routers with frequent changes
to whether the are advertised or not and where from.
ISPs use some of this space for their own uses, including
perhaps running ITRs and ETRs. Most if it is used for their
customers who get smaller portions, as longer prefixes -
including hundreds of millions of DSL, HFC cable, fibre etc.
domestic and SOHO customers who get a single IPv4 address.
To all those customers, the prefix of address space they get
is a "PA" prefix, because it is Provider Assigned - they only
get this address space as long as they keep using this ISP.
2 - End-user networks who have their own prefixes of space. They
either have their own routers connecting to the DFZ or they
advertise these prefixes through ISPs. To these networks,
their prefixes are "PI" - Provider Independent - since they
can use these prefixes with any ISP.
At present, PI space is the only way an end-user network
can get portability, multihoming and inbound TE. The
number of end-user networks which want and need this greatly
exceeds the number which actually use PI space.
The growing number which do use PI space is an unfair and
increasingly unsustainable burden on every DFZ router - and
all Internet users pay for these, since all ISPs must have
DFZ routers and/or pay for the DFZ routers of transit providers
(whose customers are other ISPs).
Both CES and CEE achieve routing scalability by providing mechanisms
for end-user networks to get portability, multihoming and TE without
needing PI space.
CEE does it by enabling each host to do extra work so its
applications communicate according to a new kind of thing -
Identifiers - which are portable and which are unrelated (in
principle at least) to the IP addresses which are used to physically
address packets.
CES does it by creating an "edge" subset of the global unicast
address space and by splitting up each MAB of this (each a single
advertisement in the DFZ) into many smaller chunks, to be used by
end-user networks, via any ISP they like. So end-user networks can
regard their portion of the "edge" space as their own (though they
will probably rent it from someone, rather than have it assigned by
an RIR). This enables them to use these "edge" addresses in a
portable fashion, and to achieve Multihoming and inbound TE with them.
Neither the conventional "core" addresses nor the "edge" addresses
are specifically Locators or Identifiers. CES doesn't alter the fact
that an IP address performs both of these roles.
The trick which CES performs is that the "core" addresses can be
split up very finely and used anywhere in the world. "Core" IP
addresses identify hosts just as much as "edge" addresses.
"Core" addresses also function as Locators since each DFZ router uses
some number of their more significant bits to choose how to forward
the packet.
"Edge" addresses also function as Locators - but in two different
ways. For a DFZ router, an "edge" address is interpreted like a
"core" address - the router figures out which DFZ-advertised prefix
it matches, and already has a rule in its FIB for which neighbour
router to forward the packet to, for each such prefix.
In the case of "edge" addresses, DFZ routers forward the packets to
the nearest DITR (Ivip) or PTR ("Proxy Tunnel Router - an awkward
term - in LISP). Internal routers forward packets addressed to
"edge" addresses also according to the short (large address span)
prefix they match. In ISPs without ITRs, the packets get forwarded
to the DFZ, where they will be forwarded to the nearest DITR or PTR.
If the ISP has ITRs, then these packets will be forwarded to an ITR.
When a packet which has an "edge" address is received by an ITR, the
ITR recognises it as such, because it is covered by one of the MAB
prefixes. The ITR uses the address to look up mapping - to find out
which ETR (Ivip) or which set of potentially multiple ETRs (LISP) the
packet should be tunneled to. The "edge" address is being used a
Locator in this stage of its travels. But the location information
is much more fine-grained than is possible with DFZ-advertised
prefixes. The ITR tunnels the packet across the DFZ to the ETR,
which decapsulates it and uses the "edge" address, again as a
Locator, to decide which end-user network to forward the packet to.
CES doesn't alter the current IP naming model which involves the IP
address functioning as both Identifier and Locator. CES achieves its
goals by making the "edge" subset of the global unicast address space
have a new, fine-grained, mechanism for interpreting the destination
address as a Locator, without burdening the ordinary DFZ routers at
all, whereby each little range (micronet in Ivip, EID prefix in LISP)
can be used via an ETR in the world. Those ETRs have to be on "core"
address space.
Perhaps this fact that ETRs need to be on the "core" addresses gives
rise to the LISP term "RLOC" for this subset of the global unicast
address space. I think "RLOC" is a misleading term, since this
"core" space will still be very widely used for other purposes than
ETRs, just as it is today for ISP's routers, ISP's hosts and the
hundreds of millions of ISP customers who each get some of this space
as "PA" space.
We need to be really careful with terminology. Unfortunately some
widely used terminology, such as "Locator Identifier Separation
Protocol" for LISP, and "RLOC" for "core" space, is misleading.
> Then the edge IP address space is only visible inside the local
> network (in LISP that is EID)
I think your term "is visible" does not have a clear meaning.
"Edge" addresses, like "core" addresses, can be used by any host in
the destination field of outgoing packets, and can appear in the
source field of incoming packets. Any host can send packets to other
hosts on both kinds of addresses. Internal routing systems and the
DFZ all have prefixes covering "edge" addresses, and as much of the
"core" space which is advertised in the DFZ.
Some hosts are on "core" addresses and others are on "edge" addresses.
It is not at all true to think that "edge" addresses are "only
visible" (whatever this means) in some kinds of networks, such as
"local networks" - whatever that means.
ISP networks, the networks of PI using end-users, the networks of PA
using end-users and the networks of end-users using the new "edge"
address all have routes for "edge" addresses and for as much of the
"core" space which is advertised in the DFZ.
> so why not give it the name e.g. Local Locator - both are used for
> routing purposes anyway and resides in the IP header.
Because "edge address" just means a subset of the address space with
which the ITR has a special way of interpreting the IP address for
the "Locator" purpose - ITRs tunnel these packets to distant ETRs,
rather than simply forwarding them to a neighbouring router.
>> The current IP address = Identifier = Locator arrangement works
>> and has major advantages in terms of being faster and
>> lighter-weight for all hosts. Scalable routing and global
>> mobility can be done better and more easily with CES than CEE.
>> CES preserves the current IP address model and does not require
>> us to alter host stacks or rewrite any applications.
>
> The current address model is soon running out of addresses, what
> then?
The "IP address = Identifier = Locator naming model I was referring
is used by both IPv4 and IPv6.
IPv4 address space is getting crowded. IPv6 will never be crowded.
There's scope for using IPv4 space more efficiently - but it involves
splitting up existing prefixes into more and more smaller chunks,
(longer prefixes). With CES, we can make more and more of those be
in "edge" space where they are perfectly scalable. Without CES, this
will drive an increase in the rate of growth of DFZ advertised
prefixes, exacerbating the routing scaling problem. IPv4 space will
eventually become too crowded to add many more hosts, but there's
quite a way to go yet before that happens.
The end of fresh, never-used, blocks of space just means people will
start sub-dividing existing blocks more and more, just as happens in
cities. In Melbourne, it is part of the official planning process to
support people selling their back-yard so another house can be built
there.
> When you are there you have to go after the host stack and some
> applications needs to be rewritten anyway.
To use IPv6, yes. Ideally, perhaps, we would all jump ship to IPv6
tomorrow. Arguably the most efficient thing for the long-term health
of humanity and the Internet is to burn every IPv4 address and
prohibit their use for ever more, forcing everyone cold-turkey onto
IPv6 where we can remain for eternity, rather than painting ourself
more and more into a corner in the too-small IPv4 room.
This won't happen, because IPv4 works well enough, despite the
looming shortage of space and the consequent ubiquity of NAT. IPv6
is a second Internet, and apart from email and perhaps DNS, it
doesn't interoperate with the IPv4 Internet at all. That's not
IPv6's fault - IPv4 has no hooks to aid migration to anything else.
> Sooner or later you need to
> deal with this problem, now there is a chance to do something more
> intelligent with IPv6, before it is getting more deployed.
I agree. But there's no tearing hurry. I will post a message soon
about current rates of growth in DFZ advertised prefixes in both IPv4
and IPv6.
> You will find it hard to categorize hIPv4, it is partly CES because
> it is splitting up the address space in core and edge addresses -
> but without any new mapping databases and the change should be
> applied at the hosts - not a map&encap solution. Also partly CEE,
> in order to achieve dynamic multi-homing a multi-path transport
> protocol should be used. So hIPv4 is an odd bird...an unorthodox
> approach but in research work that should be allowed...
OK - I wrote in "CES & CEE are completely different (graphs)" that I
know of no proposals which combine elements of both. I hope to read
hIPv4 later in the week. I am glad you are concentrating on the Home
Planet, rather than on IPv6 - which still looks very distant to me.
I think Oddness in research should be celebrated and encouraged.
Ideally the proposal should be very well grounded and practical - but
sometimes a wild and half-baked idea can be useful, if only to prompt
the discovery of a non-obvious idea which does turn out to be practical.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
