Short version: The correct use of "Locator/Identifier Separation".
NAT is evil - and incompatible with CEE.
SIP will work fine with CES.
Hi patte,
In "Multiple critiques, choice of single proposal, consensus on
constraints due to voluntary adoption?" you wrote:
> Joel,
>
> I throw some thoughts into the CES/CEE debate - just some observations
> that I think might be interesting to share with you
>
> A CES approach is preserving the hosts and applications, no changes
> needed there, right?
This is correct.
> But this is at the same time the biggest evidence that a CES approach
> is not really a true Identifier/Locator separation architecture -
Yes - Core-Edge Separation architectures do not involve "Locator /
Identifier separation". Please see:
Terminology: Loc/Id sep., LISP, CEE & CES, namespace
http://www.ietf.org/mail-archive/web/rrg/current/msg05858.html
> a CES solution engineers a certain address space (PI) from one
> repository to another, that is, from the DFZ routers' RIB/FIB to a
> mapping database.
Yes - a subset of the global unicast space is "separated" into
a subset known as "edge" space, just for end-user networks, which can
be used by them for portability, multihoming etc. in a highly
scalable fashion. This involves the individual divisions of this
space not being handled by the DFZ routers' RIB/FIB - but by a new
system of ITRs and ETRs, where the ITR tunneling behaviour is
controlled by the destination "edge" address and the results this
brings from a mapping database: basically one or more ETR addresses.
> So why can't you then consider CES as a true
> Identifier/Locator separation architecture?
CES involves separation of a subset of the global unicast space into
the new "edge" subset, and with the remainder being known as "core"
space.
This is not at all separation of Identifiers from Locators. This is
a common error of thought - a mistake I have made in the past too.
The most likely cause of it is the mistaken choice of name for LISP.
Maybe the LISP designers thought that by designing what is now known
as a Core-Edge Separation scheme (like LISP, APT, Ivip etc.) they
were really going to achieve the same things in something like the
same way as true Locator / Identifier Separation architectures such
as HIP, which predate LISP's late 2006 origins.
Just because a Core-Edge Elimination scheme such as HIP uses Locator
/ Identifier Separation to achieve scalable routing goals doesn't
mean that LISP, which uses completely different techniques (Core-Edge
Separation) to also achieve scalable routing, is also a Locator /
Identifier Separation architecture.
Other people have mentioned in the past that LISP is a misnomer. We
need to recognise this very clearly, otherwise it will be impossible
to use the perfectly valid term "Locator / Identifier Separation"
without causing a lot of confusion. It refers to Core-Edge
Elimination - not to Core-Edge Separation.
These CEE and CES terms are more recent - the last two years or so, I
think. I think the most important document which uses these terms is:
Towards a Future Internet Architecture: Arguments for Separating
Edges from Transit Core
Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf
This argues the superiority of CES over CEE. Please also see a
message I just wrote:
CES & CEE are completely different (graphs)
http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
> We know that there are overloaded applications, which are carrying
> Identifier&Locator information in there headers&payload. You can
> detect them by forcing them to traverse a NAT device - two most common
> applications that I can think of is IPsec and SIP. These protocols
> will work nicely in a CES approach but in a CEE where a true
> Identifier/Locator separation is applied you get into trouble.
You correctly state that CEE is Locator/Identifier separation.
As far as I know, CEE won't work with NAT. That is not necessarily a
bad thing with IPv6, since it has long been hoped that NAT would not
infest IPv6.
> It is
> also a well known fact that architecturally IPsec and SIP are broken,
> both are relying on IP addresses
I think the current 2 layer IP naming model is *better* than the more
"architectural correct" arrangement of having independent levels of
separate objects, in separate namespaces, for Identifier and Locator.
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.
As far as I know, IPsec and SIP will work fine with CES.
If the CES scheme is providing multihoming, and being extended with
the TTR Mobility architecture to provide global mobility (each MN
keeping its one or more IPv4 addresses or IPv6 /64s, no matter where
it connects, including behind NAT) then SIP should work just as well
as it does without CES. It may not accord with the "architecturally
pure" vision of all hosts having independent Identifiers and
Locators, but that doesn't mean it is "broken". It works today, and
it will keep working with a CES solution to the routing scaling problem.
One potential advantage of TTR Mobility is that a MN can have one or
more addresses behind NAT, but can still use its one or more IPv4
addresses or IPv6 /64s of "edge" address space: global unicast space,
known as SPI (Scalable PI) in Ivip, or EID space in LISP. This
constitutes an automatic, globally portable, form of NAT traversal
which will operates fine through any kind of NAT, or multiple levels
of NAT, because it involves the MN making a two-way tunnel out to one
or more TTRs. Those tunnels always traverse all kinds of NAT to any
depth.
> - so actually it is not the CEE's
> fault that you get into trouble with these kind of applications. And a
> new architecture comes with a cost, not everything can be preserved as
> such - if everything is preserved, then it can't be a new
> architecture.
Yes, but the only benefit of CEE I know of, apart from architectural
purity, is that it enables multihoming and perhaps mobility on a
scalable basis without the need to upgrade the routing system at all.
This is impressive and interesting, but it comes at a cost, as I
argue in my recent message about how CES is very different from CEE:
more delays in establishing most communication sessions, more work
for hosts, more packets going back and forth between hosts, more
lookups by hosts into slow, less then 100% reliable global query
server systems (such as DNS) - and all this is made worse still for
any host which is on a wireless link with congestion, delay, dropped
packets etc.
Then there is the fact that CEE only delivers substantial benefits to
adopters and to scalable routing after everyone has adopted it in
their hosts and after essentially all applications have been
rewritten to use the new CEE API in the stack.
This is never going to happen. The Internet is not so broken that we
have to rewrite the apps.
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.
> So is NAT really that evil as its reputation?
I think NAT is very evil. The any-to-any connectivity model of the
Internet is an excellent thing. I think its a tragedy (though
understandable) that IPv4's address length is 32 bits rather than 40
or 48. 48 would be heaps. So would 64. Given that it was 32 bits,
its a major blunder not to have a way out of this via an API which
returned to all apps the current length of the addresses used in the
Internet. If apps could have been ready for 64 bits, and have been
made to work with 32 for a while, then a transition from IPv4 to
something with more bits would be much easier.
> NAT has forced the
> application people to decouple the location and identifier - from
> application's point of view, you can't really rely on the IP address
> since it might be changed in a middlebox. And this is good,
> applications that works well through a NAT middlebox shouldn't have
> trouble with a CEE architecture.
If we can ever move to IPv6 or something else, NAT would be the
number one thing I hope never comes with us.
NAT itself is not standardised and the NAT traversal protocols are
consequently very messy and may not work, depending on the flavour of
NAT.
>From a very broad, excessively reductionist "architectural"
perspective, you might look at a bunch of developers who have
succeeded in making their code work when running on hosts behind a
variety of NAT boxes, despite the fundamental problems of these hosts
not being reachable from the global Internet - and say "Oh good -
these apps are so well written they work no matter where the hosts
are." But these efforts usually rely on the use of servers, such as
STUN servers and other contrivances which would never be needed if
every host was on a global unicast address.
But this capacity to cope with NAT usually (always?) depends on these
ugly servers and ugly NAT traversal techniques. This is not at all
the same as what a CEE architecture does. It is the result of an
heroic effort to overcome a pestilence which should never have been
introduced - but it had to be introduced because the limited number
of IPv4 addresses did not enable ISPs to dish out 16 or whatever IPv4
spaces to every DSL, HFC cable or whatever home, SOHO and small
company customer.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
