Copy Link
Add to Bookmark
Report
Netizens-Digest Volume 1 Number 383
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" <hcb@clark.net>
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" <hcb@clark.net> 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" <hcb@clark.net>
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" <hcb@clark.net>
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" <hcb@clark.net> 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" <hcb@clark.net>
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" <hcb@clark.net>
>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" <hcb@clark.net> 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
******************************
