Subject: old GSE idea

From: Peter Tattam <[email-masked]>
Date: Thu, 10 Apr 2003 15:41:42 +1000 (EST)

I was doing a tidy up of my document folders and ran across this which is also
online.  Doesn't look like many people have referenced it - most of the hits
look like web crawlers.

http://jazz-1.trumpet.com.au/ipv6-draft/GSE-plus-routing-idea-july-21-1999.htm

I wonder if some of it may be relevant to recent discussions.  (you might want
to ignore the junk about ARPing for routing id's - that probably won't fly)
The relevant bit is the break up of the address bits.  Apologies if it
resembles other drafts.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 04:10:30 +0100

> The relevant bit is the break up of the address bits.  Apologies if it

No need to apologize.

In general, the idea is that there is a bit of space that is free for 
the
network to rewrite at will because it is not an end-to-end value.
One way of looking at it is that it is a way of cooperating with NAT
by way of a trade-off: sacrifice a part of the address for the network
to adjust, and constrain the amount of work host developers need to do
to accomodate their existence.   There is probably a more p.c. way
of putting this, but I am not the department of warm and fuzzy feelings.

Personally, I like this approach because it's obviously workable today.
However, I prefer at this point to consider the option of unifying the
v4 and v6 Internet routing tables for operational reasons, at least for 
now.
Perry Metzger and I  had a friendly (well...) exchange about this on
a public list some time ago (3-4 Dec 1999).  The general idea is that
leveraging off v4 experience and expertise is attractive to large 
operators
and other in-the-core supporting organizations, and is acceptable
to host-side and other at-the-edge folks because it needn't get in the 
way
thanks to tunneling, 6to4 and the like.

So, rather than maintain a routing system specific to GSE, as in your 
GSE+,
why not just stuff a v4 address into the v6 one, such that the v4 
address
(for example) describes the decapsulation point of an IPv6-in-IPv4 
tunnel?

This doesn't seem to be prima facie at variance with your old idea, 
which
correctly identifies an effective requirement for an "AFI"-like 
subfield in the
higher-order bits of the v6 address in order to experiment with 
different
routing and addressing semantics within the existing v6 address and 
header syntax.

	Sean.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2003 15:40:08 +0200

I think we should fly up one level and discuss a hypothetical
world in which addresses in A000::/3 are deemed to be mutable
in flight between bits 3 and 47 inclusive. See what it does
to TCP, SCTP and IPSEC for example. Then fly down again and look 
at the idea of doing GSE within A000::/3.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Apr 2003 16:53:08 +0200

On woensdag, apr 16, 2003, at 15:40 Europe/Amsterdam, Brian E Carpenter 
wrote:

> to TCP, SCTP and IPSEC for example.

Well, break them... The TCP/UDP checksum should be easy enough to fix, 
IPsec AH not much harder. The real problem is that if I have a session 
with a001::1 and suddenly packets start coming in from a002::1, how do 
I know these belong to the same session? This can be fixed by making 
the bottom 64/80 bits should be globally unique, or by informing the 
other side of all possible values that may appear in those 45 bits 
beforehand.

As long as we're flying up levels, why not go up one more and compare 
different multiple-PA approaches?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2003 17:04:47 +0200

Actually the requirement isn't that the bottom 80 bits be globally
unique, but that they be mutually unique among the set of hosts
involved (which may of course be more than two, due to referrals).
I don't know if that constraint is easier to meet.

Some would say that the answer to your question is HIP.

I do agree we should agree on a systematic breakdown and comparison
of approaches.

   Brian

---

From: Peter Tattam <[email-masked]>
Date: Thu, 17 Apr 2003 01:41:11 +1000 (EST)

You don't need to break into TCP stacks if the variable bits are zeroed at the
borders and if advertised addresses (i.e. DNS, IPSEC) always have these bits
zeroed.  Existing Ipv6 stacks should be able to work right away if the zeroing
rules are adhered to.

Even so, you still have to solve the issue of binding the strongly aggregated
routing gook to the site unique ID without degenerating back to what we have in
IPv4.

Restating my earlier observation - if the core is going to be strongly
aggregated, the MH information to any particular site is absent at the core.
Ti does actually still exist in the network, so it needs to be reconstituted
somehow.   DNS based approaches to the binding problem would not be rugged or
timely enough, nor would they deal adequately with load sharing.  Something
akin to the connectivity cache would still be required.  The question is to use
a push approach (broadcast or BGP like) or a pull approach (DNS like).

here's another idea (again apologies if it's already been thought of).  why not
apply a few more rules to the aggregated BGP tree.  For example, each leaf BGP
node can only be N (e.g. N=2) BGP hops from the core.  If that were the case if
might not be unreasonable to extend BGP so that a transient query could be made
to the nearest node to determine the MH paths of the other end.  This
information would travel through the core, but not need not remain in the core. 
The choice as to whether to cache the information would a matter of policy.  A
core BGP router would typically only pass information but not cache it whereas
an edge BGP router would be free to cache what it desired - perhaps within the
contraints of its CPU and memory.

Peter

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Apr 2003 11:28:27 -0700

On Wednesday, April 16, 2003, at 07:53  AM, Iljitsch van Beijnum wrote:
> On woensdag, apr 16, 2003, at 15:40 Europe/Amsterdam, Brian E 
> Carpenter wrote:
>
>> in flight between bits 3 and 47 inclusive.

Lovely idea.

>> See what it does

Right.  Either change the pseudo-header checksum to incorporate only 
the top 3 and lower 80 or set the 45 bits of the global locator to some 
constant value.  The latter approach allows for use of existing IPv6 
code, but makes figuring out the source of a (non-malicious) DoS and/or 
the source of an ICMP unreachable message at the end point a bit 
challenging (malicious DoS would likely have a spoofed locator).

> other side of all possible values that may appear in those 45 bits 

I think the simplest solution is to make the lower 64 bits globally 
unique.  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).  
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.

> 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 (yes, non-tier 1 ISPs will need to renumber 
their infrastructure should they decide to change upstreams, but this  
wouldn't affect their customers).

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).

 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.

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.

Rgds,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Apr 2003 21:58:43 +0200

On woensdag, apr 16, 2003, at 20:28 Europe/Amsterdam, David Conrad 
wrote:

> unique.

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.

> 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 
names.

> 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.

> From my perspective, the "real" problems with the GSE concept, at 
> least historically, have been dealing with the distributed endpoint 
> 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?

> 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 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.

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Apr 2003 16:29:55 -0700

Iljitsch,

On Wednesday, April 16, 2003, at 12:58  PM, Iljitsch van Beijnum wrote:
> 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.

>> 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).

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.

>> rewrites the locator into the destination address and sends the 
>> packet on its way.

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.

> 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.

> 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 basic idea is worthwhile. One thing that is very attractive is 
> that it moves standard IPv6 hosts behind a middlebox that handles all 

GSE-like solutions provide this positive/negative as well.  I'll read 
Michel's MHAP draft.

>> 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.

Sorry, don't follow.

> Don't forget about the actual failover. Also quite solvable, but not a 

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.

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 17 Apr 2003 13:59:05 +0200

On donderdag, apr 17, 2003, at 01:29 Europe/Amsterdam, David Conrad 

> it is, not a normal state of affairs.

MAC address collisions are not uncommon. Some time NIC vendors screw 
up, and some times people who should know better don't do the right 
thing. Just yesterday I had a problem with a layer 3 switch that uses 
the same MAC address for all of the virtual (VLAN) IP interfaces. And 
then there is stuff like privacy protection by randomly selecting the 
lower 64 bits.

The problem is that on a LAN, you can do DAD, but doing that world wide 
each time you connect to the network is no fun.

> space.

This is going to be a problem if you want to look these up in a 
distributed database. We really need a hierarchy for something like 
this.

> 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)

Obviously this stuff isn't going to be in BGP.  :-)

A large percentage of network problems don't generate unreachables.

So we don't get to be naive here.

>> Other solutions in this area provide the same benefit without 
>> breaking link local behavior,

> How do GSE-like solutions break link local behavior?

I mean autoconfiguration and similar stuff that escapes me at the 
moment...

>>> 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 

> Sorry, don't follow.

If an attacker gets to reroute your traffic, then they presumably also 
get to route in into oblivion. So IPsec doesn't solve problems in the 
routing system.

>> Don't forget about the actual failover. Also quite solvable, but not 
>> a trivial problem.

> locators kept with the packet in transit as an IPv6 option.

Yes, Marcelo Bagnulo has a draft out on this, if I remember correctly.

This helps but doesn't really solve the problem of dead layer 2 
networks where the IP-speaking boxes at both ends don't see there is 
something wrong.

> I don't understand this statement.

What I mean is that you need to implement GSE on both ends before it 
will do you any good. 15 second explanation of MHAP: hosts use PI 
addresses, but these addresses are replaced with PA addresses in 
transit. With MHAP or something similar, you don't have to upgrade all 
hosts, which is better, none of the routers, which is much better, and 
you can also start using the PI space immediately and then move in the 
MHAP boxes later. That's what I mean by hooks backward.

I think hooks forward are possible by not hardcoding the exact 83 bits 
we look at into the modified stacks but by making this more generic so 
we can support 160 bits or 64 bits out of 128 or whatever at some later 
date.

> the IETF, small steps are more likely to get forward motion than giant 

I'm not saying we should implement huge steps, but it would be good if 
the small steps we implement get us closer to a long term goal.