Subject: RE: GSE

From: "Tony Li" <[email-masked]>
Date: Sat, 2 Nov 2002 00:11:41 -0800

Iljitsch,

|   > Each host needs to advertise its locator to correspondent 
|   hosts.  Whether
|   > this happens via DNS or via a mobile IP type solution is 
|   more detailed
|   > than we need to be right now, but basically, the correspondent can
|   > get multiple locators for any MH host.  Failover in this 
|   case is simply
|   > changing the locator in the packet and does not require tunneling.
|   
|   Yes, switching to a different locator is what we want to do when a
|   failure occurs. However, the GSE draft doesn't.

Fine, as I said, I'm looking at what we would like to do, not just
what GSE currently does.  Again, please see previous mail on 16+16.

|   Determining when to change locators isn't an altogether trivial
|   exercise. This is where we can use the help from TCP, since it knows
|   about timeouts and retransmissions, the IP layer has no 
|   idea about any
|   of this stuff.

Yes, exactly.

|   > |   - The flat part of the identifier space makes locator
|   > |   discovery hard.
|   
|   > Identifiers need not be flat.  They could be 
|   hierarchically assigned
|   > administrative entities.
|   
|   EUI-64 identifiers don't have a hierarchy that is of use to 
|   us. Using
|   anything else means autoconfiguration has to be changed.

There are enough issues around EUI-64 that I thought it was
good to get away from those anyway.  

In any case, I'm not convinced that there's a LOT of need to
have an identifier to locator mapping.  You need a hostname to 
identifier and locator mapping, but when would you go from 
identifier to locator without the hostname?

In any case, if we were to really want this, yes, autoconfiguration
would have to change.  The identifier space could have hierarchy,
but need not be tied to the topology.  Further, it wouldn't need
to aggregate except to make entry into DNS palatable.  The
autoconfiguration would assign an identifier upon recognizing the
host based on the range of identifiers available to that particular
subnet.

|   None of this is impossible, but what exactly is it about 
|   the 6+2+8 thing
|   that makes it worth going through all this trouble? If you 
|   simply assign
|   people a PI /48 you can use this address block as identifiers and
|   replace the first six bytes to make locators. The only 
|   "problem" with
|   this is that you have to replace the first six bytes in the 
|   address with
|   the original ones at some point, but it's much easier to make that
|   happen than having transport protocols only look at the 
|   bottom 64 bits.
|   If only because some box at the edge can do this.

Why is it hard to make the transport protocols only look at the 
bottom N bits?  Ok, yes, you have to feed them into the
checksum algorithm separately, but this is NOT rocket science.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 2 Nov 2002 10:39:40 +0100 (CET)

On Sat, 2 Nov 2002, Tony Li wrote:

> |   us. Using anything else means autoconfiguration has to be changed.

> good to get away from those anyway.

Good. That means we can reclaim a good number of those 64 bits. If we
use 16 bits on the local subnet, 16 bits for subnetting, 48 bits for the
routing goop or whatever it's called these days that leaves us with 48
bits for the organization identifier, which is enough to have a good
hierarchy. Although I wouldn't know how to number ogranizations
hierarchically...

> identifier to locator without the hostname?

Good question. Obviously there will be many times you'd want to do this
for debugging and so on, but that doesn't have to be very fast or 100%
reliable. Sometimes it's useful to connect to an IP address directly,
but if people really want this they can connect to three IP addresses as
well so this also isn't a very strong case.

Apart from that the only way you'd need this is for backward
compatibility with existing code, I think.

> host based on the range of identifiers available to that particular

If we kill EUI-64 we could do this right this time and base the host
address for autoconfiguration on the hostname.

> |   address with the original ones at some point, but it's much
> |   easier to make that happen than having transport protocols only
> |   look at the bottom 64 bits.

> checksum algorithm separately, but this is NOT rocket science.

The hard part isn't changing the stacks, but getting them out to
everyone who has an existing v6 implementation.

A comprimise would be to set the top 128 - n bits to 0 before
calculating the checksum. Then a host with an existing IPv6 stack can
interoperate to some degree with a modified one if a border router sets
the top 6 bytes (or whatever value we arrive at) to 0. Obviously such a
host would have to be configured with an address manually or maybe with
DHCP if DHCP knows about subnet sizes.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 04 Nov 2002 14:25:28 -0500

> identifier to locator without the hostname?

The standard argument has been that if you can't perform a mapping
from identifier to locator, it limits the ability to recover from
failures where the existing binding stops working. I.e., how do you
recover a TCP connection when this happens?

I.e, either recovery is not possible (in some scenarios), or it's
pushed back to higher layers (e.g., application and DNS lookup). But
if the application is responsible for recovery, its not clear how
attractive a solution this would be in practice (or how much more
benefit one gets compared to using full-blown addresses with no
separation of identifier and locator, as apps could do the same sort
of failure recovery today).

Of course, how often such failures will occur and thus how important
it is to deal with them depends on a lot of details/assumptions about
how frequently and underwhat conditions the bindings become invalid.

Thomas