There have been some alternate wording suggestions since Brian's
original message, but I like his text the best of all I've seen
and vote to adopt it as it stands.
We still have the use case of large networks that may have only
intermittent connectivity to the global Internet that will need
a stable prefix, as Brian says. But due to scaling limitations,
a flat addressing space simply won't suffice - there needs to be
some intra-site routing based on the stable prefixes. Finally, we
have to account for cases that can occur due to mobility:
1) A large mobile network travels together from one attachment
point to the internet to another
2) individual nodes or clusters in a non-attached network travel
to a different location within the same non-attached network
3) individual nodes or clusters from one non-attached network
travel to a differenet non-attached network
The mobile ad-hoc network case (at least) is going to require routing
based on stable prefixes on networks with only intermittent attachment.
If there are problems with the apps, as Keith suggests, we're just
going to have to fix them. I'm willing to help in any way I can.
Fred Templin
[EMAIL PROTECTED]
Brian E Carpenter wrote:
Well, that was fun: send one message and receive a few hundred. Peace.
I'm very sensitive to the argument about intermittently connected
networks needing a stable prefix. So I would finally prefer the
addressing architecture to contain yet another version of the
text in question:
Site-local addresses are designed to be used for addressing inside of
a site which is not permanently connected to the Internet. Using
site-local addresses, a subnet ID may be up to 54-bits long, but it
is recommended to use at most 16-bit subnet IDs, for convenience of
subnet management.
Why? Because we don't have consensus, and this text carries less baggage
than the others, which seems appropriate for an architecture document.
However, it may be that this change is not enough for the WG to recall
the draft from the RFC Editor. I think we should hum on that in Atlanta.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
