Subject: FW: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 11 Oct 2012 21:28:59 -0400

Hello:

The co-authors have submitted the draft-chakrabarti-nordmark-6man-efficient-nd-00.txt(see below) as a follow-up from  
https://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-02 after incorporating comments received from 6man and int-area working groups.

The outline of changes are:

- Objective is now to have an efficient ND  ( rather than only energy-efficient)
- Added clarifications on interactions with DHCPv6, ND-Proxy and DNA implementations
- Clarified Duplicate Address detection 

The document addresses both legacy IPv6 and efficient IPv6 ND compliant nodes in "mixed-mode".
It supports beahvior of sleepy nodes using node registration.

Thanks,
-Samita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 11, 2012 5:50 PM
To: Samita Chakrabarti
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-00.txt

A new version of I-D, draft-chakrabarti-nordmark-6man-efficient-nd-00.txt
has been successfully submitted by Samita Chakrabarti and posted to the IETF repository.

Filename:	 draft-chakrabarti-nordmark-6man-efficient-nd
Revision:	 00
Title:		 Efficiency aware IPv6 Neighbor Discovery Optimizations
Creation date:	 2012-10-12
WG ID:		 Individual Submission
Number of pages: 26
URL:             http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficient-nd-00.txt
Status:          http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-nd
Htmlized:        http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-00

Abstract:
   IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
   neighbor's address resolution, unreachability detection, address
   autoconfiguration, router advertisement and solicitation.  With the
   progress of Internet adoption on various industries including home,
   wireless, m2m and Cellular(LTE) networks, there is a desire for
   optimizing legacy IPv6 Neighbor Discovery protocol to be more
   efficient in terms of number of signaling messages in the network.
   This document describes a method of optimization by reducing periodic
   multicast messages, frequent Neighbor Solicitation messages and
   supports interoperability with legacy IPv6 nodes and avoids Duplicate
   Address Detection by introducing an address Registration mechanism.
   Efficient IPv6 Neighbor Discovery protocol is useful for energy-
   efficient IPv6 networks as well as Data Center and Home Networks.

The IETF Secretariat

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Oct 2012 08:23:37 +0200

Two quick comments:

-- this still uses 10 seconds as a scaler for the ARO registration lifetime. 6LoWPAN-ND used to use 10, but now uses 60 seconds.
-- I'm not too wild about the E-bit.  Maybe we should extract the 6CIO from draft-bormann-6lowpan-ghc and use this?

The two areas in which I think this proposal can benefit from some more discussion:

Clearly, mitigating the external ND table DoS is one of the major pain points addressed by this.  Thinking point: Is there any way to structure the transition from legacy ND to efficient ND in such a way that it becomes easier to reap this benefit?

For DC applications, the assumption of uniqueness of the EUI-64 probably requires some more thinking.  VMs get copied all the time, and it is way too easy to copy this kind of config info in the process.

Grüße, Carsten

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 12 Oct 2012 16:41:40 -0700 (PDT)

Hi,

----- Original Message -----
> From: Carsten Bormann <[email-masked]>
> To: Samita Chakrabarti <[email-masked]>
> Cc: 6man Mailing List <[email-masked]>
> Sent: Friday, 12 October 2012 5:23 PM
> Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt
> 
>T wo quick comments:
> 
<snip> 

> Clearly, mitigating the external ND table DoS is one of the major pain points 
> addressed by this.  Thinking point: Is there any way to structure the transition 
> from legacy ND to efficient ND in such a way that it becomes easier to reap this 
> benefit?
>
 
I've been thinking about a registration protocol recently, which would have
leveraged the MLDv2 election process at router interface connection  to
discover existing nodes' link local addresses, Inverse Neighbor Discovery
to query the nodes' for their other addresses (other LLs, ULAs, GUAs),
DAD to detect new nodes/addresses, and NUD to detect when nodes/addresses
disappear. The drawback as you indirectly point out is that it requires
all nodes to support the registration protocol before it can be enabled
and the DoS mitigated. So I worked on the following draft first, which
I think mitigates the DoS for routers, and only requires changes to
routers' neighbor discovery operation:

"Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery"

http://tools.ietf.org/search/draft-smith-6man-mitigate-nd-cache-dos-slnd-00

I've got a new update nearly finished, which I'll post later today.

I definitely think a registration protocol is necessary. While working on
the above draft, I realised that on-link sources can also cause the off-link
neighbor cache DoS, by using spoofed non-existent source addresses from
within the local subnet, and sending that traffic to a remote host that
sends replies back (e.g. lots of spoofed source addressed outgoing TCP SYNs, reply
TCP SYN/ACKs would cause the neighbor cache DoS attack on the router). A
registration protocol would allow individual address-based rather than just prefix level
BCP38 protection, because routers now know exactly what devices exist
on-link, and can therefore drop traffic with spoofed local subnet source addresses.

Regards,
Mark.