In the interest of not seeing this swept under the rug as you say, let's discuss
the disconnected/intermittently-connected network case. We require stable
addressing for apps within such networks independent of what may be going
on with the provider point(s) of attachment. This seems to rule out provider-
assigned prefixes, since these are not portable and expire after extended
periods of disconnected operation. (Do you have a differing opinion on this?)
No and yes. No, I think that given today's technology I believe we need stable addresses so that lack of connectivity does not cause internal transport connections to fail. Yes, I wonder whether this could be sufficiently handled by minimum length leases that are retained for orders of months.
Failing such, we seem to have limited range addressing
and "graceful" renumbering as alternative options. Perhaps there are others also?
Yes: a default address, which is different from a limited range address. The default address goes away when overriden.
And then there is the case of renumbering and managing networks through renumbers. That's where Fred's stuff comes in.
Yes, but if you read the draft, the renumbering procedures Fred (Baker) describes
are anything *but* "graceful". I shudder at the prospect of "finding all the places"
(where addresses to be renumbered lurk) in anything but the simplest of networks.
I'd sure like to hear Fred's perspective on this, however.
I think I've contributed some words to Fred's draft, at this point. But this is where I would put my ernest efforts. Getting from one prefix to another is indeed painful at this point and probably requires some protocol development here and there. For instance, consider the NS record that is stored in the GTLD servers. How does that get updated automatically?
Then there is the order of operations in terms of both internal and external DNS servers. We need to see that authentication is widely implemented for DDNS (SIG(0) and such).
Eliot
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
