RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Eliot, Eliot Lear wrote: What you say is possible, and has happened. But dumb things happen. Those dumb things could happen with non site-local addresses as well. More limited, that's the point. Not perfect, but better than unregulated anarchy. However, between a network design that does not meet RFPs (and therefore does not get implemented) and anarchy, I pick anarchy, especially when I'm not the one dealing with it later. This community designs protocols to please code developers and protocol designers. If it designed protocols with users in mind maybe less dumb things would happen because dumb users would not have to do dumb hacks to make things work. But look. Ultimately I think we as a community do need to own up to better tooling, which can lead to better expectations. This requires teamwork and what we have today is a bunch of people entrenched in their positions and unwilling to compromise. If you want better tooling, why don't you talk to the whiners that want to have the cake and eat the cake? You know, the same kind of people that wrote a real operating system or designed a real router that managed to capture 0.5% of the market but of course is better than the implementation that captured 75% of the market. Maybe if these people had compromised instead of digging their heels they would not be whining about proprietary implementations. The tools need to set expectations, and perhaps some of the DHCP prefix delegation code can help here. Care to explain? Michel.
FW: [ga] ITU-T Workshops on E-Health, E-Government, and Next Generation Ne tworks
Particularly the third item... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 27 March 2003 16:35 To: [EMAIL PROTECTED] Subject: [ga] ITU-T Workshops on E-Health, E-Government, and Next Generation Ne tworks The ITU-T is organizing three open workshops on, respectively, E-Health, E-Government, and Next Generation Networks. A brief description is provided below, together with the URLs pointing to full information. Standardization in E-Health, 23-25 May 2003, Geneva, Switzerland. Standardization in e-health has long been sought, but has so far not produced a very high level interoperability desired by many. In organizing this workshop, ITU-T, with the support of ITU-D and the participation of ISO, IEC and other SDOs, aims at identifying the key issues needed in support of attaining this goal and to identify a possible role to be played in ITU-T to promote such standards. Full information at: http://www.itu.int/ITU-T/worksem/e-health/index.html Challenges, perspectives and standardization issues in E-Government, 5-6 June 2003, Geneva, Switzerland. This workshop looks to develop perspectives for the members and invited guests on the issues facing Member States and vendors in the implementation of e-Government solutions today and in the future, with a focus on standardization issues. Full information at: http://www.itu.int/ITU-T/worksem/e-government/index.html Next Generation Networks: What, When and How, 9-10 July 2003, Geneva, Switzerland. The concept of Next Generation Networks (NGN) is quickly emerging as an essential initiative towards defining what do we do next? The current situation in telecommunications is characterised by over-arching market factors encompassing open competition between operators due to the rapid deregulation, the explosion of digital traffic (especially the increasing use of the Internet), in combination with sustained market demand for new generation multimedia services and applications. A key element of the marketplace is the increasing demand for global mobility and nomadism as these become norms from the end user point of view. Full information at: http://www.itu.int/ITU-T/worksem/ngn/index.html Best, Richard - Richard Hill Counsellor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva 20 Switzerland tel: +41 22 730 5887 FAX: +41 22 730 5853 Email: [EMAIL PROTECTED] Study Group 2 email: [EMAIL PROTECTED] -- This message was passed to you via the [EMAIL PROTECTED] list. Send mail to [EMAIL PROTECTED] to unsubscribe (unsubscribe ga in the body of the message). Archives at http://www.dnso.org/archives.html
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, Mar 27, 2003 at 05:48:44PM -0800, Christian Huitema wrote: My Windows-XP laptop currently has 14 IPv6 addresses, and 2 IPv4 addresses. The sky is not falling. Except of those 14 some seven(?) are RFC3041 addresses, which break a number of applications... so there are some clouds in the sky. Tim
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
I suspect that most people there, who voted for the elimination ... At my first IETF meeting I received a T-Shirt, courtesy of Marshall Rose, I believe, that said We reject kings, presidents and voting... The real tragicomedy of this situation is that someone considered it fitting and proper to count 102 hands.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Margaret Wasserman wrote: As you know, I was in favor of setting aside a prefix (FECO::, in fact) for use as private address space (either on disconnected networks, or behind NATs), but the consensus of the folks in the IPv6 WG meeting was to deprecate that prefix altogether. There were several compelling arguments from operators and others that we don't need a special prefix for disconnected sites... Besides, we have three such prefixes, given RFC-1918 and 6to4: 2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote: No, it's more than that. SLs impose burdens on hosts and apps. SLs break the separation of function between apps and the network that is inherent in the end-to-end principle. Is it safe to assume that the arguments (on either side) would also apply to such things as multicast addressing and SCTP path management? Actually we are working toward an architecture that provides a level of consistency. Which is essentially what I'm rephrasing into a question above. I think I know the answer, but I want to make sure. John
Re: Doing real work
On Fri, 28 Mar 2003 08:47:45 PST, Michel Py said: two pieces of duct tape is really way superior to Cisco products. Yeah, right. If Cisco became market leader, it is because of their ability to design and manufacture products that actually work in enterprises and not because of questionable business practices. Hmm.. So the whole DoJ/Microsoft thing was what, exactly? (We're a Cisco shop, and their gear mostly works for us, even with some of the truly demented things we try to do with it. I'm merely objecting to the assertion that technical clue is the only way to market leadership...) pgp0.pgp Description: PGP signature
Re: Doing real work
I guess I am missing something here about free markets and free societies. What is wrong with criticism? If it is valid, then the results are deserved, if not, then it will be ignored. The fact is that for many people the home-made router is superior for many reasons: price, control, flexibility, etc. For many others a commercial product is better, performance, support, availability, etc. Successes, unfortunately, not determined solely by product and technological excellence. Like it or not, the color of the box, name and even the logo all affect sales. IBM had complete domination of the computer market for years. Not just because they had superior products, they did not, but because an IT manager could not get into trouble for buying Blue. Buying IBM meant buying job security. Richard On 3/28/03 8:47 AM, Michel Py [EMAIL PROTECTED] wrote: What I'm concerned about are these guys and gals that say Cisco routers are junk. These guys at Cisco don't know jack about routing, it's fortunate they bought Linksys so they will get clued engineers from the acquisition, and my router that I put together with a recycled PC and two pieces of duct tape is really way superior to Cisco products. Yeah, right. If Cisco became market leader, it is because of their ability to design and manufacture products that actually work in enterprises and not because of questionable business practices.
RE: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Did anybody consider just handing out a /48 (or a bit smaller) automagically with each DNS registration? --On Friday, March 28, 2003 10:36 AM -0800 Tony Hain [EMAIL PROTECTED] wrote: John C Klensin wrote: 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/...)? The problems with this theory are that a registry costs money to run, and it requires an organization to expose their business plan (never mind figuring out who is really qualified to judge the validity of any given justification). Even when the big bad US Gov. was picking up the tab, there were cost control measures that required someone to validate the request (I was one such sanity checker). If we create a space that requires registration, it will become a simple -biggest wallet gets the most space- arrangement, because it is in the financial interest of the registry to accept all requests. The only push back to that is to set the price per prefix high enough that the registry doesn't need more cash to run, but that, and the recurring nature of those costs, will cause people to avoid the registry and use random numbers. The other point in this is that you can't force people to register until there is a technical reason for it, like making routing work. 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
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...))
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. ;) ...right after you get lynched for heresy. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
layers above it and a dangerous blow to the hour glass model. Looking at what is going on in the IETF, I think we are talking about first aid rather than trying to prevent the blow as such. That happened along time ago...:-( But yes, we need to protect the architectural model or discuss a new one. I vote for the first, and in both cases we need to decide on that fist, before starting to decide on implementations. So leave site-locals for know. Steve Deering made a wonderful presentation at the plenary in London. More people should read it. - kurtis -
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. SLs won't come for free either. Architecture aside, I prefer people that use a service to pay for it rather than the community as such. Then I also happen to think that SLs break the architecture but that is something else... - kurtis -
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
To echo the favorable review of Steve's presentation: It's at http://www.ietf.org/proceedings/01aug/slides/plenary-1/index.html, and is well worth the few minutes it takes to read/re-read... Spencer --- Kurt Erik Lindqvist [EMAIL PROTECTED] wrote: Steve Deering made a wonderful presentation at the plenary in London. More people should read it.
Re: site local addresses
Except of those 14 some seven(?) are RFC3041 addresses, which break a number of applications... so there are some clouds in the sky. 3041 may be next on the hit-list. Pretty soon it truly will be nothing but bigger addresses. lets shoot down those 128 bit addresses too, 64 must be enough. /ot
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 theInterNAT...))
--On Friday, 28 March, 2003 15:50 -0800 Tony Hain [EMAIL PROTECTED] wrote: 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'm interested in your not in a position comment. Whether it is reasonable or not, ISPs include such restrictions in terms and conditions of service all of the time. I have seen agreements that prohibit connecting more than one computer to an ISP-provided line, agreements that explicitly ban customer-side NAT boxes and restrict use to no more than one computer per ISP-provided address, and prohibit connecting their interfaces to anything resembling a LAN or to a machine that can gateway into a LAN. I've also seen agreements that prohibit any use of tunnels into external mail servers or corporate LANs, presumably to get the customer to buy a higher-priced commercial service if anything other than home-type web browsing and associated email is to be done with the link. Now some (or most) of these restrictions impress me, and probably you, as unreasonable. We might choose to apply the see if they can find out that I'm doing it test to the restrictions and ignore them or, at the other extreme, apply the don't sign anything on the assumption that the other party won't be able or inclined to enforce it principle. We, or more specifically, the upstream ISP or an RIR, can tell the ISP that things will go badly for them if they permit unroutable 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 unroutable one is that you would bind that advice/threat to a particular prefix while I would bind it to other indicators of unroutable 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 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. ;) And, since I have seen split-horizon DNS implementations fail more often than not, I'm not sure I see a cure there either. Regards, john
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 theInterNAT...))
--On Friday, 28 March, 2003 14:54 -0500 Keith Moore [EMAIL PROTECTED] wrote: 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. ;) ...right after you get lynched for heresy. yeah, well... Tony is right -- any registration process costs resources. But, if these addresses are assumed to be not routable, then there shouldn't be any routing table bloat. Put differently, once can conceive of three ways to get addresses: * 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
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...))
Tony is right -- any registration process costs resources. agreed, though the cost of registering a domain name should serve as a useful upper bound. at least with address blocks you don't have to worry about I18N, trademark infringement, etc. But, if these addresses are assumed to be not routable, then there shouldn't be any routing table bloat. Put differently, once can conceive of three ways to get addresses: * From an RIR, as PI space * From an ISP, as PD CIDR space. * From some other process, as long-prefix, almost certainly unroutable, isolated space. actually it's highly desirable if such addresses *are* routable by private agreement, just not by default. I don't see why we shouldn't be able to choose from the above three options.
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
% David R. Oran wrote: % % Did anybody consider just handing out a /48 (or a bit smaller) % automagically with each DNS registration? % % I proposed a couple of times a /32 from which /48 can be requested % for 'private' (never to be connected to the internet) purposes. % I think some others have proposed a similar thing. But the opposers % think that it won't be 'free' then... but they will be unique :) Been there, Done it, Bought everything. SRInic was told to split the assignments into a connected/unconnected database back in the day. It was ugly when folks figured that they really wanted to be connected and passed muster. renumbering was less fun in the late 1980s than today. Never want to re-introduce this concept unless/until we can get to the point of being able to painlessly renumber the entire Internet every 20 minutes. Now where are those renumbering in IPv6 is easy cookies. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Bill Manning [mailto:[EMAIL PROTECTED] wrote: % David R. Oran wrote: % % Did anybody consider just handing out a /48 (or a bit smaller) % automagically with each DNS registration? % % I proposed a couple of times a /32 from which /48 can be requested % for 'private' (never to be connected to the internet) purposes. % I think some others have proposed a similar thing. But the opposers % think that it won't be 'free' then... but they will be unique :) Been there, Done it, Bought everything. SRInic was told to split the assignments into a connected/unconnected database back in the day. It was ugly when folks figured that they really wanted to be connected and passed muster. renumbering was less fun in the late 1980s than today. Never want to re-introduce this concept unless/until we can get to the point of being able to painlessly renumber the entire Internet every 20 minutes. That eliminates this 'solution'. History is bound to repeat in these cases. Thus IMHO folks will just need to allocate some random space or get it out some assigned space. Now where are those renumbering in IPv6 is easy cookies. Some other old stories made those crumble also :) The renumbering isn't the part that is difficult, though it's all the configuration items around it that's the burden. Greets, Jeroen
Re: Fw: Welcome to the InterNAT...
What is not fixable is the fact that apps will break if you change an address out from under them. heck, TCP breaks if you change an address out from under it, so it's hardly surprising that apps using TCP break under similar conditions. the TCP/IP architecture simply was not designed to tolerate hosts changing addresses. and no, IPv6 doesn't fix this. actually it's very difficult to fix at anything above layer 3. This is a fact the app developers complaining about the complexity of scoped addresses continually overlook. I don't know where you get that idea. I've been arguing against both scoped addresses and limited-duration addresses. It's just that there has been more attention paid to scoped addresses later. But absent drastic changes in the architecture, it's not sufficient that addresses have global scope, they need to be reasonably stable also. The assertion is that all a network needs to do is change the addresses in use when connecting. Never mind that every local use app will break on every one of those events. That is not an acceptable approach. agreed. But SL doesn't solve that problem, except in corner cases. better to have a comprehensive solution, or simply to expect addresses to be reasonably stable, than to impose SL.
Re: Fw: Welcome to the InterNAT...
Keith; I disagree with your assessment. I will continue this technical discussion on the WG list after the minutes are published. Rich At 06:26 PM 3/27/03 -0500, Keith Moore wrote: I second Tony's key point. SL's are just 1 form of IPv6 addresses with a limited scope. As soon as operations folks put up firewall or router filters, global addresses have the same scope limitations. they don't have the same set of problems that SLs do. SL addresses are ambiguous. if you can't reach a host using its SL address, you don't know whether the problem is that you're in a different site or whether the host is down or whether there is a link failure or this is prohibited by policy. so a multiparty app ends up needing to implement various hacks to deal with ambiguous addresses (proxies, tunneling, etc), in order to function across site boundaries (and apps *will* be expected to function across site boundaries). with globals, if an app can't reach the host using a global address, it's either a host failure, a network failure, or a policy decision. to a large degree this can be disambiguated using ICMP. but in many cases the app can treat these as 'out of its control' since there's no way to work around them. SLs thus break a clean separation of function between the apps and the network. Keith Richard A. Carlson e-mail: [EMAIL PROTECTED] Network Research Sectionphone: (630) 252-7289 Argonne National Laboratory fax:(630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439
RE: Doing real work
Charlie, Charles E. Perkins wrote: What if the market were shaped by: - using questionable business practices to cripple/kill competitors? - predatory/stupid legislation? (e.g., efforts to outlaw French technology) - selective failure to enforce existing legislation? - powerful and misleading advertising? There certainly is some of it, but it's not everything either. What I'm concerned about are these guys and gals that say Cisco routers are junk. These guys at Cisco don't know jack about routing, it's fortunate they bought Linksys so they will get clued engineers from the acquisition, and my router that I put together with a recycled PC and two pieces of duct tape is really way superior to Cisco products. Yeah, right. If Cisco became market leader, it is because of their ability to design and manufacture products that actually work in enterprises and not because of questionable business practices. The same people torpedo group efforts to work on difficult issues because it has to be their way (that's better than the Cisco way or for the same topic any compromise that a WG could come up with) or no way at all. [note: I do not work for Cisco] Does it mean that we should require new sections in every Internet Draft explaining how the protocol can succeed by suggesting some clever strategies for misleading advertising and so on, or how to kill competitive protocols? I know you didn't want to suggest this. Maybe you didn't really mean what you said. It amounts to might makes right. Not at all. It amount to no solution because we found more comfortable to put issues under the rug is worse than an imperfect solution. If we don't provide a site-local solution, there will be a Microsoft solution, a Sun solution, a Cisco solution, a Juniper solution, etc. Eventually one or more of these will become a de-facto standard, and then people will be whining how dare these big mighty companies produce solutions without talking to us; they abuse their power to impose their solution. Michel.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, 27 Mar 2003 18:29:22 -0600 John Kristoff [EMAIL PROTECTED] wrote: On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote: No, it's more than that. SLs impose burdens on hosts and apps. SLs break the separation of function between apps and the network that is inherent in the end-to-end principle. Is it safe to assume that the arguments (on either side) would also apply to such things as multicast addressing and SCTP path management? I don't think these arguments apply to multicast at all because apps use multicast very differently than unicast, and the considerations about address portability are different. I suspect it does apply to SCTP path management, but I don't know enough about SCTP to be confident of that.
