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

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 1 Dec 2011 20:24:01 +0000

On 29 Nov 2011, at 18:54, Ronald Bonica wrote:
> I think that our time would be used much more productively if we discussed whether to make the allocation or not. The proposed status of the document is a secondary issue.

yes, it is, and yes, we should.

I've slept on it, but it's no good.  Ultimately, here is how it works: there are stupid people, organisations and ISPs who will resist all common sense and do the wrong thing no matter what.  It is in our best interests if they do the wrong thing at the cost of the least inconvenience to everybody else involved when that is at all possible.

IPv4 is now practically dead.  Saving it is a waste of time.  It has market value in its reduced form; let those of us who know how to exploit it to the last do so.  It does not matter.  It is seppuku to take no action on IPv6.  Nobody here should be applying their principles to the contrary in standards.  A lasting strategy to keep what's left of IPv4 is now purely transitional; no new entrants will want or need full IPv4 access, at the expense of every other legitimate user, even in reduced form, but especially not the grasshoppers who will no doubt foolishly try to create market differentiation.  And when they do, they can make their case to the regional registries, using only the address space that is needed, and benefiting everybody.  Wasting little drops of ARIN's resources with this allocation, by extension, is also no problem to the "Hastening" of IPv6 deployment; the space is used, whichever way, and to the same effect.  Artificially created scarcity through non-provision of private space will still result in the creation of private spaces and lack of addresses.  ISPs will be left communicating their incompetence in either case.  Later, we can watch the live executions and tortures of management behind the IPv4 crisis.  Just now, though, IPv4 is a market requirement for everybody.  Simple as.  We must provide.

Cheers,
Sabahattin

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 1 Dec 2011 13:05:25 -0800

I will add one more concern with this allocation.

IPv4 address allocation is a market (supply exceeds demand in this
case), and thus a strategic game (like chess) to gather limited
resources .

We have known for a long time how IPv4 was not an acceptable long term solution.

We have known for a long time that IPv6 is the only path forward for a
growing internet (more people online, more devices connected, up and
to the right...)

This allocation is changing the rules of the game in the last few
minutes (IANA and APNIC are already out...) and is dubiously blessing
an Internet model based on CGN.

Changing the rules of the game towards the end to manipulate the
outcome is seldom acceptable, regardless of the context.  AFAIK, there
have been no extenuating circumstance that have dictated a need for a
change.  IPv4 did not magically run out.  My favorite IPv4 risk
artifact should be familiar to the draft authors or other people in
the ARIN region:

https://www.arin.net/knowledge/about_resources/ceo_letter.pdf

I understand how this allocations benefits folks in the short run, and
i promise to use this allocation to my benefit  (better than squat
space, right?!).  But, at the macroscopic level at which the IETF,
IESG, and IAB should be working, this is just changing the rules of
the game at the last minute because some players don't like the
outcome, even though this outcome (ipv4 is out, need to use v6)  has
had 10+ years of runway.

I do not believe this is a positive sum game where this allocation is
made and everyone wins.  I do believe IPv6 loses (CGN vs v6
investment*, urgency, lines on strategy diagrams...) if this
allocation is made, and i do not think it is acceptable to change the
rules of the game in the final moments because the outcome is costly
for some.

Cameron

*i already have the link to your press release that your lab is ipv6
enabled, thanks!

---

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Dec 2011 14:27:20 -0800

Notes below.

On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick <[email-masked]> wrote:

> **
> Daryl,
>
> The problem described in the draft is that CPEs use 1918 space *and that
> many of them can't deal with the fact that there might be addresses on the
> outside interface that are the same as on the inside interface*. The claim
> was made by Randy, among others, that only 192.168/16 space was used by
> such unintelligent CPEs. I believe I have seen the claim that 10/8 space is
> also used in unintelligent equipment that can't deal with identical
> addresses inside and outside. Is there reason to believe that within the
> ISP network / back-office etc. that there is equipment that can't deal with
> 17.16/12 space being on both the inside and outside? I haven't seen anyone
> make that specific claim.
>
> If we know that 172.16/12 used both inside and outside will break a
> significant amount of sites that CGNs will be used with, we can ignore this
> argument. But if not, then let's rewrite the document to say that CGNs
> should use 172.16/12 and that any device that wants to use 172.16/12 needs
> the ability to deal with identical addresses on the inside and the outside
> interface. Of course, all equipment should have always been able to deal
> with identical addresses inside and outside for all 1918 addresses anyway.
> But if we think the impact of using 172.16/12 for this purpose will cause
> minimal harm, then there's no compelling reason to allocate new space for
> this purpose.
>
> pr
>
>
I wrote a response to Brian's original statement then deleted it because I
assumed others would ignore it as clearly last minute and ill-researched.
Apparently, that was wrong.  There are enterprises that currently use
172.16/12.  (There are enterprises which use every tiny piece of RFC 1918
space.)  *Any* piece of the current RFC 1918 space you attempt to define as
being used for this will conflict *somewhere*.  Anyone who happened to
chose this for an enterprise deployment and gets stuck behind a CGN would
be forced to renumber, in other words, because of this statement.  That is,
if they actually followed the statement--they're much more likely to work
with the CGN operator to use squat space on the CGN instead, since that's
the existing way of avoiding this pain.

Rubbing my crystal ball real hard, in other words, I predict that the
consequences of assigning a piece of existing RFC 1918 space to this at
this late date will have the same consequences as assigning no space at
all, with the addition of a tiny increment of confusion among those souls
who happen to read the RFC and briefly think it reflects reality.

Either allocate new space or reject; the middle ground of assuming that
some part of RFC 1918 can be safely allocated for this should not be
considered as an option.

My personal opinion, not that of my employer, spouse, child, or the man on
the street.

regards,

Ted

>
> On 11/30/11 3:04 PM, Daryl Tanner wrote:
>
> It's not just about the CPE devices and customer LANs.
>
> Address conflicts are also going to happen within the ISP network /
> back-office etc. 172.16.0.0/12 is used there.
>
>
> Daryl
>
>
> On 30 November 2011 20:52, Brian E Carpenter <[email-masked]>wrote:
>
>> On 2011-12-01 09:28, Chris Grundemann wrote:
>> ...
>> > It is more conservative to share a common pool.
>>
>>  It suddenly occurs to me that I don't recall any serious analysis
>> of using 172.16.0.0/12 for this. It is a large chunk of space
>> (a million addresses) and as far as I know it is not used by default
>> in any common CPE devices, which tend to use the other RFC 1918 blocks.
>>
>> I realise that ISPs with more than a million customers would have to
>> re-use this space, whereas a /10 would only bring this problem above 4M
>> customers, but at that scale there would be multiple CGN monsters anyway.
>>
>> Sorry to bring this up on the eve of the telechat.
>>
>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/%7Epresnick/>
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Dec 2011 15:02:13 -0800

As shown at <https://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ballot/>, a few (heh) members of the IESG want to have more discussion on the draft. Maybe we should wait for one of them (likely Ron) to give direction to that discussion.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Dec 2011 16:09:34 -0700

On 12/1/11 4:02 PM, Paul Hoffman wrote:
> As shown at
> <https://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ballot/>,
> a few (heh) members of the IESG want to have more discussion on the
> draft. Maybe we should wait for one of them (likely Ron) to give
> direction to that discussion.

Yes, that will be forthcoming soon.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Chris Donley <[email-masked]>
Date: Thu, 1 Dec 2011 17:03:17 -0700

This is not a new proposal.  People have been asking for the same thing
for a long time.  Draft-bdgks does a good job spelling out the history
(below). To say that we're trying to change the rules at the last minute
is wrong.  People have been asking for such an allocation considering this
use case as long ago as 2004, and fairly consistently since 2008. We and
the other draft authors have been following IETF process, documenting the
need, documenting the tradeoffs, and documenting the challenges with CGN
for quite some time. People wouldn't keep coming back to the IETF again
and again for seven years or so if we had a better way to satisfy this
need (although I am aware that some operators have opted for squat space
rather than push for a shared pool of CGN space).

Chris

>From bdgks:

   Proposals for additional Private space date back at least to
   [I-D.hain-1918bis
<http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
-I-D.hain-1918bis>] in April 2004.  Some of these proposals and
   surrounding discussion may have considered similar use-cases as
   described herein.  However, they were fundamentally intended to
   increase the size of the [RFC1918 <http://tools.ietf.org/html/rfc1918>]
pool, whereas a defining
   characteristic of Shared Transition Space is that it is distinctly
   not part of the Private [RFC1918 <http://tools.ietf.org/html/rfc1918>]
address pool.

   Rather, the Shared Transition Space is reserved for more narrow
   deployment scenarios, specifically for use by SPs to meet the needs
   of ongoing IPv4 connectivity during the period of IPv6 transition.
   This key feature emerged in more recent proposals such as
   [I-D.shirasaki-isp-shared-addr
<http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
-I-D.shirasaki-isp-shared-addr>] in June 2008 where a proposal to set
   aside "ISP Shared Space" was made.  During discussion of these more
   recent proposals, many of the salient points where commented upon,
   including challenges with RFC1918 <http://tools.ietf.org/html/rfc1918>
in the ISP NAT Zone, Avoidance of
   IP Address Conflicts, and challenges with 240/4.

   This effort was followed up by
   [I-D.weil-opsawg-provider-address-space
<http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
-I-D.weil-opsawg-provider-address-space>] in July 2010 which was re-
   worked in November 2010 as
   [I-D.weil-shared-transition-space-request
<http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
-I-D.weil-shared-transition-space-request>].  These latter efforts
   continued to point out the operators' need for Shared Transition
   Space, with full acknowledgement that challenges may arise with
   NAT444 as per [I-D.donley-nat444-impacts
<http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
-I-D.donley-nat444-impacts>] and that such space does
   not reduce the need for IPv6 deployment.

   Most recently, following exhaustion of the IANA's /8 pool
   [NRO-IANA-exhaust
<http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
-NRO-IANA-exhaust>], this proposal has been discussed by various RIR
   policy development participants.  As described herein, the body of
   ARIN policy development participants has reached consensus and
   recommended a Shared Address Space policy for adoption [ARIN-2011-5
<http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
-ARIN-2011-5>].

   This history shows that operators and other industry contributors
   have consistently identified the need for a Shared Transition Space
   assignment, based on pragmatic operational needs.  The previous work
   has also described the awareness of the challenges of this space, but
   points to this option as the most manageable and workable solution
   for IPv6 transition space.

Chris

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Dec 2011 13:19:53 +1300

Ted,

> There are enterprises that currently use
> 172.16/12.

Yes, but I thought the topic of discussion when I wrote was the
default prefix used by mass-market NAT CPE boxes. That's a very
different problem than dealing with enterprise networks or even
ISPs that have intentionally deployed 172.16/12. I'm not suggesting
that reconfiguring those intentional deployments is easy, but then
no solution to this problem is easy. Reconfiguring mass-market boxes
is simply impossible.

Regards
   Brian

On 2011-12-02 11:27, Ted Hardie wrote:
> ------------------------------------------------------------------------
>

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 1 Dec 2011 16:27:46 -0800

> rather than push for a shared pool of CGN space).

I know this is not a new case.

And I know efforts to make 240/4 workable are also not new.

And, historically the answer is always no to new special ipv4 space.
Someone else can expound why. If I had 240/4 in 2008, I would not have ipv6
now, that is a straight strategic business planning fact.

Saying yes now, would be changing the rules because 'the rule' was/is 'no'
new space.

Cb

> <
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
> <
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
> <
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
> <
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
> <
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
> <
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref
> <
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref

---

From: Pete Resnick <[email-masked]>
Date: Thu, 1 Dec 2011 21:47:29 -0600

On 12/1/11 4:27 PM, Ted Hardie wrote:

> On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The problem described in the draft is that CPEs use 1918 space
>     *and that many of them can't deal with the fact that there might
>     be addresses on the outside interface that are the same as on the
>     inside interface*. The claim was made by [Robert], among others,
>     that only 192.168/16 space was used by such unintelligent CPEs. I
>     believe I have seen the claim that 10/8 space is also used in
>     unintelligent equipment that can't deal with identical addresses
>     inside and outside. Is there reason to believe that within the ISP
>     network / back-office etc. that there is equipment that can't deal
>     with 17.16/12 space being on both the inside and outside? I
>     haven't seen anyone make that specific claim.
>
>     If we know that 172.16/12 used both inside and outside will break
>     a significant amount of sites that CGNs will be used with, we can
>     ignore this argument. But if not, then let's rewrite the document
>     to say that CGNs should use 172.16/12 and that any device that
>     wants to use 172.16/12 needs the ability to deal with identical
>     addresses on the inside and the outside interface. Of course, all
>     equipment should have always been able to deal with identical
>     addresses inside and outside for all 1918 addresses anyway. But if
>     we think the impact of using 172.16/12 for this purpose will cause
>     minimal harm, then there's no compelling reason to allocate new
>     space for this purpose.
>
>
> I wrote a response to Brian's original statement then deleted it 
> because I assumed others would ignore it as clearly last minute and 
> ill-researched.  Apparently, that was wrong.  There are enterprises 
> that currently use 172.16/12.  (There are enterprises which use every 
> tiny piece of RFC 1918 space.)

Ted, your response does not address what I said at all. Not one bit. 
Let's assume that *every* enterprise used every last address of 
172.16/12 (and, for that matter ever bit of 1918 space). That's 
irrelevant and still does not address my question. The question is 
whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO 
IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE. I am happy to accept an 
answer of, "Yes, all 1918 address space is used by such equipment", but 
nobody, including you, has actually said that.

> *Any* piece of the current RFC 1918 space you attempt to define as 
> chose this for an enterprise deployment and gets stuck behind a CGN 
> would be forced to renumber, in other words, because of this statement.

That statement does not logically follow from "all 1918 address space is 
used". You are missing a premise: "There exists equipment that is used 
in all of that space that can't handle identical addresses on the 
interior and exterior interface."

The current draft says that the reason 1918 space can't be used is that 
equipment that deals in 1918 address space is hosed if 1918 addresses 
are used on their external interface. Brian claimed that perhaps 
172.16/12 space might not be used by that equipment. Robert claimed that 
perhaps only 192.168 and 10.0.0.x addresses are used by that equipment. 
So the question I posed was, "Does any of *that* equipment use 172.16/12 
(or 10.x/16) space?" Nobody has said "yes".

And *I'm* still not claiming that the answer is "No." I simply don't 
know. But I'm inclined to hear from anybody to indicate that there is 
*any* evidence that the answer is "Yes". That would make me much more 
comfortable in concluding that new specialized address space is the 
better horn of this bull to throw ourselves on.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Doug Barton <[email-masked]>
Date: Thu, 01 Dec 2011 20:12:09 -0800

On 12/01/2011 19:47, Pete Resnick wrote:
> are used on their external interface.

Let's assume that's true for a second (I haven't seen any evidence of
that). We all know that if the /10 is allocated that people are going to
use it for 1918 space. So, back to square 1.

> Brian claimed that perhaps

The lack of research on this point has been pointed out in the past, and
TMK has never been addressed.

Doug

-- 

		"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: Ronald Bonica <[email-masked]>
Date: Thu, 1 Dec 2011 23:09:57 -0500

Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172.16/12 (and, for that matter ever bit of 1918 space). That's irrelevant and still does not address my question. The question is whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE. I am happy to accept an answer of, "Yes, all 1918 address space is used by such equipment", but nobody, including you, has actually said that.

I suspect that is because it is impossible to know for sure.

                                                                 Ron

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 1 Dec 2011 20:21:18 -0800

Would you take a check for $50 million USD instead of the /10? Sounds like
they are equivalent value.

http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000

---

From: Pete Resnick <[email-masked]>
Date: Thu, 1 Dec 2011 22:28:05 -0600

> use it for 1918 space. So, back to square 1.

No, that's not true. Once this document claims that a particular block 
of addresses will be used on both internal and external interfaces, 
whether they're from a part of 1918 space that isn't used by the broken 
equipment *or* from a new /10 (which obviously isn't used by the broken 
equipment), any *new* use of this address space by *newly* broken 
equipment is acceptable to the CGN people. The only thing the current 
document worries about is deployed equipment that the CGN people can't 
push back on. So either a new /10 or 1918 space not used by current 
broken equipment addresses this problem.

> TMK has never been addressed.

Ron's point (that part of the problem is that people simply don't know) 
is well-taken, but if there is not even anecdotal information that 
172.16/12 or 10.x/16 is used by broken equipment, I'd like there to be 
some research before we say that allocating a /10 is necessary.

pr

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 01 Dec 2011 21:51:48 -0800

> some research before we say that allocating a /10 is necessary.

it's simpler than that.

assuming that there existing a pool of devices for which it can be
stipulated:

	* does not support a collision between internal and external
	  address ranges
	* has a collision between it's internal address ranges and
	  assigned external prefix in 10/8

It seems unlikely in the extreme that home cpe statifying both
conditions would also have a collision with an assignment out of 172.16/12.

I have never found the arguement that, that particular problem
intractable enough to benifit from and additional prefix to be
particularly compelling.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Dec 2011 22:07:35 -0800

On Thu, Dec 1, 2011 at 7:47 PM, Pete Resnick <[email-masked]> wrote:

> space.)
> Ted, your response does not address what I said at all. Not one bit. Let's
> assume that *every* enterprise used every last address of 172.16/12 (and,
> for that matter ever bit of 1918 space). That's irrelevant and still does
> not address my question. The question is whether these addresses are used
> BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR
> INTERFACE.
>

Darling Pete,

TYPING YOUR QUESTION IN CAPS DOESN'T MAKE IT THE RIGHT QUESTION.

An enterprise that has numbered into this space and gets put behind a CGN
by a provider will have no direct control over this equipment, and it might
happen in the *future* after the allocation we're discussing here has been
made.  Asking whether anyone has this pain right now presumes a steady
state in the deployment of CGN, which, sadly, seems awfully unlikely.

To put this another way, you can't solve the problem of equipment which
cannot have internal and external interfaces being in the same pool by
moving to this, in other words; you just move the pain from users of one
RFC 1918 pool to users of another.

> used". You are missing a premise: "There exists equipment that is used in
> all of that space that can't handle identical addresses on the interior and
> exterior interface."
>
>
No, I think that premise is mis-stated.   Premise 1: There exists equipment
that can't handle identical addresses on the interior and exterior
interface.  Premise 2: it may be deployed now or in the future for
customers using any part of the RFC 1918 allocation *because those using
the RFC 1918 allocations had no prior warning that this might create a
collision*.  Conclusion:  You cannot avoid identical addresses on the
interior and exterior interface by using any part of the RFC 1918
allocation.

> (or 10.x/16) space?" Nobody has said "yes".
Any exhaustive attempt to categorize that would be single-point in time and
therefore useless.

> And *I'm* still not claiming that the answer is "No." I simply don't know.
> But I'm inclined to hear from anybody to indicate that there is *any*
> evidence that the answer is "Yes". That would make me much more comfortable
> in concluding that new specialized address space is the better horn of this
> bull to throw ourselves on.
>
>
CGNs are, in my humble opinion, an abomination unto Nuggan.  Whether or not
we throw ourselves onto this horn to enable them is, at best, a decision
that keeping the abomination in a pen is better than having it flow over
the countryside in squat space.  But the worst decision we could make is to
try to pull a /12 out of RFC 1918 space for this purpose; it will be at
best simply ignored and at worst ensure yet another group's ox gets gored.

Your humble and obedient servant,

Ted

---

From: Doug Barton <[email-masked]>
Date: Thu, 01 Dec 2011 23:08:51 -0800

On 12/01/2011 22:07, Ted Hardie wrote:
> No, I think that premise is mis-stated.   Premise 1: There exists
> equipment that can't handle identical addresses on the interior and
> exterior interface.  Premise 2: it may be deployed now or in the future
> for customers using any part of the RFC 1918 allocation *because those
> using the RFC 1918 allocations had no prior warning that this might
> create a collision*.  Conclusion:  You cannot avoid identical addresses
> on the interior and exterior interface by using any part of the RFC 1918
> allocation.

But doesn't that same line of reasoning apply to any new allocation
that's made for this purpose? You can fix the problem for today, but you
can't fix it for the future because you can't prohibit customers from
using the new allocation on the inside of their network.

Therefore, making the allocation is a pointless waste of resources that
can be better utilized elsewhere.

Step 1:	Determine the most popular inside prefixes for CPEs
Step 2: Use the least popular RFC 1918 prefix for the CGN network
Step 3: If your customer has somehow chosen the same prefix, tell them
they can't do that.

And yes, I realize that Step 3 is going to be incredibly unpopular for
the ISPs, but they created the problem, so they should have to live with
the results.

Doug

--

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Dec 2011 02:44:33 -0500

Ted,

I've been trying to stay out of this round of this debate too,
but...

--On Thursday, December 01, 2011 22:07 -0800 Ted Hardie
<[email-masked]> wrote:

>...
> An enterprise that has numbered into this space and gets put
> behind a CGN by a provider will have no direct control over
> this equipment, and it might happen in the *future* after the
> allocation we're discussing here has been made.  Asking
> whether anyone has this pain right now presumes a steady state
> in the deployment of CGN, which, sadly, seems awfully unlikely.

Sure.  But, IMO, that is the point at which "should we make this
allocation" segues into "what do you think of CGNs".  Now,
personally, I've got a bad attitude toward CGNs.  I share the
concerns others have expressed that CGNs (and this allocation
proposal) are not part of IPv6 deployment or transition plans
but are, instead, IPv4 preservation plans... or IPv6 delaying
plans, which, for many ISPs and equipment vendors, might be the
same thing.  That bad attitude is driven less by love of IPv6
than it is by the belief that global addressing and [nearly]
end-to-end access are essential to what makes the Internet
technology valuable: that we can innovate easily precisely
because we don't need or have address and protocol-translation
mechanisms in the middle of the network that have to understand
(and effectively give permission for) the applications that are
going to traverse them.  

The "data" networking community tried that (arguably a couple of
times) with protocols and addresses that worked up to a peering
point or national boundary and then got translated into
"something else".  I'm sure there are still folks around who
think that was a good idea, but I'm not one of them.   There are
others who didn't have that experience or don't understand its
implications; for them, old adages about repeating history may
be applicable.

But it is clear that some ISPs are going to deploy CGNs. Whether
they see that as "keeping IPv4 as long as possible", "arranging
a really long transition", or something else --and whether their
rationales actually make sense-- is largely irrelevant.  So I
think that question for the IETF is whether it is better to make
this allocation or just let them squat (on 1918 addresses, on
addresses they already have, or on some other addresses they
don't believe will interfere with anything that they are doing).

It seems to me that there are two ways to address that question.
One is the question I think Pete is trying to ask.  Restated to
address your "steady state" comment, I'd make it more like:

Assume that no vendor in its collective right mind would deploy
new address translation gear (or firmware) that couldn't cope
with having addresses from the same pool on the "inside" and
"outside" and that we are willing to let the marketplace punish
those who are not in their right minds, the topic of whether a
separate address range is needed to maintain inside/outside
distinctions becomes strictly one of legacy gear -- dealing with
deployed CPE gear that is hard or impossible to replace on a
near-term schedule and, quite bluntly, crappy.  

In that context, questions like Pete's make perfect sense
because they are questions about how to patch around said legacy
gear while causing minimum damage to today's assumptions about,
e.g., routable and non-routable addresses.

Even if the answer is "no, there are no devices that both have
172.16/12 wired in and that can't handle overlapping 'inside'
and 'outside' address pools", it doesn't necessarily make
allocating an address pool to this use desirable.  But that is
the other question:

Where is the stopping point?  If 172.16/12 works for
carrier-grade NATs, will we need a new allocation (possibly the
one requested in the present I-D) for peering-point-grade NATs?
If that allocation is made, will we need another one for
country-boundary-NATs or RIR-boundary-NATs?  Conversely, if we
make the requested allocation (rather than using 172.16/12 or
something else already reserved), does that fix anything or just
bring the "next NAT layer, next allocation" question a little
closer?

>From that point of view, this proposal doesn't improve things at
all and doesn't buy enough time to be worth the the trouble.

But one could then claim that any CGN that is deployed would be
able to deal with the same address pool "inside" and "outside"
even if the CPE gear cannot.  Fair enough except that then turns
into an argument that providing a special, dedicated address
pool for CGN-CPE interactions just encourages long-term support
for that CPE gear and, worse, violation of the "no ISP in its
right mind" principle expressed above.  On balance, a bad idea.

That is perhaps just a long way to say what Randy (I think)
expressed as NAT4444444444444...

> To put this another way, you can't solve the problem of
> equipment which cannot have internal and external interfaces
> being in the same pool by moving to this, in other words; you
> just move the pain from users of one RFC 1918 pool to users of
> another.

Right.

>...
> No, I think that premise is mis-stated.   Premise 1: There
> exists equipment that can't handle identical addresses on the
> interior and exterior interface.  Premise 2: it may be
> deployed now or in the future for customers using any part of
> the RFC 1918 allocation *because those using the RFC 1918
> allocations had no prior warning that this might create a
> collision*.  Conclusion:  You cannot avoid identical addresses
> on the interior and exterior interface by using any part of
> the RFC 1918 allocation.

Nor, in the long run, can one avoid it by using any other
allocation model other than public address space allocated and
dedicated to the relevant ISP for non-overlapping use.

>...
> CGNs are, in my humble opinion, an abomination unto Nuggan.
> Whether or not we throw ourselves onto this horn to enable
> them is, at best, a decision that keeping the abomination in a
> pen is better than having it flow over the countryside in
> squat space.  But the worst decision we could make is to try
> to pull a /12 out of RFC 1918 space for this purpose; it will
> be at best simply ignored and at worst ensure yet another
> group's ox gets gored.

As you can deduce from the above, I see a --very slight and very
temporary-- advantage of using a slice of 1918 space in this
way, so I'm not certain it is the worst decision.  But I think
it only postpones (for a short time) the need for a dedicated
allocation, and then another dedicated allocation, and then...
And, probably sooner rather than later, we get to squat space
anyway.  So, if it isn't the worst decision, neither it nor a
new allocation are far off.

Another thing that is interesting about this and, in particular,
about the "do this to avoid squatting" position, is that it
isn't hard to lay out a set of rules that, if everyone would
follow, would make things work.  "Use only these addresses for
this purpose, do not use them for anything else, and never,
ever, connect a CGN to a downstream device that has other than
public unique addresses on both sides" would probably top that
list.  But every scaling argument that has been used to justify
this shared space proposal and its clones proves that is
impractical and unlikely to be feasible if this is the strategy
we try to follow.

    john

---

From: Robert Elz <[email-masked]>
Date: Fri, 02 Dec 2011 15:04:59 +0700

Date:        Thu, 01 Dec 2011 23:08:51 -0800
    From:        Doug Barton <[email-masked]>
    Message-ID:  <[email-masked]>

  | Step 3: If your customer has somehow chosen the same prefix, tell them
  | they can't do that.

Another alternative there is for the ISP to simply pick a different
prefix.   There's nothing that says that the ISP has to number all of
its customers into a single number space - sure that might be more
convenient for them, but convenience isn't the objective.   What is needed
is that this not happen too often, or it would be unmanageable.

The only time this won't work at all, is if the customer has used all of the
1918 space (really used, not just pretended) - in that case there won't be an
available address from 1918 space to select that can be used - but for the
very small number of such huge customers, I see no problem continuing to use
genuine public addresses (the same one they have been using in the pre CGN
days that they won't need to be using as many of in a post CGN world).

That is, there's no need for one standard solution for this for everyone.
1918 space can be made to work, almost always, it already exists, and adding
one more "unroutable" prefix isn't really going to achieve anything other
than giving the carriers a way to say "what we're doing has been blessed
by the IETF, see they even assigned an address for us to use, it must be OK".

kre

---

From: "Lee Howard" <[email-masked]>
Date: Fri, 2 Dec 2011 09:15:16 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Doug Barton
> the ISPs, but they created the problem, so they should have to live with

Which problem did ISPs create?
The problem CGN partially solves is providing connectivity for IPv4-only
consumer electronics.  Renumbering the home network within RFC1918 
doesn't provide additional connectivity.

Lee

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 2 Dec 2011 17:03:00 +0100

> Which problem did ISPs create?

By dragging their feet to the inevitable roll-out of v6 they checked
the demand for consumer electronics compatible with v6. If v6 connectivity
had been norm 6 years ago we'd have more v6-ready devices deployed today.

> doesn't provide additional connectivity.

When the home router is reconfigured to not have the same prefix on
the inside as on the outside, connectivity will improve. It won't be
"Internet" (couldn't be without real addresses on all interfaces)
but something closely resembling it. A lot more satisfactory than the
unexplainable failure with identical addresses inside and out.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
HUMAN REPLICAS are inserted into VATS of NUTRITIONAL YEAST ...

---

From: Randy Bush <[email-masked]>
Date: Sat, 03 Dec 2011 01:11:09 +0900

> Which problem did ISPs create?

big broadband providers sitting on thumbs for a decade instead of
looking their (mostly edge) vendors in the eye and saying "ipv6 in two
years or no buy."

> The problem CGN partially solves is providing connectivity for
> IPv4-only consumer electronics.

cpe with nat46?

randy

---

From: Daryl Tanner <[email-masked]>
Date: Fri, 2 Dec 2011 16:56:55 +0000

The IPv6 "chickens and eggs" discussion could (and probably will) go on
forever:

service provider -> no content
content provider -> no customers
manufacturers -> no content or customers

IPv6 is the right answer, but for all of the above it costs money to
implement, with no return on investment (without everyone else doing their
bit to progress its rollout). It's therefore not going to happen in a
suitable timescale to avoid the necessity of 'propping-up' IPv4.

I don't like CGN, but the reality is that we're stuck with it.  On this
basis, it's a case of looking for the least-problematic solution.

A dedicated, shared prefix (not from 1918) is the lowest risk for address
conflicts, and easiest to manage and control.

Daryl

On 2 December 2011 16:03, Måns Nilsson <[email-masked]> wrote:

> Subject: RE: Consensus Call: draft-weil-shared-transition-space-request
> Date: Fri, Dec 02, 2011 at 09:15:16AM -0500 Quoting Lee Howard (
> [email-masked]):
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk7Y9rQACgkQ02/pMZDM1cWclwCeI᫚�ාொ�볖뮵�
> 4gQAoJiFArSjOeYEIiK41C6l7LwbyGkE
> =Jflb
> -----END PGP SIGNATURE-----
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 2 Dec 2011 09:50:06 -0800

> using the new allocation on the inside of their network.
If a customer uses a CGN-specific allocation on the inside of their network
as if it were RFC 1918 space, then, yes, they will have trouble if they
ever use a provider that uses a CGN.  At the very least, though, they have
collaborated in their need to renumber by ignoring the quite plain warnings
that this is a bad idea.   They did not have that warning about using an
allocation from RFC 1918 space.

> the ISPs, but they created the problem, so they should have to live with
It's not going to be unpopular with ISPs, it will be unpopular with
*customers*.  To retain those customers, the ISPs will simply ignore the
RFC and use some other space.  At least, that's my prediction.

regards,

Ted

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 2 Dec 2011 12:53:41 -0500

> had been norm 6 years ago we'd have more v6-ready devices deployed today.
The problem is three part: Connectivity / ISP, Home Ecosystem / consumer
electronics and Content.

To suggest any one entity caused this is to over simply the problem and be
disingenuous.

But to you point, many operators have been very active working with vendors
trying to get equipment to support IPv6.  This is a difficult task, but is
being done.

Some have suggested that ISPs should say "if no IPv6, then I will not buy
it".  I tired that before - I would have been left with nothing to choose
from in the space I was selecting.  There is this strange paradox in the
world... people seem to only do things when they can make money at it (not
too many saints out there).

Back to the point -  many operators are deploying IPv6, but as long as most
content and home equipment (which consumers buy from the store - not me) is
IPv4 (for the most part), connectivity alone (ISP) does not fix the problem.

regards,

Victor K

---

From: Ted Hardie <[email-masked]>
Date: Fri, 2 Dec 2011 10:06:17 -0800

> e.g., routable and non-routable addresses.
I think there is an unstated premise in Pete's question that the set of
customers behind that legacy gear has a stable usage pattern of private
addresses.  That is, if the current set of customers behind that legacy
gear uses 10/8 then use of any other RFC 1918 address on the CGN is
"safe".  I do not think that is a safe assumption.

I also strongly suspect that any vendor in its collective right mind which
had available a solution like using 172.16/12 would have done so long
before enduring the pain of being nibbled to death by the IETF's ducks.
It's not like these guys haven't read RFC 1918 and simply assumed 10/8 was
the only network available.

> bring the "next NAT layer, next allocation" question a little
I think this boils down to a recommendation to reject the request entirely,
a point of view with which I have a great amount of sympathy (heck, if that
point of view wants to come over to my house, I'll give it dinner, a good
wine, and a spot in the guest room).  I have no illusions that making this
allocation is a good idea; it's just a question of whether it is the right
bad idea for the moment.  But I personally remain convinced that shifting
this pain onto folks who used some part of the private address space as it
was described is sufficiently wrong-headed that it simply will not work.
It is better to either hold your nose and allocate or stick to your guns
and reject.

Once again, my personal opinion, not reflective of those held by my
employer, spouse, hot tub-maintainer, or the man on the street.

regards,

Ted

---

From: Michael Richardson <[email-masked]>
Date: Fri, 02 Dec 2011 12:59:20 -0500

> Ted, your response does not address what I said at all. Not
    > one bit. Let's assume that *every* enterprise used every
    > last address of 172.16/12 (and, for that matter ever bit of
    > 1918 space). That's irrelevant and still does not address my
    > question. The question is whether these addresses are used
    > BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE
    > EXTERIOR INTERFACE. I am happy to accept an answer of, "Yes,
    > all 1918 address space is used by such equipment", but

one reason enterprises use 172.16/12 for stuff is because that way,
when their VPNs come up with people's residents, they do not immediately
conflict with the LAN at the home/coffee shop, etc.

And, there is a further consideration: this space only has to be useable
to for CGNs, for ISPs that have new customers that they want to hook up
via IPv4.  Most of these ISPs already provide a home gateway (often
integrated with the DSL model or cable modem), and it only has to work
with that brand!

So I favour 172.16/12 or 224/10.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 02 Dec 2011 10:51:51 -0800

> conflict with the LAN at the home/coffee shop, etc.

realistically a sufficiently large enterprise uses all of rfc 1918 in
one form or another... you're counting on to some extent the more
specific route associated with the subnet leaving the covering vpn route
unclobbered. sometimes however heroic work-arounds are required.

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Dec 2011 14:34:04 -0500

--On Friday, December 02, 2011 10:06 -0800 Ted Hardie
<[email-masked]> wrote:

>> because they are questions about how to patch around said
>> legacy gear while causing minimum damage to today's
>> assumptions about, e.g., routable and non-routable addresses.

> I think there is an unstated premise in Pete's question that
> the set of customers behind that legacy gear has a stable
> usage pattern of private addresses.  That is, if the current
> set of customers behind that legacy gear uses 10/8 then use of
> any other RFC 1918 address on the CGN is "safe".  I do not
> think that is a safe assumption.

Agreed.  But let me also suggest that there is another
assumption that is perhaps equally unsafe or unreasonable.  Even
if one concedes that replacing the CPE gear in low-end networks
is completely unfeasible in any short period of time, that does
not imply that such networks cannot be renumbered.  Those CPE
devices typically contain the DHCP servers that allocate
addresses to devices on the relevant end-user LAN.  Virtually
all of them can be configured or patched to use different
addresses.  And, especially if we believe that renumbering is
plausible enough to make lots of our other protocols and
assumptions work, changing the address ranges they assign has to
be within the realm of possibility.

So a different (and narrower) version of Pete's question is
whether there are devices out there that (i) use a particular
range of 1918 addresses, (ii) do so stably, and (iii) cannot
plausibly be reconfigured to use something else (or a smaller
range).  We disagree in that I think that question is still
interesting.. but not very interesting. 

> I also strongly suspect that any vendor in its collective
> right mind which had available a solution like using 172.16/12
> would have done so long before enduring the pain of being
> nibbled to death by the IETF's ducks. It's not like these guys
> haven't read RFC 1918 and simply assumed 10/8 was the only
> network available.

Unless either (i) it had already figured out that trying to use
pieces of 1918 space was a dead end that would lead them to
needing a new allocation later (see my "stopping point"
comments) and had concluded that, however painful the process
would be today, it would be worse a few years down the road or
(ii) they have more sinister motives, perhaps those that kre's
reasoning suggests.

>> allocating an address pool to this use desirable.  
>...

> I think this boils down to a recommendation to reject the
> request entirely, a point of view with which I have a great
> amount of sympathy (heck, if that point of view wants to come
> over to my house, I'll give it dinner, a good wine, and a spot
> in the guest room).

Yes, it does.  Someday, I'll accept that invitation on behalf of
the point of view.

>  I have no illusions that making this
> allocation is a good idea; it's just a question of whether it
> is the right bad idea for the moment.  But I personally remain
> convinced that shifting this pain onto folks who used some
> part of the private address space as it was described is
> sufficiently wrong-headed that it simply will not work. It is
> better to either hold your nose and allocate or stick to your
> guns and reject.

If we disagree at all, it is only because I don't see enough
advantages or disadvantages of trying to use some chunk of 1918
space relative to allocating new public space to justify
choosing one over the other.  From my point of view, this is
just a bad idea that solves no useful problem.   If might delay
a few.  It might cause some ISPs, for a while, to use
IETF-designated space (of one flavor or the other) rather than
squatting, but almost all of the argument for doing this is
based on the assumption that the use of more traditional space
(dedicated/public or 1918) is not possible because that space
has been used up or soon will be.  But that argument is for
dragging the wolf away from the door and a few meters down the
block, hoping it won't come back.  Sorry, but that isn't
consistent with wolf-behavior or ISP behavior: tactics that are
justified on the basis of "we don't have enough addresses to do
this right" are tactics that are intrinsically going to bring
people back to the well over and over again.

So, yes, I think we should just reject this... and that we
should reject enabling/ encouraging any other solutions that are
intended to be IPv4-preserving rather than IPv6-enabling and
transitional.  It may still be reasonable for us to do protocol
work to enable those who intend to do this sort of thing to do
it correctly and consistently.  But, as far as making IPv4
address allocations to permit them to hide a bit longer from
IPv6 -- taking those addresses away from those who really have
IPv6 deployment and transition plans-- it is better to Just Say
No.

> Once again, my personal opinion, not reflective of those held
> by my employer, spouse, hot tub-maintainer, or the man on the
> street.

As is mine.

best,
   john

---

From: james woodyatt <[email-masked]>
Date: Fri, 02 Dec 2011 11:39:09 -0800

On Nov 28, 2011, at 13:25 , Ronald Bonica wrote:

> […] I will submit the draft to the full IESG for its consideration at its December 1 teleconference. The draft will be published as a BCP if a sufficient number of IESG members ballot "Yes" or "No Objection", and if no IESG member ballots "Discuss".

Before I get started, I should offer my deepest and most sincere apologies to the participants who have heard quite enough about 6to4 to last a lifetime.  Nobody is more ashamed of The 6to4 Problem than me.

I have reservations to this draft because it A) gives explicit advice to mitigate the addressing conflict it poses for 6to4 sites by recommending consideration of I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel, which I would contend is even more controversial than Shared CGN Address Space, and B) it mischaracterizes the advisory guidelines in RFC 6343 with respect to the IPv4 Special-Use Addresses in RFC 5375, which in fact are not referenced at all, and indeed the language in RFC 6343, section 4.2.3 IPv4 Prefix Issues and section 3 Problems Observed, would seem to contradict the language in this draft.

I could support this draft if instead it were edited to update RFC 3056 directly to clarify the interpretation of its IPv6 Prefix Allocation requirement in section 2, which currently reads:

   Suppose that a subscriber site has at least one valid, globally
   unique 32-bit IPv4 address, referred to in this document as V4ADDR.
   This address MUST be duly allocated to the site by an address
   registry (possibly via a service provider) and it MUST NOT be a
   private address [RFC 1918].

I would like to see an explicit recognition that the phrase in RFC 3056, above, "duly allocated to the site by an address registry (possibly a service provider)," MUST NOT be interpreted to include the new Shared CGN Address Space defined by this document.

In simpler terms, what I want is a document that clearly implies 6to4-PMT is not applicable with this new Shared CGN Address Space.  No, I am not joking, and I'm very sorry that I had to bring up the topic of 6to4 again.

--
j h woodyatt <[email-masked]>

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 2 Dec 2011 21:38:36 +0100

> basis, it's a case of looking for the least-problematic solution.

Which is v6. Propping up v4 will only let those who dragged their feet
continue weeping crocodile tears while continuing to fail at their
task. It has been established as broad consensus that v6 is the way
forward. If industry people failed to do their part in moving towards
this future, they should not be surprised at failing as businesses.
 
> conflicts, and easiest to manage and control.

It is also established practice that if you deploy non-unique address
space, be it from 1918 or another special prefix, you are to pay the
additional cost in managing the resulting mess. Your network. Your
problem.

I find it objectionable to waste even more address space on making it
easier to avoid DTRT. Moral and perception play a large part here --
if the IETF says it is OK to cheat your way out of what has been the
obvious upgrade/expansion/business continuity path since last millenium,
what kind of message are we sending out?

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... My pants just went on a wild rampage through a Long Island Bowling Alley!!

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 2 Dec 2011 21:48:47 +0100

On 2 dec 2011, at 21:38, Måns Nilsson wrote:

> Which is v6.

I would add, people can choose to either do v6, or to have v4 NAT boxes that can handle same address space on both sides of the NAT.

One question I think should be asked is how much time should be spent on people/organizations that have made a decision to choose neither of these two? How much should IETF spend, and how much should they be forced to spend?

Yes, IETF should adopt to reality, and not theory, but this is something different.

   Patrik

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 2 Dec 2011 16:15:30 -0500

James,

> In simpler terms, what I want is a document that clearly implies 6to4-PMT
> is not applicable with this new Shared CGN Address Space.  No, I am not
> joking, and I'm very sorry that I had to bring up the topic of 6to4 again.
>
>
I appreciate your position.  I am also biased as much as you and others are
on this.  But I would like to point out that PMT has worked in a large
production network with much success (as ugly as one may think it is).

The reality is that it works, and works well when using non-RFC1918 on CGN
zone endpoints.  When 6to4 goes away or Native is enabled, so will PMT (for
those who choose to use it).

regards,

Victor

---

From: Warren Kumari <[email-masked]>
Date: Fri, 2 Dec 2011 16:31:13 -0500

On Dec 2, 2011, at 1:51 PM, Joel jaeggli wrote:

> one form or another...

But (also realistically) a "sufficiently large enterprise" that uses all of RFC1918 is not going to be sitting behind a CGN...

W

> you're counting on to some extent the more

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 02 Dec 2011 13:35:59 -0800

> But (also realistically) a "sufficiently large enterprise" that uses all of RFC1918 is not going to be sitting behind a CGN...

it's employees are probably sitting behind many of them, but no it's
ip/ssl-vpn termination platform is not.

---

From: Doug Barton <[email-masked]>
Date: Fri, 02 Dec 2011 14:31:55 -0800

On 12/02/2011 09:50, Ted Hardie wrote:
> On Thu, Dec 1, 2011 at 11:08 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> If a customer uses a CGN-specific allocation on the inside of their
> network as if it were RFC 1918 space, then, yes, they will have trouble
> if they ever use a provider that uses a CGN. 

Thanks. So my point is, this proposed allocation doesn't solve anything,
it just kicks the can down the road a while. That's not enough benefit
to justify the cost.

> At the very least, though,
> they have collaborated in their need to renumber by ignoring the quite
> plain warnings that this is a bad idea.   They did not have that warning
> about using an allocation from RFC 1918 space.
> 
>  
> 
> *customers*. 

... which is why it'll be unpopular with the ISPs. See what I did there? :)

> To retain those customers, the ISPs will simply ignore the

Works for me.

Doug

--

---

From: Ted Hardie <[email-masked]>
Date: Fri, 2 Dec 2011 15:20:34 -0800

On Fri, Dec 2, 2011 at 1:31 PM, Warren Kumari <[email-masked]> wrote:

>
>
> But (also realistically) a "sufficiently large enterprise" that uses all
> of RFC1918 is not going to be sitting behind a CGN...
>
> W
>
> Big enterprises buy small ones; sometimes at a great rate.  Imagine an
enterprise that uses this /12 for its corporate network buying a wee little
company that was connected via CGN up to the purchase.  The order in which
they renumber/get attachments to the new mothership/ start passing traffic
from this /12 gets just a little bit more strict and the chance of
ticket-inducing failure goes up just that extra amount.

Ted

---

From: james woodyatt <[email-masked]>
Date: Fri, 02 Dec 2011 15:26:59 -0800

On Dec 2, 2011, at 13:15 , Victor Kuarsingh wrote:
> 
> […] I would like to point out that PMT has worked in a large production network with much success (as ugly as one may think it is).  The reality is that it works, and works well […]

In order to retain a semblance of professional composure, I must contain my response merely to expressing my hope that IESG pays very close attention to the language about 6to4-PMT in this draft, and the implications and consequences for the Internet engineering community, if it is published by IETF.

This draft is not just about extending the life of IPv4 with NAT444 deployments.  It is also about expressly recommending 6to4-PMT for IPv6 service.  If this draft is published as is, then I will have a much more difficult time removing 6to4 router function from forthcoming products, as RFC 6343 recommends.  Why?  Because I don't want to break users who are forced by providers to get their IPv6 service from 6to4-PMT deployment.

I hope IESG will think *very* carefully about whether it really wants to sign up for that.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 03 Dec 2011 11:46:41 +1100

> So I favour 172.16/12 or 224/10.

So you don't think existing customers will be moved behind CGN's?
This has to work for ALL customers (new and old) with equipment
that is 10+ years old.  We are talking about billions of machines
world wide.

224/10 could be made to work with new equipement provided there was
also signaling that the equipment supported it.  That doesn't help
ISP that have new customers with old equipment and no addresses.

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 03 Dec 2011 08:22:04 +0700

Date:        Fri, 2 Dec 2011 15:20:34 -0800
    From:        Ted Hardie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Big enterprises buy small ones; sometimes at a great rate.

And this itself is a good argument that 1918 space is sufficient (one way or
another), not the reverse.   What you have there is two 1918 spaces 
(typically, if it isn't, it is irrelevant here) colliding - with just the
same possibilities of collisions as are being mooted here - and yet as you
say, this happens all the time, and I don't see the big enterprises clamoring
for a dedicated address block for their use, so they can avoid clashes when
swallowing smaller ones.

This also raises another problem with the proposal - it assumes that there
are two distinct classes of networks, the carrier ISP networks that get to
use CGNs, and the new network block, and end users, who are supposed to use
1918 space.    While I agree in many cases it is easy to categorise users as
one or the other, I believe that there are very many ambiguous cases, ISPs
who believe themselves to be carriers where most of the rest of us would
treat them as end users, and others (like just big enterprises like above
that have swallowed lots of little ones) that are acting more like a big
ISP, even though their only customers are their acquired enterprises.

I still believe that there are just two types of addresses (multicast etc
aside) - routable ones, and non-routable ones, and attempting to set aside
pieces of either of those spaces for one use, as opposed to another, is just
futile.

kre

---

From: Ross Callon <[email-masked]>
Date: Fri, 2 Dec 2011 23:50:45 -0500

> it just kicks the can down the road a while. That's not enough benefit

This particular argument has been bothering me for a while. 

We write standards. Our RFCs that specify protocols or best current practices contain statements along the lines of MUST or MUST NOT (and yes other documents also may use this terminology). People who implement or who deploy products could at least in principle ignore some of these statements, and implement or deploy equipment in ways that violate the MUST and MUST NOT statements in our documents. When they do this, bad things may happen. 

This is not a valid reason for us to stop writing standards, nor to stop putting MUST statements in our standards. 

Ross

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 03 Dec 2011 21:13:37 +0900

> IPv6 is the right answer,

Wrong.

IPv6 is not operational, which is partly why most service
providers refuse it.

For example, to purposelessly enable multicast PMTUD, RFC2463
(ICMPv6) mandates routers generate ICMPv6 packet too big
against multicast packets, which causes ICMPv6 packet
implosions, which is not operational.

For further details, see my presentation at the last APNIC:

	How Path MTU Discovery Doesn't work
	http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 03 Dec 2011 21:25:34 +0900

> ISP that have new customers with old equipment and no addresses.

Yes, it takes time.

However, 224/4 (or most of it) and 240/4 (except for 255.255.255.255)
should be released for unicast uses to reduce market price on
IPv4 addresses.

						Masataka Ohta

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 03 Dec 2011 10:23:58 -0500

>should be released for unicast uses to reduce market price on

I have not objection to this.  But anything that requires replacement of
equipment only will have longer term benefit. (Built it, Ship it, Stock
it, Sell it, put it in....).  I would also hope that when we have an
opportunity to change out a box, it's with a IPv6 capable one (although it
does not help that many boxes on the retail shelf are still IPv4-only -
where we are).

I wish to spend most of our time on IPv6 deployment (and only do what is
necessary for IPv4 to keep the lights on).  Activity working on getting
equipment to utilize 240/4 seems like a lot of effort.

I am not contending that the space will not have some influence on IPv4
"prices", but I am not sure if the IETF is the right place to attempt and
control market forces and the IPv4 Futures Market.

Victor K

---

From: Russ Housley <[email-masked]>
Date: Sat, 3 Dec 2011 18:53:45 -0500

Ralph:

> Is there evidence that there are deployments today of devices that use addresses in 10.64.0.0/10?

I have seen addresses in this space used.

Russ

---

From: Doug Barton <[email-masked]>
Date: Sat, 03 Dec 2011 16:08:57 -0800

On 12/2/2011 8:50 PM, Ross Callon wrote:
>>> If a customer uses a CGN-specific allocation on the inside of
>>> their network as if it were RFC 1918 space, then, yes, they will
>>> have trouble if they ever use a provider that uses a CGN.
>> 
>> Thanks. So my point is, this proposed allocation doesn't solve
>> anything, it just kicks the can down the road a while. That's not
>> enough benefit to justify the cost.
> 
> We write standards. Our RFCs that specify protocols or best current
> practices contain statements along the lines of MUST or MUST NOT (and
> yes other documents also may use this terminology). People who
> implement or who deploy products could at least in principle ignore
> some of these statements, and implement or deploy equipment in ways
> that violate the MUST and MUST NOT statements in our documents. When
> they do this, bad things may happen.
> 
> This is not a valid reason for us to stop writing standards, nor to
> stop putting MUST statements in our standards.

To a certain extent of course you're right. But that's not the question
before us. This is a resource allocation question. More particularly,
it's a scarce resource, and making that allocation will have costs. So
it's incumbent on us to do a cost::benefit analysis to determine whether
the benefits of doing the allocation justify the costs. (I'm not trying
to talk down to anyone here, I'm just repeating what I think we all know
in order to take the conversation out of the abstract world that you're
describing and put it back into the concrete world of this particular
question.)

So in regards to this particular resource allocation in order to
determine what should be on the benefit side of the ledger we ask
ourselves the question, "Will this allocation solve the problem that it
attempts to solve?" (Note, I'm purposely ignoring the preliminary
questions, such as, "Is this a problem we _want_ to solve?") The answer,
for better or worse, is "No." 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.

So because the benefits of doing the allocation are spotty at best, and
the cost is high, we shouldn't do it.

Q.E.D.

Doug

--

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 04 Dec 2011 10:11:46 +0900

> it, Sell it, put it in....).

Remember that the current IPv6 is not operational, because of
implosions of ICMPv6 packet too big generated against multicast
packets, which means it takes time to fix ICMPv6 operational
before "Built it, Ship it, Stock it, Sell it, put it in...."

> I would also hope that when we have an

Thus, it is easier to expand IPv4 address space using port
numbers as specified in RFC3102:

   RSIP is intended as a alternative to NAT in which the end-
   to-end integrity of packets is maintained.

or something like that, which is recently called port restricted
IP.

> equipment to utilize 240/4 seems like a lot of effort.

The problem is that IPv6 is broken, which means its
deployment is meaningless until it is fixed.

The multicast PMTUD example above is just an example and
there are other problems in IPv6 specification.

> but I am not sure if the IETF is the right place to attempt and

Instead, from my experience to fix the so obvious multicast
PMTUD problem within IETF, I'm sure IETF is not the right
place to attempt to fix IPv6, which means IPv6 is hopeless.

						Masataka Ohta

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Dec 2011 14:22:58 +0000

I am not sure why 10.64.0.0/10 is being discussed instead of 10.128/10 or 10.192/10... but let's assume we picked 10.192.0.0/10 instead.  I'm sitting at home and my laptop currently has this interface:
	inet 10.2XX.XXX.XXX netmask 0xffffff00 broadcast 10.2XX.XXX.XXX

[specific digits replaced with "X" for paranoid reasons in case my IT dept. freaks]

Note that's a VPN connection interface not on-the-wire, but it shows at least my company uses that space, and I know my company uses 10.x.x.x as well as 172.16/12 in their various internal HQ and branch office networks.

In fact, this is my laptop's netstat -r output for IPv4 (again somewhat anonymized):
default            192.168.1.1        UGSc           12        0     en1
10.3X.XXX/24       link#9             UC              1        0   vnic1
10.3X.XXX.XXX      0:1c:42:0:0:9      UHLWIi          1        5     lo0
10.2XX.XXX/24      link#8             UC              1        0   vnic0
10.2XX.XXX.XXX     0:1c:42:0:0:8      UHLWIi          1        5     lo0
127                localhost          UCS             0        6     lo0
localhost          localhost          UH              0      393     lo0
169.254            link#5             UCS             0        0     en1
172.30.0.0         10.0.XXX.XXX       UH              0        0    gif0
172.30             gif0               USc             1        0    gif0
192.168.1          link#5             UCS             2        0     en1
192.168.1.1        0:12:17:e1:8e:ab   UHLWIi         13        2     en1   1166
192.168.1.102      c4:2c:3:2:c5:ee    UHLWIi          0       39     en1   1179
192.168.1.107      localhost          UHS             1        1     lo0

So you tell me how safe picking a specific RFC 1918 address space is.  There are ~100,000 enterprises with over 100 employees just in the US, and ~20,000 with over 500 employees in the US.  Obviously my company is a tech company so it's probably not "normal", but still it seems obvious enterprises use random 10.x.x.x and 172.16/12.

-hadriel

---

From: Pete Resnick <[email-masked]>
Date: Sun, 4 Dec 2011 20:23:50 -0600

> So you tell me how safe picking a specific RFC 1918 address space is.  There are ~100,000 enterprises with over 100 employees just in the US, and ~20,000 with over 500 employees in the US.  Obvious…

AFAICT, it *isn't* safe to use these addresses if and only if these 
enterprises *also* use equipment that can't deal with 1918 addresses on 
their external interface. For example, your machine taking a 
10.2xx.xxx.xxx address isn't a problem in and of itself because the NAT 
in front of you is translating. The issue only arises if the Carrier 
Grade NAT in front of you is on the other side of equipment that *can't* 
handle that portion of address space on the outside.

Now, I don't know if that means it *is* safe. I don't know how many 
enterprises talk to CGNs and wouldn't be able to deal with a particular 
block of 1918 addresses on the outside. That's the question I'd really 
like an answer to but haven't seen yet.

pr

---

From: Pete Resnick <[email-masked]>
Date: Sun, 4 Dec 2011 20:40:10 -0600

On 12/2/11 12:06 PM, Ted Hardie wrote:
> I think there is an unstated premise in Pete's question that the set 
> of customers behind that legacy gear has a stable usage pattern of 
> private addresses.  That is, if the current set of customers behind 
> that legacy gear uses 10/8 then use of any other RFC 1918 address on 
> the CGN is "safe".  I do not think that is a safe assumption.

Nope, but your close. The assumption in my question is that if the 
legacy (broken?) gear in question all uses 10/8 *and* we publish a 
document that declares a particular (presently unused by said gear) 
block of 1918 address space is henceforth off limits to use in equipment 
that can't translate when addresses are identical on the outside and the 
inside, then the use of that 1918 address space might be "safe" for CGNs 
to use. I do not presume that it *is* safe; only that the question has 
not been answered.

> I also strongly suspect that any vendor in its collective right mind 
> which had available a solution like using 172.16/12 would have done so 
> long before enduring the pain of being nibbled to death by the IETF's 
> ducks.  It's not like these guys haven't read RFC 1918 and simply 
> assumed 10/8 was the only network available.

I actually suspect that they didn't consider the possibility of 
documenting/declaring something like 172.16/12 only for use in cases 
where the NAT could deal with it on the inside and outside. Maybe they 
did. Again, I haven't heard one way or the other.

pr

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Dec 2011 22:09:32 -0500

I've seen many enterprise customers using RFC 1918 address space internally.  This includes allocating 10/8 addresses for hosts, and 172.16/12 for isolated segments behind firewalls.  Since 192.168/16 may be used by employees in their homes accessing the corpnet, often this block is avoided for use in address allocation on VPN servers.  

In terms of NAT usage in enterprise, it is very common: in branches, employee homes, campuses, even in data center load balancers (reverse NAT).  It is quite common to see RFC 1918 space of all types in enterprise routing tables. Given the huge influx of mobile devices (many of which do not support IPv6 fully), there will be even more pressure to deploy RFC 1918 addresses and more efficiently use routable address space.

In general, enterprise addressing plans are developed and changed deliberately and with considerable planning. Where things become more tricky is in Extranet design where connections can be made to partners with their own addressing complexities.  To avoid routing issues fire gaping may be required. 

On Dec 4, 2011, at 21:24, "Pete Resnick" <[email-masked]> wrote:

> AFAICT, it *isn't* safe to use these addresses if and only if these enterprises *also* use equipment that can't deal with 1918 addresses on their external interface. For example, your machine taking a 10.2xx.xxx.xxx address isn't a problem in and of itself because the NAT in front of you is translating. The issue only arises if the Carrier Grade NAT in front of you is on the other side of equipment that *can't* handle that portion of address space on the outside.
> 
> Now, I don't know if that means it *is* safe. I don't know how many enterprises talk to CGNs and wouldn't be able to deal with a particular block of 1918 addresses on the outside. That's the question I'd really like an answer....
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 05 Dec 2011 13:20:11 +0900

> The assumption in my question is that if the legacy (broken?) gear in
> question all uses 10/8 *and* we publish a document that declares a
> particular (presently unused by said gear) block of 1918 address space
> is henceforth off limits to use in equipment that can't translate when
> addresses are identical on the outside and the inside, then the use of
> that 1918 address space might be "safe" for CGNs to use.

might require a cpe change.  about the same change as for the cpe to
recognize new/10 as non-public.

randy

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Dec 2011 00:28:56 -0500

--On Sunday, December 04, 2011 20:40 -0600 Pete Resnick
<[email-masked]> wrote:

>...
> Nope, but your close. The assumption in my question is that if
> the legacy (broken?) gear in question all uses 10/8 *and* we
> publish a document that declares a particular (presently
> unused by said gear) block of 1918 address space is henceforth
> off limits to use in equipment that can't translate when
> addresses are identical on the outside and the inside, then
> the use of that 1918 address space might be "safe" for CGNs to
> use. I do not presume that it *is* safe; only that the
> question has not been answered.

Then the document we should be discussing and approving should
say "even if you were dumb enough to but and deploy in the past,
devices that don't have a clear and well-documented way to
perform address translation while using the same addresses on
the inside and outside have no future, especially in IPv4.  They
should not be expected to work in reasonable ISP
configurations".   

Whether we can or should also provide advice about address
ranges for older devices that cannot be upgraded is another
issue.  But it is not a very interesting one because:

If you advise using some piece of the 1918 space, you can only
say "We aren't aware of anyone using this space under so-and-so
circumstances" and not "We can prove that no one is using that
space".

If you advise using a newly-dedicated block, you can only say
"We have allocated this block for this purpose. and no one can
legitimately use it for anything else".  You cannot say, "It is
safe to use that new block without careful design and good
implementations because we are sure that no one has squatted one
it, no one has anticipated the allocation, no one is trying to
use it in layers, and no one is going to accept a routing
announcement for it".

I also don't know quite how to parse your conditions above
because the only legacy one-many IPv4 NAT gear I've used that
doesn't permit using the same addresses "inside" and "outside"
use parts of the 192.168/16 space, not 10/8.  The devices I've
encountered that use 10/8 instead are able to handle those
duplicate addresses although the mechanism for configuring it
may not be very well explained in documentation.  That
information is, however, worthless to you because it is
completely anecdotal and doesn't say a thing about the
particular devices you are looking for.

   john

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 5 Dec 2011 09:59:14 +0100

Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Mon, Dec 05, 2011 at 12:28:56AM -0500 Quoting John C Klensin ([email-masked]):

	(John, this is more of a general rant than a reply directly 
	 to you. Please accept apologies for the kidnapping..) 
 
> circumstances" and not "We can prove that no one is using that

We can also say "This space is quite possibly used on the inside
of customer-managed devices and thus might create routing system
confusion. As with all use of non-unique address space, the responsibility
falls on the communicating parties to coordinate their address block
utilisation so as to avoid damaging amounts of ambiguity."

I did 1918 coordination in joint venture networks 12 years ago, and felt
the pain. If I did, then,  being the wet-behind-the-ears can-do optimist
that I was, why is it that nobody more sane in the industry realised it?

I find it repulsive to excessively pamper the late-comers to something
that we've KNOWN was going to happen for 15 years. 

draft-weil-shared-transition-space-request should be rewritten to offer,
say, 172.28/16, as "Mostly used between CPE and CGN" and we all should
move on to deploying IPv6 and get the ops warts out of it.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... the MYSTERIANS are in here with my CORDUROY SOAP DISH!!

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Dec 2011 10:11:37 -0500

--On Monday, December 05, 2011 09:59 +0100 Måns Nilsson
<[email-masked]> wrote:

> Subject: Re: Consensus Call:
> draft-weil-shared-transition-space-request Date: Mon, Dec 05,
> 2011 at 12:28:56AM -0500 Quoting John C Klensin
> ([email-masked]):
> 
>> say "We aren't aware of anyone using this space under
>> so-and-so circumstances" and not "We can prove that no one is
>> using that space".
> 
> We can also say "This space is quite possibly used on the
> inside of customer-managed devices and thus might create
> routing system confusion. As with all use of non-unique
> address space, the responsibility falls on the communicating
> parties to coordinate their address block utilisation so as to
> avoid damaging amounts of ambiguity."
> 
> I did 1918 coordination in joint venture networks 12 years
> ago, and felt the pain. If I did, then,  being the
> wet-behind-the-ears can-do optimist that I was, why is it that
> nobody more sane in the industry realised it?
>...

Måns,

No apology needed; I certainly agree with the general thrust of
your rant... and that is part of what makes me impatient with
this discussion.

I'll let the co-authors speak for themselves, but the issues
with overlapping "private" spaces and the problems that would
occur with mergers and acquisitions, with attempts to use such
networks as semi-private arrangements among organizations as
well as edge network for the public Internet (including joint
ventures), etc., were certainly discussed when 1918 was adopted
and, I think, pretty well understood at the time.    Before we
started worrying actively about address conservation and
aggregation in the early 90s, the general advice to users of
TCP/IP was that they obtain and use "public" space because
networks that were designed to be isolated from the public
network often ended up attached to it, mergers, joint ventures,
and the like happened, and so on -- precisely to avoid this set
of issues.  The argument for 1918 came down to the belief that
people who saw themselves as running private networks and who
perceived it is being too hard to get public space would do bad
things (like address squatting) if address ranges were not
reserved for private use.  

>From my point of view, that leads to two conclusions: (1)
Implementations of devices that are designed around 1918 ranges
but that cannot handle the same ranges "inside" and "outside"
are defective and have been defective since day 1.  (2) Trying
to compensate for those deficiencies by adding more dedicated
shared-private space (or even trying to repurpose existing
shared-private space) will accomplish very little in the grand
scheme of things: as soon as someone tries to layer CGN
arrangements or two ISPs merge and try to merge infrastructures,
we will back into either the difficult problems to which you
refer, a demand for yet another address pool, or forced
renumbering.  My belief --which this discussion has only
strengthened -- is not only that we need to stop trying to
support old and broken-since-birth implementations, but, when
address conflicts are discovered, the only healthy solution is
to fix the problems, not layer kludges on kludges in the hope
that it will be "long enough" before another layer is needed.

While I recognize the off-repeated costs of replacing CPE, we've
been telling people for years that forced-renumbering is a
plausible option.   If we believe it, then renumbering either
the "outside" or the "inside" networks or both should be
practical.  If it is expensive and/or painful, perhaps it is
sensible to give affected end-network customers a choice between
renumbering and paying some of the costs of upgraded equipment
(or of rapid migration to IPv6, even if that effectively
involves both renumbering and new CPE).

    john

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 5 Dec 2011 08:37:23 -0800 (PST)

> recognize new/10 as non-public.

Maybe I'm missing something, but why would CPE need to recognize a 
new /10 CGN block as non-public?  Isn't the whole idea to leave the 
CPE unchanged and get the CGN boxes (and the rest of the core 
network infrastructure) to recognize the /10 CGN block as 
non-routeable?

//cmh

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 05 Dec 2011 09:07:24 -0800

> network infrastructure) to recognize the /10 CGN block as 

Existing cpe supporting some applications treat public space differently
than private. e.g. in the context of 6to4, upnp igd, dynamic dns
registration and so on.