On 7/27/2012 2:03 PM, Dan Wing wrote: >> -----Original Message----- >> From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On >> Behalf Of Wesley Eddy >> Sent: Thursday, July 26, 2012 11:34 AM >> To: sarik...@ieee.org >> Cc: Internet Area; Behcet Sarikaya >> Subject: Re: [Int-area] Completion of working group last call for >> draft-ietf-intarea-nat-reveal-analysis-02 >> >> On 7/26/2012 1:08 PM, Behcet Sarikaya wrote: >>> On Thu, Jul 26, 2012 at 3:25 AM, <mohamed.boucad...@orange.com> >> wrote: >>>> Dear Suresh, all, >>>> >>>> After reading received comments, the major point we need to discuss >> is whether the WG wants to remove Section 3.3 or maintain it. I'm >> waiting for a feedback from the WG for the direction to take. I will >> implement any change requested by the WG. >>>> >>> >>> Section 3.3 seems to give preference to one specific solution, as >> such >>> it is against the whole spirit of this document. >>> >>> I suggest removing it. >>> >> >> >> +1 >> >> In fact, I suggest that the draft should clearly say that it's >> doubtful whether a solution actually *needs* to be identified and >> recommended, especially ones that are implemented awkwardly in other >> layers. > > I can't make technical sense of which of the 8 approaches are "awkward," in > your analysis. I have my own analysis, but the document does not do an > evaluation on "awkwardness". > > > The underlying problem was identified in Section 13.1 "Abuse Logging and > Penalty Boxes" of RFC6269, "Issues with IP Address Sharing", > http://tools.ietf.org/html/rfc6269#section-13.1. That was an INTAREA > document. > > Hence, that is why the analysis document is also an INTAREA document. > > > My view is the penalty box problem described in Section 13.1 of RFC6269 is > real. My view is the penalty box problem will continue to grow so long as > there are IPv4-accessible servers and so long as there are IPv6 clients > (NAT64) or IPv4 clients accessing those IPv4 servers. There appear to be > different views on the size and trajectory of the problem (getting worse > versus getting better). Perhaps discussing those views would be beneficial. >
Hi Dan - The problem is real because there are bits of deployed code built on an assumption that was good maybe 12 years ago, that IP addresses could be tied to users or machines. Since this is totally broken now, the solution is to get rid of them and use the proper identifiers for whatever it is that these system are trying to do. Building kludges in other layers to supplement the IP address is not the answer. Since the analysis in the document already indicates that each of the 8 solutions has non-starter properties to them, I consider that to make them pretty "awkward". Recommending any of them is like saying "this is the best tasting crap we could find." -- Wes Eddy MTI Systems _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
