Thanks for your response, mine is below, with snipping. On 02/10/2012 19:19, Pete Resnick wrote: > 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. I'm sorry, I was trying to be concise in order to not re-open the debate on the topic of "should," but your response indicates that you're not seeing my point. The premise of this draft is that a new block is necessary because the same prefixes can't be used in the customer network and the CGN layer. So, let's allocate a new block to use *only* in the CGN layer. That way it can never conflict. My point is that no matter how loudly you say, "Don't use this as 1918 space!" some users will do it anyway. There have already been several requests for more IPv4 1918 space because a non-zero number of end user networks have run out. So we know that people *will* use this new block internally. Therefore we can be fairly certain that at some point there will be a conflict. That means that there is no reason to allocate this new block. > But if new folks start > using Shared Address Space without NATing it properly, they've only got > themselves to blame. That's interesting ... so you're saying that the people who created the problem should be responsible for dealing with their own mess? :) More seriously, you seem to be saying that because the draft says "Don't do it" it's Ok for us to do the allocation because if someone does screw up it's not our fault because we told them not to do it. My point is that because we can see the trap, we shouldn't walk right into it with a smile on our face. > If the text is not clear, please help. I don't think any amount of text-twiddling can help, since I feel that this is a bad idea from the ground up. > 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. Yes, that's been *said* multiple times, but it hasn't been backed up with solid data. OTOH, numerous people (many of whom are in a much better position to know than I am) have pointed out that the overwhelming majority of consumer CPE devices use one of 192.168.[01] as their internal networks. That number is likely to be in the 80% range, if not much higher. Therefore it's very likely that most of this problem is solved already if the ISPs simply stay away from those 2 ranges. What I, and others, have said repeatedly now is that given how easy most of this problem is to solve, the people who have a fiduciary interest in solving the rest of it should do so, without asking the rest of the Internet to subsidize their (arguably flawed) business model. Or put more simply, if the problem is that CPEs don't know how to deal with the same block on the inside and outside, there are (at least) 2 ways for the ISPs to solve that which do not involve allocating a new block. > 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. I appreciate the invitation, but I don't know how much more I can bring to the topic that I haven't already. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf