Netizens-Digest Tuesday, April 17 2001 Volume 01 : Number 383 Netizens Association Discussion List Digest In this issue: Re: [netz] Internet addressing and the new NAS committee Re: [netz] Internet addressing and the new NAS committee Re: [netz] Internet addressing and the new NAS committee Re: [netz] Internet addressing and the new NAS committee ---------------------------------------------------------------------- Date: Mon, 16 Apr 2001 23:04:28 -0400 (EDT) From: ronda@panix.com Subject: Re: [netz] Internet addressing and the new NAS committee >From owner-netizens@columbia.edu Mon Apr 16 11:14:46 2001 Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net In-Reply-To: <200104161326.JAA06692@panix6.panix.com> References: <200104161326.JAA06692@panix6.panix.com> Date: Mon, 16 Apr 2001 11:05:04 -0400 To: netizens@columbia.edu From: "Howard C. Berkowitz" Subject: Re: [netz] Internet addressing and the new NAS committee Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-netizens@columbia.edu Precedence: bulk Reply-To: netizens@columbia.edu "Howard C. Berkowitz" writes: At 9:26 AM -0400 4/16/01, ronda@panix.com wrote: >I have been working on writing a report on the meeting I attended >last Monday of the new committee appointed by the National Academy >of Science on "Internet Searching and the Domain Name System" >At the meeting, one of the spokespeople from the US Department of >Commerce was asked if the commmittee should consider alternative >addressing systems as well as naming systems. > >She responded that since these were related, alternatives for both >should be considered because they are related. >Oh my God. Let me first make the comment that addressing and routing >are my area of specialization. My first book was on addressing >architecture. I have authored or coauthored several RFCs in >addressing and renumbering, and given tutorials on addressing at >NANOG and ARIN. (...) >There are some nuances to this, depending on how you define >"Internet." Our current address family is IP version 4 (IPv4). Not >all of the available space has been assigned, but, with current >projections, it probably won't last beyond the end of the decade. thanks for the further explanation of this all. I found it helpful to read and want to read it again more carefully as soon as I have time as it is further background that is helpful to understand. >Incidentally, introducing a new IP protocol is far more than just a >new addressing scheme. There are fundamental changes in the protocol >based on 30 years of experience. IPv6, for example, is much easier to >process in special-purpose hardware than is IPv4. Security is a >standard feature, not an add-on. But doesn't it have a large overhead and other problems. I was at a sigcomm98 meeting and a number of people there described real probelms with ipv6. >One continuing problem is the confusion between two functions that >are both mapped onto current IPv4 addresses, and which really is a >problem. The functions are identification and location. Thanks this is a helpful distinction. >If it can be confirmed that a "DNS" committee is considering that >addressing might be within its scope, this information needs to go to >lots of organizations, including the address registries (ARIN, >RIPE-NCC, APNIC, LACNIC, AFRNIC), the operations forums (NANOG, RIPE, >APRICOT) and probably the IAB. I will look at my notes about this all more carefully and will write more in the next day or two with what I find. Also it is interesting that the name of the committee was originally "Internet Addressing and the Domain Name System" but seems to have been changed to "Internet Searching and the Domain Name System". So this is clearly an important issue. It would be good to know why this was the original title, but then why the title was changed. Ronda ronda@panix.com ------------------------------ Date: Mon, 16 Apr 2001 23:34:44 -0400 From: "Howard C. Berkowitz" Subject: Re: [netz] Internet addressing and the new NAS committee > > >>Incidentally, introducing a new IP protocol is far more than just a >>new addressing scheme. There are fundamental changes in the protocol >>based on 30 years of experience. IPv6, for example, is much easier to >>process in special-purpose hardware than is IPv4. Security is a >>standard feature, not an add-on. > >But doesn't it have a large overhead and other problems. I was >at a sigcomm98 meeting and a number of people there described >real probelms with ipv6. I wouldn't say that overhead is a current concern. While the addresses are longer, they (and the rest of the header) can be handled in a more efficient way than Ipv4. There are definitely some concerns of how to do multihoming. There's also a question of expectations. IPv6 doesn't directly do anything to solve the problems of routing scalability, although it _could_ allow a better framework. The same general operational constraints apply to routing table scalability with either protocol. One of the scary things about IPv6 is that people see the larger address space and assume that it will let them give unique addresses to every insect on the planet. The Chinese have advocated IPv6 so they can have lots of addresses. It may seem counterintuitive, but giving everyone and everything a fixed and unique address is probably the worst thing anyone can do for Internet scalability. Without going into lots of technical detail, it comes back to the identifier versus locator distinction. Unique identifiers aren't a bad thing, but the routing system (as distinct from DNS or other directories) is based on locators, not identifiers. The key to routing scalability is to minimize the number of locators needed to find endpoints. Part of the current problem is that locator mechanisms are being overloaded to do various policy things that aren't essential parts of routing, such as traffic engineering/bandwidth control and fault tolerance. "Multihoming" is part, but only part, of fault tolerance, and there are significantly more forms of multihoming than multihomed routing. In the present system, an enterprise connected to two providers in Australia often announces both uplinks to the entire world. It could very well be, however, that this enterprise's upstream share a common transoceanic link (or have diverse links that are invisible to routing). The multiple routes are relevant within Australia, but not in South America. Unfortunately, administrative and competitive issues are apt to make these routes propagate everywhere. Some of this propagation is a matter of perception rather than technology, with ISPs giving customers what they want. Indeed, responsible ISPs may lose business because competitors' salesfolk are spreading FUD (fear, uncertainty, and doubt) about multihoming. In many cases, having multiple links to the same provider is as or even more reliable than having links to different providers, because a single provider has a better chance of being sure that the physical facilities don't share a common point of failure. This, of course, isn't always possible -- diverse facilities aren't available everywhere, or they may not be affordable. Hopefully in the next couple of weeks, I'll be resurrecting an Internet Draft I wrote about multihoming requirements. ------------------------------ Date: Tue, 17 Apr 2001 08:01:13 -0400 (EDT) From: ronda@panix.com Subject: Re: [netz] Internet addressing and the new NAS committee >From owner-netizens@columbia.edu Mon Apr 16 23:41:28 2001 Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net In-Reply-To: <200104170304.XAA24598@panix2.panix.com> References: <200104170304.XAA24598@panix2.panix.com> Date: Mon, 16 Apr 2001 23:34:44 -0400 To: netizens@columbia.edu From: "Howard C. Berkowitz" Subject: Re: [netz] Internet addressing and the new NAS committee Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-netizens@columbia.edu Precedence: bulk Reply-To: netizens@columbia.edu "Howard C. Berkowitz" writes about IPv6: > > > >>But doesn't it have a large overhead and other problems. I was >>at a sigcomm98 meeting and a number of people there described >>real probelms with ipv6. >I wouldn't say that overhead is a current concern. While the >addresses are longer, they (and the rest of the header) can be >handled in a more efficient way than Ipv4. There are definitely some >concerns of how to do multihoming. Can you say what multihoming is? >There's also a question of expectations. IPv6 doesn't directly do >anything to solve the problems of routing scalability, although it >_could_ allow a better framework. The same general operational >constraints apply to routing table scalability with either protocol. >One of the scary things about IPv6 is that people see the larger >address space and assume that it will let them give unique addresses >to every insect on the planet. The Chinese have advocated IPv6 so >they can have lots of addresses. >It may seem counterintuitive, but giving everyone and everything a >fixed and unique address is probably the worst thing anyone can do >for Internet scalability. Without going into lots of technical >detail, it comes back to the identifier versus locator distinction. >Unique identifiers aren't a bad thing, but the routing system (as >distinct from DNS or other directories) is based on locators, not >identifiers. >The key to routing scalability is to minimize the number of locators >needed to find endpoints. Part of the current problem is that locator >mechanisms are being overloaded to do various policy things that >aren't essential parts of routing, such as traffic >engineering/bandwidth control and fault tolerance. "Multihoming" is >part, but only part, of fault tolerance, and there are significantly >more forms of multihoming than multihomed routing. How would you minimize the number of locators? >In the present system, an enterprise connected to two providers in >Australia often announces both uplinks to the entire world. It could >very well be, however, that this enterprise's upstream share a common >transoceanic link (or have diverse links that are invisible to >routing). The multiple routes are relevant within Australia, but not >in South America. Unfortunately, administrative and competitive >issues are apt to make these routes propagate everywhere. What are these uplinks? How does the company announce them to the world? Is that via different IP numbers for the different providers? This reminds me of the days before the regulated telephone system in the US where different companies had different telephone systems and a person had to sign up for each telephone system to be able to talk to the people who were on it. There weren't interconnections between them. I remember not too long ago, as well, when companies had their own networks but weren't yet connected to the Internet (in the early 1990's). So it seems we have made extraordinary progress in the fact that the Internet is recognized as the common network. What are the implications then of this. >Some of this propagation is a matter of perception rather than >technology, with ISPs giving customers what they want. Indeed, >responsible ISPs may lose business because competitors' salesfolk are >spreading FUD (fear, uncertainty, and doubt) about multihoming. In >many cases, having multiple links to the same provider is as or even >more reliable than having links to different providers, because a >single provider has a better chance of being sure that the physical >facilities don't share a common point of failure. This, of course, >isn't always possible -- diverse facilities aren't available >everywhere, or they may not be affordable. Interesting. It seemed for example that the idea of giving out domain names by ISPs where they weren't linked to IP numbers was a piece of a problem. Also in this scenario it doesn't seem there is adequate support for the research and thinking that is needed to provide for the infrastructure. For example Bell Labs at AT&T supported a set of people to consider the boarder and more long term development of the telephone infrastructure. The regulated telephone company in the US provided the needed support for the long term thinking to develop the technology and science needed for the infrastructure's future development. >Hopefully in the next couple of weeks, I'll be resurrecting an >Internet Draft I wrote about multihoming requirements. Good. Ronda ------------------------------ Date: Tue, 17 Apr 2001 12:50:00 -0400 From: "Howard C. Berkowitz" Subject: Re: [netz] Internet addressing and the new NAS committee > >From owner-netizens@columbia.edu Mon Apr 16 23:41:28 2001 >Mime-Version: 1.0 >X-Sender: hcb@pop3.clark.net >In-Reply-To: <200104170304.XAA24598@panix2.panix.com> >References: <200104170304.XAA24598@panix2.panix.com> >Date: Mon, 16 Apr 2001 23:34:44 -0400 >To: netizens@columbia.edu >From: "Howard C. Berkowitz" >Subject: Re: [netz] Internet addressing and the new NAS committee >Content-Type: text/plain; charset="us-ascii" ; format="flowed" >Sender: owner-netizens@columbia.edu >Precedence: bulk >Reply-To: netizens@columbia.edu > > "Howard C. Berkowitz" writes about IPv6: >> >> >> >>>But doesn't it have a large overhead and other problems. I was >>>at a sigcomm98 meeting and a number of people there described >>>real probelms with ipv6. > >>I wouldn't say that overhead is a current concern. While the >>addresses are longer, they (and the rest of the header) can be >>handled in a more efficient way than Ipv4. There are definitely some >>concerns of how to do multihoming. > >Can you say what multihoming is? This opens a huge discussion, but, in broad terms, it's the idea of having more than one path to reach a resource, with the implicit assumption that not all paths are likely to be down at the same time. Its major goal is improving fault tolerance, but it may have a secondary effect of making performance more predictable if the routine load is spread fairly over all paths. Part of the complexity of multihoming is that many people assume it to be a pure routing problem. In fact, it can very well involve DNS and other services at a logically higher level than IP routing. Let me share one of my favorite experiences, which convinced me that Dilbert and his friends are alive and well in American corporate culture. I was doing a combination of consulting and leading a design seminar for a major US Internet provider. One of my students came back in from a phone call, his face a study in frustration. He explained that he had just gotten off a long call with a client, a major national bank. The bank was establishing online banking services for its customers. For reliability, it had three regional data centers, any of which could handle the workload (although with some degradation). What the bank wanted was to establish a well-known DNS name (service.bigbank.com), and let its subscribers connect through any ISP anywhere. It was the bank's requirement, however, that the customer should get steered to the (working) set of servers that was least busy, over "the best path." It was the customer's perception that they could get what they wanted by using BGP routing, which has no awareness of individual servers. The proper solution might have involved an intelligent DNS, which tracked server utilization and returned different DNS addresses (i.e., of the real server clusters) to each customer access request. When told that BGP routing wouldn't solve what they wanted to do, they responded, "Clearly, you aren't being responsive to our needs, even though we pay you lots of money. Please give us the phone number of the person in charge of the Internet, and we will take it up with him." > >>There's also a question of expectations. IPv6 doesn't directly do >>anything to solve the problems of routing scalability, although it >>_could_ allow a better framework. The same general operational >>constraints apply to routing table scalability with either protocol. > >>One of the scary things about IPv6 is that people see the larger >>address space and assume that it will let them give unique addresses >>to every insect on the planet. The Chinese have advocated IPv6 so >>they can have lots of addresses. > >>It may seem counterintuitive, but giving everyone and everything a >>fixed and unique address is probably the worst thing anyone can do >>for Internet scalability. Without going into lots of technical >>detail, it comes back to the identifier versus locator distinction. >>Unique identifiers aren't a bad thing, but the routing system (as > >distinct from DNS or other directories) is based on locators, not >>identifiers. > >>The key to routing scalability is to minimize the number of locators >>needed to find endpoints. Part of the current problem is that locator >>mechanisms are being overloaded to do various policy things that >>aren't essential parts of routing, such as traffic >>engineering/bandwidth control and fault tolerance. "Multihoming" is >>part, but only part, of fault tolerance, and there are significantly >>more forms of multihoming than multihomed routing. > >How would you minimize the number of locators? No simple answer, but my Australian example below bears on this. Enterprises in Australia would see the locators that are meaningful in Australia, enterprises in South America would see the locators meaningful in South America, but not vice versa. There would be no master table for the world, which is a good thing for scalability. Continental-level tables would contain less locators than worldwide ones. The intercontinental tables might not contain continental locators. > >>In the present system, an enterprise connected to two providers in >>Australia often announces both uplinks to the entire world. It could > >very well be, however, that this enterprise's upstream share a common >>transoceanic link (or have diverse links that are invisible to >>routing). The multiple routes are relevant within Australia, but not >>in South America. Unfortunately, administrative and competitive >>issues are apt to make these routes propagate everywhere. > >What are these uplinks? How does the company announce them >to the world? Is that via different IP numbers for the different >providers? No simple answers to this. But, for example, one of the major southwestern Pacific undersea cables is not actually a point-to-point facility as many believe, but a ring with four entry points, two in Australia and two in North America. There is a spare internal ring that automatically takes over in the event of failure, but the "big ring" is seen as having only one IP address (well, actually, different providers have independent IP addresses mapped on it, each address associated with their bandwidth allocation). > >This reminds me of the days before the regulated telephone system >in the US where different companies had different telephone systems >and a person had to sign up for each telephone system to be able >to talk to the people who were on it. There weren't interconnections >between them. I remember not too long ago, as well, when companies >had their own networks but weren't yet connected to the Internet >(in the early 1990's). Do distinguish between having separate, end-user-visible telephony networks such as the Bell and Home Telephone Systems in 1900 or so, and the current reality that long-distance telephony can and does run over multiple long-haul providers that are hidden from the subscriber. I might make a call from Washington DC to San Francisco, and on one occasion go via Sprint across the country and by AT&T on another. The same principles apply to packets. > >So it seems we have made extraordinary progress in the fact that >the Internet is recognized as the common network. But the Public Switched Telephone Network is seen as one network, with one numbering plan, mapped onto many providers' physical networks. > >What are the implications then of this. > >>Some of this propagation is a matter of perception rather than >>technology, with ISPs giving customers what they want. Indeed, >>responsible ISPs may lose business because competitors' salesfolk are >>spreading FUD (fear, uncertainty, and doubt) about multihoming. In >>many cases, having multiple links to the same provider is as or even >>more reliable than having links to different providers, because a >>single provider has a better chance of being sure that the physical >>facilities don't share a common point of failure. This, of course, >>isn't always possible -- diverse facilities aren't available >>everywhere, or they may not be affordable. > >Interesting. > >It seemed for example that the idea of giving out domain names >by ISPs where they weren't linked to IP numbers was a piece of >a problem. I don't understand your point. There isn't supposed to be a fixed relationship between domain name and IP address. Domain names are identifiers while IP addresses are locators. If the organization with the domain name changes its connectivity, the associated IP addresses should and do change. > >Also in this scenario it doesn't seem there is adequate support for >the research and thinking that is needed to provide for the infrastructure. >For example Bell Labs at AT&T supported a set of people to consider the >boarder and more long term development of the telephone infrastructure. The best equivalent is in the IAB/IETF. > >The regulated telephone company in the US provided the needed support >for the long term thinking to develop the technology and science >needed for the infrastructure's future development. I agree that the breakup of AT&T Bell Labs, and the further breakup of its descendants such as Bellcore, was a national tragedy. > >>Hopefully in the next couple of weeks, I'll be resurrecting an >>Internet Draft I wrote about multihoming requirements. > >Good. > >Ronda ------------------------------ End of Netizens-Digest V1 #383 ******************************