Owen,
Can I get some pointers to where your comments on the first point are targeted? (I see reference to DHCP-PD and 6RD). As for Section 6, there point was related to IANA special considerations. Trying to make sure I understand the feedback. Thanks, Victor K On 2013-02-18 4:07 PM, "Owen DeLong" <[email protected]> wrote: >I have some concerns about this draft > >1. While the author explains that DHCP-PD and 6rd lack this capability, > he does not justify that the capability is needed or explain why > it is needed. I would like to see a better explanation of the > use case for this feature. > >2. Section 6 claims there are no additional considerations. I don't >agree. > > I see no reason this new ICMP type could not be used by attackers > to gain information about the internal topology of dynamically > assigned networks. Since many of these are likely to include poorly > administered gateways in the residential, SOHO, and SMB realms, > I believe this consideration should be covered in the draft. > > This additional disclosure risk is not covered in RFC4443 (ICMP6) > >Owen > >On Feb 18, 2013, at 12:46 PM, [email protected] wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Operations and Management Area Working >>Group Working Group of the IETF. >> >> Title : CGN Deployment with BGP/MPLS IP VPNs >> Author(s) : Victor Kuarsingh >> John Cianfarani >> Filename : draft-ietf-opsawg-lsn-deployment-02.txt >> Pages : 18 >> Date : 2013-02-18 >> >> Abstract: >> This document specifies a framework to integrate a Network Address >> Translation layer into an operator's network to function as a Carrier >> Grade NAT (also known as CGN or Large Scale NAT). The CGN >> infrastructure will often form a NAT444 environment as the subscriber >> home network will likely also maintain a subscriber side NAT >> function. Exhaustion of the IPv4 address pool is a major driver >> compelling some operators to implement CGN. Although operators may >> wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near >> term needs may not be satisfied with an IPv6 deployment alone. This >> document provides a practical integration model which allows the CGN >> platform to be integrated into the network meeting the connectivity >> needs of the subscriber while being mindful of not disrupting >> existing services and meeting the technical challenges that CGN >> brings. The model included in this document utilizes BGP/MPLS IP >> VPNs which allow for virtual routing separation helping ease the CGNs >> impact on the network. This document does not intend to defend the >> merits of CGN. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-lsn-deployment-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OPSAWG mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg > >_______________________________________________ >OPSAWG mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
