ietf
[Top] [All Lists]

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-12-01 21:49:36
On 12/1/11 4:27 PM, Ted Hardie wrote:

On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick <presnick(_at_)qualcomm(_dot_)com <mailto:presnick(_at_)qualcomm(_dot_)com>> wrote:

    The problem described in the draft is that CPEs use 1918 space
    *and that many of them can't deal with the fact that there might
    be addresses on the outside interface that are the same as on the
    inside interface*. The claim was made by [Robert], among others,
    that only 192.168/16 space was used by such unintelligent CPEs. I
    believe I have seen the claim that 10/8 space is also used in
    unintelligent equipment that can't deal with identical addresses
    inside and outside. Is there reason to believe that within the ISP
    network / back-office etc. that there is equipment that can't deal
    with 17.16/12 space being on both the inside and outside? I
    haven't seen anyone make that specific claim.

    If we know that 172.16/12 used both inside and outside will break
    a significant amount of sites that CGNs will be used with, we can
    ignore this argument. But if not, then let's rewrite the document
    to say that CGNs should use 172.16/12 and that any device that
    wants to use 172.16/12 needs the ability to deal with identical
    addresses on the inside and the outside interface. Of course, all
    equipment should have always been able to deal with identical
    addresses inside and outside for all 1918 addresses anyway. But if
    we think the impact of using 172.16/12 for this purpose will cause
    minimal harm, then there's no compelling reason to allocate new
    space for this purpose.


I wrote a response to Brian's original statement then deleted it because I assumed others would ignore it as clearly last minute and ill-researched. Apparently, that was wrong. There are enterprises that currently use 172.16/12. (There are enterprises which use every tiny piece of RFC 1918 space.)

Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172.16/12 (and, for that matter ever bit of 1918 space). That's irrelevant and still does not address my question. The question is whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE. I am happy to accept an answer of, "Yes, all 1918 address space is used by such equipment", but nobody, including you, has actually said that.

*Any* piece of the current RFC 1918 space you attempt to define as being used for this will conflict *somewhere*. Anyone who happened to chose this for an enterprise deployment and gets stuck behind a CGN would be forced to renumber, in other words, because of this statement.

That statement does not logically follow from "all 1918 address space is used". You are missing a premise: "There exists equipment that is used in all of that space that can't handle identical addresses on the interior and exterior interface."

The current draft says that the reason 1918 space can't be used is that equipment that deals in 1918 address space is hosed if 1918 addresses are used on their external interface. Brian claimed that perhaps 172.16/12 space might not be used by that equipment. Robert claimed that perhaps only 192.168 and 10.0.0.x addresses are used by that equipment. So the question I posed was, "Does any of *that* equipment use 172.16/12 (or 10.x/16) space?" Nobody has said "yes".

And *I'm* still not claiming that the answer is "No." I simply don't know. But I'm inclined to hear from anybody to indicate that there is *any* evidence that the answer is "Yes". That would make me much more comfortable in concluding that new specialized address space is the better horn of this bull to throw ourselves on.

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
<Prev in Thread] Current Thread [Next in Thread>