RE: GSE

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Sat, 2 Nov 2002, Tony Li wrote:

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

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

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

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.

> autoconfiguration would assign an identifier upon recognizing the
> host based on the range of identifiers available to that particular
> subnet.

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

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

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.