Subject: [OPSAWG] WGLC on shared transition space

From: [email-masked] (Scott O. Bradner)
Date: Tue, 2 Aug 2011 10:56:02 -0400 (EDT)

this starts a WGLC on draft-weil-shared-transition-space-request-03.txt

comments to the list by Aug 16 please

Scott

---
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IANA Reserved IPv4 Prefix for Shared Transition Space
	Author(s)       : Jason Weil
                         Victor Kuarsingh
                         Chris Donley
                         Telstra Corp
                         Marla Azinger
	Filename        : draft-weil-shared-transition-space-request-03.txt
	Pages           : 12
	Date            : 2011-08-02

  This document requests a reserved IANA IPv4 address allocation as
  Shared Transition Space to support the deployment of IPv4 address
  sharing technologies post IPv4 exhaustion

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt

---

From: <[email-masked]>
Date: Tue, 2 Aug 2011 15:08:45 -0400

Cox Communications supports this draft and requests that the WG's and AD's
allow it to proceed.

On 8/2/11 10:56 AM, "Scott O. Bradner" <[email-masked]> wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Aug 2011 10:13:08 +1200

I have concluded that it is inappropriate for the IETF to endorse
this hack. That isn't intended to be derogatory - there are many aspects
of running code that depend on hacks. But the fact is that this is a hack,
for reasons that have been discussed many times and that I won't
repeat here. I know that some aspects of RFC 6269 are contested, but
it does give the arguments.

I've also reviewed draft-bdgks-arin-shared-transition-space in reaching
this conclusion. I am not happy that ARIN is going the way it apparently is,
but that is my own problem. However, I don't support draft-bdgks's call for
"consensus between the IETF and RIR communities" on this issue. It isn't
necessary.

At the very minimum, if draft-weil is to proceed, it should describe the
phase-out plan for the proposed prefix (i.e. the phase-out plan for CGN
deployment). One approach to that is documented in RFC 6264.

It is strange that draft-weil doesn't reference RFC 6319 and RFC 6269.

Regards
   Brian Carpenter

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 02 Aug 2011 19:15:04 -0500

Hi, Brian.

On 8/2/11 5:13 PM, "Brian E Carpenter" <[email-masked]> wrote:

> this hack. 

We're asking for an IPv4 prefix reservation, not an endorsement. But
assuming that they're perceived to be one-and-the-same to some people, I'll
continue.

> That isn't intended to be derogatory - there are many aspects

To be clear: I think you're objecting to the use of CGN. I don't think
you're objecting to the use of IPv4 and/or the reservation of IPv4 prefixes.

On the basic motivation for your objection, I won't argue. I don't really
like NAT, especially the CGN variety, and would rather have native IPv6. (I
think I can almost hear a chorus of "amen" from the IETF devout...)

But in reality, the IETF doesn't "endorse" a technology - the market does by
choosing what to deploy. And CGN is already deployed, is currently being
deployed, and/or is part of deployment plans at just about every ISP that
I've spoken with. Most of them are focused on NAT444 for various reasons.
They all need Shared Transition Space, and unless we make this reservation
they will be forced to explore the "alternatives" described in
draft-bdgks-arin... Shutting off IPv4 connectivity is not currently an
option.

> deployment). One approach to that is documented in RFC 6264.

This was previously discussed amongst the authors of draft-weil and
draft-bdgks, and it's not obvious per that discussion that a phase-out plan
is useful.

During the period of time that IPv4 connectivity is necessary, the Shared
Transition Space reservation is likely to be needed. After an effective IPv6
transition, when the Shared Transition Space is no longer needed, it won't
matter if it's returned to the pool because IPv4 address demand will
decrease. Thus it doesn't make sense to worry about a phase-out plan. (BTW,
reclamation of unused IPv4 GUA post-transition would gain more inventory,
but also isn't worth the hassle.)

In other words, I'm assuming that we won't encounter (or won't know) a
growing IPv4 Internet with no NAT444 in use. The edge-case possibility, of
100% IPv6 clients combined with increasing IPv4 demand, seems unlikely. If
you think I'm overlooking some other possibility, please clarify.

Cheers,
-Benson

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Aug 2011 13:39:28 +1200

Benson,

> you're objecting to the use of IPv4 and/or the reservation of IPv4 prefixes.

Emotionally, I object to CGN, but realistically, I know it is part of the
real world. That's why I'm a co-author of RFC 6264.

I do object to using a significant amount of global IPv4 space for this purpose.
Whoever it was that decided to make the Internet depend on NAT44 should have
thought about this problem years ago and kept some of the RFC 1918 space
for NAT444 usage.

Failing that, I would have gone for 1.0.0.0/8 for this purpose, since it's
already compromised by bogons. But that ship has sailed. So I don't think there
*is* a solution for this problem that doesn't consume some global space that
should have been used in a normal way. Why would the IETF want to be party
to that? It's an operational issue.

> draft-bdgks-arin... Shutting off IPv4 connectivity is not currently an

Of course not, and although there are certainly alternative approaches
(see below) it's too late to avoid CGNs.

> draft-bdgks, and it's not obvious per that discussion that a phase-out plan

It's only by describing a phase-out plan that you can make a convincing
case that this a stop-gap, in which case people might just hold their noses
instead of trying to stop it.

> but also isn't worth the hassle.)

Sure - it's not the reservation of the prefix that phases out, it's the
need to use it.

> you think I'm overlooking some other possibility, please clarify.

There is a class of solutions in which there is no need for NAT44 in the CPE,
and a single layer of NAT44 is provided at the ISP end of a 4-over-6 tunnel.
Indeed, that is DS-Lite and it's part of process of removing NAT444 from
the picture. Again, see RFC 6264. An ISP that follows that path will be able to
phase out whatever IPv4 prefix(es) it uses for NAT444 "Transition Space".

Regards
    Brian

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 3 Aug 2011 09:45:51 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian E Carpenter
> Sent: Tuesday, August 02, 2011 7:39 PM

> It's only by describing a phase-out plan that you can make a convincing case
> that this a stop-gap, in which case people might just hold their noses instead
> of trying to stop it.

> Sure - it's not the reservation of the prefix that phases out, it's the need to
> use it.

[CLG] I believe that your comments are invaluable to revising the next version of draft-bdgks and I hope that you will continue to participate in this discussion as we do that. However, draft-weil is not meant to address the use-cases or BCPs surrounding shared transition space, it merely requests the reservation. The references to a phase out plan, to RFCs 6264, 6269, 6319 and any others belong in draft-bdgks if they are to be included (and you make a convincing argument that they should be). I certainly agree that these items need to be discussed further but I do not think they warrant holding up draft-weil and the reservation of a /10 for shared transition space (which the ARIN community has so graciously agreed to donate to the world).

Cheers,
~Chris

PS - Kudos on RFC 6264, it's a great doc.

---

From: Chris Donley <[email-masked]>
Date: Wed, 3 Aug 2011 12:25:50 -0600

Brian,

I share your goal of moving to IPv6 as fast as possible, but we need to do
something in the short term to give subscribers continued IPv4 access
through the transition, and NAT444 will be the best choice for some
providers in the near future (particularly since it doesn't require a
router replacement like DS-Lite).  Having reserved shared transition space
will reduce the total number of addresses used behind the CGN (compared
with direct assignments), reduce squatting, and improve operational
characteristics vs. different ranges for each operator or RFC1918 space.

>thought about this problem years ago and kept some of the RFC 1918 space
But here we are, and we don't have RFC1918 space reserved for NAT444.  We
are only 
asking for a /10 for Shared Transition Space - we calculate the aggregate
demand to be close to 10x what we are requesting. Given the current
situation, I believe this is the most responsible way to supply addresses
for NAT444 (or other transition technologies) - it doesn't squat and it
reduces the amount of global unicast address space required vs. direct
assignment. This should reduce the number of users who need to sit behind
the CGN while we transition to IPv6.
>to that? It's an operational issue.
Per RFC 2860, the IETF needs to be involved with allocations for specific
technical purposes.  Since 1/8 is not an option, I believe shared
transition space is the best option remaining (FWIW, people in the ARIN
region have been talking about possibly using reclaimed Interop space for
shared 
transition space; it's not likely to be pristine GUA space).
>(see below) it's too late to avoid CGNs.
Through testing, we've identified that IPv6 performs better than both
NAT444 and DS-Lite. After IPv4 exhaustion, I think the market will move
expeditiously towards IPv6, especially when more consumer electronics
start adding IPv6 support.
>instead of trying to stop it.

The problem is that we don't really know exactly when consumers will adopt
IPv6.  As you say, the IETF is more involved with defining technologies
than addressing operational issues - this is an operational issue, and is
likely to vary provider-by-provider based on their mix of subscribers and
different customer hardware replacement cycles.  A number of the operators
I have spoken with are doing their best to avoid NAT444, but may be forced
to deploy it eventually to continue offering IPv4 service to those who
need it.
>phase out whatever IPv4 prefix(es) it uses for NAT444 "Transition Space".
Sure, but it's not at all clear that DS-Lite will offer a better
experience to the subscriber than
NAT444. If it does make a noticeable difference, I expect that the market
will move towards it (particularly given RFC 6264). I'm not sure we need
to mandate such a transition plan here - ISPs are concerned about offering
customers a good experience, and will do the best they can with the
technology available. In the short term, however, NAT444/NAT44/or
something similar will probably be necessary for many providers, and I
believe that shared transition space offers the best path forward until we
get to native IPv6.

Chris

---

From: Vikas Sarawat <[email-masked]>
Date: Thu, 4 Aug 2011 16:22:31 -0600

I support this draft.

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 04 Aug 2011 16:03:54 -0700

> I have concluded that it is inappropriate for the IETF to endorse

I agree.

The "middle" network for NAT444 can be numbered by the ISP with RFC1918 
space in all cases except those where the specific block from RFC1918 
space conflicts with customer internal use, a situation which can be 
arranged to be rare and which is easily both detected and fixed if 
encountered.

If it is desired to never encounter that situation, globally unique 
space already allocated to the ISP may be used (and reused multiple 
times if necessary) instead of RFC1918 space.

If two or more ISPs wish to agree to reuse portions of one another's 
space for this purpose, there's nothing stopping that from happening either.

Setting aside a block for this purpose has the following drawbacks:
1. Reduces the number of rapidly diminishing globally unique IPv4 addresses

2. Provides a shared block that is known to never conflict with RFC1918 
space, and thus will be used for numerous other applications outside of 
the applicability statement (such as it is) in Section 4 of the draft. 
For example, corporate network operators will undoubtedly use this space 
to facilitate VPNs between two different companies that have overlapping 
RFC1918 space, and may even choose to place intranet servers in this 
space during merger and acquisition activities. This will then conflict 
with its use as the middle layer of NAT444 should the company be moved 
to a NAT444 environment without its knowledge.

Note that this use case is SPECIFICALLY called out in section 2.1.2 of 
draft-bdgks-arin-shared-transition-space-00, with no mention of how it 
breaks the actual intended purpose of the space.

Also note that this use case is outside of the scope of the ARIN proposal.

3. Provides a shared block that is known to not conflict with RFC1918 
space that does not "use up" an ISPs globally unique addresses, thus 
providing an opportunity to continue deploying IPv4 services to 
customers rather than transitioning to IPv6, thus making this NOT an 
IPv6 transition mechanism.

Note that this use case is SPECIFICALLY called out in section 2.1.3 of 
draft-bdgks-arin-shared-transition-space-00, with no mention that it 
counters the goal of facilitating IPv4 to IPv6 transition.

Also note that this use case is outside the scope of the ARIN proposal.

Additional comments on draft-bdgks-arin-shared-transition-space-00:

Section 2.1.3: The "care must be taken" is impossible. ANY multihomed 
customer will be negatively impacted by an overlap in address space 
exposed by their upstream provider.

Section 2.2.2: The converse of "default behaviors... which may not be 
desirable" is not mentioned. For example, a node seeing such a shared 
address will assume that it has a globally unique address rather than 
(correctly) assuming that it is behind a NAT device. 6to4 and several 
peer-to-peer protocols would exhibit this incorrect behavior. This is 
addressed in 4.1.2, but not referenced here.

Section 2.2.3: Should note that any case where the service provider 
controls a NATing CPE does in fact work, otherwise agree with analysis.

Section 4.1.3: Conflicts directly with 2.1.2 and 2.1.3 in that those 
sections recommend misuse.

Section 5.1.1: Correctly notes that the question has been asked, and 
answered in the negative, even in the recent past... I suppose we'll 
just get the same thing requested at more and more frequent intervals 
until either it finally passes or there's no /8 or /10 or whatever left 
to allocate.

Matthew Kaufman

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Aug 2011 11:20:07 +1200

Chris,

To avoiding repeating myself on the issues where we disagree, I
will just comment on one of your points, which is a new one:

> technical purposes.

It's a matter of judgment whether that applies in this case or
not. Having been the original drafter of the MoU that became RFC
2860, I must say this isn't a clear-cut case. RFC 1918 was
already ancient history when the MoU was drafted, so I certainly
never wondered about it. The actual clause refers to
"(b) assignments of specialised
   address blocks (such as multicast or anycast blocks),"
whereas this case is a block of global unicast space.

It's certainly a point to be considered. My feeling is that
this is an operational assignment, not a "specialised address
block", but clearly YMMV.

Regards
   Brian Carpenter

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 4 Aug 2011 19:51:03 -0400

see http://www.iab.org/documents/correspondence-reports-documents/2011-2/response-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/
fir the IAB's view

Scott

> block", but clearly YMMV.

Scott Bradner

Harvard University Information Technology
Security | Policy, Risk & Compliance
+1 617 495 3864
29 Oxford St., Room 407
Cambridge, MA 02138
www.harvard.edu/huit

---

From: Owen DeLong <[email-masked]>
Date: Thu, 4 Aug 2011 17:18:51 -0700

On Aug 4, 2011, at 4:03 PM, Matthew Kaufman wrote:

> The "middle" network for NAT444 can be numbered by the ISP with RFC1918 space in all cases except those where the specific block from RFC1918 space conflicts with customer internal use, a situation which can be arranged to be rare and which is easily both detected and fixed if encountered.
> 

In the case of a residential ISP where they have millions of customers distributed across random pieces of RFC-1918 space, how
would you (feasibly) arrange for it to be rare, easily detected, and (feasibly) fixed?

This claim utterly ignores the operational realities of the existing situation, which I and much of the rest of the operational community
consider rather a forté of the IETF at this point, but we're hoping to change that through participation.

> If it is desired to never encounter that situation, globally unique space already allocated to the ISP may be used (and reused multiple times if necessary) instead of RFC1918 space.
> 

It is very much desired to avoid this situation. Sure, 100s or even 1000s of ISPs can do that, resulting in 100s or 1000s of address blocks
being allocated to this purpose instead of one. How does that benefit the community?

> If two or more ISPs wish to agree to reuse portions of one another's space for this purpose, there's nothing stopping that from happening either.
> 

Other than the operational realities of making ones business dependent on the continued good will and unchanging nature of the needs of
some other business with whom you also happen to be a competitor.

Again, please step out of the ivory tower for a moment and look at the operational reality for the variety of networks that are all asking for
this. It really is in the best interests of the internet to make this happen.

> 1. Reduces the number of rapidly diminishing globally unique IPv4 addresses

No, it actually increases it because the requests that will result from a denial will far exceed a /10.

> 2. Provides a shared block that is known to never conflict with RFC1918 space, and thus will be used for numerous other applications outside of the applicability statement (such as it is) in Section 4 of the draft. For example, corporate network operators will undoubtedly use this space to facilitate VPNs between two different companies that have overlapping RFC1918 space, and may even choose to place intranet servers in this space during merger and acquisition activities. This will then conflict with its use as the middle layer of NAT444 should the company be moved to a NAT444 environment without its knowledge.

If they use it that way, they do so knowing full well the difficulties it may cause. There are lots of examples of the misuse of RFC-1918
space that have not caused any harm to those other than the ones misusing the space, so, I don't see any reason for this to be different.

> 
> Note that this use case is SPECIFICALLY called out in section 2.1.2 of draft-bdgks-arin-shared-transition-space-00, with no mention of how it breaks the actual intended purpose of the space.
> 

That's because in 99% of actual cases it wouldn't actually be a conflict. The things in this middle space wouldn't need to talk directly
to the ISP NAT network and there would be no conflict as a result.

> Also note that this use case is outside of the scope of the ARIN proposal.

Which is utterly irrelevant to the IETF discussion.

> 3. Provides a shared block that is known to not conflict with RFC1918 space that does not "use up" an ISPs globally unique addresses, thus providing an opportunity to continue deploying IPv4 services to customers rather than transitioning to IPv6, thus making this NOT an IPv6 transition mechanism.
> 

I don't believe anyone is considering this an IPv6 transition mechanism. I believe it is being treated as a survival technique to allow operators
to focus on IPv6 transition instead of having to devote vast resources to resolving NAT conflicts. We have to keep the IPv4 network running
and we have to deal with NAT444 even if IPv6 is deployed for some time. That's the reality we are faced with.

However, I don't think anyone is regarding this as an opportunity to avoid or postpone deploying IPv6. I think they are looking to survive long enough to get IPv6 deployed and to keep operating the things that have to keep working on IPv4 that are incapable of doing IPv6 on the customer end of things at least to the extent possible.

> Note that this use case is SPECIFICALLY called out in section 2.1.3 of draft-bdgks-arin-shared-transition-space-00, with no mention that it counters the goal of facilitating IPv4 to IPv6 transition.
> 

It does not counter the goal of facilitating IPv4 to IPv6 transition, it merely makes that process a little less painful.

> Also note that this use case is outside the scope of the ARIN proposal.

Which is still utterly irrelevant to the IETF discussion.

> Additional comments on draft-bdgks-arin-shared-transition-space-00:

Note that is not the draft that is the subject of this last call. I think everyone agrees there remains work to be done on draft-bdgks, which
was hastily put together by the operations community in an effort to convey additional information about the need for this draft to get
an accelerated last call and adoption.

> Section 2.1.3: The "care must be taken" is impossible. ANY multihomed customer will be negatively impacted by an overlap in address space exposed by their upstream provider.
> 

Yes. Thus, care must be taken to avoid an overlap that has impact.

> Section 2.2.2: The converse of "default behaviors... which may not be desirable" is not mentioned. For example, a node seeing such a shared address will assume that it has a globally unique address rather than (correctly) assuming that it is behind a NAT device. 6to4 and several peer-to-peer protocols would exhibit this incorrect behavior. This is addressed in 4.1.2, but not referenced here.
> 

They will ALSO exhibit this behavior if providers use and reuse their own GUA space. The difference is that with this shared block, it will be possible, maybe even feasible for software updates to incorporate it into the shared address perspective. Without this draft, the random assortment of address blocks used would make such a mitigation of this issue impossible.

Thus you have just made an excellent argument in favor of this draft.

> Section 5.1.1: Correctly notes that the question has been asked, and answered in the negative, even in the recent past... I suppose we'll just get the same thing requested at more and more frequent intervals until either it finally passes or there's no /8 or /10 or whatever left to allocate.
> 

Since there is such a strong operational need, you are correct that the request is unlikely to go away. Given that ARIN has agreed to hold addresses in reserve in support of the ARIN policy (which did achieve consensus) until such time as the IETF/IAB takes appropriate action to make it available, I believe that your statement would be more accurately:

This will keep coming back until it either passes or until IPv4 is well on its way to being decommissioned and it becomes moot.

Owen

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 04 Aug 2011 19:25:23 -0500

Hi, Brian.

> block", but clearly YMMV.

For what it's worth, I personally agree with your conclusion above.

However, the IAB offered a different opinion to the ARIN board. See
http://www.iab.org/documents/correspondence-reports-documents/2011-2/respons
e-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/ for
details. This is documented along with other details in
http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-01.

As a result, I think the ARIN board is reasonable in asking for consensus.

Cheers,
-Benson

---

From: Owen DeLong <[email-masked]>
Date: Thu, 4 Aug 2011 17:21:50 -0700

Brian,

	If you can get the IAB to recant their statement otherwise to ARIN
and give ARIN documentation that they agree with you and feel ARIN
is within its charter to do so, then this problem is actually solved and
ARIN can allocate the space without this last call succeeding.

	Absent that, the IAB has interpreted your document differently than
you intend and their ruling stands as the "law of the land" for all practical
purposes.

Owen

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 04 Aug 2011 18:12:45 -0700

> would you (feasibly) arrange for it to be rare, easily detected, and (feasibly) fixed?

*Most* "residential" customers are actually in a very tiny portion of 
RFC1918 space. And the detection strategies range from the various 
information leakage-before-changeover approaches, like watching their 
DNS queries, to having customers run software (even from a web page) 
before you switch them, all the way to my personal favorite: "Dear 
Customer, your service is about to be seriously degraded by an 
additional layer of NAT. If you are using <10.99.88.0/24> for your 
internal network OR you experience a complete outage of your service 
after <changeover date> please call our support number."

> being allocated to this purpose instead of one. How does that benefit the community?

100s and 1000s of address blocks are already allocated to suboptimal 
purposes... how is this any different? They're going to run out one way 
or another. And soon.

> some other business with whom you also happen to be a competitor.

Well, post-runout one of you will probably buy the other, thanks the 
these same "operational realities".
> this. It really is in the best interests of the internet to make this happen.

It is "a little easier for ISPs"... I would say that this is in the 
"best interests" of almost anyone else. The end-users who'll find 
themselves behind another layer of NAT? Nope. The corporate IT 
departments that will misuse this instead of switching to IPv6? Nope. 
The ISPs that put content servers here instead of switching to v6 or 
even just optimizing the use of their existing space? Nope.
I could go on, obviously.

> No, it actually increases it because the requests that will result from a denial will far exceed a /10.

Doesn't matter either way, really.

> space that have not caused any harm to those other than the ones misusing the space, so, I don't see any reason for this to be different.

The point is that this particular misuse of the space is such that if it 
happens, the situation between the customer and the ISP is *no 
different* than if RFC1918 had been used. You can't argue that RFC1918 
won't work *and* that the above outcome is acceptable simultaneously.

> to the ISP NAT network and there would be no conflict as a result.

You pulled that 99% out of the same place you found the number that 
tells me that residential users are using "all" of RFC1918, when we both 
know that most of them are in 192.168.1.0/24.

> Which is utterly irrelevant to the IETF discussion.

Sure. We can take the required restriction to the other list... but the 
ARIN proposal *is* an appendix to one of the two drafts here, and *is* 
the source of the addresses. IF the ARIN proposal results in a block 
that, due to ARIN policy reasons, is unable to be used for this use case 
then this use case can no longer be a justification for the IETF 
agreeing to the idea.

> I don't believe anyone is considering this an IPv6 transition mechanism.

Section 1 of the draft under consideration: "This document requests that 
an IPv4 /10 be reserved as Shared Transition Space solely to facilitate 
deployment of IPv6 transition/IPv4 coexistence technologies."

> I believe it is being treated as a survival technique to allow operators
> However, I don't think anyone is regarding this as an opportunity to avoid or postpone deploying IPv6.

Don't believe you. Especially when the other draft specifically calls 
out the use case of extending IPv4 lifetime by putting content 
distribution servers in this space (a way for ISPs to postpone deploying 
IPv6) and extranet servers in this space (a way for corporations to 
postpone deploying IPv6).

Take the use cases out as part of the justification for the request if 
you don't want the request read this way.

>   I think they are looking to survive long enough to get IPv6 deployed and to keep operating the things that have to keep working on IPv4 that are incapable of doing IPv6 on the customer end of things at least to the extent possible.

So the emergency they created is my problem... why?

> It does not counter the goal of facilitating IPv4 to IPv6 transition, it merely makes that process a little less painful.

Disagree. It allows transition to be postponed.

> Which is still utterly irrelevant to the IETF discussion.

See above for the reasoning. (Can't rely on that block being available 
if it is restricted.)

> an accelerated last call and adoption.

Then I believe we're doing this in the wrong order. How can I possibly 
comment as to whether or not a block should be set aside if there's not 
yet been last call on a document describing how that block would be used?

I have hypothesized above about what it might be used for, and pointed 
out that at least two of those are bad ideas. But it'd be even better to 
get the actual usage documented before we rush this through. I'm sure 
ARIN can hold the /10 if that's what it takes.

> Yes. Thus, care must be taken to avoid an overlap that has impact.

And this is different than just using RFC1918 instead of allocating a 
new /10 how?

> Thus you have just made an excellent argument in favor of this draft.

I've made an excellent argument in favor of accelerating, not 
postponing, the transition certainly.

> This will keep coming back until it either passes or until IPv4 is well on its way to being decommissioned and it becomes moot.

Well, last I checked it wasn't appropriate to just keep trying to push 
the same thing through that has been repeatedly rejected, and with good 
associated reasons. If the IETF allows this, it will open the door to 
hundreds of other resubmits of equally bad ideas that have been 
previously rejected.

Matthew Kaufman

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Aug 2011 13:32:55 +1200

Owen,

> 	If you can get the IAB to recant their statement otherwise to ARIN

Unfortunately the IAB web site appears to be bizarrely broken from where
I sit, and the document is inaccessible (even via the Google cache).

> you intend and their ruling stands as the "law of the land" for all practical

I have no intention of debating the IAB on this, if they've reached the
opposite conclusion to me. As I said, YMMV, and it's today's IAB that
oversees today's IANA. (However, I think the draft should refer to the
IAB opinion, and somebody should fix the IAB web site.)

This doesn't change my personal opinion, but once again - that's *my* problem.

   Brian

---

From: William Herrin <[email-masked]>
Date: Fri, 5 Aug 2011 00:24:01 -0400

On Thu, Aug 4, 2011 at 7:03 PM, Matthew Kaufman <[email-masked]> wrote:
> space in all cases except those where the specific block from RFC1918 space
> conflicts with customer internal use, a situation which can be arranged to
> be rare and which is easily both detected and fixed if encountered.

Matthew,

Consider:

My ISP's local modem pool: 10.1.2.0/27
My IP address today: 10.1.2.3
My company's VPN concentrator: 203.0.113.1
My company's intranet server: 10.1.2.3
My company's file servers: 10.1.2.4-30

My routing table with the VPN active:
10.1.2.3/32 = PPP adapter
203.0.113.1/32 -> PPP adapter
0.0.0.0/0 -> VPN adapter

Successful pings to intranet.mycompany.com (10.1.2.3): 100%
Successful HTTP connections to intranet.mycompany.com (10.1.2.3): 0%.

And tomorrow when I dial up again and get 10.1.2.14 as my address, one
of the file servers mysteriously won't work.

I won't go through the counter-examples for every position centered on
the claim that it's "easy" for ISPs to use RFC1918 space for their
CGNs. The CGNs need to use space which does not conflict with any of
the ISPs' subscribers _OR_ any systems which any of their subscribers
interact with while connected to that ISP. For better or for worse,
RFC1918 space won't be satisfactory for CGN use.

> space, and thus will be used for numerous other applications outside of the
> applicability statement in Section 4 of the draft.

I observe that everybody disables congestion control in TCP because
they can get away with it and it advantages them. Oh wait, that's
right: they don't.

Folks are on notice from day 1 that use of the shared addresses
outside the applicability scope *will* cause problems for only them
and their users. Anyone foolish enough to do it anyway (and there are
unlikely to be more than a handful) will undo their mistake when they
suffer conflicts like the one I described above.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Owen DeLong <[email-masked]>
Date: Fri, 5 Aug 2011 01:51:18 -0700

On Aug 4, 2011, at 6:12 PM, Matthew Kaufman wrote:

> *Most* "residential" customers are actually in a very tiny portion of RFC1918 space. And the detection strategies range from the various information leakage-before-changeover approaches, like watching their DNS queries, to having customers run software (even from a web page) before you switch them, all the way to my personal favorite: "Dear Customer, your service is about to be seriously degraded by an additional layer of NAT. If you are using <10.99.88.0/24> for your internal network OR you experience a complete outage of your service after <changeover date> please call our support number."
> 

1. *Most* residential customers may be, but, *ENOUGH* residential customers to pose a significant and costly problem are spread
	all over the map. There are some CPE routers out there that default to having the customer choose 10/172/192.168 and then
	pick random numbers to fill in the rest of the blank and/or just use that whole range and default to very sparse DHCP algorithms
	that might as well be random. The collision potential with any range chosen by the ISP is high.

2. You are assuming that having them call the support number is somehow a desirable outcome. When you are charging $20-50/month
	for a service, having 1% of your 10,000,000 customers call in a month (100,000 phone calls) is damagingly expensive.

> 100s and 1000s of address blocks are already allocated to suboptimal purposes... how is this any different? They're going to run out one way or another. And soon.
> 

I can't think of a better way to indicate that at its worst, this proposal is harmless.

> Well, post-runout one of you will probably buy the other, thanks the these same "operational realities".

I don't think that is necessarily true. In fact, it's equally likely that some other party will buy the other and decide that they want those
addresses for a different purpose, vacate my space and tell me to get off of theirs.

> It is "a little easier for ISPs"... I would say that this is in the "best interests" of almost anyone else. The end-users who'll find themselves behind another layer of NAT? Nope. The corporate IT departments that will misuse this instead of switching to IPv6? Nope. The ISPs that put content servers here instead of switching to v6 or even just optimizing the use of their existing space? Nope.

This will reduce the number of end users who will find themselves behind another layer of NAT, so, yes, it is in their interests.

Even with the proposed and/or identified corporate misuses of this space you described, it would not help them to avoid switching to IPv6,
so, that argument is specious at best. In any case, I really don't think it is the job or mission of the IETF to protect corporate IT from their
own failure to read RFCs.

ISPs that are likely to put content servers here are not likely to do it instead of switching to IPv6, they are likely to do it in parallel to switching
to IPv6, so, again, that argument is still specious.

As to optimizing the use of their existing space, this proposal allows them to do just that (see my response to your first point).

> Doesn't matter either way, really.
Ah, but, actually it does. It won't change the end date, but, it may (dramatically) reduce the number of users on whom NAT444 is inflicted.

> The point is that this particular misuse of the space is such that if it happens, the situation between the customer and the ISP is *no different* than if RFC1918 had been used. You can't argue that RFC1918 won't work *and* that the above outcome is acceptable simultaneously.
> 
While this is true, in the case of RFC-1918, it becomes a pissing contest between the customer and the ISP with the ISP having no
valid leg to stand on for why the customer should have to renumber their internal network. In the case of this space, OTOH, there's
documented RFC reasons why they shouldn't have used it this way.

Additionally, as you pointed out, it's not likely to be the 10,000,000 residential customers that misuse it this way, it's likely to be the business
customers who are:

	1)	A much smaller percentage of customers
	2)	Higher revenue than residential per circuit, generally
	3)	More reasonable in most cases than residential customers

So, while it may be mathematically no different from a purity of the solution standpoint, the economic realities of the two situations are
radically and meaningfully different.

> You pulled that 99% out of the same place you found the number that tells me that residential users are using "all" of RFC1918, when we both know that most of them are in 192.168.1.0/24.
> 

Actually, surveys conducted to date indicate that far less than 50% of them are in 192.168.1. Perhaps most of your users are on Linksys,
but, that does not mean that is the case nationwide, throughout the ARIN service region, or, world wide. Other manufacturers have different
defaults. No, I did not pull the idea that residential users are using "all" of RFC1918 out of my imagination. There have been studies of the
type you recommended above that have shown that it is not so convenient as that.

While I admit I didn't do an advanced analysis of the numbers, it doesn't take a rocket scientist to realize that corporate VPN endpoints (the things you said would be numbered in this space) are not at all likely to use those numbers as source addresses to talk to the external internet.

> Sure. We can take the required restriction to the other list... but the ARIN proposal *is* an appendix to one of the two drafts here, and *is* the source of the addresses. IF the ARIN proposal results in a block that, due to ARIN policy reasons, is unable to be used for this use case then this use case can no longer be a justification for the IETF agreeing to the idea.
> 

Or the ARIN policy can be modified to bring it in line with the IETF document, OR, the address space, since ARIN is relinquishing it to IANA for
allocation according to this RFC and using the policy as the enabling language to do so would not actually be subject to the ARIN policy once
so relinquished, etc.

There are many ways to deal with that discrepancy.

> Section 1 of the draft under consideration: "This document requests that an IPv4 /10 be reserved as Shared Transition Space solely to facilitate deployment of IPv6 transition/IPv4 coexistence technologies."
> 

Yes… THIS space is not a transition mechanism. It is an ENABLER for OTHER transition mechanisms.

> Don't believe you. Especially when the other draft specifically calls out the use case of extending IPv4 lifetime by putting content distribution servers in this space (a way for ISPs to postpone deploying IPv6) and extranet servers in this space (a way for corporations to postpone deploying IPv6).
> 
Extending IPv4 lifetime IS NOT the same as postponing deployment of IPv6. Even with IPv6 deployed, there are valid reasons to preserve
certain IPv4 functions.

You are mistaking keeping IPv4 alive for not implementing IPv6. It is a logical fallacy to conflate the two.

IPv4 does not have to die for IPv6 to get deployed.

> Take the use cases out as part of the justification for the request if you don't want the request read this way.
> 

The use cases talk about preserving IPv4. They do NOT talk about delaying IPv6.

> So the emergency they created is my problem... why?

They did not create the emergency and it isn't your problem. You are not harmed by the allocation of this space to this purpose.

> Disagree. It allows transition to be postponed.

It really doesn't.

> See above for the reasoning. (Can't rely on that block being available if it is restricted.)
> 
See above for rebuttal to the flawed reasoning.

> Then I believe we're doing this in the wrong order. How can I possibly comment as to whether or not a block should be set aside if there's not yet been last call on a document describing how that block would be used?
> 
> I have hypothesized above about what it might be used for, and pointed out that at least two of those are bad ideas. But it'd be even better to get the actual usage documented before we rush this through. I'm sure ARIN can hold the /10 if that's what it takes.
> 

That document is largely informational in nature. This document actually provides the limitations and restrictions on the use of the space and it's purpose for issuance.

> And this is different than just using RFC1918 instead of allocating a new /10 how?
> 

This particular aspect is not. However, of the millions of subscribers on the average large residential provider network, as has been recently
pointed out to me, very very few of them actually multi home. So, it differs in the implementation details due to the difference in the type and
magnitude of the afflicted audience.

> I've made an excellent argument in favor of accelerating, not postponing, the transition certainly.
> 

When you have a machine capable of going faster than the speed of light, let me know. In the meantime, let's stick to reality. The transition
isn't going to accelerate enough to make the difference required here. As much as I would like to see that happen, it isn't realistic.
Since meaningful acceleration is not realistic, we have to look at what can actually be done to mitigate and address the realities we
are faced with.

> Well, last I checked it wasn't appropriate to just keep trying to push the same thing through that has been repeatedly rejected, and with good associated reasons. If the IETF allows this, it will open the door to hundreds of other resubmits of equally bad ideas that have been previously rejected.
> 

I don't see how a body that is governed by the consensus of those that show up can avoid it. The reality is that as this becomes more  and more critical to the operational community, the nature of who comes to the IETF asking for this will continue to evolve until there is enough operator focus on the IETF that there is no alternative.

Owen

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 05 Aug 2011 10:21:45 -0700

> 	for a service, having 1% of your 10,000,000 customers call in a month (100,000 phone calls) is damagingly expensive.

So have them visit a web page beforehand that checks to see what their 
addressing situation is or something... in reality, I think any ISP that 
isn't budgeting for more support costs for users they move to NAT444 
(which is the only problem, because NEW customers on NAT444 can be told 
very clearly that certain RFC1918 blocks are "off limits"... or even 
have that enforced by CPE software changes) is going to be in for a big 
expensive surprise.

> Yes… THIS space is not a transition mechanism. It is an ENABLER for OTHER transition mechanisms.

And a DISABLER for the transition itself, in that it extends the 
lifetime of IPv4 by allowing ISPs to place content servers in the space 
instead of on IPv6 addresses, allowing corporate IT departments to put 
extranet servers in the space instead of on IPv6 addresses, etc.

>
> Extending IPv4 lifetime IS NOT the same as postponing deployment of IPv6.

Disagree. If IPv6 deployment incentives were in fact independent of IPv4 
runout, then IPv6 deployment would either be A) a lot farther along or 
B) not started for most people. And yes, strangely, everyone's IPv6 
planning seems to have gotten a big boost with the threat of runout.

Take away the threat, and it slows right back down.

> IPv4 does not have to die for IPv6 to get deployed.

But it does have to get really close to dead.

> The use cases talk about preserving IPv4. They do NOT talk about delaying IPv6.

Right. And the use cases should talk *exclusively* about enabling NAT444 
so that dual-stack w/IPv6 + NAT444 is possible, *not* about several 
other ways this shared block can be (mis)used to extend the lifetime of 
IPv4 services.

> That document is largely informational in nature. This document actually provides the limitations and restrictions on the use of the space and it's purpose for issuance.

Then modify this document to restrict the use to exclusively NAT444. 
Otherwise the resulting RFC will create a mixed message, and those 
corporate IT departments will be able to point right at those sections 
when arguing with you about what your NAT did to them.

Matthew Kaufman

---

From: Chris Grundemann <[email-masked]>
Date: Fri, 5 Aug 2011 11:35:35 -0600

> Right. And the use cases should talk *exclusively* about enabling NAT444 so
> that dual-stack w/IPv6 + NAT444 is possible, *not* about several other ways
> this shared block can be (mis)used to extend the lifetime of
> IPv4 services.
<...> 
> corporate IT departments will be able to point right at those sections when
> arguing with you about what your NAT did to them.

I am not sure we are reading/discussing the same document, just to be sure here is the bit I find relevant to your statement (from the ID in WGLC - http://www.ietf.org/id/draft-weil-shared-transition-space-request-03.txt):

4.  Shared Transition Space

   This document proposes the assignment of a /10 as Shared Transition
   Space.  Shared Transition Space is IPv4 address space reserved for
   Infrastructure provider use with the purpose of facilitating IPv6
   transition and IPv4 coexistence deployment.  The requested block
   SHOULD NOT be utilized for any purpose other than as "inside"
   addresses in a carrier NAT environment (e.g. between the CGN and
   customer CPE devices) or for other IPv4 to IPv6 transition
   infrastructure.  Network equipment manufacturers MUST NOT use the
   assigned block in default or example device configurations.

I find that quite clear on what an acceptable use of this space is. The details of applicability of and justification are left out, for further debate, but the intent of this space is well defined in the draft, imho. It IS for use by service providers to facilitate transition to IPv6, it is NOT for use by anyone else (corporate IT departments included) for any other purpose.

Cheers,
~Chris

---

From: Owen DeLong <[email-masked]>
Date: Fri, 5 Aug 2011 10:32:08 -0700

On Aug 5, 2011, at 10:21 AM, Matthew Kaufman wrote:

> So have them visit a web page beforehand that checks to see what their addressing situation is or something... in reality, I think any ISP that isn't budgeting for more support costs for users they move to NAT444 (which is the only problem, because NEW customers on NAT444 can be told very clearly that certain RFC1918 blocks are "off limits"... or even have that enforced by CPE software changes) is going to be in for a big expensive surprise.
> 

That really doesn't solve the problem. Budgeting for it would require unwelcome price increases. If you raise your prices and
your competitors don't, you don't increase revenue, you decrease your customer base. The economic reality on the ground
simply doesn't support your approach.

> And a DISABLER for the transition itself, in that it extends the lifetime of IPv4 by allowing ISPs to place content servers in the space instead of on IPv6 addresses, allowing corporate IT departments to put extranet servers in the space instead of on IPv6 addresses, etc.
> 

Continuing to propagate this fiction does not make it true. There is no way in which this space inhibits the transition. Extending the life
of IPv4 does NOT in any way block or impair deployment of IPv6. One might have been able to argue at one point that it would reduce
the pressure to deploy IPv6, but, even that is not really true any more.

You keep saying instead of and ignoring the more likely probability of in addition to.

> Disagree. If IPv6 deployment incentives were in fact independent of IPv4 runout, then IPv6 deployment would either be A) a lot farther along or B) not started for most people. And yes, strangely, everyone's IPv6 planning seems to have gotten a big boost with the threat of runout.
> 

As you have stated, this will not really delay the runout of IPv4. It will merely reduce the number of customers that have to be subjected to NAT444 when runout occurs and make the NAT444 transition less painful for the service providers that are forced to deploy it.

> But it does have to get really close to dead.

And it's already that close. This proposal won't change that momentum at this point.

> Right. And the use cases should talk *exclusively* about enabling NAT444 so that dual-stack w/IPv6 + NAT444 is possible, *not* about several other ways this shared block can be (mis)used to extend the lifetime of IPv4 services.
> 

Then argue that in the debate around the other draft, but, regardless of the final set of use cases, the space needs to be set aside for NAT444+IPv6 whether or not those other use cases end up as part of the consensus version of the other draft or not.

> Then modify this document to restrict the use to exclusively NAT444. Otherwise the resulting RFC will create a mixed message, and those corporate IT departments will be able to point right at those sections when arguing with you about what your NAT did to them.
> 

I disagree.

Owen

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 05 Aug 2011 10:40:44 -0700

> I find that quite clear on what an acceptable use of this space is. The details of applicability of and justification are left out, for further debate, but the intent of this space is well defined…

Change SHOULD NOT to MUST NOT.

More clearly define "or for other IPv4 to IPv6 transition 
infrastructure" so that it is clear that it doesn't include things like 
CDN server IPv4 addresses  or anything else that prolongs the utility of 
IPv4 by numbering things in this space.

And if we're ever going to take the other draft 
(draft-bdgks-arin-shared-transition-space) or something like it to last 
call, it should go to last call *first* so that this draft can reference 
it. Otherwise we're going to reopen this same can of worms in short order.

Matthew Kaufman

---

From: "Schiller, Heather A" <[email-masked]>
Date: Fri, 5 Aug 2011 16:24:16 -0400

I am opposed to reserving a /10 for shared transition.  In particular I am opposed to pulling a block for this purpose out of space already delegated to a [any] region, regardless of whether the most active in a region support volunteering a block for the purpose.  I think good stewardship of the space would be to allow it to be allocated naturally per regional policies.  As you deploy nat444 you will free up address space in your own network- but taking away a /10 from the community can prevent other networks from growing.  There is nothing that prohibits folks who have deployed nat444 from sharing with each other the range of IP's they have used, and feel can be safely used in another nat444 deployment.  

"The requested block should not be utilized for any other purpose"  That's a nice "should" which will quickly be forgotten.  It doesn't matter what gets put into an RFC, folks are going to use the space however they want on the inside of their network.  Look at the extensive use of 1/8 and other netblocks that have now been allocated.  The only reason that multicast space or class E space is not used on lan's for private addressing is that equipment vendors hard coded it to be handled differently.  I'm just pointing out that you aren't going to stop people from using it any way they with.   

I do agree with Owen's sentiments that facilitating NAT444 will make it easier, and likely for folks to [further] delay v6 deployment.   

--Heather

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Grundemann
Sent: Friday, August 05, 2011 1:36 PM
To: [email-masked]; Owen DeLong
Cc: [email-masked]
Subject: Re: [OPSAWG] WGLC on shared transition space

> Right. And the use cases should talk *exclusively* about enabling 
> NAT444 so that dual-stack w/IPv6 + NAT444 is possible, *not* about 
> several other ways this shared block can be (mis)used to extend the 
> lifetime of
> IPv4 services.
<...> 

Cheers,
~Chris

---

From: Owen DeLong <[email-masked]>
Date: Fri, 5 Aug 2011 13:51:39 -0700

> I do agree with Owen's sentiments that facilitating NAT444 will make it easier, and likely for folks to [further] delay v6 deployment.   

Interesting… Do you agree with me, or, are you agreeing with what I said. I do not believe that facilitating NAT444 will actually
do so… That's Matthew Kaufman.

The benefit to the community of this proposal is that it reduces the number of users that have to be subjected to NAT444.

It doesn't delay IPv4 exhaustion.
It doesn't facilitate a delay in IPv6 deployment.
It doesn't eat small children.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Aug 2011 09:16:12 +1200

Owen,

> The benefit to the community of this proposal is that it reduces the number of users that have to be subjected to NAT444.

I don't quite understand that claim. It seems to me that the amount of NAT444
deployment is orthogonal to having a designated prefix available - see my
next comments.

> It doesn't delay IPv4 exhaustion.

Agreed, because if there is no designated prefix, ISPs will find a bogon prefix
to use instead. Or they will figure out a work-around using RFC 1918 space
(despite the quite valid responses to Matthew showing why this is problematic).

> It doesn't facilitate a delay in IPv6 deployment.

Agreed. It is the availability of CGNs that will give some ISPs a way to
ignore IPv6 for a while longer. Having a designated prefix is just an
operational convenience.

    Brian

---

From: William Herrin <[email-masked]>
Date: Fri, 5 Aug 2011 17:34:21 -0400

On Fri, Aug 5, 2011 at 5:16 PM, Brian E Carpenter
<[email-masked]> wrote:
>> The benefit to the community of this proposal is
>> that it reduces the number of users that have to
>> be subjected to NAT444.
>
> deployment is orthogonal to having a designated prefix available

Hi Brian,

If each ISP has to carve out its own NAT444 space then we'll get worse
efficiency, resulting in more addresses overall being consumed by
NAT444 deployments. That leaves fewer IPv4 addresses available for
classic use which means more users in total being subjected to NAT444.

It's a weak line of reasoning but it's not wrong.

Regards,
Bill Herrin

---

From: Owen DeLong <[email-masked]>
Date: Fri, 5 Aug 2011 15:55:31 -0700

> deployment is orthogonal to having a designated prefix available - see my
If providers get a shared /10 that they can use for this purpose, they do not have
to kick existing users off of their current space to recycle it for that purpose.

> ignore IPv6 for a while longer. Having a designated prefix is just an

It really won't. There was a time when I would have believed this argument, but,
at this point, there is enough momentum building behind IPv6 that they will be
unable to do so due to the number of things at the other end which will require
IPv6 to be reachable.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 5 Aug 2011 15:53:54 -0700

> do so… That's Matthew Kaufman.

Oops… I made the same mistake… I meant are you agreeing with me or agreeing with what you (Heather) said.

---

From: Chris Donley <[email-masked]>
Date: Fri, 5 Aug 2011 17:11:23 -0600

Brian,

On 8/5/11 3:16 PM, "Brian E Carpenter" <[email-masked]> wrote:

>> The benefit to the community of this proposal is that it reduces the
>>number of users that have to be subjected to NAT444.
>
With current rates of growth, we've calculated that the excess demand for
IPv4 addresses will reach ~20% across the industry at the high-water point
(YMMV, depending on rates of growth within a specific ISP, tech savvy of
the customer base, etc).  With tightening address policies in the ARIN
region, N. American ISPs would be able to get maybe 1-1.5% IPv4 addresses
for CGNs, leaving a large gap.  As you mention, bogon space is one option.
 The others are to move a larger pool of users (e.g. Up to 20% of existing
users) behind the CGN and re-use their address space for both the existing
and new users, and/or to use multi-level CGN (ouch!).

In addition to the back side addresses for the CGN, there's also the
question of the front side public addresses.  They will likely come from
currently-assigned GUA addresses.  Shared transition space in the back-end
could free up addresses from infrastructure components that don't need to
talk to the Internet, thereby moving the addresses to customers who do,
rather than subjecting still more users to CGN.

>(despite the quite valid responses to Matthew showing why this is
My fear is that the bogon prefix might be 'squat' space, and it might vary
per provider.  This would be a poor outcome for the entire community. See
RFC 6319, Section 4.2.2.

>ignore IPv6 for a while longer. Having a designated prefix is just an

We've been testing CGN in our lab (twice now), and it does not offer the
same experience with IPv4 that we're used to.  When IPv6 is available in a
market, it will offer a better experience, assuming that the customer has
IPv6-capable gear and the Internet content is available over IPv6.  At
that point, I think there will be clear demand for IPv6 service,
especially compared to IPv4-with-CGN. IPv6 has been part of DOCSIS
specifications since 2006 - the biggest challenge we're facing now is
getting IPv6-capable consumer electronics into subscriber homes.  While
Service Providers have a role to play in bringing IPv6 to subscribers,
ultimately, it is the subscribers who will decide how long IPv4 must be
supported.  

Chris

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 06 Aug 2011 22:32:22 -0400

Chris/Brian

First.  Support the draft 100%.

A couple of leading comments.

In real world tests of CGN (NAT444) we have found problems with using
RFC1918 in the NAT Zone (CPE <-> CGN) space forcing our resolve to require
non-RFC1918 space for this usage.

Assuming we had enough RFC1918 addresses for CGN (which we don't for a
production rollout), it's too problematic to use.  Global Unicast Space
(non-RFC1918) has shown to work very well in our production tests.

Use of CGN dose not change the resolve of an ISP to roll out IPv6.  IPv6
will continue at it's set pace (quickly for some, more slowly for others).
 CGN can be used as an assist/glue technology in a dual stack service
offering quite well.

>rather than subjecting still more users to CGN.

This is a vary valid use of this space.  ISPs who can use the "Shared
Transition Space" in this type of circumstance can in fact help avoid CGN.

>>> It doesn't delay IPv4 exhaustion.

We are not talking about delaying exhaustion.  We are talking about
managing it.

>>
>>Agreed, because if there is no designated prefix, ISPs will find a bogon
>>Prefix

This will happen without transition space.

>per provider.  This would be a poor outcome for the entire community. See

This is a very big concern.  Having ISPs choose different parts for the
IPv4 space to use in the CGN (NAT444) zone would be very challenging.  It
will be harder to develop and enforce good network policy.

Having a consistent block allows for cleaner industry wide management of
this space.

Regards,

Victor Kuarsingh

---

From: Arturo Servin <[email-masked]>
Date: Thu, 4 Aug 2011 16:08:09 -0300

Not in favour, not against. Only one comment.

> "consensus between the IETF and RIR communities" on this issue. It isn't

	There is no such thing as "RIR communities" consensus. ARIN != "RIR communities".

	Last time that I checked it was only one RIR supporting this draft at community level. I encourage authors to change the text accordingly.

> It is strange that draft-weil doesn't reference RFC 6319 and RFC 6269.

Regards,
-as

---

From: "t.petch" <[email-masked]>
Date: Wed, 17 Aug 2011 09:45:43 +0200

I think that this is a bad idea and one that the IETF should not endorse.  I
suspect that the ISPs will go ahead anyway, in their own way, but that should be
their choice, not as an officially sanctioned approach.

I see Brian asking for a phase-out plan, but I think that this is one of those
uses of technology that, once approved, will be with us for ever, never to be
phased out.

I would rather see the ISPs putting more effort into getting IPv6 in place for
real, eg 464 and not 444.  My ISP, for example, has recently announced an IPv6
trial for 2012, no sign of a production network (I notice that supporters of
this proposal, who of course are on this list as individuals, as we all are,
have e-mail addresses with a domain part for that ISP:-(

Again as Brian said, this should have been thought about years ago; we should be
thinking now about the problems of IPv6 and eliminating them.

Tom Petch

> > A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-0
3.txt
> > This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03
.txt

---

From: Owen DeLong <[email-masked]>
Date: Wed, 17 Aug 2011 02:38:41 -0700

Tom,

Step out of the ivory tower for a moment and look at the real world.

Anyone who knows me will have a pretty hard time saying that I am not
an IPv6 zealot. My official job title is IPv6 Evangelist and I work for Hurricane
Electric. You won't find too many people who do more IPv6 cheerleading
than I do.

However, there's also reality and trying to keep things running and keep
customers happy through the transition process.

Reality… No matter how well an ISP does on making IPv6 available to
their customers, the fact that the customer still has a bunch of electronics
that need to talk to the internet and won't speak IPv6 means that we have
to provide a  way for them to talk to IPv4 for the foreseeable future
no matter how much we wish that wasn't the case.

Keeping things running… Since we have to provide some mechanism
for customers to reach the IPv4 internet, we're going to be faced with
some form of multi-layer or multi-protocol NAT that will (in most cases)
require some form of intermediate addressing.

One of the least disruptive approaches available is 444. While there
are some things that can be done with 464, in reality, it has it's problems,
too and in most production environments, it's a lot more sensible to run
native 6 and 444 parallel to each other than to try and force everything
through an IPv6 translation (and back).

I'm all for thinking about and eliminating the problems of IPv6. I'd love
to see us solve the route scalability problem with some form of feasible
and widely deployable locater/ID split solution.

I'd love to see us make DHCPv6 and SLAAC both fully capable standalone
autoconfiguration protocols so that a site administrator can choose the one
that best meets his/her needs.

I'd love to see vendors putting RA Guard into all the WAPs and Switches.

However, this is a real problem with a relatively simple solution that makes
sense. The operational community in the ARIN region overwhelmingly
supports this proposal. If I understand correctly, the main objection in the
APNIC region was "Not from our address space", but, they generally supported
the idea of reserving the block.

As to domain parts… I'm a supporter of this proposal and my ISP is
most definitely dual stacked, so, while some supporters may be with
ISPs that don't have production IPv6 networks as yet, you certainly
can't make that claim in my case. Both of my upstream
ISPs (6939 and 8121) are most definitely dual-stack. My network
is most definitely dual stack.

However, even in my fully dual-stack environment (including my
printer), I still have a few devices that are not dual-stack.
	2* yamaha amplifiers
	3* TiVO boxes
	1* Nintendo Wii
	2* Sony Playstations (1@ PS2, PS3)
	1* HD-DVD Player (yeah, I know, but, I still have the discs and they still play)
	2* Blu-Ray Players
	1* Livingston Portmaster 2e

Owen