> -----Original Message----- > From: Wesley Eddy [mailto:w...@mti-systems.com] > Sent: Saturday, July 28, 2012 12:28 AM > To: Dan Wing > Cc: sarik...@ieee.org; 'Internet Area'; 'Behcet Sarikaya' > Subject: Re: [Int-area] Completion of working group last call for > draft-ietf-intarea-nat-reveal-analysis-02 > > 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.
During the INTAREA presentation, one suggestion I heard was a separate protocol (ident-like). I will submit an I-D towards that end, which I am dusting off from 2010 when I first considered ident and discarded it for a variety of reasons. Do you have additional suggestions on how to accomplish convey an identifer? > Building > kludges in other layers to supplement the IP address is > not the answer. We do have a long history of crossing layers, as much as we pretend we don't do that -- ARP, IPv6 changing UDP checksum requirements compared to IPv4, incorporation of IP addresses for referrals in dozens of protocols (partially due to lack of a name service). > 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." Yeah, awkwardness happens a lot with address sharing. I also wish it was different. -d _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
