Subject: Re: To DAD or not to DAD?

From: James Woodyatt <[email-masked]>
Date: Mon, 2 Mar 2015 10:52:56 -0800

The new Apple TV doesn't start up the first time asleep. It starts up
awake, and the sleep proxy, which is listening on the network promiscuously
just for this purpose, receives the first NA the Apple TV sends for its
previously used IPv6 address, and it consequently flushes its cache entry
pointing at the stale MAC address.

On Sat, Feb 28, 2015 at 4:45 PM, Hemant Singh (shemant) <[email-masked]>
wrote:

> The ECMA-393 standard as described bellows looks useful.  However, how is
> information in the proxy purged?  I replace the sleeping Apple TV node with
> a new one.  How does the proxy purge the old one?    What if the new one
> gets the same IPv6 address as the old one?  The devices do not use Modified
> EUI-64 format for IPv6 address generation.
>
> Thanks,
>
> Hemant
>
> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Saturday, February 28, 2015 4:55 PM
> To: James Woodyatt; Erik Nordmark
> Cc: [email-masked]
> Subject: Re: To DAD or not to DAD?
>
> On 2/25/15 11:43 AM, James Woodyatt wrote:
> > Well, there's the ECMA-393 standard, which was mostly written from the
> > perspective of sleep proxies integrated with network interface
> > peripheral devices, but it's not hard to see that what those sleep
> > proxies inside the NIC are doing could be extended to work with a
> > network sleep proxy like what Apple shipped in OS X hosts, the Apple
> > TV and the AirPort base station product line: when a host goes to
> > sleep, it registers its services with a sleep proxy, which acts as a
> > ND and ARP proxy for the sleeping host, answers mDNS-SD service
> > requests for it, and sends wake-on-LAN packets to the sleeping host
> > when a TCP SYN, or initial UDP packet, or what have you arrives at the
> > sleep proxy host.  When the sleeping host awakens, it sends ARP and ND
> > advertisements to invalidate cache entries on the network that
> > previously pointed to the sleep proxy.
>
> Thanks - I'll at least add a reference to ECMA-393 and the wikpedia page
> for Bonjour sleep proxies to the draft.
>
>     Erik
>
>
> >
> > On Thu, Feb 19, 2015 at 3:57 PM, Erik Nordmark <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     On 2/19/15 3:15 PM, James Woodyatt wrote:
> >
> >
> >             The slides offered these options:
> >             1. Deprecate DAD - it is expensive and duplicates are not
> >         common
> >
> >
> >         I wish I had a euro for every second I've spent chasing
> >         problems caused by expected MAC/IPv6-IID address collisions,
> >         which had the root causes of either A) MAC address cloning, or
> >         B) some network sleep proxy protocol misbehaving somewhere. I
> >         would go live on a nice beach in Italy, and I would never wear
> >         shoes again.
> >
> >         I've also yet to work for an employer who didn't have to deal
> >         with the problem that the factory shipped a pile of machines
> >         into the market with duplicate MAC addresses, and now we can't
> >         rely on them being unique hardware identifiers anymore. The
> >         EUI-48 and EUI-64 specifications don't actually require that,
> >         you know.
> >
> >
> >     James,
> >
> >     FWIW I don't believe we should deprecate it either. Put it on the
> >     slides to wake folks up. That seems to work better on the mailing
> >     list than it did in the meeting room in Honolulu ;-)
> >
> >         That draft needs to say something about network sleep proxies.
> >
> >
> >     Is there any detailed descriptions of what sleep proxies do with
> >     ND? I've just seem a wikipedia article which didn't have any detail.
> >
> >        Erik
> >
> >
> >
> >         --
> >         james woodyatt <[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >         Nest Labs, Communications Engineering
> >
> >
> >
> >
> >
> > --
> > james woodyatt <[email-masked] <mailto:[email-masked]>> Nest Labs,
> > Communications Engineering
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 2 Mar 2015 19:41:01 +0000

Ok, thanks for the reply, James.

Hemant

From: James Woodyatt [mailto:[email-masked]]
Sent: Monday, March 02, 2015 1:53 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: To DAD or not to DAD?

The new Apple TV doesn't start up the first time asleep. It starts up awake, and the sleep proxy, which is listening on the network promiscuously just for this purpose, receives the first NA the Apple TV sends for its previously used IPv6 address, and it consequently flushes its cache entry pointing at the stale MAC address.

On Sat, Feb 28, 2015 at 4:45 PM, Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>> wrote:
The ECMA-393 standard as described bellows looks useful.  However, how is information in the proxy purged?  I replace the sleeping Apple TV node with a new one.  How does the proxy purge the old one?    What if the new one gets the same IPv6 address as the old one?  The devices do not use Modified EUI-64 format for IPv6 address generation.

Thanks,

Hemant

-----Original Message-----
From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Erik Nordmark
Sent: Saturday, February 28, 2015 4:55 PM
To: James Woodyatt; Erik Nordmark
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: To DAD or not to DAD?
> previously pointed to the sleep proxy.

Thanks - I'll at least add a reference to ECMA-393 and the wikpedia page for Bonjour sleep proxies to the draft.

    Erik

>
> On Thu, Feb 19, 2015 at 3:57 PM, Erik Nordmark <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>         james woodyatt <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>         <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
> james woodyatt <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> Nest Labs,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 18 Mar 2015 13:55:07 -0700

James,

I finally read through all of ECMA-393 and one piece of IPv6 text looks odd:

6.4.2 Behavioural Requirements

The proxy expects that the link-local and global addresses have the same 
solicitation address and that the temporary addresses have the same 
solicitation address.

I don't know what "solicitation address" is and the document doesn't 
define it. If it is "solicited-node multicast address" then the document 
is incorrect, and that incorrectness would prevent deployment of IPv6 
addresses with better privacy where the link-local and global addresses 
might not have the same IID.

Do you know a way to contact some ECMA group to get this clarified?

Thanks,
    Erik
New Ecma template for the preparation of draft Standards (update June 2009)

---

From: James Woodyatt <[email-masked]>
Date: Fri, 20 Mar 2015 21:30:05 +0100

Erik—

Recalling the Task Group discussions from memory, I think "Solicitation
Address" wasn't intended to refer to the Solicited Node Multicast Group. It
was trying to point at the concept we are now using the word Persistent
Interface Address to describe, as compared to Temporary Interface Address.
Not that it helps any.

I do agree that whole section looks pretty suspect and in need of revision.
It lists "Target Addresses" in the configuration data and doesn't define
that term either. The paragraph in section 6.4.2 Behavioral Requirements
seems like it can't be interpreted in a way that makes sense, whether it's
talking about Solicited Node Group Address or Persistent Interface Address.
I would not be at all surprised to discover some implementations of
ProxyZzzz inside NIC microcodes will be unhappy when
I-D.ietf-6man-default-iids is a requirement. I remember there was a lot of
sentiment that was invested in the idea that IPv6 interface identifiers of
interest would always contain embedded MAC addresses. I remember expressing
my disagreement about that, but ultimately declining the opportunity to get
really argumentative about it. Maybe it would have been better if I had
persisted, but I don't know.

My employer has changed since my activity in ECMA, and I think the Task
Group is now closed anyway. My activity was mainly to manage the part of
the text that became Section 8.6 Service Discovery Using mDNS, but it's
clear that I was on the team that overlooked the underclarity of Section
6.4.2. My sincere apologies for that.

On Wed, Mar 18, 2015 at 9:55 PM, Erik Nordmark <[email-masked]> wrote:

>> perspective of sleep proxies integrated with network interface peripheral
>> devices, but it's not hard to see that what those sleep proxies inside the
>> NIC are doing could be extended to work with a network sleep proxy like
>> what Apple shipped in OS X hosts, the Apple TV and the AirPort base station
>> product line: when a host goes to sleep, it registers its services with a
>> sleep proxy, which acts as a ND and ARP proxy for the sleeping host,
>> answers mDNS-SD service requests for it, and sends wake-on-LAN packets to
>> the sleeping host when a TCP SYN, or initial UDP packet, or what have you
>> arrives at the sleep proxy host.  When the sleeping host awakens, it sends
>> ARP and ND advertisements to invalidate cache entries on the network that
> define it. If it is "solicited-node multicast address" then the document is
> incorrect, and that incorrectness would prevent deployment of IPv6