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
Thinking differently about the site local problem (was:RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Tony, I've been trying to get my mind around the various issues here, and I keep getting back to the same place, so I think I need to embarrass myself by making a proposal that I find frightening. Let's assume, as I think you have suggested, that SL is all about local addresses and filtering, and not about some special prefix that applications need to recognize. I'm still not sure I believe that, but let's assume it is true and see where that takes us. Let's also remember the long path that got us to CIDR and 1918. Our original position was that anyone using TCP/IP (v4) should have unique address space. I remember many discussions in which people were told don't just grab an address on the theory that you would never connect. Our experience has been that, sooner or later, you might connect to the public network, or connect to someone else who has used 'private' (or 'squatter') space... unique addresses will save you, and everyone else, a lot of trouble. In that context, 1918 and its predecessors came out of two threads of developments: * we were running short of addresses and wanted to discourage unconnected (or hidden) networks from using up public space and * we hoped that, by encouraging such isolated networks to use some specific address ranges, those ranges could be easily and effectively filtered at the boundaries. We can debate how well either really worked, or what nasty side-effects they caused, but probably it makes little difference in the last analysis except to note that, no matter what we do, leaks happen. Now one of the problems IPv6 was supposed to solve was too little address space or, more specifically, our having to make architecturally bad decisions on the basis of address space exhaustion. I hope we have solved it. If we haven't, i.e., if the address space is still too small, then the time to deal with that issue is right now (or sooner), before IPv6 is more broadly deployed (and it better be variable-length the next time, because, if we are conceptually running short of space already, it would be, IMO, conclusive proof that we have no idea how to specify X in X addresses will be enough). 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/...)? Of course, this takes us fairly far onto the path of having to think about multihomed hosts, not just multihomed LANs, but, as others have pointed out, the notion of multiple addresses (or multiple prefixes) for a given host (or interface) takes us rather far down that path anyway. Figuring out which address to use is a problem we need to solve, with or without SL, or the whole idea of multiple addresses on hosts, especially dumb hosts, is going to turn out to be a non-starter. And, as Louis, Noel, and others have pointed out, it is hard. But, if we can find a solution, even one that is just mostly locally-optimal and that fails occasionally, then it seems to me that your position ultimately gives no advantages to a reserved site-local form over unique, but non-routable, addresses. The advantages of the latter appear obvious, starting with being able to identify the sources of address leaks and the notion that routability is a separate negotiation with providers (and their peers and other customers) and not an RIR responsibility. That would leave another topic which I consider separate: whether we ought to create some number of 1918-like addresses that organizations that are really isolated (not connected even with other prefixes) can use without needing to have a negotiation with an RIR. The answer, I think, is probably yes, but it really is a policy question, not a technical one. And, on the above model, an ISP offering service (and prefixes) to an enterprise could be expected to insist that the enterprise not be using any of those isolated addresses in their local environment. I obviously don't understand all of the issues here well enough. But the traffic of the last few days has left me with the strong impression that SL may be an answer to the wrong question. If so, is the suggestion above closer to the right question? And, unfortunately, since this approach involves a change in the advice the IETF gives the RIRs, it probably does belong on the IETF list and not that of a WG. regards, john
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...))
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. that's because (a) customers demand that apps work even in the presence of NAT, no matter how unreasonable this is, and (b) the way most filters are implemented, there's no good way for an app to tell whether a communications failure is due to a network or host failure or to a prohibition. ICMP is the only mechanism we have to do this, and it's not widely used. 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. ICMP may be routinely ignored, but on false premises. ICMP is no less secure than anything else in TCP or IP that is routinely trusted. 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'd claim that ICMP prohibited is another case for giving up. note that a 4xx error is an explicit it's okay to retry indication. Keith
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: sitelocal addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore wrote: site locals do not provide a well known flag because an application has no idea about the site boundary, Or boundaries: consider a private LAN where one part is firewalled from other parts of the same site. The single flag this address is site-local cannot mark that boundary. -- /\ |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...))
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...))
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. even when you need to do a DNS lookup, getaddrinfo() doesn't always do what you need. Keith
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 theInterNAT...))
Margaret, I can't disagree with any of this. As others have pointed out, most of these problems can, and regularly have, occurred when RFC1918 addresses are used in networks that are also connected to the public Internet and when private 1918 networks are interconnected. NATs can be used to solve some of the problems while introducing other problems of their own. And, with IPv6, the potential of having several addresses associated with each of those hosts, some SL and some public, would seem to increase the overall complexity. All of that is complicated by our not really knowing how to define site (or address-scopes more generally) in many situations in which enterprise subnets are nested within other enterprise subnets, sometimes several layers deep, before the packets emerge into an environment that is unambiguously public Internet. I also find Dave Crocker's argument about what applications can and cannot be expected to do, and some other correspondence today, immensely persuasive: if we want applications to start shuffling around addresses, and having knowledge about which ones represent what sorts of locality, we are going to need some fairly major changes to TCP and/or ICMP. There are some economic issues involved as well: if we make it significantly more complex to create applications that work acceptably well, we will reduce one of the factors --the ability to rapidly develop and deploy new applications-- that has contributed significantly to the growth of the Internet. If IPv4 offers that characteristic, and IPv6 does not, or does so even slightly less well, it will bias decision-makers strongly against IPv6 deployment. All of those things are excellent reasons for getting rid of SL and relying on unique addresses. At the same time, there seems to be ample reason for spaces that are scoped as private or local by filtering. One example is transparency of internal networking and connectivity to external prefix changes, another is outlined below, and I think there are many more. Consequently the other thing that has become clear to me over the last several days is that, if we are not going to have SL, or something else 1918-like, we need to be able to allocate unique blocks of addresses for private use. It seems to me that we don't have a plan for doing that. The RIR plans for IPv6 allocations appear to focus on the IPv4 distinction between PI and PD space and on very large blocks and intensive justifications for PI space. In the current IPv4 environment, if I go to my local ISP and say I'm going to have a really smart house, and I need an IP address for every light socket in addition to the dozen or so I need for traditional hosts, even thought the light sockets won't be exposed to the public network, the ISP will laugh. Part of that laughter will come from technologically-odd business reasons such as the desire to sell me an entirely different (and more) expensive type of connection if I really need more than one address. But part of it will come because they know that they had better not go back to their RIR, looking for more space, and presenting a model that justifies an additional allocation on the basis of thousands of electrical fixtures that are not accessed directly from the public network and that, indeed, are firewalled off from it by devices that authenticate commands from the outside and filter out traffic to or from the fixtures themselves. As far as I can tell, the announced RIR policies toward IPv6 allocations are basically the same as the IPv4 ones: my ISP is going to have no incentive, and considerable disincentive, to give me large blocks of addresses that won't be routed onto the network. And the ISP is probably the wrong answer anyway. If one of my reasons for wanting internal address space is to make communications within my LAN robust against changes imposed by the ISP, or changes of ISP, then having space that the ISP has the right (obligation?) to take back doesn't help. So, it seems to me that, while drop SL is desirable, it only half-solves the problem and might create a worse one unless the other half-problem is solved. It seems incumbent on those who want to get rid of SL to propose some rational scheme, one which can be administered at reasonable costs and bureaucracy levels, for allocating blocks of private-use unique addresses. If we don't solve that problem, but still take out SL, we will arguably be encouraging people to squat on random addresses and hope they can keep them from leaking and that they never conflict with real addresses they want to reach. And address-squatting for private use is probably the worst of all of the possibilities --been there, tried that, got killed by it. Thanks to the several people whose (mostly off-lists) notes have helped to clarify my thinking about this. regards, john --On Monday, 31 March, 2003 16:08 -0500 Margaret Wasserman
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
Hello,ietf,japanese girl VS playboy
Content-Type: application/octet-stream; name=d_first[1].htm Content-Transfer-Encoding: base64 Content-ID: Z400S931Z3t PGh0bWw+CjxoZWFkPgo8dGl0bGU+RElTSCBOZXR3b3JrIEZpcnN0IFRpbWUgU3Vic2NyaWJl cjwvdGl0bGU+CjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iU2hvcFNpdGUgUHJv IDYuMC4zIFBhZ2UgTGlua3MgRG93biBMZWZ0IFNpZGUgLUMgY29kZSI+CjwvaGVhZD4KPGJv ZHkgIGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGxpbms9IiMwMDAwODAiIHZs aW5rPSIjODAwMDgwIiBhbGluaz0iIzY2NjY2NiIgPgo8Ym9keSB0b3BtYXJnaW49IjAiPgo8 ZGl2IGFsaWduPSJjZW50ZXIiPgogICAgPGNlbnRlcj4KCiAgPHRhYmxlIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNzQ0Ij4KICAgIDx0cj4K ICAgICAgPHRkIHdpZHRoPSIxMDAlIj48aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vc2t5 dmlzaW9uLmNvbS9zdG9yZS9tZWRpYS9za3liYW5uZXJfMi5qcGciIHdpZHRoPSI3NDQiIGhl aWdodD0iOTMiPjwvdGQ+CiAgICA8L3RyPgogIDwvdGFibGU+CiAgICA8L2NlbnRlcj4KICA8 L2Rpdj4KICA8ZGl2IGFsaWduPSJjZW50ZXIiPgogICAgPGNlbnRlcj4KICA8dGFibGUgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI3NDQiIGJn Y29sb3I9IiMwMDQwODAiIGhlaWdodD0iMjQiPgogICAgPHRyPgogICAgICA8dGQgd2lkdGg9 Ijc2Ij4KICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj4KICAgICAgICA8c3Ryb25nPjxhIGhy ZWY9Imh0dHA6Ly9za3l2aXNpb24uY29tL2luZGV4Lmh0bWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZGRkZGIj48L2ZvbnQ+PC9hPjxhIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmUiIGhyZWY9Imh0dHA6Ly9za3l2aXNpb24uY29t L2luZGV4Lmh0bWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNv bG9yPSIjRkZGRkZGIj5Ib21lPC9mb250PjwvYT48L3N0cm9uZz4KICAgICAgPC90ZD4KICAg ICAgPHRkIHdpZHRoPSIxMTUiPgogICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPgogICAgICAg IDxzdHJvbmc+PGEgaHJlZj0iaHR0cDovL3NreXZpc2lvbi5jb20vZm9ybXMvY2F0YWxvZ19y ZXF1ZXN0cy5odG1sIiBzdHlsZT0iVEVYVC1kZWNvcmF0aW9uOiBub25lIiB0YXJnZXQ9Il9i bGFuayI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSIgY29sb3I9IiNG RkZGRkYiPkZyZWUKICAgICAgICBDYXRhbG9nPC9mb250PjwvYT48L3N0cm9uZz4KICAgICAg PC90ZD4KICAgICAgPHRkIHdpZHRoPSIxMTUiPgogICAgICAgIDxwIGFsaWduPSJjZW50ZXIi PjxzdHJvbmc+PGEgaHJlZj0iaHR0cDovL3NreXZpc2lvbi5jb20vY2dpLWJpbi9zaG9wc2l0 ZS9zYy9vcmRlci5jZ2k/c3RvcmVpZD1za3l2aXNpb24mYW1wO2Z1bmN0aW9uPXNob3ciIHN0 eWxlPSJURVhULWRlY29yYXRpb246IG5vbmUiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFs LCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZGRkZGIj5SZXZpZXcKICAgICAgICBPcmRlcjwvZm9u dD48L2E+PC9zdHJvbmc+CiAgICAgIDwvdGQ+CiAgICAgIDx0ZCB3aWR0aD0iMTI4Ij4KICAg ICAgICA8cCBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxhIGhyZWY9Imh0dHA6Ly9za3l2aXNp b24uY29tL2Zvcm1zL3pjb250YWN0Lmh0bWwiIHN0eWxlPSJURVhULWRlY29yYXRpb246IG5v bmUiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZG RkZGIj5Db250YWN0CiAgICAgICAgVXM8L2ZvbnQ+PC9hPjwvc3Ryb25nPgogICAgICA8L3Rk PgogICAgICA8dGQgd2lkdGg9IjEzNyI+CiAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PHN0 cm9uZz48YSBocmVmPSJodHRwOi8vc2t5dmlzaW9uLmNvbS9mb3Jtcy9jdXN0b21lcl9zZXJ2 aWNlLmh0bWwiIHN0eWxlPSJURVhULWRlY29yYXRpb246IG5vbmUiPjxmb250IHNpemU9IjIi IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZGRkZGIj5DdXN0b21lcgogICAg ICAgIFNlcnZpY2U8L2ZvbnQ+PC9hPjwvc3Ryb25nPgogICAgICA8L3RkPgogICAgICA8dGQg d2lkdGg9Ijg2Ij4KICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxhIGhyZWY9 Imh0dHA6Ly9za3l2aXNpb24uY29tL3N0b3JlL3NlYXJjaC5odG1sIiBzdHlsZT0iVEVYVC1k ZWNvcmF0aW9uOiBub25lIj48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNh IiBjb2xvcj0iI0ZGRkZGRiI+U2VhcmNoPC9mb250PjwvYT48L3N0cm9uZz4KICAgICAgPC90 ZD4KICAgICAgPHRkIHdpZHRoPSI4MSI+CiAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PHN0 cm9uZz48YSBocmVmPSJKYXZhU2NyaXB0Omhpc3RvcnkuYmFjaygxKSIKc3R5bGU9InRleHQt ZGVjb3JhdGlvbjogbm9uZSI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSIgY29sb3I9IiNGRkZGRkYiPkJhY2s8L2ZvbnQ+PC9hPjwvc3Ryb25nPgogICAgICA8L3Rk PgogICAgPC90cj4KICA8L3RhYmxlPgoKICAgIDwvY2VudGVyPgogIDwvZGl2PgoKCgoKPHRh YmxlPjx0cj48dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSIxMjUiPiAKPHRhYmxlPgo8dHI+Cjx0 ZCB2YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8 YSBocmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUvc2t5c3RvcmVpbmRleC5o dG1sIj4gPGI+PHNtYWxsPlNreXZpc2lvbiBTdG9yZSBJbmRleDwvc21hbGw+PC9iPjwvYT48 YnIgY2xlYXI9YWxsPgo8L3RkPgo8L3RyPgo8dHI+Cjx0ZCB2YWxpZ249InRvcCIgYWxpZ249 ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8YSBocmVmPSJodHRwOi8vd3d3LnNr eXZpc2lvbi5jb20vc3RvcmUvc2VhcmNoLmh0bWwiPiA8Yj48c21hbGw+U2VhcmNoIHRoZSBT dG9yZTwvc21hbGw+PC9iPjwvYT48YnIgY2xlYXI9YWxsPgo8L3RkPgo8L3RyPgo8dHI+Cjx0 ZCB2YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8 YSBocmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUvZGJzaG9tZS5odG1sIj4g PGI+PHNtYWxsPkRCUyBTdG9yZTwvc21hbGw+PC9iPjwvYT48YnIgY2xlYXI9YWxsPgo8L3Rk Pgo8L3RyPgo8dHI+Cjx0ZCB2YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAl Ij4KJm5ic3A7PEJSPgo8YSBocmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUv ZF9kaXNobmV0X3N5c3RlbXMuaHRtbCI+IDxiPjxzbWFsbD5ESVNIIE5ldHdvcmsgU3lzdGVt czwvc21hbGw+PC9iPjwvYT48YnIgY2xlYXI9YWxsPgo8L3RkPgo8L3RyPgo8dHI+Cjx0ZCB2 YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8YSBo cmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUvZF9kYnNwcm9nLmh0bWwiPiA8 Yj48c21hbGw+RElTSCBOZXR3b3JrIFByb2dyYW1taW5nPC9zbWFsbD48L2I+PC9hPjxiciBj
Thinking differently about names and addresses
Tony, 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? TH Send a name. Some sort of identifier, perhaps. The details are something we all need to discuss (and define) separately, quietly, and carefully. It is actually orthogonal to Site Local, though Site Local has engendered the discussion. In any event, please note that the suggestion that applications are required to use names, rather than IP addresses, is new. Completely new. As in, it has not been part of the Internet architecture for the past 25 years. So we all should be a tad careful about claiming that failure to use that enhancement represents a failure. A new idea that is good is good, but failure to use that idea previously is not broken. 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? TH Any app that sends topology locator information without understanding TH the topology is broken. If it is trying to use it in terms of the topological information, you are right. However it is usually just carrying it as an opaque identifier. This is not such an unusual or broken behavior as one might think. Using an upper layer for context storage of strings that are meaningful to a lower layer -- but not to the higher one -- is a well-accepted practise. So, we now get an unusual opportunity for network layer folk and apps layer folk to again consider the difference between naming and addressing. Maybe we can get John Shoch to remind us of the fundamentals. (The URI/URN confusion on this point has been a continuing source of frustration.) The problem is that addresses are (transient) unique identifiers, so we sometimes use them without knowing they are addresses. - 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. TH It absolutely does. When an app knows there is an insufficient scope, I guess the point that it is a new requirement -- to expect an app know about topology -- is not registering clearly enough. Perhaps it is a reasonable requirement, but it is a major one and it is one that is certainly not well enough understood. There is nothing obvious, simple or historical about this requirement. So discussion of it needs to be on a rather different basis than inventing a new kind of IP address and then, belatedly, passing up the requirement to apps that they deal with it differentially. TH I can't parse this. In any case if an application is passing topology TH locator information, it has to understand the topology. Tony, I could be wrong, but I suspect that constantly repeating the same mantra will not help any of us who are not yet enlightened to achieve the nirvana that you are espousing. On the other hand, it is certainly effective at making clear that our own efforts to enlighten YOU of our own nirvana are falling far short. (1) Routing protocol issues/complexity, such as the need to handle ambiguous addresses in routing exchanges and the need to maintain site convexity. TH Either the addresses are ambiguous to the routing protocol, or it can TH deal with them. If they are ambiguous, there is no way to pass them TH around, so the 'need' is fabricated at best. Clearly that is not true for Site Local addresses, or they would not be called Site Local. Clearly the idea behind Site Local is that two different sites can use the same addresses, while both sites are able to reach each other. If that were NOT intended, there would be no need for a special mechanism. So in the context of the global Internet, those addresses are ambiguous. Yet they are expected to be routable (within the scope of their respective sites.) TH DNS passes around topology locators. Keeping it ignorant of the real TH topology is the poor architectural choice. Topology changes very fast. DNS changes very slow. How do you propose to handle this mismatch? TH If the app developers really TH want to keep the apps simple, they must pass around names, and let the TH infrastructure component tasked with keeping track of reality do the TH work. If apps insist on passing around topology locators rather than TH relying on DNS, they must understand the reality of the network they are TH describing. H. There IS a rather interesting thought this suggests to me, namely that an app should be able to query some service by saying something like I want to give destination X a reference to destination Y, please give me the reference to Y that I should use. The nature of that service and of the reference(s) then becomes the discussion. TH The
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 names and addresses
Dave Crocker wrote: TH Send a name. Some sort of identifier, perhaps. The details are something we all need to discuss (and define) separately, quietly, and carefully. Any other identifier will need to have all the properties of the FQDN, as well as have a secure mechanism for the owning node to update the binding to the current set of topology locators. It is actually orthogonal to Site Local, though Site Local has engendered the discussion. In any event, please note that the suggestion that applications are required to use names, rather than IP addresses, is new. Completely new. It is derived from the position that applications shouldn't know about topology. In general I agree, but that means they need to stop dealing with topologically significant entities. As in, it has not been part of the Internet architecture for the past 25 years. That is not clear, but in any case the deployed Internet is not the same as it was 25 years ago. From RFC 791; A distinction is made between names, addresses, and routes [4]. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primarily with addresses. It is the task of higher level (i.e., host-to-host or application) protocols to make the mapping from names to addresses. The internet module maps internet addresses to local net addresses. It is the task of lower level (i.e., local net or gateways) procedures to make the mapping from local net addresses to routes. Mapping names to addresses is a simple task. One could argue that it was so simple that apps took the shortcut of using the 'where' to also define the 'what'. That does not mean the requirement for apps to keep a clear context for 'what' is a new requirement. So we all should be a tad careful about claiming that failure to use that enhancement represents a failure. A new idea that is good is good, but failure to use that idea previously is not broken. In the Internet of 25 years ago, there were no filters that limited scope, so an app could get away with passing around mixed 'what'/'where' tags. The current world exposes that shortcut, and arguably identifies its failures. 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? TH Any app that sends topology locator information without TH understanding the topology is broken. If it is trying to use it in terms of the topological information, you are right. However it is usually just carrying it as an opaque identifier. This is not such an unusual or broken behavior as one might think. Using an upper layer for context storage of strings that are meaningful to a lower layer -- but not to the higher one -- is a well-accepted practise. I understand the intent here, but passing information outside its realm of applicability is broken. Turn on the wayback machine and consider the effect of passing a bitnet address across the gateway, or an internet address back. The receiver must have a context or the identifier is meaningless. The same is true with passing IP addresses outside of a filtering router, no matter which prefix is being used. So, we now get an unusual opportunity for network layer folk and apps layer folk to again consider the difference between naming and addressing. Maybe we can get John Shoch to remind us of the fundamentals. (The URI/URN confusion on this point has been a continuing source of frustration.) The problem is that addresses are (transient) unique identifiers, so we sometimes use them without knowing they are addresses. The multi6 list recently had a long discussion on this point. Unfortunately that effort is all about creating yet another layer of mapping between names and addresses, but misses the point that it requires all of the binding security and update processes that are already defined for DNS. - 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. TH It absolutely does. When an app knows there is an insufficient TH scope, I guess the point that it is a new requirement -- to expect an app know about topology -- is not registering clearly enough. Perhaps it is a reasonable requirement, but it is a major one and it is one that is certainly not well enough understood. I am not arguing that all apps need to know about topology, just those that insist on passing around topology locators. Basically, the app needs to know what it is doing. There is nothing obvious, simple or historical about this requirement. Again from 791; Care must be taken in mapping internet addresses to local net addresses; a single physical host
Re: Thinking differently about names and addresses
Tony, I am going to wait on replying to the debate aspect of this exchange, to see if others have comments. I am posting now only to offer a clarification: TH Either the addresses are ambiguous to the routing protocol, or it TH can deal with them. If they are ambiguous, there is no way to pass TH them around, so the 'need' is fabricated at best. Clearly that is not true for Site Local addresses, or they would not be called Site Local. Clearly the idea behind Site Local is that two different sites can use the same addresses, while both sites are able to reach each other. TH This is part of the FUD confusion propegated through the presentation TH to the apps area, as well as those who simply want to pretend that local TH scope addresses don't exist. The reality is that two networks that use TH ambiguous addresses can't just route to each other, because the routing TH protocol can't sort out the ambiguity. Sorry for the confusion: Site Local means that two sites need to be able to each use the same addresses. If the two sites interact, they need to use some other set of addresses. However Site Local is only an interesting construct if it operates while a site that is using one is attached to the Internet and, therefore, talking to others sites. When this occurs, obviously it is essential that a site local address stay... local to that site. However from the context of the larger Internet, the Site Local address is ambiguous. (Your reply agrees to this point, so this is here only for completeness.) d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253, fax:+1.866.358.5301
site locals are bankrupt
Tony, You are wasting our time. There is clear consensus to deprecate SLs. They were a bad idea, and people realize that now. Your attempt to justify the burdens they place on the network, on apps (including DNS), on routing hasn't made them look any more attractive. The best justification you've been able to produce for keeping them is that they're supposedly already deployed. Of course that deployment is insignificant compared to the future use of IPv6. At any rate, nothing is likely to stop legacy products from using SLs if they want to -- the point is to make certain that future products (especially apps) don't have to deal with them. What you have totally failed to do is explain why site locals and the burdens and complexity and unreliability that come with it are in the best interests of the Internet as a whole, as opposed to the interests of some company that wants to sell crippled products to its customers. Site locals had their chance, and failed to justify themselves. Taking them away results in a vast improvement to IPv6. It's time to move forward. Keith
Re: Thinking differently about names and addresses
--On Monday, 31 March, 2003 16:44 -0800 Dave Crocker [EMAIL PROTECTED] wrote: Tony, 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? TH Send a name. ... In any event, please note that the suggestion that applications are required to use names, rather than IP addresses, is new. Completely new. As in, it has not been part of the Internet architecture for the past 25 years. So we all should be a tad careful about claiming that failure to use that enhancement represents a failure. A new idea that is good is good, but failure to use that idea previously is not broken. Hmm. Maybe some clarification is in order, since at least three different, and contradictory, claims have been made about this principle. The use names and not addresses to facilitate the transition to IPv6 principle was articulated some years ago, I'm pretty sure back when I was still Apps AD. It was discussed at the time, and should not now come as a surprise to anyone. However, my understanding --then and now-- was that what we agreed to was to try to move away from the presentation form of IP addresses on the user interface side of applications. For example, we wanted to strongly discourage the use of addresses in URLs, we wanted to see an address in a telnet command or in setting up an FTP command channel only for debugging (if that) and so on. Today's implied claim that the principle extends to use of names within and between applications is new to me. There are all sorts of reasons why I think it is impractical. Certainly it is not something I would have consciously agreed to at any time in the last decade or so. In addition to the reasons that have been given, there is the small matter that DNS resolvers use timeout logic that is measured in seconds -- tolerable for one-time use when an application starts up, and maybe every half-hour or so thereafter, but almost inconceivable each time an application needs to look at an address or pass an address reference to a machine with which it is already conducting a dialogue. Worse, some applications are likely to get very confused if they go back to the DNS a second time and get very different address information (or even a different ordering of a set of addresses) to be used in conjunction with connections that are already open. Now, this may suggest that we need new facilities. Or perhaps we just need a way to say use this address, but the same prefix you already have for me or look the name up again, and pick the address you get back that matches the prefix you see for me. I don't know. I am pretty sure that no one has discussed those issues with the applications area at any time since IPv6 started to gell. I'm equally concerned about statements like: TH Any app that sends topology locator information without understanding TH the topology is broken. and That is not clear, but in any case the deployed Internet is not the same as it was 25 years ago. From RFC 791; A distinction is made between names, addresses, and routes [4]. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primarily with addresses. It is the task of higher level (i.e., host-to-host or application) protocols to make the mapping from names to addresses. The internet module maps internet addresses to local net addresses. It is the task of lower level (i.e., local net or gateways) procedures to make the mapping from local net addresses to routes. Mapping names to addresses is a simple task. One could argue that it was so simple that apps took the shortcut of using the 'where' to also define the 'what'. That does not mean the requirement for apps to keep a clear context for 'what' is a new requirement. Tony, I agree with the first statement. I'd almost suggest that it is self-evidently true, which may be the point you are trying to make. But we get different meanings from the RFC 791 quote, and that may be a lot of the difference in perspective here. At the time 791 was written, addresses were not routes, or bound to routes. Consequently, it would have been inappropriate to refer to them as topology locators. They were just addresses. Routes, and hence topology and topology locators, were invisible, not only to the applications, but even to TCP. An application that uses addresses in the 791 sense isn't involved with topology at all and has no clue about network topology. Even the here and not here implied by testing whether an address was on the same network was, and remains, invisible to most applications. When we introduced subnetting and then CIDR and, more specifically, route aggregation, we
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...))
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! 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. Eliot
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 12:17:44 -0800 Eliot Lear [EMAIL PROTECTED] wrote: 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! 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. In every network (well, larger than a single subnet behind a firewall, that is) I've seen, where there were RFC1918 addresses routed on the inside, these things happened, although in v4-land. It is madness. It must stop. With v6, we can make it stop. So, SL must go away, for it is an invitation to madness. All things SL is claimed to solve are solveable with unique addresses too, as long as you've got enough of them. The rest is just simple (perhaps tedious) work that every operations-aware person I know of would prefer to madness. -- Måns Nilssonhttp://vvv.besserwisser.org 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...))
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...))
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. 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.
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 15:43:38 -0600 Matt Crawford [EMAIL PROTECTED] wrote: All things SL is claimed to solve are solveable with unique addresses too, as long as you've got enough of them. The rest is just simple (perhaps tedious) work that every operations-aware person I know of would prefer to madness. 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.
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 15:49:03 -0600 Matt Crawford [EMAIL PROTECTED] 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? I thought we agreed, completely outside of IPv6 concerns, that shipping addresses in application data was bad. what's this we stuff? some individuals may have thought this was bad, but there's never been widespread agreement. 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.
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...))
On Mon, 31 Mar 2003 16:12:51 -0600 Matt Crawford [EMAIL PROTECTED] wrote: 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. well, it's about like declaring by fiat that all apps should always use DNS names, that apps should never use IP addresses, and that DNS should be aware of network topology -- without bothering to consult with apps writers to see whether this will actually work. look, we've basically got three choices for address stability. either (a) sites never renumber, (b) they renumber occasionally, or (c) they NAT. we haven't figure out how to make (a) work and allow routing to scale, or to allow enterprise networks to split or merge, etc. we have tried very hard to work around the problems with (c) and failed miserably. (b) is the only remaining option. so it's not so much a matter of declaring 'by fiat' that apps need to be able to survive renumbering, as setting expectations for which apps need to be able to survive renumbering while they're running. and it appears feasible to set expectations in such a way that most apps need not worry about it. Keith
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
This has nothing to do with sitelocal but more with the fact that a host can have multiple paths from A to B: internet ;) multiple paths does not imply multiple addresses.
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
