From heather.skanks at gmail.com Fri Jul 11 14:04:19 2008 From: heather.skanks at gmail.com (heather skanks) Date: Fri, 11 Jul 2008 14:04:19 -0400 Subject: [arin-ppml] ARIN to make Legacy WhoIs (WhoWas) info available - Suggestion 2008.15 Message-ID: <616812070807111104h168ddc3fjca42f2032234bacf@mail.gmail.com> I didn't see anything on ppml about this .. ARIN responded to the suggestion to make WhoWas data publicly availale (suggestion 2008.15) Here is the response: http://www.arin.net/acsp/suggestions/2008-15.html Following review by ARIN staff, we believe your suggestion for ARIN 'to offer a "WHOWAS" service' is a good suggestion for the community. ARIN has periodically, and under certain circumstances, provided this service on an adhoc basis but has not published it as an available service. As a result, we will implement this suggestion in a published, phased approach. First, within three months, ARIN will implement this service through online requests to ARIN's Registration Services Department (RSD). RSD will respond to the requests within 5 business days. The second phase of this service will be an online query capability. This service should be available by the end of 2009 following implementation of our web-based on-line service center. For both phases, ARIN will require a thorough understanding of both the requester and intended use of the data. The requestor may also be bound by some form of an Acceptable Use Policy (AUP). Limits may be set regarding how many requests can be made by any single entity, related to both the number of requests and period of time for requests. ARIN may have limitations on the availability of the data, particularly in cases where it in not available to ARIN. Restrictions may be placed on third party requests. ACSP suggestion 2008.15 will remain in a pending status until implemented. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Fri Jul 11 17:36:15 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 11 Jul 2008 14:36:15 -0700 Subject: [arin-ppml] ARIN to make Legacy WhoIs (WhoWas) info available -Suggestion 2008.15 In-Reply-To: <616812070807111104h168ddc3fjca42f2032234bacf@mail.gmail.com> Message-ID: <3E46EF8700D048D492A5F716F9358002@tedsdesk> Good for you Heather! http://www.youtube.com/watch?v=mEJL2Uuv-oQ Ted -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of heather skanks Sent: Friday, July 11, 2008 11:04 AM To: PPML ppml Subject: [arin-ppml] ARIN to make Legacy WhoIs (WhoWas) info available -Suggestion 2008.15 I didn't see anything on ppml about this .. ARIN responded to the suggestion to make WhoWas data publicly availale (suggestion 2008.15) Here is the response: http://www.arin.net/acsp/suggestions/2008-15.html Following review by ARIN staff, we believe your suggestion for ARIN 'to offer a "WHOWAS" service' is a good suggestion for the community. ARIN has periodically, and under certain circumstances, provided this service on an adhoc basis but has not published it as an available service. As a result, we will implement this suggestion in a published, phased approach. First, within three months, ARIN will implement this service through online requests to ARIN's Registration Services Department (RSD). RSD will respond to the requests within 5 business days. The second phase of this service will be an online query capability. This service should be available by the end of 2009 following implementation of our web-based on-line service center. For both phases, ARIN will require a thorough understanding of both the requester and intended use of the data. The requestor may also be bound by some form of an Acceptable Use Policy (AUP). Limits may be set regarding how many requests can be made by any single entity, related to both the number of requests and period of time for requests. ARIN may have limitations on the availability of the data, particularly in cases where it in not available to ARIN. Restrictions may be placed on third party requests. ACSP suggestion 2008.15 will remain in a pending status until implemented. -------------- next part -------------- An HTML attachment was scrubbed... URL: From awahid at cwgo.com Sat Jul 12 12:32:21 2008 From: awahid at cwgo.com (Aamir Wahid) Date: Sat, 12 Jul 2008 12:32:21 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 37, Issue 2 Message-ID: <955016202@mail.cwgo.com> From matt at conundrum.com Tue Jul 15 12:50:19 2008 From: matt at conundrum.com (Matthew Pounsett) Date: Tue, 15 Jul 2008 12:50:19 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <484B3ACD.5060604@merit.edu> <86051.1212891201@sa.vix.com> Message-ID: <8A69A1BF-AF2D-41C6-9D01-AFCFDE0F0815@conundrum.com> On 27-Jun-2008, at 14:26 , Tom Vest wrote: > If it wasn't already obvious, I support this proposal. > However, I think that the reservation should envision a 20-year > transition timeframe, if not longer. In discussing this with Alain early on, we talked about how to figure out how large the block should be. I think a reasonable approach is to look at the growth curve of the number of unique organizations ARIN has, and then project out to whatever horizon we want from there. It shouldn't be too hard to figure out an average allocation per org under this policy, which should tell us the size of the reserve that's necessary. > I am assuming that a resource transfer proposal will advance in > parallel, and ultimately versions of both policies may be approved. > > If that happens, some very risk-averse and/or very windfall-driven > IPv4 holders/users may still be tempted to hold out until the reserved > pool too is exhausted. The size of the reserved pool is the only real > deterrent to discourage that kind of strategy. Agreed. I hadn't really considered this impact to transfers, but it certainly seems plausible... so setting the horizon a long way out seems like a good idea to me. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From BillD at cait.wustl.edu Tue Jul 15 15:02:26 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 15 Jul 2008 14:02:26 -0500 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 Message-ID: The ARIN Advisory Council(AC) is charged with assessing consensus on policy proposals. Most often, proposals are relatively straighforward and orient toward relatively well-known issues that have a greater or lesser impact on the community. When this is the case, the process of the Information Resource Policy Evaluation Policy (IRPEP) works pretty well. When something as big as an amended transfer policy proposal comes along with all its implications and little experience by anyone, especially when the proposal itself is crafted by the AC and tries to be very specific and comprehensive....well, this delivers unprecedented challenges to get concise feedback from the community and make progress toward consensus. I personally feel perplexed by this today and I am polling those engaged in ppml to help me and my colleagues move this proposal forward. ******** What I ask is for you to consider your own understanding and stance on amending our present transfer policy to determine what you really like (if anything) about the proposal....What must be 'in' if the proposal is to get your support? Alternatively, if you are not inclined to support this or any updated transfer policy, what is it that makes this a non-starter for you? In each/either case, a short list of the items is what I ask for.....and a very brief/concise explanation if you feel the need. ********** For those of you who have continually expressed your views, I would still ask for your concise list as I believe the aggregate response from all participants will help point us all in the direction of consensus. Those who have not previously expressed your views are even more crucial....we need your input. As our Los Angeles Public Policy Meeting is fast approaching....October 15-17....we need your feedback right now! Thanks for your support and continued involvement with ARIN! Bill Darte ARIN Advisory Council From tedm at ipinc.net Tue Jul 15 16:01:46 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 15 Jul 2008 13:01:46 -0700 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 In-Reply-To: Message-ID: <8E3929E2C6A04667B7C02537B1289850@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte > Sent: Tuesday, July 15, 2008 12:02 PM > To: ppml at arin.net > Subject: [arin-ppml] Your views on ARIN Transfer Policy > Proposal 2008-2 > > > The ARIN Advisory Council(AC) is charged with assessing > consensus on policy proposals. > > Most often, proposals are relatively straighforward and > orient toward relatively well-known issues that have a > greater or lesser impact on the community. When this is the > case, the process of the Information Resource Policy > Evaluation Policy (IRPEP) works pretty well. > > When something as big as an amended transfer policy proposal > comes along with all its implications and little experience > by anyone, especially when the proposal itself is crafted by > the AC and tries to be very specific and > comprehensive....well, this delivers unprecedented challenges > to get concise feedback from the community and make progress > toward consensus. > I really question that the AC wants consensus on this proposal. > I personally feel perplexed by this today and I am polling > those engaged in ppml to help me and my colleagues move this > proposal forward. > There has been a large amount of feedback on the discussion list already on this proposal. Bill, I don't know if you are a supporter of this proposal or not but I will assume for the rest of this e-mail that you are, and when I say "you" I mean "everyone who dreamed this up and is pushing it" So don't take "you" personally. You need to keep in mind that this is a very polarizing proposal. And of course it is, because of how your doing it. Your basically trying a revolutionary approach to the proposal and everyone on the list is already somewhat conservative, or they wouldn't even be subscribed. That's the first strike against it. Even if I was for the concept of allowing 3rd parties to buy and sell IPv4 addresses - which I am not - I would vote against this because it is too much, too fast. There currently is no consensus in the community for an answer to the question of whether it is even a good idea to even begin taking steps to try prolonging the life of IPv4 in the first place. This proposal is attempting to do an end-run around that discussion by ASSUMING that we should be prolonging IPv4 and asking the community to say the best way to do it. In short, you have already made up our minds for us on that score. So, the people like myself who are opposed to the idea realize that there is no point in even discussing anything with the supporters of this proposal. They don't want to examine or even admit that it might be a bad thing to attempt to interfere with the natural course of events that would result in the death of IPv4 in a few years. And you figure that once you have a 51% majority that is all you need to force your paradigm. I am not interested in helping you to modify this proposal. I do not consider that you are reaching out to the opposition. I think that all your trying to do is scrape a few undecided people into your camp to obtain that 51% majority. If you really wanted to reach out to the opposition then scrap this and replace it with a proposal that modifies the NRPM to insert a single, simple paragraph that states that it is ARIN's position that steps must be taken to prolong the use of IPv4 past the runout date. That would allow the community to debate the wisdom of attempting to extend IPv4. If the majority ended up deciding that this was a good thing, then the minority of people opposed to allowing IPv4 to just die naturally would at least have the feeling that they would be able to have some input in the next phase of the discussion - which is how to best extend it. IF the community DID decide it was a good thing to extend IPv4, THEN you can resurrect this proposal at that time. At this point all I want is for the vote to take place because I think this proposal will lose, and losing is the ONLY THING that I think that will bring you to your senses to realize that you aren't going to be able to sidestep the discussion, and your going to have to have the discussion of whether extending IPv4 is a good idea or not, whether you want to or not. Because, it's obvious your not willing to discuss that topic now. Probably because your afraid of losing, because deep down you know it is a bad idea to extend IPv4. Ted From BillD at cait.wustl.edu Tue Jul 15 18:05:07 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 15 Jul 2008 17:05:07 -0500 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 In-Reply-To: <8E3929E2C6A04667B7C02537B1289850@tedsdesk> References: <8E3929E2C6A04667B7C02537B1289850@tedsdesk> Message-ID: > > > > I really question that the AC wants consensus on this proposal. > > > I personally feel perplexed by this today and I am polling those > > engaged in ppml to help me and my colleagues move this proposal > > forward. > > > > There has been a large amount of feedback on the discussion > list already on this proposal. > > Bill, I don't know if you are a supporter of this proposal or > not but I will assume for the rest of this e-mail that you > are, and when I say "you" I mean "everyone who dreamed this > up and is pushing it" So don't take "you" personally. Actually and personally, I am looking for consensus for or against. My role is to help make sure that the policy proposal is as acceptable as it can be made to be.... Whether that ever reaches a level of acceptability that warrants the AC forwarding it to the Board is beside the point. Personally, my particular interests and 'vote' don't matter in my role as AC member. > > You need to keep in mind that this is a very polarizing proposal. > And of course it is, because of how your doing it. Your > basically trying a revolutionary approach to the proposal and > everyone on the list is already somewhat conservative, or > they wouldn't even be subscribed. That's the first strike against it. > > Even if I was for the concept of allowing 3rd parties to buy and sell > IPv4 addresses - which I am not - I would vote against this > because it is too much, too fast. Personally, I'm not for sales either....empathically. I'm much of an 80/20 person and think that a policy can often do good in a simplified state and become better with experience and future tweaking. > > There currently is no consensus in the community for an > answer to the question of whether it is even a good idea to > even begin taking steps to try prolonging the life of IPv4 in > the first place. Certainly prolonging IPv4 was never an objective or intent of 2008-2 at least for the majority of AC members, I'm sure. > > This proposal is attempting to do an end-run around that > discussion by ASSUMING that we should be prolonging IPv4 and > asking the community to say the best way to do it. In short, > you have already made up our minds for us on that score. > > So, the people like myself who are opposed to the idea > realize that there is no point in even discussing anything > with the supporters of this proposal. They don't want to > examine or even admit that it might be a bad thing to attempt > to interfere with the natural course of events that would > result in the death of IPv4 in a few years. > > And you figure that once you have a 51% majority that is all > you need to force your paradigm. 51% majority (or anything close to it) on any policy proposal discussion in my 10 years of experience, has never constituted consensus. > > I am not interested in helping you to modify this proposal. > I do not consider that you are reaching out to the > opposition. I think that all your trying to do is scrape a > few undecided people into your camp to obtain that 51% majority. > > If you really wanted to reach out to the opposition then > scrap this and replace it with a proposal that modifies the > NRPM to insert a single, simple paragraph that states that it > is ARIN's position that steps must be taken to prolong the > use of IPv4 past the runout date. You are and have always been welcome to introduce such a policy proposal. I'd be in your camp on that one...fyi. > > That would allow the community to debate the wisdom of > attempting to extend IPv4. If the majority ended up deciding > that this was a good thing, then the minority of people > opposed to allowing IPv4 to just die naturally would at least > have the feeling that they would be able to have some input > in the next phase of the discussion - which is how to best extend it. > > IF the community DID decide it was a good thing to extend > IPv4, THEN you can resurrect this proposal at that time. > > At this point all I want is for the vote to take place > because I think this proposal will lose, and losing is the > ONLY THING that I think that will bring you to your senses to > realize that you aren't going to be able to sidestep the > discussion, and your going to have to have the discussion of > whether extending IPv4 is a good idea or not, whether you > want to or not. Because, it's obvious your not willing to > discuss that topic now. > Probably because your afraid of losing, because deep down you > know it is a bad idea to extend IPv4. I do. But, again. You may perceive that that was the intention of 2008-2, but it was not. Many/most (all?) of the AC were worried about that reception....but we felt that the community should debate it if they took it that way. It seems to have worked out that way indeed. > > > > Ted > > From mueller at syr.edu Tue Jul 15 18:08:59 2008 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 15 Jul 2008 18:08:59 -0400 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 In-Reply-To: References: Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DC9B3@SUEXCL-02.ad.syr.edu> Bill: > -----Original Message----- > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte > > What I ask is for you to consider your own understanding and stance on > amending our present transfer policy to determine what you really like > (if anything) about the proposal.... What I like about the proposal is that it recognizes that something needs to be done and it gives organizations that currently hold or need address resources more flexibility to deal with the impending scarcity. I also like the fact that it is taking a _responsible_ attitude toward v4-v6 migration; it recognizes that we must manage IPv4 scarcity wisely because we don't really know how long it will take to get to v6, if ever. > What must be 'in' if the proposal is to get your support? To get my support, what must be 'out' of the current ARIN proposal is pre-qualification of buyers using traditional needs assessment. That defeats the whole purpose of transfers and makes it unlikely that it will make any difference. See the RIPE proposal, for a good model of how to defeat speculation without drastic measures. You should also get rid of the trigger date, just start authorizing transfers as soon as the new policy is passed. From tvest at pch.net Tue Jul 15 19:46:43 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 15 Jul 2008 16:46:43 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment In-Reply-To: <8A69A1BF-AF2D-41C6-9D01-AFCFDE0F0815@conundrum.com> References: <4849f2d4.1db.4182.26981@batelnet.bs> <45479.1212809939@sa.vix.com> <84853.1212888922@sa.vix.com> <484B3ACD.5060604@merit.edu> <86051.1212891201@sa.vix.com> <8A69A1BF-AF2D-41C6-9D01-AFCFDE0F0815@conundrum.com> Message-ID: <67B5AB3B-D035-4C63-A8DC-9435590D45E4@pch.net> On Jul 15, 2008, at 9:50 AM, Matthew Pounsett wrote: > > On 27-Jun-2008, at 14:26 , Tom Vest wrote: > >> If it wasn't already obvious, I support this proposal. >> However, I think that the reservation should envision a 20-year >> transition timeframe, if not longer. > > In discussing this with Alain early on, we talked about how to > figure out how large the block should be. I think a reasonable > approach is to look at the growth curve of the number of unique > organizations ARIN has, and then project out to whatever horizon we > want from there. It shouldn't be too hard to figure out an average > allocation per org under this policy, which should tell us the size > of the reserve that's necessary. > >> I am assuming that a resource transfer proposal will advance in >> parallel, and ultimately versions of both policies may be approved. >> >> If that happens, some very risk-averse and/or very windfall-driven >> IPv4 holders/users may still be tempted to hold out until the >> reserved >> pool too is exhausted. The size of the reserved pool is the only real >> deterrent to discourage that kind of strategy. > > Agreed. I hadn't really considered this impact to transfers, but it > certainly seems plausible... so setting the horizon a long way out > seems like a good idea to me. > > Matt Hi Matt, Thanks for the reply. You should consider this to be the *single most important and influential factor* that will impact transfers, hands down. For example, if you think that only fringe elements are placing their bets on no IPv6, ever, then I commend to your attention: http://www.renesys.com/tech/presentations/pdf/telecomnext-underwood-ipv6.pdf http://www.renesys.com/blog/2006/03/bashing_ipv6_at_telecomnext.shtml I've looked (and inquired directly) to see if this is still the Renesys view; absent any evidence of a change of positions I assume that it is. Of course one could produce many op-eds and presentations that champion the opposing view, including a few authored by equally knowledgeable and well-connected sources. However, this alone should make it plain enough that there's a credible commercial message and a receptive commercial audience of some size for opinions, advice -- maybe even strategies and tools (note: this latter bit is purely speculative) -- that build on the assumption that IPv6 will remain a non-starter, permanently. So, to clarify and reaffirm my position on this policy, I believe that it will create a tension between the goal of extracting maximum rents from legacy IPv4 resources (the "just business" default assumption), and the goal of maintaining openness to new entrants -- which is good, since if a resource transfer policy moves forward without any accompanying policy like this, then the most likely outcome is no new entrants, no problem! However, that tension could lead to a kind-of waiting game, with incumbent IPv4 holders who cannot command a price that they will accept choosing instead to hold onto all of the IPv4 that they have or could decommission until the reservation is exhausted and the price of IPv4 is unbounded.To the degree that that happens, then of course the whole goal of the resource transfer proposals -- to create a liquid supply of IPv4 address space for whatever future awaits -- could be undermined or thwarted entirely. The best way to mitigate that risk while keeping the industry open and the antitrust intervention risk low would be to make the reservation large enough so no one could imagine holding out long enough to enjoy that unbounded price opportunity. A /8 per RIR would have a nice symmetry. It would leave the developing regions especially well stocked for new entrants if IPv6 is ultimately rejected. In the more advanced industrial regions, where the aforementioned strategic considerations are more important, a /8 should suffice to deter all but the most patient and determined would- be price maximizers. Actually, once the substance of this policy is solidified, I would strongly encourage the AC to consider revising 2008-2 so that it *incorporates* the text.... Think of it as an earmark for the "future network operators" special interest ;-) TV From michael.dillon at bt.com Wed Jul 16 05:35:38 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jul 2008 10:35:38 +0100 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 In-Reply-To: Message-ID: > For those of you who have continually expressed your views, I > would still ask for your concise list as I believe the > aggregate response from all participants will help point us > all in the direction of consensus. 1. I do not believe that an address holder should be able to negotiate a transfer of IP addresses separately from network assets. This skates to close to conflicting with the statement that numbers are not sold by ARIN. 2. The runout of the IANA free pool is a symptom of scarcity of IPv4 addresses. I do not believe that there will be any significant number of address blocks available for transfer in a time of scarcity. 3. If an organization is willing to transfer an address block, this means that they don't need it. Allowing them to transfer these addresses is a violation of section 8 of the RSA. 4. The end result of this policy is that an address block that is not needed by organization A will end up in the hands of organization B. This can already be accomplished in accord with ARIN policy and with the RSA, if organization A meets its obligation and gives the addresses back to ARIN. 5. This policy proposal is too darn COMPLICATED with legal terminology such as "safe harbor" which may or may not have special meanings that are not obvious to PPML participants. ARIN policy has generally only been as complex as the technology requires, but this now adds layers of complexity that have nothing whatsoever to do with technology. 6. Organizations who hold IP addresses will have to take the ARIN relationship away from operational address administrators and give it to their legal departments in order to make this kind of policy work. 7. This policy attempts to engineer an IP address trading market with clauses pulled out of thin air to do things like "discourage speculation". This goes beyond ARIN's scope. I'm sure you will point to article 7 paragraph 5 of the charter, but when I say that it goes beyond ARIN's scope, I am saying it in broad terms taking all 9 paragraphs of article 7 as an organic whole. Not just three words (all and everything). --Michael Dillon From michael.dillon at bt.com Wed Jul 16 05:53:23 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jul 2008 10:53:23 +0100 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: <67B5AB3B-D035-4C63-A8DC-9435590D45E4@pch.net> Message-ID: > For example, if you think that only fringe elements are > placing their bets on no IPv6, ever, then I commend to your attention: > > http://www.renesys.com/tech/presentations/pdf/telecomnext-unde > rwood-ipv6.pdf > > http://www.renesys.com/blog/2006/03/bashing_ipv6_at_telecomnext.shtml That's one guy. The OECD, of which the USA is a member, seems to think IPv6 is inevitable. The EU is taking measures to encourage deployment of IPv6. In China, Japan and Korea, the major economies of the Asia-Pacific region, IPv6 is already deployed and there is government backing for extending this deployment. In the USA, the DoD and Federal government are pushing IPv6 as the way forward. But I do understand that in the USA, businesses are under no obligation to follow the lead of the OECD or Federal government, but do you seriously think that U.S. network operators will circle the wagons and go it alone with IPv4 while the rest of the world goes with IPv6? --Michael Dillon From jyy at uci.edu Wed Jul 16 10:41:57 2008 From: jyy at uci.edu (Jessica (Jie Yun) Yu) Date: Wed, 16 Jul 2008 07:41:57 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: References: <67B5AB3B-D035-4C63-A8DC-9435590D45E4@pch.net> Message-ID: <023101c8e752$1a1075c0$4e316140$@edu> >...but do you seriously think that U.S. network operators will circle the wagons and go it alone with IPv4 while the rest of >the world goes with IPv6? Well, it's not unprecedented that US adopts different standard than the rest of the world. According to http://en.wikipedia.org/wiki/Metric_system, the entire world (except 3 nations) has adopted Metric System for about 40 years while US is still using inch-pound system. --Jessica -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Wednesday, July 16, 2008 2:53 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment > For example, if you think that only fringe elements are > placing their bets on no IPv6, ever, then I commend to your attention: > > http://www.renesys.com/tech/presentations/pdf/telecomnext-unde > rwood-ipv6.pdf > > http://www.renesys.com/blog/2006/03/bashing_ipv6_at_telecomnext.shtml That's one guy. The OECD, of which the USA is a member, seems to think IPv6 is inevitable. The EU is taking measures to encourage deployment of IPv6. In China, Japan and Korea, the major economies of the Asia-Pacific region, IPv6 is already deployed and there is government backing for extending this deployment. In the USA, the DoD and Federal government are pushing IPv6 as the way forward. But I do understand that in the USA, businesses are under no obligation to follow the lead of the OECD or Federal government, but do you seriously think that U.S. network operators will circle the wagons and go it alone with IPv4 while the rest of the world goes with IPv6? --Michael Dillon _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bmanning at vacation.karoshi.com Wed Jul 16 11:23:04 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 16 Jul 2008 15:23:04 +0000 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitateIPv6 deployment In-Reply-To: <023101c8e752$1a1075c0$4e316140$@edu> References: <67B5AB3B-D035-4C63-A8DC-9435590D45E4@pch.net> <023101c8e752$1a1075c0$4e316140$@edu> Message-ID: <20080716152304.GB8189@vacation.karoshi.com.> the US has aadopted the metric system... offically anyway :) --bill On Wed, Jul 16, 2008 at 07:41:57AM -0700, Jessica (Jie Yun) Yu wrote: > >...but do you seriously think that U.S. network operators will circle the > wagons and go it alone with IPv4 while the rest of >the world goes with > IPv6? > > Well, it's not unprecedented that US adopts different standard than the rest > of the world. According to http://en.wikipedia.org/wiki/Metric_system, the > entire world (except 3 nations) has adopted Metric System for about 40 years > while US is still using inch-pound system. > > > --Jessica > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Wednesday, July 16, 2008 2:53 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 block to > facilitateIPv6 deployment > > > For example, if you think that only fringe elements are > > placing their bets on no IPv6, ever, then I commend to your attention: > > > > http://www.renesys.com/tech/presentations/pdf/telecomnext-unde > > rwood-ipv6.pdf > > > > http://www.renesys.com/blog/2006/03/bashing_ipv6_at_telecomnext.shtml > > That's one guy. The OECD, of which the USA is a member, seems > to think IPv6 is inevitable. The EU is taking measures to > encourage deployment of IPv6. In China, Japan and Korea, the > major economies of the Asia-Pacific region, IPv6 is already > deployed and there is government backing for extending this > deployment. In the USA, the DoD and Federal government are > pushing IPv6 as the way forward. But I do understand that in > the USA, businesses are under no obligation to follow the > lead of the OECD or Federal government, but do you seriously > think that U.S. network operators will circle the wagons > and go it alone with IPv4 while the rest of the world goes > with IPv6? > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Wed Jul 16 12:45:16 2008 From: bill at herrin.us (William Herrin) Date: Wed, 16 Jul 2008 12:45:16 -0400 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 In-Reply-To: References: Message-ID: <3c3e3fca0807160945p172f6caw95e386f057251161@mail.gmail.com> On Tue, Jul 15, 2008 at 3:02 PM, Bill Darte wrote: > What I ask is for you to consider your own understanding and stance on > amending our present transfer policy to determine what you really like > (if anything) about the proposal....What must be 'in' if the proposal is > to get your support? Hi Bill, The policy is pretty clunky, but that's to be expected of the first attempt. The clunkyness should not dissuade anyone from supporting it. We can deal with clunkiness incrementally in later proposals. What's important now is getting -something- on the books. I oppose this proposal because it appears to act as an enabler for disaggregation of IP address resources. I would support the proposal if disaggregation was clearly prohibited in this initial policy and left as a topic of discussion for later policy proposals on PPML. I understand why disaggregation is desirable, but understand this: the RRG is *not* close to solving BGP's scalability problem. Of late we've taken to discussing "clean slate" approaches, having exhausted the map-encap possibilities without finding an attractive solution. It isn't yet clear what exactly will have to change in the protocols in order to make routing scalable, but it's unlikely that the current layer-4 protocols will survive intact. This has obvious implications for the length of time for which BGP as it is now *must* be kept viable. As individual users, our primary concern is necessarily for ourselves and our clients. We rely on entities like ARIN to look out for the common good, and right now that common good means dissuading disaggregation in every way possible. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jyy at uci.edu Wed Jul 16 15:21:17 2008 From: jyy at uci.edu (Jessica (Jie Yun) Yu) Date: Wed, 16 Jul 2008 12:21:17 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 blockto facilitateIPv6 deployment In-Reply-To: <5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> References: <023101c8e752$1a1075c0$4e316140$@edu> <5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> Message-ID: <024e01c8e779$1fd59810$5f80c830$@edu> Ted, The fact is that while some special areas in the US may use the Metric system, the main measuring system in the US is the English system (inch-pound). If you think otherwise, you must live in a different United States as I do. By the way, this is sort of off the main topic of this thread intended to discuss so I will stop here. --Jessica -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Wednesday, July 16, 2008 12:00 PM To: 'Jessica (Jie Yun) Yu'; michael.dillon at bt.com; arin-ppml at arin.net Subject: RE: [arin-ppml] Policy Proposal: Dedicated IPv4 blockto facilitateIPv6 deployment > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jessica (Jie Yun) Yu > Sent: Wednesday, July 16, 2008 7:42 AM > To: michael.dillon at bt.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 > blockto facilitateIPv6 deployment > > > >...but do you seriously think that U.S. network operators > will circle > >the > wagons and go it alone with IPv4 while the rest of >the world > goes with IPv6? > > Well, it's not unprecedented that US adopts different > standard than the rest of the world. According to > http://en.wikipedia.org/wiki/Metric_system, the entire world > (except 3 nations) has adopted Metric System for about 40 > years while US is still using inch-pound system. > In all US industrial markets the metric system is in wide use. If you buy a car, a bicycle, a motorcycle, or any other item of any complexity and you want to work on it yourself, your going to use metric tools, not English. If your definition of the "entire world adopting the metric system" means that every single measurement of anything in the world is out of the metric system, you are very much mistaken. Measurements are done in a variety of different standards. In threads alone there's about 20 different popular standards, and manufacturers and industries will adopt the most unusual ones you can imagine. For example, in auto air conditioning work, when the industry shifted from chlorinated R12 the service fittings were all American Standard flare, available at any hardware store. The logical thing would have been to shift to Metric ISO flare, wouldn't you think? But guess what they did shift to? ACME, that's what. A thread standard that is used for worm drives on lathes and bench vises, coupled with a compression flare. It's unique in the AC industry and completely stupid because while the intent was to prevent DIYers from connecting their old R12 stuff to the new AC systems, you can buy ACME-to-standard flare adapters. BSW Pipe thread, (ie: Whitworth) another non-metric standard, is used on virtually all water pipes in the UK, and in Australia. MPH is also used on speed signs in the UK and Australia and until recently, in India. In the US, virtually EVERYTHING made for foreign export is metric. The lesson you should draw from this analogy is that in a post-IPv4-runout world, there are going to be "pockets" here and there of IPv4. Most obviously, we will likely see IPv4 handoffs from ISP's to residential customers, for many, MANY years, long after the core is IPv6, using proxies and translators at the ISP. And why not, because any ISP doing that can use private numbers at no cost? It's analogous to the local gas company is going to handoff your natural gas line to your home or business using NPT and English-measured pipe. But, if the gas company is buying LNG from an overseas supplier, it's likely going to be measured in metric. But the idea that somehow conversion to the metric system hasn't happened in the US, or the UK, just because they have their street speed limit signs in miles, and their water pipe sizes and threads in century-old dinosaur standards that predate metric, is a fantasy. Ted From tedm at ipinc.net Wed Jul 16 14:59:30 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Jul 2008 11:59:30 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 blockto facilitateIPv6 deployment In-Reply-To: <023101c8e752$1a1075c0$4e316140$@edu> Message-ID: <5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jessica (Jie Yun) Yu > Sent: Wednesday, July 16, 2008 7:42 AM > To: michael.dillon at bt.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 > blockto facilitateIPv6 deployment > > > >...but do you seriously think that U.S. network operators > will circle > >the > wagons and go it alone with IPv4 while the rest of >the world > goes with IPv6? > > Well, it's not unprecedented that US adopts different > standard than the rest of the world. According to > http://en.wikipedia.org/wiki/Metric_system, the entire world > (except 3 nations) has adopted Metric System for about 40 > years while US is still using inch-pound system. > In all US industrial markets the metric system is in wide use. If you buy a car, a bicycle, a motorcycle, or any other item of any complexity and you want to work on it yourself, your going to use metric tools, not English. If your definition of the "entire world adopting the metric system" means that every single measurement of anything in the world is out of the metric system, you are very much mistaken. Measurements are done in a variety of different standards. In threads alone there's about 20 different popular standards, and manufacturers and industries will adopt the most unusual ones you can imagine. For example, in auto air conditioning work, when the industry shifted from chlorinated R12 the service fittings were all American Standard flare, available at any hardware store. The logical thing would have been to shift to Metric ISO flare, wouldn't you think? But guess what they did shift to? ACME, that's what. A thread standard that is used for worm drives on lathes and bench vises, coupled with a compression flare. It's unique in the AC industry and completely stupid because while the intent was to prevent DIYers from connecting their old R12 stuff to the new AC systems, you can buy ACME-to-standard flare adapters. BSW Pipe thread, (ie: Whitworth) another non-metric standard, is used on virtually all water pipes in the UK, and in Australia. MPH is also used on speed signs in the UK and Australia and until recently, in India. In the US, virtually EVERYTHING made for foreign export is metric. The lesson you should draw from this analogy is that in a post-IPv4-runout world, there are going to be "pockets" here and there of IPv4. Most obviously, we will likely see IPv4 handoffs from ISP's to residential customers, for many, MANY years, long after the core is IPv6, using proxies and translators at the ISP. And why not, because any ISP doing that can use private numbers at no cost? It's analogous to the local gas company is going to handoff your natural gas line to your home or business using NPT and English-measured pipe. But, if the gas company is buying LNG from an overseas supplier, it's likely going to be measured in metric. But the idea that somehow conversion to the metric system hasn't happened in the US, or the UK, just because they have their street speed limit signs in miles, and their water pipe sizes and threads in century-old dinosaur standards that predate metric, is a fantasy. Ted From Matteson_Mike at emc.com Wed Jul 16 15:46:57 2008 From: Matteson_Mike at emc.com (Matteson_Mike at emc.com) Date: Wed, 16 Jul 2008 15:46:57 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4blockto facilitateIPv6 deployment In-Reply-To: <5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> References: <023101c8e752$1a1075c0$4e316140$@edu> <5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> Message-ID: <2A22ECE278A6604A84476172F106BFCE02F02A74@CORPUSMX50A.corp.emc.com> Ah, Yes Ted... ..and what is your weight in kilos, and height in meters...(w/o doing the conversion )??? regards, --MikeM-- -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Wednesday, July 16, 2008 3:00 PM To: 'Jessica (Jie Yun) Yu'; michael.dillon at bt.com; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4blockto facilitateIPv6 deployment > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jessica (Jie Yun) Yu > Sent: Wednesday, July 16, 2008 7:42 AM > To: michael.dillon at bt.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 > blockto facilitateIPv6 deployment > > > >...but do you seriously think that U.S. network operators > will circle > >the > wagons and go it alone with IPv4 while the rest of >the world > goes with IPv6? > > Well, it's not unprecedented that US adopts different > standard than the rest of the world. According to > http://en.wikipedia.org/wiki/Metric_system, the entire world > (except 3 nations) has adopted Metric System for about 40 > years while US is still using inch-pound system. > In all US industrial markets the metric system is in wide use. If you buy a car, a bicycle, a motorcycle, or any other item of any complexity and you want to work on it yourself, your going to use metric tools, not English. If your definition of the "entire world adopting the metric system" means that every single measurement of anything in the world is out of the metric system, you are very much mistaken. Measurements are done in a variety of different standards. In threads alone there's about 20 different popular standards, and manufacturers and industries will adopt the most unusual ones you can imagine. For example, in auto air conditioning work, when the industry shifted from chlorinated R12 the service fittings were all American Standard flare, available at any hardware store. The logical thing would have been to shift to Metric ISO flare, wouldn't you think? But guess what they did shift to? ACME, that's what. A thread standard that is used for worm drives on lathes and bench vises, coupled with a compression flare. It's unique in the AC industry and completely stupid because while the intent was to prevent DIYers from connecting their old R12 stuff to the new AC systems, you can buy ACME-to-standard flare adapters. BSW Pipe thread, (ie: Whitworth) another non-metric standard, is used on virtually all water pipes in the UK, and in Australia. MPH is also used on speed signs in the UK and Australia and until recently, in India. In the US, virtually EVERYTHING made for foreign export is metric. The lesson you should draw from this analogy is that in a post-IPv4-runout world, there are going to be "pockets" here and there of IPv4. Most obviously, we will likely see IPv4 handoffs from ISP's to residential customers, for many, MANY years, long after the core is IPv6, using proxies and translators at the ISP. And why not, because any ISP doing that can use private numbers at no cost? It's analogous to the local gas company is going to handoff your natural gas line to your home or business using NPT and English-measured pipe. But, if the gas company is buying LNG from an overseas supplier, it's likely going to be measured in metric. But the idea that somehow conversion to the metric system hasn't happened in the US, or the UK, just because they have their street speed limit signs in miles, and their water pipe sizes and threads in century-old dinosaur standards that predate metric, is a fantasy. Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From Matthew.Wilder at telus.com Wed Jul 16 16:45:31 2008 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Wed, 16 Jul 2008 13:45:31 -0700 Subject: [arin-ppml] Policy Proposal: DedicatedIPv4blockto facilitateIPv6 deployment In-Reply-To: <2A22ECE278A6604A84476172F106BFCE02F02A74@CORPUSMX50A.corp.emc.com> References: <023101c8e752$1a1075c0$4e316140$@edu><5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> <2A22ECE278A6604A84476172F106BFCE02F02A74@CORPUSMX50A.corp.emc.com> Message-ID: <4C80F17364FE2E4C93053BE9D01DB47909022E4A@BCMSG111.corp.ads> Time for a Candian to enter the discussion: Kilograms are a measure of mass as opposed to weight... -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matteson_Mike at emc.com Sent: Wednesday, July 16, 2008 12:47 PM To: tedm at ipinc.net; jyy at uci.edu; michael.dillon at bt.com; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: DedicatedIPv4blockto facilitateIPv6 deployment Ah, Yes Ted... ..and what is your weight in kilos, and height in meters...(w/o doing the conversion )??? regards, --MikeM-- -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Wednesday, July 16, 2008 3:00 PM To: 'Jessica (Jie Yun) Yu'; michael.dillon at bt.com; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4blockto facilitateIPv6 deployment > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jessica (Jie Yun) Yu > Sent: Wednesday, July 16, 2008 7:42 AM > To: michael.dillon at bt.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 blockto > facilitateIPv6 deployment > > > >...but do you seriously think that U.S. network operators > will circle > >the > wagons and go it alone with IPv4 while the rest of >the world goes > with IPv6? > > Well, it's not unprecedented that US adopts different standard than > the rest of the world. According to > http://en.wikipedia.org/wiki/Metric_system, the entire world (except 3 > nations) has adopted Metric System for about 40 years while US is > still using inch-pound system. > In all US industrial markets the metric system is in wide use. If you buy a car, a bicycle, a motorcycle, or any other item of any complexity and you want to work on it yourself, your going to use metric tools, not English. If your definition of the "entire world adopting the metric system" means that every single measurement of anything in the world is out of the metric system, you are very much mistaken. Measurements are done in a variety of different standards. In threads alone there's about 20 different popular standards, and manufacturers and industries will adopt the most unusual ones you can imagine. For example, in auto air conditioning work, when the industry shifted from chlorinated R12 the service fittings were all American Standard flare, available at any hardware store. The logical thing would have been to shift to Metric ISO flare, wouldn't you think? But guess what they did shift to? ACME, that's what. A thread standard that is used for worm drives on lathes and bench vises, coupled with a compression flare. It's unique in the AC industry and completely stupid because while the intent was to prevent DIYers from connecting their old R12 stuff to the new AC systems, you can buy ACME-to-standard flare adapters. BSW Pipe thread, (ie: Whitworth) another non-metric standard, is used on virtually all water pipes in the UK, and in Australia. MPH is also used on speed signs in the UK and Australia and until recently, in India. In the US, virtually EVERYTHING made for foreign export is metric. The lesson you should draw from this analogy is that in a post-IPv4-runout world, there are going to be "pockets" here and there of IPv4. Most obviously, we will likely see IPv4 handoffs from ISP's to residential customers, for many, MANY years, long after the core is IPv6, using proxies and translators at the ISP. And why not, because any ISP doing that can use private numbers at no cost? It's analogous to the local gas company is going to handoff your natural gas line to your home or business using NPT and English-measured pipe. But, if the gas company is buying LNG from an overseas supplier, it's likely going to be measured in metric. But the idea that somehow conversion to the metric system hasn't happened in the US, or the UK, just because they have their street speed limit signs in miles, and their water pipe sizes and threads in century-old dinosaur standards that predate metric, is a fantasy. Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Wed Jul 16 17:05:40 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Jul 2008 14:05:40 -0700 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 blockto facilitateIPv6 deployment In-Reply-To: <024e01c8e779$1fd59810$5f80c830$@edu> Message-ID: <24845A2388E94226A07CBABD37E0F93A@tedsdesk> > -----Original Message----- > From: Jessica (Jie Yun) Yu [mailto:jyy at uci.edu] > Sent: Wednesday, July 16, 2008 12:21 PM > To: 'Ted Mittelstaedt'; michael.dillon at bt.com; arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal: Dedicated IPv4 > blockto facilitateIPv6 deployment > > > Ted, > > The fact is that while some special areas in the US may use > the Metric system, the main measuring system in the US is the > English system (inch-pound). Wrong. As I said, measurements are done in a variety of different standards depending on the industry. In the US the machine tool industry is almost completely metric now. Most fastners (ie: bolts) used in all industries except for construction are metric - a few are metric threads with english heads. Construction is one of the few holdouts because most construction is governed by local building codes of which there are thousands in the US. Also, because construction is still one of the industries where there's significant participation by non-professionals (go into any Home Depot or Lowes to see what I mean) Transportation regulatory speeds, map distances, and fuel measurements (sales and vehicle efficiency) are still english, however it is also common for the general public to make statements like "this car with the 2.5 liter engine gets 25 mpg, and this car with the 4 liter engine gets 30 mpg" basically mixing metric and english measurement types in the same sentence. In any case, the US standard for deviation of an auto speedometer is something like 2-3 mph, the assertion that an auto speedometer is anything like a precision measuring device is preposterous, that is why arguing in a court that your car speedo says you were going 55 when the cop's radar gun says you were going 65 is not a defense against a ticket. Vehicle manufacture is mostly metric nowadays. (or soon will be with GM talking about bankruptcy) Space exploration is metric now, after NASA lost the million dollar Mars lander due to the stupidity of mixing metric and non-metric measurements in the same spacescraft (much like the general public does with cars) they went on a tear to stop doing that. Food for retail sale USED to be packaged in standard-sized containers. With the exception of a few holdouts, such as beer and soda cans and bottles (12 oz aluminum cans, and 2 liter plastic bottles, another example of mixed metric/english) today retail food container sizes are NOT standardized, they are all over the map as food companies attempt to deceive consumers. For example a lot of "1/2 gallon" ice cream containers are now really 56 oz, Country Crock has come out with a 2lb 13 oz margarine container that appears identical to a 3 lb container, etc. These containers no longer follow any kind of english or metric standard, are designed purely for the looks, and marked with whatever minimum amounts the company thinks they can get away with putting inside, in both english and metric per the food labeling laws. I could go on, but for more info see the following: http://physics.nist.gov/cuu/Units/bibliography.html In short, the statement that there is any such a thing as a "main" system in the US is ignorant. In industry, it's majority metric, among retail consumers, it is a mix. > If you think otherwise, you must > live in a different United States as I do. > I know it's no use attempting to convince someone such as yourself who obviously has no real experience in the mechanical (or electronic or most other) industries. But it's embarassing to our non-US list subscribers to have a US citizen who should certainly know better be spouting such silliness. > By the way, this is sort of off the main topic of this thread > intended to discuss so I will stop here. > Of course, your out of your element. Your also ignoring the real meat of the response, which is that there will be IPv4 pockets in an IPv6 universe, with no ill effects, just as there's english measurement pockets, and Whitworth measurement pockets, in a Metric world. Ted > --Jessica > > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Wednesday, July 16, 2008 12:00 PM > To: 'Jessica (Jie Yun) Yu'; michael.dillon at bt.com; arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal: Dedicated IPv4 > blockto facilitateIPv6 deployment > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jessica > (Jie Yun) Yu > > Sent: Wednesday, July 16, 2008 7:42 AM > > To: michael.dillon at bt.com; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 > > blockto facilitateIPv6 deployment > > > > > > >...but do you seriously think that U.S. network operators > > will circle > > >the > > wagons and go it alone with IPv4 while the rest of >the world > > goes with IPv6? > > > > Well, it's not unprecedented that US adopts different > > standard than the rest of the world. According to > > http://en.wikipedia.org/wiki/Metric_system, the entire world > > (except 3 nations) has adopted Metric System for about 40 > > years while US is still using inch-pound system. > > > > In all US industrial markets the metric system is > in wide use. If you buy a car, a bicycle, a motorcycle, or any other > item of any complexity and you want to work on it yourself, your > going to use metric tools, not English. > > If your definition of the "entire world adopting the metric system" > means that every single measurement of anything in the world is out > of the metric system, you are very much mistaken. Measurements > are done in a variety of different standards. In threads > alone there's > about 20 different popular standards, and manufacturers and > industries will > adopt the most unusual ones you can imagine. For example, in auto > air conditioning work, when the industry shifted from chlorinated > R12 the service fittings were all American Standard flare, available > at any hardware store. The logical thing would have been to shift to > Metric ISO flare, wouldn't you think? But guess what they did shift > to? ACME, that's what. A thread standard that is used for > worm drives > on lathes and bench vises, coupled with a compression flare. It's > unique in the AC industry and completely stupid because while the > intent was to prevent DIYers from connecting their old R12 stuff > to the new AC systems, you can buy ACME-to-standard flare adapters. > > BSW Pipe thread, (ie: Whitworth) another non-metric standard, is used > on virtually all water pipes in the UK, and in Australia. MPH is also > used on speed signs in the UK and Australia and until recently, in > India. > > In the US, virtually EVERYTHING made for foreign export is metric. > > The lesson you should draw from this analogy is that in a > post-IPv4-runout > world, there are going to be "pockets" here and there of IPv4. Most > obviously, we will likely see IPv4 handoffs from ISP's to residential > customers, for many, MANY years, long after the core is IPv6, using > proxies and translators at the ISP. And why not, because any > ISP doing > that can use private numbers at no cost? It's analogous to the > local gas company is going to handoff your natural gas line to your > home or business using NPT and English-measured pipe. But, if the > gas company is buying LNG from an overseas supplier, it's likely going > to be measured in metric. > > But the idea that somehow conversion to the metric system hasn't > happened in the US, or the UK, just because they have their street > speed limit signs in miles, and their water pipe sizes and threads > in century-old dinosaur standards that predate metric, is a fantasy. > > Ted > > > From kkargel at polartel.com Wed Jul 16 17:29:48 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 16 Jul 2008 16:29:48 -0500 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 In-Reply-To: <3c3e3fca0807160945p172f6caw95e386f057251161@mail.gmail.com> References: <3c3e3fca0807160945p172f6caw95e386f057251161@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10919@mail> I for one am strongly opposed to any policy that permits user to user transfers of IP addresses bypassing ARIN qualification whether for money or for free. Any policy that accomplishes that will dilute any management efforts that ARIN has until they are worthless. With such a policy ARIN could just as well be reduced to a Wikki with a spreadsheet. From tedm at ipinc.net Wed Jul 16 18:42:56 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Jul 2008 15:42:56 -0700 Subject: [arin-ppml] Policy Proposal: DedicatedIPv4blocktofacilitateIPv6 deployment In-Reply-To: <278B5E4BCD5E654385A9F83C7CA6D51712A498E538@MAILBOX-01.qcommcorp.ad> Message-ID: <65414D67687E43F7B55971336A6554B8@tedsdesk> > -----Original Message----- > From: Hyunseog Ryu [mailto:hyunseog.ryu at norlight.com] > Sent: Wednesday, July 16, 2008 2:12 PM > To: Matthew Wilder; Matteson_Mike at emc.com; tedm at ipinc.net; > jyy at uci.edu; michael.dillon at bt.com; arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal: > DedicatedIPv4blocktofacilitateIPv6 deployment > > > I cannot help to put some feedback on this one. > I believe that the reason why U.S. is still using lb(pound), > inches, miles is because of cost concern. For some industries, that is true. However for most it is because you have an existing infrastructure that uses the older measurements and there's a need to interface with equipment using the older measurements. Take for example the lowly 12 oz aluminum beer can and think of everything, from store shelf heights, to the dual-beer hats that people wear to ball games, to automatic recycling machines, that is already designed for that exact dimension of can. The manufacturer cannot shrink or expand the size of the can without having to change all this stuff, and while the new sized cans are coming into the market, the equipment in use already will need to continue to work with the old size can, it cannot just be replaced. We are in a much better situation with IPv6 since we can dual-stack devices. > Long time ago the > federal government was trying to use meter measure instead of > mile/inch measure, but it turned out that it cost 4 times of > U.S. federal government annual budget at the time. That's > what I heard. I don't know it's true or not. But for IPv6 > deployment, it might be same reason. Which is why IPv4->IPv6 deployments are ALL envisioned as gradual changeovers. At the least, because Windows XP does not completely properly handle all IPv6 cases, even though it is dual stacked, we won't even be at the stage that we can properly dual-stack the clients used on the Internet until XP disappears. And a properly dual-stacked client is what you do at the BEGINNING of an IPv4->IPv6 changeover. > Since U.S. has so many > laywers, there will be debate who's going to pay for what. > Other countries have more power from government/service > providers. But in U.S., service provider needs to invest the > money for existing infrastructure to support IPv6 and there > will be resistance coming from consumers/users for pushing > IPv6. So far, I tried to find IPv6 transit peering from U.S. > market, but for even tier-1 providers, not all of them > supports IPv6 for peering yet. Sometimes request for IPv6 > peering got lost from sales people and engineering people, > too. So how can I expect IPv6 useable for our customers? All you need for now is ONE of your peers to support IPv6. Yes, it won't be redundant. That does not matter on a dual stack client since the client will have a redundant path through the IPv4 network. > Even > IPv6 supported tier-1 providers doesn't have native IPv6 dual > stack support from peering viewpoint. It turns out to be > tunneling method for IPv6 peering for all of cases I have > found so far. So what? I don't know your age but at one time it was common to run IPTunnel and tunnel IPv4 over Novell Netware IPX protocol on corporate WANS. Tunnelling is a transition technology and you shouldn't be afraid of it. > Most of business from U.S. is strictly based on > ROI(Return on Investment). They don't want to spend the money > unless it is absolutely necessary. From that viewpoint, most > of CEOs and management still see that they have no problem to > run the business using IPv4 only. If they need to push IPv6, > they have recommended CPE to support IPv6 and etc. It will > cost money to customers, and big players such as Tier-1 still > have some ip address available from legacy allocation such as > /8 from pre-ARIN era. So it's not immediate need for them to > push IPv6 at this moment. > Agreed. However, merely standing with hands at your sides and not participating in an IPv6 deployment is completely different than actively campaigning against IPv6 by claiming that IPv6 will never get off the ground, IPv4 is permanent, etc. Like you, I have people we buy bandwidth from who at this point only offer IPv6 tunnelling. They don't route IPv6 natively because of cost concerns of deploying it. In short, they have decided that they can make more profit allowing customers who demand native IPv6 to disconnect and go find other bandwidth providers, than spending the money to offer native IPv6. However none of them are out there telling customers that IPv6 isn't ever going to happen. Even the ones who refuse to provide IPv6 now, and will only give a tunnel, all say that they know they will have to offer IPv6 eventually. Most industry conversions happen this way, and IPv6 will be no different. In the beginning the customer base who is willing to pay for IPv6 native routing is small. Only some providers will spend the money to service them, and that is fine because if all providers spent the money to service them, then no providers would ever make any return back. As the customer base that wants to pay for IPv6 natively continues to grow, more and more of these customers will leave their native IPv4-only providers and go to IPv6/IPv4 native providers. Eventually a point is reached with the IPv4-only providers that they lose enough customers and have enough difficulty attracting new ones due to IPv6 demands that they will see it as a necessary expense to retain their existing customer base, and tool up to supply IPv6. The problem here is that there's some people out there who want to cheat. Instead of simply being honest and saying that if you want to get IPv6, quit and find another provider, they are electing to go out there and lie like dogs, and tell people that IPv6 will never amount to anything. They know that not all of their customers will believe them, but they are hoping that some will so they can stave off the expenditure for another couple of years. In the meantime this sales and marketing lying is confusing a lot of people. What people who buy bandwidth for resale need to know is that they should be doing 3 things now: 1) Asking whoever they buy bandwidth from if they have IPv6 EVEN IF they have no intention of running it right now. 2) Making IPv6 a requirement for a bandwidth contract renewal from their suppliers. 3) If they are shopping around for bandwidth, don't buy it from anyone who isn't offering IPv6 or will not committ in the contract to offering it in the next few years. If your not buying bandwidth, and your current suppliers don't offer IPv6, then you can't do anything to apply pressure to anyone in the market to supply it, so you might as well just relax and wait and see what happens, in the meantime get a test IPv6 tunnel from someone for free, and play with it a bit. Ted From sleibrand at internap.com Wed Jul 16 19:52:25 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 16 Jul 2008 16:52:25 -0700 Subject: [arin-ppml] Your views on ARIN Transfer Policy Proposal 2008-2 In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10919@mail> References: <3c3e3fca0807160945p172f6caw95e386f057251161@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10919@mail> Message-ID: <487E89B9.7070408@internap.com> Kevin, 2008-2 retains a requirement for needs-based qualification in order for potential transferees to receive addresses via transfer. What are your thoughts on that? -Scott Kevin Kargel wrote: > > I for one am strongly opposed to any policy that permits user to user > transfers of IP addresses bypassing ARIN qualification whether for money > or for free. Any policy that accomplishes that will dilute any > management efforts that ARIN has until they are worthless. With such a > policy ARIN could just as well be reduced to a Wikki with a spreadsheet. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tme at multicasttech.com Wed Jul 16 20:41:05 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 16 Jul 2008 20:41:05 -0400 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4blockto facilitateIPv6 deployment In-Reply-To: <2A22ECE278A6604A84476172F106BFCE02F02A74@CORPUSMX50A.corp.emc.com> References: <023101c8e752$1a1075c0$4e316140$@edu> <5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> <2A22ECE278A6604A84476172F106BFCE02F02A74@CORPUSMX50A.corp.emc.com> Message-ID: Dear Mike; On Jul 16, 2008, at 3:46 PM, Matteson_Mike at emc.com wrote: > Ah, Yes Ted... > ..and what is your weight in kilos, and height in meters...(w/o doing > the conversion )??? You obviously don't hang out with many physicists. What I don't understand is how any of this is relevant to the PPML list. Regards Marshall > > regards, > --MikeM-- > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > Behalf Of Ted Mittelstaedt > Sent: Wednesday, July 16, 2008 3:00 PM > To: 'Jessica (Jie Yun) Yu'; michael.dillon at bt.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4blockto > facilitateIPv6 deployment > > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jessica (Jie Yun) Yu >> Sent: Wednesday, July 16, 2008 7:42 AM >> To: michael.dillon at bt.com; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy Proposal: Dedicated IPv4 >> blockto facilitateIPv6 deployment >> >> >>> ...but do you seriously think that U.S. network operators >> will circle >>> the >> wagons and go it alone with IPv4 while the rest of >the world >> goes with IPv6? >> >> Well, it's not unprecedented that US adopts different >> standard than the rest of the world. According to >> http://en.wikipedia.org/wiki/Metric_system, the entire world >> (except 3 nations) has adopted Metric System for about 40 >> years while US is still using inch-pound system. >> > > In all US industrial markets the metric system is > in wide use. If you buy a car, a bicycle, a motorcycle, or any other > item of any complexity and you want to work on it yourself, your > going to use metric tools, not English. > > If your definition of the "entire world adopting the metric system" > means that every single measurement of anything in the world is out > of the metric system, you are very much mistaken. Measurements > are done in a variety of different standards. In threads alone > there's > about 20 different popular standards, and manufacturers and industries > will > adopt the most unusual ones you can imagine. For example, in auto > air conditioning work, when the industry shifted from chlorinated > R12 the service fittings were all American Standard flare, available > at any hardware store. The logical thing would have been to shift to > Metric ISO flare, wouldn't you think? But guess what they did shift > to? ACME, that's what. A thread standard that is used for worm > drives > on lathes and bench vises, coupled with a compression flare. It's > unique in the AC industry and completely stupid because while the > intent was to prevent DIYers from connecting their old R12 stuff > to the new AC systems, you can buy ACME-to-standard flare adapters. > > BSW Pipe thread, (ie: Whitworth) another non-metric standard, is used > on virtually all water pipes in the UK, and in Australia. MPH is also > used on speed signs in the UK and Australia and until recently, in > India. > > In the US, virtually EVERYTHING made for foreign export is metric. > > The lesson you should draw from this analogy is that in a > post-IPv4-runout > world, there are going to be "pockets" here and there of IPv4. Most > obviously, we will likely see IPv4 handoffs from ISP's to residential > customers, for many, MANY years, long after the core is IPv6, using > proxies and translators at the ISP. And why not, because any ISP > doing > that can use private numbers at no cost? It's analogous to the > local gas company is going to handoff your natural gas line to your > home or business using NPT and English-measured pipe. But, if the > gas company is buying LNG from an overseas supplier, it's likely going > to be measured in metric. > > But the idea that somehow conversion to the metric system hasn't > happened in the US, or the UK, just because they have their street > speed limit signs in miles, and their water pipe sizes and threads > in century-old dinosaur standards that predate metric, is a fantasy. > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Thu Jul 17 07:22:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Jul 2008 12:22:51 +0100 Subject: [arin-ppml] Policy Proposal: Dedicated IPv4 blockto facilitateIPv6 deployment In-Reply-To: <5DE367DCB9EB42278FF0BC19802ECF66@tedsdesk> Message-ID: > MPH is also used on speed signs in the UK Also miles on distance signs. Temperatures are reported in Celsius and although produce must be sold in kilograms many places also quote price per pound. > The lesson you should draw from this analogy is that in a > post-IPv4-runout world, there are going to be "pockets" here > and there of IPv4. Nobody is seriously suggesting that IPv6 will replace IPv4 or that companies should begin converting anything to IPv6. What we are saying is that it is time to beging deploying IPv6 so that when IPv4 addresses run out, you will still be able to grow your networks and your businesses. The IPv4 networks will stay around for a long time, but the growth will all be on IPv6. This isn't like the metric switch because nothing needs to stop using IPv4 right away. Of course we do expect that once IPv6 is deployed, some users of IPv4 will indeed switch, but the IPv4 address shortage will not be the driver for that. --Michael Dillon From info at arin.net Thu Jul 17 10:45:42 2008 From: info at arin.net (Member Services) Date: Thu, 17 Jul 2008 10:45:42 -0400 Subject: [arin-ppml] Deadline for Policy Proposals - 16 August 2008 Message-ID: <487F5B16.7000708@arin.net> The ARIN XXII Public Policy Meeting will take place 15-16 October 2008 in Los Angeles. New policy proposals must be submitted by 23:59 EDT, 16 August 2008, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XXII agenda. The ARIN Internet Resource Policy Evaluation Process requires that proposed policies must be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. Send the template via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From heather.skanks at gmail.com Thu Jul 17 13:46:25 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 17 Jul 2008 13:46:25 -0400 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <443de7ad0806250904i7f2f0479t954e2be2375194e0@mail.gmail.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> <486197D2.5010802@dilkie.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu> <48624CB0.6080106@dilkie.com> <486257D5.1030309@chl.com> <443de7ad0806250904i7f2f0479t954e2be2375194e0@mail.gmail.com> Message-ID: <616812070807171046y5c3f0691nf9f712562124a6e9@mail.gmail.com> On Wed, Jun 25, 2008 at 12:04 PM, Chris Grundemann wrote: > > > I think that there could be some compromise reached between forcing > every node on someones network to be dual stacked and just giving out > ipv6 space to everyone with no requirement for use. > > Maybe (as you suggest) ARIN should give out a /32 (or other block) to > every AS, no questions asked. Then, based on the knowledge that they > have the v6 space, you build some requirements for requesting more v4 > space. I think most will agree that requiring every host to be dual > stacked would both provide the most benefit and also be virtually > impossible to enforce. Maybe instead, the requirement should be > simply advertising the v6 block. Are you suggesting give out /32 PI to every AS? If so: Please don't add 40-50k routes to the global internet routing table if people aren't actually using them. You might want to make a clarification that you verify that the ASN is still in use and the organization actually wants PI vs PA - before assigning it a /32. If doing this through PA is also acceptable - you'd have to give larger allocations to ISP's. Their actually are some organizations that do not want to obtain and maintain their own IP space. This would require the organization > to get some sort of ipv6 transit service and would thus encourage them > to actually utilize it. No it would encourage them to route it - which is not the same as using it. > It would also help push the demand for v6 > transit. Another possible requirement is that the organizations > public website have a AAAA record from the previously assigned /32 (or > whatever size block). I think that these two requirements are easily > measurable and would noticeably affect ipv6 adoption rates. > This last idea, is not *so* bad ..in that it gives you a means to measure - and is along the lines of the 'demonstrate you are making some effort with v6' requirement that's been suggested. However it pushes enforcement to the part of the cycle when they come back for IP's. Some considerations.. I ask for IPv4 I get IPv4 + IPv6 and get told to put our public website on IPv6 as well I come back for more IPv4 - and then what? Do I get denied because I have enough IP's with IPv6? What if my public website is available on v6 -- but I want more v4 for my customers? Do I get denied because my public website isn't reachable by an IP in the IPv6 allocation I got? What if it's reachable on some other IPv6 IP? What if I contract out my public website to some company who doesn't do IPv6 yet despite all my requests for them to do it... and the IP's I'm asking for are for my corporate network, or my customers? I have to change webhosting vendors in order to be able to have my website on v6, in order to be able to get more IP's for the rest of my business? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Thu Jul 17 14:42:24 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 17 Jul 2008 13:42:24 -0500 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <616812070807171046y5c3f0691nf9f712562124a6e9@mail.gmail.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com><486197D2.5010802@dilkie.com><7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu><48624CB0.6080106@dilkie.com> <486257D5.1030309@chl.com><443de7ad0806250904i7f2f0479t954e2be2375194e0@mail.gmail.com> <616812070807171046y5c3f0691nf9f712562124a6e9@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10924@mail> This doesn't have to be this difficult or complicated. Every IPV4 request should also get a /xx if IPv6 if it does not already exist. There should be no requirement to use or route the IPv6 block. The end user can use it as PI, PA, whatever they want, or not at all. If /xx is a /32, or even a /34, there are very few organizations (on a global scale) that will actually utilize a significant percentage of an IPv6 /32. So we give people too many IPv6 addresses.. what is the problem? Excess route advertisement is simple.. if you are not going to publicly route it, don't advertise it. If you don't advertise it then it doesn't consume a slot. To my mind this is the only distinction between IPv6 public space and IPv6 private space. If you are going to route part of your block and not another part, advertise the whole block (or one contiguous block) in one aggregate statement, and access list at your edge the parts of the advertised block you do not want to route. This minimizes route slots consumed and gives you complete control over how you want to utilize your IPv6 block without having to deal with any authority. It also makes routing "private" space between peers, or inter-area tunnelling trivial. IPv4 requests are going to get tougher. Simple. There is no policy that will guarantee availability of IPv4 space to everyone or anyone forever. When it is gone we cannot manufacture more. Well, we can, by adding more bits to the address space.. hmm.. that sounds like IPv6 Every host does not have to be dual stack.. only your edge hardware needs to be dual stack.. you can translate at your edge if needed.. there is facility built in to IPv6 for v6/v4 one to one translation by prepending the IPv4 address with your IPv6 network segment.. voila, it routes and there was no internal renumbering.. Cisco hardware does this today. ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of heather skanks Sent: Thursday, July 17, 2008 12:46 PM To: Chris Grundemann Cc: ARIN PPML; Lee Dilkie Subject: Re: [arin-ppml] Linking IPv4 allocations to IPv6 On Wed, Jun 25, 2008 at 12:04 PM, Chris Grundemann wrote: I think that there could be some compromise reached between forcing every node on someones network to be dual stacked and just giving out ipv6 space to everyone with no requirement for use. Maybe (as you suggest) ARIN should give out a /32 (or other block) to every AS, no questions asked. Then, based on the knowledge that they have the v6 space, you build some requirements for requesting more v4 space. I think most will agree that requiring every host to be dual stacked would both provide the most benefit and also be virtually impossible to enforce. Maybe instead, the requirement should be simply advertising the v6 block. Are you suggesting give out /32 PI to every AS? If so: Please don't add 40-50k routes to the global internet routing table if people aren't actually using them. You might want to make a clarification that you verify that the ASN is still in use and the organization actually wants PI vs PA - before assigning it a /32. If doing this through PA is also acceptable - you'd have to give larger allocations to ISP's. Their actually are some organizations that do not want to obtain and maintain their own IP space. This would require the organization to get some sort of ipv6 transit service and would thus encourage them to actually utilize it. No it would encourage them to route it - which is not the same as using it. It would also help push the demand for v6 transit. Another possible requirement is that the organizations public website have a AAAA record from the previously assigned /32 (or whatever size block). I think that these two requirements are easily measurable and would noticeably affect ipv6 adoption rates. This last idea, is not *so* bad ..in that it gives you a means to measure - and is along the lines of the 'demonstrate you are making some effort with v6' requirement that's been suggested. However it pushes enforcement to the part of the cycle when they come back for IP's. Some considerations.. I ask for IPv4 I get IPv4 + IPv6 and get told to put our public website on IPv6 as well I come back for more IPv4 - and then what? Do I get denied because I have enough IP's with IPv6? What if my public website is available on v6 -- but I want more v4 for my customers? Do I get denied because my public website isn't reachable by an IP in the IPv6 allocation I got? What if it's reachable on some other IPv6 IP? What if I contract out my public website to some company who doesn't do IPv6 yet despite all my requests for them to do it... and the IP's I'm asking for are for my corporate network, or my customers? I have to change webhosting vendors in order to be able to have my website on v6, in order to be able to get more IP's for the rest of my business? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Thu Jul 17 14:42:49 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 17 Jul 2008 12:42:49 -0600 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <616812070807171046y5c3f0691nf9f712562124a6e9@mail.gmail.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com> <486197D2.5010802@dilkie.com> <7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu> <48624CB0.6080106@dilkie.com> <486257D5.1030309@chl.com> <443de7ad0806250904i7f2f0479t954e2be2375194e0@mail.gmail.com> <616812070807171046y5c3f0691nf9f712562124a6e9@mail.gmail.com> Message-ID: <443de7ad0807171142i6a648e80jf3d1cbad88dd348@mail.gmail.com> On Thu, Jul 17, 2008 at 11:46 AM, heather skanks wrote: > > > On Wed, Jun 25, 2008 at 12:04 PM, Chris Grundemann > wrote: >> >> >> I think that there could be some compromise reached between forcing >> every node on someones network to be dual stacked and just giving out >> ipv6 space to everyone with no requirement for use. >> >> Maybe (as you suggest) ARIN should give out a /32 (or other block) to >> every AS, no questions asked. Then, based on the knowledge that they >> have the v6 space, you build some requirements for requesting more v4 >> space. I think most will agree that requiring every host to be dual >> stacked would both provide the most benefit and also be virtually >> impossible to enforce. Maybe instead, the requirement should be >> simply advertising the v6 block. > > Are you suggesting give out /32 PI to every AS? > > If so: > Please don't add 40-50k routes to the global internet routing table if > people aren't actually using them. > You might want to make a clarification that you verify that the ASN is > still in use and the organization actually wants PI vs PA - before assigning > it a /32. Very good points. I personally would love it if all IPv6 space was PA, to help prevent the problems we are facing now with IPv4 route 'de-aggregation.' Unfortunately to speed/ease adoption I have accepted that this will not be the case. I would definitely support some sort of quick audit process to verify ASN activity and access to PA space. > > If doing this through PA is also acceptable - you'd have to give larger > allocations to ISP's. Their actually are some organizations that do not > want to obtain and maintain their own IP space. Agreed. > >> This would require the organization >> to get some sort of ipv6 transit service and would thus encourage them >> to actually utilize it. > > No it would encourage them to route it - which is not the same as using it. It would /require/ them to route it (if they want more space), which is an (possibly slight) encouragement to use it. Say you are an enterprise with no available IPv4 space and a routed block of IPv6. Do you go though the process to obtain more IPv4 space or just start utilizing the IPv6 space? If you are announcing it already, you have at least one dual-stacked router and you have IPv6 access of some sort. Add that if a transfer policy is in place, you may have to pay for the IPv4... > >> >> It would also help push the demand for v6 >> transit. Another possible requirement is that the organizations >> public website have a AAAA record from the previously assigned /32 (or >> whatever size block). I think that these two requirements are easily >> measurable and would noticeably affect ipv6 adoption rates. > > This last idea, is not *so* bad ..in that it gives you a means to measure - > and is along the lines of the 'demonstrate you are making some effort with > v6' requirement that's been suggested. However it pushes enforcement to the > part of the cycle when they come back for IP's. > > Some considerations.. > > I ask for IPv4 > I get IPv4 + IPv6 and get told to put our public website on IPv6 as well > I come back for more IPv4 - and then what? > Do I get denied because I have enough IP's with IPv6? I say no, my position is that (at least for the time being) IPv4 requests should be weighed against previous IPv4 allocations and IPv6 requests should be weighed against IPv6 allocations. > What if my public website is available on v6 -- but I want more v4 for my > customers? If there is free IPv4 space available from/through ARIN, you are announcing/routing your IPv6 allocation, your site is on v6 AND you demonstrate need for the new IPv4 allocation; then you can have it. > Do I get denied because my public website isn't reachable by an IP in the > IPv6 allocation I got? > What if it's reachable on some other IPv6 IP? IMO, if it has a AAAA record and is reachable on v6 (anybodies allocation) you pass. Also, because of the limitation with some current OS' there may need to be a provision for setting up an ipv6.company.com as opposed to requiring a AAAA on the www address. > What if I contract out my public website to some company who doesn't do IPv6 > yet despite all my requests for them to do it... and the IP's I'm asking for > are for my corporate network, or my customers? I have to change webhosting > vendors in order to be able to have my website on v6, in order to be able to > get more IP's for the rest of my business? Yes. I bet there would be a quick(er) move on the part of hosting companies to support IPv6 if they were threatened with losing customers over it. > > > -- Chris Grundemann www.linkedin.com/in/cgrundemann From mksmith at adhost.com Thu Jul 17 15:29:41 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 17 Jul 2008 12:29:41 -0700 Subject: [arin-ppml] Linking IPv4 allocations to IPv6 In-Reply-To: <443de7ad0807171142i6a648e80jf3d1cbad88dd348@mail.gmail.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40A576F3E@CL-S-EX-1.stanleyassociates.com><486197D2.5010802@dilkie.com><7663C7E01D8E094989CA62F0B0D21CD901E0DAD7@SUEXCL-02.ad.syr.edu><48624CB0.6080106@dilkie.com> <486257D5.1030309@chl.com><443de7ad0806250904i7f2f0479t954e2be2375194e0@mail.gmail.com><616812070807171046y5c3f0691nf9f712562124a6e9@mail.gmail.com> <443de7ad0807171142i6a648e80jf3d1cbad88dd348@mail.gmail.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316045EF11F@ad-exh01.adhost.lan> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Chris Grundemann > Sent: Thursday, July 17, 2008 11:43 AM > To: heather skanks > Cc: ARIN PPML; Lee Dilkie > Subject: Re: [arin-ppml] Linking IPv4 allocations to IPv6 > > On Thu, Jul 17, 2008 at 11:46 AM, heather skanks > wrote: > > > > > > On Wed, Jun 25, 2008 at 12:04 PM, Chris Grundemann > > wrote: > >> > >> > >> I think that there could be some compromise reached between forcing > >> every node on someones network to be dual stacked and just giving out > >> ipv6 space to everyone with no requirement for use. > >> > >> Maybe (as you suggest) ARIN should give out a /32 (or other block) to > >> every AS, no questions asked. Then, based on the knowledge that they > >> have the v6 space, you build some requirements for requesting more v4 > >> space. I think most will agree that requiring every host to be dual > >> stacked would both provide the most benefit and also be virtually > >> impossible to enforce. Maybe instead, the requirement should be > >> simply advertising the v6 block. > > > > Are you suggesting give out /32 PI to every AS? > > > > If so: > > Please don't add 40-50k routes to the global internet routing table if > > people aren't actually using them. > > You might want to make a clarification that you verify that the ASN is > > still in use and the organization actually wants PI vs PA - before assigning > > it a /32. > > Very good points. I personally would love it if all IPv6 space was > PA, to help prevent the problems we are facing now with IPv4 route > 'de-aggregation.' Unfortunately to speed/ease adoption I have > accepted that this will not be the case. I would definitely support > some sort of quick audit process to verify ASN activity and access to > PA space. > > How would PA space solve de-aggregation? I have a /32 from ARIN that I route over my multiple transit providers. So, now I have PA space from a provider that I route over multiple transit providers? Or, are you saying I should have only one provider? Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From vixie at isc.org Fri Jul 18 12:59:59 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 18 Jul 2008 16:59:59 +0000 Subject: [arin-ppml] Mark Townsley: IPv4 and IPv6 Co-existence discussions in Dublin Message-ID: <10082.1216400399@nsa.vix.com> for those of you not on the ietf distribution lists, they're talking about ipv4 address exhaustion and ipv4/ipv6 coexistence. see attached. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An embedded message was scrubbed... From: Mark Townsley Subject: IPv4 and IPv6 Co-existence discussions in Dublin Date: Fri, 18 Jul 2008 18:30:05 +0200 Size: 8259 URL: From bmanning at vacation.karoshi.com Fri Jul 18 13:11:44 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 18 Jul 2008 17:11:44 +0000 Subject: [arin-ppml] Mark Townsley: IPv4 and IPv6 Co-existence discussions in Dublin In-Reply-To: <10082.1216400399@nsa.vix.com> References: <10082.1216400399@nsa.vix.com> Message-ID: <20080718171144.GA9739@vacation.karoshi.com.> On Fri, Jul 18, 2008 at 04:59:59PM +0000, Paul Vixie wrote: > for those of you not on the ietf distribution lists, they're talking about > ipv4 address exhaustion and ipv4/ipv6 coexistence. see attached. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > Apologies for cross-posting, please reply only to int-area at ietf.org > > All, > > Specifically, two initial steps appear as potential work items: > > 2. NAT-PT was deprecated for reasons described in RFC 4966. However, > there are scenarios where some forms of translation may be necessary. In > particular, the IAB noted in [1] that scenarios involving servers without > public IPv4 addresses cannot be adequately handled with the existing > mechanisms. Requirements on this issue have been discussed in V6OPS, and > a problem statement document written [2]. One possible translation design > with reduced scope from NAT-PT as defined in RFC 2766 has been discussed > recently in the BEHAVE WG [3], but there are other possible designs as > well [5]. In essence, these designs attempt to reduce the problems present > in NAT-PT by various techniques, including limiting themselves to a > simpler part of the overall problem, allowing some changes in IPv6 hosts, > and generally being designed with a better knowledge of the issues in RFC > 4966. We believe that, on balance, the benefits outweigh the costs on > developing a standard method for translation of IPv4 and IPv6. This will > likely have a smaller scope, at least in the short term, than the original > NAT-PT though it will inevitably share some of the same limitations. being an active user of the code referenced in [5], it meets most of my v4/v6 translation requirements (either way) ... although it does have problems w/ apps that presume the ability to tunnel (MMORG et.al. on PS3, WII etc) that code has been given to ARIN staff for evaluation/review and i'll be talking about it at the I2/JT meetings next week. Lots of interest in some parts of the I2 - EDU community. if anyone else wants a copy, hollar. > We would like to focus our discussions on whether the requirements > scenario and architectural direction is sufficiently ready so that the > work can be given to the protocol WGs. If the answer to these questions > is yes, after the Dublin IETF the ADs will recharter the relevant > working groups to do the work. V6OPS is already working on the > requirements. We expect that the behave WG would be the primary solution > discussion forum and produce the base translation specification. 6MAN > and DNSEXT would in turn handle any IPv6 stack or DNS protocol impacts > (including a DNS ALG, if needed). IVI doesn't require any DNS specific changes ... (although there are some places where there are application specific assumptions on IP characteristics... but thats layer violation for you.) > [5] http://tools.ietf.org/id/draft-xli-behave-ivi > --bill From bmanning at vacation.karoshi.com Tue Jul 22 20:01:22 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 23 Jul 2008 00:01:22 +0000 Subject: [arin-ppml] Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) In-Reply-To: References: <7582BC68E4994F4ABF0BD4723975C3FA09DDF45B@crexc41p> Message-ID: <20080723000122.GA21946@vacation.karoshi.com.> you know, this outcome (ULA == GUA) was predicted from the begining of the ULA emergence. and the many assurances that *never* would ULA's *ever* become GUAs are hollow. --bill On Tue, Jul 22, 2008 at 06:15:04PM -0400, Alain Durand wrote: > [Changing the title of this long thread to focus the discussion and trimming > the distribution list] > > We have a trade-off here to make between network stability and application > complexity: either modify apps to deal with renumbering (ie try > reconnecting, avoid well know literal addresses, use some kind of service > location,...) or to teach application when it is ok to use ULA vs GUA, > especially in referrals. > > My take is that the former is simpler and lead to less service calls. The > later introduce the notion that apps have to be aware of the topology, which > I found disturbing. > > - Alain. > > > On 7/22/08 6:05 PM, "Stark, Barbara" wrote: > > > Please don't change the ULA requirement. I believe ULA is needed. And I agree > > that apps need to be intelligent about the scope of the addresses they are > > using. I do not want to see the ULA go away. It needs to be persistent and > > always there, from my perspective. > > Barbara > > > > -----Original Message----- > > From: owner-v6ops at ops.ietf.org [mailto:owner-v6ops at ops.ietf.org] On Behalf Of > > Hemant Singh (shemant) > > Sent: Tuesday, July 22, 2008 5:02 PM > > To: Alain Durand; Ralph Droms (rdroms) > > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi Denis-Courmont; > > v6ops at ops.ietf.org; Wes Beebee (wbeebee) > > Subject: RE: New (-02) version of IPv6 CPE Router draft is available for > > review > > > > Alain, > > > > Very sorry, I missed your "*with* address referral" phrase. Thanks for > > providing the example. Here is the analysis: > > > > Yes, if C tries to communicate with B using B's ULA for destination, C will > > also slap its ULA on the packet src address. Thereafter before the CPE Router > > WAN interface egresses the packet, the router has to comply to ULA forwarding > > rules. As per section 4.3 of RFC4193, the CPE Router will drop the packet > > (unless the router is explicitly configured for a route to destination ULA) > > and send an ICMPv6 Destination Unreachable to C. Here is the text from the > > RFC. > > > > [Site border routers and firewalls should be configured to not forward > > any packets with Local IPv6 source or destination addresses outside > > of the site, unless they have been explicitly configured with routing > > information about specific /48 or longer Local IPv6 prefixes.] > > > > I don't expect the CPE Router to be supporting a site connected to another ULA > > site so the question of any configuration on the CPE Router for a neighbor ULA > > site is out of the question. Since C gets some error indication, the app then > > needs to figure out fixes in its implementation. > > > > Sorry, I don't see this as rustication to change the CPE Router permanent ULA. > > Some brain-dead apps need fixing. I need more people to speak up and give > > their opinion. I am still open to change. > > > > Thanks. > > > > Hemant > > > > -----Original Message----- > > From: Alain Durand [mailto:alain_durand at cable.comcast.com] > > Sent: Tuesday, July 22, 2008 1:25 PM > > To: Hemant Singh (shemant); Ralph Droms (rdroms) > > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi Denis-Courmont; > > v6ops at ops.ietf.org; Wes Beebee (wbeebee) > > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > > review > > > > Hemant, > > > > You missed the phrase "*with* address referral" in my response. > > > > Say A & B are inside their home and use ULA & GUA. C and D are within another > > home and are also using ULA & GUA. > > > > Now, A B C & D enter a 4 way communication where they initially exchange the > > addresses of their pier. > > If A passes C the ULA and GUA of B, C might prefer to use B's ULA because of > > address selection rules and C->B communication would fail or worse, go > > somewhere else. > > > > There are multiple variants of this. The point is that you cannot expect apps > > that passes addresses to be smart enough to know about ULA & GUA. > > > > BTw, using DNS does not help at all if you include both ULA & GUA AAAAs in > > your zone... > > > > - Alain. > > > > > > On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: > > > >> Alain, > >> > >> Sorry I don't understand. If any node in the home using an ULA sends > >> a packet out the WAN interface of the CPE Router, the src-addr of the > >> packet used is the GUA before the packet heads out of the node > >> because, as we said in our draft, GUA has larger scope. So any > >> multi-party host on the Internet sees only the GUA. I will need a > >> specific example to show me how multi-party communications will break > >> down with ULA and GUA configured on an interface of any node in the > >> home behind the CPE Router or if ULA and GUA is configured on the LAN > >> Interface of the CPE Router. > >> > >> Thanks. > >> > >> Hemant > >> > >> -----Original Message----- > >> From: Alain Durand [mailto:alain_durand at cable.comcast.com] > >> Sent: Tuesday, July 22, 2008 11:48 AM > >> To: Hemant Singh (shemant); Ralph Droms (rdroms) > >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi > >> Denis-Courmont; v6ops at ops.ietf.org; Wes Beebee (wbeebee) > >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available > >> for review > >> > >> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote: > >> > >>> I have repeatedly said, I am not convinced the ULA gets appreciable > >>> complexity into the CPE Router. Our section 5.5.1 has clearly > >>> outlined any complexity and shown it's minimal. The ULA fixes a very > >>> common problem for the CPE Router which is configuring the router > >>> without any SP access - the problem is not a corner case. > >> > >> Hemant, > >> > >> 2 party communications in the presence of mixed ULA & GUA work ok, > >> given proper default address selection rules. > >> > >> Multi-party communications *with* address referral do not work in the > >> general case in such a mixed environment, regardless of default address > >> selection. > >> > >> - Alain. > >> > >> > > > > > > > > > > ***** > > > > The information transmitted is intended only for the person or entity to which > > it is addressed and may contain confidential, proprietary, and/or privileged > > material. Any review, retransmission, dissemination or other use of, or taking > > of any action in reliance upon this information by persons or entities other > > than the intended recipient is prohibited. If you received this in error, > > please contact the sender and delete the material from all computers. GA621 > > > > > > >