RE: IPv6: Past mistakes repeated?
Vinton retiring to a cabin in Montana? (..this is ominous..vaguely horrifying visions based on the "War Games" come flitting by..) Will you be leaving us any WOPRs in IPv6? :-) -Original Message- From: vinton g. cerf [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 10, 2000 5:56 AM To: [EMAIL PROTECTED]; 'Paul Robinson'; 'Tripp Lilley' Cc: 'Keith Moore'; 'Greg Skinner'; [EMAIL PROTECTED] Subject: RE: IPv6: Past mistakes repeated? At 10:39 AM 5/8/2000 -0700, Jim Stephenson-Dunn wrote: No! We don't want to fix the holes! We want to keep a record of them without telling the admins, and when they misbehave, not only can we pop their kneecaps, set fire to their house, release information to their families they wouldn't want to be released, but also as a grand finale, we can take control of the machine and do what we wanted anyway. Eventually, we as the IETF would have complete control of every machine connected to the Internet, thereby giving us control of the entire planet, which in turn would allow us to park wherever we wanted and *not*get*a*ticket*!! :-) Dang! Jim's gone and uncovered my nefarious retirement plan. Now I'll have to think of something else :-( Jim, you left out the "Nyah-ha-ha-ha-ha-ha!" part... vint p.s. apologies to IETF list for cluttering with this. It just slipped out. = I moved to a new MCI WorldCom facility on Nov 11, 1999 MCI WorldCom 22001 Loudoun County Parkway Building F2, Room 4115, ATTN: Vint Cerf Ashburn, VA 20147 Telephone (703) 886-1690 FAX (703) 886-0047 "INTERNET IS FOR EVERYONE!" See you at INET2000, Yokohama, Japan July 18-21, 2000 http://www.isoc.org/inet2000
Re: IPv6: Past mistakes repeated?
ooops, sorry, I guess it was Paul that uncovered my retirement scheme. v At 10:10 AM 5/8/2000 +0100, Paul Robinson wrote: No! We don't want to fix the holes! We want to keep a record of them without telling the admins, and when they misbehave, not only can we pop their kneecaps, set fire to their house, release information to their families they wouldn't want to be released, but also as a grand finale, we can take control of the machine and do what we wanted anyway. Eventually, we as the IETF would have complete control of every machine connected to the Internet, thereby giving us control of the entire planet, which in turn would allow us to park wherever we wanted and *not*get*a*ticket*!! :-) -- Paul Robinson - Developer/Sys Admin @ Akitanet http://www.akitanet.co.uk = I moved to a new MCI WorldCom facility on Nov 11, 1999 MCI WorldCom 22001 Loudoun County Parkway Building F2, Room 4115, ATTN: Vint Cerf Ashburn, VA 20147 Telephone (703) 886-1690 FAX (703) 886-0047 "INTERNET IS FOR EVERYONE!" See you at INET2000, Yokohama, Japan July 18-21, 2000 http://www.isoc.org/inet2000
RE: IPv6: Past mistakes repeated?
At 10:39 AM 5/8/2000 -0700, Jim Stephenson-Dunn wrote: No! We don't want to fix the holes! We want to keep a record of them without telling the admins, and when they misbehave, not only can we pop their kneecaps, set fire to their house, release information to their families they wouldn't want to be released, but also as a grand finale, we can take control of the machine and do what we wanted anyway. Eventually, we as the IETF would have complete control of every machine connected to the Internet, thereby giving us control of the entire planet, which in turn would allow us to park wherever we wanted and *not*get*a*ticket*!! :-) Dang! Jim's gone and uncovered my nefarious retirement plan. Now I'll have to think of something else :-( Jim, you left out the "Nyah-ha-ha-ha-ha-ha!" part... vint p.s. apologies to IETF list for cluttering with this. It just slipped out. = I moved to a new MCI WorldCom facility on Nov 11, 1999 MCI WorldCom 22001 Loudoun County Parkway Building F2, Room 4115, ATTN: Vint Cerf Ashburn, VA 20147 Telephone (703) 886-1690 FAX (703) 886-0047 "INTERNET IS FOR EVERYONE!" See you at INET2000, Yokohama, Japan July 18-21, 2000 http://www.isoc.org/inet2000
RE: IPv6: Past mistakes repeated?
It was Paul, I wanted to know where I got my IETF sunglasses,trench coat and neuralizer from and wheather I could nominate parking in advance. (Form an ordely queue behind paul and myself, and no pushing please) If this "just" happens to help a certain Mr. C to retire in peace and quiet and run the internet (Via IPv6) from his Montana log cabin, who am I to disagree. I still want first dibs on the parking, especially in San Francisco ;- Jim Jim Dunn Senior Network Engineer San Francisco NOC -Original Message- From: vinton g. cerf [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 10, 2000 2:58 AM To: Paul Robinson; Tripp Lilley Cc: Keith Moore; Greg Skinner; [EMAIL PROTECTED] Subject: Re: IPv6: Past mistakes repeated? ooops, sorry, I guess it was Paul that uncovered my retirement scheme. v At 10:10 AM 5/8/2000 +0100, Paul Robinson wrote: No! We don't want to fix the holes! We want to keep a record of them without telling the admins, and when they misbehave, not only can we pop their kneecaps, set fire to their house, release information to their families they wouldn't want to be released, but also as a grand finale, we can take control of the machine and do what we wanted anyway. Eventually, we as the IETF would have complete control of every machine connected to the Internet, thereby giving us control of the entire planet, which in turn would allow us to park wherever we wanted and *not*get*a*ticket*!! :-) -- Paul Robinson - Developer/Sys Admin @ Akitanet http://www.akitanet.co.uk = I moved to a new MCI WorldCom facility on Nov 11, 1999 MCI WorldCom 22001 Loudoun County Parkway Building F2, Room 4115, ATTN: Vint Cerf Ashburn, VA 20147 Telephone (703) 886-1690 FAX (703) 886-0047 "INTERNET IS FOR EVERYONE!" See you at INET2000, Yokohama, Japan July 18-21, 2000 http://www.isoc.org/inet2000
Re: IPv6: Past mistakes repeated?
Anyone want to by a 3? :) The value is not the number but its percived routablity. % % Heh. % % I know someone who wants to offer a class B at seven figures and for class B's % that "sold" for 5 figures. And you say addresses have no value. % % Ah, nostalgia. It's so nice to revisit old "discussions"... % % Rgds, % -drc % % Bill Manning wrote: % % Sigh, % Please -NOT- the PIARA again. There is near zero value in the % number/address and very real value in the routing slot. Perhaps it is % best to simply have ebone route filter on the /16 boundaries to drive % home your point. (being cranky this morning) % % % I would like to see a market develop for IPv4 addresses, along the % % lines of the late PIARA work. This would also encourage a % % market for routing-table entries, both of which would produce a significant % % incentive to dramatically improve upon on-the-fly host-renumbering. % % % % Sean. % % % % P.S. by "routing-table entries", I mean of course, not just the % % consumption of memory and CPU resources in forwarding packets % % in to large numbers of possible destinations, but also the cost % % in various resources (bandwidth, CPU, complexity) of acquiring % % and propagating information which may lead to routing-table changes. % % % % % % -- % --bill % % - % This message was passed through [EMAIL PROTECTED], which % is a sublist of [EMAIL PROTECTED] Not all messages are passed. % Decisions on what to pass are made solely by Harald Alvestrand. % -- --bill
Re: IPv6: Past mistakes repeated?
Steve, There was a similar discussion here about five years ago where some people proposed market models for address allocation and routing. Unfortunately, it's not in the archives. I think it was on CIDRD, actually, no? If anyone has this discussion archived, could they please point me to it? Well, one thing I do have is the draft of: "Suggestions for Market-Based Allocation of IP Address Blocks", by Paul Resnick (then of ATT Research, I don't know where he is now - Paul, you out there?), which I have at: http://ana-3.lcs.mit.edu/~jnc/tech/addr_charging.txt It never turned into an RFC (shame, I thought it was a really well thought out draft), and I don't think it's anywhere else permanent. See http://www.research.att.com/~smb/papers/piara/index.html, by Paul, Yakov Rekhter, and myself. This paper was also published in in "Coordination the Internet", MIT Press, 1997 (Rekhter, Y., Resnick, P., Bellovin, S., "Financial Incentives for Route Aggregation and Efficient Address Utilization in the Internet"). Yakov.
Re: IPv6: Past mistakes repeated?
"J. Noel Chiappa" [EMAIL PROTECTED] wrote: From: Greg Skinner [EMAIL PROTECTED] There was a similar discussion here about five years ago where some people proposed market models for address allocation and routing. Unfortunately, it's not in the archives. I think it was on CIDRD, actually, no? I don't think so. I vaguely recall at some point in the discussion, it was also suggested that IP addresses be maintained as trusteeships. At any rate, thanks to all for the links. --gregbo
Re: IPv6: Past mistakes repeated?
From: Greg Skinner [EMAIL PROTECTED] I think it was on CIDRD, actually, no? I don't think so. Well, it turns out that Paul Resnick's draft (which did come out as an I-D, draft-ietf-cidrd-mktbased-alloc-00.txt) was discussed at some length on CIDRD in February, 1996. But it sounds like the PIARA discussion was more extensive. Noel
Re: IPv6: Past mistakes repeated?
Tripp Lilley wrote: We came up with a wacky idea here yesterday at Interop... Why not accelerate v6 deployment by writing a virus that will upgrade end-stations' stacks? :) Even better, why doesn't the IETF employ a bunch of people dressed in black suits and wearing sun glasses to go around and 'enforce' IPv6... not as subtle I know, but administrators have this stupid habit of deleting viruses once they know what's going on, in the foolish belief that they know what is best! Pah! By sending a bunch of heavies around various Network Operations and Data Operations Centers, we can ensure the quickest possible roll-out of IPv6 under the threat of 'Big Billy' getting 'a bit wild with the baseball bat, right?' sort-of-thing. I'm sure over here in the UK we can contribute a few East-London types to help everything along nicely... That will give us the pervasive deployment needed to convince the ISPs to upgrade the core. The "upgrade" that the virus propagates can do gratuitous tunneling until it discovers that the infrastructure between it and the rest of the world has been upgraded. Indeed, your solution would get right down to the end user ultimately, which our lads would not be able to do necessarily, but if your ISP phoned you up and told you that you had to upgrade to IPv6 'or else' you would, wouldn't you? This would also help us in gaining all sorts of blackmail material about various administrators and senior managment of various ISPs used to put a little pressure on them, but would also give the IETF an additional revenue stream, and could potnetially ensure that even Microsoft started following the 'standard line'... (yes, any such toy would need to include a raft of known exploits for various Unices, so we can include them in the "upgrade") :) No! We don't want to fix the holes! We want to keep a record of them without telling the admins, and when they misbehave, not only can we pop their kneecaps, set fire to their house, release information to their families they wouldn't want to be released, but also as a grand finale, we can take control of the machine and do what we wanted anyway. Eventually, we as the IETF would have complete control of every machine connected to the Internet, thereby giving us control of the entire planet, which in turn would allow us to park wherever we wanted and *not*get*a*ticket*!! :-) -- Paul Robinson - Developer/Sys Admin @ Akitanet http://www.akitanet.co.uk Sales: T:+44 (0)1869 337088 F:+44 (0)1869 337488 E:[EMAIL PROTECTED] Techs: T:+44 (0)161 228 6388 F:+44 (0)161 228 6387 E:[EMAIL PROTECTED]
Re: IPv6: Past mistakes repeated?
In message [EMAIL PROTECTED], Paul Robinson typed: Even better, why doesn't the IETF employ a bunch of people dressed in black suits and wearing sun glasses to go around and 'enforce' IPv6... we do, but you keep forgetting. :-) j. iab member, and official "man in black"
Re: IPv6: Past mistakes repeated?
In message [EMAIL PROTECTED], Bill Manning writes: Sigh, Please -NOT- the PIARA again. There is near zero value in the number/address Right. That's why, following the publication of RFC 1631, everyone gave up on NATs as a bad idea, and no one is selling them. We all have all the addresses we want, so why bother translating? --Steve Bellovin
Re: IPv6: Past mistakes repeated?
"David R. Conrad" [EMAIL PROTECTED] wrote: Ah, nostalgia. It's so nice to revisit old "discussions"... There was a similar discussion here about five years ago where some people proposed market models for address allocation and routing. Unfortunately, it's not in the archives. If anyone has this discussion archived, could they please point me to it? Thanks. --gregbo
Re: IPv6: Past mistakes repeated?
In message [EMAIL PROTECTED], "J. Noel Chiappa" writes : From: Greg Skinner [EMAIL PROTECTED] There was a similar discussion here about five years ago where some people proposed market models for address allocation and routing. Unfortunately, it's not in the archives. I think it was on CIDRD, actually, no? If anyone has this discussion archived, could they please point me to it? Well, one thing I do have is the draft of: "Suggestions for Market-Based Allocation of IP Address Blocks", by Paul Resnick (then of ATT Research, I don't know where he is now - Paul, you out there?), which I have at: http://ana-3.lcs.mit.edu/~jnc/tech/addr_charging.txt It never turned into an RFC (shame, I thought it was a really well thought out draft), and I don't think it's anywhere else permanent. See http://www.research.att.com/~smb/papers/piara/index.html, by Paul, Yakov Rekhter, and myself. --Steve Bellovin
Re: IPv6: Past mistakes repeated?
For the archives of the historic PIARA discussions, see http://www.apnic.net/wilma-bin/wilma/piara (I think the mailing list is still alive) Rgds, -drc "Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], "J. Noel Chiappa" writes : From: Greg Skinner [EMAIL PROTECTED] There was a similar discussion here about five years ago where some people proposed market models for address allocation and routing. Unfortunately, it's not in the archives. I think it was on CIDRD, actually, no? If anyone has this discussion archived, could they please point me to it? Well, one thing I do have is the draft of: "Suggestions for Market-Based Allocation of IP Address Blocks", by Paul Resnick (then of ATT Research, I don't know where he is now - Paul, you out there?), which I have at: http://ana-3.lcs.mit.edu/~jnc/tech/addr_charging.txt It never turned into an RFC (shame, I thought it was a really well thought out draft), and I don't think it's anywhere else permanent. See http://www.research.att.com/~smb/papers/piara/index.html, by Paul, Yakov Rekhter, and myself. --Steve Bellovin - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
RE: IPv6: Past mistakes repeated?
Mathis Jim-AJM005 [EMAIL PROTECTED] wrote: We need to move forward with IPv6 both by deploying it in the "core" and setting a time-frame after which non-IPv4 compatible addresses will be assigned. Unless there is a clear reason to move, no one wants to change software just to change. Once IPv6 is in the major backhaul carriers, ISPs can role out improved services based on IPv6 which will be the real reason end-users upgrade. Seems like a real leadership vacuum here... Hmmm ... seems like the same issues are in effect with regards to deploying IPv6 in the "core", namely, no one wants to change software just to change. There don't seem to be overly compelling reasons (yet) for a significantly large number of end users to switch to IPv6 compliant technology, such that it would spur deployment of IPv6 in the critical infrastructure they use. Rather, it has spurred deployment of IPv4/NATv4. Some of you know that I like to draw parallels between the Internet and other media. One possible analogy (with US radio broadcasting) is that IPv4 is to AM as IPv6 is to FM. Licensing of FM stations and the eventual growth and development of that medium was accomplished through a variety of means, such as limiting the number of new AM licenses granted, and the development of programming on FM that became sufficiently compelling that a marketplace grew for radios that could receive both AM and FM broadcasts. This suggests that a possible key to mass deployment of IPv6 could come from stricter IPv4 address space allocation, but more likely from development of content reachable *only* via IPv6 address space. This would hopefully compel the folks who currently want to stick with IPv4/NATv4 to make/market/purchase IPv6-compliant solutions in order not to be left behind. For the record, I don't necessarily think stricter IPv4 address space allocation is a good idea. But using the US radio broadcasting analogy again, a good deal of FM licenses were issued to people who wanted to be broadcasters but had no choice but to go to FM because the FCC would not issue them an AM license. --gregbo
Re: IPv6: Past mistakes repeated?
Keith Moore writes: | the core will support v6 when it makes economic sense - i.e. when | top tier ISPs can save enough on bandwidth and support costs (as compared | to tunneling) to make the investment worthwhile. Perry Metzger had this to say a long time ago (1999 12 03): Peter made the absurd statement at DC that he'd be willing to provide v6 at some high multiple of the price of v4. Why should we bother? I can just pay 5% more for the extra bandwidth encapsulation will consume and ignore you until such time as you decide it is in your interest to offer native service. Clearly he agrees with you that the core of the Internet can effectively run IPv4ever, or at least until there is a clear advantage to running IPv6. Peter Lothberg, meanwhile, has proposed a price which would make it worthwhile for certain ISPs to become dual-protocol. I'm sure others would be interested. Maybe you guys can convince the U.S. and European Taxpayers to pay this cost through direct and indirect government grants and subsidies to ISPs and ISPs' customers, sort-of like what used to happen in the OSI days? | as for your AM vs. FM analogy - there are a variety of theories about | this, ranging anywhere from artifically making v4 addresses even | more scarce to encouraging a run on v4 address space and making them | scarce that way. I would like to see a market develop for IPv4 addresses, along the lines of the late PIARA work. This would also encourage a market for routing-table entries, both of which would produce a significant incentive to dramatically improve upon on-the-fly host-renumbering. There is no reason to believe a PIARA-style market for IPv6 addresses and routing-table entries could not also be interesting and perhaps useful. There is clearly a "price" associated with receiving a TLA allocation, namely the compliance with a number of IETF-produced rules with respect to how one conducts one's business. I counterbid $1000 in U.S. currency. Sean. P.S. by "routing-table entries", I mean of course, not just the consumption of memory and CPU resources in forwarding packets in to large numbers of possible destinations, but also the cost in various resources (bandwidth, CPU, complexity) of acquiring and propagating information which may lead to routing-table changes.
Re: IPv6: Past mistakes repeated?
Sigh, Please -NOT- the PIARA again. There is near zero value in the number/address and very real value in the routing slot. Perhaps it is best to simply have ebone route filter on the /16 boundaries to drive home your point. (being cranky this morning) % I would like to see a market develop for IPv4 addresses, along the % lines of the late PIARA work. This would also encourage a % market for routing-table entries, both of which would produce a significant % incentive to dramatically improve upon on-the-fly host-renumbering. % % Sean. % % P.S. by "routing-table entries", I mean of course, not just the % consumption of memory and CPU resources in forwarding packets % in to large numbers of possible destinations, but also the cost % in various resources (bandwidth, CPU, complexity) of acquiring % and propagating information which may lead to routing-table changes. % % -- --bill
Re: IPv6: Past mistakes repeated?
Heh. I know someone who wants to offer a class B at seven figures and for class B's that "sold" for 5 figures. And you say addresses have no value. Ah, nostalgia. It's so nice to revisit old "discussions"... Rgds, -drc Bill Manning wrote: Sigh, Please -NOT- the PIARA again. There is near zero value in the number/address and very real value in the routing slot. Perhaps it is best to simply have ebone route filter on the /16 boundaries to drive home your point. (being cranky this morning) % I would like to see a market develop for IPv4 addresses, along the % lines of the late PIARA work. This would also encourage a % market for routing-table entries, both of which would produce a significant % incentive to dramatically improve upon on-the-fly host-renumbering. % % Sean. % % P.S. by "routing-table entries", I mean of course, not just the % consumption of memory and CPU resources in forwarding packets % in to large numbers of possible destinations, but also the cost % in various resources (bandwidth, CPU, complexity) of acquiring % and propagating information which may lead to routing-table changes. % % -- --bill - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Ok, I will stop being a lurker and chime in since our draft was mentioned :- Stephen Sprunk wrote: draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of sessions within a server pool, where uncoordinated failover of sessions from one endpoint to another is a requirement. There is signifcant overheard and indirection added to the session to achieve this. Yes, I think you sum up what DDP attempts to do but I strongly disagree with your "signifcant overhead" argument. Qiaobing and I have been playing with DDP now for quite a number of years. It has some overhead on the wire (not much) since the overhead is mainly upfront i.e. when you want to go hold a talk to someone you may need to do a query to find out where it is and where all its redundant pools are. This drops in to a cache in any sensible implementation and then within some period will need to expire or be updated. Even when the cache is updated it does NOT interfere with the ongoing communication (its done in parrallel). So basically the delay overhead to talk to a peer is possibly one round trip to the local ENRP server (of course local is not necessarrily on the machine you are on but it could be :-0). In some cases there may be no delay. In particular, the ability to send to a address (pre-known) and then do a parrallel query to the ENRP deamon. We did not get this one in the draft but I am sure future updates will have this ... The point is I can't see what your "signifcant overhead" is. Yes it will take a query to get some redundancy but after 5 years of work I think we have the overhead as slim as we can... of course perhaps the working group will show us a way to reduce it further but we will see We seem to be discussing a simpler requirement: coordinated movement of a session from one ip:port pair on a single endpoint to a different ip:port pair on the same endpoint. Windows, buffer states, sequence numbers, etc. could all remain the same. In its basic state this is what DDP does do.. i.e. if you don't have multiple peers. But of course if the route fails between you and your peer, the conversations over.. until the path is back up. I would think the latter requirement could be implemented as a simple TCP "forward me" option. For ESP/AH-protected sessions, no TCP-level anti-hijacking protection seems necessary. This could even be performed if the original IP is suddenly not available and the other endpoint hasn't given up on the connection yet; you send a "forward me" packet sourced from the first IP, then listen for an ACK on the new IP. I can think of no simple way (ie. without recreating IKEAH inside TCP) to do this for unprotected sessions; I'm not sure it's worth the effort to solve either. I'm sure there's something I'm missing here, or else this would have been implemented 15 years ago... Thoughts? Yes, having worked at solving this problem for 5 years you are missing some of the subtle nature of where the different state is. You really must have a seperate state around, unless the "new IP" is attached to the same machine. In that case you end up with something that looks like SCTP to provide the redundancy, i.e. use the "new IP" address. R S | | Stephen Sprunk, K5SSS, CCIE #3723 :|::|:Network Consulting Engineer, NSA :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||:..:|||:.Email: [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: Karl Auerbach Cc: IETF Sent: Wednesday, April 26, 2000 16:48 Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?) Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms... Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? I believe that if we had such a protocol that it would be a useful tool to solve many of the juggling acts that transpire under the heading of "mobile networking" as well as providing a way to continue (or "resume") connectivity after IP address changes. (I will, of course, be suitably embarrassed if someone points out that work is already going on to do this.) draft-xie-stewart-sigtran-ddp-00.txt ned -- Randall R. Stewart Member Technical Staff Network Architecture and Technology (NAT) 847-632-7438 fax:847-632-6733
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
It seems to me that the decision to just use NATv6 rather than do a site-wide runumber will be a very easy decision to make. Actually, if your assumption is that NATv6 is better than IPv6 with renumbering, then IPv4 and NATv4 was good enough to start with and there was need to move to IPv6 in the first place. However, many people fear that NATs just won't cut it as a long-term solution, with a number of different reasons why this is so (impact on security and applications, operational and administrative costs, etc.). But if NATv4 doesn't cut it, I don't see how NATv6 between IPv6 sites cuts it either. Thomas
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
So what I am suggesting is that it seems that there is evidence that one can do an "association" protocol that is relatively lightweight in terms of machinery, packets, packet headers, and end-node state if one leaves the heavy lifting of reliability to the underlying TCP protocol. the on-the-wire protocol overhead is not that great. the computational overhead to the host and application, and the resulting loss in maximum bandwidth, are fairly expensive. basically it's a lot more efficient to do some variant of mobile IP. Keith
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Thomas Narten writes: | Actually, if your assumption is that NATv6 is better than IPv6 with | renumbering, then IPv4 and NATv4 was good enough to start with and | there was need to move to IPv6 in the first place. ^ no (right? maybe this is where the previous "not" came from -:) ) Did you see Noel's excellent observation that the problem with NAT is architectural and not mechanical? The architectural problem: more things to address on one side of the NAT than there are addresses on the other side of the NAT. IPv6 does bring *ONE* thing significantly different from IPv4: lots of address space. So much, that we do not obviously need to have situations where there is an addressability mismatch on any side of a NAT. NATv6 therefore does not suffer the architectural flaw that causes him to have real problems with NAT, although it can suffer many of the mechanical problems, particularly if IPv6 deliberately seeks to worsen the mechanical difficulties of NATv6. This allows for the architectural features of NAT to be less awkwared to exploit. | But if NATv4 doesn't cut it, I don't see how NATv6 between IPv6 | sites cuts it either. I hope this makes it clearer for you. Sean.
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
I agree completely with what you say about needing to push the multi-address complexity to the host. As you kindly pointed out (and I self-servingly expand on here), this is an architecture I put forth about a decade ago in a sigcomm paper (in Zurich, I don't remember the year). The paper "Efficient and robust policy routing using multiple hierarchical addresses " was published at the 1991 SIGCOMM, in Zurich. ACM papers used to be available on line, but it seems that the ACM now wants to enforce pay per view. (http://www.acm.org/pubs/citations/proceedings/comm/115992/p53-tsuchiya/) There is related work on an "Extended Transmission Control Protocol" available at http://www.chem.ucla.edu/~beichuan/etcp/ But that architecture (hosts having multiple addresses representing a site's multiple aggregation prefixes and selecting among them) requires some method of identifying hosts when they switch from one address to another mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful...
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful... But if the mechanisms used are the mobility mechanisms, then the security mechanisms for mobility will apply... PF
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms... Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? I believe that if we had such a protocol that it would be a useful tool to solve many of the juggling acts that transpire under the heading of "mobile networking" as well as providing a way to continue (or "resume") connectivity after IP address changes. (I will, of course, be suitably embarrassed if someone points out that work is already going on to do this.) draft-xie-stewart-sigtran-ddp-00.txt ned
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of sessions within a server pool, where uncoordinated failover of sessions from one endpoint to another is a requirement. There is signifcant overheard and indirection added to the session to achieve this. We seem to be discussing a simpler requirement: coordinated movement of a session from one ip:port pair on a single endpoint to a different ip:port pair on the same endpoint. Windows, buffer states, sequence numbers, etc. could all remain the same. I would think the latter requirement could be implemented as a simple TCP "forward me" option. For ESP/AH-protected sessions, no TCP-level anti-hijacking protection seems necessary. This could even be performed if the original IP is suddenly not available and the other endpoint hasn't given up on the connection yet; you send a "forward me" packet sourced from the first IP, then listen for an ACK on the new IP. I can think of no simple way (ie. without recreating IKEAH inside TCP) to do this for unprotected sessions; I'm not sure it's worth the effort to solve either. I'm sure there's something I'm missing here, or else this would have been implemented 15 years ago... Thoughts? S | | Stephen Sprunk, K5SSS, CCIE #3723 :|::|:Network Consulting Engineer, NSA :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||:..:|||:.Email: [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: Karl Auerbach Cc: IETF Sent: Wednesday, April 26, 2000 16:48 Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?) Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms... Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? I believe that if we had such a protocol that it would be a useful tool to solve many of the juggling acts that transpire under the heading of "mobile networking" as well as providing a way to continue (or "resume") connectivity after IP address changes. (I will, of course, be suitably embarrassed if someone points out that work is already going on to do this.) draft-xie-stewart-sigtran-ddp-00.txt ned
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Christian; But that architecture (hosts having multiple addresses representing a site's multiple aggregation prefixes and selecting among them) requires some method of identifying hosts when they switch from one address to another mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) 8+8 is not strictly necessary here unless you use locally scoped addresses. As you can see, DNS reverse and, then, forward look up is working fine for IPv4 hosts to know all the addresses of other hosts with weak security. Mobility, which does not work when home is unreachable, is no rubust and, as is often the case with a psuedo multihoming proposal, does not satisfy people needing multihoming. To make mobility rubust, it is, instead, necessary to make mobile hosts multihomed. The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful... Wrong. Use of complex and time consuming mechanisms such as IPSEC makes the system insecure vulnerable to DoS attacks. To avoid connection hijacking, cookies, such as TCP port and sequence numbers, is enough, if they are long enough. You may use optional IPSEC over it for extra security (it is more secure primarily because IPSEC keys are long cookies), but you don't need it. Masataka Ohta
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Steve Bellovin; To avoid connection hijacking, cookies, such as TCP port and sequence numbers, is enough, if they are long enough. That's preposterous. Long-enough numbers are good *if* and only if there are no eavesdroppers present. "good *if* and only if"? With cookies, a network is as secure as a telephone or fax network, which is *GOOD* enough for credit card companies. On the other hand, complex key handling mechanism introduces a lot of chances for key eavesdropping. You may use optional IPSEC over it for extra security (it is more secure primarily because IPSEC keys are long cookies), but you don't need it. Nonsense. Agreed, because TCP port and sequence numbers are long enough. Masataka Ohta
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Hi all, I guess this is somewhat unrelated to the thread's maing topic but the paper that Christian mentioned is available to everyone (as well as all papers from SIGCOMM since 91) through SIGCOMM's web site. The exact pointer for the paper mentioned below is http://www.acm.org/pubs/articles/proceedings/comm/115992/p53-tsuchiya/p53-tsuchiya.pdf regards, -andreas =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Andreas A. Terzis, | UCLA Computer Science Department http://irl.cs.ucla.edu/~terzis | Internet Research Lab On Wed, 26 Apr 2000, Christian Huitema wrote: I agree completely with what you say about needing to push the multi-address complexity to the host. As you kindly pointed out (and I self-servingly expand on here), this is an architecture I put forth about a decade ago in a sigcomm paper (in Zurich, I don't remember the year). The paper "Efficient and robust policy routing using multiple hierarchical addresses " was published at the 1991 SIGCOMM, in Zurich. ACM papers used to be available on line, but it seems that the ACM now wants to enforce pay per view. (http://www.acm.org/pubs/citations/proceedings/comm/115992/p53-tsuchiya/) There is related work on an "Extended Transmission Control Protocol" available at http://www.chem.ucla.edu/~beichuan/etcp/ But that architecture (hosts having multiple addresses representing a site's multiple aggregation prefixes and selecting among them) requires some method of identifying hosts when they switch from one address to another mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful...
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
So what I am suggesting is that it seems that there is evidence that one can do an "association" protocol that is relatively lightweight in terms of machinery, packets, packet headers, and end-node state if one leaves the heavy lifting of reliability to the underlying TCP protocol. the on-the-wire protocol overhead is not that great. the computational overhead to the host and application, and the resulting loss in maximum bandwidth, are fairly expensive. I tend to disagree. An association protocol only really does its work on connect/reconnect - hopefully a rear event -- and when the application says "let's establish a work-mark here". no, that's not the bulk of the work. the bulk of the work is just in managing the extra copies of data (applications don't want to deal with this explicitly, they want it handled by lower layers), in detecting failures, distinguishing one kind of failure from another, and in recovery. for instance, to make the handoff efficient you want to have the ability to say to your peer "please contact me on this new address" and have it do so. but that message may be delayed and meanwhile some new data might have been sent your way. so the host that is moving might also arrange to have data which was sent to its old location forwarded to the new location for a time - this saves the burden of getting the peer to retransmit everything. but the "I'm moving" message might get dropped - this is actually likely because hosts don't usually know that they're moving and you have to assume that hosts that are mobile will be disconnected from time to time. so you still need a fallback way to find your peer's connections again - and this generally means some sort of resolution service for connection endpoints. and the resolution service probably also needs some redundancy. now realize that it's quite possible for two peers to be moving on the network at the same time, with their redirect messages crossing each other and/or being dropped. etc. there are a lot of states that have to be dealt with if you want the system to be both reliable and efficient. And given that many of our applications are bursty/transactional vehicles we're not talking about supercomputers transfering bulk files of simulation data. if you're talking about a general purpose facility then it probably does need to span a wide range of applications' needs. perhaps not supercomputers exchanging large matrices, but those are hardly the only applications that care about performance and bandwidth. even lowly web servers care about performance and bandwidth. basically it's a lot more efficient to do some variant of mobile IP. Mobility is not the issue. Rather, there is use, distinct from mobilty, for an association that can persever longer than the underlying transport(s), including changes of IP addresses. if you build a level of indirection to handle this then it had better handle mobility also. and we don't need the kind of facility you're talking about just to do renumbering. nor would such a facility be sufficient, because IP addresses are kept in other places besides just TCP connection state. In my eyes, an application that uses an association protocol to deal with changes and faults in underlying connectivity is a lot more in accord with end-to-end principles than if it relied on ad hoc transport/network address juggling. either approach is end-to-end. it's just that by putting this functionality above the transport layer you end up duplicating the functionality that was already implemented at lower layers, and you have to make the resulting system fairly complex before you gain much for your trouble. OTOH, by putting the mobility at the IP layer, you can let TCP take care of the sequencing etc. and you don't have to implement it again in a higher layer. Keith
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of sessions within a server pool, where uncoordinated failover of sessions from one endpoint to another is a requirement. There is signifcant overheard and indirection added to the session to achieve this. We seem to be discussing a simpler requirement: coordinated movement of a session from one ip:port pair on a single endpoint to a different ip:port pair on the same endpoint. Windows, buffer states, sequence numbers, etc. could all remain the same. The stated requirement was "an association that will outlast the TCP connections it is based on". I saw (and see) nothing that limited this to coordinated moves set up in advance. You're right that it's a simpler problem, but the general problem is what's on the table IMO. And if ISO session layer is seen as comparable, we're *definitely* in the more general problem space. (Although whether or not ISO session layer actually solved such problems is another matter -- it sorta did on paper if you read the specifications optimistically, but it never solved any of these problems in practice. And I have the misfortunate of having had to deal with ISO session layer stuff a *lot*.) Ned
RE: IPv6: Past mistakes repeated?
For those of you who don't know, and Jim is too modest to tell you, he was a member of the Stanford team that designed and implemented the first TCP protocol versions. Later he went on to build the first versions for the portable Digital LSI-11s used in the Packet Radio network. Vint = I moved to a new MCI WorldCom facility on Nov 11, 1999 MCI WorldCom 22001 Loudoun County Parkway Building F2, Room 4115, ATTN: Vint Cerf Ashburn, VA 20147 Telephone (703) 886-1690 FAX (703) 886-0047 "INTERNET IS FOR EVERYONE!" See you at INET2000, Yokohama, Japan July 18-21, 2000 http://www.isoc.org/inet2000
Re: IPv6: Past mistakes repeated?
John Stracke [EMAIL PROTECTED] writes: Wasn't one of the design goals of IPv6 to make renumbering easier, so that people could move from small assignments to large ones? Yes. IPv6's primary tool in this regard is that it supports multiple addresses simultaneously. To renumber, you add a new address to each of your devices (corresponding to the addresses appropriate for the new ISP) and start using it. For a transition period, both addresses work equally well. When everything is switched over to the new address, you simply stop using the old address. There are mechanisms in IPv6 that make this approach straightforward (i.e., specifying when to start using the new addresses, how long to overlap using both the old and new ones, and when to finally retire the old addresses). No flag day, no need to even reboot machines. Thomas
Re: IPv6: Past mistakes repeated?
Daniel Senie wrote: Ian King wrote: From the reports I read, this was implemented by mapping phone numbers to some other tag (which the user doesn't see) which is used to get the calls to the proper carrier and ultimately to the proper user. Sounds a whole lot like using DNS to map names to IP addresses. Of course we expose users to IP addresses WAY too often, and overuse them in applications as well, for this analogy to be really workable for the Internet. It might also sound like another level of indirection would be useful. DNS - IP is sometimes difficult to manage because both can change. It would be useful to have an ID that had nothing to do with either, allowing renumbering and renaming without losing that pointer. E.g. DNS - ID - IP Joe
Re: IPv6: Past mistakes repeated?
Anthony Atkielski wrote: Exactly ... but that's the magic of the variable address scheme. You only have to allocate disparate chunks in a fixed address scheme because the size of each chunk is limited by the length of an address field. But if the address field is variable, you can make any chunk as big as you want. If you have addresses of 4739124xx initially (Metropolis only had a few machines at first), and you run out of addresses after 473912498, you just make 473912499 point to "more addresses for Metropolis," and start allocating, say 4739124990001 through 473912498 (you always leave at least one slot empty so that it can point to "more addresses"). Seems like that's very inefficient. You're building a tree. You make the tree deeper in places where you have more nodes. Even with forward-looking allocations, the tree is going to lopside toward a linear organization, and need to be rebalanced. (e.g., renumbered). No matter how conservative they are, the finite length of the address field will eventually cause problems, and much sooner than anyone thinks. And variable length addrs. will cause problems eventually too, but it'll be harder to explain why. Joe
Re: IPv6: Past mistakes repeated?
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. PS - that's what we have version numbers for. Open-ended can sometimes mean "you never know when you're exercising (exorcising) new code" too. Joe
Re: IPv6: Past mistakes repeated?
From: "Keith Moore" [EMAIL PROTECTED] I wasn't there, but I expect it would have sounded even more preposterous for someone to have said: "I'm absolutely positive that this Internet thing will reach to nearly everyone on the planet in a couple of decades, and therefore we need to make sure it has many times more than 32 bits of address space" even though that's what eventually happened. Well, I suppose it would depend on who was listening at the time. but just because it happened once doesn't mean that it will happen again. we do well to learn from the past, but the past doesn't repeat itself exactly. It often repeats itself approximately, though. And I predict that, since computer engineers have been underestimating capacity requirements for the past fifty years, they'll do it yet again this time, and then this conversation will be repeated a few decades from now. it often seems to be the case that if you design for the long term, what you get back isn't deployable in the near term because you've made the problem too hard. I dunno. I don't think that adding two more digits in the 1960s to year fields would have really made any problems too hard. It was more a question of people wanting to do things the easy way. And you can't say that it was a technological barrier, because they were still making Y2K-related mistakes into the 1980s and beyond. Also, making things hard is probably the second-most-common mistake of computer engineers. First they don't plan for the required capacity, and then they get so lost in ever-expanding features that they never actually deploy anything close to what they put in the specs. This is more a problem for software engineers than hardware enginers, though; hardware engineers are constrained by the harsh realities of actually having to build things that work, whereas software engineers can throw together buggy approximations and limp along with those indefinitely. It seems that, in the early days of [insert any major computer development here], engineers just try to get something to work--anything. Simplest is best. They make the capacity mistake, but they don't make the software-bloat mistake. However, ten years later, when they come up with the "new and improved" version of whatever major development is in question, not only do they _still_ underestimate capacity (even with past mistakes in this area staring them in the face), but they slide into the abyss of featuritis and software bloat, spending their time writing and reviewing and honing ever-more-complex specifications that nobody will be able to actually code, debut, and implement before the observable universe reaches thermal equilibrium. Sometimes the result is a "temporary" implementation that actually does the job (even though it still has the capacity problem) and eventually becomes the permaennt standard, with the original specs being relegated to dusty archives somewhere. ... the fact that we got a global Internet out of IPv4 demonstrated to people that the concept was viable. Absolutely. We just underestimated capacity requirements, as usual. with IPv6 there's a considerable amount of breathing room for address space. Why settle for a "considerable amount" (which time will show to be less considerable than first believed) when a "nearly infinite amount" can be designed into the project? address space shortage is just one of many possible problems. True, but it is much better understood than many of the others. It's a classic capacity problem. And, as in most cases of capacity problems, it's more a nuisance than something fun to work on, so it doesn't get as much attention as it probably deserves, compared to the rest. as long as the network keeps growing at exponential rates we are bound to run into some other major hurdle in a few years. It won't continue to grow at exponential rates, but it will grow in a way that doesn't match the addressing scheme, and the modes of its future growth will probably be different from anything we can expect or foresee today. So the only option is to just allow for the unforeseeable, instead of trying to predict and implement for it. we can either try to anticipate every possible hurdle that the Internet might face or we can concentrate on fixing the obvious problems now and wait for the later problems to make themselves apparent before trying to fix them. Address space is a pretty obvious problem. But as I've indicated, it's not a very exciting one. on one hand you're saying that we cannot predict how addresses will be used ... Yes. ... and on the other hand you're saying that you can definitely predict that we'll run out of IPv6 addreses very soon. No, I cannot predict that. But consider this: If a fixed-length address field is used, and we exceed the capacity of the field, we have a serious problem. If a variable-length address field is used, we do not exceed the capacity of the field, ever. And if
Re: IPv6: Past mistakes repeated?
From: [EMAIL PROTECTED] The problem is that the router guys wanted to fast-path the case of "no IP option field, routing entry in cache" so that after seeing only the first few bytes, they could know what interface to enqueue the outbound packet on *before the entire packet had even come in*. But this would be even faster with a variable-length address than with a fixed-length address. You just read address bits until you find a match, and ignore the rest. It's easy to do for an end-user workstation that's already bogged down by the bloat inherent in insert your least favorite OS vendor here. It's hard to do for something that's truly high-performance. Something that is high-performance usually costs a lot more than an end-user workstation, too, especially with the 90% gross margin that the vendor adds to the hardware price. It's reasonable to expect to get what you pay for. -- Anthony
Re: IPv6: Past mistakes repeated?
On Tue, 25 Apr 2000 20:07:05 +0200, Anthony Atkielski [EMAIL PROTECTED] said: I dunno. I don't think that adding two more digits in the 1960s to year fields would have really made any problems too hard. It was more a question You never had to fit 2 more bytes onto a punch card, did you? I'm not being facetious here - you had 80 columns and that was IT. Some databases were laid out with (for instance) exactly 3 6144-byte records per physical track on the disk. Adding 2 more digits would have dropped it to 2 per track, with a lot of wasted space - and forcing not only the consumption of 50% more disk, but also re-doing any indexing (see below for a related story). of people wanting to do things the easy way. And you can't say that it was a technological barrier, because they were still making Y2K-related mistakes into the 1980s and beyond. When I got to VT in 1989, chargeback accounts on the IBM mainframe were of the form 'nxxxy'. n was a 0-9 type code, and xxx was a 3-digit hex number and y was a single digit 0-7. Turns out that the xxx and y were the track humber and record number when the database lived on an IBM3330 disk drive. The database had since been moved to 3350, and then to 3380/3390. However, it proved to be just too much of a challenge to track down ALL the places those numbers were used and fix them. Not only does the database itself need to be redone, but you get to re-do all the userids to give them the new numbers, find ALL the JCL that has chargeback accounting information, fix all the files on secretary's PCs that have a professor-to-account lists.. the list goes on and on And we're a relatively small shop - our machine room is only 10K sqare feet.. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: IPv6: Past mistakes repeated?
On Tue, 25 Apr 2000 20:16:28 +0200, Anthony Atkielski [EMAIL PROTECTED] said: But this would be even faster with a variable-length address than with a fixed-length address. You just read address bits until you find a match, and ignore the rest. Umm.. No. "until you find a match" works totally differently in the silicon world than for programming. Today's homework assignment: Using 7400-series logic chips, design and implement an 8-bit adder (you may ignore the carry out of the high bit). For bonus credit - implement an arbitrary-length adder, the number of bits being specified in-band (do NOT use the signalling bits as input to the adder). When you understand the difference, enlightenment will soon follow. (And yes, I thought variable-length was a Cool Idea too, until one of the Cisco crew made the case for router convenience...) Somebody with a better memory than I can point at the big-internet archives, where this was all thrashed out the FIRST time... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: IPv6: Past mistakes repeated?
I dunno. I don't think that adding two more digits in the 1960s to year fields would have really made any problems too hard. you've obviously never tried to write business applications for a machine with only a few Kbytes of memory. memory was expensive in the 1960s, and limited in size. so was secondary storage. people optimized every byte, and for good reasons. And you can't say that it was a technological barrier, because they were still making Y2K-related mistakes into the 1980s and beyond. up and into the early 1980s the technological barrier was real. after that, some of the problems were habit or oversight and some of them were due to the need to backward compatibility. there's also a more subtle problem that it's difficult to maintain old software and every time you fix an old bug you stand a good chance of introducing a new one. so software tends not to get updated as long as it's mostly working. it's hardly surprising that people didn't bother to fix some of the y2k problems until they were forced to do so. Why settle for a "considerable amount" (which time will show to be less considerable than first believed) when a "nearly infinite amount" can be designed into the project? this has been explained already. "nearly infinite" imposes technological limitations which make it unimplementable at wire speeds, and thus, undeployable. and I've already addressed most of the other questions you ask, so I'm not going to respond to them again. Keith
Re: IPv6: Past mistakes repeated?
Anthony Atkielski wrote: From: [EMAIL PROTECTED] so that after seeing only the first few bytes, they could know what interface to enqueue the outbound packet on *before the entire packet had even come in*. But this would be even faster with a variable-length address than with a fixed-length address. You just read address bits until you find a match, and ignore the rest. That's *slow*. Remember, fast routers are built out of logic gates, not software. Dynamic tree structures are hard to build out of gates (no recursion). It's hard to do for something that's truly high-performance. Something that is high-performance usually costs a lot more than an end-user workstation, too, especially with the 90% gross margin that the vendor adds to the hardware price. It's reasonable to expect to get what you pay for. Well, yes. Backbone providers pay lots and lots of money to get routers that actually work. If all they got was gated running on a workstation, the backbones wouldn't be performing anywhere near current levels. (Proof: that's what the old T3 NSFNet routers were, RS/6000s with special hardware to talk to the T3. Supposedly, they couldn't even keep up with T3s, let alone modern OC-mumbles.) -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |"Collect call from reality, will you accept | |[EMAIL PROTECTED]|the--" *click* | \==/
Re: IPv6: Past mistakes repeated?
Anthony Atkielski wrote: From: "Keith Moore" [EMAIL PROTECTED] it often seems to be the case that if you design for the long term, what you get back isn't deployable in the near term because you've made the problem too hard. I dunno. I don't think that adding two more digits in the 1960s to year fields would have really made any problems too hard. Hard, no; expensive, yes. Consider a DMV system for a state with, oh, 10 million people; each person has a record with at least 3 dates (birth, license expiration, and one registration date for each car). Using 4-digit years would have required over 60MB more storage space. I don't know 1960s storage prices, but I know that 60MB would have cost enough to be worth saving. -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |Anyone who has a conditioned response| |[EMAIL PROTECTED]|immediately thinks of Pavlov.| \==/
Re: IPv6: Past mistakes repeated?
Anthony, One interesting example: OSI NSAP addresses are variable length, with a theoretical limit of 255 bytes I believe (perhaps there's an escape mechanism to grow them longer?). There was an "implementors' agreement" to limit the maximum length in actual use to 20 bytes "for now", to make implementations practical. Two things happened: (1) Almost all of the addressing plans designed for NSAPAs produced addresses that were *exactly* 20 bytes long, in some cases inserting padding in the middle of the address to fill it out to 20 bytes! I suspect that was done to make the address allocation job easier, e.g., making sure delegation boundaries fell on byte boundaries. (2) Many of the implementations ended up with the 20-byte limit wired into them, such that the use of addresses longer than 20 bytes would have required updating most of the installed base (the changes being of a similar nature to those required to modify an IPv4 application or protocol to support IPv6). This (admittedly anecdotal) example led me to surmise that: - any variable-length address scheme will have a maximum size imposed upon it, for pragmatic implementation reasons. - any variable-length address scheme will quickly degenerate into a fixed-length scheme of maximum size, for human nature reasons (the humans being the people doing the address allocation). At which point, you are back to the problem you were trying to avoid. I think the only reason this hasn't happened in the phone system is due to resistance by humans to reading, writing, and entering very long strings of digits. Unfortunately, computers aren't as fussy. Perhaps you could think of IPv6 addresses as variable-length addresses within a fixed-size container, in which the variable-length part is in the middle and not at the right hand end? :-) Anyway, as pointed out by others, the IPv6 work anticipates that there may be a need to "rebalance" the address assignments (i.e., renumber) in the future, if/when our predictions of where the growth will be turn out to be wrong, which ought to be less painful than making the changes to deployed implementations that your scheme would require whenever a significant number of addresses started to exceed the length that caused traps into the exception-handling code. And we avoid the risk of having many very long addresses (in this case, longer than 16 bytes) being used, which is important for a connectionless protocol like IP, in which the addresses are overhead in every packet. Steve
Re: IPv6: Past mistakes repeated?
address space shortage is just one of many possible problems. as long as the network keeps growing at exponential rates we are bound to run into some other major hurdle in a few years. it might be address space but the chances are good that before we hit that limitation again that we will run into some other fundamental barrier. The problem some of us have been worring about is the routing table. The routing table can either fill up or be overwhelmed by the rate of change of routing entries. There is a tradeoff between these two - no changes means that you can have a large static table; lots of changes and you will need a smaller table to have stability. Unfortunately its hard to predict when you will tip over... [EMAIL PROTECTED] (Andrew Partan)
Re: IPv6: Past mistakes repeated?
I think the only reason this hasn't happened in the phone system is due to resistance by humans to reading, writing, and entering very long strings of digits. Unfortunately, computers aren't as fussy. My experience is that as people become more (internationally) mobile their use of IDD +xx form number spec becomes more common. Likewise with major slices of the UK and Australia recently renumbered, people were forced to ditch their paper investment in old numbers and dropped into line in a semi-standard form of representation which has to be full-number aligned, because the new digits are in front of the old semi-optional prefixes. In other words, the old '7 digits is all people can handle' rule is melting in the face of a larger pool of people who have to use longer digit strings. cheers -George -- George Michaelson | DSTC Pty Ltd Email: [EMAIL PROTECTED]| University of Qld 4072 Phone: +61 7 3365 4310| Australia Fax: +61 7 3365 4311| http://www.dstc.edu.au
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Now consider the NATv6 alternative. The average net admin is already comfortable with NAT at the ISP boundary (hell, some even like it). She will already be running NAT, if for no other reason than to deal with IPv4-IPv6 transition. NATv6 is much less onerous than NATv4, because the address mapping is one to one (and in fact is probably a simple prefix rewriting, not a large table lookup), not many to one like with IPv4. What's more, NATv6 will give you some rudimentary form of multihoming (can advertise different prefixes at different ISPs)! I think your description is somewhat biased, Paul. Suppose that you execute the strategy you describe, and that the address 10.3.2.1, that was mapped to 129.87.64.32, gets transparently remapped to 130.123.45.67. It seems to me that you are going to loose all existing TCP connections, just like with any other form of renumbering. Suppose then that the external prefix of your site, 129.87.64.0/25, was used in the firewall access control lists of your business partners. Well, unless these partners somehow reprogram their firewall, the packets sourced from 130.123.45.67 are not going to get through. What? Numeric addresses in ACL is bad? Come on -- if none were used, if we only used DNS names, then renumbering would not be the problem that it is known to be! Besides, do you believe that using a NAT rather than plain renumbering would make your external DNS records to upgrade any sooner? Suppose now that you want to use NAT for multihoming. Suppose then that I really care that my TCP connection survives when I loose contact with ISP-A, the one that provided me with the prefix 129.87.64.0/25. Can I just go on routing the packets through ISP-B, that provides me with the address 130.123.45.0/25? Well, you can source them, but not receiving them, unless you convince ISP-B to announce your other /25 prefix in its BGP tables -- just like the old fashion no-NAT multihoming. And then, how exactly do you tell your customers that, among the two IP addresses of your web site, they should really use 130.123.45.3, not 129.87.64.5? Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms, in effect some form of TCP-NG, and effective multihoming requires either a single address prefix supported by multiple ISPs, or end to end smartness to pick the best of N addresses (hey, we could use *your* work for that!) As Steve pointed out, trying to convince your ISP to announce random non topological prefixes will get you laughed out of court. There is, in fact, no alternative to end-to-end smartness -- the smarter your end systems, the more likely they are to use the network correctly. Now, if your systems are smart and now how to choose one of many available addresses, then we have a solution with v6 multi-homing -- the support of multiple prefixes per site, multiple addresses per interface.
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
% Turn it any way you want, TCP sessions can only survive renumbering through % end to end mechanisms... % % Which raises the interesting (to me anyway) question: Is there value in % considering a new protocol, layered on top of TCP, but beneath new % applications, that provides an "association" the life of which transcends % the TCP transports upon which it is constructed? % % I believe that if we had such a protocol that it would be a useful tool to % solve many of the juggling acts that transpire under the heading of % "mobile networking" as well as providing a way to continue (or % "resume") connectivity after IP address changes. % % (I will, of course, be suitably embarrassed if someone points out that % work is already going on to do this.) % % --karl-- The most visable one was implemented at UCLA in 1996. Built using a per-session 32bit sequence. My idea was to use the DNS lable instead of a fixed 32bit number. A bit harder... :) --bill
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? been there, done that. yes, it is valuable. but it is expensive in terms of the amount of protocol overhead and support that you need to make it work reliably in the face of various failures. and it can be slow to recover from such failures. for instance, you have to build your own data acks on top of TCP, because if the other end of a connection changes IP addresses you cannot assume that any data already acknowledged at the TCP level was actually received by the application at the other end...and you therefore have to keep track of data that is unacknowleged by the other end in case you have to resynchronize. and you need above-TCP keepalives and redirects. and you need a separate mechanism to keep track of the current IP address and port number for each of your connection endpoints... and which gets updated independently (in case your connection with a peer drops before it has a chance to tell you where it's moving to) this separate mechanism has its own failure modes, and parts of that mechanism might also be mobile. if you had to build mobility entirely at the above-tcp level this might be a useful approach. but there are better ways to implement mobile networking. Keith
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? been there, done that. yes, it is valuable. but it is expensive in terms of the amount of protocol overhead and support that you need to make it work reliably in the face of various failures. and it can be slow to recover from such failures. for instance, you have to build your own data acks on top of TCP, There is a protocol design that did this, but we tend to shield our eyes when we look that way - OSI Session layer. It was a hideous thing indeed to read on paper and way overburdened with options. But when one got down to the wire, the actual protocol traffic was small. It didn't try to do any kind of reliability or sequencing or even sensing that a transport had died. Rather it maintained a sequence of restart points - and it was only at those points (which were triggered by the application saying "mark this point") that there were things that could be called "acks". So what I am suggesting is that it seems that there is evidence that one can do an "association" protocol that is relatively lightweight in terms of machinery, packets, packet headers, and end-node state if one leaves the heavy lifting of reliability to the underlying TCP protocol. I bet Marshall Rose has some good comments on this as he actually went and did some of this. (By-the-way, I'm not in any way suggesting OSI Session, I'm only trying to learn from the past.) --karl--
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 PROTECTED]] Sent: Monday, April 24, 2000 6:05 AM To: [EMAIL PROTECTED] Subject: 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 run out of addresses after a finite period of time, and that period may be orders of magnitude shorter than anyone might at first believe. Consider IPv4. Thirty-two bits allows more than four billion individual machines to be addressed. In theory, then, we should have enough IPv4 addresses for everyone until four billion machines are actually online simultaneously. Despite this, however, we seem to be running short of addresses already, even though only a fraction of them are actually used. The reason for this is that the address space is of finite size, and that we attempt to allocate that finite space in advance of actual use. It should be clear that IPv6 will have the same problem. The space will be allocated in advance. Over time, it will become obvious that the original allocation scheme is ill-adapted to changing requirements (because we simply cannot foresee those requirements). Much, _much_ sooner than anyone expects, IPv6 will start to run short of addresses, for the same reason that IPv4 is running short. It seems impossible now, but I suppose that running out of space in IPv4 seemed impossible at one time, too. The allocation pattern is easy to foresee. Initially, enormous subsets of the address space will be allocated carelessly and generously, because "there are so many addresses that we'll never run out" and because nobody will want to expend the effort to achieve finer granularity in the face of such apparent plenty. This mistake will be repeated for each subset of the address space allocated, by each organization charged with allocating the space. As a result, in a surprisingly short time, the address space will be exhausted. This _always_ happens with fixed address spaces. It seems to be human nature, but information theory has a hand in it, too. If you need further evidence, look at virtual memory address spaces. Even if a computer's architecture allows for a trillion bits of addressing space, it invariably becomes fragmented and exhausted in an amazingly short time. The "nearly infinite space" allowed by huge virtual addresses turns out to be very finite and very limiting indeed. The only real solution to this is an open-ended addressing scheme--one to which digits can be added as required. And it just so happens that a near-perfect example of such a scheme is right in front of us all, in the form of the telephone system. Telephone numbers have never had a fixed number of digits. The number has always been variable, and has simply expanded as needs have changed and increased. At one time, a four-digit number was enough to reach anyone. Then seven-digit numbers became necessary. Then an area code became necessary. And finally, a country code became necessary. Perhaps a planet code will be necessary at some point in the future. But the key feature of the telephone system is that nobody ever decided upon a fixed number of digits in the beginning, and so there is no insurmountable obstacle to adding digits forever, if necessary. Imagine what things would be like if someone had decided in 1900 that seven digits would be enough for the whole world, and then equipment around the world were designed only to handle seven digits, with no room for expansion. What would happen when it came time to install the 10,000,000th telephone, or when careless allocation exhausted the seven-digit space? Anyway, some keys to a successful addressing scheme, in my opinion, are as follows (but the first is the only mandatory feature, I think): 1. The number of digits used for addressing is not limited by the addressing protocol. 2. Every machine in the network need only know in detail about other points in the network that have the same high-order digits in their addresses. 3. There is a distinction for every machine between "local" addresses (those that implicitly have the same high-order digits as the address of the machine in question) and "remote" addresses (those that have different high-order digits). With such an address scheme, a single international body can allocate one digit to each region of the world (the size of the regions is irrelevant). Beneath that, other, more local bodies, one per initial digit, can allocate more digits below that. There is no need for anyone to allocate
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 related software needs to be upgraded. Personally my telephone number has changed 3 times within the last couple of years. So in this case, it is not possible to change the code of the intermediate routers every time. But yeah, the numbers can be made configurable. Although I agree that the concept being advocated is indeed revolutionary, and also might be beneficial to some extent. But the million dollar question is that whether the protocol and switch vendors would like to scrap the years and amount of investment that they have already made in the existing system. Furthur study of your proposal needs to be done !!! and can be a hot topic of discussion. Cheers !!! Manish. -- ** Nothing is Impossible, Even Impossible says I'm possible !!! ** -- Manish R. Shah. Senior Software Engineer, Future Software Pvt Ltd. 480-481, Anna Salai, Nandanam Chennai 600035. Phone: +91-(44)-433-0550 Xten 294. +++ -Original Message- From: Anthony Atkielski [SMTP:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 3:35 PM To: [EMAIL PROTECTED] Subject:IPv6: Past mistakes repeated? File: ATT1.txt; charset = Windows-1252 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 run out of addresses after a finite period of time, and that period may be orders of magnitude shorter than anyone might at first believe. Consider IPv4. Thirty-two bits allows more than four billion individual machines to be addressed. In theory, then, we should have enough IPv4 addresses for everyone until four billion machines are actually online simultaneously. Despite this, however, we seem to be running short of addresses already, even though only a fraction of them are actually used. The reason for this is that the address space is of finite size, and that we attempt to allocate that finite space in advance of actual use. It should be clear that IPv6 will have the same problem. The space will be allocated in advance. Over time, it will become obvious that the original allocation scheme is ill-adapted to changing requirements (because we simply cannot foresee those requirements). Much, _much_ sooner than anyone expects, IPv6 will start to run short of addresses, for the same reason that IPv4 is running short. It seems impossible now, but I suppose that running out of space in IPv4 seemed impossible at one time, too. The allocation pattern is easy to foresee. Initially, enormous subsets of the address space will be allocated carelessly and generously, because "there are so many addresses that we'll never run out" and because nobody will want to expend the effort to achieve finer granularity in the face of such apparent plenty. This mistake will be repeated for each subset of the address space allocated, by each organization charged with allocating the space. As a result, in a surprisingly short time, the address space will be exhausted. This _always_ happens with fixed address spaces. It seems to be human nature, but information theory has a hand in it, too. If you need further evidence, look at virtual memory address spaces. Even if a computer's architecture allows for a trillion bits of addressing space, it invariably becomes fragmented and exhausted in an amazingly short time. The "nearly infinite space" allowed by huge virtual addresses turns out to be very finite and very limiting indeed. The only real solution to this is an open-ended addressing scheme--one to which digits can be added as required. And it just so happens that a near-perfect example of such a scheme is right in front of us all, in the form of the telephone system. Telephone numbers have never had a fixed number of digits. The number has always been variable, and has simply expanded as needs have changed and increased. At one time, a four-digit number was enough to reach anyone. Then seven-digit numbers became necessary. Then an area code became necessary. And finally, a country code became necessary. Perhaps a planet code will be necessary at some point in the future. But the key feature of the telephone system is that nobody ever decided upon a fixed number of digits in the beginning, and so there is no insurmountable obstacle to adding digits forever, if necessary. Imagine what things
Re: IPv6: Past mistakes repeated?
In message BB2831D3689AD211B14C00104B14623B1E7569@HAZEN04, "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 further use of it? Would it surprise anyone to hear that all of that was considered and discussed, ad nauseum, in the IPng directorate? That's right -- we weren't stupid or ignorant of technological history. There were proponents for several different schemes, including fixed-length addresses of 64 and later 128 bits, addresses where the two high-order bits denoted the multiple of 64 to be used (that was my preference), or CLNP, where addresses could be quite variable in length (I forget the maximum). 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) and (more importantly) route, since the router has to use the entire address in making its decision. Furthermore, if it's a variable-length address, the router has to know where the end is, in order to look at the next field. (Even if the destination address comes first, routers have to look at the source address because of ACLs -- though you don't want address-based security (and you shouldn't want it), you still need anti-spoofing filters.) I should add, btw, that there's a considerable advantage to having addresses be a multiple of the bus width in size, since that simplifies fetching the next field.) As I said, I (and others) preferred a limited form of variable-length addresses. Given the various tradeoffs, we "lost". One reason is something that was pointed out by a number of people: code that isn't exercised generally doesn't work well. If we didn't have really long addresses in use from the beginning, some major implementations wouldn't support them properly. Some minor points. Using a MAC address was considered and rejected. First, not all machines have them. Second, some machines have more than one -- which should be used? Third, although MACs are supposed to be globally unique, accidents happen and there have been collisions. Fourth, they're two short -- 48 bits then, moving towards 64 bits today. Fifth, there's the issue of privacy. Sixth -- and this rules out pure geographic addressing schemes -- IP addresses are tied to the routing system. We don't know any other way to route large numbers of networks other than by using the high-order bits of the address. If you want addresses allocated geographically, your routing has to be geographic. (There have been designs for that, I should add, such as the Metropolitan Area Exchanges. But for those to work, assorted ISPs would have to co-operate on a large scale, something that I don't think will happen.) Phone numbers are allocated geographically, but that only works because historically, most areas only had one monopoly phone company. That has changed today, in many parts of the world, leading to complexities such as (in the U.S.) local number portability -- but telephone networks do one lookup per call, not one per packet. --Steve Bellovin
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" would be split into smaller areas with multiple area codes; these days, those areas aren't necessarily even contiguous. Moving from seven-digit to (effectively) ten-digit numbers was difficult, if not impossible, for some older equipment; sometimes a kludge could be developed to allow the old equipment to be used for a few more months or years, but often as not new equipment was required, at considerable cost. It was difficult for end users, too: in addition to the confusion everyone suffered during the transition (I still get scads of wrong numbers on my cellphone, because people forget the area code is needed), businesses had to spend great sums of money to revise their public appearance (advertising, letterhead, etc.). And, often as not, we'd do it all over again a few months later. My point is that ANY numbering scheme is difficult to change, once it's in place. Someone else on this thread made a good point, however, that the administration of that scheme can make worlds of difference - this person's point was about "giveaway" assignment of large portions of the address space, "because there's so much" -- hm, sounds like the exhaustion of Earth's natural resources, too. :-) 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 another 256 when the new branch office opens, then another 64 for the summer interns... and so individuals can easily get multiple addresses through an ISP. In fact, it should be as easy as getting a telephone number. -- Ian -Original Message- From: Anthony Atkielski [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 3:05 AM To: [EMAIL PROTECTED] Subject: IPv6: Past mistakes repeated? [snip] The only real solution to this is an open-ended addressing scheme--one to which digits can be added as required. And it just so happens that a near-perfect example of such a scheme is right in front of us all, in the form of the telephone system. Telephone numbers have never had a fixed number of digits. The number has always been variable, and has simply expanded as needs have changed and increased. At one time, a four-digit number was enough to reach anyone. Then seven-digit numbers became necessary. Then an area code became necessary. And finally, a country code became necessary. Perhaps a planet code will be necessary at some point in the future. But the key feature of the telephone system is that nobody ever decided upon a fixed number of digits in the beginning, and so there is no insurmountable obstacle to adding digits forever, if necessary. Imagine what things would be like if someone had decided in 1900 that seven digits would be enough for the whole world, and then equipment around the world were designed only to handle seven digits, with no room for expansion. What would happen when it came time to install the 10,000,000th telephone, or when careless allocation exhausted the seven-digit space? [snip]
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 served by a given "area code" would be split into smaller areas with multiple area codes; these days, those areas aren't necessarily even contiguous. Moving from seven-digit to (effectively) ten-digit numbers was difficult, if not impossible, for some older equipment; sometimes a kludge could be developed to allow the old equipment to be used for a few more months or years, but often as not new equipment was required, at considerable cost. It was difficult for end users, too: in addition to the confusion everyone suffered during the transition (I still get scads of wrong numbers on my cellphone, because people forget the area code is needed), businesses had to spend great sums of money to revise their public appearance (advertising, letterhead, etc.). And, often as not, we'd do it all over again a few months later. We've now got number portability. I've got a choice of local exchange carriers. I can get service from Bell Atlantic or from MediaOne. I can keep the same phone number when I move from one to the other. From the reports I read, this was implemented by mapping phone numbers to some other tag (which the user doesn't see) which is used to get the calls to the proper carrier and ultimately to the proper user. Sounds a whole lot like using DNS to map names to IP addresses. Of course we expose users to IP addresses WAY too often, and overuse them in applications as well, for this analogy to be really workable for the Internet. 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). -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
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 another 256 when the new branch office opens Wasn't one of the design goals of IPv6 to make renumbering easier, so that people could move from small assignments to large ones? -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |The cheapest, fastest, most reliable components| |[EMAIL PROTECTED]|of a computer system are those that aren't | ||there.--Gordon Bell| \/
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 areas aren't necessarily even contiguous. Moving from seven-digit to (effectively) ten-digit numbers was difficult, if not impossible, for some older equipment; sometimes a kludge could be developed to allow the old equipment to be used for a few more months or years, but often as not new equipment was required, at considerable cost. It was difficult for end users, too: in addition to the confusion everyone suffered during the transition (I still get scads of wrong numbers on my cellphone, because people forget the area code is needed), businesses had to spend great sums of money to revise their public appearance (advertising, letterhead, etc.). And, often as not, we'd do it all over again a few months later. We've now got number portability. I've got a choice of local exchange carriers. I can get service from Bell Atlantic or from MediaOne. I can keep the same phone number when I move from one to the other. FYI And by 2002 you will be able to port your number from your land line phone service to your cell phone as well...that is called "service portability". From the reports I read, this was implemented by mapping phone numbers to some other tag (which the user doesn't see) which is used to get the calls to the proper carrier and ultimately to the proper user. Yep ...essentially phone numbers are nothing more than names to the IN. FYI there is a ID on how the Number Portability system works and there have been recent FCC rulings on Number Conservation and Pooling which direct teleco's not to hoard phone numbers or else they will be taken away. It is a system that has worked remarkably well and is rapidly being adopted my many other countries as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-np-00.txt Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail IFAX : [EMAIL PROTECTED] GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464
Re: IPv6: Past mistakes repeated?
From: "Steven M. Bellovin" [EMAIL PROTECTED] In message BB2831D3689AD211B14C00104B14623B1E7569@HAZEN04, "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 further use of it? Would it surprise anyone to hear that all of that was considered and discussed, ad nauseum, in the IPng directorate? That's right -- we weren't stupid or ignorant of technological history. There were proponents for several different schemes, including fixed-length addresses of 64 and later 128 bits, addresses where the two high-order bits denoted the multiple of 64 to be used (that was my preference), or CLNP, where addresses could be quite variable in length (I forget the maximum). 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) and (more importantly) route, since the router has to use the entire address in making its decision. Furthermore, if it's a variable-length address, the router has to know where the end is, in order to look at the next field. (Even if the destination address comes first, routers have to look at the source address because of ACLs -- though you don't want address-based security (and you shouldn't want it), you still need anti-spoofing filters.) I should add, btw, that there's a considerable advantage to having addresses be a multiple of the bus width in size, since that simplifies fetching the next field.) Routers may use the different addresses for routing. Outbound router may assign "route address" to keep intermediate route tables small. It is not the same as NAT because original and real destination address never replaced. - Leonid Yegoshin.
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, Right idea, wrong link layer. The low-order 24 bits of an IP address was originally a 24-bit ARPANET (/Milnet/DDN) host address. Bob Braden
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 request another 256 when the new branch office opens, then another 64 for the summer interns... Sorry, this doesn't work - at least with IPvN (N=4,6) addresses as currently constituted. The routing system (i.e. the software that computes paths through the network) uses those addresses as the namespace it works on, and to make the routing scale properly (a.k.a. "keep the network running"), those addresses have to be aggregable. In other words, you need to be able to have a single routing table entry that covers a chunk of the network (such as a company's in-house network) - and that routing table entry can't include other things as well. If a company, etc, had addresses assigned in dribs and drabs, the way you suggest, that company's addresses would no longer have that property. Other namespaces, which don't have to include location information, just identification (e.g. IEEE 48-bit numbers) work just fine with this kind of allocation policy - but not any namespace used by path selection in a large network. From: Steve Deering [EMAIL PROTECTED] 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 path-selection architectures than the one the Internet is currently using do not exist :-). Even with the best routing system, it still couldn't support tracking large numbers of houses as individual destinations (i.e. having individual routing tables extries across the global scope) - even if the routers had large enough route table memories to hold the 100's of millions of routes which could result. Noel
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 will run out of addresses after a finite period of time, 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, but in the meantime we still find it useful. and that period may be orders of magnitude shorter than anyone might at first believe. it is certainly true that without careful management IPv6 address space could be consumed fairly quickly. but to me it looks like that with even moderate care IPv6 space can last for several tens of years. Consider IPv4. Thirty-two bits allows more than four billion individual machines to be addressed. not really. IP has always assumed that address space would be delegated in power-of-two sized "chunks" - at first those chunks only came in 3 sizes (2**8, 2**16, or 2**24 addresses), and later on it became possible to delegate any power-of-two sized chunk. but even assuming ideally sized allocations, each of those chunks would on average be only 50% utilized. so every level of delegation effectively uses 1 of those 32 bits, and on average most parts of the net are probably delegated 4-5 levels deep. (IANA/regional registry/ISP/customer/internal). so we end up effectively not with 2**32 addresses but with something like 2**27 or 2**28. (approximately 134 million or 268 million) (see also RFC 1715 for a different analysis, which when applied to IPv4, yields similar results for the optimistic case) allocating space in advance might indeed take away another few bits. but given the current growth rate of the internet it is necessary. the internet is growing so fast that a policy of always allocating only the smallest possible chunk for a net would not only be cumbersome, it would result in poor aggregation in routing tables and quite possibly in worse overall utilization of address space. but if it someday gets easier to renumber a subnet we might then find it easier to garbage collect, and recycle, fragmented portions of address space. and if the growth rate slowed down (which for various reasons is possible) then we could do advance allocation more conservatively. It should be clear that IPv6 will have the same problem. The space will be allocated in advance. Over time, it will become obvious that the original allocation scheme is ill-adapted to changing requirements (because we simply cannot foresee those requirements). Much, _much_ sooner than anyone expects, IPv6 will start to run short of addresses, for the same reason that IPv4 is running short. It seems impossible now, but I suppose that running out of space in IPv4 seemed impossible at one time, too. IPv6 allocation will have some of the same properties of IPv4 allocation. We're still using power-of-two sized blocks, we'll still waste at least one bit of address space per level of delegation. It will probably be somewhat easier to renumber networks and recycle address - how much easier remains to be seen. 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 allocation pattern is easy to foresee. Initially, enormous subsets of the address space will be allocated carelessly and generously, because "there are so many addresses that we'll never run out" I don't know where you get that idea. Quite the contrary, the regional registries seem to share your concern that we will use up IPv6 space too quickly and *all* of the comments I've heard about the initial assignment policies were that they were too conservative. IPv6 space does need to be carefully managed, but it can be doled out somewhat more generously than IPv4 space. and because nobody will want to expend the effort to achieve finer granularity in the face of such apparent plenty. First of all, having too fine a granularity in allocation prevents you from aggregating routes. Second, with power-of-two sized allocations there's a limit to how much granularity you can get - even if you always allocate optimal sized blocks. This mistake will be repeated for each subset of the address space allocated, by each organization charged with allocating the space. It's not clear that it's a mistake. it's a tradeoff between having aggregatable addresses and distributed assignment on one hand and conserving address space on the other. and the people doing address assignment these days are quite accustomed to thinking in these terms. If you need further evidence, look at virtual
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 DISPLAY variables is not to make them visible to the user - it's because using the IP address is (in a non-NATted network) far more reliable than depending on the DNS lookup to work. the fact that doing this makes the address more visible to the user is just a side effect; most users don't care diddly about it one way or the other as long as it works. Keith
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 fixed space generously, _and_ you include code that traps any address with more bytes than you can handle. If that ever happens, you rebuild your table with a larger fixed space. You might include code to catch addresses that approach the limit so that you have time to rebuild the table at your leisure, rather than when the routing actually fails, of course. ... and (more importantly) route, since the router has to use the entire address in making its decision. Why does it need the entire address? You only need the entire address if addresses are assigned arbitrarily from the address space, such that no subset of the complete address is in itself sufficient to complete any portion of the routing. That is indeed a problem today, with address allocation that does not necessarily strictly following routing requirements. But that was imposed by the very fact of trying to 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 need to look at enough of an address to figure out where it should go next. In a variable-length scheme, you can be sure that any address that begins with 19283 always goes down the route you have for 19283, no matter what the remaining digits are. (Naturally, you could route with finer granularity at some nodes, if you wanted to, but you wouldn't necessarily be obligated to do that.) Furthermore, if it's a variable-length address, the router has to know where the end is, in order to look at the next field. Just put that up front. For example, prefix the address with a length byte. If the byte is zero, the address is four bytes long (compatible with IPv4). If it is one, the address is five bytes long. And so on, up to 254+4= 258 bytes long. If the byte is 255, however (unlikely, but this scheme would provide for _any_ address length), then the _next_ byte specifies additional bytes to be added to 254 (i.e., lengths of 254 through 508 bytes). This second byte follows the same pattern, and so on. You'll never run out of addresses this way, ever. It's not really hard. You just have to write the code up front to handle it. And if you don't want to allow for infinite capacity (you have to stop somewhere, in any practical implementation), you just make darn sure that you have code that will trap any address longer than you can handle. If anything ever hits the trap, you change some parameters and recompile, and you're back online. Even if the destination address comes first, routers have to look at the source address because of ACLs -- though you don't want address-based security (and you shouldn't want it), you still need anti-spoofing filters. Hmm... I don't know. If you restrict the address field to routing only, do you still need anti-spoofing? A given address can lead to only one endpoint, unless I'm missing something here. One reason is something that was pointed out by a number of people: code that isn't exercised generally doesn't work well. If we didn't have really long addresses in use from the beginning, some major implementations wouldn't support them properly. It's a lot easier to fix a bug than to rewrite the protocol from scratch when it runs out of capacity. There have been designs for [geographic addressing], I should add, such as the Metropolitan Area Exchanges. But for those to work, assorted ISPs would have to co-operate on a large scale, something that I don't think will happen. Why would they have to cooperate in a variable-length scheme? They would only allocate addresses on their branch. They could route within their branch without knowing or caring about other branches (as long as they know the high-order digits identifying their own branches, which someone else would assign to them). And if they ever saw addresses with high-order digits that didn't match their own assigned digits, they'd know that the address meant "elsewhere." Of course, finer granularity would be possible, but not required. That's how telephones work. If you call someone in Mongolia from the U.S., the U.S. exchanges don't have to know or care about the trailing digits in the number; they only have to look at enough of the number to know to route the call towards Mongolia. Can you imagine what the telephone system would be like if every country had to know every detail about the numbering system of every other country? Phone numbers are allocated geographically, but that only works because historically, most areas only had one monopoly phone company. That's not a requirement. Just assign additional
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 numbers several times over the past 20 years, and it has always been without a hitch. Each time the telco has prepared for a barrage of misdials, just in case, but they have never materialized. Currently, numbers are ten digits long, everywhere in the country, although the first digit is actually a selector for your chosen local telco provider (0 = France Telecom, the historical operator). -- Anthony
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 address why not make further use of it? 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 interested in that. In any case, this latter application is outside the scope of Internet discussions. -- Anthony
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 areas aren't necessarily even contiguous. That is mostly because the telco(s) tried to impose a fixed address length on a scheme that really should have remained variable. Telephone numbers overseas are truly variable. When you dial 011+3, the remaining digits can be anywhere from one to a thousand. The local end just stores them all until you say you are done (by pausing or hitting the # key), and then it routes it as far as it can, and passes the rest onto some other node. 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 ... But if you use a truly variable scheme, you don't have to assign anything at all. Say Company X wants some addresses, and it is in an area where all addresses start with 9482. You just add some digits, tell them what they are, and they can add as many addresses as they want behind those digits. All you have to care about is that 94825x gets routed to Company X. The rest of the address allocation is their business. They might have just two digits on the end, or they might have forty. With fixed-length addresses, you're in trouble as soon as you make an assignment. You might assign 9482 through 9482 to Company X. The problem is that, if Company X needs only 200 addresses, you've wasted 9800 addresses, and you can't give them to anyone else. Conversely, if Company X ever needs more than 1 addresses, you have to completely reallocate everything, or fragment their address range. Either way, you lose. ... big users would be willing to request another 256 when the new branch office opens, then another 64 for the summer interns... All well and good, except that it fragments the address space, making it impossible to route on just a portion of the address--you have to start looking at the entire address, all the time. -- Anthony
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| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |Beware of wizards, for you are crunchy and good| |[EMAIL PROTECTED]|with ketchup. | \/
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 path-selection architectures than the one the Internet is currently using do not exist :-). Even with the best routing system, it still couldn't support tracking large numbers of houses as individual destinations (i.e. having individual routing tables extries across the global scope) - even if the routers had large enough route table memories to hold the 100's of millions of routes which could result. I should probably just go back to lurking, but ... my take on every house being multihomed was to imagine full local meshing - each house peering with its neighbors redundantly. If, say, my power-line port was down, that information needn't be known by anything outside my own neighborhood. When the local power distribution center couldn't get a power-grid packet to me directly, they'd give it to my neighbor and let his smart house determine whether to send it to mine by wireless or cable or whatever else has come along. The rest of the world could just engage in some kind of "get it closer" routing. Don't ask me about mobile users. I'm going back to lurking ... -- Dick St.Peters, [EMAIL PROTECTED] Gatekeeper, NetHeaven, Saratoga Springs, NY Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/ GlensFalls/LakePlacid/NorthCreek/Plattsburgh/... Oldest Internet service based in the Adirondack-Albany region
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, but in the meantime we still find it useful. 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 computers ... just give a Class A to anyone who asks." And so now we are running out. But the real thing here is, even with the wisest allocations imaginable, we would still run out much, much faster than the total number of addresses in the address space might lead one to believe. And that is because we have to _predict_ how addresses will be used, and we cannot easily change the consequences of those predictions. So there are always significant blocks of unused addresses, even as we run out of addresses in other ways. it is certainly true that without careful management IPv6 address space could be consumed fairly quickly. but to me it looks like that with even moderate care IPv6 space can last for several tens of years. Ten years, I'd say. And then redefining a new addressing scheme will cost a thousand times more than it will today, at least. Even washing machines will have to get new programming! not really. IP has always assumed that address space would be delegated in power-of-two sized "chunks" ... Aye, there's the rub. It has always been necessary to _assume_ and _delegate_ address space, because the address space is finite in size. It has always been necessary to predict the future, in other words, in a domain where the future is very uncertain indeed. ... at first those chunks only came in 3 sizes (2**8, 2**16, or 2**24 addresses), and later on it became possible to delegate any power-of-two sized chunk. But by then, a lot of the biggest chunks were already in use. ... but even assuming ideally sized allocations, each of those chunks would on average be only 50% utilized. Right. So the only solution is to get rid of the need to allocate in advance in the first place. Think of variable addressing and the needs of the tiny country of Vulgaria. Vulgaria needs address space. Okay, so you say, well, Vulgaria is in, say, Eastern Europe, and all addresses in Eastern Europe begin with 473. All the addresses from 4731 to 4738 are taken. So you add address 4739, which now means "everyone else in Eastern Europe," and you assign 47391 to Vulgaria. That's all you have to do. If Vulgaria wants to further subdivide, it can; it can assign 473911 to Northern Vulgaria, and 473912 to the rugged Vulgarian Alps region. It doesn't matter to anyone except Vulgaria. Given this, North America doesn't have to change anything at all. Before, anything that started with 473 went to Eastern Europe, and that's still the case. Some European routers have to smarten up a bit, because now they have to be aware that 4739 goes to another routing point that handles "all other" Eastern European countries. And this new routing point (heck, maybe Vulgaria will host it, eh?) must know that 47391 goes to Vulgaria, but nothing more. Only routers in Vulgaria itself need to care where 473911 goes as compared to 473912. And only routers in the rugged Vulgarian Alps need to know that 4739124 goes to Smallville, and 4739126 goes to Metropolis, both cities nestled there in the Alps. And since the addressing scheme is open ended, even if Vulgaria one day has ten trillion computers on the Net, nothing outside Vulgaria needs to change. allocating space in advance might indeed take away another few bits. but given the current growth rate of the internet it is necessary. Only with a fixed address space. the internet is growing so fast that a policy of always allocating only the smallest possible chunk for a net would not only be cumbersome, it would result in poor aggregation in routing tables and quite possibly in worse overall utilization of address space. Exactly ... but that's the magic of the variable address scheme. You only have to allocate disparate chunks in a fixed address scheme because the size of each chunk is limited by the length of an address field. But if the address field is variable, you can make any chunk as big as you want. If you have addresses of 4739124xx initially (Metropolis only had a few machines at first), and you run out of addresses after 473912498, you just make 473912499 point to "more addresses for Metropolis," and start allocating, say 4739124990001 through 473912498 (you always leave at least one slot empty so that it can point to "more addresses"). I don't know where you get that idea. That's how it happened for IPv4. Quite the contrary, the
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 DISPLAY variables is not to make them visible to the user - it's because using the IP address is (in a non-NATted network) far more reliable than depending on the DNS lookup to work. the fact that doing this makes the address more visible to the user is just a side effect; most users don't care diddly about it one way or the other as long as it works. Keith The default DISPLAY variable for an X Server on the local machine is unix:0 This means contact the 0th display attached to the 0th X Server on the local machine. When you make a connection to a remote machine you cannot count on the return from gethostname() is going to have any relationship to the name in the DNS. Not to mention that on a multi-homed machine you need to be able to choose the IP address that is actually accessible to the remote. So what you do is look at the IP address on the local end of the socket that is being used to connect to the remote system and insert that IP address into the exported DISPLAY variable. This has of course worked for 20 years and fails when a NAT is in the middle. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
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 read: 6 or 7 bits out of 128 total is a lot better than 4 or 5 bits out of 32. (I originally wrote the comparison in the other order, but when I swapped sides, forgot to change the direction of the comparison.) Keith
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 add new features. "Open-ended" isn't helping us in extending DHCP. That's not to say a practical, extensible, open-ended protocol can't be written... - Ralph
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: 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 computers ... just give a Class A to anyone who asks." I wasn't there, but I expect it would have sounded even more preposterous for someone to have said: "I'm absolutely positive that this Internet thing will reach to nearly everyone on the planet in a couple of decades, and therefore we need to make sure it has many times more than 32 bits of address space" even though that's what eventually happened. but just because it happened once doesn't mean that it will happen again. we do well to learn from the past, but the past doesn't repeat itself exactly. it often seems to be the case that if you design for the long term, what you get back isn't deployable in the near term because you've made the problem too hard. and if you design for the near term, what you get back will break in the long term. but at least you get somewhere with the latter approach - the fact that we got a global Internet out of IPv4 demonstrated to people that the concept was viable. today's design constraints aren't the same as tomorrow's. with today's Internet a lack of address space is a big problem. with IPv6 there's a considerable amount of breathing room for address space. address space shortage is just one of many possible problems. as long as the network keeps growing at exponential rates we are bound to run into some other major hurdle in a few years. it might be address space but the chances are good that before we hit that limitation again that we will run into some other fundamental barrier. we can either try to anticipate every possible hurdle that the Internet might face or we can concentrate on fixing the obvious problems now and wait for the later problems to make themselves apparent before trying to fix them. if we try to anticipate every major hurdle, we will never agree on how to solve all of those problems, and the Internet will bog down to the point that it's no longer useful. But the real thing here is, even with the wisest allocations imaginable, we would still run out much, much faster than the total number of addresses in the address space might lead one to believe. And that is because we have to _predict_ how addresses will be used, and we cannot easily change the consequences of those predictions. no, that's just bogus. on one hand you're saying that we cannot predict how addresses will be used, and on the other hand you're saying that you can definitely predict that we'll run out of IPv6 addreses very soon. Ten years, I'd say. right now you're just pulling numbers out of thin air. you have yet to give any basis whatsoever to make such a prediction credible. not really. IP has always assumed that address space would be delegated in power-of-two sized "chunks" ... Aye, there's the rub. It has always been necessary to _assume_ and _delegate_ address space, because the address space is finite in size. wrong. you need to make design assumptions about delegation points, and delegate portions of address space, even for variable length addresses of arbitrary size. ... at first those chunks only came in 3 sizes (2**8, 2**16, or 2**24 addresses), and later on it became possible to delegate any power-of-two sized chunk. But by then, a lot of the biggest chunks were already in use. true, several of the class A blocks were already in use by then. but initial allocations of IPv6 space are much more conservative . ... but even assuming ideally sized allocations, each of those chunks would on average be only 50% utilized. Right. So the only solution is to get rid of the need to allocate in advance in the first place. no. even with variable length addresses you want to exercise some discipline about how you allocate addresses. otherwise you end up some addresses being much longer than necessary, and this creates inefficiency and problems for routing. allocating space in advance might indeed take away another few bits. but given the current growth rate of the internet it is necessary. Only with a fixed address space. nope. even phone numbers are allocated by prefix blocks. the internet is growing so fast that a policy of always allocating only the smallest possible chunk for a net would not only be cumbersome, it would result in poor aggregation in routing tables and quite possibly in worse overall utilization of address space. Exactly ... but that's the magic of the variable address scheme. You only have to allocate disparate chunks in a fixed address scheme because the size of each chunk is limited by the length of an address field. no, there are lots of other reasons for doing it. you seem to be forgetting that routing
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 lot more elegant than a hardware key such as a dongle), but nobody seems interested in that. Nobody is interested in it because it doesn't work. The Ethernet spec requires that each card have a unique MAC address that's burnt onto the card. However, due to some truly wierd stuff done by DecNet "way back when", cards were *also* required to support loading a new MAC address on the fly. So to pirate a softare package that locks based on the MAC address, all you have to do is pirate it off any compatible machine on any subnet other than your own. You can even pirate it off your own subnet if you don't care about ARP working. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech
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 need to look at enough of an address to figure out where it should go next. In a Actually, we argued a *lot* about fixed/variable. The reason 128 bit fixed won out was to a large extent due to the people from various large high-performance router companies wanting a way to switch packets *quickly*. At the time, a DS3 was considered REALLY fast, and only a few places had FDDI campus backbones. The problem is that the router guys wanted to fast-path the case of "no IP option field, routing entry in cache" so that after seeing only the first few bytes, they could know what interface to enqueue the outbound packet on *before the entire packet had even come in*. So for them, the idea of being able to take a known fixed-lenght field that happened to line up nicely on the hardware memory cache lines, stuffing it through an associative-lookup cache or other hardware assist, and knowing in one or three cycles how to route it, was VERY enticing. Of course, an OC48 instead of a DS3 only makes it more crucial - do the math, and figure out how many nanoseconds you have to make a routing decision when reading off an OC48... Furthermore, if it's a variable-length address, the router has to know where the end is, in order to look at the next field. Just put that up front. For example, prefix the address with a length byte. If the byte is zero, the address is four bytes long (compatible with IPv4). It's not really hard. You just have to write the code up front to handle it. And if you don't want to allow for infinite capacity (you have to stop It's easy to do for an end-user workstation that's already bogged down by the bloat inherent in insert your least favorite OS vendor here. It's hard to do for something that's truly high-performance. Hmm... I don't know. If you restrict the address field to routing only, do you still need anti-spoofing? A given address can lead to only one endpoint, unless I'm missing something here. Well, at least around here, we also look at the *source* address on all packets inbound to our routers to see if they make sense. If it's coming in from off-campus, it shouldn't have a prefix that belongs to our AS. If it's coming into our backbone from a building subnet, the source better be in that subnet's range. And so on. RFC2267 talks about it in more detail. Valdis Kletnieks Operating Systems Analyst Virginia Tech
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 prescient -- we're just engineers. We made some "good enough" guesses with IPv4 that, as Keith points out, got us to the situation of a global Internet -- and our present dilemma is a byproduct of that solution's success. I would not be disappointed if our next "good enough" guess lasts us as long as the last one. After all, I'll want SOMEthing entertaining to do twenty years from now. :-) BTW -- I feel the same way about NAT: it's "good enough" for many situations. :-) Send me mail at home, it goes to one machine on my internal 172.16 LAN; check out my personal webpages, you're talking to another machine (and a different OS) in that address space. You don't see that, and frankly I don't think about it very often. It's close to a "it just works" solution -- which is "good enough" for now. -- Ian -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 5:38 PM To: Anthony Atkielski Cc: [EMAIL PROTECTED] Subject: Re: IPv6: Past mistakes repeated? [snip] but this same impossibility means that we do not know whether we should put today's energy into making variable length addresses work efficiently or into something else. so we made a guess - a design compromise - that we're better off with very long fixed-length addresses because fast routing hardware is an absolute requirement, and at least today it seems much easier to design fast routing hardware (or software) that looks at fixed offsets within a packet, than to design hardware or software that looks at variable offsets. [snip]
