Re: [OPSAWG] I-D Action: draft-shishio-v6ops-dpvt

Apologies for my earlier mispost. This was actually targeted at the Shishio
draft, not the LSN draft. My concerns are about the IPv6 delegated prefix
verification tool. Thanks to Mister Kauringh for calling my attention to the
error.

Owen

On Feb 18, 2013, at 1:07 PM, Owen DeLong <owen@delong.com> 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, internet-drafts@ietf.org 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
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg