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

[Ronald Bonica <[e-mail]>]

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



> -----Original Message-----
> From: George, Wesley [mailto:[e-mail]]
> Sent: Wednesday, September 07, 2011 5:26 PM
> To: Owen DeLong
> Cc: Scott O. Bradner; [e-mail]; draft-weil-shared-transition-
> [e-mail]; draft-bdgks-arin-shared-transition-
> [e-mail]; Ronald Bonica
> Subject: RE: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space
>
> -----Original Message-----
> From: Owen DeLong [mailto:[e-mail]]
> 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.
>
> > 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 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:
> >  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..."
>
> 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.
>
> > 3.5 - you need to coordinate with draft-vegoda-no-more-unallocated-
> slash8s section 4
> >
>
> 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.
>
> > 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.
>
> > 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.
> >
>
> 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.
> ___________
> WEG] no disagreement. I much prefer the way that you make the point
> here to the hyperbole in the draft.
>
> > 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.
> ___________
> 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.