On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick
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 Randy, 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
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.) *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 is,
if they actually followed the statement--they're much more likely to work
with the CGN operator to use squat space on the CGN instead, since that's
the existing way of avoiding this pain.
Rubbing my crystal ball real hard, in other words, I predict that the
consequences of assigning a piece of existing RFC 1918 space to this at
this late date will have the same consequences as assigning no space at
all, with the addition of a tiny increment of confusion among those souls
who happen to read the RFC and briefly think it reflects reality.
Either allocate new space or reject; the middle ground of assuming that
some part of RFC 1918 can be safely allocated for this should not be
considered as an option.
My personal opinion, not that of my employer, spouse, child, or the man on
On 11/30/11 3:04 PM, Daryl Tanner wrote:
It's not just about the CPE devices and customer LANs.
Address conflicts are also going to happen within the ISP network /
back-office etc. 172.16.0.0/12 is used there.
On 30 November 2011 20:52, Brian E Carpenter
On 2011-12-01 09:28, Chris Grundemann wrote:
It is more conservative to share a common pool.
It suddenly occurs to me that I don't recall any serious analysis
of using 172.16.0.0/12 for this. It is a large chunk of space
(a million addresses) and as far as I know it is not used by default
in any common CPE devices, which tend to use the other RFC 1918 blocks.
I realise that ISPs with more than a million customers would have to
re-use this space, whereas a /10 would only bring this problem above 4M
customers, but at that scale there would be multiple CGN monsters anyway.
Sorry to bring this up on the eve of the telechat.
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Ietf mailing list
Ietf mailing list