Hi all,

I guess this is somewhat unrelated to the thread's maing topic but
the paper that Christian mentioned is available to everyone (as
well as all papers from SIGCOMM since 91) through SIGCOMM's web site.

The exact pointer for the paper mentioned below is

http://www.acm.org/pubs/articles/proceedings/comm/115992/p53-tsuchiya/p53-tsuchiya.pdf

regards,

-andreas

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andreas A. Terzis,                  | UCLA Computer Science Department
http://irl.cs.ucla.edu/~terzis      | Internet Research Lab 

On Wed, 26 Apr 2000, Christian Huitema wrote:

> > I agree completely with what you say about needing to push
> > the multi-address complexity to the host.  As you kindly
> > pointed out (and I self-servingly expand on here), this is
> > an architecture I put forth about a decade ago in a sigcomm
> > paper (in Zurich, I don't remember the year).
> 
> The paper "Efficient and robust policy routing using multiple hierarchical
> addresses " was published at the 1991 SIGCOMM, in Zurich. ACM papers used to
> be available on line, but it seems that the ACM now wants to enforce pay per
> view.
> (http://www.acm.org/pubs/citations/proceedings/comm/115992/p53-tsuchiya/)
> 
> There is related work on an "Extended Transmission Control Protocol"
> available at http://www.chem.ucla.edu/~beichuan/etcp/
> 
> > But that architecture (hosts having multiple addresses
> > representing a site's multiple aggregation prefixes and
> > selecting among them) requires some method of identifying
> > hosts when they switch from one address to another
> > mid-connection.  I would assume that what people have in
> > mind for this are the mobility mechanisms?  (The alternative
> > is 8+8 or some variant, which I understand to be contentious
> > enough that it is a defacto non-starter.)
> 
> The rubbing point is that identifying is not quite enough -- you need
> "secure identifying" in order to avoid connection hijacking, probably
> through some variation of IPSEC. Which brings us back to NATs not being
> terribly helpful...
> 
> 

Reply via email to