Re: An idea: GxSE

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

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

How does an application learn its own GR addresses?

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

For the peer this is fine. But what about itself?


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

I see how that can be made to work.
The point is that I think this is a significant change in the way applications
deal with their own addresses. Today they can just use getsockname(int
sock,...) and pass this to peers.

Thus whatever the new architecture needs to be for applications (handling 
addresses) the ramifications of this is best understood by folks with
apps clue. I don't know how many of those we have on this list.

BTW: Working out how IKE would work in the GxSE architecture would be
a good test. (Even though IKE isn't a multi-party application it passes
IP addresses around.)


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

I had the same idea. At least it works better than changing the length
of the packets in the border routers.

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

In a sense your moving the complexity of the routing system to handle 
scalable multihoming to the transport and applications layers.

  Erik