Hello Richard, Reading your note, I thought of something that might be useful in the discussion.
Richard Carlson wrote: > That is, some > addresses only work within a limited scope (link-local, site-local, and > global). I believe this limited scope view matches the reality, were > network managers and institutions block certain connections. I also > believe this is a correct architectural position to take. In this excerpt, I suggest replacing the concept of addresse "working" by "are routable". This does make sense, and moreover it allows a possibly important refinement on the meaning of "addressability". I would like to suggest that a host is "addressable" at a certain address if a packet, with that particular destination address, would be accepted by the host. A host is "routable" at the address if routers know how to route packets to some link where the host is able to receive it. I hope the distinction is clear. For instance, I am typically addressable as Charles E. Perkins, but some messages addressed with that as a destination address cannot be delivered to me, depending on the transmission medium and location of the source and so on. Maybe the distinction has already been made, but I don't remember seeing it lately. If you like that distinction, then I think it means that site-local addressability as a concept should be replaced by site-local routability. That puts it squarely in the domain of routing configuration (and protocol), and takes it even farther away from proper visibility by applications. Anyway, I prefer globally unique but not-necessarily-routable addresses to replace site-local addresses. I don't see why they shouldn't have prefix FEC0:/10, and I don't see why whatever document deprecates site-locals should not also reserve that prefix for the provider-independent uses that have been proposed. The allocation mechanism could be discussed further, but the addresses would be taken on the understanding that they would not be globally routable. If a particular recipient wishes to make private routing arrangements, then that's their business. Regards, Charlie P. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
