Subject: Next Steps on DAD Improvements

From: Bob Hinden <[email-masked]>
Date: Mon, 8 Jun 2015 13:02:06 -0700

At the 6man WG meeting in Dallas there was discussion on what to do (if anything) about duplicate address detection.  The background on this is documented in https://datatracker.ietf.org/doc/draft-yourtchenko-6man-dad-issues/

Should we work on the robustness and efficiency issues of DAD?  For example, improving DAD in environments where nodes sleep and on links with high packet loss.  We think that DAD robustness and efficiency are intertwined and we need solutions that take both into account.

In case the WG wants to address these issues, there is an outline of how they can be addressed in https://datatracker.ietf.org/doc/draft-nordmark-6man-dad-approaches/.  This is probably not the only way they can be addressed, but the draft indicates that the issues are solvable.

The chair would like your feedback on this issue and if there is interest we will schedule an agenda slot in Prague.

Bob and Ole
6MAN Chairs

---

From: James Woodyatt <[email-masked]>
Date: Tue, 9 Jun 2015 10:28:12 -0700

On Mon, Jun 8, 2015 at 1:02 PM, Bob Hinden <[email-masked]> wrote:

>
> Should we work on the robustness and efficiency issues of DAD?
>

Yes.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jun 2015 11:11:45 +1200

>> Should we work on the robustness and efficiency issues of DAD?

I concur. There are too many loopholes at present.

   Brian Carpenter

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jun 2015 09:45:35 +0900

On Tue, Jun 9, 2015 at 5:02 AM, Bob Hinden <[email-masked]> wrote:

> Should we work on the robustness and efficiency issues of DAD?  For
> example, improving DAD in environments where nodes sleep and on links with
> high packet loss.  We think that DAD robustness and efficiency are
> intertwined and we need solutions that take both into account.
>

What would be the goal of such an exercise?

Reliable duplicate address detection cannot be achieved without giving an
on-link authority that the ability to decide which node gets what address.
Is that what we want?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2015 01:03:00 +0000

Hi:

I'd reword that to "giving a node authority to reject a claim for an address on a link" since your text really talks about a DHCP- like world where nodes get their addresses from servers. Here, the authority does not impose which address gets assigned and autoconf is still doable.

But uniqueness is checked with one particular node in the network as opposed to all nodes on link - this arguably may help reduce openings to bad behaviors.

Getting unique addresses is a pillar for the whole IP architecture and if that's the price to pay I'd say yes, we want the option.

Cheers,

Pascal

Le 9 juin 2015 à 20:46, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> a écrit :

On Tue, Jun 9, 2015 at 5:02 AM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
Should we work on the robustness and efficiency issues of DAD?  For example, improving DAD in environments where nodes sleep and on links with high packet loss.  We think that DAD robustness and efficiency are intertwined and we need solutions that take both into account.

Reliable duplicate address detection cannot be achieved without giving an on-link authority that the ability to decide which node gets what address. Is that what we want?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jun 2015 10:19:08 +0900

On Wed, Jun 10, 2015 at 10:03 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  I'd reword that to "giving a node authority to reject a claim for an
> address on a link" since your text really talks about a DHCP- like world
> where nodes get their addresses from servers. Here, the authority does not
> impose which address gets assigned and autoconf is still doable.
>

I think it's a bit more than that. In order for DAD to be reliable, one
node (or a collection of nodes that share state), needs to know all
addresses on the link, at all times. And a node cannot configure an address
without the authority's approval.

I'm not sure about the statement "autoconf is still doable". The semantics
change substantially, I think. Right now autoconf is "you can use any
address you like, unless a one-packet exchange results in a collision".
With reliable DAD it becomes "you can only use addresses approved by the
authority".

You might think that it's the same, because today a node on the link can
always spoof a DAD packet. But it's not the same, because DAD is not
reliable, and a network that attempts to enforce that sort of policy will
cause breakage.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jun 2015 13:35:10 +1200

> on-link authority that the ability to decide which node gets what address.

Not necessarily. We might be satisfied with less unreliable DAD.

    Brian

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Wed, 10 Jun 2015 04:41:03 +0000

Pascal,

This was a proposal for distribution of unique interface ID's as a part DAD  draft-joshi-6man-neighbor-inform

--
Shree

From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, June 10, 2015 6:33 AM
To: Lorenzo Colitti
Cc: IPv6 List; Bob Hinden
Subject: Re: Next Steps on DAD Improvements

Hi:

Cheers,

Pascal

---

From: Greg Daley <[email-masked]>
Date: Wed, 10 Jun 2015 06:55:58 +0000

Hi Lorenzo et al, 

> From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
> Sent: Wednesday, 10 June 2015 11:19 AM
> To: Pascal Thubert (pthubert)
> On Wed, Jun 10, 2015 at 10:03 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> I'd reword that to "giving a node authority to reject a claim for an address on a link" since your text really talks about a DHCP- like world where nodes get their
> addresses from servers. Here, the authority does not impose which address gets assigned and autoconf is still doable. 
>
> I think it's a bit more than that. In order for DAD to be reliable, one node (or a collection of nodes that share state), needs to know all addresses on the link, at
> all times. And a node cannot configure an address without the authority's approval.
>
> I'm not sure about the statement "autoconf is still doable". The semantics change substantially, I think. Right now autoconf is "you can use any address you 
> like, unless a one-packet exchange results in a collision". With reliable DAD it becomes "you can only use addresses approved by the authority".
>
> You might think that it's the same, because today a node on the link can always spoof a DAD packet. But it's not the same, because DAD is not reliable, and a
> network that attempts to enforce that sort of policy will cause breakage

This seems to be cycling back towards the stateful vs tentative/optimistic DAD investigation we did 10 years ago for Mobile-IPv6 and Detecting Network Attachment.

At the time, the only stateful oracle which already knew about addresses or the solicited nodes' address on the link was the MLD querier router.  This kept a list of the devices which had joined the multicast groups other than ff02::1.  Other devices just wouldn't see the messages on some links.

There was no move to using a stateful approach based on MLD for DAD for a number of reasons (one of which is it was a nasty hack to rely on the MLD router to identify solicited nodes, when we're talking about on-link communication).  Other mechanisms built in stateful information based on other information derived from mobility etc.

The other solution which was mentioned back then was to keep IP addresses tentative for longer, but to use the ND protocol optimistically and safely in the mean time.

Even if we want to have a more reliable and less energy intensive protocol for DAD in the future, it still needs to be backward compatible:  I think some part of the solution will rely on treating the address as if you don't fully own it for a longer period of time.

Sincerely, 

Greg Daley
Solutions Architect
Logicalis Australia Pty Ltd
t +61 3 8532 4042
m +61 401 772 770.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jun 2015 16:14:05 +0900

Greg,

in some sends making DAD more reliable (e.g., through repeated DAD
attempts) and simultaneously using optimistic DAD (as the latest versions
of Android and iOS do) is going to make things worse, because it increases
the number of in-flight transactions (e.g., TCP connections) connections
that need to be rolled back if DAD eventually fails 10 seconds later.

Cheers,
Lorenzo

On Wed, Jun 10, 2015 at 3:55 PM, Greg Daley <[email-masked]> wrote:

> where nodes get their
> > addresses from servers. Here, the authority does not impose which
> address gets assigned and autoconf is still doable.
> >
> addresses on the link, at
> > I'm not sure about the statement "autoconf is still doable". The
> semantics change substantially, I think. Right now autoconf is "you can use
> any address you
> > like, unless a one-packet exchange results in a collision". With
> reliable DAD it becomes "you can only use addresses approved by the
> authority".
> >
> reliable, and a
> This seems to be cycling back towards the stateful vs tentative/optimistic
> DAD investigation we did 10 years ago for Mobile-IPv6 and Detecting Network
> Attachment.
>
> At the time, the only stateful oracle which already knew about addresses
> or the solicited nodes' address on the link was the MLD querier router.
> This kept a list of the devices which had joined the multicast groups other
> than ff02::1.  Other devices just wouldn't see the messages on some links.
>
> There was no move to using a stateful approach based on MLD for DAD for a
> number of reasons (one of which is it was a nasty hack to rely on the MLD
> router to identify solicited nodes, when we're talking about on-link
> communication).  Other mechanisms built in stateful information based on
> other information derived from mobility etc.
>
> The other solution which was mentioned back then was to keep IP addresses
> tentative for longer, but to use the ND protocol optimistically and safely
> in the mean time.
>
> Even if we want to have a more reliable and less energy intensive protocol
> for DAD in the future, it still needs to be backward compatible:  I think
> some part of the solution will rely on treating the address as if you don't
> fully own it for a longer period of time.
>
> Sincerely,
>
> Greg Daley
> Solutions Architect

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Jun 2015 09:28:29 +0200

> in some sends making DAD more reliable (e.g., through repeated DAD attempts) and simultaneously using optimistic DAD (as the latest versions of Android and iOS do) is going to make things worse, because it increases the number of in-flight transactions (e.g., TCP connections) connections that need to be rolled back if DAD eventually fails 10 seconds later.

an address may stop working at _any_ time.
if nothing else comes out of this work, but a change in the belief that addresses are stable...

cheers,
Ole

> [email-masked]

---

From: Greg Daley <[email-masked]>
Date: Wed, 10 Jun 2015 07:33:58 +0000

> From: Lorenzo Colitti [mailto:[email-masked]] 
> Sent: Wednesday, 10 June 2015 5:14 PM
> To: Greg Daley
> Cc: Pascal Thubert (pthubert); IPv6 List; Bob Hinden
> in some sends making DAD more reliable (e.g., through repeated DAD attempts) and simultaneously using optimistic DAD (as the latest versions of Android and iOS do)
> is going to make things worse, because it increases the number of in-flight transactions (e.g., TCP connections) connections that need to be rolled back if DAD eventually
> fails 10 seconds later.
> 
> Cheers,
> Lorenzo

Hi Lorenzo, 

You are right. Keeping the address optimistic increases the potential number of devices that can have address failure at any time.  At least they would know the failure had occurred though, which may not be the case if a link merges in the current scenario.

Greg Daley
Solutions Architect
Logicalis Australia Pty Ltd   t +61 3 8532 4042
m +61 401 772 770

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jun 2015 16:35:37 +0900

> if nothing else comes out of this work, but a change in the belief that

Are you saying that you want a mechanism for the network to say that a
previously-assigned address can no longer be used? That involves WAY more
work than changes to DAD.

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Jun 2015 09:55:55 +0200

> Are you saying that you want a mechanism for the network to say that a previously-assigned address can no longer be used? That involves WAY more work than changes to DAD.

no. I’m saying that hosts has to be prepared to deal with addresses not working or stopping working at any time during their attachment to a link.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jun 2015 16:59:51 +0900

On Wed, Jun 10, 2015 at 4:55 PM, Ole Troan <[email-masked]> wrote:

> no. I’m saying that hosts has to be prepared to deal with addresses not
> working or stopping working at any time during their attachment to a link.
>

How is that different from the network telling the host that an address can
no longer be used?

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Jun 2015 10:27:45 +0200

> How is that different from the network telling the host that an address can no longer be used?

that might be one way the hosts figures out an address no longer works.
but I don’t think we can assume the network would necessarily know in all cases.

please let’s not make too many assumptions about solutions at this stage.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jun 2015 17:44:22 +0900

> please let’s not make too many assumptions about solutions at this stage.

I'm not talking about solutions, I'm talking about scope.

Duplicate address detection is a well-defined concept. It deals with
detecting duplicates on a given link. On the other hand, saying that an
address "works" is a completely undefined concept. You might be able to say
that an address is unique on link at a given point in time, or that it's
not unique, or that it can be used to reach some set of off-node (on-link
or off-link) destinations.

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Jun 2015 10:57:34 +0100

> On 10 Jun 2015, at 09:44, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Wed, Jun 10, 2015 at 5:27 PM, Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:
> Duplicate address detection is a well-defined concept. It deals with detecting duplicates on a given link. On the other hand, saying that an address "works" is a completely undefined concept. You might be able to say that an address is unique on link at a given point in time, or that it's not unique, or that it can be used to reach some set of off-node (on-link or off-link) destinations.

Indeed. 

A different view on this problem is the accountability view - some of us are using various techniques to track IP/MAC/physical port activity on our networks for accountability purposes. Rather than trying to control address assignments, we embrace the fact that devices can pick their own addresses, and try to monitor and record that. We happen to use SNMP scraping of our network devices, some use Cisco syslogging, some do ND inspection. From the database that is built, we know where each MAC/IP address has been used, and when. But if there is an ‘authority’ on a link for unique addresses, it could presumably also fulfil this function.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jun 2015 19:55:51 +0900

On Wed, Jun 10, 2015 at 6:57 PM, Tim Chown <[email-masked]> wrote:

> But if there is an ‘authority’ on a link for unique addresses, it could
> presumably also fulfil this function.
>
> It could do lots of other things: ensure that nobody can use any addresses
if it crashes, ensure that each MAC address is allowed to use one IPv6
address for every $5 paid, and so on :-)

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Jun 2015 12:00:24 +0100

On 10 Jun 2015, at 11:55, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Wed, Jun 10, 2015 at 6:57 PM, Tim Chown <[email-masked] <mailto:[email-masked]>> wrote:
>> But if there is an ‘authority’ on a link for unique addresses, it could presumably also fulfil this function.
> 
> It could do lots of other things: ensure that nobody can use any addresses if it crashes, ensure that each MAC address is allowed to use one IPv6 address for every $5 paid, and so on :-)

A bargain, v4 addresses are around $7 ;)

Tim

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 10 Jun 2015 11:45:37 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Wednesday, June 10, 2015 5:58 AM
To: 6man WG
Subject: Re: Next Steps on DAD Improvements

>A different view on this problem is the accountability view - some of us are using various techniques to track IP/MAC/physical port activity on our networks for accountability purposes. >Rather than trying to control address assignments, we embrace the fact that devices can pick their own addresses, and try to monitor and record that. We happen to use SNMP scraping of our >network devices, some use Cisco syslogging, some do ND inspection. From the database that is built, we know where each MAC/IP address has been used, and when. But if there is an >‘authority’ on a link for unique addresses, it could presumably also fulfil this function.

The default router on the link is an authority and if the router supports a DAD proxy, the router has all the information for the admin to use SNMP etc.  Note, RFC 4862 and IPv6 DAD does not solve the problem of receiving a duplicate indication (DAD message or NA) once the address is in assigned state.   This is an open and hard problem to solve – the WG has to decide if it would like to solve this one or not.

Hemant

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 11 Jun 2015 04:35:59 +0000 (UTC)

From: Lorenzo Colitti <[email-masked]>
 To: Tim Chown <[email-masked]> 
Cc: 6man WG <[email-masked]> 
 Sent: Wednesday, 10 June 2015, 20:55
 Subject: Re: Next Steps on DAD Improvements

It could do lots of other things: ensure that nobody can use any addresses if it crashes, ensure that each MAC address is allowed to use one IPv6 address for every $5 paid, and so on :-)
/ Override the desire/right of the client to use privacy addresses.
/ In a corporate environment, where they own/operate the network and the attached host, then I think it is the corporation's right to choose how addresses are allocated and how globally unique they are (and they can already use DHCPv6 for that purpose).
/ However, when it is my device attached to a public network e.g., one in a hotel or at a cafe, then I don't think they should have an ability to disable my use of globally privacy addresses without me knowing. If I was informed that they were going to do that, then I would choose to not use their network.
/ Regards,Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: 神明達哉 <[email-masked]>
Date: Thu, 11 Jun 2015 11:41:33 -0700

At Mon, 8 Jun 2015 13:02:06 -0700,

> Should we work on the robustness and efficiency issues of DAD?
[...]
> The chair would like your feedback on this issue and if there is
> interest we will schedule an agenda slot in Prague.

I think it makes sense to work on these, as the dad-issues draft
sensibly explains that at least some of operational assumptions at the
time of original DAD design may not be valid.  Of course, we'll still
have to assess which part of the issues are sufficiently substantial
to be solved, and consider pros and cons of each particular solution
to each particular (sub-)issue.  I assume "work on" includes these
assessment and considerations.

--
JINMEI, Tatuya