Let me make some general comments. I think people are missing some of the fundamental architectural concepts of IPv6. Indeed, I was one of the people in the final vote (well, consensus) at the Toronto IETF where we decided on 128 versus 64 bits.
It is NOT the intention of IPv6 to expand the address space so that everyone can have their own static address. Addresses have two distinct functions that coexist in IPv4, but that IPv6, not completely cleanly, tries to separate. These functions are location and identification. Location is routing-oriented and tells you how to get somewhere. Identification identifies a specific host or interface. In very general terms, the high-order 64 bits of a v6 address are used mostly for location, to reach a particular scope called a "site." The next 64 bits identify (potentially with levels of aggregation), hosts within that site. Again simplifying greatly, renumbering to a new carrier requires you to change the locator but not the identifier. Moving a host within a scope may require you to change the identifier but not the locator. There are some forms of multihoming that aren't completely solved, and the multi6 Working Group is trying to come up with strateies. The high-order locator part has at least three levels of aggregation for public addressing: Top-Level Aggregator, Second-Level Aggregator, and Next-Level Aggregator. At 11:25 PM -0400 4/30/02, Michael L. Williams wrote: >Comments inline.... > >"Priscilla Oppenheimer" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> > however, it seems in an attempt to make >> >addressing a convenience (where it doesn't take skill to understand and >do >> >it), there will be wasted space...... Absolutely, positively, the architects intended to waste some space to avoid some of the convolutions we go through with V4. > > >> So? 128 bits is a lot of bits. In fact, there's more waste than you may >> realize. In a number of the formats, Interface IDs are required to be 64 >> bits long and to be constructed in IEEE EUI-64 format. EUI-64 based >> Interface identifiers may have global scope when a global token is >> available (e.g., IEEE 48-bit MAC) or may have local scope where a global >> token is not available (e.g., serial links, tunnel end-points, etc.) > >So? Isn't it dangerous to approach a new technology (128-bit addressing >scheme) with such a "ah, who cares if we waste.... there's so much" >attitude? I realize 128 bits is alot of bits now..... but I also remember >when 640K was alot of memory ("no one will ever need more than 640K").... There was some fairly extensive analysis done to suggest that we have to get considerably off the planet before 128 bits turns out not to be enough. I can't cite the specific RFCs, but they are among the V6 documents. Also look for a couple of RFCs that talk about the "H ratio" for address space. > I >remember when 32-bits of address space (IPv4) was considered endless, so why >bother conserving address space, etc..... and now look at where we are.... >Now we have to use NAT at every turn to "reuse" 10.x.x.x and 192,168.x.x on >private and corporate LANs because "real" IPs are so scarce. Now ISPs give >you the 3rd degree, mounds of paperwork, and many times request usage >details for you to justfy that /26 they allocated to you.... These problems >could have been avoided with IPv4 with better address management and >allocation ( I mean, MIT and IBM both have their own /8s... neither >organization could dream of using all 16.7 million of those addresses.... >that equals major waste)... but again, that was back when "32-bits was alot >of bits"..... so we shouldn't view 128-bits as a lot of bits.... for that >matter, IMHO, we should treat every new address as a precious commodity as >we do IPv4 addresses now...... > >> Regarding IPv6 autoconfiguration addresses, I'm no expert. You'll want to >> read the RFCs to answer those questions. But I think your fears about > > summarization are unfounded. RFC 2723 says this: "IPv6 unicast addresses >> are aggregatable with contiguous bit-wise masks similar to IPv4 addresses >> under Class-less Interdomain Routing [CIDR]." > >So that RFC2723 is saying is that IPv6 has the ability to be aggregatable >like IPv4 under CIDR. Great... but ability to be aggregated means nothing >if the addresses are discontiguously allocated (i.e. are allocated in a >manner that isn't condusive to aggregation), as is the case with IPv4 >currently. You may be missing that the high-order (itself subdivided) and low-order parts are assigned separately. One can change without affecting the other, in most cases. >If IPv4 addresses were allocated properly, BGP routing tables >would be 4MB, not 128MB. No, probably not, because we see the trend that users want to multihome in a manner that simply is not conducive to aggregation. Other schemes are being discussed, such as scoping the propagation of announcements up to, but not beyond, a point where providers peer and the individual customer is lost in the noise. The concept of having the global routing table EVER fully converge and stay converged is no longer a goal. Current interdomain research is more in the direction of convergence at the level of domains and some aggregates of domains, then exchanging general information at a higher level -- let's call it federation. > I know you understand allocating addresses in a >manner that makes summarization possible, and you know there are ways to >assign addresses (poorly) that keeps an adminstrator from being able to >summarize. So even tho IPv4 (and IPv6) support aggregation, if allocated >improperly, the aggregation "feature" vanishes......that's all I was saying >........ > >> >The only people that want > > >"auto-addressing", IMHO, want it out of laziness... No. In V6, it's often to deal with various problems of changing providers and of mobility. Believe me, as the author of RFC 2072 on V4 router renumbering, it's a quite different situation when, in V6, you have a Router Renumbering Protocol. > > >> People don't want autoconfiguration because of laziness. They want it >> because sometimes there's no network administrator available and maybe >> there never was one available (to set up a server, for example). Take the >> typical kitchen, laundry room (your washing machine may have a L3 address >> some day), car, space station, hotel lobby, Starbucks, park, real-estate >> office, many other small offices, etc. > >Point well taken..... My comment about laziness was off target..... As you >mention, in the future cars, toasters, washing machines, etc will be using >IP and so there needs to be a good methods for these devices to obtain an >IP..... (perhaps they could just be embedded like MACs are)....... > >> You made fun of AppleTalk, but there is an IETF movement afoot to >> standardize user-friendliness, autoconfiguration, and many other AppleTalk >> themes. See the work of the Zero Configuration Networking working group >here: > >Hey! I wasn't making fun of AppleTalk..... just pointing out things I >thought were lame =) I can't really explain it... it's just a nagging >feeling..... oh... that's just my dog pulling on my pants leg.... =) > >But, it seems to me that, even on Macs, if AppleTalk were that easy to >setup/use and administer, then why has TCP/IP pretty much crushed it (along >with IPX, etc....)? Something that works very well in a local environment doesn't necessarily scale to global, and vice versa. V6 attempts to combine global and local optimizations in different parts of the addresss. >I guess my point is, ease of configuration and user >friendliness, although niceties, will always take a back seat to core >functionality and compatibility. And any sort of autoconfiguration isn't >worth the price if it autoconfigures at the expense of proper address >allocation. > >Also keep in mind that the Zero Configuration Networking, no matter how well >thought out or planned, will be just like any other "Zero" anything (i.e. >Zero Effort Networking (Z.E.N. Works) ala Novell) and will be anything but >Zero configuration/effort, etc... =) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42950&t=42913 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
