Re: An idea: GxSE

["Paul Francis" <yoid2000@home.com>]

> > Every host knows at least one (and typically only one) address for
itself,
> > called the self-known address (SK address).  The SK address may or may
not
> > be globally routable, but must be globally unique.
>
> I think that today there are distributed (multi-party) applications
> that depend on an application being able to extract a globally routable
> IP address of the box (so that it can be passed to peers etc).
> It would be good to run the idea of apps not knowing their GR addresses
> passed folks with better application knowledge.
>
> It the applications need to know the GR addresses but the host itself
> doesn't know them then it seems like you need a way to map from SK
> to GR addresses.

I think you are mis-understanding the model a little here (cause I wasn't
clear about this aspect in the original message).  Applications should
operate in terms of passing the entire list of addresses around.  SK
addresses should not be thought of as some magic token that can be used by
applications to learn GR addresses.  Applications should know the GR
addresses from the start.  So here is the basic model:

1.  A DNS lookup on the FQDN will return you the GR addresses (if you are
outside the target's site), suggesting that at least for the initial
contact, the application should be aware of the FQDN not the addresses.
2.  Applications should be aware of the complete list of addresses, not just
the SK address.  Obviously this is tricky if a host doesn't know its own
complete list of addresses.  But what I have in mind is this:

The socket API has a set of calls like this:

    getcurrentaddresslist1(sock_id)
    or
    getcurrentaddresslist2(sk_address)
    or
    getcurrentaddresslist3(fqdn)

When host A talks to host B, host B learns the list of addresses by making
one of the above calls.  Ideally host A never "identifies" itself to host B
in the application, host B simply does the first call while the socket is
still up, learns the whole list, and uses the whole list whenever it
identifies A, either internally or when talking to a third application at
host C.  If for some reason it is necessary for host A to send its identity
to host B in the application layer, host A should preferably use its FQDN,
but could also use its SK address.

The second or thir call could be then used by host B if the socket has
closed.  If host B's "network layer" (kernel or whatever) has forgotten the
list, then both the FQDN or the SK address could be used by DNS to obtain
the list, but the third one is more likely to succeed (and requiring that
reverse lookups on SK addresses work even if they are not globally routable
is possible but puts more constraints on SK addresses).

Ideally the first call would be used wherever possible.

Anyway, once host B's application gets the whole list, which it can do
without host A knowing what the list is, it can send the whole list to host
C so that subsequently host C can access host A without resorting to DNS.


I don't think the above is real pretty---it is the cost one pays for
isolating site addressing from global addressing and getting rid of the
renumbering burden.


>
> > The list of addresses (GR and SK) is conveyed to partner hosts by an
IPv6
> > extension header---the address-list extension.  This header is typically
> > added by the site border router as the packet exits the site.  (It could
>
> Having intermediate nodes change the length of the packet does cause some
> issues with path MTU discovery. That's why encapsulation is normally used
> (e.g. in mobile IP) to deal with this.

An alternative approach would be to have the host attach a syntactically
correct address-list extension, but with empty place-holders for the GR
prefix list (instead of the "address-list trigger" extension I suggested
before).  There would be a learning mechanism, whereby address-list
extensions would have a field indicating the number of GR prefixes, and this
field would be set on incoming packets.  So if the host doesn't know the
number of prefixes, it would use a default, say 4.  If it chooses too small
of a number, then it would learn that in a subsequent return packet.  Of
course now the partner host would not have the complete list, but this would
not be a disaster.  (Alternatively the sending host could always add one
more GR prefix placeholder than it thinks it needs, to catch the case where
a new prefix has recently been added.)

Of course one could take this one step further, and simply have the
destination host return the source host's list of GR prefixes in the return
packet, so that the source host knows it too (on a connection by connection
basis---this would not be something the source host could generalize about
once the connection was closed).  This could be an option selectable by the
application...(ah, the complexity creeps in!!!!)

>
> > Pseudo-header checksums and IPsec would I suppose be based on the SK
address
> > only (not the GR addresses).
>
> It would be good to look at the effects of bit errors in the source GR
address.
> With no IPv6 header checksum and the GR address not being part of the
> pseudo-header checksum means that it is unprotected. (Perhaps having a
> checksum on the address-list extension can catch this.)
>

Thinking about it a bit more, pseudo-header checksumming the SK address,
when in fact it isn't even sent end-to-end, sounds kind of stupid...maybe
better to cover just the ID part of the source address (and the full
destination address, which doesn't get translated), and let it go at that.

PF