Subject: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space

From: [email-masked] (Scott O. Bradner)
Date: Thu, 1 Sep 2011 11:43:35 -0400 (EDT)

this is the start of a WGLC for draft-bdqks-arin-shared-transition-space
to be published as an informational RFC (with a reference from
draft-weil-shared-transition-space-request)

please comment to the list before Sep 14 

thanks

Scott

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Sat, 3 Sep 2011 00:32:19 -0700

<hat off>
+1
<hat on>

	Chris

On 01Sep2011, at 08.43, Scott O. Bradner wrote:

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

--  
李柯睿
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf

---

From: "Stan Barber" <[email-masked]>
Date: Sat, 03 Sep 2011 11:17:39 -0500

Me too. +1, thumbs up, etc.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 4 Sep 2011 01:50:01 -0700

I fully support the draft. (Would be silly to be a co-author if I did not).

Owen

---

From: Chris Donley <[email-masked]>
Date: Tue, 6 Sep 2011 08:37:16 -0600

I support this draft.

Chris

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 6 Sep 2011 14:03:15 -0400

I don't believe that this document is ready to move forward. I provided a significant amount of comments privately to the authors on version 1, and many of them are not addressed in this revision.
For context - this document is supposed to be the justification for draft-weil. My understanding was that they were split so that much more work could be done to refine and achieve consensus on the justification without delaying the allocation of the actual space. There really has not been much on-list discussion of the draft so far, but there was a significant amount of discussion during the WG session in Quebec City.

My biggest issue with this draft is that there are multiple sections within it that discuss other use cases for this shared transition space. In almost every case, these are in conflict with the language in section 4 of draft-weil-shared-transition-space-request, and even with other sections within draft-bdgks that assert that this shared transition space is not to be used as additional RFC1918 space. From draft-weil:
   "Shared Transition Space is IPv4 address
   space reserved for Service Provider or large enterprise use with the
   purpose of facilitating IPv6 transition and IPv4 coexistence
   deployment.  This space SHOULD only be used for the purpose of
   providing NAT'ed IPv4 access to subscriber networks or IPv6-in-IPv4
   tunnels during the transition to full IPv6 deployment."
I'll note specifically sections 2.1.2, 2.1.3, 3.3, 4.1.3, 4.2.2 as areas where this is unclear or conflicting.
I'm not sure whether the language needs to be refined in draft-weil to clarify acceptable vs unacceptable uses and permit additional cases, or whether this draft purports to make a recommendation of alternate use cases that move beyond draft-weil, but somehow the conflict needs to be resolved. If the intent is to add more use cases, this document could say:
  In addition to the uses documented in [draft-weil], a provider
  could delay their need for NAT by using the space in the following ways:
  .... (moving into existing section 2.1.2, 2.1.3, etc)
But if it does that, it would also have to discuss in each case, "RFC1918 is problematic for this use because..."
My personal opinion is that the more alternate use cases we document, the more slippery the slope becomes towards this becoming a second, but not properly documented (eg a formal RFC1918-bis) set of RFC1918 space, rather than limited to a fairly narrowly stated purpose that is easily distinguishable from RFC1918. I would encourage the draft authors to re-read RFC1918 section 2 with a mind to identifying use cases that are unique to this application.

Some additional comments beyond that issue:

2.1.3-  There have been objections that doing this will just bail out ISPs who haven't deployed IPv6, so we need to respond to that.  In this section, you can clarify why the ISP can't just push IPv6 faster, e.g.:

  Where these services are accessed by customers who have their own IPv4-only
  equipment, use of this space will reduce or eliminate the need for NAT.
  Similarly, those infrastructure elements which touch IPv4-only customer-
  managed equipment could also be numbered from this space.  In cases where
  the provider manages both endpoints, IPv6 should be used.

2.1.4 - I agree with the concern about routing ambiguity, but the reference to allowing ICMP messages is confusing (at least to me) as to how it relates to the previous statements. There are multiple documents covering proper filtering of ICMP both for NATs and otherwise, such as RFC5508. At the least, you should provide a reference to 5508. If the authors do not believe that 5508 covers all of the considerations something more specific than "...requires further investigation..." needs to be here.

2.2.2-
"...our testing...did not filter correctly..." - Please provide a citation to the testing results and replace "our" with something more descriptive.

2.2.6 - A consortium would also have difficulty demonstrating enough need to get the an allocation for the address space necessary given the limitations present in the RIRs due to "last /8 policies" (/22 in APNIC, 3 month justification in ARIN, etc).

3.3.2 - I think that this conflicts with section 4.1.1, where the authors are saying that they basically agree that NAT is Evil, but that it is also a Necessary Evil. If using shared transition space + NAT results in the return of IPs, rather than simply serving as a bridge to cover net new customers that need IPv4 connectivity post-exhaustion, it means that NAT is being deployed much more widely than is strictly necessary. Following that logic, the hypothetical SP is creating an inherently worse experience for a much larger subset (or all) of their customers, possibly to profit by selling address space on the transfer market. That seems like a bad position for the IETF to be taking - don't just do NAT, do enough of it so that you can give (sell) space back...

3.5 - you need to coordinate with draft-vegoda-no-more-unallocated-slash8s section 4 since it's basically recommending that you stop filtering everything but reserved space, and this would be a change to the reserved spaces being covered. I'm not sure where it makes sense to update this, either in that draft, this draft, or draft-weil, but it definitely needs to be covered in one or more of them.

3.6 - segmenting networks is a foregone conclusion unless the provider is small enough that a single instance of shared space (/10) network-wide is enough. I think that you can make the point that this frees cycles for IPv6 without mentioning segmentation.

4.1.2 - I disagree with the assertion of "Bad Host Assumption" as justification here. I haven't been able to find anything within the IETF that explicitly says "assuming address scope based on IPv4 address block considered harmful" or similar. In fact, there are multiple places where IETF discusses problems inherent with non-unique addresses and behavior/implementation changes to compensate (such as 3056 section 5.8 and 5.9, quoted below) in such a way that it conflates the two and perpetuates that assumption.
   "The V4ADDR MUST be
   a duly allocated global IPv4 address, which MUST be unique within the
   private network.  The Intranet thereby obtains globally unique IPv6
   addresses even if it is internally using private IPv4 addresses [RFC
   1918]."
I don't think that "not globally-unique" is crisply distinguished from "RFC1918 addresses" in all existing IETF work on the matter. Further, this has become a de facto assumption in many implementations because prior to IPv4 address exhaustion, it was largely accurate.
In addition, RFC6250 (which covers and debunks a number of bad assumptions about IP) section 3.2.4 says "...scoped addresses as defined for both IPv4 [RFC1918][RFC3927]..." illustrating the link between the two. It also does not discuss this concept of assuming scope via address block as a bad assumption, despite just being published this year.
If it's a bad host assumption, there probably needs to be a separate document updating this guidance.

And a nit - The heading should probably be something more descriptive like "breaks assumptions about address scope", and then leave whether it's a bad assumption to the body text of that section, since it is the only host assumption discussed.

4.1.2.1 - Include an informative reference to draft-kuarsingh-PMT? Happy Eyeballs?

4.1.3 - Between the inconsistencies that I have pointed out within this draft, and the fact that draft-weil says "should not" and not "must not," I'm not sure that this section really responds to the noted concern in its current form. At a minimum, it would be appropriate to cite/quote specific normative language from draft-weil to underscore that this would actually be a misuse and not simply a grey area. Personally, I would be much more comfortable with a "must not" in draft-weil, but perhaps that ship has sailed.

4.2.1 - This section needs referential support in order to not be debating an opinion. Perhaps you could provide pointers to places where ISPs have said that they would use it. If those are unavailable, it may make sense to call explicit attention to the fact that two of the authors on this draft are operators of broadband residential networks, draft-weil is also written by several operators, and explain that Cablelabs represents many cable operators. If not actually coming out and saying that the operators represented have plans to use this, it would be strongly implied simply by making the affiliations more obvious.

4.2.2 - you should cite some publicly available statistics about ISP growth rate in order to show that the net new (new customers less lost customers for some period of time) growth rate is non-trivial. Asserting it without supporting facts is debating opinion.
Also, "...do not work with NAT..."  is confusing in a doc that is justifying addresses explicitly expected to be used with a NAT. Which devices don't work with NAT?  How would Shared Transition Space used for the inside of a NAT help them?

4.2.3 - also mention ARIN 3 months policy, add references to Tony Hain's work on address exhaustion (in addition to Geoff Huston's) http://www.tndh.net/~tony/ietf/ipv4-pool.htm

4.3.1 - I recommend removing the second paragraph altogether. Either this alleviates demand or it doesn't. The first paragraph stands well on its own as a response to this concern, and the second simply waffles.

4.3.3 doesn't say anything new. Combine with 4.3.1.

4.4 - cite draft-ietf-ipv6-required as evidence that this is being worked aggressively?

4.4.2 - why is it that "The whole Internet needs to get to IPv6 more or less at the same time"? There are plenty of communities of interest where IPv6 capability can reach critical mass and see immediate benefit independent of what "the Internet" does. For instance, any dual-stack customer on an ISP network can bypass an IPv4 CGN if the content they wish to hit (like any of the participants of world IPv6 day, for example) is IPv6-capable.

7 - Don't these IANA considerations belong in draft-weil since that is the draft that is actually requesting the IANA reservation/documentation?

8- I'm bothered by the "weasel words" in this section. If this is documenting new use cases for this shared space not covered in draft-weil, it should provide detailed security considerations for each, or references to existing documents where they are discussed. If the authors believe that there are no security considerations, then just say so, rather than "... the reader is advised to investigate these independently."

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott O. Bradner
Sent: Thursday, September 01, 2011 11:44 AM
To: [email-masked]
Subject: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space

thanks

Scott

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: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Sep 2011 09:31:09 +1200

+1. The draft should be very crisp and restrictive about the use of this
space, assuming it is to be allocated. People may forget that RFC 1918
was a replacement for RFC 1597, and even so failed to prevent sloppy
use of that form of ambiguous address space. We need to do a better
job this time around. Weasel words and wiggle room are inappropriate.

I think Wes has picked up a lot of important points.

Regards
   Brian Carpenter

---

From: Owen DeLong <[email-masked]>
Date: Tue, 6 Sep 2011 15:44:07 -0700

> For context - this document is supposed to be the justification for draft-weil. My understanding was that they were split so that much more work could be done to refine and achieve consensus on the…
This document is not the justification for draft-weil, it is a description of a set of recommended use cases for the space set aside in draft-weil.

Further, we've since basically been told that draft-weil is not going to move forward until this draft does, so, that purpose for the spilt has been eliminated and this has become a blocking item for getting the space actually allocated.

> I'll note specifically sections 2.1.2, 2.1.3, 3.3, 4.1.3, 4.2.2 as areas where this is unclear or conflicting.

I don't see those areas as necessarily conflicting though I do think they make somewhat substantial use of should whereas you seem to feel that should in draft-weil ought to be treated as must. Since the very service provider making the decision to use any of those mechanisms described in the sections you refer to as conflicting would also be the one suffering from any conflict, I believe leaving it up to said service provider to resolve such conflicts is in keeping with the intents of both drafts.

> But if it does that, it would also have to discuss in each case, "RFC1918 is problematic for this use because..."

It really doesn't. RFC-1918 is problematic in each of the use cases for the exact same reason as is described in draft-weil.

> My personal opinion is that the more alternate use cases we document, the more slippery the slope becomes towards this becoming a second, but not properly documented (eg a formal RFC1918-bis) set o…

My personal opinion is that all of the use cases documented are not a slippery slope at all and each involves a decision by the very provider who would be affected by that decision. This is radically different from the problem caused by RFC-1918 conflicts with customers.

I have re-read RFC1918 section 2 and I believe that the use cases documented in this draft are all unique to this situation in that they all involve a service provider needing IPv4 space that does not have to be globally unique, but, does have to avoid any overlap with space in use on said ISPs customer's networks.

>  the provider manages both endpoints, IPv6 should be used.

We could, and that would have been great feedback earlier in the process. I have trouble seeing this as a show-stopper for moving the draft forward, but, if it does not impede forward progress, I would support adding the language even at this late stage.

> 2.1.4 - I agree with the concern about routing ambiguity, but the reference to allowing ICMP messages is confusing (at least to me) as to how it relates to the previous statements. There are multip…

I can't speak for all of the authors, but, I believe that 5508 does not cover all of the possible considerations in the various scenarios that could be encountered in this brave new world of multi-layer NAT and/or NAT being inflicted on customers at the carrier level. I also do not believe that such consideration is possible until a certain amount of operational observation has occurred. Therefore, since each provider using this space is headed off to chart new territory, the best that can be said at this time is "requires further investigation" so as to alert providers using said space that they may enter uncharted territory and may face considerations beyond the clairvoyance of the authors.

> "...our testing...did not filter correctly..." - Please provide a citation to the testing results and replace "our" with something more descriptive.

Fair comment. One has to wonder, however, why you did not make this comment prior to last call.

> 2.2.6 - A consortium would also have difficulty demonstrating enough need to get the an allocation for the address space necessary given the limitations present in the RIRs due to "last /8 policies…

I believe given recent allocation history, a combination of signatories to the consortium sufficient to justify a 3 month need for a /10 would be possible, but, yes, it would be difficult at best. I'm not sure what you are trying to achieve with this comment.

> 3.3.2 - I think that this conflicts with section 4.1.1, where the authors are saying that they basically agree that NAT is Evil, but that it is also a Necessary Evil. If using shared transition spa…

I don't disagree with you here, but, the reality is that whether or not to do so is a business decision that will be made by each ISP regardless of what is said in any RFC and we felt it was better to address this directly than to ignore it.

> 3.5 - you need to coordinate with draft-vegoda-no-more-unallocated-slash8s section 4 since it's basically recommending that you stop filtering everything but reserved space, and this would be a cha…

I would say once this moves forward, draft-vegoda would need the update. I don't see the update to draft-vegoda as a gating item for this draft, but, rather that if this draft moves forward, that update would become a gating item for draft-vegoda. To the best of my knowledge, draft-vegoda has not moved to WGLC as yet.

> 3.6 - segmenting networks is a foregone conclusion unless the provider is small enough that a single instance of shared space (/10) network-wide is enough. I think that you can make the point that…

Perhaps, but, is there some reason you wish to avoid mentioning segmentation?

> If it's a bad host assumption, there probably needs to be a separate document updating this guidance.

Whether you want to call it a bad assumption or not, it's a problematic assumption at this point. The point is that while that assumption will be problematic here, it is even more problematic for each of the possible alternatives to this shared space. With a defined block at least mitigation is possible. In the case of squatting or blocks chosen individually by each provider, no such host-level mitigation could be achieved.

> And a nit - The heading should probably be something more descriptive like "breaks assumptions about address scope", and then leave whether it's a bad assumption to the body text of that section, s…
meh... as you said a nit. I wouldn't mind having addressed this earlier in the process, but, I don't see holding up advancing the draft over it.

> 4.1.2.1 - Include an informative reference to draft-kuarsingh-PMT? Happy Eyeballs?

I don't oppose this, but, I don't see holding up the draft for it.

> 4.1.3 - Between the inconsistencies that I have pointed out within this draft, and the fact that draft-weil says "should not" and not "must not," I'm not sure that this section really responds to t…

The inconsistencies you have pointed out would be inconsistent if draft-weil said "must not", but, in a "should not" case aren't all that inconsistent IMHO.

I believe that this paragraph meets the author's intent and that there are situations where said use cases while not ideal may be entirely pragmatic. Since the scope of the problems which may be created by said alternate uses is entirely within the affected ISPs domain of control, I think this is the best approach at this time -- explain, discourage, but leave the options open.

> 4.2.1 - This section needs referential support in order to not be debating an opinion. Perhaps you could provide pointers to places where ISPs have said that they would use it. If those are unavail…

Multiple ISPs have said they would use it during the development of this draft on this very list. While I wouldn't oppose such additional text, I really don't see it as necessary to move forward.  Had you chosen not to wait until WGLC to bring this up, I think the authors would have easily addressed it. Making it a gating item to exit last call is simply obstructionist.

> Also, "...do not work with NAT..."  is confusing in a doc that is justifying addresses explicitly expected to be used with a NAT. Which devices don't work with NAT?  How would Shared Transition Spa…

While I agree this could be improved, I think it is a nit which should not prevent a successful last call.

> 4.2.3 - also mention ARIN 3 months policy, add references to Tony Hain's work on address exhaustion (in addition to Geoff Huston's) http://www.tndh.net/~tony/ietf/ipv4-pool.htm

Another nit which you could have easily raised prior to WGLC and which I do not feel should delay the draft at this time.

> 4.3.3 doesn't say anything new. Combine with 4.3.1.

Now we're really getting down to the tiniest of nits.

> 4.4 - cite draft-ietf-ipv6-required as evidence that this is being worked aggressively?

Microscopic nit. I agree said reference is desirable, but, I don't think it is important enough to block on.

> 4.4.2 - why is it that "The whole Internet needs to get to IPv6 more or less at the same time"? There are plenty of communities of interest where IPv6 capability can reach critical mass and see imm…

Many of the participants of world IPv6 day are no longer reachable via IPv6. I agree that "whole internet" may not be slightly hyperbolous, but, the point is that no matter how many access providers fully dual-stack their customers, IPv4 support will be required until there is a sufficient critical mass of content providers.

> 7 - Don't these IANA considerations belong in draft-weil since that is the draft that is actually requesting the IANA reservation/documentation?

Since the IETF has insisted on joining the drafts at the hip with a shared fate, I'm not sure it matters.

> 8- I'm bothered by the "weasel words" in this section. If this is documenting new use cases for this shared space not covered in draft-weil, it should provide detailed security considerations for e…

Absent operational experience with these mechanisms, it really isn't possible to identify all of the security concerns, especially given the variety of operational environments in which they are likely to be deployed. As such, I think the appropriate course is to advise the reader that they must consider this form themselves as it applies to their unique environment.

Owen

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 7 Sep 2011 17:26:02 -0400

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]]
Sent: Tuesday, September 06, 2011 6:44 PM
Subject: Re: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space

This document is not the justification for draft-weil, it is a description of a set of recommended use cases for the space set aside in draft-weil.
__________
WEG] Draft-weil has been stripped of nearly all of its justification with the expectation that it would exist in another draft, and its language disagrees with you:
  "The applicability of and justification for Shared Transition Space is
   described in [I-D.bdgks-arin-shared-transition-space]."

Further, we've since basically been told that draft-weil is not going to move forward until this draft does, so, that purpose for the spilt has been eliminated and this has become a blocking item for getting the space actually allocated.
__________
WEG] This is news to me, based on the discussion in Quebec, but I may well have missed something...
Was that change ever discussed publicly on the list? What was the rationale for the change? Do the sponsoring AD or WG chairs have any comments?
Regardless of this change, I do not see that as a reason to ignore legitimate feedback in the interest of hurrying this draft through. A few weeks is not going to make that much of a difference in the grand scheme of things. WGLC is among the first hurdles to publication, not the last.

I don't see those areas as necessarily conflicting though I do think they make somewhat substantial use of should whereas you seem to feel that should in draft-weil ought to be treated as must. Since the very service provider making the decision to use any of those mechanisms described in the sections you refer to as conflicting would also be the one suffering from any conflict, I believe leaving it up to said service provider to resolve such conflicts is in keeping with the intents of both drafts.
__________
WEG] The draft (and therefore IETF's recommendations) on the matter needs to be internally consistent. What parts of it an implementer chooses to ignore is quite rightly beyond the IETF's purview as we can do little but shake our fingers and say that we told you so if it goes pear-shaped. However, if there is a question of consistency then it makes sense to determine consensus on that point:
Is, or is this not expected to be used as a replacement for existing private-scope address space (RFC1918), even if only in certain circumstances? If so, does the WG (and the IETF community) agree that these use cases are sufficiently unmanageable with RFC1918 space that they support the need to expand the use of the space beyond what was defined in draft-weil to cover these cases? If so, does it warrant an official update to RFC1918 to ensure that those making assumptions about scope of address space are aware of the updated guidance?
Getting a clear answer to this will identify if the SHOULD needs to be a MUST, or if it's ok as-is but the bdgks needs to be clarified, etc.

It really doesn't. RFC-1918 is problematic in each of the use cases for the exact same reason as is described in draft-weil.
___________
WEG] could you point me to where exactly draft-weil describes this, or even mentions RFC1918 other than to note that this allocated space should be separate from it? If 1918 is problematic for these use cases, this is the draft that needs to discuss it. Alternatively, remove these use cases from this draft and spin a separate draft to cover that, since it's likely to be more contentious than the simple case of using space as inside NAT pools for IPv6 transition.

I have re-read RFC1918 section 2 and I believe that the use cases documented in this draft are all unique to this situation in that they all involve a service provider needing IPv4 space that does not have to be globally unique, but, does have to avoid any overlap with space in use on said ISPs customer's networks.
_____________
WEG] We've established that our personal opinions on the matter do not line up, but we don't have to agree. I fully expect consensus to either loudly shout one of us down or force us to meet somewhere in the middle now that I've raised the concern for discussion. Is "conflicts with existing (1918) space" an acceptable case to use this space for things beyond the stated use in draft-weil or not?

WEG] This is a cop out. No one expects the authors to be clairvoyant, but if you're so convinced that 5508 is inadequate, it should not be difficult to articulate some broad-strokes discussion on *some* of the areas where it falls down to help to direct the "further investigation"  that may be required.

I believe given recent allocation history, a combination of signatories to the consortium sufficient to justify a 3 month need for a /10 would be possible, but, yes, it would be difficult at best. I'm not sure what you are trying to achieve with this comment.
WEG] Well, mainly I was trying to provide a helpful addition to the case that you're trying to make here. You by no means need to add it, but I'm a bit confused by the adversarial nature of your response.

> 3.3.2 - ...That seems like a bad position for the IETF to be taking - don't just do NAT, do enough of it so that you can give (sell) space back...
>

I don't disagree with you here, but, the reality is that whether or not to do so is a business decision that will be made by each ISP regardless of what is said in any RFC and we felt it was better to address this directly than to ignore it.
WEG] There's a big difference between individual ISPs making business decisions and IETF recommending that something be done. Given that this discussion is part of the justification for why we are allocating this space in the first place, it comes across as an implicit recommendation of that action. In this case, we're recommending something that we know will do harm, and I have philosophical problems with this. Based on discussions I've heard at IETF in the past, I believe that others will too.

> 3.5 - you need to coordinate with draft-vegoda-no-more-unallocated-slash8s section 4
>

WEG] As I said, as long as the updates happen somewhere, I'm happy. FYI draft-vegoda is currently in Publication requested status (though to be fair the status just changed). http://datatracker.ietf.org/wg/grow/ However, it went through WGLC in July. http://www.ietf.org/mail-archive/web/grow/current/msg01978.html. It may end up being a race condition.

> 3.6 - segmenting networks...
>

Perhaps, but, is there some reason you wish to avoid mentioning segmentation?
WEG] not really, I just don't think that it helps to bolster the point you're trying to make here.

Whether you want to call it a bad assumption or not, it's a problematic assumption at this point. The point is that while that assumption will be problematic here, it is even more problematic for each of the possible alternatives to this shared space. With a defined block at least mitigation is possible. In the case of squatting or blocks chosen individually by each provider, no such host-level mitigation could be achieved.
___________
WEG] I'm not disputing the point that it breaks just as badly if you choose to squat on other GUA space, nor that it may *become* a bad host assumption. I am disputing the assertion that it's *currently* a bad host assumption and therefore not a valid concern, and I also disagree with the notion that vendors will put in host-level mitigation beyond what they have already done to depref broken things like 6to4, especially if this is carved out as separate in an "almost, but not entirely, RFC1918 space" way.

I believe that this paragraph meets the author's intent and that there are situations where said use cases while not ideal may be entirely pragmatic. Since the scope of the problems which may be created by said alternate uses is entirely within the affected ISPs domain of control, I think this is the best approach at this time -- explain, discourage, but leave the options open.
___________
WEG] Intent is exactly what I'm trying to tease out here, so that I can determine more clearly if draft-weil really needs to have a MUST, whether this draft needs tweaking for clarification, or what. I won't repeat my earlier questions here.

Multiple ISPs have said they would use it during the development of this draft on this very list. While I wouldn't oppose such additional text, I really don't see it as necessary to move forward.  Had you chosen not to wait until WGLC to bring this up, I think the authors would have easily addressed it. Making it a gating item to exit last call is simply obstructionist.
_____________
WEG] This document is supposed to help the reader understand the rationale behind the action that IETF is being asked to take, and I don't think it's unreasonable to say, "citation, please" when assertions like 4.2.1 and 4.2.2 are made in rebuttal to arguments that have been previously made. Further, I'm growing tired of being lectured about when I chose to bring up my concerns and having them labeled as obstructionist or nit-picking in lieu of responding to them. The whole point behind WGLC is not to get a rubber-stamp on the draft. It is to ensure that those of us who get busy and procrastinate on draft reviews look at drafts before they move forward, to ensure that quality reviews are completed and concerns addressed. WGLC quite often triggers a revision of the document to address comments from the LC. Failure to address concerns (or worse, inadequate review) during WGLC results in those same concerns being brought up at IETF LC, or IESG review, and/or shoddy drafts. The point is to generate a good document based on consensus, not to push it through the process as quickly as possible, no matter how important and urgent the authors (and other supporters) think it might be.
If we want to talk dates - I sent private mail to several (admittedly, not all) of the authors around the time when -01 was released in July. -02 (which should have addressed those comments) was released on 8/31, and the doc went to WGLC the next day, right before a holiday weekend in the US. By my estimation, I'm less than 5 business days in responding with comments to the current draft.

Many of the participants of world IPv6 day are no longer reachable via IPv6. I agree that "whole internet" may not be slightly hyperbolous, but, the point is that no matter how many access providers fully dual-stack their customers, IPv4 support will be required until there is a sufficient critical mass of content providers.
___________
WEG] no disagreement. I much prefer the way that you make the point here to the hyperbole in the draft.

Since the IETF has insisted on joining the drafts at the hip with a shared fate, I'm not sure it matters.
___________
WEG] then let me ask the question a slightly different way, possibly to the chairs and sponsors: what is the point of having a separate draft at all? If there's no longer a push to get draft-weil moved through quicker to get the allocation completed while giving us time to make the rationale draft thorough, I'd rather see these combined, as it may help to alleviate some of the confusion on the language between the two. If expediency of both drafts is really the goal, I'd say that you're overreaching with the rest of the use cases, and should cut the draft down to the minimum required to cover the primary case. If you want to write another draft about alternate use cases after the rush is addressed, you then have plenty of time to address concerns.

Absent operational experience with these mechanisms, it really isn't possible to identify all of the security concerns, especially given the variety of operational environments in which they are likely to be deployed. As such, I think the appropriate course is to advise the reader that they must consider this form themselves as it applies to their unique environment.
___________
WEG] quite a lot of IETF drafts are written "absent operational experience." It is incumbent upon the authors and the adopting WG to consider those security considerations and document them to the best of their abilities. It is not an expectation that the authors or WG will be clairvoyant, but that a good faith effort was made to consider and document based on what is known at the time of writing. Keep in mind that each draft gets a review by the security directorate before publishing, and if they don't like the answer, they'll make you fix it, so it's better to be proactive.

Wes George

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 7 Sep 2011 18:43:28 -0400

Wes,

In Quebec, we agreed to progress a minimal draft-weil very quickly. Draft-weil would include an informative reference to draft-bdqks. Since draft-bdqks is a more substantive work, it could progress more slowly.

During the last call on draft-weil, somebody pointed out that draft-bdqks contained the rationale for draft-weil. Therefore, the informative reference to draft-bdqks was inappropriate and needed to be replaced with a normative reference. This put draft-bdqks on the critical path for draft-weil.

It seems that now we have the following options:

- Argue that there is no normative dependency between draft-weil and draft-bdqks
- Break the dependency between draft-weil and draft-bdqks by moving enough motivating material into draft-weil
- Speed up the progress of draft-bdqks
- Live with a later ETA for draft-weil

I'm sorry that I don't have better news.

                                          Ron

> From: George, Wesley [mailto:[email-masked]]
> Sent: Wednesday, September 07, 2011 5:26 PM
> To: Owen DeLong
> Cc: Scott O. Bradner; [email-masked]; draft-weil-shared-transition-
> [email-masked]; draft-bdgks-arin-shared-transition-
> [email-masked]; Ronald Bonica
> Subject: RE: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space
>
> This document is not the justification for draft-weil, it is a
> description of a set of recommended use cases for the space set aside
> in draft-weil.
> __________
> WEG] Draft-weil has been stripped of nearly all of its justification
> with the expectation that it would exist in another draft, and its
> language disagrees with you:
> Further, we've since basically been told that draft-weil is not going
> to move forward until this draft does, so, that purpose for the spilt
> has been eliminated and this has become a blocking item for getting the
> space actually allocated.
> __________
> Was that change ever discussed publicly on the list? What was the
> rationale for the change? Do the sponsoring AD or WG chairs have any
> comments?
> Regardless of this change, I do not see that as a reason to ignore
> legitimate feedback in the interest of hurrying this draft through. A
> few weeks is not going to make that much of a difference in the grand
> scheme of things. WGLC is among the first hurdles to publication, not
> the last.
>
> > My biggest issue with this draft is that there are multiple sections
> within it that discuss other use cases for this shared transition
> space. In almost every case, these are in conflict with the language in
> section 4 of draft-weil-shared-transition-space-request, and even with
> other sections within draft-bdgks that assert that this shared
> transition space is not to be used as additional RFC1918 space. From
> draft-weil:
> > I'll note specifically sections 2.1.2, 2.1.3, 3.3, 4.1.3, 4.2.2 as
> areas where this is unclear or conflicting.
>
> I don't see those areas as necessarily conflicting though I do think
> they make somewhat substantial use of should whereas you seem to feel
> that should in draft-weil ought to be treated as must. Since the very
> service provider making the decision to use any of those mechanisms
> described in the sections you refer to as conflicting would also be the
> one suffering from any conflict, I believe leaving it up to said
> service provider to resolve such conflicts is in keeping with the
> intents of both drafts.
> __________
> WEG] The draft (and therefore IETF's recommendations) on the matter
> needs to be internally consistent. What parts of it an implementer
> chooses to ignore is quite rightly beyond the IETF's purview as we can
> do little but shake our fingers and say that we told you so if it goes
> pear-shaped. However, if there is a question of consistency then it
> makes sense to determine consensus on that point:
> Is, or is this not expected to be used as a replacement for existing
> private-scope address space (RFC1918), even if only in certain
> circumstances? If so, does the WG (and the IETF community) agree that
> these use cases are sufficiently unmanageable with RFC1918 space that
> they support the need to expand the use of the space beyond what was
> defined in draft-weil to cover these cases? If so, does it warrant an
> official update to RFC1918 to ensure that those making assumptions
> about scope of address space are aware of the updated guidance?
> Getting a clear answer to this will identify if the SHOULD needs to be
> a MUST, or if it's ok as-is but the bdgks needs to be clarified, etc.
>
> > I'm not sure whether the language needs to be refined in draft-weil
> to clarify acceptable vs unacceptable uses and permit additional cases,
> or whether this draft purports to make a recommendation of alternate
> use cases that move beyond draft-weil, but somehow the conflict needs
> to be resolved. If the intent is to add more use cases, this document
> could say:
> > But if it does that, it would also have to discuss in each case,
> "RFC1918 is problematic for this use because..."
>
> It really doesn't. RFC-1918 is problematic in each of the use cases for
> the exact same reason as is described in draft-weil.
> ___________
> WEG] could you point me to where exactly draft-weil describes this, or
> even mentions RFC1918 other than to note that this allocated space
> should be separate from it? If 1918 is problematic for these use cases,
> this is the draft that needs to discuss it. Alternatively, remove these
> use cases from this draft and spin a separate draft to cover that,
> since it's likely to be more contentious than the simple case of using
> space as inside NAT pools for IPv6 transition.
>
> > My personal opinion is that the more alternate use cases we document,
> the more slippery the slope becomes towards this becoming a second, but
> not properly documented (eg a formal RFC1918-bis) set of RFC1918 space,
> rather than limited to a fairly narrowly stated purpose that is easily
> distinguishable from RFC1918. I would encourage the draft authors to
> re-read RFC1918 section 2 with a mind to identifying use cases that are
> unique to this application.
> >
>
> My personal opinion is that all of the use cases documented are not a
> slippery slope at all and each involves a decision by the very provider
> who would be affected by that decision. This is radically different
> from the problem caused by RFC-1918 conflicts with customers.
>
> I have re-read RFC1918 section 2 and I believe that the use cases
> documented in this draft are all unique to this situation in that they
> all involve a service provider needing IPv4 space that does not have to
> be globally unique, but, does have to avoid any overlap with space in
> use on said ISPs customer's networks.
> _____________
> WEG] We've established that our personal opinions on the matter do not
> line up, but we don't have to agree. I fully expect consensus to either
> loudly shout one of us down or force us to meet somewhere in the middle
> now that I've raised the concern for discussion. Is "conflicts with
> existing (1918) space" an acceptable case to use this space for things
> beyond the stated use in draft-weil or not?
>
> > 2.1.4 - I agree with the concern about routing ambiguity, but the
> reference to allowing ICMP messages is confusing (at least to me) as to
> how it relates to the previous statements. There are multiple documents
> covering proper filtering of ICMP both for NATs and otherwise, such as
> RFC5508. At the least, you should provide a reference to 5508. If the
> authors do not believe that 5508 covers all of the considerations
> something more specific than "...requires further investigation..."
> needs to be here.
> >
>
> I can't speak for all of the authors, but, I believe that 5508 does not
> cover all of the possible considerations in the various scenarios that
> could be encountered in this brave new world of multi-layer NAT and/or
> NAT being inflicted on customers at the carrier level. I also do not
> believe that such consideration is possible until a certain amount of
> operational observation has occurred. Therefore, since each provider
> using this space is headed off to chart new territory, the best that
> can be said at this time is "requires further investigation" so as to
> alert providers using said space that they may enter uncharted
> territory and may face considerations beyond the clairvoyance of the
> authors.
>
> WEG] This is a cop out. No one expects the authors to be clairvoyant,
> but if you're so convinced that 5508 is inadequate, it should not be
> difficult to articulate some broad-strokes discussion on *some* of the
> areas where it falls down to help to direct the "further investigation"
> that may be required.
>
> > 2.2.6 - A consortium would also have difficulty demonstrating enough
> need to get the an allocation for the address space necessary given the
> limitations present in the RIRs due to "last /8 policies" (/22 in
> APNIC, 3 month justification in ARIN, etc).
> >
>
> I believe given recent allocation history, a combination of signatories
> to the consortium sufficient to justify a 3 month need for a /10 would
> be possible, but, yes, it would be difficult at best. I'm not sure what
> you are trying to achieve with this comment.
> WEG] Well, mainly I was trying to provide a helpful addition to the
> case that you're trying to make here. You by no means need to add it,
> but I'm a bit confused by the adversarial nature of your response.
>
> > 3.3.2 - ...That seems like a bad position for the IETF to be taking -
> don't just do NAT, do enough of it so that you can give (sell) space
> back...
> >
>
> I don't disagree with you here, but, the reality is that whether or not
> to do so is a business decision that will be made by each ISP
> regardless of what is said in any RFC and we felt it was better to
> address this directly than to ignore it.
> WEG] There's a big difference between individual ISPs making business
> decisions and IETF recommending that something be done. Given that this
> discussion is part of the justification for why we are allocating this
> space in the first place, it comes across as an implicit recommendation
> of that action. In this case, we're recommending something that we know
> will do harm, and I have philosophical problems with this. Based on
> discussions I've heard at IETF in the past, I believe that others will
> too.
>
> I would say once this moves forward, draft-vegoda would need the
> update. I don't see the update to draft-vegoda as a gating item for
> this draft, but, rather that if this draft moves forward, that update
> would become a gating item for draft-vegoda. To the best of my
> knowledge, draft-vegoda has not moved to WGLC as yet.
>
> WEG] As I said, as long as the updates happen somewhere, I'm happy. FYI
> draft-vegoda is currently in Publication requested status (though to be
> fair the status just changed). http://datatracker.ietf.org/wg/grow/
> However, it went through WGLC in July. http://www.ietf.org/mail-
> archive/web/grow/current/msg01978.html. It may end up being a race
> condition.
>
> > 4.1.2 - I disagree with the assertion of "Bad Host Assumption" as
> justification here. I haven't been able to find anything within the
> IETF that explicitly says "assuming address scope based on IPv4 address
> block considered harmful" or similar. In fact, there are multiple
> places where IETF discusses problems inherent with non-unique addresses
> and behavior/implementation changes to compensate (such as 3056 section
> 5.8 and 5.9, quoted below) in such a way that it conflates the two and
> perpetuates that assumption.
> >   "The V4ADDR MUST be
> > I don't think that "not globally-unique" is crisply distinguished
> from "RFC1918 addresses" in all existing IETF work on the matter.
> Further, this has become a de facto assumption in many implementations
> because prior to IPv4 address exhaustion, it was largely accurate.
> > In addition, RFC6250 (which covers and debunks a number of bad
> assumptions about IP) section 3.2.4 says "...scoped addresses as
> defined for both IPv4 [RFC1918][RFC3927]..." illustrating the link
> between the two. It also does not discuss this concept of assuming
> scope via address block as a bad assumption, despite just being
> published this year.
> Whether you want to call it a bad assumption or not, it's a problematic
> assumption at this point. The point is that while that assumption will
> be problematic here, it is even more problematic for each of the
> possible alternatives to this shared space. With a defined block at
> least mitigation is possible. In the case of squatting or blocks chosen
> individually by each provider, no such host-level mitigation could be
> achieved.
> ___________
> WEG] I'm not disputing the point that it breaks just as badly if you
> choose to squat on other GUA space, nor that it may *become* a bad host
> assumption. I am disputing the assertion that it's *currently* a bad
> host assumption and therefore not a valid concern, and I also disagree
> with the notion that vendors will put in host-level mitigation beyond
> what they have already done to depref broken things like 6to4,
> especially if this is carved out as separate in an "almost, but not
> entirely, RFC1918 space" way.
>
>
> > 4.1.3 - Between the inconsistencies that I have pointed out within
> this draft, and the fact that draft-weil says "should not" and not
> "must not," I'm not sure that this section really responds to the noted
> concern in its current form. At a minimum, it would be appropriate to
> cite/quote specific normative language from draft-weil to underscore
> that this would actually be a misuse and not simply a grey area.
> Personally, I would be much more comfortable with a "must not" in
> draft-weil, but perhaps that ship has sailed.
> >
>
> The inconsistencies you have pointed out would be inconsistent if
> draft-weil said "must not", but, in a "should not" case aren't all that
> inconsistent IMHO.
>
> I believe that this paragraph meets the author's intent and that there
> are situations where said use cases while not ideal may be entirely
> pragmatic. Since the scope of the problems which may be created by said
> alternate uses is entirely within the affected ISPs domain of control,
> I think this is the best approach at this time -- explain, discourage,
> but leave the options open.
> ___________
> WEG] Intent is exactly what I'm trying to tease out here, so that I can
> determine more clearly if draft-weil really needs to have a MUST,
> whether this draft needs tweaking for clarification, or what. I won't
> repeat my earlier questions here.
>
> > 4.2.1 - This section needs referential support in order to not be
> debating an opinion. Perhaps you could provide pointers to places where
> ISPs have said that they would use it. If those are unavailable, it may
> make sense to call explicit attention to the fact that two of the
> authors on this draft are operators of broadband residential networks,
> draft-weil is also written by several operators, and explain that
> Cablelabs represents many cable operators. If not actually coming out
> and saying that the operators represented have plans to use this, it
> would be strongly implied simply by making the affiliations more
> obvious.
> >
>
> Multiple ISPs have said they would use it during the development of
> this draft on this very list. While I wouldn't oppose such additional
> text, I really don't see it as necessary to move forward.  Had you
> chosen not to wait until WGLC to bring this up, I think the authors
> would have easily addressed it. Making it a gating item to exit last
> call is simply obstructionist.
> _____________
> WEG] This document is supposed to help the reader understand the
> rationale behind the action that IETF is being asked to take, and I
> don't think it's unreasonable to say, "citation, please" when
> assertions like 4.2.1 and 4.2.2 are made in rebuttal to arguments that
> have been previously made. Further, I'm growing tired of being lectured
> about when I chose to bring up my concerns and having them labeled as
> obstructionist or nit-picking in lieu of responding to them. The whole
> point behind WGLC is not to get a rubber-stamp on the draft. It is to
> ensure that those of us who get busy and procrastinate on draft reviews
> look at drafts before they move forward, to ensure that quality reviews
> are completed and concerns addressed. WGLC quite often triggers a
> revision of the document to address comments from the LC. Failure to
> address concerns (or worse, inadequate review) during WGLC results in
> those same concerns being brought up at IETF LC, or IESG review, and/or
> shoddy drafts. The point is to generate a good document based on
> consensus, not to push it through the process as quickly as possible,
> no matter how important and urgent the authors (and other supporters)
> think it might be.
> If we want to talk dates - I sent private mail to several (admittedly,
> not all) of the authors around the time when -01 was released in July.
> -02 (which should have addressed those comments) was released on 8/31,
> and the doc went to WGLC the next day, right before a holiday weekend
> in the US. By my estimation, I'm less than 5 business days in
> responding with comments to the current draft.
>
> > 4.4.2 - why is it that "The whole Internet needs to get to IPv6 more
> or less at the same time"? There are plenty of communities of interest
> where IPv6 capability can reach critical mass and see immediate benefit
> independent of what "the Internet" does. For instance, any dual-stack
> customer on an ISP network can bypass an IPv4 CGN if the content they
> wish to hit (like any of the participants of world IPv6 day, for
> example) is IPv6-capable.
> >
>
> Many of the participants of world IPv6 day are no longer reachable via
> IPv6. I agree that "whole internet" may not be slightly hyperbolous,
> but, the point is that no matter how many access providers fully dual-
> stack their customers, IPv4 support will be required until there is a
> sufficient critical mass of content providers.
> ___________
> > 7 - Don't these IANA considerations belong in draft-weil since that
> is the draft that is actually requesting the IANA
> reservation/documentation?
> >
>
> WEG] then let me ask the question a slightly different way, possibly to
> the chairs and sponsors: what is the point of having a separate draft
> at all? If there's no longer a push to get draft-weil moved through
> quicker to get the allocation completed while giving us time to make
> the rationale draft thorough, I'd rather see these combined, as it may
> help to alleviate some of the confusion on the language between the
> two. If expediency of both drafts is really the goal, I'd say that
> you're overreaching with the rest of the use cases, and should cut the
> draft down to the minimum required to cover the primary case. If you
> want to write another draft about alternate use cases after the rush is
> addressed, you then have plenty of time to address concerns.
>
> > 8- I'm bothered by the "weasel words" in this section. If this is
> documenting new use cases for this shared space not covered in draft-
> weil, it should provide detailed security considerations for each, or
> references to existing documents where they are discussed. If the
> authors believe that there are no security considerations, then just
> say so, rather than "... the reader is advised to investigate these
> independently."
> >
>
> Absent operational experience with these mechanisms, it really isn't
> possible to identify all of the security concerns, especially given the
> variety of operational environments in which they are likely to be
> deployed. As such, I think the appropriate course is to advise the
> reader that they must consider this form themselves as it applies to
> their unique environment.
> ___________
> WEG] quite a lot of IETF drafts are written "absent operational
> experience." It is incumbent upon the authors and the adopting WG to
> consider those security considerations and document them to the best of
> their abilities. It is not an expectation that the authors or WG will
> be clairvoyant, but that a good faith effort was made to consider and
> document based on what is known at the time of writing. Keep in mind
> that each draft gets a review by the security directorate before
> publishing, and if they don't like the answer, they'll make you fix it,
> so it's better to be proactive.
>
> 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: Owen DeLong <[email-masked]>
Date: Wed, 7 Sep 2011 18:05:02 -0700

> This document is not the justification for draft-weil, it is a description of a set of recommended use cases for the space set aside in draft-weil.

Interesting... That's news to me. I had been told that it was strictly the applicability document and not that we needed to also include the justification.

> Further, we've since basically been told that draft-weil is not going to move forward until this draft does, so, that purpose for the spilt has been eliminated and this has become a blocking item f…

I don't know if it was discussed publicly, but, word came back to the bdgks authors from those that have been working with the AD and WG chairs that "draft-weil will not survive the conference call unless we have draft-bdgks out of last call to move forward with it."

I confess to a certain ignorance of IETF process details as I spend far more of my time dealing with actual operational issues and very little time on IETF matters
like most operators.

> I don't see those areas as necessarily conflicting though I do think they make somewhat substantial use of should whereas you seem to feel that should in draft-weil ought to be treated as must. Sin…

I don't see the uses you describe as being a replacement for private-scope RFC-1918 address space. Since they are services being provided to end users outside of the local administrative domain (or perhaps more accurately in other administrative domains). To me, RFC-1918 is not generally intended to be used for purposes which cross administrative domains. (I realize that it routinely is, but, I consider that a pear-shaped use of RFC-1918 as you call it).

Further, these recommendations involve use of it to provide services in one administrative domain to leaf networks which are generally single-homed to the serving administrative domain. This is also, IMHO, a significant difference from the intent of RFC-1918.

> It really doesn't. RFC-1918 is problematic in each of the use cases for the exact same reason as is described in draft-weil.
Appears to have been removed in one of the more recent edits. You're right, draft-weil has become quite minimal.

I do think, however, that bdgks 2.2.2 does a pretty good job of explaining why RFC-1918 is problematic for all of the use cases mentioned and delineating when this space is likely to be a preferred alternative.

> I have re-read RFC1918 section 2 and I believe that the use cases documented in this draft are all unique to this situation in that they all involve a service provider needing IPv4 space that does…

Fortunately, so far, it appears you and Brian are lone voices of dissent.

> WEG] Well, mainly I was trying to provide a helpful addition to the case that you're trying to make here. You by no means need to add it, but I'm a bit confused by the adversarial nature of your re…

Sorry, I misunderstood your intent. I thought you were attempting to point out that the consortium argument no longer held water.

> WEG] There's a big difference between individual ISPs making business decisions and IETF recommending that something be done. Given that this discussion is part of the justification for why we are…

I don't believe that this encourages operators to do more NAT as phrased. I believe it points out that if you do (as many providers are likely to) convert blocks of customers at a time, addresses which are freed up can and should be transferred rather than being left fallow.

> WEG] As I said, as long as the updates happen somewhere, I'm happy. FYI draft-vegoda is currently in Publication requested status (though to be fair the status just changed). http://datatracker.iet…

I think this can be resolved after the dust settles. It's not like draft-vegoda becomes immutable after publication. Many RFCs obsolete precursor RFCs.

The right place to make the update you suggest is, IMHO, in draft-vegoda.

Thanks for correcting my perception about the status of draft-vegoda.

> Whether you want to call it a bad assumption or not, it's a problematic assumption at this point. The point is that while that assumption will be problematic here, it is even more problematic for e…

Well... In discussions I have had with engineers from D-Link, Linksys, and Netgear, I've been told that adding a /10 to the list of excluded prefixes would be the cleanest and easiest way to deal with it. That while they would may not update existing products, they would likely update their software for new products relatively quickly.

As such, I think that making the /10 in question known at the earliest possible opportunity provides the best opportunity to reduce the amount of brokenness that will be caused. As you have agreed above, any of the available solutions to the problem (provider GUA, Squat GUA, or this draft) all inflict the same damage. The difference is that this draft is the one with the greatest chance of mitigation.

> I believe that this paragraph meets the author's intent and that there are situations where said use cases while not ideal may be entirely pragmatic. Since the scope of the problems which may be cr…

I believe that the current wording reflects the intent of the authors in both cases. I believe a must would be inappropriate in draft-weil in that location.

> WEG] This document is supposed to help the reader understand the rationale behind the action that IETF is being asked to take, and I don't think it's unreasonable to say, "citation, please" when assertions like 4.2.1 and 4.2.2 are made in rebuttal to arguments that have been previously made. Further, I'm growing tired of being lectured about when I chose to bring up my concerns and having them labeled as obstructionist or nit-picking in lieu of responding to them. The whole point behind WGLC is not to get a rubber-stamp on the draft. It is to ensure that those of us who get busy and procrastinate on draft reviews look at drafts before they move forward, to ensure that quality reviews are completed and concerns addressed. WGLC quite often triggers a revision of the document to address comments from the LC.

I'm not opposed to addressing your concerns to the extent that they can be addressed without delaying progress on the draft and to the extent that they are shared by more of the WG and/or the authors. I disagree with most of your concerns.

> Failure to address concerns (or worse, inadequate review) during WGLC results in those same concerns being brought up at IETF LC, or IESG review, and/or shoddy drafts. The point is to generate a good document based on consensus, not to push it through the process as quickly as possible, no matter how important and urgent the authors (and other supporters) think it might be.

There's always a tradeoff. If there were a way to get agreement to issue the /10 and publish the specific prefix prior to completion of the draft process, I'd be happy to debate the merits and refine the drafts until the cows come home. However, the longer the issuance of the /10 is delayed, the more damage will be done in the real world as a result. 

> If we want to talk dates - I sent private mail to several (admittedly, not all) of the authors around the time when -01 was released in July. -02 (which should have addressed those comments) was re…

I believe that we addressed the concerns expressed by you in any of the emails that I saw. If you sent emails to other authors that I did not see, then, I cannot comment on the content of those emails. To my viewpoint, the concerns raised here are mostly new and do not reflect the same concerns raised in your earlier writings that I received.

> Many of the participants of world IPv6 day are no longer reachable via IPv6. I agree that "whole internet" may not be slightly hyperbolous, but, the point is that no matter how many access provider…

A change I would not oppose making in the draft, though I don't believe this change has meaningful impact.

> Since the IETF has insisted on joining the drafts at the hip with a shared fate, I'm not sure it matters.
I would greatly prefer that it was possible to get draft-weil through and spend time refining draft-bdgks. I think that under the current circumstances, if we cannot move forward quickly in any other way, then, yes, your final suggestion in the last paragraph may well be the best way to go.

I believe the second paragraph of section 8 reflects exactly that. There are no direct security concerns with the issuance of the /10, but, there may well be implementation dependent concerns for those that choose to deploy it. Since these concerns are, literally, implementation dependent, absent clairvoyance about a given implementation, I'm not sure what you expect here.

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

#include <std_lawyersig_rant.h>

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 07:58:42 -0400

Owen,

This matches my understanding as well and I was presenting at the meeting in Quebec.

Wes, 

Can you point out where it seemed this changed?

---

From: "George, Wesley" <[email-masked]>
Date: Thu, 8 Sep 2011 13:09:14 -0400

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]]
Sent: Wednesday, September 07, 2011 9:05 PM

I don't see the uses you describe as being a replacement for private-scope RFC-1918 address space. Since they are services being provided to end users outside of the local administrative domain (or perhaps more accurately in other administrative domains). To me, RFC-1918 is not generally intended to be used for purposes which cross administrative domains.

Further, these recommendations involve use of it to provide services in one administrative domain to leaf networks which are generally single-homed to the serving administrative domain. This is also, IMHO, a significant difference from the intent of RFC-1918.
____________
WEG] You would do well to add nearly all of the above text to your draft. This is much clearer in delineating the difference between the two, which is really what I was after - crispness and clarity around how to use each. However, in understanding better what you mean, I think that it translates to a requirement to formally update RFC1918 since the draft is essentially saying that there are additional private-scope use cases that were not covered by 1918. It's fine to say that, and stipulate that because of the potential conflict between the two spaces that they MUST not be used interchangeably. From a process perspective, this doesn't mean that you have to start over, because you can simply add "this draft updates RFC1918," but it would help to have some guidance on how best to proceed with the two drafts. I think you can make the argument that even the inside NAT pool case in draft-weil could be covered this way, merge everything back together into one cohesive draft and be done with it.

WEG] There's that critical caveat: "...may not update existing products..." If ISPs could get shiny new boxes from the above vendors to all of their customers, they would support IPv6 and therefore sharply reduce the amount of CGN that is necessary in the first place, because it would effectively push the IPv4-only portion down another layer to legacy Consumer Electronics. But I digress...

Wes George

---

From: "George, Wesley" <[email-masked]>
Date: Thu, 8 Sep 2011 13:33:19 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 08, 2011 7:59 AM

Wes,
Can you point out where it seemed this changed?
_______
WEG] Ron's message explains what happened - someone noted during WGLC of draft-weil that you can't have a normative ref to a draft that's not complete, which effectively stopped the current plan. Mea culpa, I missed that.
However, we shouldn't be surprised that there was confusion over this (or at least *I* am not surprised that *I* was confused). Note that over the past year, there have been 3 or 4 different versions of a draft for shared transition space:
draft-weil-opsawg-provider-address-space, which had at least 2 dramatically different versions
draft-weil-shared-transition-space-request (the current one) which has added and then removed justification over each version
And some of that orphaned text made it into draft-bdgks-arin-shared-transition-space
And in between, it made the rounds through ARIN (policy 2011-5), only to be sent back here by IAB.

Independent of whether the opposition represents consensus or simply a vocal minority, this has always been a controversial idea and it feels more like we're trying to play shell games to avoid controversy and push this through quickly than to build consensus and a quality document(s).
First it dropped from a /8 to a /10 to try to reduce the opposition due to size
Then it dropped most of the justification text from the draft to "reduce the attack surface"
Then it split the drafts, with draft-weil becoming an AD-sponsored draft (for rapid adoption) and some other draft (eventually bdgks) providing the rationale and justification to provide the WG time to properly review and refine the details around draft-weil.
Now, based on the author's responses, it leaves draft-weil without any justification, and has a separate draft that covers additional use cases. If bdgks isn't the justification for draft-weil, perhaps draft-weil doesn't actually *need* a normative reference to bdgks, which would address the concern brought up at its last call. Whether the lack of rationale now brings up a new concern for draft-weil is for the sponsoring AD to address, I suppose.

I'm starting to think that it's not productive to continue discussing the content of the drafts until we have a clearer direction of what that content and the separation between them is supposed to be. If the plan is to push through both drafts largely as-is, and I am truly in the minority, so be it, I'll hold my nose and get out of the way. If, however, the aim is to actually provide a convincing argument for shared transition space, we need some additional guidance from the AD and Chairs. Most notably, for additional use cases, should there be a formal update to RFC1918 to acknowledge that there are circumstances where RFC1918 space is not an acceptable solution, and that additional address space is required to avoid conflicts?

Wes George

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 8 Sep 2011 15:15:59 -0400

I support draft-bdgks-arin-shared-transition-space in principle.

> - Argue that there is no normative dependency between draft-weil and
draft-bdqks

draft-weil-shared-transition-space-request-04 looks sufficient to me.  It
describes the
need ("support such heritage IPv4-only devices") and the use case ("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." ).   Nobody
would be 
confused about how to implement draft-weil if draft-bdgks were never
adopted;
draft-bdgks is therefore informative, not normative.    draft-bdgks then
provides 
additional context and additional possible use cases.

> - Break the dependency between draft-weil and draft-bdqks by moving enough
motivating
> material into draft-weil

How much is "enough"?  Is an additional sentence describing "heritage
IPv4-only
devices" enough?  I can't find any description of the objection that caused
the
documents to be linked.

> - Speed up the progress of draft-bdqks

Already in WGLC, not sure it could be sped up much.

> - Live with a later ETA for draft-weil

We already have that. 

Lee

---

From: Owen DeLong <[email-masked]>
Date: Thu, 8 Sep 2011 18:15:01 -0700

I'd support doing that so long as doing so does not delay a positive outcome from last call.

Owen

Sent from my iPad

---

From: Owen DeLong <[email-masked]>
Date: Thu, 8 Sep 2011 18:17:00 -0700

Sent from my iPad

> Further, these recommendations involve use of it to provide services in one administrative domain to leaf networks which are generally single-homed to the serving administrative domain. This is als…

Yes, but, here's the set of choices we are faced with...

1. Shared /10 -- some boxes get mitigation, others MAY not.
2. Squat space -- Nobody gets mitigation.
3. SIP space -- Nobody gets mitigation and a likely increase in the number of customers subjected to CGN

Of those three sets of tradeoffs, I think 1 is a markedly better choice.

Owen

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 10 Sep 2011 22:44:20 -0400

>> Well... In discussions I have had with engineers from D-Link, Linksys,
>>and Netgear, I've been told that adding a /10 to the list of excluded
>>prefixes would be the cleanest and easiest way to deal with it. That
>>while they would may not update existing products, they would likely
>>update their software for new products relatively quickly.
>> 
>> WEG] There's that critical caveat: "...may not update existing
>>products..." If ISPs could get shiny new boxes from the above vendors to
>>all of their customers, they would support IPv6 and therefore sharply
>>reduce the amount of CGN that is necessary in the first place, because
>>it would effectively push the IPv4-only portion down another layer to
>>legacy Consumer Electronics. But I digress...

That may be true, but IPv6 addition does not remove the need for IPv4
connectivity for the near/mid term future.  In many cases the IPv4 path
may need to be CGN (dual stacked CPE) due to address constraints.  It
would be still valid to have new boxes include this space irrespective of
the IPv6 operation.

>number of customers subjected to CGN

Agreed. Many keep (understandably so) comparing the the shared space
option to "good operation" whereas we have been clear there will be
challenges.  The issue is that options 2/3 (which will happen without
Share Space - option 1) will create far more problems.

Options 2/3 (as shown above) will not only introduce the known challenges
of the shared space, but will add in many more variables and will
ultimately be impossible to control and build rules around - the wild west.

The community has the opportunity to make the best of a less then optimal
situation or we can explain to the Internet base why we missed this
valuable opportunity to make things better while we discussed how to
achieve utopia.

Regards,

Victor K

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 11 Sep 2011 10:53:24 -0700

>> number of customers subjected to CGN

The debate persistently an consistently ignores that using rfc 1918
space is an option. even as the document addresses that in 2.2.2

Given that there are abundant field examples of using existing private
scope address space for this purpose the fact that is routinely elided
remains mystifying.

The nature of the breakage is the subject of debate not the extent to
which it works or not.

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 11 Sep 2011 11:00:44 -0700

> I'll note specifically sections 2.1.2, 2.1.3, 3.3, 4.1.3, 4.2.2 as areas where this is unclear or conflicting.

2.1.2 strikes me as implausible... not only case the space be assumed to
be used internal once allocated but it's simply not big enough to
allocate non-overlapped extranets out of. We have this problem already
with RFC-1918 net-10 and it's 4x that size. It also by definition
extends the application of the space beyond service providers which
other parts of the docuement 4.1.3 5.1.1 discourage.

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Sep 2011 20:14:25 +0200

> be used internal once allocated

but it will be a great betting pool how many seconds until it is used
for other means

randy

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 11 Sep 2011 15:04:19 -0400

On 11-09-11 2:00 PM, "Joel jaeggli" <[email-masked]> wrote:

>with RFC-1918 net-10 and it's 4x that size.
>

This is actually a real problem. To overcome overlaps of RFC1918 space
between many large enterprises (as an example) operators need to deploy
global space such that overlap does not occur.  Using global space is a
poor use of this valuable resource that should be used for Internet
hosts/endpoints.

Again, the problem with using RFC1918 is assuring non-overlap since most
organizations already use this space (all parts in aggregate).

So this is not about the number of addresses, but that fact that it
overlaps.

> It also by definition

Section 4.1.3 describes why the potential for "mis-use" is not a valid
argument to not assign shared space.  The above example is not considered
mis-use, therefore not conflicting.

Section 5.1.1 speaks to the history of this request and the need for this
type of address space. The use for extranet purposes (operating assigning
addresses to customer network facing interfaces) would still fit the
intent of the space as operators can use it to better utilize addresses
helping IPv6 transition (which includes IPv4 connectivity)

5.1.1 Quote (Par 2)
"Rather, the Shared Transition Space is reserved for more narrow
   deployment scenarios, specifically for use by SPs to meet the needs
   of ongoing IPv4 connectivity during the period of IPv6 transition."

Regards,

Victor K

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 11 Sep 2011 12:14:28 -0700

On 9/11/11 12:04 , Victor Kuarsingh wrote:
> This is actually a real problem.

you won't find be arguing that this is not a real problem.

Thing is i'm not a service provider by the denfitions used in this doc
or by arin's definition either, I have order of magnitude 10,000 /25
prefixes (per datacenter). when I do an partner integration that
involves backend integration of addressing resources I have a big
problem. when that partner is amazon/savvis/rackspace etc so do they.

> To overcome overlaps of RFC1918 space

the question is is that an appropriate use of a shared service provider
block it runs contrary to some of the other language about appropiate
use of the prefix.

if the prefix is allocated I can assure you that we'll use it for this
purpose whether it's approiate or not, whether that impacts it's utility
for service providers is I gues left as an exercise for the reader.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Sep 2011 09:23:39 +1200

On 2011-09-12 05:53, Joel jaeggli wrote:
...
> The nature of the breakage is the subject of debate not the extent to

My understanding is that many CPE NATs, being implemented by hacks rather
than as genuine NAT routers, cannot deal with the same RFC 1918 prefix
being subnetted on both sides of the NAT. In other words if the customer
is using Net 10 and the ISP is using Net 10, even in non-overlapping
subnets, the NAT breaks. And of course they all break if 10.1.1.1 is
present on both sides.

This can only be fixed by expensive help desk calls explaining how to
reconfigure the subscriber's Linksys, D-Link, etc. box.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Sep 2011 23:44:04 +0200

> poor use of this valuable resource that should be used for Internet

so let's create more private space to increase this problem.  brilliant.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Sep 2011 23:45:59 +0200

> My understanding is that many CPE NATs, being implemented by hacks
> rather than as genuine NAT routers, cannot deal with the same RFC 1918
> prefix being subnetted on both sides of the NAT. In other words if the
> customer is using Net 10 and the ISP is using Net 10, even in
> non-overlapping subnets, the NAT breaks. And of course they all break
> if 10.1.1.1 is present on both sides.

and this will even be more fun when a kinky nat/pnp, some algs, ...
think they found public space on the 'outside' and it is not really
public space.

randy

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 12 Sep 2011 01:11:36 -0700

On 9/11/11 14:23 , Brian E Carpenter wrote:
> subnets, 

if the subnets don't overlap why  would it break? even the jankiest
router I've seen can cope so long at the route you hit is on your way to
it's destination is default.

> the NAT breaks. And of course they all break if 10.1.1.1 is
> present on both sides.

so long as translation is done prior to forwarding that's not true. that
said I see no reason to temp fate, since there are plently of
(non-linux) cpe that don't do it that way.

> reconfigure the subscriber's Linksys, D-Link, etc. box.

actually no, for the home cpe case it can be fixed by having two pools
in a region (lets call them 10/8 and 172.16/12 . if a modem doesn't work
in one pool it'll work in the other. that's one support call which is
probably less onerous, that the one where I provided the mac address of
my new cable modem to the comcast tech so he could update radius. the
trouble shooting of this case is not  exotic.

consumer cpe aren't going to use two prefix ranges without manual
intervention, enterprises are another matter.

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 12 Sep 2011 08:15:15 -0400

> trouble shooting of this case is not  exotic.

So every gateway must have an entry in the DHCP server pointing to 
which pool to use?  Doesn't scale.

> intervention, 

Which doesn't scale.

Lee

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 12 Sep 2011 07:10:45 -0700

> which pool to use?  Doesn't scale.

every cable modem and stb has any entry in a database and that scales
just fine. these are just the exceptions.

>> consumer cpe aren't going to use two prefix ranges without manual

reread what I said. I don't have to worry about it because it'll be rare
enough to be irrelevant. (a device with more than one address range
collision)

---

From: [email-masked]
Date: Mon, 12 Sep 2011 15:51:12 -0400

+1

I would also support the text of the draft if: 
- Any dependency to draft-weil is removed
- Cases for other uses (i.e. 2.1.2 and 2.1.3, as pointed out by Wesley) 
are removed, they seem to strongly contradict 4.1.3 and the idea of the 
draft. Even if the space will probably be used for other purposes, there's 
no need to document them (DSBUYN). 

/JF

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Sep 2011 08:59:43 +1200

> it's destination is default.

Because the boxes in question *are not routers*. They are basically
hacked bridges where the layer 2 code peeks at the IP header.
They don't do proper subnetting.

I seem to remember Shin Miyakawa explaining this at the Dublin IETF.

   Brian

> (non-linux) cpe that don't do it that way.

I don't see how any system can work in which 10.1.1.1 sends packets
to 10.1.1.1. True, it's not the NAT that breaks, because the packet
never even gets there.

C:\Documents and Settings\brian>tracert 10.1.1.1

Tracing route to bc [10.1.1.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  bc [10.1.1.1]

Trace complete.

> in one pool it'll work in the other. 

If you can auto-detect that, it would be fine.

    Brian

that's one support call which is

---

From: David Farmer <[email-masked]>
Date: Mon, 12 Sep 2011 16:46:19 -0500

I also support the changes Wes George is suggesting as long as they can 
be incorporated without significant delay in moving 
draft-weil-shared-transition-space-request forward.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 14 Sep 2011 08:47:54 -0600

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Owen DeLong
> Sent: Sunday, September 04, 2011 2:50 AM
 
> I fully support the draft. (Would be silly to be a co-author if I did not).

[CLG]   +1