RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
John Stracke wrote: Jeroen Massar wrote: Ad-hoc networks are another similar case, where two machines are connected via ad-hoc wireless, bluetooth, firewire, or similar. In any other way do you like remembering and typing over 128bit addresses?? :) :: is your friend. If you're building an ad hoc, point-to-point network, you can pick convenient addresses. :: as in all 0's which corresponds to 'not bound'? I don't see how you are going to communicate between two hosts with a unbound IP. Especially in a ad-hoc network where everything should be configured automatically. Most OS's require a (unique) hostname to be entered/automatically generated on install False. And is there any reasoned argument instead of the simple 'false'? Greets, Jeroen
Re: v6 support (was Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)))
In message [EMAIL PROTECTED], Keith Moore writes: Then there's the problem that when a 800-pound gorilla ships code, that code largely defines expectations for what will and will not work in practice- often moreso than the standards themselves. Strange as I feel defending Microsoft, I actually think it's commendable that they implemented IPv6 at all; it's not as if there's a lot of market demand for it yet. I'm certainly glad that they've done so; however most of their competitors are shipping v6 also, and some have been doing so for considerably longer than MS. About the only major vendor that isn't shipping v6 seems to be Palm (shame on them!). Keith, I can't get upset about Microsoft declining to ship poorly-tested code. Given how many security holes are due to buggy, poorly-tested programs, I applaud anyone who takes that seriously. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book)
Re: v6 support (was Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)))
Steve I can't get upset about Microsoft declining to ship poorly-tested Steve code. Given how many security holes are due to buggy, poorly-tested Steve programs, I applaud anyone who takes that seriously. Well, suppose they were to ship IPv6 without IPsec, on the grounds that they didn't have the testing resources for IPsec. Would you still be applauding them? Or would you be questioning whether they have their priorities right? Features always fall off due to the inability to allocate sufficient testing resources, but a vendor does have some choice over which features those are.
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
On 2 Apr 2003 at 18:10, Keith Moore wrote: The lack of IPv6 literal address support in the version of wininet.dll that shipped with Windows XP was for reasons of engineering expediency, in other words, MS deliberately shipped a broken product. Oh, look, release notes, known issue statements, bugtracker entries... Seems like everybody is deliberately shipping broken products... -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Michael Richardson wrote: -BEGIN PGP SIGNED MESSAGE- Bill == Bill Manning [EMAIL PROTECTED] writes: Bill Are the apps for which IPv6 is enabled that -can not- Bill use address literals? If so, then Steve is wrong and yes. Both IPv4 and IPv6 web browsers behave differently if you do, for instance: http://192.139.46.2/ vs http://www.sandelman.ca/ A different Host: header is sent, and therefore one gets a different (virtual) web site. Configure your server better than :) (eg use _default_ ) HTTP goes by name, not by IP. Also there is a RFC which says to never use IPv6 IP's in URL's... That's also why IE in XP doesn't support it. Host is now an integral part of HTTP/1.1 and one can't even do without it anymore. Of course, we have no need of this in IPv6, since 2^64 web sites per LAN is plenty, but the protocol still exists to do it. Can we change this in IPv6? Maybe. I don't think many hosters will like configuring 2^64 addresses on their webservers, even though it is possible. One neat thing about this is HTTPS though, as there are now enough addresses for that. But fortunatly there are propositions for enabling the Host header for different SSL sites even while using the same IP (v4+v6 ofcourse). Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Hi, Jeroen, Are you talking about ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)? My quick read of this RFC is that it says don't use IPv6 literals without enclosing them in brackets, as in host = hostname | IPv4address | IPv6reference ipv6reference = [ IPv6address ] But that's not quite the same thing you said: never use IPv6 IP's in URL's. If you're talking about another reference, could you provide it? A quick RFC search for IPv6 URL turned up only this RFC... Thanks, Spencer --- Jeroen Massar [EMAIL PROTECTED] wrote: Also there is a RFC which says to never use IPv6 IP's in URL's... That's also why IE in XP doesn't support it. Host is now an integral part of HTTP/1.1 and one can't even do without it anymore.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Spencer Dawkins wrote: Hi, Jeroen, Are you talking about ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)? My quick read of this RFC is that it says don't use IPv6 literals without enclosing them in brackets, as in host = hostname | IPv4address | IPv6reference ipv6reference = [ IPv6address ] But that's not quite the same thing you said: never use IPv6 IP's in URL's. If you're talking about another reference, could you provide it? A quick RFC search for IPv6 URL turned up only this RFC... Yes, though I can't seem to google up any references. Except for: http://www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/defa ult.asp Q: How can I force IPv6 connections using my Web browser? SNIP For applications other than Internet Explorer: Connect using a literal IPv6 address. URLs that use the format for literal IPv6 addresses described in RFC 2732, Format for Literal IPv6 Addresses in URLs, are not supported by the version of Internet Explorer provided with Windows XP. There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). And there where a number of other reasons for deciding so. Unfortunatly I can't find the messages which where sent to a mailinglist about this discussion which also contained why they decided this. Note that wininet.dll doesn't support it that's why IE doesn't either... MS CC'd, they can best explain the rationale behind it. Greets, Jeroen PS: Is 'google' already an official english verb? :)
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Jeroen Massar wrote: ... That's also why IE in XP doesn't support it. Making claims that you know nothing about, only exposes your lack of clue. Tony
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
At 10:18 AM 4/2/2003, Jeroen Massar wrote: Spencer Dawkins wrote: Hi, Jeroen, Are you talking about ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)? My quick read of this RFC is that it says don't use IPv6 literals without enclosing them in brackets, as in host = hostname | IPv4address | IPv6reference ipv6reference = [ IPv6address ] But that's not quite the same thing you said: never use IPv6 IP's in URL's. If you're talking about another reference, could you provide it? A quick RFC search for IPv6 URL turned up only this RFC... Yes, though I can't seem to google up any references. Except for: http://www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/defa ult.asp Q: How can I force IPv6 connections using my Web browser? SNIP For applications other than Internet Explorer: Connect using a literal IPv6 address. URLs that use the format for literal IPv6 addresses described in RFC 2732, Format for Literal IPv6 Addresses in URLs, are not supported by the version of Internet Explorer provided with Windows XP. There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). And there where a number of other reasons for deciding so. Unfortunatly I can't find the messages which where sent to a mailinglist about this discussion which also contained why they decided this. Note that wininet.dll doesn't support it that's why IE doesn't either... MS CC'd, they can best explain the rationale behind it. This line of reasoning troubles me. One of the ways in which numeric IP addresses are useful in URLs is for talking to systems which are not yet fully configured (e.g. configuring routers and such). I'm sure Microsoft's answer to this is Use UPNP but that may not be a universally sufficient answer. Others will say Use Zeroconf which may also not be sufficient. I guess I'm just really uncomfortable requiring name spaces in temporary and disconnected networks as an absolute requirement. Ad-hoc networks are another similar case, where two machines are connected via ad-hoc wireless, bluetooth, firewire, or similar. I'd think it might be useful to be able to serve web pages between two laptops on a train without requiring a naming service to be present. Perhaps that won't be an issue in the brave new world. It just seems to me there is some utility in having this capability (and others must have thought so since we have an RFC describing the formatting). Let's think hard before deciding we are sure there are no useful cases left.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Tony Hain [mailto:[EMAIL PROTECTED] wrote: Jeroen Massar wrote: ... That's also why IE in XP doesn't support it. Making claims that you know nothing about, only exposes your lack of clue. Fortunatly I don't have to resolve to personal accusations to get my point across. I cc:'d the people who really know how the stuff works so they could comment on these statements. :) Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Jeroen Massar wrote: Tony Hain [mailto:[EMAIL PROTECTED] wrote: Jeroen Massar wrote: ... That's also why IE in XP doesn't support it. Making claims that you know nothing about, only exposes your lack of clue. Fortunatly I don't have to resolve to personal accusations to get my point across. I cc:'d the people who really know how the stuff works so they could comment on these statements. :) I was the IPv6 program manager for what ended up shipping in XP, and literals in wininet didn't make it for lack of testing resources. Tony
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
% Are the apps for which IPv6 is enabled that -can not- % use address literals? If so, then Steve is wrong and % the DNS has become critical infrastructure to the working % of the Internet. % % anyone who believes that the DNS is not critical infrastructure for just % about every single purpose the Internet is used for is either living in a % fantasy world or has redefined the Internet to be something that's % strictly at layer 3 and below. % % agreed. but there's a difference between saying that DNS is critical % infrastructure and that it's appropriate to use DNS every time an address is % needed. DNS is necessary, not sufficient. % % Keith to pass bits, in the IPv4 world, DNS is -NOT- critical. no application forbids address literals and every app will allow address literals to be used. Couple this with the fact that IPv4 addresses are within the scope of human comprehension, i.e. I can remember 128.9.160.160 with IPv6, the addresses are long enough to not be human friendly, e.g. 2001:0478:6: is about as much as I remember on my own... I must use the DNS or my little yellow sticky note to complete the address. And there are intimations that some applications now forbid the use of address literals, even if bracketed. Sounds like you both are arguing that the DNS has become embedded and the applications that use IP are unusable without a working DNS. This assertion, if true, has ramifcations beyond a simple requirement to have the latency of an extra lookup against a third party. (Can you say Death to e2e!... sure you can :) --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore [mailto:[EMAIL PROTECTED] wrote: There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). perfectly reasonable thing to do. browsers that don't support it are broken. It's perfectly reasonable to not support RFC2732? or? Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore wrote: Sounds like you both are arguing that the DNS has become embedded and the applications that use IP are unusable without a working DNS. as a practical matter, this was true even in IPv4. yes, you can often use address literals in either v4 or v6 apps, but this isn't practical for ordinary users on an ordinary basis. and in both v4 and v6, several essential apps (e.g. email, the web) have explicit dependencies on DNS. yes you can use address literals in email addresses and URLs but there is no assurance that an email address or URL with an address literal is equivalent to the same address or URL with a domain instead of the address. Both email and the web define their resources in relation to a DNS name, not relative to a host or address. of course it is possible to write apps that do not use DNS, but this is rarely done. Fortunatly we still all are humans and like names, not numbers :) We'll let the numbers to computers (big fast math machines) Our brains are more advanced and just can't cope with numbers any more ;) Greets, Jeroen
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
From: Keith Moore [EMAIL PROTECTED] actually it's bad to force all apps to use DNS names - which are often less reliable, slower, less correct, and more ambiguous than IP addresses. This is like saying it's bad to force people to use cars/busses/whatever because they occasionally break, and everyone should walk everytime they need to go anywhere, because that's more reliable. That works in an agrarian society, but not an industrialized one. We have multiple namespaces, each with different characteristics for the names, for very good reasons. If we really need a name with characteristic A, and we instead wind up using one with characteristic ~A because it's more reliable, then that's not good. If we have a need for a name, and the optimal characteristics for that name are those of an address (i.e. the topological location of an interface to the network), then fine, use an address. If not, don't. If the system for mapping from one namespace to another has problems, we ought to fix it, not say oh, we'll just stop using it. Don't try and make everything into a nail because the hammer is the most reliable tool you have. Noel
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
From: [EMAIL PROTECTED] Effectively this could be resolved by having one globally unique identifier per node. Paging Noel Chiappa Paging Noel Chiappa ;) Ah, one moment, if I may: his books, he always said, contained the teachings of his master, Socrates; ... what [Plato] had to teach could only be learned as fire is kindled, by the touch of the flame itself. - Mary Renault, 'Fire From Heaven' The heart of all my knowledge on this matter I got from Jerry Saltzer, in particular the paper that was reprinted as RFC-1498, On the Naming and Binding of Network Destinations. I have merely been repeating what seemed to me a good idea. Noel
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
% Let's assume that there is a FooBar server in SiteA. If % another node in SiteA (NodeA) is communicating via a % multi-party application to a node in SiteB (NodeB), and wants % to refer NodeB to the FooBar server in SiteA, what does it do? % % Send a name. % % Not all addresses are published in DNS. % DNS isn't a requirement for IP either. % % Greets, % Jeroen Quoth Steve... There are no urgent DNS problems Are the apps for which IPv6 is enabled that -can not- use address literals? If so, then Steve is wrong and the DNS has become critical infrastructure to the working of the Internet. Otherwise, we should trapese down the path of separation of topology locator from stack identifier. and then revisit the DNS to see if its best used as a lookup service between these two things... :) --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Re: Thinking differently about the site local problem(was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
--On Monday, 31 March, 2003 09:01 -0800 Bill Manning [EMAIL PROTECTED] wrote: Is may be worth noting that RIRs have -NEVER- made presumptionson routability of the delegations they make. I believe that, although I remember some arguments within ARIN back when I was on the AC about whether it was legitimate or rational to make allocations that were believed to be unroutable. But I've gotten several private notes that lead me to believe that a lot of the community doesn't believe this or, more specifically, believes that everyone will fall into line and route any delegation that an RIR makes directly and, hence, that any RIR allocation will, de facto, become routable. john
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
-BEGIN PGP SIGNED MESSAGE- Bill == Bill Manning [EMAIL PROTECTED] writes: Bill Are the apps for which IPv6 is enabled that -can not- Bill use address literals? If so, then Steve is wrong and yes. Both IPv4 and IPv6 web browsers behave differently if you do, for instance: http://192.139.46.2/ vs http://www.sandelman.ca/ A different Host: header is sent, and therefore one gets a different (virtual) web site. Of course, we have no need of this in IPv6, since 2^64 web sites per LAN is plenty, but the protocol still exists to do it. Can we change this in IPv6? Maybe. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPopZtIqHRg3pndX9AQEc+wQA7lhFyoHXkIMopiYnh295B9R+8fpJxESt dUGdIlbNUA6QwefQoHMkLo77teXn4cc2CxDI6RaE2t93FRxMOeJQUfgdT022UmQ/ co+cVhkyRXnweJb6DfwGfu3YHK/j+J7ScLw0TQ0FSAPFwGXHRbOmAppVD138hUJG UXkPMLHDA/s= =JyhG -END PGP SIGNATURE-
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
David, let's not mix the problem with provider independent addressspace with the SL issue. The first needs to be solved anyway, and SLs are not the answer. Best regards, - kurtis - What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Keith Moore wrote: On Thu, 27 Mar 2003 15:31:23 -0500 John Stracke [EMAIL PROTECTED] wrote: Besides, we have three such prefixes, given RFC-1918 and 6to4: 2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32. the same problems exist for these as for SLs. Right. we should deprecate these also when we revise 6to4. Perhaps; but, given the prevalence of RFC-1918 addresses, it's unlikely that anybody's going to build their 6to4 implementation to block it from using them. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Hi John, But suppose we really do have enough address space (independent of routing issues). In that context, is site local just a shortcut to avoid dealing with a more general problem? Should we have a address allocation policy that updates the policies of the 70s but ignores the intermediate we are running out steps? Should I be able to go to an RIR and ask for unique space for an isolated network, justify how much of it I need, and get it -- with no promises that the addresses can be routed (and, presumably, without pushing a wheelbarrow full of dollars/ euros/ yen/ won/ yuan/...)? Yes, yes and yes. Margaret
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Bill Manning wrote: Is may be worth noting that RIRs have -NEVER- made presumptions on routability of the delegations they make. Did you just say 69/8 ? :) If an ISP chooses not to make a specific prefix reachable it is there 'problem'/policy, not much to do about it. Also anybody could just start up a Registry where one can register IP addresses for their Cybernet or whatever they call it. No need to go to the RIR's. The addresses won't be accepted by the Internet community though ;) Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Which actually poses an interesting question: when should an application just give up? IMHO, there is only one clear-cut case, i.e. when the application actually contacted the peer and obtained an explicit statement that the planned exchange should not take place -- the equivalent of a 4XX or 5XX error in SMTP or HTTP. Of course, in the case of site-local addresses, you don't know for sure that you reached the _correct_ peer, unless you know for sure that the node you want to reach is in your site. So, when working from a list of addresses that includes a site-local, an explicit refusal from the node that you reach at the site-local address (i.e. connection reset, port unreachable, or an application-level refusal) might not be a reason to stop working down the list. This is one case where the ambiguity of site-local addresses causes problems that would not be caused by using addresses that are globally unique, but unreachable. I understand that a collision of site-local addresses will be rare in autoconfigured networks. But, in non-autoconfigured networks, I'd still expect some proliferation of subnet == 1, IID == 1. Margaret
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Christian Huitema wrote: Well, that is emphatically *NOT* what application developers do. They do not just observe that it does not work, they try to work around, e.g. routing messages to a different address, at a different time, through a third party, or through a different protocol. Indeed, correctly coded applications will use a getaddrinfo() and then a connect() in a loop until succesful. This will also overcome filtering as all possibilities will be tried on the remote side. Note that 'succesful' here means that it was able to setup a tcp connection. UDP is totally out of the question here. Some applications could also modify 'succesful' to include a 2xx smtp reply etc. and absolute failure to be defined by a 5xx error. The problem is that this doesn't account for the locally-bound IP though. Thus if a host has a 'site-local' and a 'global' IP how does it know how to use which one? Also note that getaddrinfo() is only in use since a couple of years and most programmers are not even aware of it. I would suggest that the applications never bind() to a local address, this is possible for most applications. Then the stack can figure out which address to use for the outgoing connection. Most stacks will currently base this on longest prefix matching. Thus if there is a 'local' scope and the destination address is also in the same 'local' prefix, this address will be used for the connection. Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
From: Christian Huitema [EMAIL PROTECTED] ... Well, that is emphatically *NOT* what application developers do. Speak for yourself. Which actually poses an interesting question: when should an application just give up? IMHO, there is only one clear-cut case, i.e. when the application actually contacted the peer and obtained an explicit statement that the planned exchange should not take place -- the equivalent of a 4XX or 5XX error in SMTP or HTTP. I've written application code that shuts up for a while when it receives an errno value that indicates that the kernel has received an ICMP Unreachable. The code I'm thinking of is fairly portable, and so I've also had to #ifdef it to ignore error numbers that ought to indicate an Unreachable but don't on some UNIX-like systems or are not reported. Vernon Schryver[EMAIL PROTECTED]
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
On Mon, 31 Mar 2003 12:17:44 PST, Eliot Lear said: Right up till the point where two companies start communicating with one another directly with site-locals. Even if there is a router frob to keep the scopes scoped, you can bet it won't be used until someone realizes that the above problem occurred. Well.. the same thing is true for 2 companies that get merged and both have their 10/8 and 192.168/16 nets - then the router frobs get used. I've heard of one poor network engineer that had *5* 1:1 NATs separating one end of the company from the other. And of course, we all know that all RFC1918 users are conscientious about filtering at their border routers. It's deja vu all over again -- Yogi Berra pgp0.pgp Description: PGP signature
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Hi Tony, At 11:51 AM 3/31/2003 -0800, Tony Hain wrote: Margaret Wasserman wrote: Of course, in the case of site-local addresses, you don't know for sure that you reached the _correct_ peer, unless you know for sure that the node you want to reach is in your site. Since the address block is ambiguous, routing will assure that if you reach a node it is the correct one. This FUD needs to stop! I believe that you have misunderstood my point... I'll try to explain further, although our friends in the applications area may be able to give better examples. Let's assume that there is a FooBar server in SiteA. If another node in SiteA (NodeA) is communicating via a multi-party application to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar server in SiteA, what does it do? If this is IPv6 with site-local addressing, NodeA may be speaking to the FooBar server using a site-local address. What happens if NodeA sends that site local address to NodeB? NodeB tries to reach the FooBar server at the SL address that points to the FooBar server in SiteA. But, within SiteB, that same address may point to a non-existent subnet, to a non-existent node or to an existing node in SiteB. Scoped routing doesn't stop NodeB from reaching the wrong node, it guarantees that NodeB _will not_ reach the right node and _may_ reach the wrong node. The type of failure that NodeB will receive is different in each case. If the address points to a non-existent subnet or node, an ICMP error may or may not be generated and no connection will be established (timeout), but if there is an existing node in SiteB with the same address, NodeB will receive some type error from that node (the node that NodeB _thinks_ is the FooBar server), such as port not available, connection reset, or an application-level error. Or, worse yet, NodeB may not receive any error at all, and may never know that it was speaking to the wrong node. Now, what if NodeA has a list of addresses for the FooBar server (perhaps obtained through the use of split DNS) that includes both site-local and global addresses? Perhaps NodeA will send the whole list of addresses to NodeB. If NodeB tries the site-local address first (as current IPv6 address selection rules indicate) it will not reach the FooBar server. However, it could have reached the FooBar server using a global address. Perhaps, you believe that NodeA should include intelligence inside the application that knows NOT to send site-local addresses to NodeB if NodeB is not in the same site? If so, how does NodeA find out that NodeB is not in the same site? One proposal is that NodeA should only send addresses to NodeB that are of the same or larger scope as the IP address that NodeA is currently using to reach NodeB. But, this has problems, too: - It requires some fairly complicated changes to existing applications to make them work properly on IPv6. - It requires applications to make address selection choices based on the addresses in use at the network layer. Since there is an increasing desire for applications to be unaware of the addresses used at the network layer, and to survive changes in those addresses (see SCTP, SIP, Mobile IP, etc.), this is not an architecturally sound mechanism. - It doesn't give a good answer for what the application should do if it only has one address available for the referral, and it is not of sufficient scope. - It may not interact well with access control mechanisms that depend on using a site-local address to reach services, as it errs on the side of not sending site-local addresses, even when they may be valid. There are, IMO, three major problems (and several minor problems) with the use of site-local addressing on globally connected networks: (1) Routing protocol issues/complexity, such as the need to handle ambiguous addresses in routing exchanges and the need to maintain site convexity. These problems can be avoided by avoiding site-border routers and site-border nodes (as in the moderate proposal), AND by placing site borders on OSPF/IS-IS area boundaries or on AS boundaries. (2) Institutionalizing the need for split DNS. I understand that some network administrators choose to use split DNS today, but that doesn't meant that we want to build a requirement for split DNS it into the IPv6 architecture. IMO, requiring the DNS infrastructure to be aware of and enforce topology boundaries is a poor architectural choice. (3) The need for upper-layer protocols (transport, session and application-layer protocols)
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Let's assume that there is a FooBar server in SiteA. If another node in SiteA (NodeA) is communicating via a multi-party application to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar server in SiteA, what does it do? I thought we agreed, completely outside of IPv6 concerns, that shipping addresses in application data was bad. So NodeA refers NodeB to foobar-server.sitea.org. Q.E.F.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Eliot Lear wrote: Right up till the point where two companies start communicating with one another directly with site-locals. No, no, no. That's exactly what we don't want site-locals to do. Site-locals are not to communicate outside their own site, period. Michel.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Margaret Wasserman wrote: I believe that you have misunderstood my point... I'll try to explain further, although our friends in the applications area may be able to give better examples. Let's assume that there is a FooBar server in SiteA. If another node in SiteA (NodeA) is communicating via a multi-party application to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar server in SiteA, what does it do? Send a name. If this is IPv6 with site-local addressing, NodeA may be speaking to the FooBar server using a site-local address. What happens if NodeA sends that site local address to NodeB? Any app that sends topology locator information without understanding the topology is broken. NodeB tries to reach the FooBar server at the SL address that points to the FooBar server in SiteA. But, within SiteB, that same address may point to a non-existent subnet, to a non-existent node or to an existing node in SiteB. Scoped routing doesn't stop NodeB from reaching the wrong node, it guarantees that NodeB _will not_ reach the right node and _may_ reach the wrong node. In simple two party apps there will be no such confusion. If applications insist on passing around information that they don't understand, they will create the confusion you suggest. The type of failure that NodeB will receive is different in each case. If the address points to a non-existent subnet or node, an ICMP error may or may not be generated and no connection will be established (timeout), but if there is an existing node in SiteB with the same address, NodeB will receive some type error from that node (the node that NodeB _thinks_ is the FooBar server), such as port not available, connection reset, or an application-level error. Or, worse yet, NodeB may not receive any error at all, and may never know that it was speaking to the wrong node. It is very likely that no error will be received, because most site network managers block ICMP at the border anyway. Now, what if NodeA has a list of addresses for the FooBar server (perhaps obtained through the use of split DNS) that includes both site-local and global addresses? Perhaps NodeA will send the whole list of addresses to NodeB. If NodeB tries the site-local address first (as current IPv6 address selection rules indicate) it will not reach the FooBar server. However, it could have reached the FooBar server using a global address. If NodeB doesn't walk the list, it is broken. If the application on NodeA passed topology locator information without understanding the topology, it is broken. Perhaps, you believe that NodeA should include intelligence inside the application that knows NOT to send site-local addresses to NodeB if NodeB is not in the same site? If so, how does NodeA find out that NodeB is not in the same site? Since it didn't get a SL back for NodeB, there is no reason to provide NodeB with a SL address. Those addresses are defined to be filtered, and from the information that NodeA has, NodeB is on the outside of the filter. One proposal is that NodeA should only send addresses to NodeB that are of the same or larger scope as the IP address that NodeA is currently using to reach NodeB. But, this has problems, too: - It requires some fairly complicated changes to existing applications to make them work properly on IPv6. Changes that should be required anyway. Applications MUST NOT pass around topology locator information without understanding what they are doing. - It requires applications to make address selection choices based on the addresses in use at the network layer. Since there is an increasing desire for applications to be unaware of the addresses used at the network layer, and to survive changes in those addresses (see SCTP, SIP, Mobile IP, etc.), this is not an architecturally sound mechanism. If applications work from names, there is no need for a layer violation. The stack is perfectly capable of figuring out the correct address to use if it has a name to work from. Passing topology locator information without a firm grasp of the topology is the architecturally unsound issue here. - It doesn't give a good answer for what the application should do if it only has one address available for the referral, and it is not of sufficient scope. It absolutely does. When an app knows there is an insufficient scope, it also knows that the connection is designed by the network manager to fail. If the app developer can't figure out what to do when it is known that a prospective member can't participate, it is not our job to spell that out. - It may not interact well with access control mechanisms that depend on using a site-local
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
On Tue, 01 Apr 2003 00:23:15 +0200, Jeroen Massar said: Effectively this could be resolved by having one globally unique identifier per node. The underlying protocols should Paging Noel Chiappa Paging Noel Chiappa ;) pgp0.pgp Description: PGP signature
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Tony Hain wrote: Margaret Wasserman wrote: I believe that you have misunderstood my point... I'll try to explain further, although our friends in the applications area may be able to give better examples. Let's assume that there is a FooBar server in SiteA. If another node in SiteA (NodeA) is communicating via a multi-party application to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar server in SiteA, what does it do? Send a name. Not all addresses are published in DNS. DNS isn't a requirement for IP either. If this is IPv6 with site-local addressing, NodeA may be speaking to the FooBar server using a site-local address. What happens if NodeA sends that site local address to NodeB? Any app that sends topology locator information without understanding the topology is broken. SNIP Thus RFC959 is broken? There goes my favourite transfer proto :) And there are enough applications that are broken then. Actually all the applications that need special processing when traversing a NAT as those apps If those apps didn't pass an IP(/port) combo inside then they wouldn't need special treatment by the NAT either. We are actually getting to: Use a unique identifier that is topology independent. Wasn't that where IP Addresses where meant for? A unique address independent of topology... Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote: On Tue, 01 Apr 2003 00:23:15 +0200, Jeroen Massar said: Effectively this could be resolved by having one globally unique identifier per node. The underlying protocols should Paging Noel Chiappa Paging Noel Chiappa ;) Based on a quick Google I think I've just hit the flamepit... Reading the, interresting on first sight, documents... Greets, Jeroen
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
On Monday, March 31, 2003, at 05:30 PM, Tony Hain wrote: Let's assume that there is a FooBar server in SiteA. If another node in SiteA (NodeA) is communicating via a multi-party application to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar server in SiteA, what does it do? Send a name. What if the address has no name? Suddenly running a DNS becomes a pre-requisite to running a network connected to the internet? simon
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Margaret, Margaret Wasserman wrote: (2) Institutionalizing the need for split DNS. I understand that some network administrators choose to use split DNS today, but that doesn't meant that we want to build a requirement for split DNS it into the IPv6 architecture. I don't think Institutionalizing is a good choice of words here. Split DNS is not unique to site-local addresses, it's not even unique to private addresses. I have seen several sites that have split DNS even though they use public addresses only. Out of the 50 something distinct sites that I administer, I think only one or two do not have split DNS. IMO, requiring the DNS infrastructure to be aware of and enforce topology boundaries is a poor architectural choice. In theory, I agree but the fact of the matter is that it already is aware of the topology and I don't see this changing any time soon. Don't get me wrong: I do not like split DNS, but I have seen it on sites that have a single public address per host. There also are multitudes of perl scripts that parse custom zone files to make multiple different ones, such as the very typical example below that will produce 2 set of zone files: (yes I know it does include NAT but keep in mind this is today's reality too). name inside_addr outside_addr www 192.168.1.2 209.233.126.65 # web server ftp 192.168.1.3 209.233.126.65 # ftp server sql 192.168.1.4 0.0.0.0 pop3 0.0.0.0 209.233.126.65 [parse with homebrew perl script] zone file for inside DNS servers: www 192.168.1.2 # web server ftp 192.168.1.3 # ftp server sql 192.168.1.4 zone file for outside DNS servers: www 209.233.126.65 # web server ftp 209.233.126.65 # ftp server pop3 209.233.126.65 Again I'm not saying this is good but don't think it will be introduced or institutionalized with site-local addresses; it's been around for a long time. Michel.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Margaret Wasserman wrote: Of course, in the case of site-local addresses, you don't know for sure that you reached the _correct_ peer, unless you know for sure that the node you want to reach is in your site. Since the address block is ambiguous, routing will assure that if you reach a node it is the correct one. This FUD needs to stop! So, when working from a list of addresses that includes a site-local, an explicit refusal from the node that you reach at the site-local address (i.e. connection reset, port unreachable, or an application-level refusal) might not be a reason to stop working down the list. Your argument applies to global scope addresses, not ambiguous SL as currently defined. This is one case where the ambiguity of site-local addresses causes problems that would not be caused by using addresses that are globally unique, but unreachable. It does not, routing explicitly breaks in the presence of ambiguous addresses. That is the feature of ambiguity that many network managers want. What others want and we haven't provided is a stable address block that is unambiguous and unrelated to any providers they may be attached to. I understand that a collision of site-local addresses will be rare in autoconfigured networks. But, in non-autoconfigured networks, I'd still expect some proliferation of subnet == 1, IID == 1. This is not a problem, it is seen by many as a feature since it prevents unintended exchange of routing information. Tony
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Thus spake Eliot Lear [EMAIL PROTECTED] Right up till the point where two companies start communicating with one another directly with site-locals. Even if there is a router frob to keep the scopes scoped, you can bet it won't be used until someone realizes that the above problem occurred. I've dealt with many companies interconnecting where both use RFC1918 space -- NAT is the first thing discussed. You forget, these people are connecting for a _business reason_ and there is real money to be lost if they mess up. It's a totally different engineering model than the public Internet. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore wrote: Well, that is emphatically *NOT* what application developers do. They do not just observe that it does not work, they try to work around, e.g. routing messages to a different address, at a different time, through a third party, or through a different protocol. Indeed, correctly coded applications will use a getaddrinfo() and then a connect() in a loop until succesful. it's perfectly reasonable to connect to an address without first doing a DNS lookup. I think nobody can't help you if you are using hardcoded IP's. The only case you have an IP without DNS is when you get it passed from another layer/entity (eg in a FTP from the server). In any other way if you have multiple targets you can also try all of those in a loop similar to getaddrinfo(). even when you need to do a DNS lookup, getaddrinfo() doesn't always do what you need. Can you identify those so that getaddrinfo() can be expanded to fix these cases? Greets, Jeroen
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
All right, how do you make internal site communications completely oblivious to a change in your externally-visible routing prefix? You declare that any app that keeps connections around for more than some time period T (say for 30 days) have a mechanism for detecting and recovering from prefix changes. That solves the problem for all apps, not just for local apps. Ah, well, if we're allowed to solve problems by fiat, let's just declare that everyone do the right thing about site-local addresses, automatically drop unauthorized packets, end hunger and violence, and brush their teeth.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore [mailto:[EMAIL PROTECTED] wrote: Indeed, correctly coded applications will use a getaddrinfo() and then a connect() in a loop until succesful. it's perfectly reasonable to connect to an address without first doing a DNS lookup. I think nobody can't help you if you are using hardcoded IP's. The only case you have an IP without DNS is when you get it passed from another layer/entity (eg in a FTP from the server). uh, no. you can get IP addresses from any number of sources other than DNS, including from other processes that exist on other nodes. It's a perfectly reasonable thing to do. Note the line about other layer/entity :) Which is also one of the reasons why multi-faced dns isn't the solution to this problem. Can you identify those so that getaddrinfo() can be expanded to fix these cases? getaddrinfo() cannot be fixed. it's major premise - that the host has the knowledge to make decisions about which of several addresses is best to use - is fundamentally flawed, except in a few corner cases. Effectively this could be resolved by having one globally unique identifier per node. The underlying protocols should then take care that messages are delivered to the host described by the unique locator. The underlying protocols could then, in case of your so called corner cases, or routing troubles, based on all kinds of external information change the underlying protocols so that the connection stays active and messages can still be sent from A to B. Enter SCTP and multihoming ? :) This has nothing to do with sitelocal but more with the fact that a host can have multiple paths from A to B: internet ;) Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Applications will have to deal with that, yet there is no hint unless we provide a well-known flag. applications cannot be expected to deal with filters in any way other than to report that the communication is prohibited. the well known flag exists and is called ICMP. Well, that is emphatically *NOT* what application developers do. They do not just observe that it does not work, they try to work around, e.g. routing messages to a different address, at a different time, through a third party, or through a different protocol. Silently dropping packets is certainly not the right way to get an application to stop trying. ICMP messages won't achieve that either: since ICMP is insecure, it is routinely ignored. Which actually poses an interesting question: when should an application just give up? IMHO, there is only one clear-cut case, i.e. when the application actually contacted the peer and obtained an explicit statement that the planned exchange should not take place -- the equivalent of a 4XX or 5XX error in SMTP or HTTP. -- Christian Huitema
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Eliot, Eliot Lear wrote: What you say is possible, and has happened. But dumb things happen. Those dumb things could happen with non site-local addresses as well. More limited, that's the point. Not perfect, but better than unregulated anarchy. However, between a network design that does not meet RFPs (and therefore does not get implemented) and anarchy, I pick anarchy, especially when I'm not the one dealing with it later. This community designs protocols to please code developers and protocol designers. If it designed protocols with users in mind maybe less dumb things would happen because dumb users would not have to do dumb hacks to make things work. But look. Ultimately I think we as a community do need to own up to better tooling, which can lead to better expectations. This requires teamwork and what we have today is a bunch of people entrenched in their positions and unwilling to compromise. If you want better tooling, why don't you talk to the whiners that want to have the cake and eat the cake? You know, the same kind of people that wrote a real operating system or designed a real router that managed to capture 0.5% of the market but of course is better than the implementation that captured 75% of the market. Maybe if these people had compromised instead of digging their heels they would not be whining about proprietary implementations. The tools need to set expectations, and perhaps some of the DHCP prefix delegation code can help here. Care to explain? Michel.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, Mar 27, 2003 at 05:48:44PM -0800, Christian Huitema wrote: My Windows-XP laptop currently has 14 IPv6 addresses, and 2 IPv4 addresses. The sky is not falling. Except of those 14 some seven(?) are RFC3041 addresses, which break a number of applications... so there are some clouds in the sky. Tim
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
I suspect that most people there, who voted for the elimination ... At my first IETF meeting I received a T-Shirt, courtesy of Marshall Rose, I believe, that said We reject kings, presidents and voting... The real tragicomedy of this situation is that someone considered it fitting and proper to count 102 hands.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Margaret Wasserman wrote: As you know, I was in favor of setting aside a prefix (FECO::, in fact) for use as private address space (either on disconnected networks, or behind NATs), but the consensus of the folks in the IPv6 WG meeting was to deprecate that prefix altogether. There were several compelling arguments from operators and others that we don't need a special prefix for disconnected sites... Besides, we have three such prefixes, given RFC-1918 and 6to4: 2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote: No, it's more than that. SLs impose burdens on hosts and apps. SLs break the separation of function between apps and the network that is inherent in the end-to-end principle. Is it safe to assume that the arguments (on either side) would also apply to such things as multicast addressing and SCTP path management? Actually we are working toward an architecture that provides a level of consistency. Which is essentially what I'm rephrasing into a question above. I think I know the answer, but I want to make sure. John
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
On Fri, 28 Mar 2003 14:00:31 EST, David R. Oran said: Did anybody consider just handing out a /48 (or a bit smaller) automagically with each DNS registration? Routing Table Bloat. If you can figure out how to do this in a CIDR aggregation context, or otherwise work around the table problem, the IETF and NANOG will quite certainly jointly nominate you for sainthood. ;) pgp0.pgp Description: PGP signature
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
layers above it and a dangerous blow to the hour glass model. Looking at what is going on in the IETF, I think we are talking about first aid rather than trying to prevent the blow as such. That happened along time ago...:-( But yes, we need to protect the architectural model or discuss a new one. I vote for the first, and in both cases we need to decide on that fist, before starting to decide on implementations. So leave site-locals for know. Steve Deering made a wonderful presentation at the plenary in London. More people should read it. - kurtis -
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. SLs won't come for free either. Architecture aside, I prefer people that use a service to pay for it rather than the community as such. Then I also happen to think that SLs break the architecture but that is something else... - kurtis -
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
To echo the favorable review of Steve's presentation: It's at http://www.ietf.org/proceedings/01aug/slides/plenary-1/index.html, and is well worth the few minutes it takes to read/re-read... Spencer --- Kurt Erik Lindqvist [EMAIL PROTECTED] wrote: Steve Deering made a wonderful presentation at the plenary in London. More people should read it.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
David R. Oran wrote: Did anybody consider just handing out a /48 (or a bit smaller) automagically with each DNS registration? I proposed a couple of times a /32 from which /48 can be requested for 'private' (never to be connected to the internet) purposes. I think some others have proposed a similar thing. But the opposers think that it won't be 'free' then... but they will be unique :) Greets, Jeroen
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
John C Klensin wrote: (ii) ISPs impose restrictions on their customers all the time and often even enforce them. Many of us consider some of these to be desirable (e.g., terms and conditions prohibiting spamming) and others less so (e.g., prohibitions against running server or peer-peer protocols over a cable network or address restrictions that force reasonably-architected LANs into NAT arrangements) but the conditions clearly exist. Note I said: It is absolutely unreasonable for an ISP to tell their customer anything about running their network that is not directely related to the customer/provider interface. As long as the enterprise traffic over that interface is related to the capabilities they are paying for, it is none of the ISPs (or IETFs) business what they are doing elsewhere. The ISPs do set terms for the customer/provider interface all the time, and rightly so. They can not restrict me from setting up an 802.11 link to my neighbor, only that my neighbor is not allowed to use that for access to the provider's network. In a similar vein, the provider is not in a position to tell customers what address space they can use for purposes that do not interact with the provider interface. They can try, and in a monopoly environment will probably succeed. That does not mean we can tell ISPs to require that people not use any given address space just because the provider is supplying another one. I also note that site local addresses open up a whole series of questions about locality and scope-range. Perhaps we also need ISP-local addresses (routing into one ISP's space, or part of it, but not to that ISP's peers or transit customers) and so on. The one thing that can be guaranteed about that sort of arrangement is an extension of the pay enough and someone will route it model will apply: If some ISP sees a potential competitive advantage in offering such a product (and addresses), the product will follow soon thereafter. And, again, I think that this suggests that we had better figures out how to deal with these things on a policy basis, not a protocol-imbedded special address scope one. We are almost certain to have the policy problem anyway and it is not clear that special cases for peculiar address scopes will buy us that much in addition. Address filtering exists in the network today, and will continue. Since that is done as an expression of local policies, you are correct the whole discussion is really about policy. It is not clear to me what the IETF is in a position to do, other than define the operation of a multifacited DNS. ;) Tony
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
John C Klensin wrote: ... but I am unconvinced that we should make special architectural provisions to make it easier to be in the ISP business while being clueless. Isn't that just what we did with MPLS?? ;) or does that just prove your point? ;)) My arguments are more about acknowledging the reality and requirements of the deployed architecture than they are about creating a special case. Routing filters do and will exist, ergo local scope addresses will exist. Applications will have to deal with that, yet there is no hint unless we provide a well-known flag. I agree that applications should not have to understand topology, but when they insist on passing around topology information they have bought into the need to understand what they are doing. DNS is one of the protocols that deals in topology information, so it needs to understand topology. We need to make it robust enough that applications can rely on it so they will simply pass around names. In writing that it occurs to me that one of our failings is that we have allowed a component of the system to have a very unrealistic (archaic) view of what the network is. The DNS system is designed for the network of 1985, and we blindly continue to use it as the database for locator information in a very different network. I understand the IAB has recently cleared its backlog of issues, so maybe this is a ripe topic for them to address ... Tony
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
John, John C Klensin wrote: We, or more specifically, the upstream ISP or an RIR, can tell the ISP that things will go badly for them if they permit un-routable addresses to leak into the public Internet. The only difference I can see between what I think is your SL address preference and my unique, but un-routable one is that you would bind that advice/threat to a particular prefix while I would bind it to other indicators of un-routable address. The reserved prefix approach is less likely to get mucked up by a clueless ISP, but I am unconvinced that we should make special architectural provisions to make it easier to be in the ISP business while being clueless. I also think that policy alone can not enforce un-routability of addresses. The only way to make sure that addresses are not routable on the public Internet is to suppress the demand for routing them. Example that works: RFC1918. Although we occasionally see these on the public Internet, it's due to misconfiguration. No customer is going to see their upstream and offer them money to leak or route RFC1918 addresses, because it achieves nothing (because RFC1918 addresses are ambiguous). No demand, no routing. Example that would not work: Allocate a block of regular addresses (let's say, 2003::/16) to the purpose of globally unique non-routable addresses. Whether you bind the advice/threat to that prefix to other indicators of un-routable address you will create the demand from end-sites to go to their providers and indeed ask them to route them to be used as PI, with the result of routing table bloat. What is required in order to get globally unique non-routable are three things: - Policy (the advice/threat). - Some normative language mandating implementations (vs. policy) to disallow the practice (default blackholing). - Some kind of architectural limitation such as site-local. The combination of all three is required. The policy alone is not enough because some ISPs will take the customer's money at the risk of being labeled as bad boys. The normative language alone is not enough as we have no way to force implementers to code it. The architectural limitation alone is not enough as one will likely come up with a dirty hack to route SLs globally if need be. Any combination of two would not be a powerful enough deterrent either. In other words: the only way to guarantee the non-routability of globally unique private addresses is to put so many hurdles on the way that it won't happen. To this effect, the proposed deprecation of site-locals is a serious blow as it suppresses the architectural limitation and therefore creates demand for sites to pay their ISPs to forget to filter their prefixes and transform a non-routable globally unique prefix into a de-facto routable globally unique prefix also called PI. Michel.
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
John, mixed bag of nasties here. Routing, addressing, and (of course) the DNS. More fun than should be legal on a friday afternoon. Routing: there is a varient here. Think about routing table slots. If I get one, does it matter what the length of the prefix that I put in it? There are other abstraction methods besides aggregation, at least thats what some smart people are telling me. The other bits will have to wait. % * From an RIR, as PI space % % * From an ISP, as PD CIDR space. ISPs might sensibly % decide to charge less (in money or aggravation) for % space which no one intended to route. Or might not: the % marketplace is good at sorting out these things, as long % as the RIRs are willing to make allocations to ISPs that % reflect the desirability of having addresses for % isolated networks unique and reflecting the ISPs to % which they might ultimately connect. % % * From some other process, as long-prefix, almost % certainly unroutable, isolated space. This process % could presumably be designed to be very lightweight in % charges and administrative costs. % % So, while I'm very hesitant about anything that ties addressing % (of any sort) to DNS names, I'm not convinced that Dave's % suggestion is worth dismissing out of hand. % % Three additional observations: % % (i) Tony's response to my note seems, to me, to turn SL largely % into a policy problem, not a technical one. We haven't have % really good success binding policies into protocols. That % doesn't convince me that we should never do so, but it does seem % to argue for looking at alternatives, even radical ones. % % (ii) ISPs impose restrictions on their customers all the time % and often even enforce them. Many of us consider some of these % to be desirable (e.g., terms and conditions prohibiting % spamming) and others less so (e.g., prohibitions against running % server or peer-peer protocols over a cable network or address % restrictions that force reasonably-architected LANs into NAT % arrangements) but the conditions clearly exist. % % (iii) Yes, if I have an odd address and sufficient money, I can % almost certainly convince some ISP to route it. But that ISP's % leverage to get its peers to accept any long-prefix addresses it % happens to offer and route them may be distinctly limited, % especially if, by offering/announcing those addresses, it is % violating a well-understood policy against doing such things. % (For example, an RIR policy that made PI address allocations % much more difficult for ISPs who were guilty of routing table % pollution by short prefixes could really focus the attention.) % So it seems to me to be plausible to suggest that the right % place to prevent routing table explosion (or even bloat) is in % routing decisions and acceptance of announcements, and not in % creating special address scopes. % % I also note that site local addresses open up a whole series of % questions about locality and scope-range. Perhaps we also % need ISP-local addresses (routing into one ISP's space, or % part of it, but not to that ISP's peers or transit customers) % and so on. The one thing that can be guaranteed about that sort % of arrangement is an extension of the pay enough and someone % will route it model will apply: If some ISP sees a potential % competitive advantage in offering such a product (and % addresses), the product will follow soon thereafter. And, % again, I think that this suggests that we had better figures out % how to deal with these things on a policy basis, not a % protocol-imbedded special address scope one. We are almost % certain to have the policy problem anyway and it is not clear % that special cases for peculiar address scopes will buy us that % much in addition. % %john % % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
% David R. Oran wrote: % % Did anybody consider just handing out a /48 (or a bit smaller) % automagically with each DNS registration? % % I proposed a couple of times a /32 from which /48 can be requested % for 'private' (never to be connected to the internet) purposes. % I think some others have proposed a similar thing. But the opposers % think that it won't be 'free' then... but they will be unique :) Been there, Done it, Bought everything. SRInic was told to split the assignments into a connected/unconnected database back in the day. It was ugly when folks figured that they really wanted to be connected and passed muster. renumbering was less fun in the late 1980s than today. Never want to re-introduce this concept unless/until we can get to the point of being able to painlessly renumber the entire Internet every 20 minutes. Now where are those renumbering in IPv6 is easy cookies. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Bill Manning [mailto:[EMAIL PROTECTED] wrote: % David R. Oran wrote: % % Did anybody consider just handing out a /48 (or a bit smaller) % automagically with each DNS registration? % % I proposed a couple of times a /32 from which /48 can be requested % for 'private' (never to be connected to the internet) purposes. % I think some others have proposed a similar thing. But the opposers % think that it won't be 'free' then... but they will be unique :) Been there, Done it, Bought everything. SRInic was told to split the assignments into a connected/unconnected database back in the day. It was ugly when folks figured that they really wanted to be connected and passed muster. renumbering was less fun in the late 1980s than today. Never want to re-introduce this concept unless/until we can get to the point of being able to painlessly renumber the entire Internet every 20 minutes. That eliminates this 'solution'. History is bound to repeat in these cases. Thus IMHO folks will just need to allocate some random space or get it out some assigned space. Now where are those renumbering in IPv6 is easy cookies. Some other old stories made those crumble also :) The renumbering isn't the part that is difficult, though it's all the configuration items around it that's the burden. Greets, Jeroen
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, 27 Mar 2003 18:29:22 -0600 John Kristoff [EMAIL PROTECTED] wrote: On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote: No, it's more than that. SLs impose burdens on hosts and apps. SLs break the separation of function between apps and the network that is inherent in the end-to-end principle. Is it safe to assume that the arguments (on either side) would also apply to such things as multicast addressing and SCTP path management? I don't think these arguments apply to multicast at all because apps use multicast very differently than unicast, and the considerations about address portability are different. I suspect it does apply to SCTP path management, but I don't know enough about SCTP to be confident of that.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Daniel Senie wrote: SNIP No. It does not imply NAT. It implies traffic to hosts which are used for purposes which do not communicate to the public network. Could we PLEASE leave NAT out of the equation? Not all hosts in the world want or need to be connected outside of the corporate network they belong to. Today such hosts are numbered in RFC 1918 space WITHOUT NAT and are connected to corporate networks. It's likely, given the line of argument you're proposing, that many corporations will just laugh at the IETF, and continue to use IPv4 for their private network space. What you are implying here is that using some $random unroutable address space makes these private hosts secure. Why don't you just use firewalls and configure your routers at the correct places? BTW if a network does IPv6 it will most likely also be doing RA's, how are you going to configure those 1 printers to not be using this RA? Taking into account that DHCPv6 is not completely crystal clear yet. If DHCPv6 where there you would be configuring all your hosts that need to use those printers with site local and global IP addresses. How and foremost *why* should an application differentiate between those addresses? I think at least I won't like the answer... Greets, Jeroen
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Could we PLEASE leave NAT out of the equation? Not all hosts in the world want or need to be connected outside of the corporate network they belong to. true. but they still need unique addresses.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. This is a good sounding story, except that it's never really been true. You could choose to ignore the topology of the network, and ignorance works much of the time. Way back in the dark ages, it was not uncommon to have multi-homed HOSTS: one leg on the ARPANET, the other arm on some local LAN segment. The application and/or network stack on that machine was left with a decision to choose which interface address it ought to use when binding some local association endpoint address. It's easy when the other end is on the same network; e.g., directly attached. The Internet architecture never gave the end system some mechanism to help it make this binding decision when trying to communicate with non-local peers. There are hacks in implementations; like the local resolver having some sorting policy for the A records returned when doing a DNS query, with the assumption that the application was going to try them in turn. But that was just a hack. There was no protocol to ask the network which of address should I use to talk to this remote end system? So here we are today, a couple of decades later, with the promise of a different type of end-system multi-homing (having multiple addresses on a single) interface due to IPv6 multi-provider multihoming with provider specific addresses, and still no means to decide which of the alternatives are preferable when deciding to launch some traffic into the network. Adding one more site-local address doesn't make this problem any harder to solve, I think. louie
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Yes, there was mention of site local as a license to NAT, but there where many other arguments: leakage through IP, DNS or application; the lack of practicality of several restrictive models for site locals; the possibility or not to use other solutions for isolated sites; and the complexity of handling scoped addresses in applications. At the end, the tally shows 20 hands rising in support of site locals, 102 hands rising for their elimination. In short, it was not a hasty discussion, there was an informed debate, opinions evolved during the discussion, and a consensus was reached. This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. How many of your 22 speakers had implementation and deployment experience to report?
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. Well Matt, this may happen in various groups, but the IPv6 WG has been actively debating this issue since Atlanta. I object to the characterization of the discussion as an exchange of handwaves. How many of your 22 speakers had implementation and deployment experience to report? From looking at the names, I would say at least 18. I suggest that this discussion resumes on the IPv6 mail list after the minutes are published. -- Christian Huitema
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, Mar 27, 2003 at 06:51:01PM -0500, Keith Moore wrote: I suspect that most people there, who voted for the elimination of site-locals, would still be favor of enabling the features that site-locals were intended to offer. Perhaps the majority position could be paraphrased as against site-local, but sorry to see them go. I agree. I think there was a general understanding that we need to provide the capabilities that SLs were supposed to provide, but to do so in other ways. Agree absolutely. Erik made good points in SFO about desirable addressing properties for customer networks (e.g. stable addressing). That is one side of the issue. The ipng list should be identifying the scenarios where networks require addressing that would have otherwise have been supplied by site-locals, and present viable alternatives. For example, manets, intermittently connected networks, and community networks with partial yet varied uplinks. If these can be addressed (sic), then I think objections will diminuish. As a side-note, a fifth SL option was presented out of the blue in SFO, namely exclusive SL/global addressing (one or the other only), which, because it was rather a broken idea, I think perhaps added to the room sentiment that site-locals are broken (rightly or wrongly :) Tim
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
At 03:49 PM 3/27/2003 -0800, Tony Hain wrote: Margaret Wasserman wrote: No active IPv6 WG participant (whether or not he attends IETF meetings) could credibly claim that he was unaware that this discussion was taking place, The discussion has been about potential usage limitation, or BCP's identifying application issues. The point of deprecation came out of nowhere, and only occurred in the room in SF. This has not had valid discussion. There have been people calling for the complete removal of site-local addressing all along. And, elimination/deprecation was quite clearly raised as an option in Atlanta. At that time, we called for opinions on the following options: elimination, limited, moderate or full usage, and each of the four options had some support in that WG meeting. Margaret
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Margaret Wasserman wrote: There have been people calling for the complete removal of site-local addressing all along. And, elimination/deprecation was quite clearly raised as an option in Atlanta. At that time, we called for opinions on the following options: elimination, limited, moderate or full usage, and each of the four options had some support in that WG meeting. And in Atlanta we all agreed to take elimination off the list, and it has not been discussed since. The agenda for SF was: Site-Local Addressing Impact of site-local addressing -- Margaret Wasserman (20 min) http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx t Limited Usage Summary -- Margaret Wasserman (5 min) [See appendix of draft-wasserman-ipv6-sl-impact-02, above.] Moderate Usage Proposal -- Bob Hinden (15 min) http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-01.txt Nowhere in that or the mail preceding the meeting is elimination mentioned. Tony
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Hi Tony, I am not sure what your point is exactly, or why you want to make this point on the full IETF list... Are you suggesting that the options open to the IPv6 WG should be constrained by the drafts that Bob and I list on the agenda? By Thursday, the agenda had actually changed to a joint presentation by me and Bob on the trade-offs between different site-local usage options. We also had a discussion section listed (on both the published and final agendas) that you omitted, and during that discussion the WG members in the room chose to reject the recommendations that Bob and I had made, and they chose to deprecate site local addresses. Frankly, I was as surprised as you were. Like all consensus reached in WG meetings, this consensus _will_ be confirmed on the list. You will get your chance to express your opinion there. You have your chance, right now, to make any arguments on the list that you think will persuade people not to deprecate site-local addresses. Unless you think that there is an issue here that is of wider IETF interest, perhaps we could move this discussion to the IPv6 WG mailing list? Margaret At 05:26 PM 3/27/2003 -0800, Tony Hain wrote: Margaret Wasserman wrote: There have been people calling for the complete removal of site-local addressing all along. And, elimination/deprecation was quite clearly raised as an option in Atlanta. At that time, we called for opinions on the following options: elimination, limited, moderate or full usage, and each of the four options had some support in that WG meeting. And in Atlanta we all agreed to take elimination off the list, and it has not been discussed since. The agenda for SF was: Site-Local Addressing Impact of site-local addressing -- Margaret Wasserman (20 min) http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx t Limited Usage Summary -- Margaret Wasserman (5 min) [See appendix of draft-wasserman-ipv6-sl-impact-02, above.] Moderate Usage Proposal -- Bob Hinden (15 min) http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-01.txt Nowhere in that or the mail preceding the meeting is elimination mentioned. Tony
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted, Ted Hardie wrote: I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. Michel Py wrote: Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. Ted Hardie wrote: I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Does not work if you change providers and your former provider allocates this address space to someone else; the space then ceases to be globally unique. See below for a detailed technical case scenario. The collision risk is way too high. Here's the topology. Replace SL addr with non-routed globally unique space if you wish; talking about which you could also have a look at this: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt (disclaimer: unpublished unfinished text, but it's not like I never thought about it before). I used this topo before as an example of a utility company that has IP-enabled control devices. This is a fairly common topology. Global Addresses -- SL addr -- +-+ | ISP |: +--+--+: ! : +--+-+ +--+ +--+ +--+ | Router A : +--| Firewall+--+--| Firewall+--+--+ Router B +---+ ++ +--+ | +--+ | +--+ | : || | : +---+--+ +--+---++++ : | DFZ | | Host || Control | : | Host | +--+| Device | : +--+ +-+ ---Site --:-- Site - : - Router A is the SBR. - DFZ hosts need to be able to talk to hosts between the internal firewall and router B, but not to the control devices. - DFZ hosts need to be able to talk to the outside. - Hosts between the internal firewall and router B need to be able to talk to everybody. - Control devices are accessible only from hosts between the internal firewall and router B. The name of the game here is not renumbering the control devices if the ISP changes. There can be scores of them; this is not even open to discussion. Even NATv6 will be chosen over renumbering if need be and this includes developing the NATv6 code in-house if required. Argument heard a thousand times: You don't care about the prefix you use for these because it's not routable. Rebuttal given a thousand times: Wrong. You do route this prefix inside the site. If the prefix is being used both inside and outside you're SOL as hosts between the internal firewall and router B won't be able to talk to both. What is the risk? A LIR gets a /32, a site gets a /48. That's 64k sites per LIR at most. On a large LIR, the collision risk might be 1/3 or 1/4, not the kind of chance I take. OTOH, if I use a random /48 out of a private /24 block, the collision risk to the outside is zero and the collision risk if I have to merge with another site is 1 out of 16 Million (2^24) and this is the kind of odds I'm willing to take. I would prefer site-locals as it's a /10 that can make the collision risk for site mergers zero, but I'd deal with a /24. PA re-used addresses just don't cut it. Are you concerned that doing so has some impact on the routing system that needs to be considered? No. I am concerned about impacts on the routing system but this is an unrelated issue. Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. This is irrelevant. Let's look at the situation: - You want to deprecate site-locals. - What does it cost me? Nothing. If SLs go away I can hijack any prefix of my own choosing to replace them, these days I have my eyes on a hole in the 6to4 space: 2002:0A00::/24. - What can you do about me hijacking a prefix? Nothing. - What do I gain: Actually, hijacking is more flexible than the exclusive model that Bob and Margaret have compromised on (I support it for the sake of compromise not because I like it). Someone said that a compromise is something that pleases no one, and to this regard the exclusive model is a very good one. - What problems have we (as engineers) solved by having me hijack a prefix instead of using site-locals? None. We have put an embarrassing issue under the carpet for now. - What is the impact for app developers that
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Michel, What you say is possible, and has happened. But dumb things happen. Those dumb things could happen with non site-local addresses as well. But look. Ultimately I think we as a community do need to own up to better tooling, which can lead to better expectations. Also, I don't see any reason why an IP v6 prefix allocation can't linger for a very long time after a contract ends. The tools need to set expectations, and perhaps some of the DHCP prefix delegation code can help here. Regards, Eliot
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. uh, no. 102 people finally understood just how comprehensively broken SLs are, and managed to finally overwhelm the 20 or so who were still in compete denial about it. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Hello folks, I was there, and it wasn't so black and white. It's not fair to characterize it so. I suspect that most people there, who voted for the elimination of site-locals, would still be favor of enabling the features that site-locals were intended to offer. Perhaps the majority position could be paraphrased as against site-local, but sorry to see them go. My own vote was for elimination, but I think it will be a mistake if there isn't a way for people to get unique prefixes practically for free. Regards, Charlie P. Keith Moore wrote: This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. uh, no. 102 people finally understood just how comprehensively broken SLs are, and managed to finally overwhelm the 20 or so who were still in compete denial about it. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
You are mixing cause and effect. In IPv4 the vast majority of nodes are limited to a single address at a time. Well, I don't know about windows boxes, but real operating systems have supported virtual hosting in IPv4 for many years. Having multiple addresses on a node, even a node with a single network interface, is nothing new. Network managers that want some of their nodes in private space find it simpler to also put the nodes with public access in the same space rather than deploy multiple subnets to each office and route between them. There are easier ways to solve the problem than having multiple subnets, that doesn't require use of SL. Any bit in the address can be used for filtering, it doesn't have to be in the subnet mask. During the IPV6 meeting in SF, we did discuss several options for limiting the use of site-local addressing, but all of those options had some sorts of problems associated with them. So rather than address any problems, the needs of the (mostly absent) network managers were simply dismissed as irrelevant. Nope. The problems couldn't be solved. The group responsibly decided to fix the architecture by deprecating site locals and to solve the network managers' problems in other ways, because the solutions to the network managers' problems without SLs are simpler than the solutions to everyone's problems with SLs. (especially because the latter do not exist) Site-local is nothing more than a well-known prefix for filtering. No, it's more than that. SLs impose burdens on hosts and apps. SLs break the separation of function between apps and the network that is inherent in the end-to-end principle. (2) RFC 1918 addresses are most commonly used behind NATs. In this case, there is a middle box that performs translation of those addresses into global addresses at the site boundary, both in IP headers and at the application layer (through ALGs). In IPv6, we hope to avoid NAT. Site-local addresses were expected to be used on globally connected networks without any translation. Why do you continue to equate SL with NAT? Why do you continue to accuse people of equating SL with NAT even when they carefully explain just how they are similar and how they are different? It doesn't require address selection rules or ALG's. The only way an application should receive a record with a SL is if it is in the same address zone as the target. Standardizing split DNS is both insufficient and unacceptable. What we should not do is stick our heads in the sand and believe that simply because we don't want to have limited scope addresses they will magically disappear. What we should not do is stick our heads in the sand and believe that simply because some sites will have limited scope addresses that it's okay to burden hosts, DNS, routing, and large numbers of applications with having to deal with them. Rather than force people to create a bunch of ad-hoc solutions to the problem, we should in fact provide an architected approach that creates a level of consistency (actually we have, but some want to see it deprecated). Actually we are working toward an architecture that provides a level of consistency. But this requires that we deprecate SL. Exactly. There are many of these applications defined within the IETF, by other standards bodies, and/or developed by private enterprises. In fact, the applications area folks assure me that there are more of these types of applications deployed than there are simple client- server applications (that was news to me). IETF applications that fall into this category include FTP, SIP and (in some uses) HTTP. And they will continue to fail when the network administrator puts in routing filters, only nobody will be able to figure it out because we removed the hint of a well-known prefix. No, it will be easy to figure out, because it will be clear that the network administrator is to blame, unlike the current situation with where the app vendor is blamed for the problems caused by the NAT. This moves the problem to a place where it's more easily fixed. This is a huge improvement. Maybe... There has been a great deal of reticence from application developers to rely on DNS look-ups for this type of referral, and it is not all based on DNS reliability. There are many, many nodes that either do not have a DNS entry or do not know their own DNS name, and many applications need to work on those nodes. Rather than fix the problem, shoot the feature that exposes it ... Rather than fix the problem, force another broken layer on every app. It won't solve anything but it will provide another layer of delay, complexity, and unreliability. The network will be even less functional than it is today, but at least we'll have something to blame it on. The borders exist. Either we create a tool that allows people to easily manage which nodes are on
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
You are mixing cause and effect. In IPv4 the vast majority of nodes are limited to a single address at a time. Well, I don't know about windows boxes, but real operating systems have supported virtual hosting in IPv4 for many years. Having multiple addresses on a node, even a node with a single network interface, is nothing new. My Windows-XP laptop currently has 14 IPv6 addresses, and 2 IPv4 addresses. The sky is not falling. -- Christian Huitema
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
And in Atlanta we all agreed to take elimination off the list, and it has not been discussed since. what's changed is that we had a chance to look at various ways of limiting usage of SL, and found that none of them would make SLs tolerable.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
As a side-note, a fifth SL option was presented out of the blue in SFO, namely exclusive SL/global addressing (one or the other only), which, because it was rather a broken idea, I think perhaps added to the room sentiment that site-locals are broken (rightly or wrongly :) well, it was something that hadn't been suggested yet, so I don't blame them for trying. but what became clear after looking at all of the different ways of limiting usage of site local side-by-side is that every way of restricting site locals still leaves us with a mess. the only set of restrictions that avoids leakage and/or requiring apps to be aware of network topology is to use SLs only on isolated networks, and experience with RFC 1918 strongly indicates that this doesn't work well in practice.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted Hardie wrote: There is a long and interesting history here, but it isn't directly relevant to this discussion. I think it would be valuable to focus the discussion on Site Local, rather than on RFC 1918 space. The reason for bring 1918 into the discussion is that prior to NAT, there was a market demand for private address space. That demand hasn't gone away, and the non-NAT users of that space are completely disenfranchised in this discussion because they have seen no need to worry about it given there is a comparable space defined for IPv6. I think you may underestimate how much trouble this might cause in applications. As Dave Crocker noted in response to Margaret Wasserman's presentation to the APPs Open Area meeting, applications have been designed so that they do not know and don't need to know anything about network topology. If you require applications to understand the consequences of different unicast address scopes, you are changing a pretty fundamental assumption. While it is theoretically possible to change that assumption, it is a major piece of work, and I believe that the sense of the room was that the advantages of Site Local were not worth that amount of work. I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. This doesn't sound like rocket science, and the arguments against it are coming across like 'we don't want to change because it is too much work'. Rather than argue that nobody can ever use a new feature, the basic approach should be that you don't have to unless you want to. As you note, this is subject to discussion and confirmation on the mailing list and, ultimately, to the consensus of the IETF as a whole. And it has yet to be formally raised by the chairs on the WG list, so if it gets to IETF last call, it will be ripe for an appeal. Tony Margaret's presentation, for those not at the APPs open area, was derived from her draft, found at http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact- 02.txt. See especially section 3.7.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Wed, 2003-03-26 at 16:38, Tony Hain wrote: Ted Hardie wrote: I think you may underestimate how much trouble this might cause in applications. As Dave Crocker noted in response to Margaret Wasserman's presentation to the APPs Open Area meeting, applications have been designed so that they do not know and don't need to know anything about network topology. If you require applications to understand the consequences of different unicast address scopes, you are changing a pretty fundamental assumption. While it is theoretically possible to change that assumption, it is a major piece of work, and I believe that the sense of the room was that the advantages of Site Local were not worth that amount of work. I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. This doesn't sound like rocket science, and the arguments against it are coming across like 'we don't want to change because it is too much work'. Rather than argue that nobody can ever use a new feature, the basic approach should be that you don't have to unless you want to. Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. -MM
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
At 1:38 PM -0800 3/26/03, Tony Hain wrote: I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. Those two sentences don't line up. Either things that use addresses need to know about network topology, or they don't. And it's not just applications. Security services like IPsec are also equally affected by having to know that ah, I'm actually doing something site local, so I need to prompt the operator for a prefix and then use that prefix in many places in my security logic. It's not just an API question. --Paul Hoffman, Director --VPN Consortium
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Michael Mealling wrote: Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. You really don't want to go there, since it is in fact the violation of the layering by the apps that has created some of the mobility and renumbering challenges. Apps know all too much about what is going on below them, which is why the app developer sees any change as a lot of work. Tony
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Wednesday, March 26, 2003, at 01:38 PM, Tony Hain wrote: Ted Hardie wrote: There is a long and interesting history here, but it isn't directly relevant to this discussion. I think it would be valuable to focus the discussion on Site Local, rather than on RFC 1918 space. The reason for bring 1918 into the discussion is that prior to NAT, there was a market demand for private address space. That demand hasn't gone away, and the non-NAT users of that space are completely disenfranchised in this discussion because they have seen no need to worry about it given there is a comparable space defined for IPv6. I'm not sure I agree that there was ever a non-scarcity induced market demand for private address space in the pre-RFC 1918 days, but I'll concede it for the sake of argument. I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. If the market demand is for something else, then I'd appreciate a concise statement of what it is. I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. This doesn't sound like rocket science, and the arguments against it are coming across like 'we don't want to change because it is too much work'. Rather than argue that nobody can ever use a new feature, the basic approach should be that you don't have to unless you want to. I'm sorry that the arguments against it are coming across like we don't want to change because it is too much work. That is certainly a part of the reaction, but the underlying reason is actually that the model doesn't fit the Internet architecture as the apps understand it. As I tried to note in my first response, I agree that it is possible to *change* the assumptions about the app's layer knowledge of topology, but the reasons given for the need seem remarkably weak in the light of such a basic change. To put it bluntly, this is not a new feature that requires a tweak to some ur-API. This change requires apps to understand address scope, and to understand it in a totally new way. Again, I urge folks following the discussion to read Margaret's draft. regards, Ted Hardie Margaret's presentation, for those not at the APPs open area, was derived from her draft, found at http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact- 02.txt. See especially section 3.7.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted Hardie wrote: I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. Michel.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted On Wednesday, March 26, 2003, at 03:51 PM, Michel Py wrote: Ted Hardie wrote: I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. Michel.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted, What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Hi David, Provider of what? Note that if a provider of address space is not routing the addresses involved, they have few or no performance responsibilities in the arena. They don't even need to polish and regrind the digits periodically; they just go. It seems unlikely to me personally that you would change providers for performance reasons. Back to money. If you are getting a slice of the globally unique address space from someone to whom it has been delegated, you may pay them for the privilege. Those fees could go up, and in that case, a network might decide to renumber into a cheaper provider's space to avoid costs. Given that they are all derived from the same sources and the lack of scarcity in the resource, though, its hard to see this as a major problem, unless scarcity is created artificially. That would be a matter for policy debate with the allocating agencies, though, not the IETF. If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. regards, Ted On Wednesday, March 26, 2003, at 04:32 PM, David Conrad wrote: Ted, What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
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
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Wednesday, March 26, 2003, at 05:40 PM, David Conrad wrote: Ted, On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote: If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. Which, of course, implies NAT (where's there's pain, there's NAT? :-)). Anyhow, this is the wrong list for this discussion... Rgds, -drc where there's pain, there's NAT--are you sure you have these in the right order? :^) I'll respond further by private email, as I agree that we're now a bit far afield of the IETF main list's normal function. Ted
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Or what if there is no provider (as in default addresses used by a software vendor)? -andy David Conrad wrote: Ted, What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
From the reading of the draft, it would appear that much of the pain for applications with SL is caused because the apps violated the contract. Actually, its a wonder any of these would work in v6 at all given the description of the problem (address leaks). -andy Michael Mealling wrote: Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. -MM
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
At 08:40 PM 3/26/2003, David Conrad wrote: Ted, On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote: If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. Which, of course, implies NAT (where's there's pain, there's NAT? :-)). No. It does not imply NAT. It implies traffic to hosts which are used for purposes which do not communicate to the public network. Could we PLEASE leave NAT out of the equation? Not all hosts in the world want or need to be connected outside of the corporate network they belong to. Today such hosts are numbered in RFC 1918 space WITHOUT NAT and are connected to corporate networks. It's likely, given the line of argument you're proposing, that many corporations will just laugh at the IETF, and continue to use IPv4 for their private network space.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Tony, The specifics of the site local issue should be debated on the IPv6 WG list, not on the global IETF list. Let me however respond to your point regarding the quality of the debate, as I was the note taker during that session. My notes record that 22 separate speakers took part to this debate, some coming to the microphone several time. It is also pretty clear from my notes that the consensus of the room is evolving as the discussion progresses, and as arguments are being exchange. Yes, there was mention of site local as a license to NAT, but there where many other arguments: leakage through IP, DNS or application; the lack of practicality of several restrictive models for site locals; the possibility or not to use other solutions for isolated sites; and the complexity of handling scoped addresses in applications. At the end, the tally shows 20 hands rising in support of site locals, 102 hands rising for their elimination. In short, it was not a hasty discussion, there was an informed debate, opinions evolved during the discussion, and a consensus was reached. I believe that if you had been in the room you would feel closer to that consensus. -- Christian Huitema
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Thus spake Christian Huitema [EMAIL PROTECTED] The specifics of the site local issue should be debated on the IPv6 WG list, not on the global IETF list. Let me however respond to your point regarding the quality of the debate, as I was the note taker during that session. Issues most often move to the IETF list when a vocal minority object to a declaration of consensus by the WG chairs. If the WG chair would like to reopen the debate, I'm sure everyone will move back there. In short, it was not a hasty discussion, there was an informed debate, opinions evolved during the discussion, and a consensus was reached. I believe that if you had been in the room you would feel closer to that consensus. I haven't seen anyone argue in favor of site-local addressing for the purposes of having explicitly scoped addresses, so you are correct in one sense. What I am seeing is debate over private address space and NAT, which many of us had expected site-locals to be useful for -- this email thread (and the one on routing-discussion) belies any claims of consensus on that. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
--On onsdag, mars 26, 2003 17:40:23 -0800 David Conrad [EMAIL PROTECTED] wrote: Ted, On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote: If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. Which, of course, implies NAT (where's there's pain, there's NAT? :-)). the more general aphorism is probably where there's pain people want painkillers painkillers don't cure the cause of pain painkillers have side effects not that this helps evaluate the issue (much); my personal take (which is largely irrelevant to this list) is that IPv6 applications will be cheaper and simpler when the code does not have to treat some addresses differently from others; the fewer special cases, the better. Special cases are pain; in this case, we were able to eliminate one source of this pain. In my opinion, of course. Harald
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
The reason for bring 1918 into the discussion is that prior to NAT, there was a market demand for private address space. sometimes the market is misled by vendors who want to sell planned obsolesence. NAT is the perfect example.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
since it is in fact the violation of the layering by the apps that has created some of the mobility and renumbering challenges. uh, no. DNS is not a layer. it is a naming service. it's not the only way that an app can get an IP address, and never has been.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ignoring the format of addresses has worked well for 1918 addresses (loathsome as they might be) because the assumption is that filtering (so that they don't leak onto the public network) is the responsibility of anything that connects a 1918 network to the public Internet. but this assumption proved to be a false one. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
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). for multiparty apps, the probability that this will happen is within epsilon of 1. If one believes that a split-DNS is reasonable to build and deploy (since many exist it seems self evident) no. there are lots of unreasonable things in this world. split DNS is a hack that works only in limited situations, and even then it doesn't work well. it makes assumptions about application behavior that are not valid. , then an application should only see a SL in a DNS response if the query originates in the same private address region. DNS is irrelevant. you can't fix SLs by fixing DNS, even if you could fix DNS, which you can't. it's not reasonable for a DNS server to assume that the party making the query is the party that will use the address. actually DNS caching depends on DNS producing consistent results no matter who is making the query, and DNS caching is not don't exclusively by DNS servers. This again will work fine bzzzt. wrong again. The place SL starts to have trouble is when a multi-party app does referrals based on obtained addresses rather than names. which is a perfectly reasonable thing to do. it's how the Internet was designed to work. 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. there are far better ways to solve that problem than by crippling apps. We need to get past the arguments that private space == nat, no that's not the problem. the problem is that scoped addresses are dysfunctional. NAT has nothing to do with it.
