RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

["Bound, Jim" <Jim.Bound@hp.com>]

> On vrijdag, mei 9, 2003, at 14:05 Europe/Amsterdam, Bound, Jim wrote:
> 
> > By storing the end nodes in a routing header all other location can 
> > change enroute. This is completely stateless.
> 
> Not really. Someone must know to put in the routing header at some 
> point.

We build a dst option that informs the router the host did this so the
routers don't have to mess with it.  Or just but it in as dst option.
Or as new ext header.  I don't care how.

> 
> And this doesn't provide the functionality we need. Assume ISP A can 
> reach destination X but ISP B can't. In this case, the source must 
> transmit the packet over A. Transmitting it over B isn't 
> going to yield 
> useful results, regardless of the presence of routing headers.

This is not what I am addressing and orthogonal  However we get the
packet to the dst whether thru A or B the return address of the node is
required.  I want to avoid stateful looks in the path back to the
orginal, by last hop router to the dst, or by the receiving node as one
option for multi6.  

Or it can be kept in FINAL DST option within IPv6 too.  That way only
the receiving end node would ever see it and routers would not care. 

> 
> Also, we can't assume that users will universally prefer a stateless 
> solution with per-packet overhead over a stateful one that 
> doesn't have 
> extra overhead.

I can as one solution and that is my proposal for a stateless solution
as enhancement and use of the extensibility of IPv6.

> 
> I think state in the endpoints is perfectly acceptable. If 
> people want 
> central control over their multihoming and/or they want to 
> multihome-enable unmodified hosts by implementing the multihoming 
> functionality in a middlebox, having state in this middlebox 
> would also 
> be acceptable, especially if it's "soft state" that can be recreated 
> without breaking sessions if the middlebox fails. NAT shows 
> that it is 
> possible to build middleboxes that keep lots of state.

NAT is an abortion to networking that is not worthy of any response from
me it is almost as bad as the invention of bridges.

But if folks want state in the middleboxes that is fine I am proposing
another fix using the network computer science use of overloading,
extensibility of the datum being carried, and principles of cohesion
(close proximity) for indirection back to the end node. It also causes
no processing by ASICs in routers or processing.  It is used by the
receiving end node to respond to the destination.  It is similar in
property and architecture as the Home Address Option in Mobile IPv6, but
not exactly.  I believe it has less overhead too.

This way we can define the semantics of the 128bits architecturally to
support loc+ID and how to route packets across a inter-network of
topology and not have to worry about what the loc+id was for the
original node it becomes a non-issue.

Security for this is now well understood to apply what is required here
from MIPv6, HIP, AAA, and DNSSEC principles in those cases.  But has to
be clearly worked out.

If you don't like it that is fine but I would like to hear from others
on this list and the WG if that is ok with you?

I assume the answer is yes or you and I can go offline and discuss IETF
process?

/jim

> 
>