Subject: Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 07:44:55 -0800

At 03:03 PM 1/30/2012, The IESG wrote:
>The IESG has received a request from an individual submitter to 
>consider the following document:
>- 'IANA Reserved IPv4 Prefix for Shared CGN Space'
>  <draft-weil-shared-transition-space-request-14.txt> as a BCP
>
>On its December 15, 2011 telechat, the IESG reviewed version 10 of this
>document and requested various changes. These changes are reflected in
>the draft version 14 and the IESG now solicits community input on the
>changed text only. Please send substantive comments to the [email-masked]
>mailing lists by 2012-02-16. Exceptionally, comments may be sent to

Is that a two-weeks Last Call?

Will the determination of consensus be made only on the basis of this 
Last Call?

In Section 3:

   "A Service Provider can number the interfaces in question from
    legitimately assigned globally unique address space.  While this
    solution poses the fewest problems, it is impractical because
    globally unique IPv4 address space is in short supply."

Unique IPv4 address space is not in short supply in some regions.  If 
it is globally in short supply, I gather that several regions have 
already reached their IPv4 Exhaustion phase.  I haven't seen any 
announcements about that.

   "While the Regional Internet Registries (RIR) have enough address
    space to allocate a single /10 to be shared by all Service Providers,
    they do not have enough address space to make a unique assignment to
    each Service Provider."

The above is incorrect as RIRs are still providing unique IPv4 
assignments to service providers that request IPv4 addresses.  On 
reading this draft, I conclude that as IPv4 addresses are nearly 
exhausted, the only option left is to deploy Carrier Grade NAT 
instead of requesting IPv4 addresses from a RIR.

For the determination of consensus, I do not support this proposal.

Regards,
-sm

---

From: Chris Grundemann <[email-masked]>
Date: Thu, 9 Feb 2012 09:57:56 -0700

On Thu, Feb 9, 2012 at 08:44, SM <[email-masked]> wrote:

> Unique IPv4 address space is not in short supply in some regions.  If it is
> globally in short supply, I gather that several regions have already reached
> their IPv4 Exhaustion phase.  I haven't seen any announcements about that.

http://www.apnic.net/publications/news/2011/final-8
http://www.coisoc.org/index.php/2011/internet-society-statement-on-apnic-ipv4-depletion/
http://www.apnic.net/community/ipv4-exhaustion/ipv4-exhaustion-details
http://isoc.org/wp/newsletter/?p=3592

> The above is incorrect as RIRs are still providing unique IPv4 assignments
> to service providers that request IPv4 addresses.  On reading this draft, I
> conclude that as IPv4 addresses are nearly exhausted, the only option left
> is to deploy Carrier Grade NAT instead of requesting IPv4 addresses from a
> RIR.

Are you proposing that every ISP on the planet be given a /10 for
inside CGN use, rather than one single /10 being reserved for this
purpose?

Cheers,
~Chris

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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org

---

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 09:59:28 -0800

Hi Chris,
>http://www.apnic.net/publications/news/2011/final-8

I am aware of the APNIC announcement.  That's one out of five regions.

>inside CGN use, rather than one single /10 being reserved for this

No.

If I am not mistaken, IPv4 assignments are on a needs basis.  In my 
previous comment, I mentioned that RIRs are still providing unique 
IPv4 assignments to service providers that request IPv4 
addresses.  Even if the IANA pool was not exhausted, it is unlikely 
that an ISP would get a /20 due to the slow-start mechanism.

Regards,
-sm

---

From: Chris Grundemann <[email-masked]>
Date: Thu, 9 Feb 2012 12:14:11 -0700

> I am aware of the APNIC announcement.  That's one out of five regions.

My apologies, when you stated "I haven't seen any announcements about
that." I thought you were not. Hopefully others found the link useful.

> If I am not mistaken, IPv4 assignments are on a needs basis.  In my previous
> comment, I mentioned that RIRs are still providing unique IPv4 assignments
> to service providers that request IPv4 addresses.  Even if the IANA pool was
> not exhausted, it is unlikely that an ISP would get a /20 due to the
> slow-start mechanism.

In the ARIN region, slow-start only applies to new-to-ARIN
organizations. Most (if not all) of the ISPs we're discussing here are
established entities and are not subject to slow start.

More to the point: I do not see giving everyone a unique bit of space
for inside CGN use as an efficient solution to the problem. Likewise,
waiting until we are completely out of IPv4 space before reacting to
the problems that IPv4 free pool exhaustion WILL cause seems _very_
unlikely to produce positive results.

Cheers,
~Chris

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 9 Feb 2012 15:40:13 -0500

SM,

At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs ask for a /10 for CGN, we burn one of those /8s.

Is that really a good idea?

                              Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> SM
> Sent: Thursday, February 09, 2012 10:45 AM
> To: [email-masked]
> Subject: Re: Last Call: <draft-weil-shared-transition-space-request-
> 14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
>

---

From: David Conrad <[email-masked]>
Date: Thu, 9 Feb 2012 12:59:14 -0800

Ron,

> Is that really a good idea?

Long ago, I once proposed a policy at ARIN to try to extend the IPv4 runway.  One of the most common responses I received (including from several members of ARIN's AC) was "let it run out naturally", with the rationale being either:

a) "it'll force people to move to IPv6"
b) "we spent a lot of money to prepare for IPv6 because we knew it was coming soon, we don't want to give our competitors who fiddled the summer away more time"

I suspect those people would answer "yes" (well, unless their opinions have changed as reality starts biting).

Regards,
-drc

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 9 Feb 2012 22:02:47 +0100

> Is that really a good idea?

It's not about good or bad idea, it should be more about; If they can
justify having a /10 each then they should get it. And yes, that will
hurt.

... wish people could use more time to move on instead of trying to
squeeze even more out of the good old, dry and dead dog called IPv4.

With all of that said, giving out this shared address space is a
horrible idea, but it just a little bit less horrible than the
alternates.
And yes it will be abused and be counted as yet another RFC1918 space
anyway. I know of plenty of people that will be trilled for this
space... "woho, no more address collision" while they quiet think "I
hope no one else know about this address space...."

in other word, move on, give out this space, it'll hurt just a little
bit less than the other options.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Chris Grundemann <[email-masked]>
Date: Thu, 9 Feb 2012 14:17:29 -0700

> I suspect those people would answer "yes" (well, unless their opinions have changed as reality starts biting).

Being one of the people who believe that IPv4 should run out
naturally, I can tell you that my answer is "no." Natural-run-out and
waste are not synonymous.

Cheers,
~Chris

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2012 09:40:40 +1100

> that an ISP would get a /20 due to the slow-start mechanism.

In none of the discussions I've seen has anyone proposed forcing ISP's
to use this space.  It is being provided as a alternative, the same
away RFC 1918 space is offered as a alternative.

Today you get ask "have you considered RFC 1918 space?"  You can
still get space even if RFC 1918 space would have worked.  I suspect
a similar question, will be part of allocation proceedures, for this
space in the future.  You need to know that the applicant is aware
of this space.

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

---

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 14:40:18 -0800

Hi Ron,
At 12:40 PM 2/9/2012, Ronald Bonica wrote:
>At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just 
>four ISPs ask for a /10 for CGN, we burn one of those /8s.
>

The short answer is no.

The long answer is a bit complicated as it would be difficult to 
justify efficient utilization of a /10 within a three-month time 
frame.  There are also specific policies which can be used to get a /10.

 From an IETF perspective, I understand that the IESG is faced with a 
difficult decision and I respect its decision.

I note that Chris Grundemann has been fair when we interacted in a 
non-IETF venue.

Based on the above, I'll keep the -1 for the determination of consensus.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Feb 2012 20:17:35 -0500

--On Thursday, February 09, 2012 15:40 -0500 Ronald Bonica
<[email-masked]> wrote:

> SM,
> 
> At NANOG 54, ARIN reported that they are down to 5.6 /8s. If
> just four ISPs ask for a /10 for CGN, we burn one of those /8s.
> 

Ron,

I've mostly been staying out of this since an earlier round, but
that question/ scenario seems pretty irrelevant to me.    If
four ISPs ask for (and can justify) /10s to serve customers, or
a larger number asks for smaller allocations that add up to the
same thing, we burn a /10 equally quickly.   I think the real
answer to questions like the one you ask is another question:
Suppose there is a strategy that delays, by (say) six months or
a year, the date that ARIN (for example) runs out of
useful-sized blocks to allocate, it is worth doing something
strange or pathological just to gain that extra time?  I think
the answer to that question is "no", regardless of how one
defines "strange or pathological", because a year of traditional
IPv4 allocations from the RIRs one way or the other is quite
unlikely to make a major different to the Internet.

I'm not claiming this proposal is either strange or pathological
(or that it is not).  But I suggest that the decision be made on
the same basis that other allocation decisions are made, not by
trying to save a few months or by deciding that some types of
applications or applicants are inherently more privileged than
others regardless of their actual merits. 

      john

---

From: Doug Barton <[email-masked]>
Date: Thu, 09 Feb 2012 22:47:16 -0800

On 01/30/2012 15:03, The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider the following document:
> changed text only.

As I (and many others) remain opposed to this entire concept I think
it's incredibly unfortunate that the IESG has decided to shift the topic
of conversation from "whether" this should happen to "how" it should
happen. But comments more to the point below ....

> Please send substantive comments to the [email-masked] 
> [email-masked] instead. In either case, please retain the beginning of 
> the Subject line to allow automated sorting.
> 
> Abstract
> 
>   This document requests the allocation of an IPv4 /10 address block to
>   be used as Shared Address Space to accommodate the needs of Carrier
>   Grade Network Address Translation (CGN) devices.  It is anticipated
>   that Service Providers will use this Shared Address Space to number
>   the interfaces that connect CGN devices to Customer Premise Equipment
>   (CPE).
> 
>   Shared Address Space is distinct from RFC1918 private address space
>   because it is intended for use on Service Provider networks.
>   However, it may be used as RFC 1918 private address space in certain
>   circumstances.  Details are provided in the text of this document.
> 
>   As this document proposes the allocation of an additional special-use
>   IPv4 address block, it updates RFC 5735.
> 
> The following text captures the most salient change between version 10 and 14 of this document:
> 
>   Shared Address Space is IPv4 address space designated for Service
>      Provider use with the purpose of facilitating CGN deployment.  Also,
>      Shared Address Space can be used as additional [RFC1918] space

I think it's a feature that we're finally willing to admit that this new
block is going to be used as 1918 space. Given that previous requests
for new 1918 space have been (rightly) denied, I think this document
should describe why this request is better/more important than previous
requests, and what the bar will be for future requests for new 1918 space.

> when
>      at least one of the following conditions is true:
> 
>      o  Shared Address Space is not also used on the Service Provider side
>         of the CPE.
> 
>      o  CPE routers behave correctly when using the same address block on
>         both the internal and external interfaces.

When I previously proposed this as *the* proper solution I was told that
it wasn't in any way practical. Now that we're apparently willing to
discuss it as *a* possible solution one wonders why a new block is
necessary at all.

Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

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

---

From: Chris Donley <[email-masked]>
Date: Fri, 10 Feb 2012 08:47:23 -0700

>space in the future.  You need to know that the applicant is aware
Please remember that this draft is in support of ARIN Draft Policy 2011-5.
Should this draft become an RFC, and should ARIN pony up the /10, ARIN's
staff is likely to look askance at requests for address space for CGNs.
IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how
to allocate space; the ARIN/RIR policy processes can be much more targeted
to the needs of the community, and in this case, I think your concern has
already been addressed.

Chris

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Feb 2012 13:15:40 -0500

--On Friday, February 10, 2012 08:47 -0700 Chris Donley
<[email-masked]> wrote:

>... 
> Please remember that this draft is in support of ARIN Draft
> Policy 2011-5. Should this draft become an RFC, and should
> ARIN pony up the /10, ARIN's staff is likely to look askance
> at requests for address space for CGNs. IMO, an IETF RFC is
> not the correct place to tell ARIN or other RIRs how to
> allocate space; the ARIN/RIR policy processes can be much more
> targeted to the needs of the community, and in this case, I
> think your concern has already been addressed.

Chris,

To follow up on an earlier comment, the rate at which ARIN (or
other RIRs) are running out of /10s (or /8s) is probably
irrelevant, as are hypotheses about what ARIN staff might do
about requests for allocation for CGN use with or without this
policy/ block.

But, since people want to talk about it in those terms, I'd be
interested in some real data and projections.  In particular,
how many large ISPs have expressed significant interest in this,
where "large" is defined as "big enough that an application for
a /10 would be taken seriously".  Now, if one /10 block is
allocated to this use versus all of those ISPs applying for
separate ones, how much does that change the likely date at
which all of the currently-unallocated /8s are exhausted.   

If that difference is less than years, I, personally, don't
think that particular argument is useful.   Other arguments may
be, but not that one.

     john

---

From: Chris Grundemann <[email-masked]>
Date: Fri, 10 Feb 2012 11:22:27 -0700

> which all of the currently-unallocated /8s are exhausted.

This is not about IPv4 life-support. This is about providing the best
answer to a difficult problem. Run-out date is not nearly as important
as efficient use at this point. It is not efficient for multiple ISPs
to use different space when a shared space will function optimally.

> think that particular argument is useful.   Other arguments may

Please see https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space
for a more thorough analysis of the motivations, pros, cons, and
alternatives for this shared CGN space. I think you'll find that those
other arguments are laid out there.

Cheers,
~Chris

-- 
@ChrisGrundemann
http://chrisgrundemann.com

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Feb 2012 14:29:24 -0500

> This is not about IPv4 life-support. This is about providing
> the best answer to a difficult problem. Run-out date is not
> nearly as important as efficient use at this point. It is not
> efficient for multiple ISPs to use different space when a
> shared space will function optimally.

Indeed, although I note that it isn't a huge step from the above
to get to "we could really make _much_ more efficient use of
IPv4 space by partitioning the Internet into regions and using
explicit routing or X.75-like gateways to route traffic between
regions, thereby permitting each region to use almost all of the
IPv4 space".  One could even use CGNs to establish that model
with each ISP using almost the entire IPv4 space inside its
castle walls.    Now, I think either of those would be terrible
ideas but, as you and others are probably aware, people who
believe themselves to be serious and competent have proposed
them, almost exactly  

Anything that moves us closer to those models gives me visions
of slippery steep cliffs and the creeps, so I feel a need to be
careful about efficiency arguments too.   YMMD, either because
you see the efficiency arguments differently, because you have
reason to be less afraid of an ultimate "islands connected by
gateways" outcome, or for other reasons.

>> think that particular argument is useful.   Other arguments
>> may be, but not that one.
> 
> Please see
> https://tools.ietf.org/html/draft-bdgks-arin-shared-transition
> -space for a more thorough analysis of the motivations, pros,
> cons, and alternatives for this shared CGN space. I think
> you'll find that those other arguments are laid out there.

I have and I agree those arguments are there (their interaction
with my fear of the scenarios above is another matter).  Again,
my main suggestion was that we just stop the discussions based
on allocation strategies or IPv4 exhaustion alone... because
they are distractions rather than helpful.

     john

---

From: Doug Barton <[email-masked]>
Date: Fri, 10 Feb 2012 14:09:47 -0800

> Please remember that this draft is in support of ARIN Draft Policy 2011-5.

Partially, sure. But RFCs apply to the whole Internet.

> to allocate space;

I'm not going to parse the nuances of what you wrote, but I think
generally you're wrong.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Fri, 10 Feb 2012 14:13:49 -0800

On 02/10/2012 10:22, Chris Grundemann wrote:
> This is not about IPv4 life-support.

Seriously?

> This is about providing the best answer to a difficult problem.

The best answer is to make sure that CPEs that will be doing CGN can
handle the same 1918 space inside the user network and at the CGN layer.

Doug

--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2012 12:31:49 +1300

> Partially, sure. But RFCs apply to the whole Internet.

Hear hear.

> I'm not going to parse the nuances of what you wrote, but I think

The RIRs get their space from IANA@ICANN, so s/ARIN/ICANN/ and
read clause 4.3 of RFC 2860 carefully.  The IAB decided that
the current issue *is* the IETF's business under that clause.

   Brian

---

From: Pete Resnick <[email-masked]>
Date: Fri, 10 Feb 2012 15:42:31 -0800

On 2/9/12 10:47 PM, Doug Barton wrote:

> happen.

As an AD who is now comfortable with going forward with the document, I 
do want to point out that the IESG as a whole has *not* come to 
consensus on this document. There are still not the required number of 
"Yes" or "No objection" ballots for the document to move forward. So I 
don't think it's accurate to say that the IESG is only deciding "how" it 
should happen.

> block is going to be used as 1918 space.

I expect there will be clarifications as per the earlier messages in 
this thread: This is *not* to be used as additional 1918 space. (See my 
message of 2/1/12 4:33 PM -0600. ) 1918 space is guaranteed to be 
private, and devices have been built that have made the assumption that 
the space is private and they will not see it on a network that is not 
within its administrative control. This proposed space is most assuredly 
not that. It's shared and therefore has additional constraints on use 
that 1918 space does not. It is certainly *similar* to 1918 space in 
that it is not globally routeable, but it is not 1918 space.

> Given that previous requests

I hope it does, and if it is not sufficient, I expect text will be 
accepted by the authors. In particular, the text suggested in the 
aforementioned message was:

    Shared Address Space is similar to [RFC1918] private address space in
    that it is not global routeable address space and can be used by
    multiple pieces of equipment. However, Shared Address Space has
    limitations in its use that the current [RFC1918] private address
    space does not have. In particular, Shared Address Space can only be
    used on routing equipment that is able to do address translation
    across router interfaces when the addresses are identical on two
    different interfaces.

> discuss it as *a* possible solution one wonders why a new block is

See above paragraph.

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: Fri, 10 Feb 2012 15:57:03 -0800

> don't think it's accurate to say that the IESG is only deciding "how" it

I suppose that's some small comfort.

> this thread: This is *not* to be used as additional 1918 space.

The following is not meant to be a snark (nor is anything else I've
written on this topic, for that matter), but I think it's a huge problem
that you think *saying* "Don't use this as 1918 space" is going to make
any difference at all.

> I hope it does,

For my money, it does not.

> and if it is not sufficient, I expect text will be

So if we're saying the same thing about CPEs capable of doing CGN
needing to understand the same block(s) on the inside and outside, why
is the new block necessary?

Doug

--

---

From: Chris Grundemann <[email-masked]>
Date: Fri, 10 Feb 2012 17:12:31 -0700

>> This is not about IPv4 life-support.

Seriously.

The birth of a shared CGN space in no significant way extends the life
of IPv4. It does provide the best possible solution to a necessary
evil (CGN inside addresses).

> handle the same 1918 space inside the user network and at the CGN layer.

Are you volunteering to buy everyone on earth a new CPE? If not, who
do you suggest will? My bet is that no one is willing to drop the
billions of dollars required - if they were, we could just sign
everyone up for IPv6 capable CPE and skip the whole debate... ;)

Cheers,
~Chris

---

From: Doug Barton <[email-masked]>
Date: Fri, 10 Feb 2012 16:23:47 -0800

> evil (CGN inside addresses).

Ok, now THIS is a snark:  Dude, don't bogart the good stuff, pass it
around man. </snark>

We were specifically asked not to reopen the debate on the necessity of
CGN to start with, so I won't go there .... feel free to dig through the
archives on all the reasons why this evil isn't actually necessary.

> everyone up for IPv6 capable CPE and skip the whole debate... ;)

Everyone doesn't need a new one. In fact, the only end users who need
new ones are those behind ISPs that chose to ignore IPv6, "need" to
deploy CGN, and can't actually get CGN done with existing 1918 space. I
strongly suspect that the latter number will be very small, and what
this allocation request is really about is to make lives easier (read,
cheaper) for those that didn't want to invest in IPv6, and now don't
want to have to think hard about how they do their network design.

It's also in no way clear to me how many extant CPEs would break if CGN
were deployed with 1918, and/or how many of the extant CPEs will have to
be replaced anyway to do CGN in the first place. Repeated requests for
hard data on this (by me and others) have gone unanswered, I suspect
because collecting such data would also be expensive.

Doug

--

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 11 Feb 2012 01:25:46 +0100

> evil (CGN inside addresses).

We do not need another reason for people to delay v6 deployment. Just
saying "this isn't about sticking your head in the sand" does not make
it any more so. This _will_be_used_ as an excuse for not rolling out v6. 

> everyone up for IPv6 capable CPE and skip the whole debate... ;)

There are more than 1 prefix in RFC1918. Tell the customers to use
another one than the one you inflict on them as bad excuse for not
doing v6 quick enough. That there will be increased support load on any
provider not giving customers public space is a suitable punishment for
above mentioned failure to deliver v6.

I still strongly oppose the publication of this draft. In any form except
a complete rewrite telling providers to use RFC1918 and be done with it.

-- 
Måns, sadly enough not surprised by the fact 
      that this bad idea still isn't properly killed.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 10 Feb 2012 16:47:33 -0800

> it any more so. This _will_be_used_ as an excuse for not rolling out v6.

+1. This is all business. Companies have made their choices.

> a complete rewrite telling providers to use RFC1918 and be done with it.

This is the logical path for the cgn minded. They need to deal with the
challenge of renumbering users.

I also oppose this draft.

Cb

---

From: Pete Resnick <[email-masked]>
Date: Fri, 10 Feb 2012 19:19:34 -0800

On 2/10/12 3:57 PM, Doug Barton wrote:

> The following is not meant to be a snark

Not taken as such.

> ...I think it's a huge problem

Neither the text of the current draft nor the proposed text that Brian 
and I seem to like says "Don't use this as 1918 space", nor do I think 
saying so would be a good idea or make any difference. I apologize that 
I was not clear when I said that it "is *not* to be used as 1918 space". 
What I meant was that the document should be clear that this so-called 
"Shared Address Space" has limitations and can't be used in 
circumstances where 1918 addresses can be used. Now, I am under no 
delusions that some equipment won't *try* to use this new space in ways 
that will cause problems (any more than I think that people won't use 
port numbers for non-registered uses, or won't use bogus SMTP protocol 
return codes, etc.). But like those situations, folks who want to use 
this new address space *don't care* if other people do stupid things 
with it; they're making their own beds and they can lie in them. 
Remember, the whole purpose of using new address space is that the 1918 
space has specific semantics that folks have already implemented and 
deployed in equipment *in compliance with the spec* in that they don't 
NAT what they consider an "outside" address. If people with current 
equipment call and complain when a CGN uses 1918 space and screws up 
their equipment, they've got a legitimate beef. But if new folks start 
using Shared Address Space without NATing it properly, they've only got 
themselves to blame.

The new and suggested text makes this all clear: You can safely use this 
non-globally-routeable Shared Address Space so long as you NAT it on 
both ends. If you don't, you're going to have routing problems. You want 
routing problems? Have at it. I don't care. Like any good IETF spec, 
we're just telling you what the rest of us intend to do.

If the text is not clear, please help.

> For my money, it does not.

Again, text welcome.

> is the new block necessary?

I believe this has been said multiple times before (and is not the 
subject of this Last Call, AFAICT), but: The new block is necessary 
because current equipment, which will be connected to CGNs (or any other 
kinds of devices that use this new space), and which conforms to a 
reasonable interpretation of 1918, is not able to understand the same 
block on the inside and the outside, and therefore will not be able to 
route through CGNs (or other such new equipment) if they used 1918 
space. Again, if the current text is not clear on this point, please 
identify where clarification is needed. (If you disagree with my 
assessment, let's please take that conversation offlist and we can 
figure out where the disagreement is and maybe bring our collective 
wisdom back to the list. And that invitation is to anyone who feels that 
they disagree with the above reasoning. You have my email address.)

pr

---

From: Doug Barton <[email-masked]>
Date: Fri, 10 Feb 2012 19:51:34 -0800

Thanks for your response, mine is below, with snipping.

On 02/10/2012 19:19, Pete Resnick wrote:
> circumstances where 1918 addresses can be used.

I'm sorry, I was trying to be concise in order to not re-open the debate
on the topic of "should," but your response indicates that you're not
seeing my point.

The premise of this draft is that a new block is necessary because the
same prefixes can't be used in the customer network and the CGN layer.
So, let's allocate a new block to use *only* in the CGN layer. That way
it can never conflict.

My point is that no matter how loudly you say, "Don't use this as 1918
space!" some users will do it anyway. There have already been several
requests for more IPv4 1918 space because a non-zero number of end user
networks have run out. So we know that people *will* use this new block
internally. Therefore we can be fairly certain that at some point there
will be a conflict. That means that there is no reason to allocate this
new block.

> But if new folks start

That's interesting ... so you're saying that the people who created the
problem should be responsible for dealing with their own mess? :) More
seriously, you seem to be saying that because the draft says "Don't do
it" it's Ok for us to do the allocation because if someone does screw up
it's not our fault because we told them not to do it. My point is that
because we can see the trap, we shouldn't walk right into it with a
smile on our face.

> If the text is not clear, please help.

I don't think any amount of text-twiddling can help, since I feel that
this is a bad idea from the ground up.

> space.

Yes, that's been *said* multiple times, but it hasn't been backed up
with solid data. OTOH, numerous people (many of whom are in a much
better position to know than I am) have pointed out that the
overwhelming majority of consumer CPE devices use one of 192.168.[01] as
their internal networks. That number is likely to be in the 80% range,
if not much higher. Therefore it's very likely that most of this problem
is solved already if the ISPs simply stay away from those 2 ranges.

What I, and others, have said repeatedly now is that given how easy most
of this problem is to solve, the people who have a fiduciary interest in
solving the rest of it should do so, without asking the rest of the
Internet to subsidize their (arguably flawed) business model.

Or put more simply, if the problem is that CPEs don't know how to deal
with the same block on the inside and outside, there are (at least) 2
ways for the ISPs to solve that which do not involve allocating a new
block.

> Again, if the current text is not clear on this point, please
> wisdom back to the list. 

I appreciate the invitation, but I don't know how much more I can bring
to the topic that I haven't already.

Doug

--

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Feb 2012 10:34:22 -0500

--On Saturday, February 11, 2012 11:00 -0200 Arturo Servin
<[email-masked]> wrote:

> 
> On 10 Feb 2012, at 22:12, Chris Grundemann wrote:
> 
>> Are you volunteering to buy everyone on earth a new CPE? If
>> not, who do you suggest will?
> 
> 	I suggest the ISPs, they are charging for the service, right?

One additional observation about this particular line of
argument.

It seems to me that, to the extent to which this allocation idea
is part of a legitimate IPv6 transition strategy, we should be
listening carefully and with sympathy.  We can still debate
whether it is the best strategy, whether there are better ways
to do the same thing, etc., but I hope there is no one who will
argue against having strategies for moving forward other than
hoping that the world ends before the last IPv4 allocation is
given out by the RIRs.

But, as soon as one suggests that the alternative to this space
request is "volunteering to buy everyone on earth a new CPE", we
aren't talking about transition strategies any more.  If we
assume that end system networks will eventually either be
running IPv6 or that the IPv6-IPv4 transition will occur at
those boundaries, then that CPE equipment will need to be
replaced because most of it doesn't support IPv6.   I suppose an
ISP could be stupid enough to buy CPE now that supports "same
address range inside and outside" but does not support IPv6, but
such an ISP would be much too stupid to survive (with or without
help from us).  

So the CPE will need to be upgraded.  There are potentially
interesting economic discussions about capitalization,
amortization, and deployment rates, but let's not pretend that
this allocation for CGN use is the alternate to replacing CPE --
unless it is really a plan for IPv4 Forever based on layers and
layers of address translation (and this is where I incorporate
my snarky comment about X.75 gateways by reference -- a comment,
I'm pleased to report, a few people have responded to with tales
of painful experiences in past lives).

>...
>> if they were, we could just sign

So, Chris, if you expect this allocation will avoid the costs of
signing everyone up for IPv6-capable CPE, what is your
transition plan?  Or are you advocating an IPv4-forever model?
If the latter, can you explain succinctly to the rest of us how
you expect it to work?

best,
  john

---

From: Chris Grundemann <[email-masked]>
Date: Sat, 11 Feb 2012 12:38:12 -0700

> If the latter, can you explain succinctly to the rest of us how

You snipped the comment I was replying too, and thus the context of my
statement.

What I was replying to was a statement that we should just give
everyone a CPE that could handle the same space inside and outside. My
response was that if we are to replace CPE it should be with IPv6
capable CPE, _not_ CGN tolerant CPE.

What I did not say was anything about prolonging the life of IPv4. In
fact I have argued against that several times, a few in this very
thread.

Hopefully that clears up your confusion.

Cheers,
~Chris

---

From: Arturo Servin <[email-masked]>
Date: Sat, 11 Feb 2012 11:00:04 -0200

On 10 Feb 2012, at 22:12, Chris Grundemann wrote:

> do you suggest will?

> My bet is that no one is willing to drop the
> billions of dollars required -

	Errors cost money. They decided not to invest in IPv6, now there is time to pay.

> everyone up for IPv6 capable CPE and skip the whole debate... ;)

	For many of the reasons stated before, I think this space is not needed and I am against this proposal.

Regards,
/as

---

From: Martin Rex <[email-masked]>
Date: Mon, 13 Feb 2012 17:11:39 +0100 (MET)

John C Klensin wrote:
>Arturo Servin wrote:
>>Chris Grundemann wrote:

If CPE is meant to refer to the border router, then this appears like
a very short-sighted look at the real issue.

There are huge amounts of equipment in use that simply does not support IPv6,
other than border routers, like home multimedia and entertainment stuff
(Nintendo WII, Nintendo DS, Internet-enabled set-top-boxes & TV & Radio,
webcams, home NAS, etc.), which do not support IPv6,
so I don't see how IPv6 could be seen as a solution at all (it isn't).

So everyone who is suggesting IPv6 here, is actually
suggesting NAT 4664 over NAT 444.

-Martin

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Feb 2012 12:47:41 -0500

--On Monday, February 13, 2012 17:11 +0100 Martin Rex
<[email-masked]> wrote:

>>> 	I suggest the ISPs, they are charging for the service,
>>> 	right? ...
>> So, Chris, if you expect this allocation will avoid the costs
>> of signing everyone up for IPv6-capable CPE, what is your
> If CPE is meant to refer to the border router, then this
> appears like a very short-sighted look at the real issue.
> 
> There are huge amounts of equipment in use that simply does
> not support IPv6, other than border routers, like home
> multimedia and entertainment stuff (Nintendo WII, Nintendo DS,
> Internet-enabled set-top-boxes & TV & Radio, webcams, home
> NAS, etc.), which do not support IPv6,

Martin,

I think we have been over this territory before.   It certainly
isn't part of the current Last Call (I've changed the subject
line after it got truncated).

But, briefly and in the faint hope that an explanation from a
slightly different perspective might help, from where I sit it
looks like there are three families of IPv6 migration strategies:

(1) IPv6 packets on core network, replace or upgrade end network
border router to run IPv6, provide IPv6 on end network, expect
all devices on end network to be IPv6-capable (either natively
or dual-stack).    I agree with you that this is completely
unrealistic but it is also a complete strawman -- I know of no
one who understands the issues who is advocating it at this
point.

(2) IPv6 packets on core network, replace or upgrade end network
border router to be able to do protocol conversion address
translation as needed so that IPv4-only devices on the LAN
receive and send IPv4 packets.  That border device presents
public IPv6 addresses to the Internet, not (only) IPv4 addresses
(public or private)  There seem to be dozens of variations on
this theme, with, e.g., varying ideas about what to do about
IPv6-native or dual-stack devices on the LAN and whether to
temporarily provide public IPv4 addresses to the Internet as
well, but the two important things that all of the alternatives
have in common are that a customer with IPv6-capable devices can
reasonably expect to run IPv6 on them (and run them in the
traditional end to end mode with other IPv6 LANs and devices)
and that the translations are, at least in principle, under
customer control.

Note that, especially for ISPs that provide the customer
boundary devices as part of their services, one of the
variations is to install IPv6-only border equipment and tell
customers that, if they want to continue to run IPv4-only
devices, they need to obtain and install conversion boxes behind
the boundary devices (possibly subsidized but basically at their
own expense).  I would find that approach odious, but it is no
more odious than the choice faced by households with older
televisions in countries (or smaller areas) that are going
all-digital.  Indeed, as far as I can tell, it is _exactly_ the
same issue.

(3) IPv6 packets possibly on ISP core networks or at peering/
exchange points, but, other than large customers who can make
their own arrangements, end network border routers all speak
IPv4 (more or less exclusively) and present IPv4 addresses to
the network.  Whatever conversions are needed occur somewhere in
the middle of the network.   It seems to me that there are
several variations on this theme too but, if the motivation for
it includes "don't change any of the equipment on the user site
to be IPv6-capable" then devices on the LAN that are
IPv6-capable can't take advantage of it and devices on the LAN
that are IPv6-only can't operate (note the symmetry between that
situation and the argument you are making).  

Now a problem that some of us are having with CGNs (a member of
the third category but perhaps not the only one, or even only
one architecture), is that it doesn't seem to inherently involve
an IPv6 transition at all.  Maybe there are hybrid strategies
that make them an integral part of an IPv6 transition, but I'm
not sure I see them.  If end system LANs are going to be able to
receive IPv6 packets and/or use them internally then someone is
going to need to incur the cost of purchasing, installing, and
supporting IPv6-capable border equipment.  If avoiding the costs
of that equipment change (regardless of what else the equipment
could do) is a goal of a CGN-based strategy, then there is no
IPv6 transition strategy, only an IPv4 preservation one (and, to
me, one that reinvents many of the strengths and weaknesses of
the traditional PSTN Central Office Switch).

That doesn't mean the IETF should or should not allocate this
shared space block.  If an ISP has decided its best strategy
lies in CGNs (whether they have an IPv6 transition strategy or
the CGNs are code for an IPv4-only network that tied together
walled gardens (walled weed-patches?)), then I assume that,
absent pressures the IETF can't apply, they will do that.  If
they don't think they can use private address space for that
purpose, then either they will get this shared allocation, they
will get private space from the RIRs for running a CGN-based
architecture, or they will squat (well, maybe all three).  I
can't imagine an ISP who had decided on a CGN strategy deciding
to not go forward with it because the IETF (or even the IETF and
the RIRs) are resistant to that plan.    But that is really a
discussion about CDNs, not about the wisdom (or not) of making
this allocation.

   john

---

From: Chris Grundemann <[email-masked]>
Date: Tue, 14 Feb 2012 10:45:04 -0700

Apologies for top posting rather than addressing specific
commentators, but there have been several misconceptions raised
several times that I felt should be addressed generically:

1) "We are out of IPv4 space / There's no-where to get this /10" -
There is already a /10 reserved by the ARIN community for this purpose
(as long as we don't drag our feet too long), please see:
https://www.arin.net/policy/proposals/2011_5.html

2) "Just use 1918 space" - I apologize for not having more data to
share, but I can tell you that I have spoken with numerous network
operators and NONE of them are willing to do this. ISPs will NOT use
RFC 1918 space, no matter how many times folks scream it from the tops
of ivory towers. Operational realities must sometimes trump ideals.

3) "CGN is bad" - This one is accurate. It has no bearing on this I-D
whatsoever though. Yes, CGN sucks and we want as few networks to use
it as possible. But, no matter what we do, some will have to deploy
it. This I-D is about helping reduce everyone's pain when they do.
Leaking squat space hurts more than just the one who leaks it...

4) "IPv6 is awesome" - Again, accurate but inconsequential here. IPv6
does not solve IPv4 connectivity issues. Operators are not solely
responsible for the lack of IPv6 penetration. Rather than throw stones
from our glass houses, we should focus on ensuring that the transition
can happen without shattering all of them.

I understand that many have strong emotional ties to their opinions.
My only hope is to point those with open minds in the right direction
as they seek to understand this issue more fully.

Cheers,
~Chris (speaking for myself, from an ivory tower made of glass)

On Mon, Jan 30, 2012 at 16:03, The IESG <[email-masked]> wrote:
>     Shared Address Space can be used as additional [RFC1918] space when
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/
>
>
> No IPR declarations have been submitted directly on this I-D.
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Lea Roberts <[email-masked]>
Date: Wed, 15 Feb 2012 12:02:47 -0800 (PST)

support