RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
"Tony Hain" <alh-ietf@tndh.net> Thu, 27 March 2003 01:10 UTC
Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26083; Wed, 26 Mar 2003 20:10:23 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18yM6J-0001tH-00 for ietf-list@ran.ietf.org; Wed, 26 Mar 2003 20:22:39 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18yM5I-0001ob-00 for ietf@ran.ietf.org; Wed, 26 Mar 2003 20:21:36 -0500
Received: from tndh.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26022 for <ietf@ietf.org>; Wed, 26 Mar 2003 20:06:22 -0500 (EST)
Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id <S23190> for <ietf@ietf.org> from <alh-ietf@tndh.net>; Wed, 26 Mar 2003 17:08:37 -0800
Reply-To: alh-ietf@tndh.net
From: Tony Hain <alh-ietf@tndh.net>
To: 'John C Klensin' <john-ietf@jck.com>, 'Michael Mealling' <michael@neonym.net>
Cc: 'The IETF' <ietf@ietf.org>
Subject: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Date: Wed, 26 Mar 2003 17:08:42 -0800
Message-ID: <04b201c2f3fd$69555270$ee1a4104@eagleswings>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <6020286.1048705632@p3.JCK.COM>
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA26083
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
- Fw: Welcome to the InterNAT... Jim Fleming
- Re: Fw: Welcome to the InterNAT... Peter O'Neil
- Re: Fw: Welcome to the InterNAT... Jim Fleming
- Re: Fw: Welcome to the InterNAT... Lloyd Wood
- RE: Fw: Welcome to the InterNAT... Tony Hain
- Re: Fw: Welcome to the InterNAT... Keith Moore
- RE: Fw: Welcome to the InterNAT... Tony Hain
- Re: Fw: Welcome to the InterNAT... Eliot Lear
- RE: Fw: Welcome to the InterNAT... Jeroen Massar
- site local addresses (was Re: Fw: Welcome to the … Ted Hardie
- RE: Fw: Welcome to the InterNAT... Jeroen Massar
- RE: site local addresses (was Re: Fw: Welcome to … Tony Hain
- RE: site local addresses (was Re: Fw: Welcome to … Michael Mealling
- RE: Fw: Welcome to the InterNAT... Fred Baker
- RE: Fw: Welcome to the InterNAT... Michel Py
- RE: site local addresses (was Re: Fw: Welcome to … Paul Hoffman / VPNC
- RE: Fw: Welcome to the InterNAT... Jeroen Massar
- RE: Fw: Welcome to the InterNAT... Margaret Wasserman
- RE: Fw: Welcome to the InterNAT... Michel Py
- RE: site local addresses (was Re: Fw: Welcome to … Tony Hain
- Re: site local addresses (was Re: Fw: Welcome to … Ted Hardie
- RE: Fw: Welcome to the InterNAT... Tony Hain
- Re: Fw: Welcome to the InterNAT... Eliot Lear
- RE: site local addresses (was Re: Fw: Welcome to … John C Klensin
- RE: Fw: Welcome to the InterNAT... Tony Hain
- RE: Fw: Welcome to the InterNAT... Fred Baker
- Re: Fw: Welcome to the InterNAT... Tim Chown
- Re: Fw: Welcome to the InterNAT... Eliot Lear
- RE: site local addresses (was Re: Fw: Welcome to … Tony Hain
- Re: Fw: Welcome to the InterNAT... Stephen Sprunk
- Re: site local addresses (was Re: Fw: Welcome to … Andrew Newton
- Re: Fw: Welcome to the InterNAT... Måns Nilsson
- RE: Fw: Welcome to the InterNAT... Michel Py
- Re: Fw: Welcome to the InterNAT... Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: Fw: Welcome to the InterNAT... Pekka Savola
- Re: Fw: Welcome to the InterNAT... Måns Nilsson
- RE: Fw: Welcome to the InterNAT... Tony Hain
- Re: site local addresses (was Re: Fw: Welcome to … Louis A. Mamakos
- RE: Fw: Welcome to the InterNAT... Tony Hain
- RE: Fw: Welcome to the InterNAT... Pekka Savola
- RE: Fw: Welcome to the InterNAT... Tony Hain
- RE: Fw: Welcome to the InterNAT... Richard Carlson
- Re: Fw: Welcome to the InterNAT... Valdis.Kletnieks
- RE: Fw: Welcome to the InterNAT... shogunx
- Re: site local addresses (was Re: Fw: Welcome to … Lloyd Wood
- RE: Fw: Welcome to the InterNAT... Pekka Savola
- RE: site local addresses (was Re: Fw: Welcome to … Margaret Wasserman
- RE: site local addresses (was Re: Fw: Welcome to … Tony Hain
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: Fw: Welcome to the InterNAT... Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … John Stracke
- Re: Fw: Welcome to the InterNAT... Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … John Kristoff
- Re: Fw: Welcome to the InterNAT... Richard Carlson
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Spencer Dawkins
- Re: site local addresses (was Re: Fw: Welcome to … Kurt Erik Lindqvist
- Re: site local addresses Simon Leinen
- Re: site local addresses (was Re: Fw: Welcome to … John Stracke
- Re: Fw: Welcome to the InterNAT... Lloyd Wood
- Re: Fw: Welcome to the InterNAT... Paul Vixie