Re: Architecture [Re: Agenda for Vienna]

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Iljitsch;

> >> In this draft you say TCP (and other protocols, leaving those alone 
> >> for
> >> a moment) should get multiple addresses from the application.
> 
> > Well, basically, I say hosts should have multiple addresses. It is,
> > of course, at IP layer.
> 
> What I mean is that when an applications wants to connect to an 
> application on another host, the first application has to find all the 
> addresses for the correspondent host and give them to TCP so that TCP 
> can start a session.
> 
> I don't think this is the right approach. Applications should only work 
> with one thing that identifiers the other end and not worry what 
> happens on the network.

That's merely a terminology concern.

Our TCP has an API accepting multiple addresses.

We also support API over TCP accepting a DNS name of a peer and
nothing more than that, which may be located at transport or
application layer. An interesting property of the API is universal
that it transparently works with IPv4, leagacy IPv6 and multihomed
IPv6 peers.

Or, there can be an API accepting ID of a peer, though it is not
universal.

Note that, architecturally, there is no real difference between
transport and application layers on the best effort Internet,
though, traditionally, something implemented in BSD kernel has
been called transport.

So, you can call all the APIs above TCP, if you so want.

> (BTW, how does the second host learn the alternative addresses for the 
> first host?)

Through DNS reverse and forward lookup, TCP option or some
transport/application specific way.

> > It is architecuturally of course that a change at the IP layer
> > affects many things.
> 
> It shouldn't.

Remember that promoters of NAT was saying so.

NAT was advertised to be a small harmless change.

> > As for deployment, change is optionaly.
> 
> All of the stuff we're discussing right now needs support from both 
> ends in order for multihoming on one end to work. This means change is 
> NOT optional, we need to get at least 95% of the internet to adopt this 
> or we have failed.

Interesting.

According to your logic, IPv6 have failed as IPv6 needs support from
both ends in order for IPv6 on one end to work. As you know, far
less than 95% of the Internet speak IPv6. So, don't bother to
discuss IPv6 multihoming.

On the other hand, the stuff we have finished is interoperating
with 100% of the leagacy IPv6 hosts.

						Masataka Ohta