sleeping proxy at the IETF

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello James:

 

Do I read from your description that the particular sleeping proxy expects a single IPv6 address per device/MAC or something? Cisco ships an implementation of such proxy function for wireless devices - used over WiFi for multicast cancellation -, and in that case we cannot make such an assumption. Instead, we implemented a state machine that echoes that of ND, and will flush unused bindings, or least recently used STALE address bindings when the number of addresses per device is bounded.

 

Requirements for a sleeping proxy are indeed discussed at the IETF. This is happening at 6lo with the 6LoWPAN ND update requirements draft <https://tools.ietf.org/html/draft-thubert-6lo-rfc6775-update-reqs-05> , with a use case where the sleeping devices are not on the Ethernet backbone where classical ND is operated, but on a 6lo link that is 1)  potentially wireless and potentially L2-meshed or L3-routed, and 2) connected to the backbone via a so-called backbone router. These requirements derive in particular from the 6TiSCH architecture <https://tools.ietf.org/html/draft-ietf-6tisch-architecture> , whereby the wireless links are in fact routed with RPL. But the fundamental design point is that the interface between the 6lo link(s) and the backbone router is agnostic to the routing technology on the 6lo side, in the same fashion as the 6lo side does not know or care what happens on the Ethernet side, be it ND proxy, MIP tunneling, redistribution in a homenet routing protocol, or else, you name it. 

 

There is an obsoleting spec <http://tools.ietf.org/id/draft-thubert-6lowpan-backbone-router-03.txt>  for the backbone router that implements the above – obsoleting since the spec was not updated after the lessons learnt from running code and testing through 2 consecutive plugtests at the IETF. In that spec, an updated efficient/6LoWPAN ND is used  the method to redistribute routes between the 6lo router and the backbone router – an operation that is done classically inside a router without a protocol. Thomas and I have brought the hardware for a live demo of the backbone router with a TSCH-based routed mesh; please contact us if you want to see it and we’ll bring it up for you.

 

Cheers,

 

Pascal

 

From: ipv6 [mailto:[e-mail]] On Behalf Of James Woodyatt
Sent: lundi 2 mars 2015 12:53
To: Hemant Singh (shemant)
Cc: [e-mail]
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) <[e-mail]> 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:[e-mail]] On Behalf Of Erik Nordmark
Sent: Saturday, February 28, 2015 4:55 PM
To: James Woodyatt; Erik Nordmark
Cc: [e-mail]
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 <[e-mail]
> <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>         Nest Labs, Communications Engineering
>
>
>
>
>
> --
> james woodyatt <[e-mail] <mailto:[e-mail]>> Nest Labs,
> Communications Engineering

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------





 

-- 

james woodyatt <[e-mail]>

Nest Labs, Communications Engineering