Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt

Indeed, SLAAC is showing up primarily in environment instrumentation (sensors) and sometimes in the DC for server provisioning coupled with dynamic DNS.

It is a good catch besides RA Guard (http://tools.ietf.org/html/rfc6105), a feature in big demand by enterprise customers.

Tina

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
> Hemant Singh (shemant)
> Sent: Wednesday, January 25, 2012 1:57 PM
> To: Warren Kumari; IPv6 Operations
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt
> 
> Warren,
> 
> Thanks.  I support the document to move forward to the IESG.
> 
> Hemant
> 
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Warren Kumari
> Sent: Wednesday, January 25, 2012 3:48 PM
> To: IPv6 Operations
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt
> 
> This simply folds in the comments that folk sent to the list during
> WGLC.
> 
> W
> On Jan 25, 2012, at 3:16 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 IPv6 Operations Working
> Group of the IETF.
> >
> > 	Title           : Operational Neighbor Discovery Problems
> > 	Author(s)       : Igor Gashinsky
> >                          Joel Jaeggli
> >                          Warren Kumari
> > 	Filename        : draft-ietf-v6ops-v6nd-problems-03.txt
> > 	Pages           : 13
> > 	Date            : 2012-01-25
> >
> >   In IPv4, subnets are generally small, made just large enough to
> cover
> >   the actual number of machines on the subnet.  In contrast, the
> >   default IPv6 subnet size is a /64, a number so large it covers
> >   trillions of addresses, the overwhelming number of which will be
> >   unassigned.  Consequently, simplistic implementations of Neighbor
> >   Discovery (ND) can be vulnerable to deliberate or accidental denial
> >   of service, whereby they attempt to perform address resolution for
> >   large numbers of unassigned addresses.  Such denial of attacks can
> be
> >   launched intentionally (by an attacker), or result from legitimate
> >   operational tools or accident conditions.  As a result of these
> >   vulnerabilities, new devices may not be able to "join" a network, it
> >   may be impossible to establish new IPv6 flows, and existing IPv6
> >   transported flows may be interrupted.
> >
> >   This document describes the potential for DOS in detail and suggests
> >   possible implementation improvements as well as operational
> >   mitigation techniques that can in some cases be used to protect
> >   against or at least alleviate the impact of such attacks.
> >
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.tx
> t
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> >
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops