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

[Benson Schliesser <[e-mail]>]

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

>> It's unclear from your statement if you're proposing adding the above to this
>> draft or to a subsequent draft.
> 
> Sorry. I think this should be a part of draft-weil. I think we'll end up
> making further work in this space (e.g., if some RFC needs an update then the
> actual update should probably be in another document) but I would like to see
> the high level impacts documented here.

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

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

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

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

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

>> 2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as
>> additional private-scope use cases?
> 
> My personal concern was with making the impacts clear, but I think other
> people in the IESG have commented on the updates aspect. I personally think it
> would be useful if draft-weil updated RFC 1918, because then when someone
> looks up RFC 1918 from the web site they would see the Updates: header and go
> read the new RFC as well.

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

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

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

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

Cheers,
-Benson