Subject: Fwd: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Feb 2014 23:03:56 -0800

Samita has already outlined some of the changes we have been making 
based on the feedback from the list.

In addition this version has significant editorial changes based on the 
feedback, and also more detail for the host and router behavior.

It also addresses some additional technical issues that have been 
raised, notable how it works with VRRP and the routers being a SPoF. 
Those are handled with a new Registrar Address Option which can be 
included in RAs.

     Erik

-------- Original Message --------
Subject: 	New Version Notification for 
draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
Date: 	Fri, 14 Feb 2014 15:57:34 -0800
From: 	[email-masked]
To: 	Pascal Thubert <[email-masked]>, Erik Nordmark 
<[email-masked]>, Pascal Thubert <[email-masked]>, Margaret 
Wasserman <[email-masked]>, Samita Chakrabarti 
<[email-masked]>, Erik Nordmark <[email-masked]>, 
Samita Chakrabarti <[email-masked]>, Margaret Wasserman 
<[email-masked]>

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

Name:		draft-chakrabarti-nordmark-6man-efficient-nd
Revision:	05
Title:		IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks
Document date:	2014-02-14
Group:		Individual Submission
Pages:		35
URL:            http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
Status:         https://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-nd/
Htmlized:       http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-chakrabarti-nordmark-6man-efficient-nd-05

Abstract:
    IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined
    at a time when link-local multicast was as reliable and with the same
    network cost (send a packet on a yellow-coax Ethernet) as unicast and
    where the hosts were assumed to be always on and connected.

    Since 1996 we've seen a significant change with both an introduction
    of wireless networks and battery operated devices, which poses
    significant challenges for the old assumptions.  We are also seeing
    datacenter networks where virtual machines are not always on and
    connected, and scaling of multicast can be challenging.

    This specification contains extensions to IPv6 Neighbor Discovery
    which remove most use of multicast and make sleeping hosts more
    efficient.  The specification includes a default mixed mode where a
    link can have an arbitrary mix of hosts and/or routers - some
    implementing legacy Neighbor Discovery and some implementing the
    optimizations in this specification.  The optimizations provide
    incremental benefits to hosts as soon as the first updated routers
    are deployed on a link.

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

---

From: 神明達哉 <[email-masked]>
Date: Thu, 27 Feb 2014 10:28:23 -0800

At Fri, 14 Feb 2014 23:03:56 -0800,

> based on the feedback from the list.

Was this point addressed in 05?

>> Clarify bootstrapping and DAD for link-local or not How to inform duplicate address detection during link-local address formation

Section 11 talks about boot strapping and the formation of a
link-local address, but it doesn't talk about DAD for the LL address.

Section 5 has this bullet:

   o  Address Resolution and DAD uses the registered addresses instead
      of multicast Neighbor Solicitation messages for non-link-local
      IPv6 addresses.

which seems to suggest DAD is used for link-local addresses, but it's
not really clear (and this is not an addition to 05).

Assuming the intent is to perform DAD for the link-local address, I
suggest Section 11 explains that explicitly.  It would also be better
if that point is clarified in Section 8.  And, this point of Section 2
may also have to be updated:

      Remove the use of multicast for DAD and Address Resolution (no
      multicast NS messages), and remove periodic multicast RAs.  Some

so it's clear that DAD is still needed for link-local addresses.

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Feb 2014 22:08:27 +0100

Jinmei,

thanks for reviewing the updated draft.

>>> Clarify bootstrapping and DAD for link-local or not How to inform duplicate address detection during link-local address formation
Not very well it seems. We discovered shortly before the draft cutoff 
that the 6lowpan-nd approach to handling link-locals doesn't make any 
sense in this broader applicability.
Hence we added how to handle link-locals to the open issues section.

But we seemed to not have edited the rest of the draft correctly around 
DAD, including the bootstrapping section.
As the draft currently stands DAD for link-locals is (or "can be" given 
the lack of editorial clarity) replaced by NS/ARO. But address 
resolution for link-local targets needs to be done for using multicast NS.

One of the discussion on list is how to avoid the latter, with 
suggestions to add the ability to have RAs state that link-locals should 
be sent to routers. That might make sense in some deployments (when 
hosts do not depend on protocols with have a ttl=255 check).

    Erik

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Feb 2014 14:53:52 -0800

At Thu, 27 Feb 2014 22:08:27 +0100,

> resolution for link-local targets needs to be done for using multicast NS.

I don't understand how it works in the bootstrap stage.  To send the
NS/ARO for a link-local address (on bootstrap), the host should first
know the registrar's address.  But the host can't get the information
by unicast RS-RA exchange since the source address of the RS would
need to be the link-local address to prove unique.  Or am I
misunderstanding your intent?

--
JINMEI, Tatuya