From bmanning at vacation.karoshi.com Mon Feb 5 11:14:56 2001 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Feb 2001 16:14:56 +0000 (UCT) Subject: a revised IAB/IESG document Message-ID: <200102051614.QAA27946@vacation.karoshi.com> draft-iesg-ipv6-addressing-recommendations-00.txt A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iesg-ipv6-addressing-recommendations-0 0.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iesg-ipv6-addressing-recommendations-00.txt". ... Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-iesg-ipv6-addressing-recommendations-00.txt ". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. From narten at raleigh.ibm.com Wed Feb 7 10:35:58 2001 From: narten at raleigh.ibm.com (Thomas Narten) Date: Wed, 07 Feb 2001 10:35:58 -0500 Subject: a revised IAB/IESG document Message-ID: <200102071535.f17FZwt01511@hygro.adsl.duke.edu> draft-iesg-ipv6-addressing-recommendations-00.txt which recently became available is an update of the statement posted by the IESG/IAB to various mailing lists on 9/1/2000. The intention of this revision is to clarify and refine that text, rather than to change the overall recommendation. In particular, it attempts to incoporate feedback received from the presentations on the recommendation made to the three registries (RIPE, ARIN, and APNIC). I just looked at a diff of the changes, and there are enough individual changes that is hard to summarize them. The one that I think is worth pointing out is that the text surrounding the explanation of the H Ratio has been redone. I'm including it here for convenience: - [RFC1715] defines an "H ratio" based on experience in address space assignment in various networks. The H ratio varies between 0 and 0.3, with larger values denoting denser, more efficient assignment. Experience shows that problems start to occur when the H ratio becomes greater than 0.25. At an H ratio of 0.25, a 45 bit address space would have 178 billion (178 thousand million) identifiers. H = log10(178*10^9) / 45 = 0.25 This means that we feel comfortable about the prospect of allocating 178 billions /48 prefixes under that scheme before problems start to appear. To understand how big that number is, one has to compare 178 billion to 10 billion, which is the projected population on earth in year 2050 (see http://www.popin.org/pop1998/). However, there are other wording improvements as well, so I would encourate you all to read the new ID. Comments are welcome of course. Also, Scott Marcus' suggested changes didn't make it into the current version, but will be included in the next version. Thomas From narten at raleigh.ibm.com Wed Feb 7 11:18:01 2001 From: narten at raleigh.ibm.com (Thomas Narten) Date: Wed, 07 Feb 2001 11:18:01 -0500 Subject: Closure? In-Reply-To: Message from Shane Kerr of "Tue, 30 Jan 2001 10:35:30 +0100." Message-ID: <200102071618.f17GI1X01962@hygro.adsl.duke.edu> Shane, > Actually, I am worried by both the overconfidence and the apparent > classfulness and inflexibility of IPv6. We've started with 128 bits, > threw away half, split the rest up on 16-bit boundaries and now we're > left with 13 bits to play with all of a sudden. Just to clarify the above point. I believe it is a misunderstanding of the intent of the various IPv6 addressing documents to compare them with classful addressing. The only firm boundaries within addresses that have been defined by the architecture are the 64/64 split (routing part and interface identifier). This was done as an explicit engineering tradeoff decision in which the benefits of stateless address autoconfiguration were believed to be large, and the belief that leaving 64 bits for routing left more than ample room for being able to address the number of networks as called for in the original IPng requirements. >From the architecture's perspective (and from what implementations know about), addresses are just 128 bits long. From a routing perspective, longest match is done. The internal address boundaries as specified in RFC 2374 (for example) are really there for address assignment and management, not because implementations need to be aware of them. Indeed, no IPv6 document that I am aware of calls for (or even suggests) that an implementation might want to take those boundaries into consideration. Having said that, the concern that implementations (hardware or software) might hardcode such boundaries has been heard from several sources, so I suspect that more forceful wording on this point would be useful. But I think that wording is probably more important to have in other IPv6 documents than in the addressing recommendation under discussion here. > The analysis that > "well, it's only 1/8 of the available space" is fundamentally > flawed, I don't think folks are making this argument to justify giving /48 everywhere. Or if they are, I certainly don't agree with this line of reasoning. What I believe folks *are* saying though is they believe that 45 bits of heirarchy is really a lot, and *is* sufficient to allow the giving out of /48s. However, do note that if the analysis is turns out to be flawed (not that we expect it to be) we do still quite a lot of remaining space that we can use more conservatively. Thomas From smarcus at genuity.com Wed Feb 7 12:06:41 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Wed, 07 Feb 2001 12:06:41 -0500 Subject: a revised IAB/IESG document In-Reply-To: <200102071535.f17FZwt01511@hygro.adsl.duke.edu> Message-ID: <3.0.5.32.20010207120641.029d4600@pobox3.genuity.com> > ... To understand how big that number is, > one has to compare 178 billion to 10 billion, which is the > projected population on earth in year 2050 (see > http://www.popin.org/pop1998/). > A nit with the draft: the URL is no longer good. My sense from a quick look at the site is that the UN is now SELLING these reports! FWIW, the report at http://www.undp.org/popin/wdtrends/urbanization.pdf shows a population of 7.15 billion in 2015, and 8.11 billion in 2030. An alternative would be to cite the original study as a document rather than a URL. From hinden at iprg.nokia.com Wed Feb 7 13:29:36 2001 From: hinden at iprg.nokia.com (Bob Hinden) Date: Wed, 07 Feb 2001 10:29:36 -0800 Subject: a revised IAB/IESG document In-Reply-To: <3.0.5.32.20010207120641.029d4600@pobox3.genuity.com> References: <200102071535.f17FZwt01511@hygro.adsl.duke.edu> Message-ID: <4.3.2.7.2.20010207100859.025a3ed8@mailhost.iprg.nokia.com> I agree that referencing the real document is good. I did find several places on the site with the 10B in 2050 data: http://www.undp.org/popin/wdtrends/p98/tp98pwld.htm http://www.undp.org/popin/wdtrends/chart/3.pdf http://www.undp.org/popin/wdtrends/p98/p98cht2.htm I also found an interesting table of Countries with a population of over 100 million in 1950, 1998 and 2050: http://www.undp.org/popin/wdtrends/p98/tp98cht0.htm The interesting thing that the majority of these countries don't have any significant IP address allocations today. Bob At 12:06 PM 2/7/2001 -0500, J. Scott Marcus wrote: > > ... To understand how big that number is, > > one has to compare 178 billion to 10 billion, which is the > > projected population on earth in year 2050 (see > > http://www.popin.org/pop1998/). > > > > >A nit with the draft: the URL is no longer good. My sense from a quick >look at the site is that the UN is now SELLING these reports! > >FWIW, the report at http://www.undp.org/popin/wdtrends/urbanization.pdf >shows a population of 7.15 billion in 2015, and 8.11 billion in 2030. An >alternative would be to cite the original study as a document rather than a >URL. From smarcus at genuity.com Wed Feb 7 13:47:03 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Wed, 07 Feb 2001 13:47:03 -0500 Subject: a revised IAB/IESG document In-Reply-To: <4.3.2.7.2.20010207100859.025a3ed8@mailhost.iprg.nokia.com> References: <3.0.5.32.20010207120641.029d4600@pobox3.genuity.com> <200102071535.f17FZwt01511@hygro.adsl.duke.edu> Message-ID: <3.0.5.32.20010207134703.008e0330@pobox3.genuity.com> At 10:29 02/07/2001 -0800, Bob Hinden wrote: >I agree that referencing the real document is good. I did find several >places on the site with the 10B in 2050 data: > > http://www.undp.org/popin/wdtrends/p98/tp98pwld.htm > http://www.undp.org/popin/wdtrends/chart/3.pdf > http://www.undp.org/popin/wdtrends/p98/p98cht2.htm > >I also found an interesting table of Countries with a population of over >100 million in 1950, 1998 and 2050: > > http://www.undp.org/popin/wdtrends/p98/tp98cht0.htm > >The interesting thing that the majority of these countries don't have any >significant IP address allocations today. Thanks, Bob! :-) Interesting that the table at http://www.undp.org/popin/wdtrends/p98/tp98pwld.htm shows 8.9B people in 2050. Presumably, this is the mid-range estimate, while the ID figure of 10B in 2050 is based on the high range estimate? That would be consistent with the graph in the third URL, http://www.undp.org/popin/wdtrends/p98/p98cht2.htm But it does not much matter for these purposes; the difference between 9B and 10B has no effect whatsoever on the conclusions. From hinden at iprg.nokia.com Wed Feb 7 14:12:04 2001 From: hinden at iprg.nokia.com (Bob Hinden) Date: Wed, 07 Feb 2001 11:12:04 -0800 Subject: a revised IAB/IESG document In-Reply-To: <3.0.5.32.20010207134703.008e0330@pobox3.genuity.com> References: <4.3.2.7.2.20010207100859.025a3ed8@mailhost.iprg.nokia.com> <3.0.5.32.20010207120641.029d4600@pobox3.genuity.com> <200102071535.f17FZwt01511@hygro.adsl.duke.edu> Message-ID: <4.3.2.7.2.20010207110314.01c40630@mailhost.iprg.nokia.com> Scott, >Thanks, Bob! :-) You are welcome! >But it does not much matter for these purposes; the difference between 9B >and 10B has no effect whatsoever on the conclusions. Right, the 10B number is the worst case. Bob From randy at psg.com Thu Feb 8 02:52:48 2001 From: randy at psg.com (Randy Bush) Date: Wed, 07 Feb 2001 23:52:48 -0800 Subject: classful addressing considered harmful [was Re: Closure?] References: <200102071618.f17GI1X01962@hygro.adsl.duke.edu> Message-ID: [ please excuse the roughness and sloppiness of this. i am at the end of weeks on the road, and utterly jet slagged ] > Just to clarify the above point. I believe it is a misunderstanding of > the intent of the various IPv6 addressing documents to compare them > with classful addressing. the scheme in 2374 sec 3.1 seems to segment the address space with [TNS]LA boundaries based on lightly specified socio-political theories of how much space different kinds of entities will need. to many of us crass and under-educated operators, this does not appear to be much different than the classic and classful A, B, and C design. this whole subject we have been discussing seems to say o we don't really know what those boundaries should be today, but are trying to make a stab at it in the practices document under discussion o the current /35 suggested isp allocation is not even in the 'addressing architecture' and seems too lightly treated in the document under discussion. yet it is of critical interest to the ops community (and many suspect it needs adjusting) o the size to be given by iana to rirs has not even been described. the /29 being discussed does not map to any of the boundaries in 2374 o many folk strongly suspect that the tla-for-global-isp idea is lawyer chum > The only firm boundaries within addresses that have been defined by the > architecture are the 64/64 split (routing part and interface identifier). huh? so 2374 sec 3.1 and its proposed update are not firm, yet it is going for draft status? i am more confused than usual. allow me to quote "Top-Level Aggregation Identifiers (TLA ID) are the top level in the routing hierarchy. Default-free routers must have a routing table entry for every active TLA ID ..." this would seem to take a poorly-substantiated socio-political theory and mandate its enshrinement in the core of v6 routing. while we ops folk appreciate that it is kindly trying to reduce route explosion, doing so on a fixed boundary for a routing protocol we hope will last more than the two decades of ipv4 seems, shall we say, optimistic. some relevant lessons we might take from v4 are o i suspect that the folk who did A, B, and C thought they would be useful and expected them to last forever. it seems they may have had a social view of network addressing topology [0] o fixed unicast boundaries became a serious problem, yet people had coded them in software and protocols (e.g. RIPv1), and we have regretted it sorely o the only useful boundary was that between uni- and multi-cast, i.e. one where protocols must treat things very differently o the soft socio-political allocation boundaries move in time, from /18 (pre danvers), to /19 (on a widespread consensus), and recently /20 (by arin's unilateral act) so i suggest that o non-technical boundaries such as tlas, ... need to be omitted from standards (as opposed to practice) documents o this document, the allocation best current practice description, should be the main place we describe these socio-political boundaries. and we appreciate the word 'current' in this context. o gse/8+8 is the type of thing for which we should place boundaries in standards randy --- [0] rfc791 is the first i found with a, b, and c. it says "To provide for flexibility in assigning address to networks and allow for the large number of small to intermediate sized networks the interpretation of the address field is coded to specify a small number of networks with a large number of host, a moderate number of networks with a moderate number of hosts, and a large number of networks with a small number of hosts. In addition there is an escape code for extended addressing mode." some earlier documents are instructive ien-111 and 115 had only what we think of as A addressing, 8/24 ien-122 mapped hardware issues ien-162 used the second octet to add hierarchy ien-170 and 171 tried to deal with the hardware hierarchy rfc760 still had only 8/24 -30- From brian at hursley.ibm.com Thu Feb 8 16:39:59 2001 From: brian at hursley.ibm.com (Brian E Carpenter) Date: Thu, 08 Feb 2001 15:39:59 -0600 Subject: classful addressing considered harmful [was Re: Closure?] References: <200102071618.f17GI1X01962@hygro.adsl.duke.edu> Message-ID: <3A83122F.B364D00A@hursley.ibm.com> Randy Bush wrote: > > [ please excuse the roughness and sloppiness of this. i am at the end of > weeks on the road, and utterly jet slagged ] It's more coherent than most of the mail on the ietf list... > > > Just to clarify the above point. I believe it is a misunderstanding of > > the intent of the various IPv6 addressing documents to compare them > > with classful addressing. > > the scheme in 2374 sec 3.1 seems to segment the address space with [TNS]LA > boundaries based on lightly specified socio-political theories of how much > space different kinds of entities will need. to many of us crass and > under-educated operators, this does not appear to be much different than > the classic and classful A, B, and C design. IPv6 is intrinsically based on VLSNs with the boundaries in the TLA format being administratively overlayed. I think that is an important difference from classful IPv4. Also there are moveable boundaries within the fields of the address, which give CIDR like properties. But you are correct that there is an assumption about the topology being unflat to the extent of having backbone operators who get a TLA, many more regional operators who don't, and sites that hang off the regionals. If reality doesn't look like that, the entropy will be worse than we hoped. > this whole subject we have been discussing seems to say > > o we don't really know what those boundaries should be today, but are > trying to make a stab at it in the practices document under discussion Well, the field sizes were not chosen at random. 13 bits for the TLA = 8k backbone operators. With 200 countries in the world, that seems a lot. > o the current /35 suggested isp allocation is not even in the 'addressing > architecture' and seems too lightly treated in the document under > discussion. yet it is of critical interest to the ops community (and > many suspect it needs adjusting) It might, but have we seen enumerated topology scenarios to show that it might? > o the size to be given by iana to rirs has not even been described. the > /29 being discussed does not map to any of the boundaries in 2374 No, why does it need to? It's not inconsistent with 2374. > o many folk strongly suspect that the tla-for-global-isp idea is lawyer > chum Only if you make "what is a backbone" into a judgement call. If we have precise and non-discriminatory criteria we ought to avoid the lawyers. But this certainly has to be worked out very carefully. In fact I thought it was covered in the *existing* RIR policies on IPv6 allocation such as http://www.ripe.net/ripe/docs/ripe-196.html . They are written for sub-TLAs but transforming them for TLAs is straightforward. > > The only firm boundaries within addresses that have been defined by the > > architecture are the 64/64 split (routing part and interface identifier). > > huh? so 2374 sec 3.1 and its proposed update are not firm, yet it is going > for draft status? i am more confused than usual. allow me to quote > > "Top-Level Aggregation Identifiers (TLA ID) are the top level in the > routing hierarchy. Default-free routers must have a routing table > entry for every active TLA ID ..." > > this would seem to take a poorly-substantiated socio-political theory and > mandate its enshrinement in the core of v6 routing. while we ops folk > appreciate that it is kindly trying to reduce route explosion, doing so on > a fixed boundary for a routing protocol we hope will last more than the two > decades of ipv4 seems, shall we say, optimistic. They are only administrative boundaries. BGP4 and other routing protocols won't know anything about them. Maybe 2374 should have been a BCP not a Draft Standard; but we certainly need the administrative boundaries globally agreed if TLA aggregation is to have any chance. > some relevant lessons we might take from v4 are > > o i suspect that the folk who did A, B, and C thought they would be > useful and expected them to last forever. it seems they may have had a > social view of network addressing topology [0] Indeed. hence it's important that the TLA boundaries are administrative only > o fixed unicast boundaries became a serious problem, yet people had coded > them in software and protocols (e.g. RIPv1), and we have regretted it > sorely Indeed. Nobody should code in anything except the 64/64 boundary and one or two of the special case format prefixes. > o the only useful boundary was that between uni- and multi-cast, i.e. one > where protocols must treat things very differently > > o the soft socio-political allocation boundaries move in time, from /18 > (pre danvers), to /19 (on a widespread consensus), and recently /20 (by > arin's unilateral act) Indeed. And no doubt the IPv6 boundaries will slide. > > so i suggest that > > o non-technical boundaries such as tlas, ... need to be omitted from > standards (as opposed to practice) documents that's an IESG debate, but you have a point IMHO. It doesn't change any technical proposal. > > o this document, the allocation best current practice description, should > be the main place we describe these socio-political boundaries. and we > appreciate the word 'current' in this context. not sure I can parse "this document". There is no proposal that I know of to change RFC 2374 . draft-iesg-ipv6-addressing-recommendations-00.txt builds on 2374, and is clearly a current practice document that only makes sense if the RIRs agree to it. > > o gse/8+8 is the type of thing for which we should place boundaries in > standards Yes, although that actually places three boundaries (6+2+8) where today we have two architecturally (8+8) with the other ones being admin. Brian > > randy > > --- > > [0] rfc791 is the first i found with a, b, and c. it says > > "To provide for flexibility in assigning address to networks and > allow for the large number of small to intermediate sized networks > the interpretation of the address field is coded to specify a small > number of networks with a large number of host, a moderate number of > networks with a moderate number of hosts, and a large number of > networks with a small number of hosts. In addition there is an > escape code for extended addressing mode." > > some earlier documents are instructive > > ien-111 and 115 had only what we think of as A addressing, 8/24 > ien-122 mapped hardware issues > ien-162 used the second octet to add hierarchy > ien-170 and 171 tried to deal with the hardware hierarchy > rfc760 still had only 8/24 > > -30- From hinden at iprg.nokia.com Thu Feb 8 17:06:36 2001 From: hinden at iprg.nokia.com (Bob Hinden) Date: Thu, 08 Feb 2001 14:06:36 -0800 Subject: classful addressing considered harmful [was Re: Closure?] In-Reply-To: References: <200102071618.f17GI1X01962@hygro.adsl.duke.edu> Message-ID: <4.3.2.7.2.20010208131820.01f0a440@mailhost.iprg.nokia.com> Randy, Please excuse the roughness of my reply. I am not that articulate even when I am not jet lagged :-) I think there is still much confusion. The major problem with IPv4's class-full addressing was that the boundaries in the address were built into implementations and into routing protocols. The network part of the address was derived by looking at the bits in the address. This made it impossible to add new prefix lengths without changing all of the implementations and routing protocols. We even had routing protocols that only carried the bits of the network part (i.e., not the full address). Even BGP started out without a prefix length. It was added when we invented CIDR. IPv4 today is still class-full in how multicast addresses are distinguished from unicast (i.e., uses class D), and the non-global prefixes (net 10, etc.). These are built into implementations. All other unicast addresses are not predefined in implementations and the network part is distinguished from the host part by a prefix length. IPv6 follows the same model as IPv4 with CIDR. With just about the same exceptions as IPv4, IPv6 addresses are class-less. The exceptions are defined in section 2.8 of the addressing architecture document. These are: o Multicast Prefix (FF) o Local-Use Prefixes (Link-Local and Site-Local) o Pre-Defined Multicast Addresses o IPv4-Compatible Prefixes IPv6 implementation do not have any other built in knowledge about the boundaries in the addresses. Like IPv4, IPv6 uses prefixes. It uses CIDR. IPv6 routing protocols carry prefixes. Just like IPv4 with CIDR. You argued that the /64 boundary is a class-full boundary. This is a middle ground. It is from an address creation point of view. As Thomas pointed out, this was a tradeoff to make auto-configuration simple. However, it is not from a routing and forwarding point of view. I think the distinction is important. All of the other "boundaries" are for allocation purposes. They do not affect forwarding and routing. They can be changed with having to change any implementations. As you pointed out the /35 prefix was not defined in a standard. The main point I am trying to make is that IPv6 is no more class-full than IPv4 is today. Bob p.s. The history behind of the TLA/NLA structure is that it is generally based on work that came out of Mike O'Dell's 8+8/GSE proposal. That had a similar top level structure. The specifics of the current TLA/NLA fields were worked out with Mike and I sitting at one of tables in the hotel lobby at Memphis, Tennessee IETF meeting. I think this was before the ducks came down from the roof :-) From Gilbert.Martin at za.didata.com Fri Feb 9 00:35:50 2001 From: Gilbert.Martin at za.didata.com (Gilbert Martin @ Learning Solutions) Date: Fri, 9 Feb 2001 07:35:50 +0200 Subject: classful addressing considered harmful [was Re: Closure?] Message-ID: I think none of us are articulate at any stage... Lets see if ten or so years if this gives any issues and well if it does make it the next generations problem... -----Original Message----- From: Bob Hinden [mailto:hinden at iprg.nokia.com] Sent: Friday, February 09, 2001 12:07 AM To: Randy Bush Cc: Thomas Narten; v6wg at arin.net Subject: Re: classful addressing considered harmful [was Re: Closure?] Randy, Please excuse the roughness of my reply. I am not that articulate even when I am not jet lagged :-) I think there is still much confusion. The major problem with IPv4's class-full addressing was that the boundaries in the address were built into implementations and into routing protocols. The network part of the address was derived by looking at the bits in the address. This made it impossible to add new prefix lengths without changing all of the implementations and routing protocols. We even had routing protocols that only carried the bits of the network part (i.e., not the full address). Even BGP started out without a prefix length. It was added when we invented CIDR. IPv4 today is still class-full in how multicast addresses are distinguished from unicast (i.e., uses class D), and the non-global prefixes (net 10, etc.). These are built into implementations. All other unicast addresses are not predefined in implementations and the network part is distinguished from the host part by a prefix length. IPv6 follows the same model as IPv4 with CIDR. With just about the same exceptions as IPv4, IPv6 addresses are class-less. The exceptions are defined in section 2.8 of the addressing architecture document. These are: o Multicast Prefix (FF) o Local-Use Prefixes (Link-Local and Site-Local) o Pre-Defined Multicast Addresses o IPv4-Compatible Prefixes IPv6 implementation do not have any other built in knowledge about the boundaries in the addresses. Like IPv4, IPv6 uses prefixes. It uses CIDR. IPv6 routing protocols carry prefixes. Just like IPv4 with CIDR. You argued that the /64 boundary is a class-full boundary. This is a middle ground. It is from an address creation point of view. As Thomas pointed out, this was a tradeoff to make auto-configuration simple. However, it is not from a routing and forwarding point of view. I think the distinction is important. All of the other "boundaries" are for allocation purposes. They do not affect forwarding and routing. They can be changed with having to change any implementations. As you pointed out the /35 prefix was not defined in a standard. The main point I am trying to make is that IPv6 is no more class-full than IPv4 is today. Bob p.s. The history behind of the TLA/NLA structure is that it is generally based on work that came out of Mike O'Dell's 8+8/GSE proposal. That had a similar top level structure. The specifics of the current TLA/NLA fields were worked out with Mike and I sitting at one of tables in the hotel lobby at Memphis, Tennessee IETF meeting. I think this was before the ducks came down from the roof :-) ********************************************************************** The information in this e-mail is confidential and is legally privileged. It is intended solely for the addressee. If this email is not intended for you, you cannot copy, distribute, or disclose the included information to any-one If you are not the intended recipient please delete the mail. Whilst all reasonable steps have been taken to ensure the accuracy and integrity of all data transmitted electronically, no liability is accepted if the data, for whatever reason, is corrupt or does not reach it's intended destination. All business is undertaken, subject to our standard trading conditions which are available on request. ******************************************************************* From craig at your-GAME.com Tue Feb 27 18:14:40 2001 From: craig at your-GAME.com (Craig Martin) Date: Tue, 27 Feb 2001 18:14:40 -0500 Subject: Closure? References: Message-ID: <009301c0a113$1015f960$1bcdcdcd@craigspc> Hi There, My name is Craig Martin and I am fairly new to this mailing-list. I am an eager computer and internet hobbyist (besides it being my job!), and as such have signed up to this ARIN mailing list to try to learn more about the IPv6 recommendations. Obviously there is a lot of acronyms and the such flying around in these e-mails to save time for all of you who are up to date on this stuff, but for myself, I am having a hard time understanding some of it. Thus, I have 2 question for you (if you don't mind!): 1. Where can I get my hands on some basic-intermediate info on IPv6 to allow me to better understand it and what is being discussed in this group? 2. What are the /35 and /48 and /64 all about? As far as I can tell they are subnetting (CIDR notation), but I only know the ones for subnetting a Class C license which as you probably know are /24 to /32. What are the higher numbers you are talking about? (Or am I completely off base?!?) Any help with this would be much appreciated. Thanks in advance. Later, Craig Martin ----- Original Message ----- From: Shane Kerr To: J. Scott Marcus Cc: Sent: Tuesday, January 30, 2001 4:35 AM Subject: Re: Closure? > On Mon, 29 Jan 2001, J. Scott Marcus wrote: > > > Again, the recommendation is probably workable. I am worried about > > the underlying overconfidence. > > This is my position as well. > > Actually, I am worried by both the overconfidence and the apparent > classfulness and inflexibility of IPv6. We've started with 128 bits, > threw away half, split the rest up on 16-bit boundaries and now we're > left with 13 bits to play with all of a sudden. The analysis that > "well, it's only 1/8 of the available space" is fundamentally flawed, > because problems with allocation of that first block may impact the use > of the rest of the space. IPv6 folks at the IETF think that people who > disagree with their recommendation simply don't understand it - not > true! I, at least, simply disagree. The "broad concensus and > acceptance" within other RIR communities is probably a combination of > eagerness to roll out new networks and excessive trust in the IETF > recommendation, rather than a well-thought out assessment of possible > problems. > > But let's be realistic. It doesn't really matter WHAT the RIR space > usage recommendations are. If I get a /35 from APNIC, ARIN, or the RIPE > NCC, then if I'm at all smart about my allocations, then I won't ever > need more space. There's no reason for me to allocate /48, /64, or any > other specific allocation. Unless the RIR's decide to monitor > allocations and REVOKE IPv6 space, any recommendation will carry even > less weight than TTL suggestions for DNS servers (I was going to say > something about recommendations to put name servers on seperate > networks, but that would be an unfair jab at a certain well-known > company, I suppose...). > > Shane > > From hinden at iprg.nokia.com Tue Feb 27 19:19:31 2001 From: hinden at iprg.nokia.com (Bob Hinden) Date: Tue, 27 Feb 2001 16:19:31 -0800 Subject: Closure? In-Reply-To: <009301c0a113$1015f960$1bcdcdcd@craigspc> References: Message-ID: <4.3.2.7.2.20010227161820.025ca1e0@mailhost.iprg.nokia.com> Craig, >1. Where can I get my hands on some basic-intermediate info on IPv6 to allow >me to better understand it and what is being discussed in this group? You look on: http://playground.sun.com/ipng That site has lots of info on IPv6. Bob From jfleming at anet.com Tue Feb 27 19:35:54 2001 From: jfleming at anet.com (Jim Fleming) Date: Tue, 27 Feb 2001 18:35:54 -0600 Subject: Closure? In-Reply-To: <009301c0a113$1015f960$1bcdcdcd@craigspc> Message-ID: Craig, If you are interested in using IPv6 to establish an IPv8 cloud, then the links below may help. http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif -----Original Message----- From: owner-v6wg at arin.net [mailto:owner-v6wg at arin.net]On Behalf Of Craig Martin Sent: Tuesday, February 27, 2001 5:15 PM To: Shane Kerr; J. Scott Marcus Cc: v6wg at arin.net Subject: Re: Closure? Hi There, My name is Craig Martin and I am fairly new to this mailing-list. I am an eager computer and internet hobbyist (besides it being my job!), and as such have signed up to this ARIN mailing list to try to learn more about the IPv6 recommendations. Obviously there is a lot of acronyms and the such flying around in these e-mails to save time for all of you who are up to date on this stuff, but for myself, I am having a hard time understanding some of it. Thus, I have 2 question for you (if you don't mind!): 1. Where can I get my hands on some basic-intermediate info on IPv6 to allow me to better understand it and what is being discussed in this group? 2. What are the /35 and /48 and /64 all about? As far as I can tell they are subnetting (CIDR notation), but I only know the ones for subnetting a Class C license which as you probably know are /24 to /32. What are the higher numbers you are talking about? (Or am I completely off base?!?) Any help with this would be much appreciated. Thanks in advance. Later, Craig Martin ----- Original Message ----- From: Shane Kerr To: J. Scott Marcus Cc: Sent: Tuesday, January 30, 2001 4:35 AM Subject: Re: Closure? > On Mon, 29 Jan 2001, J. Scott Marcus wrote: > > > Again, the recommendation is probably workable. I am worried about > > the underlying overconfidence. > > This is my position as well. > > Actually, I am worried by both the overconfidence and the apparent > classfulness and inflexibility of IPv6. We've started with 128 bits, > threw away half, split the rest up on 16-bit boundaries and now we're > left with 13 bits to play with all of a sudden. The analysis that > "well, it's only 1/8 of the available space" is fundamentally flawed, > because problems with allocation of that first block may impact the use > of the rest of the space. IPv6 folks at the IETF think that people who > disagree with their recommendation simply don't understand it - not > true! I, at least, simply disagree. The "broad concensus and > acceptance" within other RIR communities is probably a combination of > eagerness to roll out new networks and excessive trust in the IETF > recommendation, rather than a well-thought out assessment of possible > problems. > > But let's be realistic. It doesn't really matter WHAT the RIR space > usage recommendations are. If I get a /35 from APNIC, ARIN, or the RIPE > NCC, then if I'm at all smart about my allocations, then I won't ever > need more space. There's no reason for me to allocate /48, /64, or any > other specific allocation. Unless the RIR's decide to monitor > allocations and REVOKE IPv6 space, any recommendation will carry even > less weight than TTL suggestions for DNS servers (I was going to say > something about recommendations to put name servers on seperate > networks, but that would be an unfair jab at a certain well-known > company, I suppose...). > > Shane > >