Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]