On 9/22/11 4:59 PM, "Jari Arkko" <jari(_dot_)arkko(_at_)piuha(_dot_)net> 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf