Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Sep 2011 21:35:18 +0300

I reviewed this document as a part of IESG document approvals this week.

I have to say that I found it difficult to decide whether to recommend the approval of this or not. We are in a difficult position, out of addresses, having to deploy NAT444, having to choose between the bad and even worse alternatives. It is hard for me to evaluate whether the proposed allocation will reduce pain more than it will cause pain elsewhere. In other words, is this making the Internet work better.

But there is clearly consensus in the operator community that we need this. However, I have one concern. The document is quite silent on the impacts. And there are negative impacts. For instance, anything that today checks for RFC 1918 space is potentially going to get a wrong answer tomorrow unless the code is changed to support the new private address space. And I don't know what things might be impacted. It is certainly possible for hosts to attempt to discover their externally visible IP addresses, query their access router for its external address, employ address testing in their NAT traversal solution (most non-trivial applications have one), and so on.

I did a quick check with a few pieces of software and found out that in at least some fraction of them there seems to be code that is testing for this stuff. I looked at the Linux kernel source, Asterisk SIP server, Skype, and the Chromium browser. I looked for decimal 192 and 168 on the same line either in the source code or strings from binaries, and then looked at the found instances myself to understand what they might be about. Skype produced an inconclusive or negative answer, I did not find these patterns in the binary. Asterisk clearly had code for testing addressing, hard coded to the current RFC 1918 addresses. Chromium had  strings for 10/8 and 192.168/16 but it was hard to tell what it is using them for. Linux kernel used these addresses in many places but as far as I could tell, none of them were about testing, so they might be fine.

So what breaks if a test goes wrong? The true answer is that I don't know. But it is certainly possible that an application ends up not working because it chose to use an address that is not globally visible, or that some delays are incurred when addresses are tested in suboptimal order. And so on. Draft-well has a companion document, draft-bdgks, which sort of mentions this issue but dismisses it as bad implementation assumptions. I do not believe that is an appropriate assessment in a world where RFC 1918 status has been stable for a long time, and per evidence above, software in general seems to hardcode these addresses. This is reality, we need to face it. Draft-bdgks makes a much better argument when it states that the allocation of the new address space does not really change the impacts in this respect if NAT444 is deployed anyway but just using some otherwise agreed or bogon address space. This is true, but I think the official approval of new space from the IETF and 
ARIN will make this practice more widely known and used. It is our responsibility to deal with the impacts.

So here's what I would like to propose. The document goes forward but we make a much clearer statement with regards to the implications both for applications out there, as well as for subsequent IETF work:

- what types of impacts may be felt by the rest of the network (not the ISP that is deploying NAT444)
- what kinds of application practices may be affected
- what IETF specifications may need revision due to this (e.g., do we need to revise ICE etc)

(It would have been even better if we had access to research that has looked at the various impacts in a rigorous manner. E.g., what's the likelihood of ISP - subscriber address collision in the different parts of the current RFC 1918 space vs. what is the likelihood of application failures with the new space. Not sure if we have time for that research now unless it already exists.)

Jari

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 22 Sep 2011 15:28:46 -0500

Jari,

I found your review comments to be very thoughtful and helpful. I understand 
the concerns you are raising, and I agree that your proposed way forward is 
reasonable.

I did have one question:

> So here's what I would like to propose. The document goes forward but we 
> make a much clearer statement with regards to the implications both for 
> applications out there, as well as for subsequent IETF work:
>

Who was the "we" you were thinking of, making this statement?

(I think I'm asking, would this statement be part of this draft, or 
something else?)

Thanks,

Spencer

---

From: SM <[email-masked]>
Date: Thu, 22 Sep 2011 13:53:42 -0700

Hi Jari,
At 11:35 22-09-2011, Jari Arkko wrote:
>But there is clearly consensus in the operator community that we 
>need this. However, I

Are you referring to the correspondence between the IAB and ARIN at 
http://www.iab.org/documents/correspondence-reports-documents/2011-2/response-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/ 
to determine "consensus in the operator community?

Is the draft being approved for publication as an Informational 
RFC?  If so, I would appreciate if it documents IETF Consensus.

Regards,
-sm

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Sep 2011 00:00:11 +0300

Thanks for that question, it is a good one.

I would like these additions to be made to a new version of draft-weil. I'm willing to contribute, if necessary.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Sep 2011 00:03:41 +0300

SM,

There obviously has been discussions at ARIN and in the IAB. But when I said "consensus" in my e-mail, I was referring to discussions in the IETF.

Jari

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 22 Sep 2011 17:04:34 -0400

> RFC?  If so, I would appreciate if it documents IETF Consensus.

Before the allocation is made, it will need to be last called again as a BCP.

                                                 Ron

---

From: "George, Wes" <[email-masked]>
Date: Thu, 22 Sep 2011 17:10:02 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Thursday, September 22, 2011 2:35 PM
To: [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

Jari -
It's unclear from your statement if you're proposing adding the above to this draft or to a subsequent draft.

To respond to your concerns and recommendation, I think that there are three separate issues here that merit some discussion:

1) Does IETF recommend the practice of inferring address scope in IPv4 based on address/bit value (the actual numbers), and then using this to trigger different behavior based on that inferred scope?

2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as additional private-scope use cases?

3) Independent of consensus on the state of the *draft* directing it to happen, is there consensus on the *idea* that the /10 of IPv4 space should be reserved as shared transition space?

My own opinion on each question:

1) We do link the scope and bit values pretty closely in IPv6. Multicast (Class D) is definitely a scope link, and RFC6250 doesn't say otherwise, though it would have been a recent opportunity to clarify our position. My sense is that there are a number of standards (notably 3056) that recommend specific behavior when private-scope or non-unique addresses are used, but the terms "behind a NAT", "RFC1918 addresses" and "private addresses" are often used interchangeably, thus reinforcing this link between scope and value. However, draft-bdkgs section 4.1.2 implies that this is not a valid assumption to make, but your concerns over what breaks and how to test support the idea of a link, which is why I bring up the question.
I think that it might be useful to formalize this link, but I'm not sure if that belongs in these drafts, and I don't think that it's gating to them moving forward.

2) I really believe that one or both drafts should either be an update or -bis document for RFC1918. I believe that they are in essence documenting additional use cases for private scope address that are beyond what was covered in RFC1918, with the added requirement that they cannot conflict with the existing space. While the address space and use cases are not interchangeable for reasons documented in draft-bdgks, most of the same considerations regarding usage (how not to break things) apply to both. Formally updating RFC1918 would at least give implementers a warning that there is new space to test for wherever 1918 is referenced in an existing standard and should therefore address your concern.
Based on your proposal, if we don't formally update 1918, we end up having to go through existing standards to find places where the authors used RFC1918 interchangeably with "non-unique addresses" or "private-scope address space". We would then have to evaluate if they used this as an indicator to recommend a different behavior in cases where one can infer the address scope based on the bit value and decide whether those cases apply to this new space or not. I think that using 1918 as a baseline and only documenting items which are unique considerations for this space and application represents a lot less work than what you're proposing above, whether it's part of this draft or its own work.

3) The reason I bring up consensus for the idea rather than the document is that there seems to be some urgency behind getting *something* approved to make the allocation happen, but it seems to be driving this strange behavior to push through incomplete documents and sort out the details in subsequent drafts.
Assuming that it is in fact necessary to get the allocation completed rapidly, I'd rather see us split the logistics of making that happen from the process required to produce consensus documents. This may be as simple as IAB or IESG giving ARIN (and/or IANA) provisional clearance to allocate or reserve the space on the belief that there is consensus to make the reservation, but that we want our documentation in order before it is made public for use. That removes any pressure to push the documents through before they are ready, while still ensuring that the address space is available when we are happy with the documentation. If for some reason the document fails to achieve consensus in its final form, there's no harm in then telling ARIN that they must release the reservation.
Additionally, if we're talking about pushing draft-weil back for that much analysis, we're now talking about a non-trivial delay, and in that case it may make sense to simply put the two drafts back together since weil was supposed to go through quickly as a minimal draft with bdgks being the one that the community spent more time on to ensure completeness and consensus.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Sep 2011 00:59:22 +0300

Wes,

> :

Sorry. I think this should be a part of draft-weil. I think we'll end up making further work in this space (e.g., if some RFC needs an update then the actual update should probably be in another document) but I would like to see the high level impacts documented here.

> 1) Does IETF recommend the practice of inferring address scope in IPv4 based on address/bit value (the actual numbers), and then using this to trigger different behavior based on that inferred scop…

We could probably have varying opinions on this, but I think the reality is that software *does* depend on specific bit values, for better or worse. I propose we spend our effort elsewhere, we can't change the situation.

> 2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as additional private-scope use cases?

My personal concern was with making the impacts clear, but I think other people in the IESG have commented on the updates aspect. I personally think it would be useful if draft-weil updated RFC 1918, because then when someone looks up RFC 1918 from the web site they would see the Updates: header and go read the new RFC as well.

> Additionally, if we're talking about pushing draft-weil back for that much analysis, we're now talking about a non-trivial delay, and in that case it may make sense to simply put the two drafts bac…

Interesting thoughts. We discussed some of that in the IESG as well. For what it is worth, what I am asking should not be a long piece of text or require a huge amount of analysis. Basically, it should state that the effects are <here> and that these undesirable <implications> may be seen, and that <this type of IETF specifications> need revision. Making those actual revisions should be done in separate documents. We would only need a significant time if we decided that we are unsure if we want to make this allocation, and wanted to do research to understand the failure likelihoods of different options. (I'm personally in that camp, but I think I may be in the rough and/or it is too late to do it properly anyway.)

But if we are unsure and somehow asked ARIN to make the reservation anyway, the address space would already be nailed down, the knowledge of the actual usable space would leak and everyone would be using it anyway.

Jari

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Sep 2011 21:29:27 -0700

Dual-Stack Lite, RFC6333 that makes these conversions using a single NAT 
by combining IPv6 address space with a common 192.0.0.0/29.  This 
approach does not suffer from scaling limitations other than 
constraining access points to 6 IPv4 interfaces where IPv6 provides the 
native IP protocol.   While taking a chunk out of 240/4 should not 
introduce any hardship, the intended use is for compound NAT topology 
seems aimed at retaining the provider's IPv4 infrastructure.  Such 
inferior IPv4 networks will certainly expedite demand for IPv6 access.

Any IPv4 need can be satisfied by the CPE  that conforms with RFC6333 at 
roughly the cost of the monthly service.  Does it really make since to 
endorse a strategy that attempts to produce inferior networks to delay 
an upgrade and impact many services now offered over IPv4?  This is 
likely to be significant mistake, IMHO.

-Doug

---

From: Benson Schliesser <[email-masked]>
Date: Fri, 23 Sep 2011 00:21:15 -0500

On 9/22/11 4:59 PM, "Jari Arkko" <[email-masked]> wrote:

> Sorry. I think this should be a part of draft-weil. I think we'll end up
> making further work in this space (e.g., if some RFC needs an update then the
> actual update should probably be in another document) but I would like to see
> the high level impacts documented here.

Given constraints on existing IPv4 inventory (i.e. we're running out of the
stuff), our desire has been to have draft-weil proceed without delay.  We
hoped to leverage draft-bdgks for more detailed analysis.  To some extent,
the idea was to have a fast-track/slow-track approach to the conversation.

I appreciate that progressing draft-weil in absence of substantial analysis
may be undesirable, especially if there are concerns such as the ones you
raised.  However, I would like to make sure we don't lose sight of the need
for some urgency with draft-weil.

>> 1) Does IETF recommend the practice of inferring address scope in IPv4 based
>> on address/bit value (the actual numbers), and then using this to trigger
>> different behavior based on that inferred scope?
> 
> We could probably have varying opinions on this, but I think the reality is
> that software *does* depend on specific bit values, for better or worse. I
> propose we spend our effort elsewhere, we can't change the situation.

So what would this translate to, in terms of updates to draft-weil and/or
draft-bdgks?  I think it's safe to say that address-inferred scope will
break in a number of circumstances - basically, every time an address+scope
pairing is not what the implementation expects.  And this concern exists for
any new reservation that we make for scope purposes.

As you pointed out, draft-bdgks makes note that either GUA or the Shared
Transition Space (STS) will have a similar effect on existing
implementations when deployed behind a NAT. The only way to avoid these
impacts is to use RFC1918 space, because it's already well-known, which
frequently is not an option (for reasons described in draft-bdgks).

> My personal concern was with making the impacts clear, but I think other
> people in the IESG have commented on the updates aspect. I personally think it
> would be useful if draft-weil updated RFC 1918, because then when someone
> looks up RFC 1918 from the web site they would see the Updates: header and go
> read the new RFC as well.

We should be somewhat careful with this. I respect Wes' comments around
updating existing documents etc. But we would need to update RFC1918 in a
way that reflects the difference in scopes. The STS may have similar
semantics as RFC1918 space, in that it's non-routable on the Internet etc.
But it is not meant to be used in the same scope. While it would be
appropriate (when possible) to use RFC1918 space inside a CGN, it would not
be appropriate to use STS in many of the same places RFC1918 space is used.

>> Assuming that it is in fact necessary to get the allocation completed
>> rapidly, I'd rather see us split the logistics of making that happen from the
>> process required to produce consensus documents.
>> ...
> 
> Interesting thoughts. We discussed some of that in the IESG as well. For what
> it is worth, what I am asking should not be a long piece of text or require a
> huge amount of analysis. Basically, it should state that the effects are
> <here> and that these undesirable <implications> may be seen, and that <this
> type of IETF specifications> need revision. Making those actual revisions
> should be done in separate documents.

This is good guidance for moving forward quickly with draft-weil.  It's good
to have the approach outlined by Wes as a backup option, but I agree that it
amounts to effectively the same as allowing draft-weil to progress as-is.

As for research into the alternatives, some of that was discussed in
draft-bdgks.  If you have specific thoughts on how to improve upon that
analysis, I'd appreciate hearing them.

Cheers,
-Benson

---

From: SM <[email-masked]>
Date: Fri, 23 Sep 2011 01:38:18 -0700

At 14:10 22-09-2011, George, Wes wrote:
>Additionally, if we're talking about pushing draft-weil back for 
>that much analysis, we're now talking about a non-trivial delay, and 
>in that case it may make sense to simply put the two drafts back 
>together since weil was supposed to go through quickly as a minimal 
>draft with bdgks being the one that the community spent more time on 
>to ensure completeness and consensus.

The write-up mentions that this important draft should be progressed 
in a timely manner.  I don't know what gave a sense of this draft 
going through quickly.  The document got six DISCUSSes.  The Last 
Call comments were not addressed.

The entire issue is, in my opinion, due to a lack of planning by 
vendors of Internet 
services.  draft-bdgks-arin-shared-transition-space-03 represents the 
consensus of the ARIN region only.  It is being used as a basis to 
ask the IAB, through the IETF, to perform a protocol assignment.  It 
would set a bad precedent if such an assignment is made without 
careful analysis.  It would be better if the IETF spares itself the 
embarassment given that the IANA Contract is a hot topic.

I suggest that ARIN publishes its policy through the Independent 
Stream and documents the IPv4 addresses that will be used for 
so-called shared transition space.

Regards,
-sm

---

From: "George, Wes" <[email-masked]>
Date: Fri, 23 Sep 2011 09:58:09 -0400

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Thursday, September 22, 2011 5:59 PM
To: George, Wes
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

what I am asking should not be a long piece of text or require a huge amount of analysis. Basically, it should state that the effects are <here> and that these undesirable <implications> may be seen, and that <this type of IETF specifications> need revision. Making those actual revisions should be done in separate documents.

WEG] Jari, effects and implications probably wouldn't add much. However, I'm wondering about the value of maintaining two separate drafts (-weil and bdgks) if weil is now being asked to include these things that are mostly already covered in bdgks.
Regarding "<this type of IETF specifications> need revision" - would you be ok with something like, "any existing standard that prescribes different behavior in the presence of RFC1918 (or non-unique) addresses will need to be evaluated." ?
If you're wanting something more in-depth than that, I think you're underestimating the work involved. That in and of itself could be a whole draft. If we're going to undertake it, I don't want to do it half-assed, and I would rather not see it be gating to these drafts.

> But if we are unsure and somehow asked ARIN to make the reservation anyway, the address space would already be nailed down, the knowledge of the actual usable space would leak and everyone would be…
WEG] I think that this is a minor concern at best. ARIN can be explicitly instructed not to divulge the reservation. This is something that could be reserved internally by ARIN staff without publishing it publicly.

Wes George

---

From: "George, Wes" <[email-masked]>
Date: Fri, 23 Sep 2011 10:06:06 -0400

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]]
Sent: Thursday, September 22, 2011 6:32 PM
To: George, Wes
Cc: Jari Arkko; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

> 2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as additional private-scope use cases?
I don't believe so. I believe that conflating these drafts with RFC-1918 would only serve to further increase the
probability that someone would consider this additional space for the same purpose. I would not oppose
adding a reference to RFC-1918 that links to these documents as additional related considerations.

WEG] "adding a reference to RFC1918 that links to..." means updating RFC1918, which is why I suggested it. It is not necessary to rewrite/replace/obsolete 1918, and I believe that some of the language that you added to bdgks after our discussion about how these cases are different from 1918 would be fine to help prevent conflation between the two. It's incumbent upon us to ensure that the draft is very crisp in defining acceptable and unacceptable uses of the space and its relationship to existing RFC1918 uses, and I believe that this is quite doable. Regarding increased risk of off-label use, all we can say is "don't do this" and "only do this" using the strongest language we feel appropriate. What implementers ultimately decide to do will be driven by their individual business and technical needs more than whether or not we choose to update 1918 formally.

There is urgency to make the space available for use, so, the split you describe does not actually help. The urgency
is to make this space available before providers start having to deploy NAT444 without it, or, at this point, more
accurately, to limit the amount of NAT444 deployed using GUA, Squat Space, or any of the other alternatives
that these drafts show are a significantly worse alternative vs. this /10 shared transition space.
Pushing draft weil back as you describe would be extremely harmful IMHO.

WEG] this is exactly the type of hand-waving I'm trying to avoid when discussing whether there's actually this much urgency and what is driving it. While I've heard good support for this reservation of shared transition space, and the concern that if we screw around for too long the address space will be gone, I have not heard anyone saying "I need this within the next few weeks (or even months) or I'm going to have to do something else." It's been over a year since this round of discussion started (with draft-weil-opsawg-provider-address-space-00), and yet no one has unequivocally said "I'm being materially impacted by your failure to get this done *right now*." As may be obvious, I work for a broadband residential ISP. This idea of when/if we have to do CGN is pretty important to us and to my colleagues in the industry right now, and I'm not hearing event horizons earlier than 12-18 months. If anything, people are starting to look at this and say, "wow, this is going to suck, I wonder how long I can hold it off?" So I simply don't see the necessity for short-circuiting the process. Even if the timeframe is more like 6 months, we still have time to do this correctly.
I speak for no one but myself, but if you fall into the category of needing this address space ASAP, you'd be wise to speak up to lend credence to the perceived sense of urgency.

Wes George

---

From: "George, Wes" <[email-masked]>
Date: Fri, 23 Sep 2011 10:10:25 -0400

-----Original Message-----
From: Benson Schliesser [mailto:[email-masked]]
Sent: Friday, September 23, 2011 1:21 AM
To: Jari Arkko
Cc: [email-masked]; [email-masked]; [email-masked]; George, Wes
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

Given constraints on existing IPv4 inventory (i.e. we're running out of the
stuff), our desire has been to have draft-weil proceed without delay.  <snip>  However, I would like to make sure we don't lose sight of the need for some urgency with draft-weil.

WEG] I won't repeat my comments to Owen here, but I will note that if the concern is about the availability of the address space, my suggestion would allow us to ensure it's available without any artificial (?) sense of urgency over getting the documents to a form that we're happy with.

WEG] my thought is that it's useful to say exactly that - this exists, so if you're going to do it to avoid breakage, know that there's now additional space to be aware of, especially if we go the route of updating RFC1918. I do appreciate the clarification of the difference between deriving address scope based on bit value for defined-scope values vs. assuming that everything not included in that defined-scope of private space could be unique and global, but I'm not sure that particular distinction is important in the context of these drafts. Similarly, the idea that squatting on other GUA space has a similar problem is mostly interesting as a justification for doing STS instead of squatting, and so that idea is probably minimally important in the grand scheme of things.

WEG] Agree, the wording and the distinction between the use cases are important, but I believe it is possible to articulate it properly. I think that crispness and clarity is required anyway, in order to clearly explain why these use cases are not simply solved by use of existing RFC1918 space. BDGKS is getting there, so let's refine that to address both your concern and mine.

Wes George

---

From: Owen DeLong <[email-masked]>
Date: Thu, 22 Sep 2011 15:31:57 -0700

> 1) Does IETF recommend the practice of inferring address scope in IPv4 based on address/bit value (the actual numbers), and then using this to trigger different behavior based on that inferred scop…

Whether IETF recommends it or not, it is common practice in CPE today. As such, I think we should recognize
and address the reality rather than ignore it in the name of architectural purity. However, I am not convinced
that these drafts are the place to address it.

I don't believe the draft says that there is no link so much as we say that hard-coding such assumptions and
making the assumption that all other addresses are globally reachable or have global reachability is a poor
assumption. This draft doesn't change that fact and no clarification of scope linkage would change the fact
that assuming your GUA (or presumed GUA) is globally unique or has global reachability is a bad assumption
which is, nonetheless, an assumption built into many residential CPE devices today.

> 3) Independent of consensus on the state of the *draft* directing it to happen, is there consensus on the *idea* that the /10 of IPv4 space should be reserved as shared transition space?

I believe there is. Further comment below...

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 23 Sep 2011 07:32:18 -0700

> WEG] "adding a reference to RFC1918 that links to..." means updating RFC1918, which is why I suggested it. It is not necessary to rewrite/replace/obsolete 1918, and I believe that some of the langu…

If the scope of "updating RFC-1918" you intended was a simple reference, then, yes, I can support that idea.

I took "updating RFC-1918" to mean something more along the lines of incorporating these drafts into 1918
instead of giving them their own RFC numbers which I think would be counterproductive.

> I speak for no one but myself, but if you fall into the category of needing this address space ASAP, you'd be wise to speak up to lend credence to the perceived sense of urgency.

I suspect that the operators most likely to choose alternative solutions immediately in the absence of moving this forward are also the ones least likely to be reading this list, unfortunately.

We already have assurance from ARIN that the space will not go away. Mr. Curran has assured us that the space will be set aside if we get to the point where that must be done to prevent it from getting otherwise allocated.

I'm really not trying to hand-wave, but, while I don't work for a residential ISP, I do talk to people from a lot of them in my travels, both large and small. I know that there are providers already starting to deploy LSN for some of their customers. (To a certain extent, much of the residential broadband in India is already behind one or more layers of LSN, but I wouldn't consider that situation particularly representative of the problem.)

I wish I could give you a list of the providers I've talked to, but, frankly, I don't remember which ones they were, these are Q&A and other hallway discussions from various conferences. However, some excerpts go like this:

	"We either need the /10 to move forward soon, or, we'll be forced to use squat space."

	"I'll probably have to start deploying LSN one way or another in the next 60 days."

	"I'm dreading LSN. Especially if I end up having to hack it without reserved space."

Admittedly, I hear these things more often when I am in Asia than when I am in the ARIN region. However, I believe this is intended to apply equally well to all regions and that ARIN is providing the space primarily because they have the largest pool of remaining available addresses.

I do hope that there are at least some such providers on here that will confirm what I have said, but, I don't know. The majority of operational residential ISPs don't actually have much presence in the IETF, if any.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Sep 2011 08:40:25 +1200

On 2011-09-23 17:21, Benson Schliesser wrote:

> However, I would like to make sure we don't lose sight of the need

I'm a little puzzled by the claim of urgency; I remember hearing in
July 2008 that doom was imminent if this was not done immediately.

I thought that the urgent issue was deploying IPv6.

On 2011-09-23 20:38, SM wrote:
...
> I suggest that ARIN publishes its policy through the Independent Stream
> and documents the IPv4 addresses that will be used for so-called shared
> transition space.

What makes you think that the Independent stream would publish such an
RFC, which on the face of it would be a complete end-run around the
IETF process, and fly in the face of the IAB position?

    Brian

---

From: Benson Schliesser <[email-masked]>
Date: Fri, 23 Sep 2011 16:41:09 -0500

Hi, Brian.

> I thought that the urgent issue was deploying IPv6.

I agree; no doubt, deploying IPv6 is urgent. But, unfortunately, operators
often face multiple urgent issues at the same time.

In any case, the urgency that I referred to is a reflection of advice from
various ARIN leaders. Obviously, there is a future date at which ARIN will
be unable to donate the /10 prefix because of IPv4 inventory exhaustion.
More near-term is the prospect that operators will deploy CGN using global
unicast addresses. This might have negative repercussions for the operator
and/or their users, along the lines of scope detection etc. It definitely
has negative repercussions for the rate at which RIR inventories are
exhausted.

In other words, the sooner we act, the more benefit this reservation will
have. That doesn't imply that we have so little time we are unable to
address the issues raised by the IESG. But we certainly don't have the sort
of time that many drafts commonly require, per the stats at
http://www.arkko.com/tools/lifecyclestats.html for example.

Cheers,
-Benson

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 23 Sep 2011 14:43:24 -0700

> IETF process, and fly in the face of the IAB position?

+1

Additionally, this network operator and ARIN member is fully opposed to any
shared address draft. Real routable addresses are need for real routable
systems.

There is no free lunch, these efforts should be focused on making 240/4 work
or doing ipv6, not ripping of really working ipv4 space.

Both of the above are hard ... sorry.

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

---

From: SM <[email-masked]>
Date: Fri, 23 Sep 2011 17:54:17 -0700

>IETF process, and fly in the face of the IAB position?

There is an Editorial Board which can decide whether the draft is 
acceptable in that stream.  In my opinion there will be more end-runs 
until ARIN gets what it wants.

Regards,
-sm

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 23 Sep 2011 23:24:22 -0400

Folks,

This allocation cannot be made without IETF consensus. Publication on the Independent Stream does not reflect IETF consensus. Therefore, publication on the Independent Stream wouldn't enable the allocation.

                                                        Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> SM
> Sent: Friday, September 23, 2011 8:54 PM
> To: [email-masked]
> Subject: Re: Last Call: <draft-weil-shared-transition-space-request-
> 03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to
> Informational RFC
>

---

From: Doug Barton <[email-masked]>
Date: Fri, 23 Sep 2011 20:48:35 -0700

On 09/22/2011 11:35, Jari Arkko wrote:
> It would have been even better if we had access to research that has
> looked at the various impacts in a rigorous manner. E.g., what's the
> likelihood of ISP - subscriber address collision in the different parts
> of the current RFC 1918 space vs. what is the likelihood of application
> failures with the new space. Not sure if we have time for that research
> now unless it already exists.

I agree with Jari that this would be a better alternative (in addition
to Jari's other point that software which relies on being able to detect
non-RFC-1918 space having problems with this new range). I have a very
difficult time being sympathetic to the people that created the problem
by sticking their fingers in their ears and singing "la la la la la la
la" while the v4 address space went away. I would much rather see them
take responsibility for fixing the problem they helped create by finding
a way to deal with it using existing resources.

This document, and
https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03
talk about the potential pitfalls of not allocating the space, but my
reading of them didn't reveal an adequate examination of the opportunity
cost of taking 4,096 /22s out of the free pool.

Finally, I have absolutely zero sympathy for any argument that
performing such an allocation is "urgent." The coming IPv4 exhaustion
problem has been a known issue for over 15 years. Section 5.1 of bdgks
talks about the history of similar requests going back to 2004. In an
ideal world the message that "IPv6 is the solution to this problem"
would have been received at some point in the process.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

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

---

From: SM <[email-masked]>
Date: Sat, 24 Sep 2011 03:24:41 -0700

>cost of taking 4,096 /22s out of the free pool.

There are three ways to get an allocation from the IANA free pool:

  1. RIR allocation (that's no longer possible)

  2. A global policy

  3. A protocol assignment

A global policy proposal would take some time and it would not fare 
well as the ARIN region has ticked off the APNIC region due to its 
unilateral stance about how IPv4 addresses should be managed.  The 
third option offers a path to work around that.

Section 2.2.2 of draft-bdgks-arin-shared-transition-space-03 is 
another option.  I would not be surprised if ARIN blessed that option.

Section 4.1.2.1 of the draft mentions that:

   "Since the volume of impacted endpoints will be low, operators can
    likely manage the disabling of 6to4 when needed."

I smiled when I saw that as it is contrary to some positions taken 
during the previous 6to4 controversy. :-)

draft-bdqks-arin-shared-transition-space went through a WGLC and it 
has been determined that there is rough consensus in OPSAWG to 
request publication.  In my opinion it is inappropriate use of the 
IETF Stream as it is not the right venue for RIR politics.  I don't 
believe that it is the intent of the authors to do that but that's 
what it is going to be translated into.

Regards,
-sm

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 24 Sep 2011 08:45:00 -0700

On 9/24/11 03:24 , SM wrote:
> A global policy proposal would take some time and it would not fare well
> as the ARIN region has ticked off the APNIC region due to its unilateral
> stance about how IPv4 addresses should be managed.  The third option
> offers a path to work around that.
> 
> Section 2.2.2 of draft-bdgks-arin-shared-transition-space-03 is another
> option.  I would not be surprised if ARIN blessed that option.
> 

I don't really believe the scale of the problem is fairly characterized
by the text. manually disabling (where possible) or physcially replacing
existing cpe are no more scalable than any other form of intervention.
it is worth noting that in general this problem can be address by
putting an rfc 1918 address on the outside.

the proponents of the demise of 6to4 are precisely the folks who really
would prefer not to break 6to4 in this fashion. less-than-functional
auto-tunneling does enough damage already without our help.

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 24 Sep 2011 09:24:34 -0700

> be unable to donate the /10 prefix because of IPv4 inventory exhaustion.

A prefix is not donated because they are not property of arin.

Directing the allocation of a prefix through a standards action is what
is in the table.

> and/or their users, along the lines of scope detection etc.

All CGN deployments have negative repurcussions for the users, it's the
job of the operators to decide how to minimize those based on their
specific circumstances. any newly assigned prefix will be treated as
global unicast space by existing cpe (and hosts) so in the near term
that doesn't sound like a substative distinction. the question of where
it's RFC1918 (as it for the verizon 4G modem I'm sending this over) or a
global unicastish prefix seems germain.

> It definitely

---

From: John C Klensin <[email-masked]>
Date: Sun, 25 Sep 2011 09:26:43 -0400

--On Friday, September 23, 2011 17:54 -0700 SM <[email-masked]>
wrote:

>> What makes you think that the Independent stream would
>> publish such an RFC, which on the face of it would be a
>> complete end-run around the IETF process, and fly in the face
>> of the IAB position?
> 
> There is an Editorial Board which can decide whether the draft
> is acceptable in that stream.  In my opinion there will be
> more end-runs until ARIN gets what it wants.

Well, yes, but...

(1) The IESG gets to review all documents that the Independent
Stream intends to publish to verify that the document doesn't
interfere with IETF work.  The Independent Stream can, in
principle, publish over IESG objections (perhaps with some notes
about that) but, like Brian, I'd be at least mildly astonished
to see that done in a case like this.

(2) Independent Stream publication wouldn't accomplish the
presumed purpose of creating this draft because, while such
publication might be good for starting a discussion or providing
information to the community, it doesn't get allocations made--
the intent here is pretty clearly to get an allocation.

    john

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 25 Sep 2011 21:09:40 +0200

> This allocation cannot be made without IETF consensus. Publication on the Independent Stream does not reflect IETF consensus. Therefore, publication on the Independent Stream wouldn't enable the al…

Sorry, or maybe I'm not really sorry, but I can not see it as a good
thing for the internet at whole to allocate the prefix right now.
Notice that right now part.

Let people try out all of the scenario we have available, we don't
need to add yet another part into the huge mess we've already got us
into. Are already too many ways to get from v4 to v6 as it is....

In a few years _when_ we've got IPv6 more into mainstream, I'm quite
sure we will see a technical (and only technical) reason for
allocating that last remaining piece of IPv4 netblock we've got left.

There is already too many burning fire out there right now, we don't
need to add more wood (ipv4 addresses or special case usage etc) to
it.

-- 

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Sep 2011 16:55:41 +0200

On 23 Sep 2011, at 7:21 , Benson Schliesser wrote:

> The STS may have similar
> But it is not meant to be used in the same scope. 

The draft isn't sufficiently clear on this to my liking.

I think it should be explicitly stated that no services are to be hosted on addresses in this prefix.

There is no support for the choice for a /10. Why not a /11 or a /9?

There is no discussion on the consequences of filtering packets to/from these addresses, such as PMTUD black holes.

Hosting the reverse DNS for these addresses within the prefix may or may not be useful.

Did anyone try to talk to holders of legacy space that is not present in the global routing table, such as the US government, to see if their addresses can be reused for this purpose?

---

From: "Azinger, Marla" <[email-masked]>
Date: Mon, 26 Sep 2011 14:16:15 -0400

Iljisch

Regarding /10 and not another size:
Originally it was a /8 and then the authors and networks dug in a bit more investigated what was to much and what was to little and decided a /10 would be sufficient.

Regarding IP resources for this use:

I spoke with DoD offline.  The answer is "approval would never be given for that". I had also sent an official request up one of the DoD chains and it never got a response. So, I'm going with the answer of no.

Regarding Legacy.  From what I have witnessed in the last 6 months, if Legacy holders have space that's not globally routing, they are busy assessing their networks and making "business" decisions.  Any space that they are bound to maintain and also not globally route that outsiders would request they possibly "share" for essentially private use, is not a likely outcome.  I've not received any positive responses for an outcome like that.

Additionally, correcti me if Im wrong here someone, but I believe ARIN has said they have a /10 they can put forward for this use if the policy and requirement is put in place for it.

Hope this answers your questions

Cheers
Marla

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Monday, September 26, 2011 7:56 AM
To: Benson Schliesser
Cc: Jari Arkko; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

This communication is confidential.  Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 30 Sep 2011 19:14:37 -0400

I read the document again today for the first time in a while and went
through the more recent threads on the ietf list.

I have 2 main comments.

First, where did the /10 figure come from? Why not a /16? Some
justification is needed for a particular figure.

Second, this will break stuff, and even though the document talks
about it some, we are dreaming IMO if we think talking about the
problems (and encouraging implementations to fix things) will have any
impact. At least not in the next few years. The problem will happen
with stuff deployed today, or already in the pipeline for
deployment. So, this will cause things to break. I don't feel good
about that, even if one accepts the argument that neither approach is
painless and we're gonna have breakage anyway. E.g., breaking 6to4
seems like a bad thing to do for IPv6.

E.g.,:

   ingress links.  DNS queries for Shared CGN Space addresses MUST NOT
   be forwarded to the global DNS infrastructure.  This is done to avoid
   having to set up something similar to AS112.net for RFC 1918 private
   address space that a host has incorrectly sent for a DNS reverse-
   mapping queries on the public Internet [RFC6304].

This is totally unenforceable. We will be forced to deal with
this. Existing software that is massively deployed will do
this. Saying MUST NOT here is kind of like some IETF document saying
you MUST NOT use NAT.

   When configured with a Shared CGN Space address (or other address
   range not described in [RFC5735]), such devices may attempt to
   initiate 6to4.  Since 6to4 includes the WAN IPv4 address embedded in
   its IPv6 address, should 6to4 traffic traverse a CGN, return traffic
   could be misdirected and not reach the originating router.  Service
   Providers can mitigate this issue using a technology such as 6to4-PMT
   [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel].  When the address
   range is well-defined, as with Shared CGN Space, home router vendors
   can include Shared CGN Space in their list of special-use addresses
   (e.g., [RFC5735]) and treat Shared CGN Space similarly to private
   [RFC1918] space.  When the WAN address is not well-defined, as in the
   case of Globally Unique space, it will be more difficult for home
   router vendors to mitigate against this issue.

This won't happen for a long time (if ever). so counting on this seems
like a dream.

Finally, what this document/reservation does is shift pain
around. I.e., moving pain felt by one party (if nothing is done) to
another party (if this is done). Are we unfairly pushing the pain to
people (e.g., CPE routers) to help the ISPs? How do we decide or
justify who deserves the pain?

I'm pretty ambivalent about recommending this document. I don't like
it and I don't like the precedent it sets, particularly in pushing
pain from one party to another. I do understand what the document is
trying to do. I think it will result in some small amount of sharing
of space (thus slightly reducing demand for IPv4 addresses), which is
arguably a good thing. But the amount of address space we are talking
about here is negligible in the overall scheme of things....

Thomas