Subject: Re: Submitted draft-chakrabarti-nordmark-6man-efficient-nd-04.txt

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Dec 2013 10:00:12 +0100 (CET)

Reading this document first time, I haven't read any previous discussion 
on it so I might be re-iterating views.

There is a typo in 1.2, "enahnced". You're talking about EUI-64 addresses, 
aren't we deprecating them right now in another draft? If this refers to 
L2 only somehow, it should probably be more explicit that this is the 
case.

3. "All nodes are single IPv6-hop away from their default router in the 
subnet". I don't understand this sentence. Either they are adjacent (have 
L2 connectivity) or they have not. Talking about "single IPv6 hop away" 
makes me confused. "/64-bit" is a strange notation to me. I would 
recommend rephrasing to "IPv6 /64 prefix".

11.1 Shouldn't it be explicit here that a NEAR router should drop all 
packets to unknown destinations in case of non-mixed or legacy mode (what 
is this mode called? Energy-efficient mode? Acronym?)

13. Can a host register multiple addresses?

17.3 "default-rotuer", wrong spelling. How does the DHCP server inform the 
DHCP requestor about "default-router capability"? I don't understand this.

Other thoughts:

Shouldn't the L2 forwarding charateristics be specified somewhere? For 
instance SAVI standards ramifications (if any) by the changes proposed?.

On Mon, 21 Oct 2013, Samita Chakrabarti wrote:

> Submitted a  slightly modified version (04) of Efficient-nd based on further input on version 03 :
>
> --  Added a place holder section on VRRP interaction [ Co-authors to discuss further on this topic proposed by Mark ZZZ Smith]
> --  Clarified that the NEAR router can deny registration if the neighbor cache is full
> --  Clarified  EAH (host) behavior on registration denial.
>
>
> Thanks,
> -Samita
>
>
>
> URL:             http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficient-nd-04.txt
>
>
> 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 networks there is a desire for optimizing
>   the legacy IPv6 Neighbor Discovery protocol.  This document describes
>   a method of optimization by reducing multicast messages and
>   introducing an IPv6 address Registration mechanism.  The optimization
>   of IPv6 Neighbor Discovery protocol is useful for Wirless and low-
>   power IPv6 networks and as well as Data Centers and Home Networks.
>   The solution is capable of handling existing legacy IPv6 nodes in the
>   network with local mobility.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
Mikael Abrahamsson    email: [email-masked]