[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: old GSE idea
Iljitsch,
On Wednesday, April 16, 2003, at 12:58 PM, Iljitsch van Beijnum wrote:
On woensdag, apr 16, 2003, at 20:28 Europe/Amsterdam, David Conrad wrote:
I think the simplest solution is to make the lower 64 bits globally unique.
This breaks autoconfiguration.
Only in as much as the 64 bits used in auto-configuration are not globally unique. How is this that much different than duplicate IP addresses in a WAN or duplicate MAC addresses on a LAN (both in terms of detection and remedy)? It should be treated as the error condition it is, not a normal state of affairs.
I think we need at least 40 bits for the organization ID so that leaves just 24 bits for link-local use,
Why put location back into identity? In my view, endpoint identifiers are 'names'. They are a flat, undifferentiated (from the network perspective, administratively, you may want some hierarchy) identifier space. The core/edge boundary forwarding mechanism dynamically associates a set of locators with that identifier. If you don't need to cross the core/edge boundary, normal routing via the lower 80 bits (16 bit site locator, 64 bit identifier) applies.
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?
Because it complicates renumbering and the DNS administrator does not know what the full addresses are. The full address is synthesized as a packet crosses the core/edge boundary and depends on the service provider(s) the destination uses. Also, placing the full address in the DNS would mean the administrator of the core/edge boundary forwarding mechanism has the authorization to muck about with data about the identifier. This is probably not universally desirable.
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?
Assuming you are asking about the multi-homed destination case,the naive approach would be to have the source core/edge boundary forwarder notice the link is down via 'traditional' methods (BGP re-convergence, ICMP network unreachable, whatever) and choose an alternate from the set of locators that map into the endpoint identifier. For a slightly more complicated case, see below.
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.
I meant the term "core/edge boundary" to imply the insertion of the locator occurs at the boundary between the core (more accurately, that part of the network that only cares about the locator) and the edge (more accurately, that part of the network that cares about the end point ID).
Normal CIDR provider-based addressing, painful renumbering, BGP-4+, etc. applies within the core -- it is no different than what we have today.
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,
How do GSE-like solutions break link local behavior?
and I would (eventually) like to go even further and completely remove the addresses from the user experience: just use names.
Presumably by "user experience" you mean from above the network layer.
You can have this if you limit names to 8 bytes. :-)
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 desired.
GSE-like solutions provide this positive/negative as well. I'll read Michel's MHAP draft.
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 null0 interface?
Sorry, don't follow.
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 trivial problem.
The difficulty in failover is detecting failover is necessary at the source. One possible solution would be to have the alternative locators kept with the packet in transit as an IPv6 option. Should a router in the transit path determine the destination locator is unreachable, the next (in terms of some administrative policy) locator that is reachable is popped out of the option, a new destination address is synthesized, and the packet is redirected to the destination via the new locator.
The problem I have with GSE and its derivatives is that it is self-contained and doesn't provide hooks either forward or backward.
I don't understand this statement.
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.
I believe the first step in any reasonable evolution will be to separate identifier from locator. Given realities of the market and the IETF, small steps are more likely to get forward motion than giant leaps.
Rgds,
-drc