IPv6: Past mistakes repeated?

What I find interesting throughout discussions that mention IPv6 as a solution for a shortage of addresses in IPv4 is that people see the problems with IPv4, but they don't realize that IPv6 will run into the same difficulties. _Any_ addressing scheme that uses addresses of fixed length will ru

RE: IPv6: Past mistakes repeated?

I agree! Why create a finite anything when an infinite possibility exists? On another note, I have heard the argument that a unique identifier already exists in the form of a MAC address why not make further use of it? David H -Original Message- From: Anthony Atkielski [mailto:[EMAIL PRO

RE: IPv6: Past mistakes repeated?

IPv6 is designed to be compatible with IPv4? If what you suggest should be implemented, then probably the entire software of all the switches and hubs need to be upgraded (if not entirely scrapped) . As also everytime the source and destination addresses are upgraded, all the systems and the r

Re: draft-ietf-nat-protocol-complications-02.txt

> Maybe we need to help make it easy to GET assignments of blocks of addresses > for individuals/small businesses/etc. Part of the problem is the obvious: > IPv4 addresses are running short. Part is the "K-Mart" level of product > understanding I've experienced with many vendors of Internet conn

Re: IPv6: Past mistakes repeated?

In message , "David A Higginbot ham" writes: >I agree! Why create a finite anything when an infinite possibility exists? >On another note, I have heard the argument that a unique identifier already >exists in the form of a MAC address why not make fu

Re: draft-ietf-nat-protocol-complications-02.txt

[Keith Moore on a "KMart box"] | take it home, plug it in to your phone line or whatever, and get | instant internet for all of the computers in your home. | (almost just like NATs today except that you get static IP addresses). No, not "or whatever" but "AND whatever". Otherwise this is a ni

Re: IPv6: Past mistakes repeated?

its ironic you should send this today, when 12 million people in london, england, had to learn to dial 8 digits instead of 7 because of lack of foresight from the telephone regualtor when re-numbering less than a decade ago - it is reported that 2--30% of calls today are misdialled... repeat aft

RE: IPv6: Past mistakes repeated?

At 07:22 AM 4/24/00 -0400, David A Higginbotham wrote: >On another note, I have heard the argument that a unique identifier already >exists in the form of a MAC address why not make further use of it? Well, because it's too Ethernet-centric, for one thing! Other transport media (suitable to tran

RE: IPv6: Past mistakes repeated?

"Near-perfect example"? I beg to differ. I used to work for a Local Exchange Carrier. The telephone number situation in the United States has been one of continual crisis for years, because of rapid growth in use (in part because of Internet access!). The area served by a given "area code" w

Re: draft-ietf-nat-protocol-complications-02.txt

--- Henning Schulzrinne <[EMAIL PROTECTED]> wrote: > It might be useful to point out more clearly the common characteristics > of protocols that are broken by NATs. These include, in particular, > protocols that use one connection to establish another data flow. Such > protocols include ftp, SIP

Re: draft-ietf-nat-protocol-complications-02.txt

At 4:32 PM +0200 4/24/00, Sean Doran wrote: >Unfortunately, IPv6's current addressing architecture makes it very >difficult to do this sort of traditional multihoming if one is not >a TLA. This is a significant step backward from the current IPv4 >situation, where one can persuade various operato

Re: IPv6: Past mistakes repeated?

Ian King wrote: > > "Near-perfect example"? I beg to differ. I used to work for a Local > Exchange Carrier. > > The telephone number situation in the United States has been one of > continual crisis for years, because of rapid growth in use (in part because > of Internet access!). The area se

Re: draft-ietf-nat-protocol-complications-02.txt

Richard Shockey wrote: > If we were looking at a typicial household and you wanted to plan for the > future I would have to assume 1 address for every single thing plugged in > to any thing, phone, electrical appliances, water, maybe even sewage. Yes > an IP address on your toilet. [...] > Busi

Re: Patent protection from NATs

Henning Schulzrinne wrote: > Indeed, I > think we should get together a group of people to patent all the > architecturally bad ideas (call it the "RSI group"), as they'll appear > sooner or later. That will give us 20 years of respite... ...provided somebody pays the legal fees to enforce the p

Re: IPv6: Past mistakes repeated?

Ian King wrote: > I'd suggest that address assignment > policy should keep process lightweight, so that it is realistic for > businesses to regularly ask for assignments in more granular chunks; rather > than grabbing a class A-size space "just in case", big users would be > willing to request an

Re: IPv6: Past mistakes repeated?

> > > The telephone number situation in the United States has been one of > > continual crisis for years, because of rapid growth in use (in part because > > of Internet access!). The area served by a given "area code" would be > split > > into smaller areas with multiple area codes; these days

RE: IPv6: Past mistakes repeated?

> On another note, I have heard the argument that a unique identifier already > exists in the form of a MAC address why not make further use of it? I can remember early TCP/IP implementations that used class A addressing only, with the host portion of the Enet MAC address as the host portion of t

Re: draft-ietf-nat-protocol-complications-02.txt

> [Keith Moore on a "KMart box"] > | take it home, plug it in to your phone line or whatever, and get > | instant internet for all of the computers in your home. > | (almost just like NATs today except that you get static IP addresses). > > No, not "or whatever" but "AND whatever". > > Otherwi

RE: Universal Network Language

Pardon my ignorance, but isn't this the function of IP? -Scot Mc Pherson, N2UPA -Sr. Network Analyst -ClearAccess Communications -Ph: 941.744.5757 ext. 210 -Fax: 941.744.0629 -mailto:[EMAIL PROTECTED] -http://www.clearaccess.net -Original Message- From: Fred Baker [mailto:[EMAIL PROTECTE

Re: IPv6: Past mistakes repeated?

>From: "Steven M. Bellovin" <[EMAIL PROTECTED]> > >In message , "David A Higginbot >ham" writes: >>I agree! Why create a finite anything when an infinite possibility exists? >>On another note, I have heard the argument that a unique identifier alread

RE: IPv6: Past mistakes repeated?

*> *> I can remember early TCP/IP implementations that used class A *> addressing only, with the host portion of the Enet MAC address as the *> host portion of the IP address - "because ARP is too hard" or *> something like that. I think the first Suns did this. *> *> -- Dick, R

Re: draft-ietf-nat-protocol-complications-02.txt

Keith Moore wrote: > it's not at all clear to me why households need traditional multihoming, > nor how to make it feasible for households to have it. so I would regard > this as overdesign of the home 'internet interface box' Now that I've got a decent DSL provider, I've found that the least r

Re: Universal Network Language

Scot Mc Pherson wrote: > Pardon my ignorance, but isn't this the function of IP? No, it turns out that what they mean by UNL is an artificial human language, a common intermediary that any human text can be translated into; they postulate translation servers that know how to translate between UN

RE: IPv6: Past mistakes repeated?

A couple of routing points, not related to NAT: > From: Ian King <[EMAIL PROTECTED]> > so that it is realistic for businesses to regularly ask for assignments > in more granular chunks; rather than grabbing a class A-size space > "just in case", big users would be willing to requ

Re: draft-ietf-nat-protocol-complications-02.txt

| it's not at all clear to me why households need traditional multihoming, | nor how to make it feasible for households to have it. so I would regard | this as overdesign of the home 'internet interface box' Three observations: 1. In the past, when and if large arrogant backb

Re: Universal Network Language

On Mon, 24 Apr 2000 15:08:40 EDT, John Stracke <[EMAIL PROTECTED]> said: > No, it turns out that what they mean by UNL is an artificial human language, a > common intermediary that any human text can be translated into; they postulate > translation servers that know how to translate between UNL a

Re: IPv6: Past mistakes repeated?

> What I find interesting throughout discussions that mention IPv6 as a > solution for a shortage of addresses in IPv4 is that people see the > problems with IPv4, but they don't realize that IPv6 will run into the > same difficulties. _Any_ addressing scheme that uses addresses of > fixed length

Re: IPv6: Past mistakes repeated?

> Users shouldn't care or know about the network's internal addressing. > Some of the application issues with NATs spring directly from this issue > (e.g. user of X-terminal setting display based on IP address instead of > DNS name). it's not the same issue. the point of using IP addresses in DI

Fw: IPv6: Past mistakes repeated?

> If what you suggest should be implemented, then > probably the entire software of all the switches > and hubs need to be upgraded (if not entirely scrapped) . That's what has to be done, anyway. I'm not sure that I see what you are saying. > As also everytime the source and destination addres

Re: draft-ietf-nat-protocol-complications-02.txt

> | it's not at all clear to me why households need traditional multihoming, > | nor how to make it feasible for households to have it. so I would regard > | this as overdesign of the home 'internet interface box' > > Three observations: > > 1. > > In the past, when and if large a

Re: IPv6: Past mistakes repeated?

> But the first thing to remember is that there are > tradeoffs. Yes, infinitely long addresses are nice, > but they're much harder to store in programs (you > can no longer use a simple fixed-size structure for > any tuple that includes an address) ... Sure you can. You just allocated the fixe

Re: IPv6: Past mistakes repeated?

> its ironic you should send this today, when 12 > million people in london, england, had to learn > to dial 8 digits instead of 7 because of lack > of foresight from the telephone regualtor when > re-numbering less than a decade ago ... France has increased the number of digits in telephone numb

RE: Universal Network Language

I totally agree with you - at least there should be a choice either user or content induced - to translate or not to translate. Also one must think of the possibility of how much the translation service or program will become another point of failure - or even a security issue. Lillian Komlossy

Re: IPv6: Past mistakes repeated?

> I agree! Why create a finite anything when an infinite > possibility exists? Exactly. If you designed an open-ended protocol, you're far less likely to ever have to rewrite it. > On another note, I have heard the argument that > a unique identifier already exists in the form of > a MAC addres

Re: IPv6: Past mistakes repeated?

> The telephone number situation in the United States > has been one of continual crisis for years, because > of rapid growth in use (in part because of Internet > access!). The area served by a given "area code" would > be split into smaller areas with multiple area codes; > these days, those ar

Re: draft-ietf-nat-protocol-complications-02.txt

Date: Mon, 24 Apr 2000 15:06:21 -0400 From: John Stracke <[EMAIL PROTECTED]> > it's not at all clear to me why households need traditional multihoming, > nor how to make it feasible for households to have it. so I would regard > this as overdesign of the home 'internet interface b

Re: IPv6: Past mistakes repeated?

Keith Moore wrote: > if by that time the robot population exceeds the human population then > I'm happy to let the robots solve the problem of upgrading to a new > version of IP. Ah--the Iron Man's Burden. :-) -- /\ |John Stracke

RE: IPv6: Past mistakes repeated?

> > making each house a TLA does not strike me as a scalable multihoming > > solution for very large numbers of houses, given the current state of > > the routing art. > > The restriction has little to do with the current state of the routing art > (which is not to say that better pat

Re: IPv6: Past mistakes repeated?

From: "Keith Moore" <[EMAIL PROTECTED]> > I suppose that's true - as long as addresses are consumed > at a rate faster than they are recycled. But the fact that > we will run out of addresses eventually might not be terribly > significant - the Sun will also run out of hydrogen > eventually, bu

Re: IPv6: Past mistakes repeated?

> > Users shouldn't care or know about the network's internal addressing. > > Some of the application issues with NATs spring directly from this issue > > (e.g. user of X-terminal setting display based on IP address instead of > > DNS name). > > it's not the same issue. the point of using IP add

correction Re: IPv6: Past mistakes repeated?

in an earlier message, I wrote: > OTOH, I don't see why IPv6 will necessarily have significantly more > levels of assignment delegation. Even if it needs a few more levels, > 6 or 7 bits out of 128 total is a lot worse than 4 or 5 bits out of 32. the last sentence contains a thinko. it should

Re: draft-ietf-nat-protocol-complications-02.txt

Sean; > [Keith Moore on a "KMart box"] > | take it home, plug it in to your phone line or whatever, and get > | instant internet for all of the computers in your home. > | (almost just like NATs today except that you get static IP addresses). > > No, not "or whatever" but "AND whatever". Do y

RE: IPv6: Past mistakes repeated?

Dick St.Peters writes: | I should probably just go back to lurking No, these are fundamentally hard problems, and nobody has real answers. What is interesting is that people haven't asked real questions either, and yet have decided that the correct approach is IPv6. | but ... my take on every |

Re: IPv6: Past mistakes repeated?

At 09:45 PM 4/24/00 +0200, Anthony Atkielski wrote: > > I agree! Why create a finite anything when an infinite > > possibility exists? > >Exactly. If you designed an open-ended protocol, you're far less likely to >ever have to rewrite it. You just have to redeploy new implementations when you ad

Re: draft-ietf-nat-protocol-complications-02.txt

Ohta-san: | > No, not "or whatever" but "AND whatever". | | Do you mean "plug THEM in to your phone line and whatever"? Yes, that is certainly one possibility. I imagine the "inside" interface would be some easy-to-wire LAN interface, enabling THEM to communicate using whatever protocol/addres

Re: IPv6: Past mistakes repeated?

personally, I can't imagine peering with my neighbors. but maybe that's just me ... or my neighborhood. Keith

Re: draft-ietf-nat-protocol-complications-02.txt

Sean Doran wrote: > > Ohta-san: > > | > No, not "or whatever" but "AND whatever". > | > | Do you mean "plug THEM in to your phone line and whatever"? > > Yes, that is certainly one possibility. I imagine the "inside" > interface would be some easy-to-wire LAN interface, enabling THEM > to com

Re: draft-ietf-nat-protocol-complications-02.txt

On Mon, Apr 24, 2000 at 04:32:38PM +0200, Sean Doran wrote: > Therefore, in order to support IPv6 house-network multihoming, so > as to preserve at least these three features of traditional > multihoming, either the current IPv6 addressing architecture's > restrictions on who can be a TLA must be

Re: IPv6: Past mistakes repeated?

> Ah ... famous last words. I feel confident that similar words were said > when the original 32-bit address scheme was developed: > > "Four billion addresses ... that's more than one computer for every person > on Earth!" > > "Only a few companies are every going to have more than a few comput

Re: draft-ietf-nat-protocol-complications-02.txt

At 08:27 PM 04/24/2000 -0400, Andrew Partan wrote: >Or seperate the end system identifer from the routing goop. This >solves lots of problems (while introducing others). Deja Vu. - paul

Re: draft-ietf-nat-protocol-complications-02.txt

asp writes: | Or seperate the end system identifer from the routing goop. This | solves lots of problems (while introducing others). Right, so in the 8+8 model, some router performs a NAT function by writing in the routing goop portion at an address abstraction boundary. The host does not need

Re: IPv6: Past mistakes repeated?

On Mon, 24 Apr 2000 21:45:43 +0200, Anthony Atkielski <[EMAIL PROTECTED]> said: > Not every machine on the Internet has an Ethernet card with a MAC address, > otherwise it might not be such a bad idea. I think using the MAC address is > an excellent idea for software protection schemes (it's a l

Re: IPv6: Past mistakes repeated?

On Mon, 24 Apr 2000 22:18:09 +0200, Anthony Atkielski <[EMAIL PROTECTED]> said: > allocate a fixed space in advance. In a variable-length address space, you > don't have to anticipate any kind of advance allocation--you can just add > digits to addresses where they are required, and routers only

Re: IPv6: Past mistakes repeated?

> > Not every machine on the Internet has an Ethernet card with a MAC address, > > otherwise it might not be such a bad idea. I think using the MAC address is > > an excellent idea for software protection schemes (it's a lot more elegant > > than a hardware key such as a dongle), but nobody seems

RE: IPv6: Past mistakes repeated?

A brief history lesson... There was some concern about a 32-bit address space. MIT-LCS proposed 48 (or 64-bit) addresses but that was coupled with a reduction of the TCP sequence number to 16 bits. After some discussion, we settled on 32-bits based on the computing resources available at the t

Re: draft-ietf-nat-protocol-complications-02.txt

> Or seperate the end system identifer from the routing goop. This > solves lots of problems (while introducing others). even if you do this the end system identifier needs to be globally scoped, and you need to be able to use the end system identifier from anywhere in the net, as a means to re

Re: draft-ietf-nat-protocol-complications-02.txt

>From: Keith Moore <[EMAIL PROTECTED]> > >> Or seperate the end system identifer from the routing goop. This >> solves lots of problems (while introducing others). > >even if you do this the end system identifier needs to be globally >scoped, and you need to be able to use the end system identifi

RE: IPv6: Past mistakes repeated?

Yes, we made a guess -- a design compromise. Folks, we're engineers, and we come up with "good enough" answers. Sure, we try to make sure that the "good enough" answers are good enough for the majority of situations, for a reasonable length of time. But we're not prophets or philosophers or pre