I would echo Robert's comments. The draft poses a workable solution to a real problem faced by the operators (me) in dealing with the reality of CGN logging and management.
I would say this is especially important for Mobile given the large hole that environment has dug with respect to the number of devices behind big NATs with a necessity to keep it going longer then we have hoped. Feedback to the author team previously sent. Regards, Victor K From: "Flaim, Robert" <[email protected]> Date: Thu, 24 Jan 2013 12:58:46 -0500 To: "[email protected]" <[email protected]> Subject: [OPSAWG] Deterministic Logging Chris Donley's draft is significant in that is will help minimize logging for attribution purposes in cases of abuse, fraud and malfeasance. It will greatly aid the Operational Security community. Dear Opsawg, We have posted an updated version of our Deterministic CGN draft, which describes a way to significantly reduce or eliminate CGN logging while providing traceability for abuse response. We'd appreciate your feedback. We'd also like to request adoption as a WG item. Thanks, Chris -- Chris Donley CCIE, CISSP, SCiPM Director - Network Technologies CableLabs® 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) On 1/12/13 8:36 AM, "internet-drafts at ietf.org" <internet-drafts at ietf.org> wrote: > >A new version of I-D, draft-donley-behave-deterministic-cgn-05.txt >has been successfully submitted by Chris Donley and posted to the >IETF repository. > >Filename: draft-donley-behave-deterministic-cgn >Revision: 05 >Title: Deterministic Address Mapping to Reduce Logging in Carrier >Grade >NAT Deployments >Creation date: 2013-01-12 >WG ID: Individual Submission >Number of pages: 15 >URL: >http://www.ietf.org/internet-drafts/draft-donley-behave-deterministic-cgn- >05.txt >Status: >http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn >Htmlized: >http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-05 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-donley-behave-deterministic-cgn-05 > >Abstract: > In some instances, Service Providers have a legal logging requirement > to be able to map a subscriber's inside address with the address used > on the public Internet (e.g. for abuse response). Unfortunately, > many Carrier Grade NAT logging solutions require active logging of > dynamic translations. Carrier Grade NAT port assignments are often > per-connection, but could optionally use port ranges. Research > indicates that per-connection logging is not scalable in many > residential broadband services. This document suggests a way to > manage Carrier Grade NAT translations in such a way as to > significantly reduce the amount of logging required while providing > traceability for abuse response. While the authors acknowledge that > IPv6 is a preferred solution, Carrier Grade NAT is a reality in many > networks, and is needed in situations where either customer equipment > or Internet content only supports IPv4; this approach should in no > way slow the deployment of IPv6. > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
