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: 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: 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: 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
