Hi Keith, I've been scratching my head over this whole (collective) discussion, and at the end of the day, I find myself collecting the arguments into a few boxes, some of the boxes are clearly out of scope for the IETF:
1) OS support - current POSIX OSs have a certain model for handling IP addresses, and address ambiguity creates problems for existing applications (& application writers). Application milage may vary with different OSs. I can think of other OSs that may do better or worse. 2) UI support - how do applications (& users) understand the difference between global & local (addresses & operations). How do we map these properties onto interfaces, links, etc. UI I mean in a broad sense, as how the user (human, silicon or code) of an address uses the address 3) Creating mechanisms for unambiguous addresses that may have additional properties like local and global. 4) Religious support - this is a rather large box that I'm going to toss much of the discussion for topics like need or non-need of local addressing; any sentence that contains the word NAT, and so forth. Clearly ignoring point 4, what I am left is that point 3 is clearly within the IETF's scope. I'd like for us to define a mechanism that clearly supports mechanisms for creating unambigious addresses that can have both global and local properties. Point 2 may have relevance to the IETF, but I think we would create some guidelines to applications developers, APIs, etc. I think that point 1 is clearly outside of the IETF's mandate, so we shouldn't go there. >From the various mails, there seem to be a sizable group of people who want to have the option of some sort of local addressing. I think we should provide a mecahism that supports that need/desire but also allows applications to disregard local addresses if they want to. br, John > II. On the "need" for "local addressing" > > Several people maintain that network admins will insist on local addressing. > A few have countered that network admins are quite aware of the problems > associated with local addressing and NATs in IPv4. > > I'm wondering if this is essentially a tools and/or a marketing problem. That > is, maybe we need to > > a. standardize the addressing solution that makes the most sense for support > of applications and actual operations, > > b. provide tools that make it easy and foolproof to restrict access and/or > hide networks that aren't supposed to be externally visible, and > > c. market these addresses and tools in such a way that they'll sound like "the > right thing" to network admins, and especially, their bosses. > > Of course, IETF is not a marketing organization, but that doesn't mean > we have to ignore human nature. > > So if we need to slap the words "local addresses" in some document title, and > then explain how GUPIs or PUPIs or whatever serve that need, for the sake of > appearances, let's do so. And if we can find a way to make it easy to get the > configuration right at the borders of a network beyond which PUPIs aren't > supposed to be visible, fine - as long as we're not placing a huge burden on > hosts or apps. > > But when we're talking among ourselves, it seems (on a technical level) better > to avoid the complexity that comes with firmly associating a single specific > and fairly arbitrary network boundary with an address format. And it seems > clearer if we use a less-loaded term than "local addresses" when talking among > ourselves - even while we acknowledge that blocks of these addresses will > sometimes (perhaps often) be confined to enclaves. > > (Personally I suspect the idea of the "site" with definite boundaries is > something of an anachronism - since I'm increasingly hearing of cases where > people are pulling their hair out trying to glue together separate "sites" > with NATs and make the result look seamless. But I don't want to overlook > the hazards of poor marketing.) -------------------------------------------------------------------- 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] --------------------------------------------------------------------
