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

From: Ronald Bonica <[email-masked]>
Date: Mon, 28 Nov 2011 16:25:16 -0500

On October 10, 2011, the IESG issued a last call for comments regarding draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for Shared CGN Space). While the community did not display consensus supporting the draft, it also did not display consensus against the draft. Therefore, 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".

Because the decision to submit this draft to the full IESG is controversial, I will explain the decision making process.

The IETF has a precedent for interpreting silence as consent. Typically, if a last call elicits no response, the draft is brought to the full IESG for consideration. The October 10 last call regarding draft-weil-shared-transition-space-request-09 evoked only two responses. One response supported publication of the draft while the other was opposed to it. The respondent voicing support for the draft offered no rationale. The respondent objecting offered many editorial comments, but almost no rationale for blocking the draft once the editorial comments are addressed.

Because the October 10 last call elicited so little response, and because many community members have privately expressed strong opinions regarding this draft, I will summarize outstanding issues below. The following are arguments *against* draft-weil-shared-transition-space-request:

- Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network.
- If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft.
- If a special-use /10 is allocated, it will encourage others to request still more special-use address space.
- Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future.

Arguments *supporting* draft-weil-shared-transition-space-request-09 assume that operators will deploy CGNs and will number the interfaces between CGN and CPE. If the /10 proposed by draft-weil-shared-transition-space-request is not allocated, operators will number from one of the following:

- public address space 
- RFC 1918 address space
- squat space

If operators number from public address space, they will deplete an already scarce resource. If operators number from RFC 1918 space and the same RFC 1918 space is used on the customer premise, some CPE will behave badly. The consequences of numbering from squat space are determined by the squat space that is chosen.

In summary, allocation of the /10 will have certain adverse effects upon the community. However, failure to allocate the /10 will have different adverse effects on the community. The IESG is being asked to choose the lesser of two evils.

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Nov 2011 15:07:17 -0800

In my opinion, having a designated space is better than "squat" space, given that we we already know that squat space is being used. The argument that it extends the life of IPv4 is, IMHO, of limited value; yes, it allows operators to keep their IPv4 service running; given the number of CPE Routers that lack IPv6 capabilities, that will likely be necessary for the equipment lifetime of a CPE Router barring extraordinary activities on the part of vendors and operators to replace the current load of CPE Routers in favor of IPv6-capable upgrades.

IMHO, the space should be allocated.

On Nov 28, 2011, at 1:25 PM, Ronald Bonica wrote:

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

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 28 Nov 2011 15:49:05 -0800

>> In summary, allocation of the /10 will have certain adverse effects upon the community. However, failure to allocate the /10 will have different adverse effects on the community. The IESG is being…

Given that this is not a last call but folks are weighing in anyhow, i
will say i oppose this allocations.

This is taking legitimate IPv4 public space from people who need it,
and without SOP justification, giving it to an industry segment who
has not deployed IPv6 in the 10+ years allowed to do so.

IPv4 space has a market value.  Making this allocation is effectively
the same thing as the IETF giving these companies money to NOT deploy
IPv6 and paying them to roll out CGN (feels like a farm subsidy).

If there are really boxes in the ground that cannot do IPv6 (96 bits
too much), then folks should spend the money to make 240/4 work.  I
was told the 240/4 fix was too expensive.  Anyone on the black markets
want to provide a spot market value of a of pristine /10 of ARIN
space?  I think i overheard that a /16 goes for about a million, but
i dont actually know.

CB

ps.  Just came across this HBS study on IPv4 prices and market, I have
not read it yet http://www.hbs.edu/research/pdf/12-020.pdf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Nov 2011 15:43:12 +1300

I refrained from commenting during the IETF Last Call, and I think it might
help the IESG to reach the least bad decision if I say why.

This whole proposal will *never* be palatable to me. However, it may be
reasonable for the IETF to lay down appropriate restrictions, even though
we know that ISPs will ignore them.

IMNSHO it would have been much better if the IAB had agreed that this
allocation was a policy matter to be left to IANA and the RIRs under
Clause 4.3 of RFC 2860 . Since the IAB chose to define it as a technical
allocation, it is the IETF that has to take responsibility, and it is a
lose-lose game for us. Whatever we decide is wrong.

Regards
   Brian Carpenter

---

From: Doug Barton <[email-masked]>
Date: Mon, 28 Nov 2011 19:18:18 -0800

I agree generally with Brian except for the 2860 part. I would not want
to have seen IANA put on the spot for this, even if the IAB had been
willing to take responsibility for it.

Meanwhile I will say once again that capitulating here is wrong on many
levels. First there is the whole, "They made their non-IPv6 bed, they
ought to be required to lay down in it" issue. But completely aside from
that, I think Brian is right that the chances are within a close
approximation of 100% that whatever we do here will be ignored anyway.
So why not take a stand by doing the right thing and not allocating the
prefix?

... and a meta-issue for Ron. I saw a lot more opposition to the
document in the last call than you did. Are you by any chance referring
to my message at
https://www.ietf.org/mail-archive/web/ietf/current/msg69583.html below?
If so, I guess I needed to actually say the words, "I oppose publication
of this document?" If I wasn't clear, sorry.

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: SM <[email-masked]>
Date: Tue, 29 Nov 2011 00:23:57 -0800

>lose-lose game for us. Whatever we decide is wrong.

I support Brian's comments.

FWIW, IANA does not do policy.  The amended IANA RFP is explicit 
about that.  The IAB did not make any determination about 
draft-weil-shared-transition-space-request.  As such, it can disclaim 
any responsibility and go by IETF Consensus.

Some of the points raised during IESG evaluation have not been 
addressed, i.e. the application angle, which is about NAT detection 
code and not 6to4.  Some of the arguments made in RFC 1627 might be 
an eye-opener.  BTW, RFC 6269 was published in June 2011.  The 
down-ref was not called out during the Last Call.

If the message from the sponsoring AD is about a determination of 
consensus, please note that I am against the publication of the draft as a BCP.

Regards,
-sm

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 29 Nov 2011 10:28:02 -0500

Doug,

I did not refer to your message. The only two responses to the October 10 Last Call regarding draft-weil-shared-transition-space-request-09 were:

- https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=60292&tid=1322579909
- https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=59923&tid=1322579994

The message that you reference below, as well as many other messages,  were in response to a an August 19 Last call regarding draft-weil-shared-transition-space-request-03. Many of the problems pointed out in that last call were addressed between versions 03 and 09 of the document. However, many were not. Therefore, I summarized what I believed to be the outstanding issues in the message that I posted last night.

If I missed any outstanding issues, please add to the list.

I hope that this helps.

                                            Ron

> -----Original Message-----
> From: Doug Barton [mailto:[email-masked]]
> Sent: Monday, November 28, 2011 10:18 PM
> To: Brian E Carpenter
> Cc: Ronald Bonica; IESG IESG; IETF Discussion
> Subject: Re: Consensus Call: draft-weil-shared-transition-space-request
> 

[snip]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Nov 2011 07:43:39 -0800

> On October 10, 2011, the IESG issued a last call for comments regarding draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for Shared CGN Space). While the community did not d…

Regardless of whether or not IESG members support the allocation in this document, it is *not* a BCP. There is no current practice in this area; if there was, any of the /10s being used could be used. RFC 5735 is a BCP because the addressed listed were already known to be used for the purposes described; draft-weil-shared-transition-space-request is, as its title says, a request for a new allocation.

If the IESG decides to publish this document, please be forthright and call it a Proposed Standard.

--Paul Hoffman

---

From: "Bradner, Scott" <[email-masked]>
Date: Tue, 29 Nov 2011 15:51:25 +0000

to be pedantic - a BCP stands for the best way we know how to do something
it is not required that the process actually be in use before the BCP is adopted

as Mike O'Dell once said, if BCPs had to reflect what was actually being done we 
could never have a BCP defining good manners on the IETF mailing list

see RFC 2026 - it says
   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

i.e, the IETF's "best current thinking" on the "best way" to do something - not
'describing the way something is done'

this has always been the case - e.g., RFC 6410 described a new standards track
not the (not well used) existing standards track

Scott

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Nov 2011 10:57:54 -0500

+1

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Nov 2011 08:47:15 -0800

>> 'describing the way something is done'

You stopped the excerpt from 2026 too soon on both ends; "the community's best current thinking on a statement of principle". Ron already said that the community didn't agree on a clear "best current thinking", and the document very clearly says that this is meant to be a new allocation of addresses, not "a statement of principle".

If the IESG wants to weasel around the actual words in RFC 2026, that's fine: this wouldn't be the first time. However, there is also an opportunity to be more honest and call it a Proposed Standard.

--Paul Hoffman

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2011 01:48:34 +0900

+1

as has been discussed endlessly, it is technically broken, will not
achieve squat, and is a waste of time.

randy

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Nov 2011 09:42:31 -0800

> The message that you reference below, as well as many other messages,  were in response to a an August 19 Last call regarding draft-weil-shared-transition-space-request-03. Many of the problems poi…

Thanks for clarifying. My concern was that my message may have fallen
into the category, "offered many editorial comments, but almost no
rationale for blocking the draft once the editorial comments are
addressed." Now I see that you were looking at a completely different
last call. Silly me.

> If I missed any outstanding issues, please add to the list.

My issue remains simple. This is a bad idea. It will still be a bad idea
no matter how it's dressed up.

hth,

Doug

--

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 29 Nov 2011 13:54:08 -0500

Folks,

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.

                                             Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Tuesday, November 29, 2011 11:47 AM
> To: IESG IESG
> Cc: IETF Discussion
> You stopped the excerpt from 2026 too soon on both ends; "the
> community's best current thinking on a statement of principle". Ron
> already said that the community didn't agree on a clear "best current
> thinking", and the document very clearly says that this is meant to be
> a new allocation of addresses, not "a statement of principle".
> 
> If the IESG wants to weasel around the actual words in RFC 2026, that's
> fine: this wouldn't be the first time. However, there is also an
> opportunity to be more honest and call it a Proposed Standard.
> 
> --Paul Hoffman

---

From: Chris Donley <[email-masked]>
Date: Tue, 29 Nov 2011 13:13:49 -0700

Ron,

One point of clarification, in your *against* list, you include:

On 11/28/11 2:25 PM, "Ronald Bonica" <[email-masked]> wrote:

>- Some applications will break. These applications share the
>characteristic of assuming that an interface is globally reachable if it
>is numbered by an non-RFC 1918 address. To date, the only application
>that has been identified as breaking is 6to4, but others may be
>identified in the future.

Since this address space is between the CPE router and CGN device, and is
therefore not globally routable, the same application(s) (e.g. 6to4) will
break if public or 'squat' space are used instead of shared CGN space.
Such applications rely on the home router detecting that there is private,
non-globally routable space (i.e. RFC1918) on the WAN and disabling such
an application.  While that same detection code will always fail for
public address space and squat space since the exact range is not defined,
there is the possibility of fixing the detection code in home routers if
we do define shared CGN space for that purpose.

Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 29 Nov 2011 21:53:51 +0100

> If the IESG wants to weasel around the actual words in RFC 2026, that's fine: this wouldn't be the first time. However, there is also an opportunity to be more honest and call it a Proposed Standar…
I believe Russ was reading the words ".... on what is believed to be the 
best way to perform some operations ...".

FWIW, given that the IAB has chosen to not uphold the principle of 
subsidiarity and let this thing be done at the lowest possible level in 
the decision hierarchy, I hold with the people who argue that allocating 
this /10 is less harmful than not allocating it.

"best" in this case being synonymous with "least bad", not synonymous 
with "good".

                       Harald

---

From: Mark Townsley <[email-masked]>
Date: Tue, 29 Nov 2011 22:02:34 +0100

> we do define shared CGN space for that purpose.

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03 has this requirement:

   DLW-4:  If the IPv6 CE Router is configured with a public IPv4
           address on its WAN interface, where public IPv4 address is
           defined as any address which is not in the private IP address
           space specified in [RFC5735], then the IPv6 CE Router SHOULD
           disable the DS-Lite B4 element.

I'm not sure I personally agree with this requirement, but suffice to say if this kind of language is popping up in our own v6ops documents at this very moment, there is a decent chance that it has made its way into specifications and code elsewhere.

- Mark

---

From: Chris Donley <[email-masked]>
Date: Tue, 29 Nov 2011 14:59:07 -0700

And that's one of the reasons this draft updates 5735. If routers make decisions as to whether or not to enable a feature based on whether behind a public or private address, having a defined address range for CGN space will be significantly easier to deal with than to have arbitrary address ranges selected on a per-ISP basis.

Chris

From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: Tue, 29 Nov 2011 14:02:34 -0700
To: Ronald Bonica <[email-masked]<mailto:[email-masked]>>, Chris Donley <[email-masked]<mailto:[email-masked]>>
Cc: IESG IESG <[email-masked]<mailto:[email-masked]>>, IETF Discussion <[email-masked]<mailto:[email-masked]>>
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request

Ron,

On 11/28/11 2:25 PM, "Ronald Bonica" <[email-masked]<mailto:[email-masked]>> wrote:

           space specified in [RFC5735<http://tools.ietf.org/html/rfc5735>], then the IPv6 CE Router SHOULD

- Mark

Chris

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

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 29 Nov 2011 17:01:24 -0500

Agreed!

> From: Chris Donley [mailto:[email-masked]]
> Sent: Tuesday, November 29, 2011 3:14 PM
> To: Ronald Bonica; IESG IESG; IETF Discussion

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Nov 2011 14:05:26 -0800

On 11/29/2011 13:59, Chris Donley wrote:
> And that's one of the reasons this draft updates 5735. If routers make
> decisions as to whether or not to enable a feature based on whether
> behind a public or private address, having a defined address range for
> CGN space will be significantly easier to deal with than to have
> arbitrary address ranges selected on a per-ISP basis.

But that's certainly not the only way to handle that problem, right? If
the router needs to be updated to recognize the new space anyway,
wouldn't it make more sense to update it with a more generic mechanism
to signal "You're behind a private address?" That way you can use the
same mechanism for IPv4 and IPv6.

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Nov 2011 10:04:53 +1100

> same mechanism for IPv4 and IPv6.

It doesn't have to be one or the other.  It can be both.  Having address
space that the CPE can identify as non-public without the ISP having
to configure something is a a good thing.

As much as I would like to see IPv6 native everywhere as soon as
possible forcing each ISP to choose part of their allocated address
space or to use RFC 1918 address space behind CGN's is not good
resource management.

RFC 1918 space is suppose to be used *within* a enterprise.  Using
it to *connect* enterprises is out of bounds. 

This also force ISP's to be less wasteful of IPv6 space with their
6rd domains as they can nolonger just shove the entire 32 IPv4 bits
into the IPv6 address with multiple use of this space within the
ISP.

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

---

From: Chris Grundemann <[email-masked]>
Date: Tue, 29 Nov 2011 16:37:23 -0700

I support draft-weil-shared-transition-space-request and the
allocation of a /10 as Shared CGN Space because we are approaching
complete global exhaustion of unallocated IPv4 addresses and the value
of globally unique addresses is becoming manifest. Network operators
recognize the need to transition to IPv6 now more than ever. However,
the immediate necessity for IPv4 connectivity poses a near-term
challenge which requires the deployment of address-sharing
technologies. We are seeing this already in the Asia-Pacific region
where APNIC has already exhausted their free pool of IPv4 and CGN is
being deployed.

The Shared CGN Space requested in draft-weil will facilitate service
provider deployment of non-unique address plans that do not conflict
with traditional Private addresses.  By using this Shared CGN Space
operators can roll out CGN without consuming, or squating on, global
addresses. There are a litany of other benefits to using a Shared CGN
Space, many of which are detailed in
draft-bdgks-arin-shared-transition-space. Draft-bdgks also contains
analysis of all the alternatives to and arguments against using Shared
CGN Space I have heard raised. Please see that I-D for my more verbose
thoughts on this matter.

Finally, the ARIN community has already come to consensus on this
issue and is willing to return a /10 for this use, it's time for the
IETF to do the right thing and allow people to start using this space.

Humbly,
~Chris

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

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

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Nov 2011 16:00:10 -0800

On 11/29/2011 15:37, Chris Grundemann wrote:
> of globally unique addresses is becoming manifest.

As others have pointed out, those ideas contradict one another. The fact
that free addresses are so valuable is precisely why they shouldn't be
taken away from new entrants to the market in order to benefit the
grasshoppers who've fiddled away the summer. And yes, I realize that
1,024 /20s is just a drop in the bucket. But sometimes the principle of
the thing IS the thing.

> Network operators recognize the need to transition to IPv6 now more than ever.

Again, no sympathy. They've had (by conservative estimates) 10 years.

> However,
> technologies.

They created the crisis. Why is it our responsibility to fix it for them?

--

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Nov 2011 16:05:41 -0800

On 11/29/2011 15:04, Mark Andrews wrote:
> It doesn't have to be one or the other. 

Of course it doesn't have to be, it *should* be.

> It can be both.  Having address

How are the CPEs going to recognize the new space without something
being configured? They will need a software upgrade, right? So why is a
generic, boolean flag not a better idea than allocating a magic block?

> space or to use RFC 1918 address space behind CGN's is not good

I don't see anything wrong with using 1918 space for this purpose.

> it to *connect* enterprises is out of bounds. 

How are you defining enterprise in this context?

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Nov 2011 12:51:19 +1100

> 1,024 /20s is just a drop in the bucket. But sometimes the principle of

And if we had done this several years ago we would have left even more space
to new comers as the RIR's could have use this space in assessing requests
for additional space.  ISP that use this block could collectively return
much more space to the free pool than this will consume.
 
> They created the crisis. Why is it our responsibility to fix it for them?

Because they have asked for our help.

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Nov 2011 18:00:14 -0800

On 11/29/2011 17:51, Mark Andrews wrote:
> And if we had done this several years ago

... but we didn't.

> we would have left even more space

... and yet at this point we all know that noone who has substantial
IPv4 space is going to return it to the RIRs.

Doug

--

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2011 12:37:42 +0900

> Since this address space is between the CPE router and CGN device, and
> is therefore not globally routable

right.  and pigs fly.

you allocate more what is essentially 1918 space and it will be used all
over the place, from your hack to enterprises to $diety knows what.  and
it will leak into the global table just as current 1918 space does.

randy

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 29 Nov 2011 23:07:31 -0500

IESG,

IMHO the allocation of such space would be extremely valuable to the
Internet Community by allowing  operators to minimize the impact of
introducing CGN if required (which can be accomplished quite successfully
in a Dual Stack deployment while introducing IPv6).

The allocation of this space does not hasten or slow the deployment of
IPv6 since those factors are controlled by a wide range of influences
including the one most uncontrollable element - the home user and their
ecosystem.

The allocation would solve real technical problems and would provide a
much more deterministic and controllable environment then the potential
rampant use of more random squat space.  Allocation of
such space would also be much more efficient then use of multiple
allocations 
of RIR space for the same use.  The technical challenges can be overcome
as the 
use of squat space (by some operators) has shown the viability of using
non-RFC1918 
for endpoint addressing by which a NAT is northbound.

On 11-11-29 10:37 PM, "Randy Bush" <[email-masked]> wrote:

>over the place, 

And yet it's not RFC1918 space by definition.  If a provider uses squat
space for private functions, it's also not RFC1918.

We may not be able to prevent some from doing the wrong thing, but this
should not stop us from providing the tools for many to follow the
guidance to do the right thing.

>from your hack to enterprises to $diety knows what.  and

This is why a well known block is better.  Operators can filter and
control this from both sides as oppose to dealing with random blocks.

>Randy

Regards,

Victor K

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 30 Nov 2011 08:11:42 +0100

On Tue, Nov 29, 2011 at 9:53 PM, Harald Alvestrand <[email-masked]> wrote:
<snip>
> subsidiarity and let this thing be done at the lowest possible level in the
> decision hierarchy, I hold with the people who argue that allocating this
> /10 is less harmful than not allocating it.
>
> "best" in this case being synonymous with "least bad", not synonymous with
> "good".

I read, it is what will hurt the whole less, nothing todo with good or bad idea.

Anyway, for what's it's worth. I'm very against the entire idea, but
all in all, it's better to give out that one big block than let the
chaos loose.

but it will probably open a can of worm that will start raining on
everyone in 2012 or so....

-- 

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

---

From: "Lee Howard" <[email-masked]>
Date: Wed, 30 Nov 2011 09:52:32 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Doug Barton
> Sent: Tuesday, November 29, 2011 7:00 PM
> To: Chris Grundemann
> Cc: IESG IESG; IETF Discussion

Even if I agree in principle, I can't agree in practice.  
How does a model ISP, who has deployed IPv6 to 100% of its users, 
support people with home electronics, and people who want to reach 
IPv4-only content?

> Again, no sympathy. They've had (by conservative estimates) 10 years.

This isn't about saving network operators.  draft-donley-nat444-impacts
shows that CGN is not a good primary strategy; any operator with sense is
deploying (or hopefully, has deployed) IPv6.

What does an ISP do when it's out of IPv4 space, and new customers expect
to use their game consoles?  Or DVRs?  Or Blu-ray players?  Or web cams?
Or picture frames?  The IETF position might be that use of IPv4-only on 
consumer electronics is obsolete (see draft-intarea-ipv6-required), and 
that anything bought prior to IPv4 runout must be replaced.

There may also be content that is IPv4-only.  Smaller web sites, of course,
may take a long time.  Until every user has replaced their home gateways
and has IPv6 access, there will certainly be p2p apps and content that are
IPv4-only (not just the app, but the remote user could be IPv4-only).  Of
course, many of these apps break under NAT444, but many don't, and
some are working around it.  IPv6 would be better.

> They created the crisis. Why is it our responsibility to fix it for them?

Who did?  You vilify ISPs, but even if an ISP has deployed IPv6 to
100% of its users, replacing all of their modems and home gateways,
(gateways which many ISPs didn't provide in the first place) how does 
it support people with home electronics, and people who want to reach 
IPv4-only content?

You made this an argument about CGN, so I'm describing why CGN 
is required.  Draft-weil explains why designated address space is 
needed for it.

Lee

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 30 Nov 2011 15:18:57 +0000

On Nov 28, 2011, at 4:25 PM, Ronald Bonica wrote:

> ...

Since the detractors of this draft admit that operators will use another address space anyway if they're not given a /10, then the above argument is false.  No matter what, CGNs will be deployed for IPv4 life-support. 

> - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft.

So what??  We write all kinds of RFCs with MUST NOTs in them that people ignore - but we can't stop writing RFCs just because that sometimes happens.  The best we can do is write the MUST NOT, explain exactly why it's a MUST NOT, and then hope people listen. (and BTW, the current draft does not sufficiently explain why not, imho)

> - If a special-use /10 is allocated, it will encourage others to request still more special-use address space.

So what??  They can request all they want, whether we publish this RFC or not.  We'll be able to say "no" to them if their request falls in the same class as this one, or we'll be able to say "yes" to them if there's some technical merit to what they want.  That's how things work, no?

> - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only appli…

Since the detractors of this draft admit that operators will use another address space anyway if they're not given a /10, then the above argument is false.  There will be some address space used that is not publicly reachable and is not in the RFC1918 space, so these applications will break *anyway*.  The question is if 6to4 and other use-cases would like to know what that address is going to be so they can fix themselves to handle the new address, or whether we keep them broken.

-hadriel

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 30 Nov 2011 13:28:09 -0700

> 1,024 /20s is just a drop in the bucket. But sometimes the principle of

It is more conservative to share a common pool.

> Again, no sympathy. They've had (by conservative estimates) 10 years.

No sympathy for "they" (basically all residential ISPs on the planet)
needed. The shared CGN space mitigates externalities that will likely
be caused by every other alternative to a shared CGN space.
> They created the crisis. Why is it our responsibility to fix it for them?

See above. We are not "fixing it for them." "They" will deploy CGN
with or without us. We are giving "them" a way to do it in the least
disruptive way.

Cheers,
~Chris

---

From: David Conrad <[email-masked]>
Date: Wed, 30 Nov 2011 12:49:42 -0800

Chris,

On Nov 30, 2011, at 12:28 PM, Chris Grundemann wrote:
> "They" will deploy CGN with or without us.

True.

> We are giving "them" a way to do it in the least disruptive way.

Could you expand on the disruption you believe would be minimized by implementation of this draft?

That is, what do you believe would happen if this draft is not accepted and the /10 allocation is not made? The draft doesn't spell this out explicitly (as far as I can tell) and I suspect much of the discussion revolves around different interpretations of the disruption.

Thanks,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Dec 2011 09:52:27 +1300

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.

   Brian

---

From: Daryl Tanner <[email-masked]>
Date: Wed, 30 Nov 2011 21:04:41 +0000

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

---

From: Pete Resnick <[email-masked]>
Date: Wed, 30 Nov 2011 20:14:58 -0600

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

On 11/30/11 3:04 PM, Daryl Tanner wrote:
> back-office etc. 172.16.0.0/12 <http://172.16.0.0/12> is used there.
>
>
> Daryl
>
>
> On 30 November 2011 20:52, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     of using 172.16.0.0/12 <http://172.16.0.0/12> for this. It is a
>     large chunk of space

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 30 Nov 2011 21:19:43 -0500

On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick 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.

Another suggestion was the use of 10.64.0.0/10, with the argument that some devices may use 10.0.0.0 but those devices tend to start numbering with 10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in 10.64.0.0/10.

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

- Ralph

> 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
> 
>> 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:

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 30 Nov 2011 21:41:53 -0500

Ralph,

Please note the following report:

WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf)

Report suggested that all three RFC1918 blocks are well utilized.

Regards,

Victor K

On 11-11-30 9:19 PM, "Ralph Droms" <[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 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.
>
>Another suggestion was the use of 10.64.0.0/10, with the argument that
>some devices may use 10.0.0.0 but those devices tend to start numbering
>with 10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in
>10.64.0.0/10.
>
>> 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.
>> 
>>><[email-masked]> wrote:

---

From: Pete Resnick <[email-masked]>
Date: Wed, 30 Nov 2011 20:53:34 -0600

> Report suggested that all three RFC1918 blocks are well utilized.

Well utilized in devices that can't deal with identical addresses on the 
inside and outside interfaces? That's the only question that counts.

pr

> On 11-11-30 9:19 PM, "Ralph Droms"<[email-masked]>  wrote:
>
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 30 Nov 2011 21:57:08 -0500

> WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf)

Thanks for the reference. Do you have an easy pointer to retrieve the doc?  I'm curious about how the data was gathered and what conclusions are drawn.

- Ralph

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 30 Nov 2011 19:04:15 -0800

> Thanks for the reference. Do you have an easy pointer to retrieve the doc?  I'm curious about how the data was gathered and what conclusions are drawn.

http://member.wide.ad.jp/tr/wide-tr-kato-as112-rep-01.pdf

I don't find this document to be very convincing that residential
services cannot be well served by 10.64.0.0/10.

---

From: Randy Bush <[email-masked]>
Date: Thu, 01 Dec 2011 15:48:11 +0900

> used by such unintelligent CPEs.

i never made any such, or similar, claim

---

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

> i never made any such, or similar, claim

Damn. It was Robert Elz I was thinking of. (See his 30-Nov 17:19 +0700 
message.) I apologize to you both for the confusion.

pr