On 2/10/12 3:57 PM, Doug Barton wrote:
On 02/10/2012 15:42, Pete Resnick wrote:
I expect there will be clarifications as per the earlier messages in
this thread: This is *not* to be used as additional 1918 space.
The following is not meant to be a snark
Not taken as such.
...I think it's a huge problem
that you think *saying* "Don't use this as 1918 space" is going to make
any difference at all.
Neither the text of the current draft nor the proposed text that Brian
and I seem to like says "Don't use this as 1918 space", nor do I think
saying so would be a good idea or make any difference. I apologize that
I was not clear when I said that it "is *not* to be used as 1918 space".
What I meant was that the document should be clear that this so-called
"Shared Address Space" has limitations and can't be used in
circumstances where 1918 addresses can be used. Now, I am under no
delusions that some equipment won't *try* to use this new space in ways
that will cause problems (any more than I think that people won't use
port numbers for non-registered uses, or won't use bogus SMTP protocol
return codes, etc.). But like those situations, folks who want to use
this new address space *don't care* if other people do stupid things
with it; they're making their own beds and they can lie in them.
Remember, the whole purpose of using new address space is that the 1918
space has specific semantics that folks have already implemented and
deployed in equipment *in compliance with the spec* in that they don't
NAT what they consider an "outside" address. If people with current
equipment call and complain when a CGN uses 1918 space and screws up
their equipment, they've got a legitimate beef. But if new folks start
using Shared Address Space without NATing it properly, they've only got
themselves to blame.
The new and suggested text makes this all clear: You can safely use this
non-globally-routeable Shared Address Space so long as you NAT it on
both ends. If you don't, you're going to have routing problems. You want
routing problems? Have at it. I don't care. Like any good IETF spec,
we're just telling you what the rest of us intend to do.
If the text is not clear, please help.
Given that previous requests
for new 1918 space have been (rightly) denied, I think this document
should describe why this request is better/more important than previous
requests, and what the bar will be for future requests for new 1918
space.
I hope it does,
For my money, it does not.
Again, text welcome.
Shared Address Space is similar to [RFC1918] private address space in
that it is not global routeable address space and can be used by
multiple pieces of equipment. However, Shared Address Space has
limitations in its use that the current [RFC1918] private address
space does not have. In particular, Shared Address Space can only be
used on routing equipment that is able to do address translation
across router interfaces when the addresses are identical on two
different interfaces.
So if we're saying the same thing about CPEs capable of doing CGN
needing to understand the same block(s) on the inside and outside, why
is the new block necessary?
I believe this has been said multiple times before (and is not the
subject of this Last Call, AFAICT), but: The new block is necessary
because current equipment, which will be connected to CGNs (or any other
kinds of devices that use this new space), and which conforms to a
reasonable interpretation of 1918, is not able to understand the same
block on the inside and the outside, and therefore will not be able to
route through CGNs (or other such new equipment) if they used 1918
space. Again, if the current text is not clear on this point, please
identify where clarification is needed. (If you disagree with my
assessment, let's please take that conversation offlist and we can
figure out where the disagreement is and maybe bring our collective
wisdom back to the list. And that invitation is to anyone who feels that
they disagree with the above reasoning. You have my email address.)
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf