Dear Noel,
Let keep the street address analogy. Consider that the full address
is the addres of the rooms in the building at a given address. Now
consider that your building is at the corner of a block and it has a
door on each street. One on 126 Main Street and another on 27 Second
Avenue (you will accept to consider that the two roads as two
different ISPs). The room numbers are the same whatever the address
you use. Room 125 at 126 Main Street is also Room 125 at 27 Second
Avenue. The City zip code stay the same.
I think you are with me until now: this is a good image for IPv6
addresses including Interface IDs?
Now, consider that in that city one does go by street numbers but by
building names. As we did for a very long time and many still do. So
our building is named by the City Registry "Innovation House" - and
if a day it is scrapped and rebuilt eleswhere everyone will keep
calling it (the new) "Innovation House" (like for Scotland Yard for
example). Now, the Room 125 is in "Innovation House" on _both_
streets. Obviously the zip code is not changed.
This show you can consider a network numbering as _three_
concatenated _orthorgonal_ numbers:
- routing (zip code and street)
- identification (name of the house)
- local subaddres (nr of the room).
If you adopt network topology oriented routing numbers you
dramatically reduce the routing tables as you show it.
Identification registration is something we know pretty well with the
DNS and the current 256 or so TLDs.
There are different possible formats, but they make you save a lot of
numbering space.
Mobility is then addressable as a "follow-me" service the user can control.
jfc
At 20:17 28/03/2006, Noel Chiappa wrote:
> From: "Gray, Eric" <[EMAIL PROTECTED]>
> I think the "street address" analogy is not close enough - anymore
> than longitude and latitude numbers or any other description of
> physical location.
No, it's a very good analogy, because the road network is a very good analog
to the data network. To see how, let's do a though-experiment.
Embed the road-network, not on the surface of a solid sphere, but on the
surface of a flexible hollow spherical surface. Now, distort that surface
arbitrarily. The location (in spatial coordinates) of any place on that road
network has changed totally - but the set of directions you'd use to get
from one point in the road network to another ("go down road A until you
meet the junction with B, and turn onto B in the direction of C", etc, etc)
remains unchanged.
What is most important about both the data network, and the road network, is
the *connectivity pattern* - what connects to what. That's because packets
are (usually) constrained to travel down links, and vehicles are (usually)
constrained to travel down roads.
> The problem with physical location portability is that the location
> remains even if you're not in it.
But the exact same thing is true of a network - Port #0 on ISP A's router R
is the same place in the network (i.e. you use the same directions to get to
it - see above) whether company X or company Y is plugged in there - just as
126 Main Street is the same building, whether company X or company Y is
housed there.
> Number assignments, however are substantially more portable.
Saying that doesn't make it so. You can easily (sic) change street names
too, to make a street name "portable".
> It is certainly possible for an IPv6 address pool manager to allocate
> personalized IPv6 addresses from an IPv6 address pool that they manage
> and thereby assume responsibility for end-delivery
That's just a translation service from *virtual* addresses to real ones -
those IPv6 "addresses" aren't the names of locations in the network: if the
pool manager *actually wants to get packets* to those entities, it is going
to have to translate those "addresses" into the real addresses at which
those entities can be found.
Noel
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
