Keith Moore wrote:
> L3 makes routing look flat to the end systems. That's its
> job - to steer packets through the network. The network is
> aware of topology so that end systems don't have to be.
Step back from the trees and notice the forest. The L3 attachment point of
each end system is part of the topology information. Both end sytems are
required to know that part of the topology. That is the only part of the
topology they are required to know.
>
> Of course the original design of IP routing expected end
> systems to be more-or-less fixed relative to the network.
> It's true that mobile/nomadic systems aren't well-served by
> traditional IP routing. That's why people are working on
> mobile IP.
People have to work on mobile IP, because there is nothing to isolate the
app from changes in the topology attachment point. If there had been a
session layer between the app and transport, there would be no issue with
changing attachment points or failure restoration through an alternate
prefix.
> It's also true that ad hoc networks aren't well
> served by traditional IP routing mechanisms. Still, these
> are properly L3 functionality, even if they're not well
> served by existing mechanisms.
The issue in the ad-hoc network is the limitation of a single address per
interface, coupled with apps being directly glued to transport. There is no
way for the topology attachment points to compensate for network realities
without impacting the app when they are forced to use one value at a time.
Allowing multiple addresses to exist mitigates some of the impacts of
topology change.
>
> > That only happens because the app
> > has the illusion of a stable session identifier that it
> derived from
> > L3 information that was valid at one point in time.
>
> The design of both IPv4 and IPv6 uses addresses as both
> endpoint identifiers (hence their use in TCP) and locators.
> This was (and still IMHO is) a reasonable compromise for
> hosts with fixed locations. For mobile or nomadic hosts you
> need to seperate them somehow.
It was never reasonable for fixed hosts, as even you admit that there is no
way to sort out multiple interfaces. Much of the baggage in BGP is there to
compensate for the inability of apps to deal with multiple addresses having
different reachability characteristics.
> ...
> If there are no other address available, the network is
> dysfunctional. This might be an acceptable condition for a
> test bench, say, or while debugging a network that is broken,
> or to support a few very specific apps. It's not an
> acceptable condition for normal operation.
This is reality for a network where 2 nodes share a link technology and
there is no infrastructure node to provide an RA to indicate any other
prefixes. You may consider it dysfunctional for the apps you want to build,
but others have apps they are building to solve the lack-of-technical-clue,
zero-infrastructure case. As long as there is a clear flag to indicate LL,
you should have no problem ignoring them.
>
> > With other options available,
> > the app should have the opportunity to decide which it wants to use
> > based on it operational characteristics and goals. Either
> way the app
> > needs a flag to indicate what it is dealing with.
>
> I'll certainly agree that as long as v6LL's exist, it's
^^^^^^^^^^^^^^^^^^^^^^^
So your goal is to kill LL's???
> important to be able
> to distinguish them from real addresses. But this doesn't
> make them suitable
> for general use.
If an address does not meet the needs of the application, use the provided
flag to ignore it. Trying to prevent others from using a technology that
solves their problem is simply being obstructionist.
Tony
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
