John C Klensin wrote: > ... For most of the cut section, consider that while 'good practice' says to use names, reality is that too many apps still grab the address for random reasons.
> But, obviously, I'm not understanding something. Could you > explain? There is a lot of noise about treating SL special, but as you note an application can ignore that a 1918 address is somehow different from any other address. If an application were to do the same and just use a SL as any other address, it will work just fine until one of the participants is on the outside of the filtering router (also true for IPv4 w/1918). If one believes that a split-DNS is reasonable to build and deploy (since many exist it seems self evident), then an application should only see a SL in a DNS response if the query originates in the same private address region. This again will work fine and the existing sending rules might cause the stack to order that one first so that any long-lived internal connections would survive an external renumbering event. The place SL starts to have trouble is when a multi-party app does referrals based on obtained addresses rather than names. Since the app can't know which parties are on which side of the routing filter, it can't pass the correct addresses around. (One could argue that if it passed a name then the split-DNS would return the correct address to the querier based on his location, but that frequently gets shouted down based on unreliability of DNS) It is also possible that one of the participants is only accessible via the private address space, so there is a failure mode where some participants can see each other while others can't. This will always be true, and has nothing to do with the well-known prefix FEC0::. The other place SL is criticized is for it's intentional ambiguity. While this doesn't prevent random announcements into the global table, it does provide a clear bogon for the route filters. Again this is not a problem until two parties try to route between each other without coordinating. Since there are 58 bits allocated for local administration, one would hope that multiple organizations could find a way to interconnect private networks without conflict. The argument against this is that people won't do it so we have to force them to register for some yet to be defined public space that is not routable. Since we know that ISP's will do whatever the customer pays for, it is only a matter of time until 'unroutable' prefixes start showing up in the global table. The intentional ambiguity prevents that. One reason that some people like private space is that they don't have to expose to their competitors what internal networks they are deploying and which office is coordinating that. If they are suddenly required to register for public space for every internal use network, they are more likely to pick random numbers than tip of the competition. What they want is space that for all intents and purposes to apps looks like global space, but they don't have to expose it, know it will be filtered at the border, and backed up by a filter at the ISP. So for these purposes there is no need to treat SL as a special case. Others are looking for a well-known filter than can be embedded in appliances so they are easy to sell to Joe-sixpack and only accessable from the home network. There may be apps that want to leverage the well-known filter to simplfy the life of Joe-sixpack. Consider the case of file sharing between nodes on an intermittently connected network. If the mount dropped evertime there was a connect event, Joe-sixpack would find another product. In this case there may be a reason for the app to treat SL as a special case, but this is something the app developer wants to do and is willing to do the extra work to make it happen. There are complex proposals for RA options, but so far none of them work for the node that needs to be seen both internally and externally. We need to get past the arguments that private space == nat, because use of private space predates nat, and its only relationship is that it facilitated nat as an address preservation tool. No matter what the WG does, there will continue to be private space used in various parts of the network. There will also be filtering in the network, so app developers have to deal with scope no matter how badly they want to avoid it. By clearly defining the address range for limited scope use, applications have the opportunity to use or avoid it at will. If the app passes names and the split-DNS infrastructure is operating correctly, there is no need for the app to care about the filters. If there really is some magic in FEC0::, I am willing to refocus my drafts from a PI mechainsm to a globally unique address space with no need to register. Since it results in a /64 per cubic meter 1km deep, there is no real potential for conflict. Tony
