Notes below. On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick <[email protected]> wrote:
> ** > Daryl, > > 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 > this purpose. > > pr > > 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 the street. regards, Ted > > 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. > > > Daryl > > > On 30 November 2011 20:52, Brian E Carpenter > <[email protected]>wrote: > >> 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/> > <http://www.qualcomm.com/%7Epresnick/> > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
