Pekka Savola wrote: > The document assumes we need local addressing. That's > already solutionism. Having a document which explores local > addressing > requirements may be OK -- but at least state it clearly and > DON'T pretend otherwise! :-)
There is no intent to pretend. Maybe what you are trying to say is that the document needs to do a better job of documenting the requirement from the Application space that they be able to identify any non-globally accessible addresses so they can ignore them. This has been stated many times on the list, but is probably not well documented in the current draft. I suspect this is the core of your argument about why we don't need any local use addresses. In the abstract, any prefix can be kept out of the global routing system, and satisfy most of the scenarios in the draft. The issue comes when one wants to have some nodes with global access, while others are limited to local access. Mixing a single prefix in this environment creates a bottleneck & single point of failure in any edge access control, and assumes that the nodes are static in their attachment to the local topology. That set of constraints is unacceptable to many network managers, so their response will be to use nat to absolutely protect the nodes that need to be. An alternative is to use 2 prefixes in the network, where one is in the global routing system and the other is not. From a routing perspective there is no particular requirement that the restricted one be identifiable from the global one. Again, any prefix that is not in the global routing system achieves the protection goal. This brings us back to the requirements Keith and others have expressed, in that any address which is not globally accessable have a flag so they can choose to ignore it when referring literal topology attachments to others. At the same time, there are other scenarios where the application wants to know how to avoid global exposure. We can and should use the Bellovin/Zill approach to indicate which prefix is local, but we should also make the local flag well-known so that service providers put them on the bogon list. This helps reinforce the expectation that the prefix stays local, and removes the possibility of a single error exposing systems that should not be. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
