Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Hi Ron On 3 December 2011 22:06, Ronald Bonica rbon...@juniper.net wrote: Folks, On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because: - it is difficult. (We are choosing between the lesser of two evils.) - a lively discussion on this mailing list has not yet converged Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? The shared /10 is required for the deployment of NAT444. This ensures a standardised, consistent way to identify CGN internal addressing, irrespective of service provider. This also provides the lowest risk of address collision with existing networks. CGN is a generic term, and in some cases 1918 space can be used - for example, where the CPE is an end-device (single host) that is not providing any additional LAN connectivity, eg mobile devices. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? The impact of using a single /10 for CGN/NAT444 is far less than each ISP assigning their own dedicated block. Large ISPs would consume a /10 each for this purpose. - Can alternative /10s be used? The alternatives (discussed) are: 1. RFC1918 space - I do not see that the inside addressing in NAT444 is legitimate use for this space. It is defined as Address allocation for Private Internets, which ISP customer connectivity is not. 2. 240/4 - I agree that this block should be released for unicast use, however for CGN/NAT444 it is not 'fit for purpose' for use with ALL existing CPE and network hardware. Perhaps a separate I-D is required to release the 240/4 address block for future use, however this should not be confused with the immediate requirement. Regards Daryl ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On 5 Dec 2011, at 18:08, Noel Chiappa wrote: I hear you. However, after thinking about it for a while, I still think we ought to include a chunk of 240/ space _as well as_ some 'general use' space (be it a /10 of that, or whatever). +1 Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
I don't want to go too far down this road, as it touches sensitive network architecture issues, but I think you're thinking of this in terms of a box. Please think, instead, of a regional network with failover capabilities and widely distributed customers.The aggregate need is (at least) a /10 for a large number of providers. Chris On 12/8/11 12:35 AM, Måns Nilsson mansa...@besserwisser.org wrote: The space is going to be reused several times anyway, and NAT (be it carrier, enterprise or SOHO) breaks pretty badly when session space is exhausted. It does not make sense to have much more than a, say, /16 behind each. (CGN is just NAT in a NEBS certified enclosure with an expensive support contract; the basic b0rkenedness remains.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Mark == Mark Andrews ma...@isc.org writes: Mark This is not a ISP/CUSTOMER problem. This is a Mark ISP/CUSTOMER/WORK problem. Mark You have the ISP using 172.16/12 You have the customer using Mark 192.168/16 or 10/8 You have WORK using 172.16/12 Mark Enterpises have choosen to use 172.16/12 for EXACTLY the same Mark reasons you want ISP to use 172.16/12. CPE equipment doesn't Mark default to that range. Both the enterprise and the ISP don't Mark want to clash with the employee/customer. It's not in general a problem unless the tunnel to work is terminated on the CPE device itself.For the normal case, the *DEKSTOP/LAPTOP* terminates the VPN, and so it sees CUSTOMER and WORK prefixes, while CPE device sees CUSTOMER and ISP prefixes. WORK sees WORK and Public-IP prefixes. In the case where the VPN is terminated on the CPE device, I claim three things: a) customer/WORK is sophisticated and can communicate about problem. b) the CPE device already has a public IP on the outside, the ISP should not renumber it. c) the CPE device can be given a host route for it's default gateway, and it has no reason to talk to any other host in the ISPs CGN network anyway. (Openswan installs a host route via the old default route for ESP traffic, and a pair of 0.0.0.0/1 and 128.0.0.0/1 routes through the tunnel if you are extruding. This avoids removing the default route...) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. pgpm2uQUalo0C.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Chris == Chris Donley c.don...@cablelabs.com writes: Chris We're requesting a /10, not a /12 or /15 (devices attached to Chris one CGN might use the whole /15). Such an allocation would Chris be too small for a regional CGN deployment at a larger ISP, Chris and would likely result in double-CGN. Shared CGN Space Chris really needs to be a /10. Chris Second, many ISPs do not control customer home network Chris addressing decisions. It is not feasible to tell a customer Chris to renumber, especially when the customer is legitimately Chris using RFC1918 space in accordance with the RFC. So, this is being forced on existing customers, or is being used for new customers only? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
From: =?utf-8?B?TcOlbnM=?= Nilsson mansa...@besserwisser.org I have 1918 space at home, that is used at work. My VPN works. Maybe we should allocate a chunk of space explicity for tunnel termination, instead of using 1918 for that? I would think it could be re-used across enterprises (but I'm probably not familiar enough with tunnels to see some issue there), especially considering people are (re-)using 1918 space for that now. Anyway, if that did work, it should kill a bunch of these problems. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Noel Chiappa j...@mercury.lcs.mit.edu wrote: Maybe we should allocate a chunk of space explicity for tunnel termination, instead of using 1918 for that? Interesting... I've learned to avoid 1918 for tunnel endpoints at almost-any cost: you lose all diagnostic packets. As it is now, I assign fully-routable IPs, and try to static-route so the endpoint actually receives traffic to that IP. (It doesn't always work.) I would think it could be re-used across enterprises (but I'm probably not familiar enough with tunnels to see some issue there), Presumably we wouldn't receive traffic to these IPs, but at least the outgoing ICMP errors wouldn't be blocked. especially considering people are (re-)using 1918 space for that now. Anyway, if that did work, it should kill a bunch of these problems. It certainly seems like an improvement... -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On 2011-12-06 22:06, Benson Schliesser wrote: ISPs need to use addressing within this scope that does not cause (additional) problems for their existing customers (and their customers' equipment). And in the event of an addressing conflict, operators (on both sides) need a common reference to determine who is at fault - i.e. who is responsible for fixing the problem. Are you suggesting that ISPs MUST use the proposed /10 for CGNs? That's... interesting. Maybe it could empower customers when an ISP is using something else (e.g. squat space) for its CGN and it's causing issues... Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Benson == Benson Schliesser bschl...@cisco.com writes: Benson However, there is one essential point that I'd like to Benson clarify: We need a common standard for numbering CGN NAT444 Benson deployments. Benson For NAT444 deployments of CGN, we are talking about a new Benson scope - the intermediate CGN zone network - that is Benson neither global or local. Within this scope, one cannot Benson expect end-to-end (global) address fidelity (because traffic Benson is NATted), nor can one expect forwarding to be confined to Benson a single organization (because it touches CPE etc). Okay, while this address touches the CPE, it does not cross it. Benson PS - I also support turning 240/4 into unicast, as others Benson have recommended. But this will not help in the immediate Benson future timeframe, for the currently deployed equipment, Benson which is driving the need for Shared CGN Space. It may be Benson complementary, but does not reduce the need for a /10 Benson assignment. The CGN space seems like a very good place to use 240.0/10. A single organization often controls and specifies all equipment which will use the address space, and even in the cases where customers have their own equipment, a lot of it will have no problem with 240. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Michael, On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote: The CGN space seems like a very good place to use 240.0/10. I believe the main driver behind this discussion is the need to deal with deployed non-field-upgradable CPE that has issues with having RFC 1918 space being assigned on the WAN interface. I'd guess said hardware would also likely have issues with 240/4 space being instead. A single organization often controls and specifies all equipment which will use the address space, and even in the cases where customers have their own equipment, a lot of it will have no problem with 240. I long ago gave up being surprised at the problems (particularly low end) devices connected to the Internet had anytime you did _anything_ out of the ordinary. I am skeptical executive management of the ISPs interested in the draft-weil space would take your assurance that there would be no problems without data to back it up. More likely, they'll simply say get another free block while we can or use 44.x.0.0/10 or something similar. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
David == David Conrad d...@virtualized.org writes: David On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote: The CGN space seems like a very good place to use 240.0/10. David I believe the main driver behind this discussion is the need David to deal with deployed non-field-upgradable CPE that has David issues with having RFC 1918 space being assigned on the WAN David interface. I'd guess said hardware would also likely have David issues with 240/4 space being instead. You'd guess, or you know. I'd like to see 240.0/10 assigned for this purpose, regardless of whether or not we assign another block. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On Dec 7, 2011, at 7:46 AM, Simon Perreault wrote: On 2011-12-06 22:06, Benson Schliesser wrote: ISPs need to use addressing within this scope that does not cause (additional) problems for their existing customers (and their customers' equipment). And in the event of an addressing conflict, operators (on both sides) need a common reference to determine who is at fault - i.e. who is responsible for fixing the problem. Are you suggesting that ISPs MUST use the proposed /10 for CGNs? In principle, I probably would not object to this suggestion. But I think that SHOULD is a better description of the requirement. (And I could be missing it, but I can't find such language in e.g. RFC1918.) That's... interesting. Maybe it could empower customers when an ISP is using something else (e.g. squat space) for its CGN and it's causing issues... Yes, I would hope so. As a BCP for numbering CGN NAT444 deployments, it would provide a useful reference point. Cheers, -Benson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
From: Michael Richardson m...@sandelman.ca The CGN space seems like a very good place to use 240.0/10. A single organization often controls and specifies all equipment which will use the address space Not _exclusively_ 240/, though, because as has been pointed out numerous times, for many contemplated CGN deployments, the CPE equipment connected directly to the CGN-fronted fabric will be that already owned by the customers, and with home customers, that may cover a very, very wide stretch of manufacturers and models - i.e. whatever those customers already own. And many of them won't support 240/. As I already pointed out: I suspect that CGNs are not, by and large, targetted to entirely new customers ... as customer bases grow, some ISPs don't have enough 'public' space to give one to each customer any more, so they want to deploy CGN - and they need address space for the chunk of fabric between the CGNs and the CPEs. In other words, its mostly _existing_ customers who are about to be CGN'd. But as I previously pointed out in another message (too lazy to dig it up), I do think we should have a chunk of 240/ space as _part_ of the CGN allocation. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at 11:31:11AM -0800 Quoting David Conrad (d...@virtualized.org): Michael, On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote: The CGN space seems like a very good place to use 240.0/10. I believe the main driver behind this discussion is the need to deal with deployed non-field-upgradable CPE that has issues with having RFC 1918 space being assigned on the WAN interface. I'd guess said hardware would also likely have issues with 240/4 space being instead. I believe we can narrow the problem with RFC 1918 addresses down to same or overlapping prefix on the outside as inside, rather than assuming that any use of 1918 space on the outside interface is detrimental. Does anybody know of any evidence to the contrary? Vendor default allocations of RFC1918 to broadband router LAN interfaces are limited to nets 10 and 192.168. Does anybody know of any evidence to the contrary? Therefore, point out a /15 from 172.16.0.0/12 and be done with it. The few conflicts arising will fall in two classes: a/ People who have knowingly changed their LAN prefix. b/ Organisations large enough to use _all_ of RFC 1918 inside. a means they can change again. Problem solved. b means that they are large enough to be able to buy public external addresses, if they do not already posess swamp space. Problem solved. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Now I understand the meaning of THE MOD SQUAD! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
In message 20111207220317.3530b18c...@mercury.lcs.mit.edu, Noel Chiappa write s: From: Michael Richardson m...@sandelman.ca The CGN space seems like a very good place to use 240.0/10. A single organization often controls and specifies all equipment which will use the address space Not _exclusively_ 240/, though, because as has been pointed out numerous times, for many contemplated CGN deployments, the CPE equipment connected directly to the CGN-fronted fabric will be that already owned by the customers, and with home customers, that may cover a very, very wide stretch of manufacturers and models - i.e. whatever those customers already own. And many of them won't support 240/. As I already pointed out: I suspect that CGNs are not, by and large, targetted to entirely new customers ... as customer bases grow, some ISPs don't have enough 'public' space to give one to each customer any more, so they want to deploy CGN - and they need address space for the chunk of fabric between the CGNs and the CPEs. In other words, its mostly _existing_ customers who are about to be CGN'd. But as I previously pointed out in another message (too lazy to dig it up), I do think we should have a chunk of 240/ space as _part_ of the CGN allocation. And it needs a seperate I-D which indicates how equipement can signal that it supports 240.0/10. Returning such a address to equipment that is not prepared to receive is a *very* bad idea. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- 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: Consensus Call (Update): draft-weil-shared-transition-space-request
From: Mark Andrews ma...@isc.org And it needs a seperate I-D which indicates how equipement can signal that it supports 240.0/10. Returning such a address to equipment that is not prepared to receive is a *very* bad idea. I wasn't suggesting using general use for 240/ addresses, as endpoint names - that's a hopeless cause, there are too many things out there that can't deal with them. Who wants an address lots of people can't talk to (with, or without, a mechanism to discover explicitly that they can't talk to it)? I was suggesting them purely for infrastucture use, in (probably _very_ limited) usage domains where their visibility would be over a limited scope, one where all devices can be 'pre-cleared' for using them. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
In message 20111207223526.gj20...@besserwisser.org, =?utf-8?B?TcOlbnM=?= Nils son writes: Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-re= quest Date: Wed, Dec 07, 2011 at 11:31:11AM -0800 Quoting David Conrad (drc= @virtualized.org): Michael, =20 On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote: The CGN space seems like a very good place to use 240.0/10. =20 I believe the main driver behind this discussion is the need to deal with= deployed non-field-upgradable CPE that has issues with having RFC 1918 spa= ce being assigned on the WAN interface. I'd guess said hardware would also= likely have issues with 240/4 space being instead. =20 I believe we can narrow the problem with RFC 1918 addresses down to same or overlapping prefix on the outside as inside, rather than assuming that any use of 1918 space on the outside interface is detrimental. Does anybody know of any evidence to the contrary?=20 This is not a ISP/CUSTOMER problem. This is a ISP/CUSTOMER/WORK problem. You have the ISP using 172.16/12 You have the customer using 192.168/16 or 10/8 You have WORK using 172.16/12 Enterpises have choosen to use 172.16/12 for EXACTLY the same reasons you want ISP to use 172.16/12. CPE equipment doesn't default to that range. Both the enterprise and the ISP don't want to clash with the employee/customer. ISP's also need a big enough range that they minimise the number of times they have to re-use the address range as every re-use introduces more potential for routing leaks, mis-diagnosis, etc. In addition to all the RFC 1918 address are for *private* use. Allocating RFC 1918 address is customers not private use, so are you also planning to update RFC 1918 to permit this *new* use case. Vendor default allocations of RFC1918 to broadband router LAN interfaces are limited to nets 10 and 192.168. Does anybody know of any evidence to th= e contrary?=20 Therefore, point out a /15 from 172.16.0.0/12 and be done with it. The few conflicts arising will fall in two classes: a/ People who have knowingly changed their LAN prefix.=20 b/ Organisations large enough to use _all_ of RFC 1918 inside.=20 a means they can change again. Problem solved.=20 b means that they are large enough to be able to buy public external addresses, if they do not already posess swamp space. Problem solved. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Now I understand the meaning of THE MOD SQUAD! --I/5syFLg1Ed7r+1G Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk7f6i4ACgkQ02/pMZDM1cUZNgCgkdyeg55f8yTu/x3mxPCwFx86 EMMAoJWcaq23P1g9SQfgeUZeDqw+M3sV =nEJ/ -END PGP SIGNATURE- --I/5syFLg1Ed7r+1G-- --===0194820202636702821== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --===0194820202636702821==-- -- 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: Consensus Call (Update): draft-weil-shared-transition-space-request
On Dec 7, 2011, at 6:57 PM, Noel Chiappa wrote: I wasn't suggesting using general use for 240/ addresses, as endpoint names - that's a hopeless cause, there are too many things out there that can't deal with them. Who wants an address lots of people can't talk to (with, or without, a mechanism to discover explicitly that they can't talk to it)? I was suggesting them purely for infrastucture use, in (probably _very_ limited) usage domains where their visibility would be over a limited scope, one where all devices can be 'pre-cleared' for using them. I agree that this is an optimal scenario for near-term deployment of 240/4, and that we should pursue the conversion of class E to unicast. However, it could be compared to using RFC1918 space for such a purpose. For instance http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores discusses some of the potential issues of using RFC1918 for infrastructure links. I'd guess that 240/4 has similar issues, and perhaps additional issues that we haven't considered. Cheers, -Benson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On 12/7/11 11:39 AM, Michael Richardson m...@sandelman.ca wrote: Benson == Benson Schliesser bschl...@cisco.com writes: Benson However, there is one essential point that I'd like to Benson clarify: We need a common standard for numbering CGN NAT444 Benson deployments. Benson For NAT444 deployments of CGN, we are talking about a new Benson scope - the intermediate CGN zone network - that is Benson neither global or local. Within this scope, one cannot Benson expect end-to-end (global) address fidelity (because traffic Benson is NATted), nor can one expect forwarding to be confined to Benson a single organization (because it touches CPE etc). Okay, while this address touches the CPE, it does not cross it. In some cases, customers attach their Pcs directly to their Cable Modem (w/o a router). So, you can't exclude Pcs in this discussion. They make up a non-trivial percentage, and many don't support 240.x (My home Mac, for instance, gives me an error about first quad out of range). Benson PS - I also support turning 240/4 into unicast, as others Benson have recommended. But this will not help in the immediate Benson future timeframe, for the currently deployed equipment, Benson which is driving the need for Shared CGN Space. It may be Benson complementary, but does not reduce the need for a /10 Benson assignment. The CGN space seems like a very good place to use 240.0/10. A single organization often controls and specifies all equipment which will use the address space, and even in the cases where customers have their own equipment, a lot of it will have no problem with 240. That's not true on many cable networks. Subscribers bring their own routers, and would be responsible for upgrading/replacing them. Too many devices will not support 240, raising the risk of using this range to an unacceptable level. Also, as was pointed out in an earlier email in this thread, some backbone routers neither accept nor forward 240/4 addresses. If the IETF changed the status of 240/4 five years ago, this would possibly be worth considering. Since it didn't, it's too late now. Equipment in the field is not ready, and won't be ready fast enough for this to be a practical proposal. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ 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: Consensus Call (Update): draft-weil-shared-transition-space-request
We're requesting a /10, not a /12 or /15 (devices attached to one CGN might use the whole /15). Such an allocation would be too small for a regional CGN deployment at a larger ISP, and would likely result in double-CGN. Shared CGN Space really needs to be a /10. Second, many ISPs do not control customer home network addressing decisions. It is not feasible to tell a customer to renumber, especially when the customer is legitimately using RFC1918 space in accordance with the RFC. Unfortunately, your proposal doesn't actually solve the problem we're facing. Chris On 12/7/11 3:35 PM, Måns Nilsson mansa...@besserwisser.org wrote: Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at 11:31:11AM -0800 Quoting David Conrad (d...@virtualized.org): Michael, On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote: The CGN space seems like a very good place to use 240.0/10. I believe the main driver behind this discussion is the need to deal with deployed non-field-upgradable CPE that has issues with having RFC 1918 space being assigned on the WAN interface. I'd guess said hardware would also likely have issues with 240/4 space being instead. I believe we can narrow the problem with RFC 1918 addresses down to same or overlapping prefix on the outside as inside, rather than assuming that any use of 1918 space on the outside interface is detrimental. Does anybody know of any evidence to the contrary? Vendor default allocations of RFC1918 to broadband router LAN interfaces are limited to nets 10 and 192.168. Does anybody know of any evidence to the contrary? Therefore, point out a /15 from 172.16.0.0/12 and be done with it. The few conflicts arising will fall in two classes: a/ People who have knowingly changed their LAN prefix. b/ Organisations large enough to use _all_ of RFC 1918 inside. a means they can change again. Problem solved. b means that they are large enough to be able to buy public external addresses, if they do not already posess swamp space. Problem solved. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Now I understand the meaning of THE MOD SQUAD! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Noel Chiappa wrote: I was suggesting them purely for infrastucture use, in (probably _very_ limited) usage domains where their visibility would be over a limited scope, one where all devices can be 'pre-cleared' for using them. More generally, class E should be used for unicast only when operators are statically, without dynamic investigation, sure that all the equipments support class E. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at 08:17:47PM -0700 Quoting Chris Donley (c.don...@cablelabs.com): We're requesting a /10, not a /12 or /15 (devices attached to one CGN might use the whole /15). Such an allocation would be too small for a regional CGN deployment at a larger ISP, and would likely result in double-CGN. Shared CGN Space really needs to be a /10. The space is going to be reused several times anyway, and NAT (be it carrier, enterprise or SOHO) breaks pretty badly when session space is exhausted. It does not make sense to have much more than a, say, /16 behind each. (CGN is just NAT in a NEBS certified enclosure with an expensive support contract; the basic b0rkenedness remains.) Second, many ISPs do not control customer home network addressing decisions. It is not feasible to tell a customer to renumber, especially when the customer is legitimately using RFC1918 space in accordance with the RFC. As has been restated several times, if you use RFC1918, be prepared to renumber. Goes for everyone, including customers. Unfortunately, your proposal doesn't actually solve the problem we're facing. We are, by request, not discussing solutions (ie. larger address space) but kludges. draft-weil-shared-transition-space-request is polishing manure, not designing solutions. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hmmm ... A hash-singer and a cross-eyed guy were SLEEPING on a deserted island, when ... signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Thu, Dec 08, 2011 at 12:30:05PM +1100 Quoting Mark Andrews (ma...@isc.org): Does anybody know of any evidence to the contrary?=20 This is not a ISP/CUSTOMER problem. This is a ISP/CUSTOMER/WORK problem. You have the ISP using 172.16/12 You have the customer using 192.168/16 or 10/8 You have WORK using 172.16/12 Enterpises have choosen to use 172.16/12 for EXACTLY the same reasons you want ISP to use 172.16/12. CPE equipment doesn't default to that range. Both the enterprise and the ISP don't want to clash with the employee/customer. I have 1918 space at home, that is used at work. My VPN works. It is common knowledge that split-tunneling is detrimental to network security since so many functions rely (properly or not) on the containment to be close to perfect. In addition to all the RFC 1918 address are for *private* use. Allocating RFC 1918 address is customers not private use, so are you also planning to update RFC 1918 to permit this *new* use case. No. To me, ultimately, private equals an instance of routing policy, ie. AS number. The customer is using 1918 space in spite of not having an AS number (if they have one, they probably got fries with that and have a /24 from swampspace, case closed) and thus must adapt to the provider routing scheme. It MIGHT work with NAT. But not more than that. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Was my SOY LOAF left out in th'RAIN? It tastes REAL GOOD!! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Hi, Ron. On Dec 3, 2011, at 4:06 PM, Ronald Bonica wrote: On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. I support the assignment of an IPv4 /10 for shared CGN space. Most of my thoughts on this topic have already been expressed in draft-bdgks-arin-shared-transition-space. And anything that wasn't captured in draft-bdgks has been discussed (and re-discussed ad nauseum) this past week on the IETF mailing list. However, there is one essential point that I'd like to clarify: We need a common standard for numbering CGN NAT444 deployments. For NAT444 deployments of CGN, we are talking about a new scope - the intermediate CGN zone network - that is neither global or local. Within this scope, one cannot expect end-to-end (global) address fidelity (because traffic is NATted), nor can one expect forwarding to be confined to a single organization (because it touches CPE etc). ISPs need to use addressing within this scope that does not cause (additional) problems for their existing customers (and their customers' equipment). And in the event of an addressing conflict, operators (on both sides) need a common reference to determine who is at fault - i.e. who is responsible for fixing the problem. Of the various options, only unique GUA and/or a Shared CGN Space can be reasonably expected to meet these requirements. For the sake of conservation and operational efficiency, I recommend that we allow the assignment of a Shared CGN Space for this purpose. Cheers, -Benson PS - I also support turning 240/4 into unicast, as others have recommended. But this will not help in the immediate future timeframe, for the currently deployed equipment, which is driving the need for Shared CGN Space. It may be complementary, but does not reduce the need for a /10 assignment. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On 12/4/11 12:33 PM, Hadriel Kaplan wrote: 3) Use RFC-1918 address space. That would work for pure consumer applications, but would break things like remote employees using VPNs. I don't think that's a result we should want to happen, because it affects good-citizen Enterprises who aren't even using that ISP while their employees are using the ISP. Maybe I'm not understanding the problem you're worried about here, but as far as I can tell, remote employees using VPNs are still a problem with a new allocation: If an enterprise has two remote sites, each served by a different CGN, those two sites will get address conflicts in the new space. A new allocation doesn't solve that problem. 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: Consensus Call (Update): draft-weil-shared-transition-space-request
--On Monday, December 05, 2011 09:36 -0600 Pete Resnick presn...@qualcomm.com wrote: On 12/4/11 12:33 PM, Hadriel Kaplan wrote: 3) Use RFC-1918 address space. That would work for pure consumer applications, but would break things like remote employees using VPNs. I don't think that's a result we should want to happen, because it affects good-citizen Enterprises who aren't even using that ISP while their employees are using the ISP. Maybe I'm not understanding the problem you're worried about here, but as far as I can tell, remote employees using VPNs are still a problem with a new allocation: If an enterprise has two remote sites, each served by a different CGN, those two sites will get address conflicts in the new space. A new allocation doesn't solve that problem. Agreed. Also, as more and more organizations use kits and third-party software of various sorts to permit people to work from home via VPNs, the notion of a 'pure consumer' installation becomes more of a myth in various part of the world. Consumer applications, yes. But, from an addressing standpoint, a LAN is either pure-consumer or it isn't. There are fewer of the former now than there were when 1918 was adopted. Worse, many of those that exist today are likely to be converted in the next year or two. An addressing policy that is designed around the assumption that we can break addresses up into safe pools that then breaks when consumers put in applications that try to create VPNs is likely to be a far worse support nightmare (and one of the expensive case-by-case variety) than actually dealing with the issues, as a group, now. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
From: Chris Donley c.don...@cablelabs.com
Both draft-bdgks and RFC 6319 describe the problems with 240/4 - too
many legacy devices won't support it. ... In addition, back-office
systems would need to be able to use the same 240/4 space for network
monitoring/maintenance, billing, lawful intercept, etc.
I hear you. However, after thinking about it for a while, I still think we
ought to include a chunk of 240/ space _as well as_ some 'general use' space
(be it a /10 of that, or whatever).
My reasoning for adding a chunk of 240/ is that anytime it is suggested that
we use 240/ for some infrastructure purpose (it's clearly not feasible for
general use - too many legacy hosts), we get the same 'well, most things
won't handle it' response. Well, ya gotta start somewhere! If we never take
the first steps to making it usable, we'll never be able to take the second,
will we? And this seems as good a place as any to start...
Yes, I know, to begin with, it will not be useful. But sooner or later some
vendor will make their boxes deal with it. And when they do, with the crunch
for address space being what it is, some customer will say 'Great! This
solves my horrible problem {X}. I'll buy your stuff.' And then others will
follow.
And then 240/ will be available for _other_ infrastructure applications.
Really, with the severe crunch that's happening, we really need to figure out
how to make it available - and this seems as good a path as any.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On Sat, Dec 3, 2011 at 15:06, Ronald Bonica rbon...@juniper.net wrote: Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? No, but it is the best option and it's allocation and use will lower the pain inflicted by CGN on the Internet at large. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? The benefit of a shared space far outweighs one months worth of addresses for one RIR. Plus, it is likely that the availability of a shared CGN space will slow allocations enough to offset this one month loss. - Can alternative /10s be used? This has been stated many times already (and is contained in multiple drafts), so I'll just leave a high-level summary of our other options as a reminder: - RFC 1918 space WILL NOT be used by operators. - Globally unique space is a waste and has all the same problems as a shared /10 with the added problem of lack of standardization. - Squat space has all the same issues as a shared CGN space plus the lack of standardization plus add the complications of squatting. - 240 - All the same issues of a shared CGN space but add the complications from an explicit/intentional lack of vendor support in many of the devices in question. By contrast, further discussion of the following topics would not help the IESG gauge consensus: snip Agreed. The bottom line here is that if we remove ourselves from the religious/political debate and focus on operational realities - the choice is not a hard one. The allocation of a shared CGN space is the best thing we can do for the Internet, it's users, it's operators, it's vendors, and for IPv6 deployment as well (which is actually redundant). Cheers, ~Chris -- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf ___ 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: Consensus Call (Update): draft-weil-shared-transition-space-request
On Dec 5, 2011 7:48 PM, Chris Grundemann cgrundem...@gmail.com wrote: On Sat, Dec 3, 2011 at 15:06, Ronald Bonica rbon...@juniper.net wrote: By contrast, further discussion of the following topics would not help the IESG gauge consensus: snip Agreed. The bottom line here is that if we remove ourselves from the religious/political debate and focus on operational realities - the choice is not a hard one. The allocation of a shared CGN space is the best thing we can do for the Internet, it's users, it's operators, it's vendors, and for IPv6 deployment as well (which is actually redundant). No it might not be a hard choice, but that dont make it a good solution, just a choice of the lesser evil. Btw: If this allocation are made from any of the free available pools, not rfc1918 or 240/4, then lets us also give out a /8 from somewhere in 240/4 and lets see if it really is so d*mn hard to use this space. That might add some value for the future --- Roger J --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Sat, Dec 03, 2011 at 05:06:42PM -0500 Quoting Ronald Bonica (rbon...@juniper.net): Folks, On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because: - it is difficult. (We are choosing between the lesser of two evils.) - a lively discussion on this mailing list has not yet converged Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? No. RFC1918 will do, if done wisely. There indeed is additional (oprational) cost, but nothing that can't normally be attributed to the use of non-unique address space. Also, noone has touched on the not-too-unusual use case of one DSL, one PC where the cutomer does not attach a home router/NAT box but instead follows the instruction manual that says Connect PC to DSL modem Ethernet jack.. In that scenario, the CGN is a marginal difference technically speaking. The assignment of a previously-unicast v4 prefix in this case would cause confusion since all How-To's currently present will point out that anything non- RFC1918 is unique or Multicast. Further, if the ISP decides to use 1918 space for CGN deployment there is nothing preventing assigning several addresses (like a /28 or similar) to each customer, removing the need for customer-operated NAT boxes. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? Depends on where you are -- for me and my employers (past and present), none. We enjoy the benefits of abundant Early Registrations. If, OTOH, a new ISP can get a bunch of v4 /24's to properly dualstack important services and interfaces exposed globally, and thus be able to get off the ground using 1918 as v4 dualstack component for the rest, that is a major improvement. - Can alternative /10s be used? While the re-assignment of experimental space up above multicast allocations remains an interesting (or at least amusing) exercise in pain-shifting, the purpose here is to allow more or less orphaned customer equipment to continue working. Forcing previously- experimental address space on them is counter-productive. And, as addressed above, unicast v4 space should be used for things essential. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... I don't like FRANK SINATRA or his CHILDREN. signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Ron, On Dec 3, 2011, at 2:06 PM, Ronald Bonica wrote: - Is the reserved /10 required for the deployment of CGN? Obviously not. It isn't a question of whether CGN can be deployed, it is a question of how. As far as I can tell, lack of the a new /10 will simply mean ISPs get to make an operational decision, the result of which will either be more rapid exhaustion of the remaining IPv4 free pools or the use of already allocated space with the potential collisions it entails. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? It may reduce the likelihood that folks deploying CGN will request (and be granted) new large blocks, thereby extending the life of the remaining free pools by some (likely small, relatively speaking) amount. However, see below. - Can alternative /10s be used? Not sure what alternative means here. If the idea is to use space from 240/4, I suspect not since I believe part of the problem statement is the need to deal with old, non-field upgradable CPE, the exact boxes that are likely to have issues with trying to configure 240/4 on the WAN interface. By contrast, further discussion of the following topics would not help the IESG gauge consensus: ... - How many ISPs really want this assignment and how many don't care because they don't need it? Without knowing how many ISPs would make use of draft-weil space, it is difficult to estimate the impact on the remaining IPv4 free pools should draft-weil space not be allocated. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On Dec 4, 2011, at 11:20 AM, David Conrad wrote: It isn't a question of whether CGN can be deployed, it is a question of how. As far as I can tell, lack of the a new /10 will simply mean ISPs get to make an operational decision, the result of which will either be more rapid exhaustion of the remaining IPv4 free pools or the use of already allocated space with the potential collisions it entails. It may mean more rapid exhaustion of the free pool for a short time, but at some not-too-far-away time it will stop meaning that since the free pool will be exhausted. So that's not a long-term result of not allocating a /10, and thus the phrase either ... or used in your email does not apply. ISTM, ISPs would really be left with 4 choices: 1) Use whatever address space they have already now as this new CGN space, such that they stop advertising the space in BGP etc., and migrate all of their existing customers to a model where this previously-public address space is now private and behind CGNs. That's not a result I think we should want to happen, both because it disrupts the current working IPv4 and because it limits potential new ISPs. (it gives an advantage to legacy ISPs with lots of existing v4 addresses) 2) Squat on someone else's space or un-allocated space. I don't think that's a result we should want to happen, for obvious reasons. (I also don't think it's likely many ISPs would do this either - just noting it's possible) 3) Use RFC-1918 address space. That would work for pure consumer applications, but would break things like remote employees using VPNs. I don't think that's a result we should want to happen, because it affects good-citizen Enterprises who aren't even using that ISP while their employees are using the ISP. 4) The CGN vendors and ISPs create a CGN Forum industry association, pool money together and buy the space to use from others. I'm not sure if that's a good or bad result, but at the going rate it would ~$50 Million as someone else has mentioned. (Cerner bought Borders' for $12 per IP, and Microsoft bought some of Nortel's for about the same price per IP) I don't know if the interested parties could really get $50 Million together, nor whom they could buy it from. Perhaps they could convince one of the CGN vendors or ISPs who already have large space to part with it for a price. 4b) If one were to think evil-ly, one thing a big CGN vendor could do is use some of their own address space for *their* CGNs, and thereby have a sales advantage over other CGN vendors who weren't given big blocks in years past. I don't think that's a result we should want, either. -hadriel p.s. rant and we should really stop talking about this as a us vs. them problem, or that ISPs are the problem - they're not the cause of the problem, and are coming here for help, and they pay for their employee's expenses to be active IETF participants, as well as having been previous financial sponsors of IETF meetings. In short: they are us. *We* have a problem to solve - we can debate if it's solvable, or how to solve it, but not by blaming others. /rant ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Hadriel, On Dec 4, 2011, at 10:33 AM, Hadriel Kaplan wrote: It isn't a question of whether CGN can be deployed, it is a question of how. As far as I can tell, lack of the a new /10 will simply mean ISPs get to make an operational decision, the result of which will either be more rapid exhaustion of the remaining IPv4 free pools or the use of already allocated space with the potential collisions it entails. It may mean more rapid exhaustion of the free pool for a short time, but at some not-too-far-away time it will stop meaning that since the free pool will be exhausted. So that's not a long-term result of not allocating a /10, and thus the phrase either ... or used in your email does not apply. The either/or (and it isn't necessarily xor) applies to the decision ISPs will make should draft-weil not move forward. ISTM, ISPs would really be left with 4 choices: 1) Use whatever address space they have already now as this new CGN space, Right, this is one possible version of the 'redeploy' option I mentioned in an earlier message (the one with the $50M estimate). I would imagine the cost of doing this would be sufficiently high as to make it a non-starter, but it is indeed an option. That's not a result I think we should want to happen, both because it disrupts the current working IPv4 and because it limits potential new ISPs. (it gives an advantage to legacy ISPs with lots of existing v4 addresses) I suspect IPv4 exhaustion will be a bit more limiting to potential new ISPs than existing ISPs renumbering their existing space so they can make use of CGNs. 2) Squat on someone else's space or un-allocated space. I don't think that's a result we should want to happen, for obvious reasons. (I also don't think it's likely many ISPs would do this either - just noting it's possible) Say you are the CIO of a large ISP. If you get to decide between spending $50M or having your customers be potentially unable to communicate with (say) a relatively tiny number of ham operators (44/8) or US SIPRnet (which I suspect is against the law for your customers to communicate with) or pick your favorite block, what would be your choice? 3) Use RFC-1918 address space. That would work for pure consumer applications, but would break things like remote employees using VPNs. I thought the primary issue was the need to number the WAN interfaces of non-field-upgradable CPE that don't allow 1918 on that interface and/or in a way that doesn't collide with 1918 space used on the inside interface. Since we've seen multiple iterations of what is now draft-weil over the years, I have to assume using 1918 space isn't really an option. 4) The CGN vendors and ISPs create a CGN Forum industry association, pool money together and buy the space to use from others. Right, this is a variation of the use somebody else's space option. They wouldn't need to buy the address space (at least if they do it soon): all the RIRs except APNIC can allocate a /10 now if it is justified. Since as far as I know numbering interfaces is seen as sufficient justification, one ISP could obtain the space and simply say 'hey, this space will never be announced'. Other ISPs could then use it or not as they see fit. 4b) If one were to think evil-ly, one thing a big CGN vendor could do is use some of their own address space for *their* CGNs, and thereby have a sales advantage over other CGN vendors who weren't given big blocks in years past. I don't think that's a result we should want, either. Not sure why this would be considered 'evil'. It indeed might make business sense for a CGN vendor to do this and it is (arguably) a less inefficient approach than each CGN-deploying ISP going out and getting their own block for this purpose. My assumption is that this issue only applies to really large ISPs and that the CGN vendors for those ISPs already have sufficient existing legacy address space to do this. p.s. rant and we should really stop talking about this as a us vs. them problem, Agreed. It is, after all, one address space. Well, sort of. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Ron, Please see in-line. Chris On 12/3/11 3:06 PM, Ronald Bonica rbon...@juniper.net wrote: - Is the reserved /10 required for the deployment of CGN? No, but it simplifies operations, lowers risk, and reduces aggregate demand. If you take ARIN's current burn rate of about a /10 per month, and assume that Geoff Huston is correct that v4-v6 parity occurs in 2016, the excess demand is around 144 M addresses (since ARIN is the RIR prepared to supply this space, I'm focusing only on the ARIN region). As has previously been discussed (and will be addressed below), neither RFC1918 nor 240/4 are operationally feasible, so if Shared CGN Space is not made available, ISPs are likely to draw CPE-CGN addresses from either A) Public space. This can either come from a new RIR allocation or from existing customers. In the ARIN region, this is problematic, since address space allocations are based on 3-month need, but the CGN high-water mark is expected to come in 3 years. So, if an ISP were to roll out CGN and wanted an ARIN allocation to cover it, the ISP would have to put a larger proportion of customers behind a CGN earlier than would otherwise be justified. Similarly, if an ISP were to take addresses from existing customers, it would again need to put a higher proportion of customers behind the CGN than would be required for Shared CGN Space. B) squat space. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? A) 4 M IPv4 addresses represents about one month's allocation by ARIN (at current rates). B) It would probably lessen the run on the bank at the very end by giving ARIN justification for refusing allocations for CGN space (currently allowed by ARIN policy), possibly buying a few extra months. - Can alternative /10s be used? Not if you mean either RFC1918 or Class E. Both draft-bdgks and RFC 6319 describe the problems with 240/4 - too many legacy devices won't support it. (Including some Cisco and Mac OS X devices, among others). In the cable provisioning model, subscribers can be behind either a customer-provided router or directly attached to the CM, so we need to support both use cases (we intend the term CPE in draft-weil to cover both). In addition, back-office systems would need to be able to use the same 240/4 space for network monitoring/maintenance, billing, lawful intercept, etc. Regarding RFC 1918, as we described in draft-weil, RFC 1918 space would only be operationally viable if: The Service Provider knows that the CPE/NAT works correctly when the same [RFC1918] address block is used both on its inside and outside interfaces, and, the Service Provider knows that the [RFC1918] address block that it uses to number interfaces between the CGN and CPE is not used on the subscriber side of the CPE. Since the ISP in many cases does not control the CPE device selected by the customer, nor the address range assigned by the customer to internal systems, this is fraught with risk. Given that a single support call costs more than the revenue generated by a subscriber in a month, I think ISPs would need to see 99.9% assurance that such an address range would not cause conflict with customer devices/address ranges before they could begin to consider 1918 space. (note: since Shared CGN Space would come from unassigned addresses, the likelihood of a conflict is significantly smaller, and avoidance of the new Shared CGN Space could be added to Terms of Service in a way that RFC1918 space cannot). As I mentioned above, the viable alternatives to Shared CGN Space are public allocations or squat space; IMO, both are more operationally problematic than Shared CGN Space, and both share the same problems wrt 6to4. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On Dec 4, 2011, at 2:48 PM, David Conrad wrote: 2) Squat on someone else's space or un-allocated space. I don't think that's a result we should want to happen, for obvious reasons. (I also don't think it's likely many ISPs would do this either - just noting it's possible) Say you are the CIO of a large ISP. If you get to decide between spending $50M or having your customers be potentially unable to communicate with (say) a relatively tiny number of ham operators (44/8) or US SIPRnet (which I suspect is against the law for your customers to communicate with) or pick your favorite block, what would be your choice? I was trying to be kind, but you're right that makes a lot of sense. I hadn't considered the 44/8 ham operator block, but that one is kind of a hog waiting to be slaughtered... it's not kosher but they probably wouldn't squeal too much. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Ron, Folks, On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because: - it is difficult. (We are choosing between the lesser of two evils.) - a lively discussion on this mailing list has not yet converged Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? I would say for the sanity of the sum of all CGN deployments a common space would be most sound. It would allow operators to build common rules on managing this CGN zone space. These rules include how information is propagated to and from the local ISP (I.e. BGP, DNS Information etc) and how internal security policies are built. This is important since many ISPs will likely be using part (or all) of the RFC1918 space for other functions which include management zones, back-office systems and the like. Such an allocation would also help avoid any conflicts with RFC1918 space used by customer networks. Although there may be portions of the RFC1918 space that *may * be open in each network, the space is not likely going to be the same (different parts of the range if any) which makes it hard to build common rules and for vendors to accommodate this if required. Should operators need to use squat (should the space not be allocated), this would potentially resolve the address conflict issues, but would promote bad form as many may choose space which can potentially be used on the Internet in the future (making life bad for customers). It would also make building common rules/filers between ISPs difficult to impossible. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? This is a question better answered by the RIR themselves. I hear much speculation from those on the list, but I don't think anyone here can authoritatively answer this question. Also, the effect of the allocation should be commented on from a technical position and not presumed market impacts (if any) since this again is speculation. Economics of the IPv4 address markets should be left out of the technical discussion (in my opinion). If the IPv4 address pool is so important and we are so concerned about the price, then one should talk to the 38 (by my count) of private companies and defence organizations which have /8s and ask them for their space back (I will assume this is not feasible) - Can alternative /10s be used? As noted, some have suggested parts of the RFC1918 space, but operators have noted the challenges with this. 240/4 would require upgrades to some of the vary devices (CPEs) which are of concern to us. A part of the legacy assigned space would work. Not sure how feasible that is. I guess if not allocated (the /10), squatting will have the same effect (with all the chaos along with it). Regards, Victor K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
