[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: old GSE idea
On woensdag, apr 16, 2003, at 20:28 Europe/Amsterdam, David Conrad
I think the simplest solution is to make the lower 64 bits globally
This breaks autoconfiguration. I think we need at least 40 bits for the
organization ID so that leaves just 24 bits for link-local use, which
isn't enough to make it possible for hosts to select a fixed address
without significant risk of address collisions. Not a fatal flaw I
guess, but not great either.
Treat the endpoint ID as a key into a distributed database of one or
more locators associated with that endpoint ID. The endpoint need not
(ever) know the full destination address, that is, the DNS lookup of
the end point host name would only return (top 3, lower 80).
Why not simply have the full addresses in the DNS?
The core/edge boundary packet forwarder takes the destination end
point identifier of the outgoing packet, looks up (simple hash would
work) the locators associated with that end point, picks one of the
locators based on some administrative policy (e.g., AS hop count),
rewrites the locator into the destination address and sends the packet
on its way.
So what happens when a link goes down?
Also we probably want this to happen either in the host or at the edge
(not the core, that would be another explosion of state) as per site
policy and not just at the edge.
As long as we're flying up levels, why not go up one more and compare
different multiple-PA approaches?
One reason I like the GSE concept is that it removes the topology
change induced renumbering problem from end sites, providing (in
addition to multi-homing), number portability, at least from the
perspective of end users
Other solutions in this area provide the same benefit without breaking
link local behavior, and I would (eventually) like to go even further
and completely remove the addresses from the user experience: just use
The other approaches that do not separate locator from identifier
don't address this problem (to my knowledge, pointers to documents
where they do greatly appreciated).
See Michel Py's MHAP draft. There are some difficult areas there, but
the basic idea is worthwhile. One thing that is very attractive is that
it moves standard IPv6 hosts behind a middlebox that handles all
multihoming processing. The downside is that it requires this, but I'm
confident that we can move MHAP or MHAP-like processing to hosts if
From my perspective, the "real" problems with the GSE concept, at
least historically, have been dealing with the distributed endpoint
ID/locator map and the fear that GSE would make insertion attacks
easier. Given the state of routing security (that is, the ability to
insert pretty much any prefix into the routing system) I personally do
not believe the latter concern is significantly worsened by something
like GSE and, in any event, this issue would be addressed by
deployment of IPSEC.
How is IPsec going to help you if the packets are rerouted over the
With respect to dealing with a distributed database, there are two
broad approaches, pushing the data out (e.g., the way routiing tables
are propagated) or pulling the data in (e.g., the way the DNS works).
Both have advantages and disadvantages, but this given existence of
solutions to this problem, this part seems solvable to me.
Don't forget about the actual failover. Also quite solvable, but not a
The problem I have with GSE and its derivatives is that it is
self-contained and doesn't provide hooks either forward or backward. It
would be great if it could be part of a bigger picture, where we can
upgrade from what we have today, to something a bit better, to GSE++,
to a clean architecture where we really get to drop in new protocols
for each layer like the OSI guys always promised we could.