Subject: [Efficientnd-dt] My DAD notes

From: Erik Nordmark <[email-masked]>
Date: Thu, 06 Mar 2014 18:52:39 +0000

Problems/constraints/goals:

1. No permission from network to form address
2. Duplicate MAC address in broadband and with vms (in some deployment)
3. Efficient
    Little/no multicast
    Save battery
4. Allow sleep
5. Partitioned link that heals

When I left I think we had a handle on 1, 3, and 4.
Makes sense to talk more about 2 - whether there is a way to detect IPv6 
duplicate addresses even when the MAC address is a duplicate.

Not clear whether we can also handle #5 - something which ACD does handle.

    Erik

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 6 Mar 2014 19:23:15 +0000

A few ideas that have been discussed after you left:

- What happens when registration fails and there is one default router in the network?

Suggestions from Andrew and Lorenzo: the host should fall back to the legacy behavior [not energy aware]

Other suggestions:
- Likes to see registration-like enhancements optional [ which is optional today in the efficient-nd draft]
- Like to provide registration like benefit in mixed-mode as well

-Samita

-----Original Message-----
From: Efficientnd-dt [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Thursday, March 06, 2014 10:53 AM
To: [email-masked]
Subject: [Efficientnd-dt] My DAD notes

1. No permission from network to form address 2. Duplicate MAC address in broadband and with vms (in some deployment) 3. Efficient
    Little/no multicast
    Save battery
4. Allow sleep
5. Partitioned link that heals

When I left I think we had a handle on 1, 3, and 4.
Makes sense to talk more about 2 - whether there is a way to detect IPv6 duplicate addresses even when the MAC address is a duplicate.

    Erik

_______________________________________________
Efficientnd-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/efficientnd-dt

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 06 Mar 2014 19:33:49 +0000

Samita,

thanks for the notes.

> Suggestions from Andrew and Lorenzo: the host should fall back to the legacy behavior [not energy aware]
Makes sense.
> - Likes to see registration-like enhancements optional [ which is optional today in the efficient-nd draft]
I think that is basically saying that we should assume mixed-mode 
forever. (which would be fine with me)
> - Like to provide registration like benefit in mixed-mode as well
I think we have that already - unless I'm missing something.

One random though - if we have registered addresses in the routers would 
there be cases we'd use that only for DAD (and do address resolution 
using the normal way)? [Excuses if that makes no sense - it's been a 
long week.]

    Erik

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 7 Mar 2014 01:40:49 +0000

One random though - if we have registered addresses in the routers would there be cases we'd use that only for DAD (and do address resolution using the normal way)? [Excuses if that makes no sense - it's been a long week.]

    Erik

[SC>]  If the node registers in order to avoid DAD, then it makes sense to do address resolution via the Router. Without that, NS address resolution messages will still be multicast and they can be lot more in case of short lived connections;  defeats the purpose of reducing multicast in my mind.

Thanks,
-Samita

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Mar 2014 18:24:38 +0000

Hello Erik:

At a minimum, the router that has a registration could observe or defend registered addresses.
Today, Cisco SAVI devices do not support unicast NS lookup because the host does not know where to ask.
But we can proxy for snooped entries, or defend them against theft by a third party.

Cheers,

Pascal

> From: Efficientnd-dt [mailto:[email-masked]] On Behalf Of
> Samita Chakrabarti
> Sent: vendredi 7 mars 2014 02:41
> To: Erik Nordmark; [email-masked]
> Subject: Re: [Efficientnd-dt] My DAD notes
> 
> 
> 
> 
> One random though - if we have registered addresses in the routers would there
> be cases we'd use that only for DAD (and do address resolution using the normal
> way)? [Excuses if that makes no sense - it's been a long week.]
> 
>     Erik
> 
> [SC>]  If the node registers in order to avoid DAD, then it makes sense to do
> address resolution via the Router. Without that, NS address resolution messages
> will still be multicast and they can be lot more in case of short lived connections;
> defeats the purpose of reducing multicast in my mind.
> 
> Thanks,
> -Samita
> 
> > 1. No permission from network to form address 2. Duplicate MAC address in
> broadband and with vms (in some deployment) 3. Efficient
> >      Little/no multicast
> >      Save battery
> > 4. Allow sleep