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, "[email protected]" <[email protected]> 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. > > > > > > >The IETF Secretariat > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
