-----Original Message-----
From: Benson Schliesser [mailto:bschlies(_at_)cisco(_dot_)com]
Sent: Friday, September 23, 2011 1:21 AM
To: Jari Arkko
Cc: draft-bdgks-arin-shared-transition-space(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org;
draft-weil-shared-transition-space-request(_at_)tools(_dot_)ietf(_dot_)org;
George, Wes
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt>
(IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
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. <snip>
However, I would like to make sure we don't lose sight of the need for some
urgency with draft-weil.
WEG] I won't repeat my comments to Owen here, but I will note that if the
concern is about the availability of the address space, my suggestion would
allow us to ensure it's available without any artificial (?) sense of urgency
over getting the documents to a form that we're happy with.
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).
WEG] my thought is that it's useful to say exactly that - this exists, so if
you're going to do it to avoid breakage, know that there's now additional space
to be aware of, especially if we go the route of updating RFC1918. I do
appreciate the clarification of the difference between deriving address scope
based on bit value for defined-scope values vs. assuming that everything not
included in that defined-scope of private space could be unique and global, but
I'm not sure that particular distinction is important in the context of these
drafts. Similarly, the idea that squatting on other GUA space has a similar
problem is mostly interesting as a justification for doing STS instead of
squatting, and so that idea is probably minimally important in the grand scheme
of things.
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.
WEG] Agree, the wording and the distinction between the use cases are
important, but I believe it is possible to articulate it properly. I think that
crispness and clarity is required anyway, in order to clearly explain why these
use cases are not simply solved by use of existing RFC1918 space. BDGKS is
getting there, so let's refine that to address both your concern and mine.
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