Wes,
:
- what types of impacts may be felt by the rest of the network (not the ISP
that is deploying NAT444)
- what kinds of application practices may be affected
- what IETF specifications may need revision due to this (e.g., do we need to
revise ICE etc)
Jari -
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.
To respond to your concerns and recommendation, I think that there are three
separate issues here that merit some discussion:
1) Does IETF recommend the practice of inferring address scope in IPv4 based on
address/bit value (the actual numbers), and then using this to trigger
different behavior based on that inferred scope?
We could probably have varying opinions on this, but I think the reality is
that software *does* depend on specific bit values, for better or worse. I
propose we spend our effort elsewhere, we can't change the situation.
2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as
additional private-scope use cases?
My personal concern was with making the impacts clear, but I think other people
in the IESG have commented on the updates aspect. I personally think it would
be useful if draft-weil updated RFC 1918, because then when someone looks up
RFC 1918 from the web site they would see the Updates: header and go read the
new RFC as well.
3) Independent of consensus on the state of the *draft* directing it to happen,
is there consensus on the *idea* that the /10 of IPv4 space should be reserved
as shared transition space?
My own opinion on each question:
1) We do link the scope and bit values pretty closely in IPv6. Multicast (Class D) is definitely a scope
link, and RFC6250 doesn't say otherwise, though it would have been a recent opportunity to clarify our
position. My sense is that there are a number of standards (notably 3056) that recommend specific behavior
when private-scope or non-unique addresses are used, but the terms "behind a NAT", "RFC1918
addresses" and "private addresses" are often used interchangeably, thus reinforcing this link
between scope and value. However, draft-bdkgs section 4.1.2 implies that this is not a valid assumption to
make, but your concerns over what breaks and how to test support the idea of a link, which is why I bring up
the question.
I think that it might be useful to formalize this link, but I'm not sure if
that belongs in these drafts, and I don't think that it's gating to them moving
forward.
2) I really believe that one or both drafts should either be an update or -bis
document for RFC1918. I believe that they are in essence documenting additional
use cases for private scope address that are beyond what was covered in
RFC1918, with the added requirement that they cannot conflict with the existing
space. While the address space and use cases are not interchangeable for
reasons documented in draft-bdgks, most of the same considerations regarding
usage (how not to break things) apply to both. Formally updating RFC1918 would
at least give implementers a warning that there is new space to test for
wherever 1918 is referenced in an existing standard and should therefore
address your concern.
Based on your proposal, if we don't formally update 1918, we end up having to go through existing
standards to find places where the authors used RFC1918 interchangeably with "non-unique
addresses" or "private-scope address space". We would then have to evaluate if they
used this as an indicator to recommend a different behavior in cases where one can infer the
address scope based on the bit value and decide whether those cases apply to this new space or not.
I think that using 1918 as a baseline and only documenting items which are unique considerations
for this space and application represents a lot less work than what you're proposing above, whether
it's part of this draft or its own work.
3) The reason I bring up consensus for the idea rather than the document is
that there seems to be some urgency behind getting *something* approved to make
the allocation happen, but it seems to be driving this strange behavior to push
through incomplete documents and sort out the details in subsequent drafts.
Assuming that it is in fact necessary to get the allocation completed rapidly,
I'd rather see us split the logistics of making that happen from the process
required to produce consensus documents. This may be as simple as IAB or IESG
giving ARIN (and/or IANA) provisional clearance to allocate or reserve the
space on the belief that there is consensus to make the reservation, but that
we want our documentation in order before it is made public for use. That
removes any pressure to push the documents through before they are ready, while
still ensuring that the address space is available when we are happy with the
documentation. If for some reason the document fails to achieve consensus in
its final form, there's no harm in then telling ARIN that they must release the
reservation.
Additionally, if we're talking about pushing draft-weil back for that much
analysis, we're now talking about a non-trivial delay, and in that case it may
make sense to simply put the two drafts back together since weil was supposed
to go through quickly as a minimal draft with bdgks being the one that the
community spent more time on to ensure completeness and consensus.
Interesting thoughts. We discussed some of that in the IESG as well. For what it is worth, what I
am asking should not be a long piece of text or require a huge amount of analysis. Basically, it
should state that the effects are <here> and that these undesirable <implications>
may be seen, and that <this type of IETF specifications> need revision. Making those actual
revisions should be done in separate documents. We would only need a significant time if we
decided that we are unsure if we want to make this allocation, and wanted to do research to
understand the failure likelihoods of different options. (I'm personally in that camp, but I
think I may be in the rough and/or it is too late to do it properly anyway.)
But if we are unsure and somehow asked ARIN to make the reservation anyway, the
address space would already be nailed down, the knowledge of the actual usable
space would leak and everyone would be using it anyway.
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf