Subject: Re: Consensus Call: draft-weil-shared-transition-space-request

From: [email-masked] (Noel Chiappa)
Date: Sat, 3 Dec 2011 19:49:51 -0500 (EST)

> From: Doug Barton <[email-masked]>

    > Doing the allocation will postpone the pain, until such time as those
    > folks that we keep hearing have exhausted all of 1918 internally catch
    > on, and then start using this block as 1918 space.

But if any particular site uses this space for either i) 1918-type uses, or
ii) the intended use, do we care? As long as having some sites use it for
1918 purposes doesn't harm the ability of _other_ sites to use it for the
purposes for which it is intended, I don't see the harm (although maybe I'm
missing something).

	Noel

---

From: Doug Barton <[email-masked]>
Date: Sat, 03 Dec 2011 17:18:06 -0800

> purposes for which it is intended, I don't see the harm (although maybe I'm

Yes, you're missing something. :)

The argument from the proponents goes something like this (refined way
down, ignoring subtleties, etc.):

"We cannot use 1918 for CGN because some customers use it internally,
and they have CPEs that break if the same block is used on both sides.
Therefore, we need a new, !1918 block for our side of the CGN."

The problem with that argument is that there is nothing to stop
customers from using the new block internally (and everyone involved so
far has recognized that they inevitably will do this). Therefore the
stated purpose of allocating the block is not going to be effective.

Or, put another way, because the pain of dealing with customers who are
using your CGN block internally is going to exist anyway, why not just
use the least popular 1918 block(s) for this purpose and deal with the
conflicts when they arise?

Doug (but you're in good company)

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: David Conrad <[email-masked]>
Date: Sat, 3 Dec 2011 18:41:14 -0800

On Dec 3, 2011, at 5:18 PM, Doug Barton wrote:
> far has recognized that they inevitably will do this). 

Hmm.  So you're saying a customer behind a CGN is going to reconfigure their CPE to use this new !1918 block in contravention to explicit statements in the specification and then complain to their ISP when said reconfiguration conflicts with the use of the CGN the customer is now behind?  This seems like a bit of a stretch to me. My guess is that the number of folks who would even be aware of the new !1918 space would be quite small and of those, the ones who would need to reconfigure to use that space would be infinitesimal so this argument against the new !1918 space seems a bit specious.

Another possible reason 1918 space can't be used: the large scale ISPs interested in deploying CGN have already used up all of the 1918 space, thus to deploy CGN with minimal disruption to their deployed infrastructure, they need another block.  Anything else would require non-trivial renumbering at undoubtedly high cost.

In any event, I'm still trying to figure out the problems that would be created if the new !1918 block were not allocated. It seems to me that ISPs deploying CGN who are unable to use existing 1918 space would be faced with the following options:

a) use normal space
b) use somebody else's space
c) redeploy stuff 

Option (a) simply means accelerating IPv4 free pool exhaustion.  To me, this implies moving the date when ISPs have to pay significantly increased costs (going rate is now about US$12/address so a /10 would mean US$50M) to obtain IPv4 addresses forward a year or two.  Interestingly, getting normal space now would probably pay off in the longer term as that space will likely be quite in demand after free pool exhaustion.

Option (b) used to be SOP with a number of larger ISPs, although I gather at least some of them have learned the risks of doing this the hard way. From a pure business perspective, while unappealing, if the choice is between paying $50M or not, I suspect finding a sparsely used /10 wouldn't be that hard (I imagine everyone here has their favorite blocks they wouldn't mind seeing sacrificed), but it does obviously come with risks.

Option (c) is simply inevitable one way or another, but pushing it forward is probably viewed as extremely difficult/expensive in the near term, hence the preference for either new !1918 space or going with options (a) or (b).

My impression is that the folks proposing draft-weil are trying to be good net citizens and not use space inefficiently. Failure to pass draft-weil will simply mean they'll go with option (a) or (b) -- I'd guess the moment draft-weil is shot down, the RIRs will start getting very large and perfectly justified address requests and the day of complete IPv4 free pool exhaustion will jump forward.

What am I missing?

Thanks,
-drc

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Dec 2011 21:56:43 -0500

I think this is indeed all about economics. Role acting ISP for a minute: From a consumer ISP perspective asked to weigh in here, there are two options beyond the ones mentioned below:

(1) They can support the new /10, which doesn't cost them anything and reduces the chance that existing NAT boxes cause problems to near-zero.

(2) They can try to find some dusty corner of the existing RFC 1918 space, but won't really be able to predict what happens until the phone lines light up. When they do, they have to tell grandma to log into their NAT box and type in a new address range.

From an ISP perspective, why would they ever choose (2)?

I don't see how we can eliminate the risk of (2) to essentially zero or even estimate it accurately. (The typical DNS root "leakage" experiments, such as the WIDE report, may miss exactly those devices that are in that dusty corner; it seems to measure "broken" devices, rather than compliant devices.)

We don't necessarily have to care about the support costs for ISPs, but the question is whether the total societal value of having this /10 be used for "regular" users exceeds the support cost (and the associated consumer aggregation), which is pure deadweight loss. I don't know if there's a good way to estimate this.

Henning

On Dec 3, 2011, at 9:41 PM, David Conrad wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Doug Barton <[email-masked]>
Date: Sun, 04 Dec 2011 13:13:39 -0800

On 12/3/2011 6:41 PM, David Conrad wrote:
>> "We cannot use 1918 for CGN because some customers use it
>> internally, and they have CPEs that break if the same block is used
>> on both sides. Therefore, we need a new, !1918 block for our side
>> of the CGN."
>> 
>> customers from using the new block internally (and everyone
>> involved so far has recognized that they inevitably will do this).
>> 
> 
> Hmm.  So you're saying a customer behind a CGN is going to
> reconfigure their CPE to use this new !1918 block in contravention to
> explicit statements in the specification and then complain to their
> ISP when said reconfiguration conflicts with the use of the CGN the
> customer is now behind? 

No, I explained the likely path to enterprises using this space in a
different message. A combination of already having exhausted all/most
1918 space internally, and not being behind a CGN when the changes are
made. And no, I don't expect it to happen in the short term, my point is
that it's incredibly likely to happen down the road as the CGN nonsense
drags on.

> This seems like a bit of a stretch to me. My
> guess is that the number of folks who would even be aware of the new
> !1918 space would be quite small and of those, the ones who would
> need to reconfigure to use that space would be infinitesimal so this
> argument against the new !1918 space seems a bit specious.

The larger enterprises which are likely to have exhausted the 1918 space
internally are likely to have more clued-in network folks who would be
aware of the new alternative.

Did you see the message where I pointed out that this is, in all
likelihood, a 90/10 problem?

> Another possible reason 1918 space can't be used: the large scale
> ISPs interested in deploying CGN have already used up all of the 1918
> space, thus to deploy CGN with minimal disruption to their deployed
> infrastructure, they need another block.  Anything else would require
> non-trivial renumbering at undoubtedly high cost.

I think to some extent you're right about this, but that reduces the
current request in essence to "We need another 1918 block," which the
IETF has already rejected, has it not?

> In any event, I'm still trying to figure out the problems that would
> be created if the new !1918 block were not allocated. It seems to me
> that ISPs deploying CGN who are unable to use existing 1918 space
> would be faced with the following options:
> 
> a) use normal space b) use somebody else's space c) redeploy stuff

d) Use 1918 space other than 192.168.[01]/24 for 90% of customers, deal
with one-offs for the rest.

> Option (a) simply means accelerating IPv4 free pool exhaustion.  To
> me, this implies moving the date when ISPs have to pay significantly
> increased costs (going rate is now about US$12/address so a /10 would
> mean US$50M)

... which is another reason I'm opposed. Like you, I recognize the
monetary value of the block, and am opposed to giving a US$50M gift to
the grasshoppers who've fiddled the summer away.

[snip]

> My impression is that the folks proposing draft-weil are trying to be
> good net citizens and not use space inefficiently. Failure to pass
> draft-weil will simply mean they'll go with option (a) or (b) -- I'd
> guess the moment draft-weil is shot down, the RIRs will start getting
> very large and perfectly justified address requests and the day of
> complete IPv4 free pool exhaustion will jump forward.

I understand this line of argument, I just don't agree with it.

Doug

--

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Dec 2011 13:51:28 -0800

Doug,

> with one-offs for the rest.

I am making the assumption that the folks who have proposed draft-weil are sufficiently competent to have ruled out the trivial/obvious solutions.

> the grasshoppers who've fiddled the summer away.

Err, no. Free pools of IPv4 addresses still exist. If draft-weil is rejected, it will mean ISPs who feel the need for the space draft-weil proposes will be forced to either request space from the RIRs or use space that has already been allocated.  Since addresses are essentially free for ISPs at the scale we're discussing, I don't see any reason they'd run the risk of using squat space. I also suspect is it wildly unlikely that those ISPs will resort to the existing markets for the space unless the RIRs reject their requests (and while I haven't looked recently, I don't think there would be policy for justification for such a rejection).  The implication here is that rejection of draft-weil will cause _others_ to feel the impact of IPv4 exhaustion soon rather than later, not the ISPs you feel should be punished.  

Whether or not accelerating the exhaustion of IPv4 is a good thing is likely a matter of perspective, however we need to be clear about who will be impacted.

>> Failure to pass

You don't agree with which part?

Regards,
-drc

---

From: Doug Barton <[email-masked]>
Date: Sun, 04 Dec 2011 14:00:05 -0800

> I am making the assumption that the folks who have proposed draft-weil are sufficiently competent to have ruled out the trivial/obvious solutions.

I admire your optimism. :)

More seriously, the impression I've gathered from various discussions is
that the 90/10 model is viable, but it's not the first choice because
the 10 part involves customer service work that those interested in
deploying CGN would like to avoid in order to protect their margins. I'm
not sympathetic.

And if that doesn't fully answer your "Which part don't you agree with?"
question, I doubt that even a significant portion of ISPs are going to
use routable addresses internally for CGN as the value of those
addresses for their intended purpose is only going to increase, and they
will still need to be able to number publicly facing things after the
RIRs have exhausted their supply.

Doug (not their own, anyway)

--

---

From: Chris Donley <[email-masked]>
Date: Sun, 4 Dec 2011 20:10:08 -0700

[CD] Really?  10% of customers having problems is a viable model?  Let's do the math here.  Consider a 10M subscriber ISP. Your breakage model (10%) would generate at least 1 M support calls (some people may call more than once).  Let's say a support call costs $50 (I don't know the exact cost, but I think this is close), so the cost of supporting a 10% failure case will be close to the $50M you keep quoting (multiply this by the number of affected ISPs).  What do you think an ISP will do if faced with this option and no Shared CGN Space? Select an IETF-specified RFC1918 block of addresses and deal with $50M of support costs plus 1M upset subscribers?  Acquire addresses from the RIR (or from an address broker)?  Or squat on someone else's space?

[CD] So you're really arguing for squat space?  I have a real problem with that.  I know people are already doing it, but I think it sets a bad precedent and increases risk of interoperability problems across the Internet. I believe the IETF has a vested interest in discouraging address squatting, and should act accordingly.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 4 Dec 2011 19:24:12 -0800

On Dec 4, 2011 7:10 PM, "Chris Donley" <[email-masked]> wrote:
> [CD] Really?  10% of customers having problems is a viable model?  Let's
do the math here.  Consider a 10M subscriber ISP. Your breakage model (10%)
would generate at least 1 M support calls (some people may call more than
once).  Let's say a support call costs $50 (I don't know the exact cost,
but I think this is close), so the cost of supporting a 10% failure case
will be close to the $50M you keep quoting (multiply this by the number of
affected ISPs).  What do you think an ISP will do if faced with this option
and no Shared CGN Space? Select an IETF-specified RFC1918 block of
addresses and deal with $50M of support costs plus 1M upset subscribers?
 Acquire addresses from the RIR (or from an address broker)?  Or squat on
someone else's space?
> [CD] So you're really arguing for squat space?  I have a real problem
with that.  I know people are already doing it, but I think it sets a bad
precedent and increases risk of interoperability problems across the
Internet. I believe the IETF has a vested interest in discouraging address
squatting, and should act accordingly.

The ietf did act. It is called ipv6.

And, they underscored that point by not rejecting various past attempts at
expanding private ipv4 space like 240/4.

Cb

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 4 Dec 2011 19:27:44 -0800

On Dec 4, 2011 7:24 PM, "Cameron Byrne" <[email-masked]> wrote:
> > [CD] Really?  10% of customers having problems is a viable model?
 Let's do the math here.  Consider a 10M subscriber ISP. Your breakage
model (10%) would generate at least 1 M support calls (some people may call
more than once).  Let's say a support call costs $50 (I don't know the
exact cost, but I think this is close), so the cost of supporting a 10%
failure case will be close to the $50M you keep quoting (multiply this by
the number of affected ISPs).  What do you think an ISP will do if faced
with this option and no Shared CGN Space? Select an IETF-specified RFC1918
block of addresses and deal with $50M of support costs plus 1M upset
subscribers?  Acquire addresses from the RIR (or from an address broker)?
 Or squat on someone else's space?
> And, they underscored that point by not rejecting various past attempts
at expanding private ipv4 space like 240/4.

Sorry. S/not rejecting/rejecting/

Cb

---

From: "George, Wes" <[email-masked]>
Date: Mon, 5 Dec 2011 13:02:21 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne

> The ietf did act. It is called ipv6.

[WEG] <sarcasm> thanks for that wonderfully relevant and technical rebuttal. I'm so glad we've stopped debating philosophy and religion in this thread and gotten down to solving technical problems. I'll be sure to tell all of my customers (and my shareholders, for that matter) that when they call to ask why their new internet-enabled TV, Xbox Live/PSN, Skype, etc doesn't work on my IETF-approved (IPv6-only) Internet service. </sarcasm>

I don't know how much clearer I can make this, so I'll keep repeating it until it hopefully sinks in:
Independent of whether we have any left, continued support for IPv4 in the home and enterprise is *non-negotiable*, no matter how many people stand atop the IETF soapbox and decree that it MUST be otherwise because IPv6 exists. I would also like it to be different, but there are a *lot* of stars that have to align before it actually is, most of which are not in my control. It's extraordinarily unproductive to vilify a group of operators as the singular scapegoat for IPv6's failure to generate critical mass when all they're trying to do is keep their network running and their customers happy, especially since they're simultaneously deploying IPv6, not using CGN to avoid it as folks on this list seem so quick to assume. If you have a way to convince my customers (or anyone else's) that they don't need IPv4 anymore, be my guest.

Until then, let's stick to solutions to the actual problem, shall we? Saying that IPv6 is a solution to an IPv4 CGN implementation problem is like saying that a railroad car is a perfectly acceptable alternative to renting a truck to move the contents of my house across town without considering whether both my source and destination are in reasonable proximity to the railroad tracks. Or worse yet, saying that I shouldn't be moving house in the first place because trucks are scarce and less efficient than rail cars.

>
> And, they underscored that point by rejecting various past attempts at expanding private ipv4 space like 240/4.

 [WEG] Every argument I've ever heard regarding 240/4 was related to the difficulty of ensuring that it was going to work *everywhere* just like the rest of the currently allocated IPv4 space. It's similar to the problems associated with going to CIDR, but the installed base is much, much larger. The concern was that most, if not all router and host stacks would have to be updated to make it work. Even if it was only commenting out a few lines of code, that was viewed as a virtual impossibility, making it impractical to consider releasing the space for general use. I'm disappointed that the space wasn't simply released (even as additional private/experimental space) with the caveat that it may not work on old equipment, and then allow the market to decide how important it was to fix such equipment, even if just for specific use cases rather than globally routable space.
IPv6 figured into the discussion, but only as a follow-on to the above. That is, it makes far more sense to expend efforts to ensure good support for IPv6 if we're proposing modifying the host stacks of lots of devices, as well as the idea that by the time we fixed 240/4, IPv6 would be well-deployed, and everyone would have their own personal 128 bit unicorn to ride, making this a case of too little too late. Depending on how far back in time you rewind, I think at least that latter point has been proven wrong repeatedly, and subsequent attempts to cut our losses and try to fix a previous poor assumption have been unsuccessful.
I think that when people look back on the IPv4 to IPv6 transition, 240/4 will be a great example of IETF's hubris and failure to use all of the tools available to them in the name of upholding some misguided sense of principles (no matter how noble they might be) or forcing people to do it our way because there's no way that we could be wrong. I would still support releasing 240/4, but I don't think that it's a solution for this problem.

Wes George

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.

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Dec 2011 10:31:39 -0800

Wes,

On Dec 5, 2011, at 10:02 AM, George, Wes wrote:
> Independent of whether we have any left, continued support for IPv4 in the home and enterprise is *non-negotiable*,

True, however as I understand it, this isn't the issue.  IIUC, the problem isn't what happens in the home and enterprise, it is what happens on the WAN side of old non-upgradeable CPE when connected via CGNs.  

> Saying that IPv6 is a solution to an IPv4 CGN implementation problem is like saying ...

I'm guessing part of the issue here is folks appear to be talking past each other.  It might be helpful to be explicit about what your view of the "IPv4 CGN implementation problem" is. For example, IPv6 _could_ be a solution if both the CPE and the CGN supports IPv6 and a way to tunnel v4 through v6 (no idea if anyone does this).

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Dec 2011 09:47:05 +1100

In message <[email-masked]>, David Conrad
 writes:
> True, however as I understand it, this isn't the issue.  IIUC, the problem is
> n't what happens in the home and enterprise, it is what happens on the WAN si
> de of old non-upgradeable CPE when connected via CGNs.  
> 
> I'm guessing part of the issue here is folks appear to be talking past each o
> ther.  It might be helpful to be explicit about what your view of the "IPv4 C
> GN implementation problem" is. For example, IPv6 _could_ be a solution if bot
> h the CPE and the CGN supports IPv6 and a way to tunnel v4 through v6 (no ide
> a if anyone does this).
> 
> Regards,
> -drc

It's called DS-Lite and the IETF is working towards getting it added
to the IPv6 CPE Router profile.   Unfortunately it requires a CPE
that supports IPv6 or is upgradable to support IPv6 and most existing
CPE routers don't fall into either of those categories.

This is primarly about getting existing equipment to work well with
CGNs without breaking everything else and address conservation.

Adding a address range as non-public to existing equipment is a lot
easier than adding IPv6 so that you can use DS-Lite.  Much CPE
equipment doesn't have the flash capacity to do the later.  The
former is trival provide the company that supplied the fireware is
still in business.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Doug Barton <[email-masked]>
Date: Mon, 05 Dec 2011 15:02:34 -0800

On 12/05/2011 10:02, George, Wes wrote:
> Independent of whether we have any left, continued support for IPv4 in the home and enterprise is *non-negotiable*

In case it isn't clear, and in spite of my snarky comments, I'm not
suggesting that IPv4 shouldn't be supported. I'm not even saying that
CGN shouldn't be done. What we're discussing is *how* it should be done,
and whether or not a new allocation is necessary to do it.

Doug

-- 

		[^L]

---

From: Doug Barton <[email-masked]>
Date: Mon, 05 Dec 2011 18:47:19 -0800

On 12/04/2011 19:10, Chris Donley wrote:
> 
> More seriously, the impression I've gathered from various discussions
> is that the 90/10 model is viable, but it's not the first choice
> because the 10 part involves customer service work that those
> interested in deploying CGN would like to avoid in order to protect
> their margins. I'm not sympathetic.
> 

I should have inserted the word "technically" in there to make my
meaning more clear. Sorry about the confusion.

> model (10%)

Please note, that's a total WAG. My gut is that the actual amount of
breakage will be substantially less, especially for an ISP that deals
primarily with the SOHO market.

> would generate at least 1 M support calls (some people
> may call more than once).  Let's say a support call costs $50 (I
> don't know the exact cost, but I think this is close), so the cost of
> supporting a 10% failure case will be close to the $50M you keep
> quoting (multiply this by the number of affected ISPs).  What do you
> think an ISP will do if faced with this option and no Shared CGN
> Space? Select an IETF-specified RFC1918 block of addresses and deal
> with $50M of support costs plus 1M upset subscribers?  Acquire
> addresses from the RIR (or from an address broker)?  Or squat on
> someone else's space?

Thank you for confirming publicly that the issue here is not a technical
one, but rather that the ISPs would prefer not to bear the costs of
dealing with the problem that they helped create.

> And if that doesn't fully answer your "Which part don't you agree
> with?" question, I doubt that even a significant portion of ISPs are
> going to use routable addresses internally for CGN as the value of
> those addresses for their intended purpose is only going to increase,
> and they will still need to be able to number publicly facing things
> after the RIRs have exhausted their supply.
> 
> [CD] So you're really arguing for squat space?

Certainly not. I think I've made my position on the "right" way to
handle this issue perfectly clear.

> I have a real problem
> with that.  I know people are already doing it, but I think it sets a
> bad precedent and increases risk of interoperability problems across
> the Internet. I believe the IETF has a vested interest in
> discouraging address squatting, and should act accordingly.

If it's already being done then we've got "running code," right? :)

More seriously, it sounds to me like the most persuasive argument in
favor of doing the new allocation boils down to simple extortion. "Give
us a $50,000,000 'gift' or we'll do bad things to the intahrnetz."

Doug

-- 

		[^L]

---

From: Greg Daley <[email-masked]>
Date: Tue, 6 Dec 2011 10:54:34 +1100

Hi Mark, 

> equipment doesn't have the flash capacity to do the later.  The former
> is trival provide the company that supplied the fireware is still in
> business.
> 

I'm mixing this conversation with the discussion on Class E, because I think that your responses are perhaps less true if the address space is sourced from that block.

I would contend that attempts to use non-traditional (Class A/B/C) addresses will not be trivial for two reasons: 

Firstly there are inherent assumptions in the uses of particular address classes which can be littered through code.

This is a similar issue to the signed-integer time_t issue (though perhaps simpler, still not trivial).

Additionally, host communicating with address classes outside the predefined unicast set may not be able to reliably connect to older IPv4 devices, or devices on specific networks (e.g. with existing Bogon filters).  

Class E relies upon the endpoint understanding the format and purpose of the address in a similar fashion to IPv6.

>From my point of view, CGNs and Class E usage are part of a continuum of IPv4 address quality degradation.  I'm not against these addresses being used, but would seek to ensure that any uses of addresses in this fashion reflects the current internet environment, and doesn't require engineering changes on third party, legacy devices.

Sincerely,

Greg Daley

---

From: Chris Donley <[email-masked]>
Date: Tue, 6 Dec 2011 13:47:19 -0700

>primarily with the SOHO market.

So the word from the Service Provider community is that until someone can
prove that the level of breakage is sufficiently low, the risks associated
with the use of RFC1918 space are unacceptably high.  I doubt many Service
Providers are willing to bet on your gut.
>dealing with the problem that they helped create.

I don't know where to begin with this one.  Of course this is a policy
discussion.  IMO, it would be better resolved within the RIR community,
which is responsible for address policy.  In fact, we did go to ARIN and
there was consensus to recommend Draft Policy 2011-5 to the ARIN Board.
However, the IAB instructed ARIN to seek IETF guidance before executing
2011-5, so here we are. Since this is a policy decision, the IETF
community gets to weigh in on how many addresses get reserved for CGN
space, and the technical/operational ramifications of such action.  If we
reserve Shared CGN Space, the size of the block is 4 M addresses.  If ISPs
acquire their own, the demand is somewhere around 30-40x that (at least in
the ARIN region) - a /10 is about 1 month's allocation. However, due to
imminent exhaustion, the amount of space that can be allocated for CGNs
before the free pool runs out is unclear, but somewhere between 4M and
150M addresses (again, within the ARIN region).

>From a technical/operational perspective, I believe that Shared CGN Space
is preferable to an uncontrolled range such as public space or squat
space, as operators and equipment vendors can work around problems with
6to4 introduced by CGN. It is also preferable to Class E space, as many
pieces of equipment do not support 240/4. Finally, from an operational
perspective, it is preferable to RFC1918 space because it will not be in
conflict with existing customer addresses.

BTW, I think your $50M argument misses the mark. Since four of the five
RIRs still have address space available, ISPs can request addresses e.g.
>From ARIN within their existing fee structure, provided they have
justification.  Given the impending IPv4 exhaustion, I don't expect ISPs
will have a problem demonstrating need.
>If it's already being done then we've got "running code," right? :)

And some Chevy Volts have been known to ignite. Running code should not be
the only justification.
>us a $50,000,000 'gift' or we'll do bad things to the intahrnetz."

Shared CGN Space is not a gift, and it's not extortion.  It's a policy
discussion as to how best to manage the remaining IPv4 resources.  ISPs
need (non-unique) addresses to go behind the CGN. They have stated that
for operational reasons, they won't use RFC1918 or 240/4 space.  That
leaves three options:
A) Public space.  Aggregate demand is somewhere around 150M addresses in
N. America, larger when you consider the rest of the world.
B) Shared CGN Space - a far smaller pool, shared amongst the ISPs, and
easiest of the three to fit into operations.
C) Squat Space

As to agency, we made this request to ARIN, the holder of the address
space, and the ARIN community reached consensus that this is an
appropriate use of IPv4 resources.  We have a willing 'giver' and a group
of willing 'recipients', and we have clearly spelled out as best we can
the tradeoffs among the available options. IMO, Shared CGN Space is the
best of the available options for the reasons previously explained: it's
limited, it's defined, and it's (operationally) predictable.

Chris

---

From: "George, Wes" <[email-masked]>
Date: Tue, 6 Dec 2011 17:13:04 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Doug Barton
>
[WEG] Thank you for confirming publicly that you'd prefer to preach at/blame ambiguous entities ("the ISPs") for perceived past sins as a way to make their problem seem illegitimate.
Yes, ISPs would rather not make a bad situation worse. We're already bearing costs to deploy IPv6, and eventually will be bearing the costs of deploying and supporting CGN no matter how distasteful we find it. We'd rather not add additional CGN breakage to the mix. This is primarily because we want our customers to be happy, and broken customers != happy customers. Yes, broken customers have associated support costs that we'd rather not pay, but that's secondary. What's mystifying and frustrating me is that some folks in the IETF refuse to believe us when we say that based on what *we* know about *our* networks and the CPE that *our* customers use, use of 1918 or squat space will be worse. You've made it clear that you don't think that the 90/10 problem is a large enough problem to justify a separate allocation, and it seems unlikely that anyone will convince you otherwise, apparently because this is somehow someone's fault and they should take responsibility for it. I'm not sure what else I can say here. I'd love for you to be right and it's not a problem, but I'm not willing to stake my job on it. Are you?

> us a $50,000,000 'gift' or we'll do bad things to the intahrnetz."
[WEG] Really? Solutions to operator problems = extortion? Glad to see that discourse here has degenerated to same extent it has in politics - when all else fails, resort to hyperbole, FUD, and namecalling...
And we wonder why we can't get better operator participation and representation here...

Wes George