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-23 12:53:01

On Sep 22, 2011, at 2:10 PM, George, Wes wrote:

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


Whether IETF recommends it or not, it is common practice in CPE today. As such, 
I think we should recognize
and address the reality rather than ignore it in the name of architectural 
purity. However, I am not convinced
that these drafts are the place to address it.

I don't believe the draft says that there is no link so much as we say that 
hard-coding such assumptions and
making the assumption that all other addresses are globally reachable or have 
global reachability is a poor
assumption. This draft doesn't change that fact and no clarification of scope 
linkage would change the fact
that assuming your GUA (or presumed GUA) is globally unique or has global 
reachability is a bad assumption
which is, nonetheless, an assumption built into many residential CPE devices 
today.

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


I don't believe so. I believe that conflating these drafts with RFC-1918 would 
only serve to further increase the
probability that someone would consider this additional space for the same 
purpose. I would not oppose
adding a reference to RFC-1918 that links to these documents as additional 
related considerations.

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?


I believe there is. Further comment below...
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.


There is urgency to make the space available for use, so, the split you 
describe does not actually help. The urgency
is to make this space available before providers start having to deploy NAT444 
without it, or, at this point, more
accurately, to limit the amount of NAT444 deployed using GUA, Squat Space, or 
any of the other alternatives
that these drafts show are a significantly worse alternative vs. this /10 
shared transition space.

Pushing draft weil back as you describe would be extremely harmful IMHO.

Owen

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

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