ietf
[Top] [All Lists]

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

2011-09-22 16:10:24
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Jari Arkko
Sent: Thursday, September 22, 2011 2:35 PM
To: ietf(_at_)ietf(_dot_)org; 
draft-weil-shared-transition-space-request(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> 
(IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

So here's what I would like to propose. The document goes forward but we make a 
much clearer statement with regards to the implications both for applications 
out there, as well as for subsequent IETF work:

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

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?

2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as 
additional private-scope use cases?

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.

Thanks
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>