Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP'
not replying specific to this mail but to the tons that have arrived lately, are there some confusion out there that it is the amount of votes on ietf@ that make a do/do not on a draft? ... or just me missunderstanding this? anyway, great to see people participate :-) --- Roger J --- On Tue, Feb 14, 2012 at 6:19 PM, Erichsen, Kirk kirk.erich...@twcable.com wrote: I fully support this draft and would like to see it progress to conclusion without further delay. With warm regard, Kirk Erichsen Principle Technology Engineer Time Warner Cable ATG West This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Tue, 2012-02-14 at 19:26 -0600, Pete Resnick wrote: On 2/14/12 2:35 PM, Randy Bush wrote: what silliness. it will be used as rfc 1918 space no matter what the document says. [...] any thought that this is not just adding to rfc 1918 is pure bs. Of course it will be used as 1918 space. That's not the point of the text. No support. For the various reasons people have put forth, and my own below, this draft should not be put through. The text is saying, You could read 1918 to say that we somehow promised that you would never be connected to a network run by someone other than yourself and see 1918 addresses on it. That's not an entirely intelligent reading, but we see how you can read it that way. So, if you built yourself a device where it isn't able to deal with 1918 addresses on its 'outside' interface that you were using on the 'inside' interfaces, we could see how that might happen. It was not at all smart of you to build your device that way, but you probably were technically within spec. Now we're adding some address space to the pool. It's not global and it's not routable, just the same as 1918 space. But we're letting you know right now: You *will* see these addresses on networks that you don't run. If you want to use this space the way that you used 1918 space, peachy, but understand that if you're unable to deal with these addresses duplicating ones you're using, your device is toast. Deal with it. This is 100% matched by an allocation of globally unique space from a RIR, shared by whoever the interested parties are. The IETF *need not* specify any BCP on how to improve NAT444 CGN-scale alone, because such action is attached with high risk of leading to a local maximum in a plot of the state of the Internet, rather than towards a global maximum. Citing RFC6264, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition warns: Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large Scale NAT, compounds IPv4 operational problems when used alone but does nothing to encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows ISPs to delay the transition and therefore causes double transition costs (once to add CGN and again to support IPv6). The draft as written, makes no effort to require the RFC6264 or equivalent approaches to a IPv6 transition, to the CGN deployments it specifies v4 address space for. All carrot, no stick. I believe the state of the Internet would be much more reliably improved by the RIRs each having (for the purpose of being able to serve their own users) one /10 special allocation for this purpose, which they can assign to multiple users upon demonstrating, under contract, they are transitioning to IPv6 according to 6264, or equivalent. As written there is no effort to mitigate the risk mentioned in the quote above, and I can't support a draft that will hurt the Internet and neither should you. Best, Martin signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 16, 2012 at 03:43, Martin Millnert mar...@millnert.se wrote: This is 100% matched by an allocation of globally unique space from a RIR, shared by whoever the interested parties are. The IETF *need not* specify any BCP on how to improve NAT444 CGN-scale alone, because such action is attached with high risk of leading to a local maximum in a plot of the state of the Internet, rather than towards a global maximum. Citing RFC6264, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition warns: Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large Scale NAT, compounds IPv4 operational problems when used alone but does nothing to encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows ISPs to delay the transition and therefore causes double transition costs (once to add CGN and again to support IPv6). The draft as written, makes no effort to require the RFC6264 or equivalent approaches to a IPv6 transition, to the CGN deployments it specifies v4 address space for. All carrot, no stick. I believe the state of the Internet would be much more reliably improved by the RIRs each having (for the purpose of being able to serve their own users) one /10 special allocation for this purpose, which they can assign to multiple users upon demonstrating, under contract, they are transitioning to IPv6 according to 6264, or equivalent. As written there is no effort to mitigate the risk mentioned in the quote above, and I can't support a draft that will hurt the Internet and neither should you. Apologies for my bluntness, but this argument is a complete misinterpretation of the facts on the ground. This draft is not about encouraging nor facilitating CGN deployments. Allocating a /10 for inside CGN addressing use _will not_ make anyone deploy CGN who would not have otherwise done so. Not allocating a /10 for inside CGN addressing use _will not_ stop anyone from deploying CGN who would have otherwise done so. In fact, neither you nor I nor the IETF can stop operators who must deploy CGN for business continuity from doing so. What we can do, is ensure that when those folks who must deploy CGN do so, that they break the Internet as little as possible. And _that_ is what this I-D seeks to accomplish. And that is why I support it, and why you should too. Cheers, ~Chris Best, Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP'
On Thu, Feb 16, 2012 at 02:34, Roger Jørgensen rog...@gmail.com wrote: not replying specific to this mail but to the tons that have arrived lately, are there some confusion out there that it is the amount of votes on ietf@ that make a do/do not on a draft? ... or just me missunderstanding this? It is my understanding that the IETF operates in an open, bottom-up, consensus-based manor and thus that all voices, taken in context, are important in all decisions made. anyway, great to see people participate :-) It is indeed. ~Chris --- Roger J --- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Dear Chris, On Thu, 2012-02-16 at 08:43 -0700, Chris Grundemann wrote: On Thu, Feb 16, 2012 at 03:43, Martin Millnert mar...@millnert.se wrote: This is 100% matched by an allocation of globally unique space from a RIR, shared by whoever the interested parties are. The IETF *need not* specify any BCP on how to improve NAT444 CGN-scale alone, because such action is attached with high risk of leading to a local maximum in a plot of the state of the Internet, rather than towards a global maximum. Citing RFC6264, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition warns: Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large Scale NAT, compounds IPv4 operational problems when used alone but does nothing to encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows ISPs to delay the transition and therefore causes double transition costs (once to add CGN and again to support IPv6). The draft as written, makes no effort to require the RFC6264 or equivalent approaches to a IPv6 transition, to the CGN deployments it specifies v4 address space for. All carrot, no stick. I believe the state of the Internet would be much more reliably improved by the RIRs each having (for the purpose of being able to serve their own users) one /10 special allocation for this purpose, which they can assign to multiple users upon demonstrating, under contract, they are transitioning to IPv6 according to 6264, or equivalent. As written there is no effort to mitigate the risk mentioned in the quote above, and I can't support a draft that will hurt the Internet and neither should you. Apologies for my bluntness, but this argument is a complete misinterpretation of the facts on the ground. Taking: This draft is not about encouraging nor facilitating CGN deployments. Allocating a /10 for inside CGN addressing use _will not_ make anyone deploy CGN who would not have otherwise done so. Not allocating a /10 for inside CGN addressing use _will not_ stop anyone from deploying CGN who would have otherwise done so. + What we can do, is ensure that when those folks who must deploy CGN do so, that they break the Internet as little as possible. And _that_ is what this I-D seeks to accomplish. you seem to be of the opinion that improving the feasibility of CGN, by making it suck less, will not have any impact on potential set of networks who are deploying it, or in what way they will deploy it. You seem to want me to believe that: - there is a fixed set of networks, who are going to deploy either: - a sucky IPv4 network, or, - a less sucky IPv4 network, - it would be entirely depending on the passing of this draft, - the failure of passing of this draft somehow will exclude from these networks the possibility of obtaining non-RFC1918 space in another way, for example as I outlined The latter two points seem a bit far-fetched. I'm curious how you can possibly have sufficient knowledge to make those statements as *facts*, rather than opinions, informed as the may be (but of limited scope -- I think it unlikely you've spoken to every network on the planet). In fact, neither you nor I nor the IETF can stop operators who must deploy CGN for business continuity from doing so. I hold no such illusions. What the IETF ought to do however, IMHO, is to point them in a good direction. I don't see that happening in this document. A less-sucky IPv4-run-out access network is still a local maxima compared to the global maxima of DS. Convince me that our journey to reach the global maxima will not be negatively affected by this document, and gain my support. Kind regards, Martin signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 16/02/2012 16:35, Martin Millnert wrote: You seem to want me to believe that: - there is a fixed set of networks, who are going to deploy either: - a sucky IPv4 network, or, - a less sucky IPv4 network, - it would be entirely depending on the passing of this draft, - the failure of passing of this draft somehow will exclude from these networks the possibility of obtaining non-RFC1918 space in another way, for example as I outlined The latter two points seem a bit far-fetched. Martin, Far-fetched - like all straw men. I'm curious how you can possibly have sufficient knowledge to make those statements as *facts*, rather than opinions, informed as the may be (but of limited scope -- I think it unlikely you've spoken to every network on the planet). More straw men. Look, we're adults here: please present good arguments. The bottom line for this ID is that address space will be required for CGN, and rfc1918 doesn't cut it for reasons described in the ID. This means that the address space must come from somewhere else. The choices are: 1. one or more shared pools allocated by RIRs/IANA/whatever 2. private pools, each of which come from the carriers' own address blocks option #1 is by definition more efficient than #2. At least one of the RIRs has indicated that they cannot assign this space due to charter problems. There is no particular reason to allocate this space on a regional basis, unless for some reason you believe that you can force carriers only to use this shared address space for specific purposes - and I cannot see why you think that this is remotely feasible for shared address space. Private address space, perhaps. But certainly not shared address space. The core function of a RIR is to guarantee that if they allocate you a bunch of numbers, that they haven't allocated the same bunch of numbers to someone else. Therefore by definition they have no particular authority over the way that shared address space might be used internally by a carrier. Incidentally, I support this draft. Nick ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 16, 2012 at 09:35, Martin Millnert mar...@millnert.se wrote: Dear Chris, On Thu, 2012-02-16 at 08:43 -0700, Chris Grundemann wrote: On Thu, Feb 16, 2012 at 03:43, Martin Millnert mar...@millnert.se wrote: This is 100% matched by an allocation of globally unique space from a RIR, shared by whoever the interested parties are. The IETF *need not* specify any BCP on how to improve NAT444 CGN-scale alone, because such action is attached with high risk of leading to a local maximum in a plot of the state of the Internet, rather than towards a global maximum. Citing RFC6264, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition warns: Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large Scale NAT, compounds IPv4 operational problems when used alone but does nothing to encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows ISPs to delay the transition and therefore causes double transition costs (once to add CGN and again to support IPv6). The draft as written, makes no effort to require the RFC6264 or equivalent approaches to a IPv6 transition, to the CGN deployments it specifies v4 address space for. All carrot, no stick. I believe the state of the Internet would be much more reliably improved by the RIRs each having (for the purpose of being able to serve their own users) one /10 special allocation for this purpose, which they can assign to multiple users upon demonstrating, under contract, they are transitioning to IPv6 according to 6264, or equivalent. As written there is no effort to mitigate the risk mentioned in the quote above, and I can't support a draft that will hurt the Internet and neither should you. Apologies for my bluntness, but this argument is a complete misinterpretation of the facts on the ground. Taking: This draft is not about encouraging nor facilitating CGN deployments. Allocating a /10 for inside CGN addressing use _will not_ make anyone deploy CGN who would not have otherwise done so. Not allocating a /10 for inside CGN addressing use _will not_ stop anyone from deploying CGN who would have otherwise done so. + What we can do, is ensure that when those folks who must deploy CGN do so, that they break the Internet as little as possible. And _that_ is what this I-D seeks to accomplish. you seem to be of the opinion that improving the feasibility of CGN, by making it suck less, will not have any impact on potential set of networks who are deploying it, or in what way they will deploy it. Correct. You seem to want me to believe that: - there is a fixed set of networks, who are going to deploy either: - a sucky IPv4 network, or, - a less sucky IPv4 network, - it would be entirely depending on the passing of this draft, - the failure of passing of this draft somehow will exclude from these networks the possibility of obtaining non-RFC1918 space in another way, for example as I outlined The latter two points seem a bit far-fetched. Not quite, let me try again. I am stating that: - Dual-Stack requires both IPv4 and IPv6 addresses - There is a non-zero number of networks which will exhaust all available IPv4 resources before the world is able to fully transition to IPv6 - These networks must choose one of either: -- Go out of business -- Find a new way to provide IPv4 connections to customers - NAT44* CGN will be chosen by a non-zero number of these networks - This decision is independent of what addresses they will use inside of the CGN (No one wants to go through two transitions. Folks who deploy CGN do so because they must. As such, the addresses used are an afterthought. The cost of CGN and it's alternatives are what drive the decision, not this I-D or the addresses it seeks to reserve.) I'm curious how you can possibly have sufficient knowledge to make those statements as *facts*, rather than opinions, informed as the may be (but of limited scope -- I think it unlikely you've spoken to every network on the planet). You are again correct, I have not spoken to every network on the planet. I have spoken to many. Several in the Asia/Pacific region have already experienced the chain of events I outlined above. Further, my job is to understand the IPv6 transition and as such, much of my time is dedicated to creating this understanding. I do not make these claims lightly. In fact, neither you nor I nor the IETF can stop operators who must deploy CGN for business continuity from doing so. I hold no such illusions. What the IETF ought to do however, IMHO, is to point them in a good direction. I don't see that happening in this document. A less-sucky IPv4-run-out access network is still a local maxima compared to the global maxima of DS. Convince me that our journey to reach the global maxima will not be negatively affected by this document, and gain my support. Once an operator has decided that
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Hi Nick, On Thu, 2012-02-16 at 16:58 +, Nick Hilliard wrote: There is no particular reason to allocate this space on a regional basis, unless for some reason you believe that you can force carriers only to use this shared address space for specific purposes - and I cannot see why you think that this is remotely feasible for shared address space. Private address space, perhaps. But certainly not shared address space. I'm not sure why a contract with a RIR would be less enforceable than this I-D. On the contrary, I think the chances of correct use are higher in that scenario than the other. It's just bits, you know. IPv4-code on the general internet certainly won't care about these bits. Routing policy however, may. I do not see how having the BCP makes any difference, if the allocation comes from the RIR in either case, provided there is at least one RIR which can assign address space to an entity who will share it. Best, Martin signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Hi Chris, On Thu, 2012-02-16 at 10:09 -0700, Chris Grundemann wrote: On Thu, Feb 16, 2012 at 09:35, Martin Millnert mar...@millnert.se wrote: snip you seem to be of the opinion that improving the feasibility of CGN, by making it suck less, will not have any impact on potential set of networks who are deploying it, or in what way they will deploy it. Correct. .. except for the part of actually changing what addresses they put on the inside, which the I-D is about. Perhaps it's splitting hairs whether that constitutes a change or not, but if it's not a change, it's weird that it would improve the quality of the network. :-) snip I am stating that: - Dual-Stack requires both IPv4 and IPv6 addresses - There is a non-zero number of networks which will exhaust all available IPv4 resources before the world is able to fully transition to IPv6 - These networks must choose one of either: -- Go out of business -- Find a new way to provide IPv4 connections to customers - NAT44* CGN will be chosen by a non-zero number of these networks - This decision is independent of what addresses they will use inside of the CGN (No one wants to go through two transitions. Folks who deploy CGN do so because they must. As such, the addresses used are an afterthought. The cost of CGN and it's alternatives are what drive the decision, not this I-D or the addresses it seeks to reserve.) In the end, I suppose, networks who do not also roll-out DS in combination with NAT44* CGN, are a blessing for their competition... where such competition physically exists. I'm curious how you can possibly have sufficient knowledge to make those statements as *facts*, rather than opinions, informed as the may be (but of limited scope -- I think it unlikely you've spoken to every network on the planet). You are again correct, I have not spoken to every network on the planet. I have spoken to many. Several in the Asia/Pacific region have already experienced the chain of events I outlined above. Check. (I'm aware, as well.) Further, my job is to understand the IPv6 transition and as such, much of my time is dedicated to creating this understanding. I do not make these claims lightly. Cool. I haven't/certainly didn't mean to suggest you did. In fact, neither you nor I nor the IETF can stop operators who must deploy CGN for business continuity from doing so. I hold no such illusions. What the IETF ought to do however, IMHO, is to point them in a good direction. I don't see that happening in this document. A less-sucky IPv4-run-out access network is still a local maxima compared to the global maxima of DS. Convince me that our journey to reach the global maxima will not be negatively affected by this document, and gain my support. Once an operator has decided that they have no other choices remaining and that they must deploy CGN, they then have to decide how to architect that deployment. One of the architectural decisions to be made (and the one we are concerned with here) is what addresses to use within the CGN. They have several options: - Globally Unique Public Addresses This option burns addresses that they or others could use to number devices that actually require a unique address, this is a net loss to the Internet. - RFC 1918 Private Addresses The chance for collision and the low margins of residential broadband make this option a non-starter. Nothing any of us say will convince any substantial number of operators to shoot themselves in the foot in this way. - Class E Addresses Too much equipment is hard coded to reject these addresses. It simply will not work in time to make a difference. - Squat Addresses Without a shared address space, this is the likely winner. Squatting on someone else's address space works and is free. A misconfigured filter allows these to leak however, another net loss to an un-borked Internet. - Shared Addresses This is the solution put forth in the I-D under discussion here. This allows an alternative that is attractive to operators and can be managed (since it is a known prefix). If one operator leaks routes, others will have filters in place. This option removes the least amount of addresses from the remaining free pools thus allowing Dual-Stack to work in the most possible networks. All in all, this is the best way to ensure a less broken Internet than any of the other options can provide. Not seeing a limitation to NAT444, you left out various alternatives which have integrated IPv6/DS. Alternatives which, once installed, will lead to a steady (comparing with the v4-only case) reduction in load on the CGN equipment, as the world increasingly moves towards DS/v6-only. Such alternatives may not apply to the CGN variant NAT444, which I ACK the I-D addresses. Again, we are not talking about encouraging or discouraging CGN use, that is outside the scope of this discussion. What we can do
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
everyone-- My position on this draft remains unchanged. It is far too forgiving of the 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] proposal, which I regard as abominable. That reason alone, in my judgment, is sufficient grounds that it should not be published. I also share the concerns of most of the opponents of this draft. My recommendation regarding this draft, to the people inside Apple who implement customer-edge router functions, is to ignore it. It is too late to add the shared transition space to the list of special-use addresses excluded from use as 6to4 tunnel endpoints in all the units already deployed in the field. Such a disruption to existing customer configurations is generally unacceptable behavior for software updates. Also, while it might seem reasonable to add the new space to the list of special-use addresses only in *forthcoming* products that support a 6to4 tunnel router feature, that too is unlikely ever to happen. (Note well: we don't comment publicly about the features of unreleased products.) Shorter james: this draft is a bad idea; please don't publish it. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Feb 16, 2012, at 8:58 AM, Nick Hilliard wrote: The bottom line for this ID is that address space will be required for CGN, and rfc1918 doesn't cut it for reasons described in the ID. This means that the address space must come from somewhere else. The choices are: 1. one or more shared pools allocated by RIRs/IANA/whatever 2. private pools, each of which come from the carriers' own address blocks 3. private pools, independently chosen by ISPs using some method from allocated space (aka squat space). option #1 is by definition more efficient than #2. and option #1 is safer than option #3. There is no particular reason to allocate this space on a regional basis, I'd say it would be silly to do so -- what would be the point? Incidentally, I support this draft. One implication of draft-weil not being accepted is that it will likely accelerate IPv4 free pool exhaustion as the folks interested in draft-weil will simply go out and get blocks from their RIRs while they still can. I will admit a small part of me finds this appealing as it would end the seemingly interminable rearrangement of deck chairs on the IPv4 address policy-wonk Titanic. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 16/02/2012 19:42, David Conrad wrote: One implication of draft-weil not being accepted is that it will likely accelerate IPv4 free pool exhaustion as the folks interested in draft-weil will simply go out and get blocks from their RIRs while they still can. I will admit a small part of me finds this appealing as it would end the seemingly interminable rearrangement of deck chairs on the IPv4 address policy-wonk Titanic. This deck-chair rearrangement stuff is as predictable as it is pointless. The only good point about the ID is that at least it puts most carriers on the same footing and gives them some level of ability to continue to support their customers' ipv4 connectivity requirements. In its absence, a lot of providers will end up using even worse alternatives. Nick ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP'
I fully support this draft and would like to see it progress to conclusion without further delay. With warm regard, Kirk Erichsen Principle Technology Engineer Time Warner Cable ATG West This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I'm agnostic about the latest round of changes or not. I just want EITHER version to move forward soon! Owen On Feb 14, 2012, at 10:38 AM, Pete Resnick wrote: To the addressed folks who's messages appear below: I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. pr On 2/14/12 8:54 AM, Donald Eastlake wrote: I also support this draft. On 2/14/12 9:06 AM, ned+i...@mauve.mrochek.com wrote: On Tuesday, February 14, 2012, Daryl Tanner daryl.tan...@blueyonder.co.uk wrote: I support this updated draft, and I am keen for this to be published as a BCP. +1 I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. +1 On 2/14/12 10:19 AM, jeff.finkelst...@cox.com wrote: I support this draft as updated. On 2/13/12 1:05 PM, Owen DeLong wrote: I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. On 2/14/12 12:25 PM, Ross Callon wrote: +1 -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Sorry Noel but I choice to reply public to this one. On Mon, Feb 13, 2012 at 10:52 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: IPv6 is The Key! If you think denying a CGN block will do anything at all to help IPv6, you're very confused. quote out of context etc... but my change of mind from supporting this draft to not supporting has nothing todo with IPv6 at all. Nothing. It all boils down to RFC1918 space, there are 3 huge network blocks there and double, tripple NAT work, just as well as CGN will (it will break plenty of application either way). * 10.0.0.0/8 ~16mill addresses * 172.16.0.0/12 ~1mill addresses * 192.168.0.0/16 ~65K addresses I can't really see what difference another /10 will make really, especially now that we're in essence out of IPv4 addresses. We're all much better of with some pain (address collision etc) during the transition to IPv6 than to delay it even more. And about your quote, yes we have to change to IPv6, there are at currently no other options at all. Sure there are plenty of not optimal design choice made, stupid things (like we're wasting /64 due to EUI-64) etc etc, but that is an entire other range of subject. Right now, we only have one real choice, move to IPv6. Everything else is moving the pain around. and for those that really really really want to continue to use IPv4, well try to make 240/4 (E-class) usable... there you have an entire /4 instead of /10. 240.0.0.0/4 Reserved for Future Use[RFC1700, page 4] I personally think that reservation should have been lifted years ago. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Tue, Feb 14, 2012 at 5:51 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Brian E Carpenter wrote: Sure, that's very common, but these devices are consumer electronics and will get gradually replaced by IPv6-supporting boxes as time goes on. The problem is that IPv6 specification is still broken in several ways to be not operational that existing boxes must be replaced after the specification is fixed. The more serious problem is that IPv6 people in IETF do not admit IPv6 broken, which makes it impossible to fix IPv6. Make a draft, gather your supporters and take that discussion on 6man wg. I'm sure there are people open to consider any arguments on what's wrong/or not. Either way, we're way passed changing any of the important parts of IPv6. That has to be IPv6 v2 WITH backward compability to IPv6 (as we currently know it). -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
The more serious problem is that IPv6 people in IETF do not admit IPv6 broken, which makes it impossible to fix IPv6. Make a draft, gather your supporters and take that discussion on 6man wg. I'm sure there are people open to consider any arguments on what's wrong/or not. Now, I'm tired of speaking with those who decided that IPv6 must be perfect. They have been warned about 10 years ago. Nowadays, I'm telling operators how IPv6 is broken to be not operational. Either way, we're way passed changing any of the important parts of IPv6. That has to be IPv6 v2 WITH backward compability to IPv6 (as we currently know it). A problem, maybe the worst operationally, of IPv6 is that IPv6 address is 16B, divine to remember, because of failed attempt to have SLAAC. As most operators are human, forget backward compatibility. It is a lot easier for all the players to make IPv4 with NAT end to end transparent. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Roger Jorgensen rog...@gmail.com Sorry Noel but I choice to reply public to this one. Ah, no, actually. Had you thought about it for a moment or two, you could have realized that you could have made your point just as well without publicly quoting my private email. But why am I not surprised? It all boils down to RFC1918 space, there are 3 huge network blocks there ... I can't really see what difference another /10 will make really, especially now that we're in essence out of IPv4 addresses. The issue is not whether it _can_ be made to work (in Milo's famous phrase, 'with enough thrust, anything will fly'). The issue is all about costs and benefits. Speaking of the costs, if we assign a block of size N, it's not as if N people are not going to be able to get on the network as a result. To the contrary, N*M people are going to be able to get on the network as a result. Of course, the N would have had globally visible addresses, whereas the N*M will not, but that dropoff in functionality does not seem to bother most people: pretty much every wireless hub I've ever seen is also a NAT box. (I'm not even sure if there's even a way to turn off the NAT functionality in the one in our house - I don't recall one.) Given that most people are happy to take the choice 'limited access is preferable to no access' in the wireless case, I see no reason to doubt that they would, were they able to explicitly make the choice, make the same choice here. Allowing more people access to the Internet is a problem... how? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I also support this draft. Donald On Tuesday, February 14, 2012, Daryl Tanner daryl.tan...@blueyonder.co.uk wrote: I support this updated draft, and I am keen for this to be published as a BCP. I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. Daryl -- Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I support this updated draft, and I am keen for this to be published as a BCP. +1 I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I support this draft as updated. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
+1, I support this draft… Bill Check On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote: http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14 +1 I support this draft! Best Regards, Hans -- Hans Thienpondt Technology Engineer Converged Network Engineering Telenet NV Liersesteenweg 4 - box 52 T: +32 15 33 30 24 2800 Mechelen - Belgium * Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes eventuelles peuvent contenir des informations confidentielles et/ou protegees par des droits de propriete intellectuelle. Ce message est adresse exclusivement e son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complete sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez recu ce message par erreur, veuillez prevenir l'expediteur du message et en detruire le contenu. * ___ 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Apologies for top posting rather than addressing specific commentators, but there have been several misconceptions raised several times that I felt should be addressed generically: 1) We are out of IPv4 space / There's no-where to get this /10 - There is already a /10 reserved by the ARIN community for this purpose (as long as we don't drag our feet too long), please see: https://www.arin.net/policy/proposals/2011_5.html 2) Just use 1918 space - I apologize for not having more data to share, but I can tell you that I have spoken with numerous network operators and NONE of them are willing to do this. ISPs will NOT use RFC 1918 space, no matter how many times folks scream it from the tops of ivory towers. Operational realities must sometimes trump ideals. 3) CGN is bad - This one is accurate. It has no bearing on this I-D whatsoever though. Yes, CGN sucks and we want as few networks to use it as possible. But, no matter what we do, some will have to deploy it. This I-D is about helping reduce everyone's pain when they do. Leaking squat space hurts more than just the one who leaks it... 4) IPv6 is awesome - Again, accurate but inconsequential here. IPv6 does not solve IPv4 connectivity issues. Operators are not solely responsible for the lack of IPv6 penetration. Rather than throw stones from our glass houses, we should focus on ensuring that the transition can happen without shattering all of them. I understand that many have strong emotional ties to their opinions. My only hope is to point those with open minds in the right direction as they seek to understand this issue more fully. Cheers, ~Chris (speaking for myself, from an ivory tower made of glass) On Mon, Jan 30, 2012 at 16:03, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Reserved IPv4 Prefix for Shared CGN Space' draft-weil-shared-transition-space-request-14.txt as a BCP On its December 15, 2011 telechat, the IESG reviewed version 10 of this document and requested various changes. These changes are reflected in the draft version 14 and the IESG now solicits community input on the changed text only. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier Grade Network Address Translation (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premise Equipment (CPE). Shared Address Space is distinct from RFC1918 private address space because it is intended for use on Service Provider networks. However, it may be used as RFC 1918 private address space in certain circumstances. Details are provided in the text of this document. As this document proposes the allocation of an additional special-use IPv4 address block, it updates RFC 5735. The following text captures the most salient change between version 10 and 14 of this document: Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional [RFC1918] space when at least one of the following conditions is true: o Shared Address Space is not also used on the Service Provider side of the CPE. o CPE routers behave correctly when using the same address block on both the internal and external interfaces. The file can be obtained via http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
To the addressed folks who's messages appear below: I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. pr On 2/14/12 8:54 AM, Donald Eastlake wrote: I also support this draft. On 2/14/12 9:06 AM, ned+i...@mauve.mrochek.com wrote: On Tuesday, February 14, 2012, Daryl Tannerdaryl.tan...@blueyonder.co.uk mailto:daryl.tan...@blueyonder.co.uk wrote: I support this updated draft, and I am keen for this to be published as a BCP. +1 I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. +1 On 2/14/12 10:19 AM, jeff.finkelst...@cox.com wrote: I support this draft as updated. On 2/13/12 1:05 PM, Owen DeLong wrote: I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. On 2/14/12 12:25 PM, Ross Callon wrote: +1 -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
To the addressed folks who's messages appear below: I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. Not sure how a +1 to a statement saying I support this updated draft, and I am keen for this to be published as a BCP. can be interpreted in any but one way, or for that matter how it can be stated much differently. Anyway, to use different words, I would like to see the current draft approved and published as a BCP. Clear enough? Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Pete Resnick wrote: I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. On the first hand, I do support draft-weil. I think I understand the use cases enough to see that it *is* required, especially for large MSO's, and potentially larger enterprises. On the other hand, I can see the confusion regarding using RFC-1918 space *for this purpose* vs use this space as *additional RFC-1918*. The former just doesn't work due to unmanaged overlap. The latter *seems* like it should work, but if you play it out until the first vendor starts releasing equipment that uses it, you've now joined the first-case scenerio. On the gripping hand, I hate the back-and-forth quibbling over the tiniest motes, hoping that the delays will just make the problem disappear... So yes, lets please move this draft forward, with the text cleaning stating that it NOT be used as RFC-1918 space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote: Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. Not sure how a +1 to a statement saying I support this updated draft, and I am keen for this to be published as a BCP. can be interpreted in any but one way, or for that matter how it can be stated much differently. Anyway, to use different words, I would like to see the current draft approved and published as a BCP. Clear enough? Nope. Perhaps my question was unclear. I'll try and ask my question again with different words: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? Nobody on the list objected to that new text. That new text significantly changes -14. You have stated your support for -14. Do you object to changing the text? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote: Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. Not sure how a +1 to a statement saying I support this updated draft, and I am keen for this to be published as a BCP. can be interpreted in any but one way, or for that matter how it can be stated much differently. Anyway, to use different words, I would like to see the current draft approved and published as a BCP. Clear enough? Nope. Perhaps my question was unclear. I'll try and ask my question again with different words: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? Nobody on the list objected to that new text. That new text significantly changes -14. You have stated your support for -14. Do you object to changing the text? I assumed the proposed change was in the current draft - isn't that how it's supposed to be done? Anyway, I think the change is fine, but I also think the draft is acceptable without it. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? what silliness. it will be used as rfc 1918 space no matter what the document says. nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. any thought that this is not just adding to rfc 1918 is pure bs. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Randy Bush writes: in response to Pete Resnick, who wrote: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? what silliness. it will be used as rfc 1918 space no matter what the document says. nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. any thought that this is not just adding to rfc 1918 is pure bs. In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2012-02-15 09:35, Randy Bush wrote: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? what silliness. it will be used as rfc 1918 space no matter what the document says. Of course it will. My suggestion was to change the text to is not intended to be used instead of can be used, hoping that would be viewed as a fair warning. http://www.ietf.org/mail-archive/web/ietf/current/msg71596.html Brian nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. any thought that this is not just adding to rfc 1918 is pure bs. randy ___ 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. and the packets will be very ashamed, right? we can say all the crap we want, but it will be used as 1918 space and, like 1918 space, bgp announcesments of it will leak. get over it. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Randy Bush writes: in response to me: In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. and the packets will be very ashamed, right? we can say all the crap we want, but it will be used as 1918 space and, like 1918 space, bgp announcesments of it will leak. get over it. And that's fine -- on a per-operator basis -- they chose their path. What we're trying to avoid by explicitly NOT marking this as RFC-1918 space is VENDORS using it inside their equipment, thereby negating the entire practical use of the space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/14/12 2:35 PM, Randy Bush wrote: what silliness. it will be used as rfc 1918 space no matter what the document says. [...] any thought that this is not just adding to rfc 1918 is pure bs. Of course it will be used as 1918 space. That's not the point of the text. The text is saying, You could read 1918 to say that we somehow promised that you would never be connected to a network run by someone other than yourself and see 1918 addresses on it. That's not an entirely intelligent reading, but we see how you can read it that way. So, if you built yourself a device where it isn't able to deal with 1918 addresses on its 'outside' interface that you were using on the 'inside' interfaces, we could see how that might happen. It was not at all smart of you to build your device that way, but you probably were technically within spec. Now we're adding some address space to the pool. It's not global and it's not routable, just the same as 1918 space. But we're letting you know right now: You *will* see these addresses on networks that you don't run. If you want to use this space the way that you used 1918 space, peachy, but understand that if you're unable to deal with these addresses duplicating ones you're using, your device is toast. Deal with it. Any thought that the text is saying something more than this is nonsense. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Randy Bush wrote: what silliness. it will be used as rfc 1918 space no matter what the document says. The difference is on how future conflicts can be resolved. nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. What if the military space is sold to public and announced? Who is forced to renumber and why? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 12-02-14 3:49 PM, Randy Bush ra...@psg.com wrote: In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. and the packets will be very ashamed, right? we can say all the crap we want, but it will be used as 1918 space and, like 1918 space, bgp announcesments of it will leak. get over it. Sure, but with a well known address range, it's not just what one AS leaks.. The other AS(s) can also block incoming. That's one of the benefits of a well known space for this. For squat, good luck figuring out who is using what from where. Victor K randy ___ 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Support Draft as written +1. Victor K On 12-02-14 12:38 PM, William Check bch...@ncta.com wrote: +1, I support this draft Bill Check On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote: http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14 +1 I support this draft! Best Regards, Hans -- Hans Thienpondt Technology Engineer Converged Network Engineering Telenet NV Liersesteenweg 4 - box 52 T: +32 15 33 30 24 2800 Mechelen - Belgium * Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes eventuelles peuvent contenir des informations confidentielles et/ou protegees par des droits de propriete intellectuelle. Ce message est adresse exclusivement e son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complete sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez recu ce message par erreur, veuillez prevenir l'expediteur du message et en detruire le contenu. * ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/14/2012 17:26, Pete Resnick wrote: Of course it will be used as 1918 space. That's not the point of the text. My first reply in this most recent version of the thread pointed out that now that we're finally willing to admit that if a new block is issued it will be used as 1918 space then that leads to the obvious conclusion that the *best* we can do with this draft is to kick the can down the road, which is not enough justification for actually doing the allocation. I'll resist the urge to repeat the other points that I've already repeated too often. :) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 10 Feb 2012, at 22:12, Chris Grundemann wrote: Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? I suggest the ISPs, they are charging for the service, right? My bet is that no one is willing to drop the billions of dollars required - Errors cost money. They decided not to invest in IPv6, now there is time to pay. if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) Cheers, ~Chris For many of the reasons stated before, I think this space is not needed and I am against this proposal. Regards, /as ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Arturo Servin arturo.ser...@gmail.com Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? I suggest the ISPs, they are charging for the service, right? Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our house, both our cable modem and the router attached to it are ours. (Not quite sure how CGN would work in such an ISP - I guess they'd assign the customer's IP address, on our side of the cable modem, out of the CGN block? 'traceroute' say our cable box has a 10. address on the far side, even now.) But, anyway, telling such ISPs 'go buy new CPE' just isn't an option. Errors cost money. They decided not to invest in IPv6, now there is time to pay. Again, it's made cystal clear that the real goal of the opponents here is to punish people for not adopting IPv6. Don't you think this casts IPv6 in a really bad light - that the only way to get people to adopt it is to force them into it, using whatever whips and chains are available? But I'll stop there, since we're not supposed to be getting de-railed into IPv6. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2012-02-14 05:51, Noel Chiappa wrote: From: Arturo Servin arturo.ser...@gmail.com Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? I suggest the ISPs, they are charging for the service, right? Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our house, both our cable modem and the router attached to it are ours. Sure, that's very common, but these devices are consumer electronics and will get gradually replaced by IPv6-supporting boxes as time goes on. (That is not hand-waving, the generation of boxes with IPv6 support is starting to appear.) Nobody, I think, is denying that there will be a long period of coexistence as a result. That is a separate question from this draft, which gives ISPs space for *growing* their IPv4 customer base. I think that is what upsets people. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/12/2012 13:34, Noel Chiappa wrote: From: Nilsson mansa...@besserwisser.org there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. On the contrary, denying this block is likely to _accelerate_ usage of what space remains, thereby penalizing the 'other users' whose interests you _claim_ to be protecting. If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. If the RIRs do not deny these requests there is likely to be a revolt. OTOH that may be a good thing As for your other 2 options: But it is. As I said before, the IETF has precisely two choices: - See CGN deployed using various hacks (e.g. squatting on space) Incredibly unlikely to happen. The ISPs are smart enough to know that this will cause them more headaches than its worth. - See CGN deployed using a block of space allocated for that purpose If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. Whatever customer support costs they have to bear for the small percentage of customers that actually manage to overlap will rightly be borne by the people who created their own problems. Everyone wins. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Doug Barton do...@dougbarton.us If the RIRs do not deny these requests there is likely to be a revolt. On what grounds? The ISPs will come along and say 'I have X new customers, please give me more space for them'. The former being true, on what ground can the RIRs refuse (modulo cases like RIPE)? If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. How? The IETF has neither police, nor an army. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Feb 13, 2012, at 12:34 PM, Doug Barton wrote: If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. If the RIRs do not deny these requests there is likely to be a revolt. OTOH that may be a good thing What grounds would an RIR have to deny this request? - See CGN deployed using various hacks (e.g. squatting on space) Incredibly unlikely to happen. The ISPs are smart enough to know that this will cause them more headaches than its worth. You're joking, right? - See CGN deployed using a block of space allocated for that purpose If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. No. ISPs will do what makes business sense for them. Some of these ISPs have already indicated that RFC 1918 won't work for them. As such, they'll take whatever steps they feel is in their best interests. Whether this is choosing some large block of (currently) unadvertised space or requesting a large block from their RIR (while they still can) is a decision they will make. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/13/2012 12:45, David Conrad wrote: On Feb 13, 2012, at 12:34 PM, Doug Barton wrote: If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. If the RIRs do not deny these requests there is likely to be a revolt. OTOH that may be a good thing What grounds would an RIR have to deny this request? I haven't kept up to date on all of the RIRs' policies for granting requests, but I don't recall seeing give me a huge block so that I can do CGN as one of the established criteria. - See CGN deployed using various hacks (e.g. squatting on space) Incredibly unlikely to happen. The ISPs are smart enough to know that this will cause them more headaches than its worth. You're joking, right? Ok, let's assume I'm wrong. Then there are 2 options: 1. They squat on space that causes them (and their customers) pain. I'm fine with that. Hopefully it will encourage their customers to move away, thus causing more pain for the ISP. 2. They squat on space that doesn't cause pain. I don't like that option, but it solves the problem, right? - See CGN deployed using a block of space allocated for that purpose If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. No. ISPs will do what makes business sense for them. Some of these ISPs have already indicated that RFC 1918 won't work for them. I've already covered all the reasons I don't buy this in detail. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 9:34 PM, Doug Barton do...@dougbarton.us wrote: On 02/12/2012 13:34, Noel Chiappa wrote: From: Nilsson mansa...@besserwisser.org there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. On the contrary, denying this block is likely to _accelerate_ usage of what space remains, thereby penalizing the 'other users' whose interests you _claim_ to be protecting. If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. If the RIRs do not deny these requests there is likely to be a revolt. OTOH that may be a good thing As for your other 2 options: But it is. As I said before, the IETF has precisely two choices: - See CGN deployed using various hacks (e.g. squatting on space) Incredibly unlikely to happen. The ISPs are smart enough to know that this will cause them more headaches than its worth. - See CGN deployed using a block of space allocated for that purpose If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. Whatever customer support costs they have to bear for the small percentage of customers that actually manage to overlap will rightly be borne by the people who created their own problems. Everyone wins. +1 :-) I did original think it was the lesser evil to support this draft, but I have now changed my mind. Plenty of arguments from so many on so many points that I can't really see any reason anymore to support it. So, no I don't support this draft. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Doug Barton do...@dougbarton.us I haven't kept up to date on all of the RIRs' policies for granting requests, but I don't recall seeing give me a huge block so that I can do CGN as one of the established criteria. An ISP needs a block of size X for CGN only if it has X customers, right? So they can legitimately go to an RIR and say I have X customers, please give me a block of size X. The fact that the block is not then advertized globally, but only used to number their CGN'd network, is neither here nor there. Needless to say, if multiple ISPs do this, it will use _more_ address space than simply giving them all a CGN block to share. (Unless that's the _actual_ goal in opposing this, of course.) I've already covered all the reasons I don't buy this in detail. I can repeat 2+2=5 as many times as I like, but that won't make it true. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 03:42:58PM -0500, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us If the RIRs do not deny these requests there is likely to be a revolt. On what grounds? The ISPs will come along and say 'I have X new customers, please give me more space for them'. The former being true, on what ground can the RIRs refuse (modulo cases like RIPE)? RIPE NCC is not unique; IIRC there has been extensive synchronisation between RIRen on the subject of sunset allocations. I'd expect any RIR to more or less laugh at the request of a /10 (the size of network we've been told (without any proof beyond handwaving) is required to do CGN nicely) at this stage of address depletion. APNIC: As of Friday, 15 April 2011, each new or existing APNIC account holder is only eligible to request and receive delegations totalling a maximum /22 worth of address space from the APNIC IPv4 address pool. ARIN: Has 3-month consumption cap on allocations. Apparently not so low on space as the others. LACNIC: Has a /22 cap per LIR en route in its PDP. RIPE: Has a /22 rule, as discussed earlier. AFRINIC: I can't at the moment locate their policy, more than that they have incorporated the last five /8's document as governing text in their policy set. Pointers to text welcome. To sum things up, we are at the stage where a /10 is a laughable proposition. The largest usable block (bar squatting on DOD space) for CGN is 10/8. I'd suggest planning for it. That last /22 will probably end up as P router addresses in MPLS core, since all vendors have dragged their feet in implementing v6 MPLS. If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. How? The IETF has neither police, nor an army. It is either 10/8 or squat. No other alternatives exist. I'd expect squatting on the wrong /8 to be punishable as a Homeland Security Department -related crime, if one takes the US-centric view. Folks, we've run out. -- Måns. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Hi Noel, At 12:42 13-02-2012, Noel Chiappa wrote: On what grounds? The ISPs will come along and say 'I have X new customers, please give me more space for them'. The former being true, on what ground can the RIRs refuse (modulo cases like RIPE)? If you have X new customers and you ask a RIR to give you more IPv4 space, I doubt that you would get more space as the evaluation might require more information ( e.g. http://www.ripe.net/lir-services/resource-management/contact/ipv4-evaluation-procedures ). Here's a comparison of RIR policies. Please refer to the document from each RIR for authoritative information. RIR Period (months) AfriNIC12 Minimum /22, no maximum Demonstrate 80% efficient utilization of last allocated space or an immediate need that requires more IP addresses than are available in the most recent allocation. APNIC 12 Minimum /24, up to a maximum /22 of the remaining available space after 15 April 2011. Demonstrate 80% efficient utilization of all prior allocated space. ARIN3 Minimum /22 for multihomed, otherwise /20, no maximum. Demonstrate efficient utilization of all previous allocations and at least 80% of the most recent allocation. LACNIC 12 The policy for determining the size of additional allocations is based on the efficient utilization of space within a time frame of 12 months. Demonstrate 80% efficient utilization of all prior allocated space. The applicant must already have at least one IPv6 block assigned by LACNIC or, if not, must simultaneously request an initial IPv6 block in accordance with the corresponding applicable policy. If an applicant has already been assigned an IPv6 block, they shall submit to LACNIC a brief document describing their progress in the implementation of IPv6. RIPE Minimum /21, no maximum. Demonstrate approximately 80% efficient utilization of all prior allocated space. Until 1 July 2010, up to 12 months. Between 1 July 2010 31 December 2010, up to nine months Between 1 January 2011- 31 June 2011, up to six months As of 1 July 2011, up to three months According to the above, you can still get an allocation of IPv4 addresses. The amount depends on the regional policy. Whether a /10 allocation is possible from the above is an exercise left to the reader. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/13/2012 13:46, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us I haven't kept up to date on all of the RIRs' policies for granting requests, but I don't recall seeing give me a huge block so that I can do CGN as one of the established criteria. An ISP needs a block of size X for CGN only if it has X customers, right? So they can legitimately go to an RIR and say I have X customers, please give me a block of size X. The fact that the block is not then advertized globally, but only used to number their CGN'd network, is neither here nor there. If they have a legitimate need for more customers - more space I have no problem with that. If they lie on their application about what they are using it for ... Needless to say, if multiple ISPs do this, it will use _more_ address space than simply giving them all a CGN block to share. (Unless that's the _actual_ goal in opposing this, of course.) Um, no. I'm not trying to accelerate IPv4 runout. I get that it's an important problem, and I've been working on solutions for it for many years. But that doesn't mean I buy the arguments that have been put forward so far about why this new block is necessary either. I've already covered all the reasons I don't buy this in detail. I can repeat 2+2=5 as many times as I like, but that won't make it true. 2+2!=5 is a fact. What you and I are talking about are opinions. I happen to think that my opinions are better grounded in facts and knowledge about the topic than yours are, but at the end of the day we could both be wrong about what actually does or doesn't happen. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Mans, On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote: To sum things up, we are at the stage where a /10 is a laughable proposition. Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs can confirm. It is either 10/8 or squat. No other alternatives exist. I'd expect squatting on the wrong /8 to be punishable as a Homeland Security Department -related crime, if one takes the US-centric view. I doubt this, particularly since the use of the addresses we're talking about is entirely internal. Folks, we've run out. I'm not dead yet! (to misquote Monty Python) Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 02:36:34PM -0800, David Conrad wrote: Mans, On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote: To sum things up, we are at the stage where a /10 is a laughable proposition. Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs can confirm. Reading from policy texts, it is. What is stuffed away in the RIR dungeons might technically support such an allocation, of course. For some time still. It is either 10/8 or squat. No other alternatives exist. I'd expect squatting on the wrong /8 to be punishable as a Homeland Security Department -related crime, if one takes the US-centric view. I doubt this, particularly since the use of the addresses we're talking about is entirely internal. Internal schmernal. Stuff leaks. Either by people watching allocations and going Hey or by routing slip Hey, this block ain't 1918, let's route it Folks, we've run out. I'm not dead yet! (to misquote Monty Python) The rumours are persistent, though. -- Måns. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Brian E Carpenter wrote: Sure, that's very common, but these devices are consumer electronics and will get gradually replaced by IPv6-supporting boxes as time goes on. The problem is that IPv6 specification is still broken in several ways to be not operational that existing boxes must be replaced after the specification is fixed. The more serious problem is that IPv6 people in IETF do not admit IPv6 broken, which makes it impossible to fix IPv6. For an example, see my recent presentation at APOPS: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
At 08:02 11-02-2012, Noel Chiappa wrote: In reality, the _only_ choice the IETF has is between: - Deploy CGNAT with messy ad-hoc assigned addresses (squatting, whatever) - Deploy CGNAT with an assigned address block There is an IPR disclosure on file for RFC 6264 (Informative reference). There is an IPR disclosure which may be related to one of the services mentioned in Section 5.2 of the draft. draft-ietf-behave-lsn-requirements-05 discusses about common requirements for Carrier Grade NATs. An IPR disclosure was filed. The IPv4 address pool status is as follows: IPv4 /8 RIR Pool 18 Reserved (IETF) 35 Unadvertised 53 Advertised 149 Research carried out in 2008 listed unofficial use of the following (IPv4) /8s: 1, 2, 5, 14, 23, 39, 42, 100, 101, 107, 175 and 176 All those IPv4 /8s are currently allocated to RIRs. Is an IPv4 address block assignment necessary for draft-ietf-behave-lsn-requirements-05? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sat, Feb 11, 2012 at 08:39:03PM -0500, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us We already have a way to make collisions very unlikely, don't use either of 192.168.[01]. I gather that that's not desirable, because otherwise people wouldn't be asking for another block. Of course it could probably be made to work somehow - with enough thrust, etc, etc. But that's not the point - engineering is (or ought to be) all about balancing costs and benefits. Close. The cost to these late adapters without sensible business plans will be higher if they aren't given this allocation. Truth is, that the same problem they are facing has been dealt with in corporate networks for at least 14 years -- I do remember being the victim of a RFC1918 address plan with double NAT for private inter-company links in 1998. The problem is known, solutions exist, and these people have no place requesting a critically scarce resource just to buy themselves fewer customer support calls. Fewer customer support calls one gets by building a better network, not by crying to get community pity. If the people involved were asking for something incredibly painful/expensive in order to make their lives easier, the answer would rightly be 'no'. The cost would far outweigh the benefit. But they're not. All they're asking for is a modest chunk of address space, and the cost of doing that is not significant - we allocate chunks of space _all the time_. Soon, all the time won't be. The IANA has no way of allocating this -- they've run out. Which RIR is going to part with a /10 then? APNIC has run out. The rest of the RIRen are, IIRC, operating in sunset mode, where allocations are _very_ restricted. That is why address space should not be allocated. Because there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. And to top that off, they are too cheap to do the homework of proving their precarious situation. They just state their need and expect us to accept it and codify it in RFC format. But it is. As I said before, the IETF has precisely two choices: - See CGN deployed using various hacks (e.g. squatting on space) - See CGN deployed using a block of space allocated for that purpose Allocate, or don't allocate. That's the only choice. This sounds like a bullying ultimatum. We are not there yet, the alley is wider, and U-turns are possible. The choice is and was between do CGN using RFC1918 and build a network that takes advantage of the latest 15 years of developement in networking. One can argue whether there is significant short-term gains for a commercial entity in doing the right thing as opposed to just cutting corners. And, I firmly believe that any SDO not in touch with reality is bordering on silly. But there is a definite difference between being a tool for the shortsighted on the one hand and crafting good solutions to technical problems on the other. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
In message 20120212204623.gl27...@besserwisser.org, =?iso-8859-1?Q?M=E5ns?= N ilsson writes: On Sat, Feb 11, 2012 at 08:39:03PM -0500, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us = We already have a way to make collisions very unlikely, don't use either of 192.168.[01]. = = I gather that that's not desirable, because otherwise people wouldn't be asking for another block. Of course it could probably be made to work somehow - with enough thrust, etc, etc. But that's not the point - engine= ering is (or ought to be) all about balancing costs and benefits. Close. The cost to these late adapters without sensible business plans will be higher if they aren't given this allocation. How is this a late adapter problem? You either have enough addresses to give every customer a IPv4 address or you don't. If you don't have enough addresses you are going to have to use some sort of CGN whether that is NAT444 or AFTR or some other transition technology which shares IPv4 addresses. Isn't the IETF's preferred transition strategy still dual stack or are you thinking that ISP's that can't get enough IPv4 address have to go IPv6 only? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Nilsson mansa...@besserwisser.org there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. On the contrary, denying this block is likely to _accelerate_ usage of what space remains, thereby penalizing the 'other users' whose interests you _claim_ to be protecting. If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. Again, denying this block is just an attempt to punish ISPs who aren't doing what you want - nothing else. There is _no_ good engineering reason to deny this request. Allocate, or don't allocate. That's the only choice. This sounds like a bullying ultimatum. Not intended to be; I am not a provider, and have no connection to any provider. This is just my take on what the reality of the situation is. The choice is and was between do CGN using RFC1918 and build a network that takes advantage of the latest 15 years of developement in networking. Don't you think any network that was going to do the second would have already decided that? The ones who are going to do CGN are going to do CGN - the only question is what block of address space they are going to use. Denying them a block is not going to stop CGN. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Mark Andrews writes: In message 20120212204623.gl27...@besserwisser.org, =?iso-8859-1?Q?M=E5ns?= N ilsson writes: On Sat, Feb 11, 2012 at 08:39:03PM -0500, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us We already have a way to make collisions very unlikely, don't use either of 192.168.[01]. = I gather that that's not desirable, because otherwise people wouldn't be asking for another block. Of course it could probably be made to work somehow - with enough thrust, etc, etc. But that's not the point - engine = ering is (or ought to be) all about balancing costs and benefits. Close. The cost to these late adapters without sensible business plans will be higher if they aren't given this allocation. How is this a late adapter problem? You either have enough addresses to give every customer a IPv4 address or you don't. If you don't have enough addresses you are going to have to use some sort of CGN whether that is NAT444 or AFTR or some other transition technology which shares IPv4 addresses. And if you restrict it to those that do IPv4 literals there isn't much other than NAT444 and AFTR and how many cpe's support B4 at this point? Isn't the IETF's preferred transition strategy still dual stack or are you thinking that ISP's that can't get enough IPv4 address have to go IPv6 only? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sun, Feb 12, 2012 at 04:34:40PM -0500, Noel Chiappa wrote: From: Nilsson mansa...@besserwisser.org there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. On the contrary, denying this block is likely to _accelerate_ usage of what space remains, thereby penalizing the 'other users' whose interests you _claim_ to be protecting. What happened to - See CGN deployed using various hacks (e.g. squatting on space) - See CGN deployed using a block of space allocated for that purpose ...that were the ONLY two choices we have? Suddenly, you introduce a third. Maybe there is more to this... If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. Not any more. Let me quote from RIPE-530, the in-force allocation policy document for RIPE NCC: Allocations for LIRs from the last /8 On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be exactly one /22. LIRs receive only one /22, even if their needs justify a larger allocation. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. RIPE-530, section 5.6 (as copied from http://www.ripe.net/ripe/docs/ripe-530) Again, denying this block is just an attempt to punish ISPs who aren't doing what you want - nothing else. There is _no_ good engineering reason to deny this request. How about there are no addresses left? Allocate, or don't allocate. That's the only choice. This sounds like a bullying ultimatum. Not intended to be; I am not a provider, and have no connection to any provider. This is just my take on what the reality of the situation is. The choice is and was between do CGN using RFC1918 and build a network that takes advantage of the latest 15 years of developement in networking. Don't you think any network that was going to do the second would have already decided that? The ones who are going to do CGN are going to do CGN - the only question is what block of address space they are going to use. Denying them a block is not going to stop CGN. ...which means that the allocation is unecessary ;-) Seriously, Doug Barton pointed out (and I agree) that 99% of the issues with RFC1918 space usage in CGN will be dealt with by using a suitably obscure part of 10/8 or simply 172.16/12. FWIW, most of Asia has been running with layers of NAT for years. Using 1918. Which stinks. That is why we have IPv6. I fully appreciate the need for some legacy connectivity; even though this email conversation is made (from my point of view) fully using IPv6, there are lots of other things needing v4. Running v4 services in NAT and dual-stacking with global scope v6 will give a good incitament to migrate important and E2E-sensitive applications to v6, while preserving some kind of pseudo-reachability for v4 services. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Nilsson mansa...@besserwisser.org denying this block is likely to _accelerate_ usage of what space remains What happened to - See CGN deployed using various hacks (e.g. squatting on space) - See CGN deployed using a block of space allocated for that purpose ...that were the ONLY two choices we have? Suddenly, you introduce a third. No. 'Everyone allocating their own CGN block' falls under various hacks (i.e. option i). Let me quote from RIPE-530, the in-force allocation policy document for RIPE NCC Well, I guess European ISPs are going to be forced to squat, then (there are a number of non-backbone-routed /8s allocated to things like intelligence agencies, which are unlikely to appear on the backbone) - unless we can get a common CGN block allocated from elsewhere. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 10:13:25PM -0500, Noel Chiappa wrote: I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. If you have any good technical reasons for finding this a bad idea _other_ than the supposed negative effects on IPv6 deployment, it would be useful to hear them. Are there any? There is no case for it. Any space so allocated will, by tearing down the last community restrains on address reuse, become an extension to RFC1918. There are legitimate uses for unique v4 space as documented in RIR policy and v4 sunset procedures. Let the /10 go there instead. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote: This is only about allocating a chunk of address space. For which there is better use than prolonging bad technical solutions. Address translation has set the state of consumer computing back severely. It might be all nice and proper according to those who desire to keep the power of owning a TV transmitter, a printing press or a transaction broker service. Do keep in mind that the real driver in IP technology is the ability for end-nodes to communicate in a manner they chose without prior coordination with some kind of protocol gateway. NAT and more so CGN explicitly disables this key feature. And this is not what the IETF should be doing. The IETF should seek to maximise the technical capabilities of the Internet protocol suite so that it may continue to enable new uses of the key feature, ie. end-node reachability. Allocating CGN-blessing address space is a clear violation of this. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sat, Feb 11, 2012 at 9:32 AM, Måns Nilsson mansa...@besserwisser.org wrote: On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote: This is only about allocating a chunk of address space. For which there is better use than prolonging bad technical solutions. Address translation has set the state of consumer computing back severely. It might be all nice and proper according to those who desire to keep the power of owning a TV transmitter, a printing press or a transaction broker service. Do keep in mind that the real driver in IP technology is the ability for end-nodes to communicate in a manner they chose without prior coordination with some kind of protocol gateway. NAT and more so CGN explicitly disables this key feature. And this is not what the IETF should be doing. The IETF should seek to maximise the technical capabilities of the Internet protocol suite so that it may continue to enable new uses of the key feature, ie. end-node reachability. Allocating CGN-blessing address space is a clear violation of this. Is that true? And if so, why and how can it be formulated or find support it earlier work? And if it is not true. Why and where do you find support for that view? I ask because you might touch something quite fundamental there... can IETF support something that will break/limit reachability on Internet. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sat, Feb 11, 2012 at 12:31:22PM +0100, Roger Jørgensen wrote: On Sat, Feb 11, 2012 at 9:32 AM, Måns Nilsson mansa...@besserwisser.org wrote: On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote: This is only about allocating a chunk of address space. For which there is better use than prolonging bad technical solutions. Address translation has set the state of consumer computing back severely. It might be all nice and proper according to those who desire to keep the power of owning a TV transmitter, a printing press or a transaction broker service. Do keep in mind that the real driver in IP technology is the ability for end-nodes to communicate in a manner they chose without prior coordination with some kind of protocol gateway. NAT and more so CGN explicitly disables this key feature. And this is not what the IETF should be doing. The IETF should seek to maximise the technical capabilities of the Internet protocol suite so that it may continue to enable new uses of the key feature, ie. end-node reachability. Allocating CGN-blessing address space is a clear violation of this. Is that true? And if so, why and how can it be formulated or find support it earlier work? And if it is not true. Why and where do you find support for that view? I ask because you might touch something quite fundamental there... can IETF support something that will break/limit reachability on Internet. IMNSHO, the answer should only be NO to that question. Where can I search support for this view? I believe, for starters, that: a/ The original IPv4 Internet was designed with a flat reachability model, as seen from the host IP-stack. (routers are a different thing, but indeed the flatness repeats itself, technically, in the DFZ.) b/ When the Internet faced an address shortage there were two solutions put forward; one being CIDR and the other being IPv6 (nee IPng, IIRC). While it is true that there was work codified in RFC 1631 etc that makes the IETF one of the culprits behind NAT, it is also written that The short-term solution is CIDR (Classless InterDomain Routing) [2]. The long-term solutions consist of various proposals for new internet protocols with larger addresses. Until the long-term solutions are ready an easy way to hold down the demand for IP addresses is through address reuse. This solution has the disadvantage of taking away the end-to-end significance of an IP address, and making up for it with increased state in the network. (RFC 1631, p1) We here clearly see that the authors tasked with describing address translation were fully aware that they were breaking E2E, and that they saw address translation as an intermediate measure to be retired as soon as suitable long-term measures were available. Reading further in the sequence of IETF documents describing NAT, we discover something of a more defaitist position in 3022. The discussion on disadvantages is still there, but there is less talk of replacing NAT with v6. Apparently the massive success of broadband routers was showing. So. With this little historical research made, I think that we can see a couple of things: 1. The IETF knew the drawbacks. 2. NAT was only a desperate measure. 3. NAT was to be retired when IPv6 was ready. 4. The IETF failed to predict the massive market penetration of broadband routers and similar solutions. The key question then becomes, are the market lemmings throwing themselves over the NAT cliff reason enough to give up sound engineering principles? I think that numbering critical devices in a sunset phase (where IPv4 is, resource-wise) uniquely is a more prudent use for address space than giving it away to people who've made bad business decisions (which doing any network business without v6 firmly on the 1-year roadmap is, post say 2006). Especially since it will be used to keep running a system that the IETF has known for 18 years to be severely deficient. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
--On Saturday, February 11, 2012 11:00 -0200 Arturo Servin arturo.ser...@gmail.com wrote: On 10 Feb 2012, at 22:12, Chris Grundemann wrote: Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? I suggest the ISPs, they are charging for the service, right? One additional observation about this particular line of argument. It seems to me that, to the extent to which this allocation idea is part of a legitimate IPv6 transition strategy, we should be listening carefully and with sympathy. We can still debate whether it is the best strategy, whether there are better ways to do the same thing, etc., but I hope there is no one who will argue against having strategies for moving forward other than hoping that the world ends before the last IPv4 allocation is given out by the RIRs. But, as soon as one suggests that the alternative to this space request is volunteering to buy everyone on earth a new CPE, we aren't talking about transition strategies any more. If we assume that end system networks will eventually either be running IPv6 or that the IPv6-IPv4 transition will occur at those boundaries, then that CPE equipment will need to be replaced because most of it doesn't support IPv6. I suppose an ISP could be stupid enough to buy CPE now that supports same address range inside and outside but does not support IPv6, but such an ISP would be much too stupid to survive (with or without help from us). So the CPE will need to be upgraded. There are potentially interesting economic discussions about capitalization, amortization, and deployment rates, but let's not pretend that this allocation for CGN use is the alternate to replacing CPE -- unless it is really a plan for IPv4 Forever based on layers and layers of address translation (and this is where I incorporate my snarky comment about X.75 gateways by reference -- a comment, I'm pleased to report, a few people have responded to with tales of painful experiences in past lives). ... if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) So, Chris, if you expect this allocation will avoid the costs of signing everyone up for IPv6-capable CPE, what is your transition plan? Or are you advocating an IPv4-forever model? If the latter, can you explain succinctly to the rest of us how you expect it to work? best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Nilsson mansa...@besserwisser.org Address translation has set the state of consumer computing back severely. We basically all know that. I myself am not happy with NAT either - in fact, back in 1992 (!!) I myself wrote what was perhaps the first problems with NAT document. So? Allocating CGN-blessing address space is a clear violation of this. You seem to be operating under the illusion that the IETF has the power to actually do something about NAT, and more particularly, CGNAT. This is not correct. No action by the IETF will have the slightest affect on the deployment of CGNAT (and probably the amount of CGNAT deployment). The notion that 'IETF blessing' will make any _real_ difference at all is complete wrong. The IETF's blessing (or failure to do so), and an appropriate amount of local currency, will get you a cup of coffee, as they say... In reality, the _only_ choice the IETF has is between: - Deploy CGNAT with messy ad-hoc assigned addresses (squatting, whatever) - Deploy CGNAT with an assigned address block Given those two choices, I pick the second. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Feb 11, 2012, at 12:27 AM 2/11/12, Doug Barton wrote:
On 02/10/2012 20:44, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
counter-arguments {A, B, C}, and since you have no other
counter-arguments, I win.'
Just because you don't think much of it, doesn't mean the rest of us have
to agree with you on that.
I understand that. Do you understand that I understand what you're
saying, and I don't agree with you?
The new block's purpose is to make collisions impossible.
Ah, no.
If you were to say 'to make collisions very unlikely if it is used in the
way it is specified', then I could agree with that.
Ok, let's go with that. We already have a way to make collisions very
unlikely, don't use either of 192.168.[01]. Fortunately this method
doesn't require allocation of a new block.
But, what we've been told by operators in the discussion about this draft is
that very unlikely is not sufficiently unlikely, and that no /10 within the
set of RFC 1918 addresses makes the probability of a collision sufficiently
unlikely. You may disagree with that claim, but I think we have to respect it.
So now what we're talking about is how much we're willing to pay to make
the collisions how much more unlikely?
I would certainly feel more comfortable with better data, but it seems highly
unlikely that we can generate it.
- Ralph
But to take a
straw-man absolutist position like impossible, and then knock it down
with great pomp:
It cannot fulfill that purpose.
I was using shorthand (or argumentum ad absurdum if you prefer) to point
out that given the fact that this new block can't fix the whole problem,
and also given the fact that there are already solutions available that
fix most of the problem for free, allocating the new block is a bad idea.
it's a very irresponsible way for an SDO to conduct themselves.
What, to say 'if you use this in a way that we specifically direct it not
be used, any problems are your fault'?
Again, you snipped the bit where I answered this. Go back and re-read my
previous post if you're confused.
And that's assuming that this action doesn't have a cost, whereas
the truth is that it has several, both direct and indirect.
And that would be...? How exactly does simply allocating a chunk of
address space - something the Internet engineering community does every
day - for a specific purpose have a cost ... both direct and indirect?
Again, I'm really trying not to dive back into the should we question,
but just as an example, there are 4,096 /22s in a /10. That's 4k new
SMBs that cannot get IPv4 space if this block is allocated.
If you want more, go look at the archives.
If you're actually thinking of 'deploying CGNAT' in the text above, this
discussion is not about that. That's going to happen no matter what the
IETF says/does.
Yep, I get that.
(Just like all those other NAT boxes the IETF huffed and
puffed until it turned blue in the face about.)
FWIW I always said that the IETF sticking its collective fingers in its
ears and singing la la la la la instead of acknowledging the reality
of NAT and trying to figure out how to do it right was a big mistake.
This is only about allocating a chunk of address space.
I wish that were true. :)
Doug
--
It's always a long day; 86400 doesn't fit into a short.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sat, Feb 11, 2012 at 08:34, John C Klensin john-i...@jck.com wrote: So, Chris, if you expect this allocation will avoid the costs of signing everyone up for IPv6-capable CPE, what is your transition plan? Or are you advocating an IPv4-forever model? If the latter, can you explain succinctly to the rest of us how you expect it to work? You snipped the comment I was replying too, and thus the context of my statement. What I was replying to was a statement that we should just give everyone a CPE that could handle the same space inside and outside. My response was that if we are to replace CPE it should be with IPv6 capable CPE, _not_ CGN tolerant CPE. What I did not say was anything about prolonging the life of IPv4. In fact I have argued against that several times, a few in this very thread. Hopefully that clears up your confusion. Cheers, ~Chris best, john -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Nilsson wrote: For which there is better use than prolonging bad technical solutions. A problem is that IPv6 is a bad technical solution. For examples, its bloated address space is bad, ND with full of bloated useless features is bad and multicast PMTUD only to cause ICMP implosions is bad. Address translation has set the state of consumer computing back severely. No, not at all. Do keep in mind that the real driver in IP technology is the ability for end-nodes to communicate in a manner they chose without prior coordination with some kind of protocol gateway. NAT and more so CGN explicitly disables this key feature. Wrong. Nat can be end to end transparent, if hosts recognize existence of NAT and cooperate with NAT gateways to reverse address (and port) translation. See RFC3102 and draft-ohta-e2e-nat-00.txt. I have confirmed that PORT command of unmodified ftp client just work. Though my draft assumes special NAT gateway, I recently noticed that similar thing is possible with UPnP capable existing NAT gateways. And this is not what the IETF should be doing. The IETF should seek to maximise the technical capabilities of the Internet protocol suite so that it may continue to enable new uses of the key feature, ie. end-node reachability. Yes. So, let's abandon IPv6, a bad technical solution, and deploy NAT with UPnP or PCP (if designed properly) capabilities. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/11/2012 04:52, Ralph Droms wrote: On Feb 11, 2012, at 12:27 AM 2/11/12, Doug Barton wrote: Ok, let's go with that. We already have a way to make collisions very unlikely, don't use either of 192.168.[01]. Fortunately this method doesn't require allocation of a new block. But, what we've been told by operators in the discussion about this draft is that very unlikely is not sufficiently unlikely, and that no /10 within the set of RFC 1918 addresses makes the probability of a collision sufficiently unlikely. You may disagree with that claim, but I think we have to respect it. Why do we have to respect it? Completely aside from the issue of trusting the fox to report on the security conditions of the henhouse, we haven't been provided any data to support the claim. What they're saying is, We don't have data for this, and we won't generate it. But we want you to trust us anyway that doing this thing that overwhelmingly benefits us is the right thing to do. Now on its face that's a bad deal no matter how you look at it. Now add in the fact that this issue has been created by the same foxes refusing to invest in IPv6, AND the assertion from people who know better than I that most of the problem can be dealt with by avoiding 2 1918 /24s, it just keeps getting worse. Make no mistake, I understand what they are asking for, and I'm very confident that I understand why they're asking for it. It makes their job infinitely easier if they can be given a /10 that, at least in the short term, they can be close to 100% certain will not be used inside a customer network. That way they don't have to think hard about their network design (and don't have to take as many customer service calls), and they will have N more years to diddle away until customers start using that block internally. And then the whole thing goes pear-shaped again. So no, I don't have to respect what they're telling us. So now what we're talking about is how much we're willing to pay to make the collisions how much more unlikely? I would certainly feel more comfortable with better data, but it seems highly unlikely that we can generate it. Generating the data on what CPEs use what blocks by default and how prevalent each of them are in the market is simply a matter of time and money. These types of surveys have already been done for DNSSEC, so we know exactly what it takes to do them. The fact that the same people who want us to spend valuable public IPv4 addresses so that they can save time and money with their CGN deployments are also refusing to spend the time and money necessary to back up their claims should, really, be making more people angry than it seems already are. And while I'm at it, John Klensin's post today about the get everyone a new CPE topic was a much more thorough treatment than I'm capable of, so I'll just add a +1. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
But, what we've been told by operators in the discussion about this ^ some draft is that very unlikely is not sufficiently unlikely, and that no /10 within the set of RFC 1918 addresses makes the probability of a collision sufficiently unlikely. You may disagree with that claim, but I think we have to respect it. aside from inter-operator acquisitions, this space will be used as 1918 and will soon have the same collision properties. but we have had this discussion many times. no one is changing anyone's minds. the iesg is simply trying to justify a bad position, where no position is particularly good. how much email do we all have to read to paper over the iesg's lack of guts? randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Doug Barton do...@dougbarton.us We already have a way to make collisions very unlikely, don't use either of 192.168.[01]. I gather that that's not desirable, because otherwise people wouldn't be asking for another block. Of course it could probably be made to work somehow - with enough thrust, etc, etc. But that's not the point - engineering is (or ought to be) all about balancing costs and benefits. If the people involved were asking for something incredibly painful/expensive in order to make their lives easier, the answer would rightly be 'no'. The cost would far outweigh the benefit. But they're not. All they're asking for is a modest chunk of address space, and the cost of doing that is not significant - we allocate chunks of space _all the time_. This is only about allocating a chunk of address space. I wish that were true. :) But it is. As I said before, the IETF has precisely two choices: - See CGN deployed using various hacks (e.g. squatting on space) - See CGN deployed using a block of space allocated for that purpose Allocate, or don't allocate. That's the only choice. It makes their job infinitely easier if they can be given a /10 that, at least in the short term, they can be close to 100% certain will not be used inside a customer network. That way they don't have to think hard about their network design (and don't have to take as many customer service calls) So, I gather that given the choice above, your choice would be 'I prefer the ugly solution' - because you want to make their life as miserable as you can, to punish them for the high crime of deigning to defy your sense of what's best for the network. Talk about a very irresponsible way for an SDO to conduct themselves, to use your own very apt phrase. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/11/12 04:52 , Ralph Droms wrote: But, what we've been told by operators in the discussion about this draft is that very unlikely is not sufficiently unlikely, and that no /10 within the set of RFC 1918 addresses makes the probability of a collision sufficiently unlikely. You may disagree with that claim, but I think we have to respect it. Given a provisioning system with two pools of address for a given set of customers, it can likely be demonstrated that no deployed consumer cpe is internally numbered in both of them. Managing breakage due to an address collision with existing cpe is one kind of support cost. Managing breakage due to a new formerly non-private scope address range now being employed is another support cost. It's entirely possible that reasonable people with experience operating consumer facing networks can disagree on which cost is more onerous. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/9/12 3:40 PM, Mark Andrews ma...@isc.org wrote: In message 6.2.5.6.2.20120209091221.082cb...@resistor.net, SM writes: Hi Chris, At 08:57 AM 2/9/2012, Chris Grundemann wrote: http://www.apnic.net/publications/news/2011/final-8 I am aware of the APNIC announcement. That's one out of five regions. Are you proposing that every ISP on the planet be given a /10 for inside CGN use, rather than one single /10 being reserved for this purpose? No. If I am not mistaken, IPv4 assignments are on a needs basis. In my previous comment, I mentioned that RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. Even if the IANA pool was not exhausted, it is unlikely that an ISP would get a /20 due to the slow-start mechanism. Regards, -sm In none of the discussions I've seen has anyone proposed forcing ISP's to use this space. It is being provided as a alternative, the same away RFC 1918 space is offered as a alternative. Today you get ask have you considered RFC 1918 space? You can still get space even if RFC 1918 space would have worked. I suspect a similar question, will be part of allocation proceedures, for this space in the future. You need to know that the applicant is aware of this space. Please remember that this draft is in support of ARIN Draft Policy 2011-5. Should this draft become an RFC, and should ARIN pony up the /10, ARIN's staff is likely to look askance at requests for address space for CGNs. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; the ARIN/RIR policy processes can be much more targeted to the needs of the community, and in this case, I think your concern has already been addressed. Chris Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
--On Friday, February 10, 2012 08:47 -0700 Chris Donley c.don...@cablelabs.com wrote: ... Please remember that this draft is in support of ARIN Draft Policy 2011-5. Should this draft become an RFC, and should ARIN pony up the /10, ARIN's staff is likely to look askance at requests for address space for CGNs. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; the ARIN/RIR policy processes can be much more targeted to the needs of the community, and in this case, I think your concern has already been addressed. Chris, To follow up on an earlier comment, the rate at which ARIN (or other RIRs) are running out of /10s (or /8s) is probably irrelevant, as are hypotheses about what ARIN staff might do about requests for allocation for CGN use with or without this policy/ block. But, since people want to talk about it in those terms, I'd be interested in some real data and projections. In particular, how many large ISPs have expressed significant interest in this, where large is defined as big enough that an application for a /10 would be taken seriously. Now, if one /10 block is allocated to this use versus all of those ISPs applying for separate ones, how much does that change the likely date at which all of the currently-unallocated /8s are exhausted. If that difference is less than years, I, personally, don't think that particular argument is useful. Other arguments may be, but not that one. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 11:15, John C Klensin john-i...@jck.com wrote: To follow up on an earlier comment, the rate at which ARIN (or other RIRs) are running out of /10s (or /8s) is probably irrelevant, as are hypotheses about what ARIN staff might do about requests for allocation for CGN use with or without this policy/ block. But, since people want to talk about it in those terms, I'd be interested in some real data and projections. In particular, how many large ISPs have expressed significant interest in this, where large is defined as big enough that an application for a /10 would be taken seriously. Now, if one /10 block is allocated to this use versus all of those ISPs applying for separate ones, how much does that change the likely date at which all of the currently-unallocated /8s are exhausted. This is not about IPv4 life-support. This is about providing the best answer to a difficult problem. Run-out date is not nearly as important as efficient use at this point. It is not efficient for multiple ISPs to use different space when a shared space will function optimally. If that difference is less than years, I, personally, don't think that particular argument is useful. Other arguments may be, but not that one. Please see https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space for a more thorough analysis of the motivations, pros, cons, and alternatives for this shared CGN space. I think you'll find that those other arguments are laid out there. Cheers, ~Chris john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
--On Friday, February 10, 2012 11:22 -0700 Chris Grundemann cgrundem...@gmail.com wrote: On Fri, Feb 10, 2012 at 11:15, John C Klensin john-i...@jck.com wrote: To follow up on an earlier comment, the rate at which ARIN (or other RIRs) are running out of /10s (or /8s) is probably irrelevant, as are hypotheses about what ARIN staff might do about requests for allocation for CGN use with or without this policy/ block. ... This is not about IPv4 life-support. This is about providing the best answer to a difficult problem. Run-out date is not nearly as important as efficient use at this point. It is not efficient for multiple ISPs to use different space when a shared space will function optimally. Indeed, although I note that it isn't a huge step from the above to get to we could really make _much_ more efficient use of IPv4 space by partitioning the Internet into regions and using explicit routing or X.75-like gateways to route traffic between regions, thereby permitting each region to use almost all of the IPv4 space. One could even use CGNs to establish that model with each ISP using almost the entire IPv4 space inside its castle walls.Now, I think either of those would be terrible ideas but, as you and others are probably aware, people who believe themselves to be serious and competent have proposed them, almost exactly Anything that moves us closer to those models gives me visions of slippery steep cliffs and the creeps, so I feel a need to be careful about efficiency arguments too. YMMD, either because you see the efficiency arguments differently, because you have reason to be less afraid of an ultimate islands connected by gateways outcome, or for other reasons. If that difference is less than years, I, personally, don't think that particular argument is useful. Other arguments may be, but not that one. Please see https://tools.ietf.org/html/draft-bdgks-arin-shared-transition -space for a more thorough analysis of the motivations, pros, cons, and alternatives for this shared CGN space. I think you'll find that those other arguments are laid out there. I have and I agree those arguments are there (their interaction with my fear of the scenarios above is another matter). Again, my main suggestion was that we just stop the discussions based on allocation strategies or IPv4 exhaustion alone... because they are distractions rather than helpful. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 07:47, Chris Donley wrote: Please remember that this draft is in support of ARIN Draft Policy 2011-5. Partially, sure. But RFCs apply to the whole Internet. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; I'm not going to parse the nuances of what you wrote, but I think generally you're wrong. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2012-02-11 11:09, Doug Barton wrote: On 02/10/2012 07:47, Chris Donley wrote: Please remember that this draft is in support of ARIN Draft Policy 2011-5. Partially, sure. But RFCs apply to the whole Internet. Hear hear. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; I'm not going to parse the nuances of what you wrote, but I think generally you're wrong. The RIRs get their space from IANA@ICANN, so s/ARIN/ICANN/ and read clause 4.3 of RFC 2860 carefully. The IAB decided that the current issue *is* the IETF's business under that clause. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/9/12 10:47 PM, Doug Barton wrote: As I (and many others) remain opposed to this entire concept I think it's incredibly unfortunate that the IESG has decided to shift the topic of conversation from whether this should happen to how it should happen. As an AD who is now comfortable with going forward with the document, I do want to point out that the IESG as a whole has *not* come to consensus on this document. There are still not the required number of Yes or No objection ballots for the document to move forward. So I don't think it's accurate to say that the IESG is only deciding how it should happen. Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional [RFC1918] space I think it's a feature that we're finally willing to admit that this new block is going to be used as 1918 space. I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. (See my message of 2/1/12 4:33 PM -0600. ) 1918 space is guaranteed to be private, and devices have been built that have made the assumption that the space is private and they will not see it on a network that is not within its administrative control. This proposed space is most assuredly not that. It's shared and therefore has additional constraints on use that 1918 space does not. It is certainly *similar* to 1918 space in that it is not globally routeable, but it is not 1918 space. Given that previous requests for new 1918 space have been (rightly) denied, I think this document should describe why this request is better/more important than previous requests, and what the bar will be for future requests for new 1918 space. I hope it does, and if it is not sufficient, I expect text will be accepted by the authors. In particular, the text suggested in the aforementioned message was: Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. When I previously proposed this as *the* proper solution I was told that it wasn't in any way practical. Now that we're apparently willing to discuss it as *a* possible solution one wonders why a new block is necessary at all. See above paragraph. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 15:42, Pete Resnick wrote: On 2/9/12 10:47 PM, Doug Barton wrote: As I (and many others) remain opposed to this entire concept I think it's incredibly unfortunate that the IESG has decided to shift the topic of conversation from whether this should happen to how it should happen. As an AD who is now comfortable with going forward with the document, I do want to point out that the IESG as a whole has *not* come to consensus on this document. There are still not the required number of Yes or No objection ballots for the document to move forward. So I don't think it's accurate to say that the IESG is only deciding how it should happen. I suppose that's some small comfort. Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional [RFC1918] space I think it's a feature that we're finally willing to admit that this new block is going to be used as 1918 space. I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. The following is not meant to be a snark (nor is anything else I've written on this topic, for that matter), but I think it's a huge problem that you think *saying* Don't use this as 1918 space is going to make any difference at all. Given that previous requests for new 1918 space have been (rightly) denied, I think this document should describe why this request is better/more important than previous requests, and what the bar will be for future requests for new 1918 space. I hope it does, For my money, it does not. and if it is not sufficient, I expect text will be accepted by the authors. In particular, the text suggested in the aforementioned message was: Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. When I previously proposed this as *the* proper solution I was told that it wasn't in any way practical. Now that we're apparently willing to discuss it as *a* possible solution one wonders why a new block is necessary at all. See above paragraph. So if we're saying the same thing about CPEs capable of doing CGN needing to understand the same block(s) on the inside and outside, why is the new block necessary? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) Cheers, ~Chris Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 16:12, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). Ok, now THIS is a snark: Dude, don't bogart the good stuff, pass it around man. /snark We were specifically asked not to reopen the debate on the necessity of CGN to start with, so I won't go there feel free to dig through the archives on all the reasons why this evil isn't actually necessary. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) Everyone doesn't need a new one. In fact, the only end users who need new ones are those behind ISPs that chose to ignore IPv6, need to deploy CGN, and can't actually get CGN done with existing 1918 space. I strongly suspect that the latter number will be very small, and what this allocation request is really about is to make lives easier (read, cheaper) for those that didn't want to invest in IPv6, and now don't want to have to think hard about how they do their network design. It's also in no way clear to me how many extant CPEs would break if CGN were deployed with 1918, and/or how many of the extant CPEs will have to be replaced anyway to do CGN in the first place. Repeated requests for hard data on this (by me and others) have gone unanswered, I suspect because collecting such data would also be expensive. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). We do not need another reason for people to delay v6 deployment. Just saying this isn't about sticking your head in the sand does not make it any more so. This _will_be_used_ as an excuse for not rolling out v6. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) There are more than 1 prefix in RFC1918. Tell the customers to use another one than the one you inflict on them as bad excuse for not doing v6 quick enough. That there will be increased support load on any provider not giving customers public space is a suitable punishment for above mentioned failure to deliver v6. I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. -- Måns, sadly enough not surprised by the fact that this bad idea still isn't properly killed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Pete Resnick wrote: and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. With so complicated functionality of NAT today, the only practical approach to build such equipment is to make it a double NAT as: +-+ +-+ (a private space)-| NAT |---| NAT |-(same private space) +-+ +-+ the only problem is that we need another private address space used only between element NATs within the double NAT. Can IETF allocate such address? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Feb 10, 2012 4:25 PM, Måns Nilsson mansa...@besserwisser.org wrote: On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). We do not need another reason for people to delay v6 deployment. Just saying this isn't about sticking your head in the sand does not make it any more so. This _will_be_used_ as an excuse for not rolling out v6. +1. This is all business. Companies have made their choices. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) There are more than 1 prefix in RFC1918. Tell the customers to use another one than the one you inflict on them as bad excuse for not doing v6 quick enough. That there will be increased support load on any provider not giving customers public space is a suitable punishment for above mentioned failure to deliver v6. I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. This is the logical path for the cgn minded. They need to deal with the challenge of renumbering users. I also oppose this draft. Cb -- Måns, sadly enough not surprised by the fact that this bad idea still isn't properly killed. ___ 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: =?iso-8859-1?Q?M=E5ns?= Nilsson mansa...@besserwisser.org We do not need another reason for people to delay v6 deployment. The last time this issue (CGNAT space) was discussed, we were asked not to open this can of worms. I don't know if that request still holds, but seriously, nothing good can come of a discussion on this topic. It will just be a lot of rhetoric, and _zero_ minds will be changed. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/10/12 3:57 PM, Doug Barton wrote: On 02/10/2012 15:42, Pete Resnick wrote: I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. The following is not meant to be a snark Not taken as such. ...I think it's a huge problem that you think *saying* Don't use this as 1918 space is going to make any difference at all. Neither the text of the current draft nor the proposed text that Brian and I seem to like says Don't use this as 1918 space, nor do I think saying so would be a good idea or make any difference. I apologize that I was not clear when I said that it is *not* to be used as 1918 space. What I meant was that the document should be clear that this so-called Shared Address Space has limitations and can't be used in circumstances where 1918 addresses can be used. Now, I am under no delusions that some equipment won't *try* to use this new space in ways that will cause problems (any more than I think that people won't use port numbers for non-registered uses, or won't use bogus SMTP protocol return codes, etc.). But like those situations, folks who want to use this new address space *don't care* if other people do stupid things with it; they're making their own beds and they can lie in them. Remember, the whole purpose of using new address space is that the 1918 space has specific semantics that folks have already implemented and deployed in equipment *in compliance with the spec* in that they don't NAT what they consider an outside address. If people with current equipment call and complain when a CGN uses 1918 space and screws up their equipment, they've got a legitimate beef. But if new folks start using Shared Address Space without NATing it properly, they've only got themselves to blame. The new and suggested text makes this all clear: You can safely use this non-globally-routeable Shared Address Space so long as you NAT it on both ends. If you don't, you're going to have routing problems. You want routing problems? Have at it. I don't care. Like any good IETF spec, we're just telling you what the rest of us intend to do. If the text is not clear, please help. Given that previous requests for new 1918 space have been (rightly) denied, I think this document should describe why this request is better/more important than previous requests, and what the bar will be for future requests for new 1918 space. I hope it does, For my money, it does not. Again, text welcome. Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. So if we're saying the same thing about CPEs capable of doing CGN needing to understand the same block(s) on the inside and outside, why is the new block necessary? I believe this has been said multiple times before (and is not the subject of this Last Call, AFAICT), but: The new block is necessary because current equipment, which will be connected to CGNs (or any other kinds of devices that use this new space), and which conforms to a reasonable interpretation of 1918, is not able to understand the same block on the inside and the outside, and therefore will not be able to route through CGNs (or other such new equipment) if they used 1918 space. Again, if the current text is not clear on this point, please identify where clarification is needed. (If you disagree with my assessment, let's please take that conversation offlist and we can figure out where the disagreement is and maybe bring our collective wisdom back to the list. And that invitation is to anyone who feels that they disagree with the above reasoning. You have my email address.) pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/10/12 6:38 PM, Masataka Ohta wrote: Pete Resnick wrote: and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. With so complicated functionality of NAT today, the only practical approach to build such equipment is to make it a double NAT Correct. That's what a CGN is, and that is what other equipment of this sort would be. as: +-+ +-+ (a private space)-| NAT |---| NAT |-(same private space) +-+ +-+ the only problem is that we need another private address space used only between element NATs within the double NAT. Can IETF allocate such address? That's what this document is doing: Allocating address space to go between 2 NATs. Maybe I don't understand your question? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Thanks for your response, mine is below, with snipping. On 02/10/2012 19:19, Pete Resnick wrote: On 2/10/12 3:57 PM, Doug Barton wrote: On 02/10/2012 15:42, Pete Resnick wrote: I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. The following is not meant to be a snark Not taken as such. ...I think it's a huge problem that you think *saying* Don't use this as 1918 space is going to make any difference at all. Neither the text of the current draft nor the proposed text that Brian and I seem to like says Don't use this as 1918 space, nor do I think saying so would be a good idea or make any difference. I apologize that I was not clear when I said that it is *not* to be used as 1918 space. What I meant was that the document should be clear that this so-called Shared Address Space has limitations and can't be used in circumstances where 1918 addresses can be used. I'm sorry, I was trying to be concise in order to not re-open the debate on the topic of should, but your response indicates that you're not seeing my point. The premise of this draft is that a new block is necessary because the same prefixes can't be used in the customer network and the CGN layer. So, let's allocate a new block to use *only* in the CGN layer. That way it can never conflict. My point is that no matter how loudly you say, Don't use this as 1918 space! some users will do it anyway. There have already been several requests for more IPv4 1918 space because a non-zero number of end user networks have run out. So we know that people *will* use this new block internally. Therefore we can be fairly certain that at some point there will be a conflict. That means that there is no reason to allocate this new block. But if new folks start using Shared Address Space without NATing it properly, they've only got themselves to blame. That's interesting ... so you're saying that the people who created the problem should be responsible for dealing with their own mess? :) More seriously, you seem to be saying that because the draft says Don't do it it's Ok for us to do the allocation because if someone does screw up it's not our fault because we told them not to do it. My point is that because we can see the trap, we shouldn't walk right into it with a smile on our face. If the text is not clear, please help. I don't think any amount of text-twiddling can help, since I feel that this is a bad idea from the ground up. I believe this has been said multiple times before (and is not the subject of this Last Call, AFAICT), but: The new block is necessary because current equipment, which will be connected to CGNs (or any other kinds of devices that use this new space), and which conforms to a reasonable interpretation of 1918, is not able to understand the same block on the inside and the outside, and therefore will not be able to route through CGNs (or other such new equipment) if they used 1918 space. Yes, that's been *said* multiple times, but it hasn't been backed up with solid data. OTOH, numerous people (many of whom are in a much better position to know than I am) have pointed out that the overwhelming majority of consumer CPE devices use one of 192.168.[01] as their internal networks. That number is likely to be in the 80% range, if not much higher. Therefore it's very likely that most of this problem is solved already if the ISPs simply stay away from those 2 ranges. What I, and others, have said repeatedly now is that given how easy most of this problem is to solve, the people who have a fiduciary interest in solving the rest of it should do so, without asking the rest of the Internet to subsidize their (arguably flawed) business model. Or put more simply, if the problem is that CPEs don't know how to deal with the same block on the inside and outside, there are (at least) 2 ways for the ISPs to solve that which do not involve allocating a new block. Again, if the current text is not clear on this point, please identify where clarification is needed. (If you disagree with my assessment, let's please take that conversation offlist and we can figure out where the disagreement is and maybe bring our collective wisdom back to the list. I appreciate the invitation, but I don't know how much more I can bring to the topic that I haven't already. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Doug Barton do...@dougbarton.us My point is that no matter how loudly you say, Don't use this as 1918 space! some users will do it anyway. And if they do, any problem that results is _their_ problem. That means that there is no reason to allocate this new block. No. If people are using thing X in way A, _which is allowed by the definition of X_, then it's really rude/unfair for a responsible standards body to turn around and say 'ooops, now you can't use thing X in way A'. If, on the other hand, the standards body then says 'here's a new thing Y; don't use thing Y in way A', and people go ahead and use thing Y in way A, then the standards body can reasonably sit back and laugh at them and blow a raspberry at them when they complain. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 20:04, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us My point is that no matter how loudly you say, Don't use this as 1918 space! some users will do it anyway. And if they do, any problem that results is _their_ problem. You snipped the bit of the my post that you're responding to where I specifically disallowed this as a reasonable argument. That means that there is no reason to allocate this new block. No. Let me boil it down even more for you. The new block's purpose is to make collisions impossible. It cannot fulfill that purpose. So it shouldn't be allocated. If people are using thing X in way A, _which is allowed by the definition of X_, then it's really rude/unfair for a responsible standards body to turn around and say 'ooops, now you can't use thing X in way A'. If, on the other hand, the standards body then says 'here's a new thing Y; don't use thing Y in way A', and people go ahead and use thing Y in way A, then the standards body can reasonably sit back and laugh at them and blow a raspberry at them when they complain. Setting aside the fact that what you're suggesting is a silly and childish way for any human to act (even taking hyperbole into account), it's a very irresponsible way for an SDO to conduct themselves. And that's assuming that this action doesn't have a cost, whereas the truth is that it has several, both direct and indirect. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Doug Barton do...@dougbarton.us
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
counter-arguments {A, B, C}, and since you have no other
counter-arguments, I win.'
Just because you don't think much of it, doesn't mean the rest of us have
to agree with you on that.
The new block's purpose is to make collisions impossible.
Ah, no.
If you were to say 'to make collisions very unlikely if it is used in the
way it is specified', then I could agree with that. But to take a
straw-man absolutist position like impossible, and then knock it down
with great pomp:
It cannot fulfill that purpose.
is not exactly a plausible argument. Outlawing cell-phone use while driving
may make accidents caused by cell-phone usage less likely, but it can't make
them impossible. Only physics (and math) make things _absolutely_ impossible
it's a very irresponsible way for an SDO to conduct themselves.
What, to say 'if you use this in a way that we specifically direct it not
be used, any problems are your fault'?
That's odd, because my lawnmower says much the same thing: 'Don't use this
as a hedge-trimmer. If you do, and cut off your arm, don't even bother
thinking of suing us, because we warned you not to.' (OK, so I translated
the legalese into something more amusing, but the basic message is exactly
that.)
And that's assuming that this action doesn't have a cost, whereas
the truth is that it has several, both direct and indirect.
And that would be...? How exactly does simply allocating a chunk of
address space - something the Internet engineering community does every
day - for a specific purpose have a cost ... both direct and indirect?
If you're actually thinking of 'deploying CGNAT' in the text above, this
discussion is not about that. That's going to happen no matter what the
IETF says/does. (Just like all those other NAT boxes the IETF huffed and
puffed until it turned blue in the face about.)
This is only about allocating a chunk of address space.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 20:44, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
counter-arguments {A, B, C}, and since you have no other
counter-arguments, I win.'
Just because you don't think much of it, doesn't mean the rest of us have
to agree with you on that.
I understand that. Do you understand that I understand what you're
saying, and I don't agree with you?
The new block's purpose is to make collisions impossible.
Ah, no.
If you were to say 'to make collisions very unlikely if it is used in the
way it is specified', then I could agree with that.
Ok, let's go with that. We already have a way to make collisions very
unlikely, don't use either of 192.168.[01]. Fortunately this method
doesn't require allocation of a new block.
So now what we're talking about is how much we're willing to pay to make
the collisions how much more unlikely?
But to take a
straw-man absolutist position like impossible, and then knock it down
with great pomp:
It cannot fulfill that purpose.
I was using shorthand (or argumentum ad absurdum if you prefer) to point
out that given the fact that this new block can't fix the whole problem,
and also given the fact that there are already solutions available that
fix most of the problem for free, allocating the new block is a bad idea.
it's a very irresponsible way for an SDO to conduct themselves.
What, to say 'if you use this in a way that we specifically direct it not
be used, any problems are your fault'?
Again, you snipped the bit where I answered this. Go back and re-read my
previous post if you're confused.
And that's assuming that this action doesn't have a cost, whereas
the truth is that it has several, both direct and indirect.
And that would be...? How exactly does simply allocating a chunk of
address space - something the Internet engineering community does every
day - for a specific purpose have a cost ... both direct and indirect?
Again, I'm really trying not to dive back into the should we question,
but just as an example, there are 4,096 /22s in a /10. That's 4k new
SMBs that cannot get IPv4 space if this block is allocated.
If you want more, go look at the archives.
If you're actually thinking of 'deploying CGNAT' in the text above, this
discussion is not about that. That's going to happen no matter what the
IETF says/does.
Yep, I get that.
(Just like all those other NAT boxes the IETF huffed and
puffed until it turned blue in the face about.)
FWIW I always said that the IETF sticking its collective fingers in its
ears and singing la la la la la instead of acknowledging the reality
of NAT and trying to figure out how to do it right was a big mistake.
This is only about allocating a chunk of address space.
I wish that were true. :)
Doug
--
It's always a long day; 86400 doesn't fit into a short.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Pete Resnick wrote: and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. With so complicated functionality of NAT today, the only practical approach to build such equipment is to make it a double NAT Correct. Note that the double NAT, here, is AN equipment. Can IETF allocate such address? That's what this document is doing: Allocating address space to go between 2 NATs. Maybe I don't understand your question? My point is that those who are arguing against the proposed allocation because of the capability of a double NAT equipment should argue for allocation of another space to enable development of the double NAT equipment. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
At 03:03 PM 1/30/2012, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Reserved IPv4 Prefix for Shared CGN Space' draft-weil-shared-transition-space-request-14.txt as a BCP On its December 15, 2011 telechat, the IESG reviewed version 10 of this document and requested various changes. These changes are reflected in the draft version 14 and the IESG now solicits community input on the changed text only. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-16. Exceptionally, comments may be sent to Is that a two-weeks Last Call? Will the determination of consensus be made only on the basis of this Last Call? In Section 3: A Service Provider can number the interfaces in question from legitimately assigned globally unique address space. While this solution poses the fewest problems, it is impractical because globally unique IPv4 address space is in short supply. Unique IPv4 address space is not in short supply in some regions. If it is globally in short supply, I gather that several regions have already reached their IPv4 Exhaustion phase. I haven't seen any announcements about that. While the Regional Internet Registries (RIR) have enough address space to allocate a single /10 to be shared by all Service Providers, they do not have enough address space to make a unique assignment to each Service Provider. The above is incorrect as RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. On reading this draft, I conclude that as IPv4 addresses are nearly exhausted, the only option left is to deploy Carrier Grade NAT instead of requesting IPv4 addresses from a RIR. For the determination of consensus, I do not support this proposal. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 9, 2012 at 08:44, SM s...@resistor.net wrote: In Section 3: A Service Provider can number the interfaces in question from legitimately assigned globally unique address space. While this solution poses the fewest problems, it is impractical because globally unique IPv4 address space is in short supply. Unique IPv4 address space is not in short supply in some regions. If it is globally in short supply, I gather that several regions have already reached their IPv4 Exhaustion phase. I haven't seen any announcements about that. http://www.apnic.net/publications/news/2011/final-8 http://www.coisoc.org/index.php/2011/internet-society-statement-on-apnic-ipv4-depletion/ http://www.apnic.net/community/ipv4-exhaustion/ipv4-exhaustion-details http://isoc.org/wp/newsletter/?p=3592 While the Regional Internet Registries (RIR) have enough address space to allocate a single /10 to be shared by all Service Providers, they do not have enough address space to make a unique assignment to each Service Provider. The above is incorrect as RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. On reading this draft, I conclude that as IPv4 addresses are nearly exhausted, the only option left is to deploy Carrier Grade NAT instead of requesting IPv4 addresses from a RIR. Are you proposing that every ISP on the planet be given a /10 for inside CGN use, rather than one single /10 being reserved for this purpose? Cheers, ~Chris For the determination of consensus, I do not support this proposal. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Hi Chris, At 08:57 AM 2/9/2012, Chris Grundemann wrote: http://www.apnic.net/publications/news/2011/final-8 I am aware of the APNIC announcement. That's one out of five regions. Are you proposing that every ISP on the planet be given a /10 for inside CGN use, rather than one single /10 being reserved for this purpose? No. If I am not mistaken, IPv4 assignments are on a needs basis. In my previous comment, I mentioned that RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. Even if the IANA pool was not exhausted, it is unlikely that an ISP would get a /20 due to the slow-start mechanism. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 9, 2012 at 10:59, SM s...@resistor.net wrote: Hi Chris, At 08:57 AM 2/9/2012, Chris Grundemann wrote: http://www.apnic.net/publications/news/2011/final-8 I am aware of the APNIC announcement. That's one out of five regions. My apologies, when you stated I haven't seen any announcements about that. I thought you were not. Hopefully others found the link useful. Are you proposing that every ISP on the planet be given a /10 for inside CGN use, rather than one single /10 being reserved for this purpose? No. If I am not mistaken, IPv4 assignments are on a needs basis. In my previous comment, I mentioned that RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. Even if the IANA pool was not exhausted, it is unlikely that an ISP would get a /20 due to the slow-start mechanism. In the ARIN region, slow-start only applies to new-to-ARIN organizations. Most (if not all) of the ISPs we're discussing here are established entities and are not subject to slow start. More to the point: I do not see giving everyone a unique bit of space for inside CGN use as an efficient solution to the problem. Likewise, waiting until we are completely out of IPv4 space before reacting to the problems that IPv4 free pool exhaustion WILL cause seems _very_ unlikely to produce positive results. Cheers, ~Chris Regards, -sm -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
