Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
On 9/24/11 11:24 AM, "Cameron Byrne" wrote: > Let's avoid having yet another thread where there is no consensus but the > parties continue to restate their claims over and over. Fair enough. We're discussing the reservation of a prefix; the context is a foregone conclusion. > Now, if you are in the business of selling ipv4 address space on the > secondary market, as folks have linked to you before on the nanog list, you > must like the idea of pushing out ipv6 deployment in favor of the broken > nat444 ipv4 ecosystem platitudes about ipv6 aside. > Here you claim to be "friends" with ipv4 black-marketeers > http://diswww.mit.edu/charon/nanog/139751 Yes, I'm friends with many people. Some of them vote for the opposite political party as me, some of them work for my competitors, etc. I may agree with some friends, disagree with others, and even hold competing ideas in my mind at the same time. Yet I remain my own person. -Benson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
On Sep 24, 2011 8:36 AM, "Benson Schliesser (bschlies)" wrote: > > > On Sep 23, 2011, at 20:54, "Cameron Byrne" wrote: > >> So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? > > 240/4 would be very useful if designated unicast. We should do that, in my opinion. But it's not immediately deployable. It can't be "fixed over time" in the sense that a prefix reserved from GUA might be; that is, it can't be deployed today and fixed over time. Rather, 240/4 is only useful after the fix is deployed. > > For what it's worth, to my knowledge none of the co-authors of draft-weil or draft-bdgks have ever expressed any love for the architectural impact of CGN. We all agree that IPv6 is the best choice from a forward-looking perspective. But we also know that the short-term needs of some service providers are driving them to deploy CGN as NAT444. > > This reservation may help make it less broken. But one concerned over IPv6 deployment may take solace in the fact that, even in the best case, CGN will be worse than native IPv6 in multiple dimensions. Just because I'm putting on a bandage today, doesn't mean that I consider it a good long-term solution. > > Cheers, > -Benson > Let's avoid having yet another thread where there is no consensus but the parties continue to restate their claims over and over. I don't see anything new in what you wrote. Things happen fast when revenue is on the line. Now, if you are in the business of selling ipv4 address space on the secondary market, as folks have linked to you before on the nanog list, you must like the idea of pushing out ipv6 deployment in favor of the broken nat444 ipv4 ecosystem platitudes about ipv6 aside. Here you claim to be "friends" with ipv4 black-marketeers http://diswww.mit.edu/charon/nanog/139751 The ietf must stick to the guidance that ipv6 replaces ipv4, not that shady black markets and middle boxes replace ipv4. Now, my motivation -- I have taken the ietf guidance and have laid the ground work for deploying ipv6 to mass consumers in the near term. The ietf has been unequivocal that ipv6 is the path forward for years. As an ipv6 network, I am subject to Metcalfe's law... meaning, if I am the only one doing v6 I am in bad shape, but if everyone else has been listening to the ietf in good faith, then ipv6 will be deployed soon (as ipv4 depletes) and Metcalfe's law is a fortuitous cycle of compound benefits for me, ipv6 networks, and ipv6 users. And, conversely, efforts to prolong ipv4 are a direct inhibitor to my short term and medium term benefits in deploying ipv6. The IETF prolonging IPv4 with this effort is changing the rules of the game and overturning well known and long standing precedent, including not joining 240/4 with public or private pools. Governing bodies should not overturn long standing precedent and change the rules of the game at critical times where change is required. Cb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On 9/23/11 14:41 , Benson Schliesser wrote: > Hi, Brian. > > On 9/23/11 3:40 PM, "Brian E Carpenter" wrote: >> On 2011-09-23 17:21, Benson Schliesser wrote: >> >>> However, I would like to make sure we don't lose sight of the need >>> for some urgency with draft-weil. >> >> I'm a little puzzled by the claim of urgency; I remember hearing in >> July 2008 that doom was imminent if this was not done immediately. >> >> I thought that the urgent issue was deploying IPv6. > > I agree; no doubt, deploying IPv6 is urgent. But, unfortunately, operators > often face multiple urgent issues at the same time. > > In any case, the urgency that I referred to is a reflection of advice from > various ARIN leaders. Obviously, there is a future date at which ARIN will > be unable to donate the /10 prefix because of IPv4 inventory exhaustion. A prefix is not donated because they are not property of arin. Directing the allocation of a prefix through a standards action is what is in the table. > More near-term is the prospect that operators will deploy CGN using global > unicast addresses. This might have negative repercussions for the operator > and/or their users, along the lines of scope detection etc. All CGN deployments have negative repurcussions for the users, it's the job of the operators to decide how to minimize those based on their specific circumstances. any newly assigned prefix will be treated as global unicast space by existing cpe (and hosts) so in the near term that doesn't sound like a substative distinction. the question of where it's RFC1918 (as it for the verizon 4G modem I'm sending this over) or a global unicastish prefix seems germain. > It definitely > has negative repercussions for the rate at which RIR inventories are > exhausted. > > In other words, the sooner we act, the more benefit this reservation will > have. That doesn't imply that we have so little time we are unable to > address the issues raised by the IESG. But we certainly don't have the sort > of time that many drafts commonly require, per the stats at > http://www.arkko.com/tools/lifecyclestats.html for example. > > Cheers, > -Benson > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-bdgks-arin-shared-transition-space-03
On 9/24/11 03:24 , SM wrote: > At 20:48 23-09-2011, Doug Barton wrote: >> This document, and >> https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03 >> talk about the potential pitfalls of not allocating the space, but my >> reading of them didn't reveal an adequate examination of the opportunity >> cost of taking 4,096 /22s out of the free pool. > > There are three ways to get an allocation from the IANA free pool: > > 1. RIR allocation (that's no longer possible) > > 2. A global policy > > 3. A protocol assignment > > A global policy proposal would take some time and it would not fare well > as the ARIN region has ticked off the APNIC region due to its unilateral > stance about how IPv4 addresses should be managed. The third option > offers a path to work around that. > > Section 2.2.2 of draft-bdgks-arin-shared-transition-space-03 is another > option. I would not be surprised if ARIN blessed that option. > > Section 4.1.2.1 of the draft mentions that: > > "Since the volume of impacted endpoints will be low, operators can >likely manage the disabling of 6to4 when needed." > > I smiled when I saw that as it is contrary to some positions taken > during the previous 6to4 controversy. :-) I don't really believe the scale of the problem is fairly characterized by the text. manually disabling (where possible) or physcially replacing existing cpe are no more scalable than any other form of intervention. it is worth noting that in general this problem can be address by putting an rfc 1918 address on the outside. the proponents of the demise of 6to4 are precisely the folks who really would prefer not to break 6to4 in this fashion. less-than-functional auto-tunneling does enough damage already without our help. ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
On Sep 23, 2011, at 20:54, "Cameron Byrne" wrote: > So if there is going to be breakage, and folks are willing to fix it over > time because the good outweighs the bad (I personally do not believe this), > then why not dedicate 240/4 for this purpose? > 240/4 would be very useful if designated unicast. We should do that, in my opinion. But it's not immediately deployable. It can't be "fixed over time" in the sense that a prefix reserved from GUA might be; that is, it can't be deployed today and fixed over time. Rather, 240/4 is only useful after the fix is deployed. For what it's worth, to my knowledge none of the co-authors of draft-weil or draft-bdgks have ever expressed any love for the architectural impact of CGN. We all agree that IPv6 is the best choice from a forward-looking perspective. But we also know that the short-term needs of some service providers are driving them to deploy CGN as NAT444. This reservation may help make it less broken. But one concerned over IPv6 deployment may take solace in the fact that, even in the best case, CGN will be worse than native IPv6 in multiple dimensions. Just because I'm putting on a bandage today, doesn't mean that I consider it a good long-term solution. Cheers, -Benson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-bdgks-arin-shared-transition-space-03 (was: Last Call: (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
At 20:48 23-09-2011, Doug Barton wrote: This document, and https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03 talk about the potential pitfalls of not allocating the space, but my reading of them didn't reveal an adequate examination of the opportunity cost of taking 4,096 /22s out of the free pool. There are three ways to get an allocation from the IANA free pool: 1. RIR allocation (that's no longer possible) 2. A global policy 3. A protocol assignment A global policy proposal would take some time and it would not fare well as the ARIN region has ticked off the APNIC region due to its unilateral stance about how IPv4 addresses should be managed. The third option offers a path to work around that. Section 2.2.2 of draft-bdgks-arin-shared-transition-space-03 is another option. I would not be surprised if ARIN blessed that option. Section 4.1.2.1 of the draft mentions that: "Since the volume of impacted endpoints will be low, operators can likely manage the disabling of 6to4 when needed." I smiled when I saw that as it is contrary to some positions taken during the previous 6to4 controversy. :-) draft-bdqks-arin-shared-transition-space went through a WGLC and it has been determined that there is rough consensus in OPSAWG to request publication. In my opinion it is inappropriate use of the IETF Stream as it is not the right venue for RIR politics. I don't believe that it is the intent of the authors to do that but that's what it is going to be translated into. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
