Subject: Re: [dnssd] [homenet] Homenet multicast support

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Apr 2014 12:02:52 -0700

On Apr 28, 2014, at 6:10 AM, Pierre Pfister <[email-masked]> wrote:

> Hello group,
> 
> I’m working on the homenet experimental implementation http://www.homewrt.org/ and have been thinking on multicast support for homenet. Encountering a few design issues, comments from the working group could be helpful.
> 
> This is a short version of my thoughts about the problem. I’m thinking about writing a draft about it. But I would like some feedbacks from the group.
> 
> 
> 1) Why supporting multicast.
> 
> I think homenet should support:
> - Hosts in the home should be able to join a group and receive traffic from inside the home and from ISPs if they provide traffic for it (and the scope allows it)
> - SSM should be supported.
> - It should work with multi-homing.
> 
> Do you think these are reasonable requirements ?
> 
> 
> 2) Scope considerations.
> 
> A basic home router supports « internal » and « external » interfaces. So for each multicast scope, we should define the default behavior for each case.  Possibly, improved routers may support tunnels between homes or home administration areas. 
> One possible default behavior could be:
> - Admin-local: Block from external (optionally block from tunnels and other home sub-areas) (Might be used to create sub-areas in the home network).
> - Site-Local: Block from external (optionally block from tunnels) (Local to geographically localized area, for connexion between multiple sites like VPNs between homes, use a bigger scope)
> - 6, 7 and 8 (Organization Local): Block from external (Organization Local being the bigger Home-local scope, in case you own multiple homes for instance, or distant servers connected through VPNs, etc...)
> - 9 to E (global scope): Accept from internal and external links
> 
> I think multicast packets originated inside the home must never leave the home network.
> 
> Are these definitions reasonable to you ?
> 
> 
> 3) Using PIM SM.
> 
> I’ve been looking at PIM as a solution candidate (If you think another MRP could be used, please tell ! :-) ). I don’t consider DM as a possible solution. SM and BIDIR could be used.
> SM would work out of the box if there was no issues with multi-homing. Indeed, border routers have to subscribe to groups on external interfaces when some host inside the home has interest for the group. So border routers needs to be aware of the subscriptions inner hosts made.
> 
> So either:
> - Only a single ISP sends traffic from the outside for each group. In which case we can use a group-to-rp mapping where every border router is a RP for its own group. That is supported by PIM. We would need configuration (e.g. DHCP, static) from ISPs to create that mapping.
> - We want multiple ISPs to be able to send traffic for some group, in which case a single RP should send subscription control messages to all border routers in order to control home multicast subscriptions (That would require modifications to PIM).
> 
> Another issue comes when using SSM. The path (S, G) subscriptions follow is dictated by routers’ routing tables. That works well when the source is inside the routing domain (the home), or when there is a single border router (and that router is the RP). When there are multiple border routers, there are multiple default routes. We need do decide which border router to use, and that must be consistent. We could use a group-to-rp mapping as well here. Or a single RP could send control unicast packets to border routers (like previously). I have a more precise description of that possibility, but I want to keep that mail ‘’short’’.
> 
> 
> 4) Using PIM BIDIR.
> 
> I personally prefer the BIDIR possibility. With a single RP which sends subscription control messages to border routers (that would require protocol specs). (*,G) would flow toward the RP and (S,G) would flow toward the source when it is inside the home, or toward the RP when the source is outside the home. By default, this architecture would not support path optimization when the source is outside the home. 
> But:
> - I imagine future home networks to be organized around high-bandwidth link(s) (e.g. wired) attached to CPE border routers and less efficient links (wifi, sensor networks, …). So in BIDIR, it’s not a problem receiving more traffic on the central link, and path optimization would often not optimize anything.
> - In general, it could be useful to have a way for ISPs to say ‘I do own these addresses’. For instance, RA’s RIOs could be used. In which case the routes would be injected in the routing protocol, and (S,G) messages could flow toward the correct home exit.
> 
> The good news about BIDIR being that it works even when you don’t really know how to route (S,G) subscriptions. Which we don’t in general when S is outside the home.
> 
> Does anybody know about some IPv6 BIDIR implementation we could use/patch ? That would be very helpful !!
> 
> 
> 5) For autoconf
> PIM makes use of its own bootstrapping extension. HNCP could be used as well for the exactly same purpose (election is pretty obvious in HNCP). An extension would be really easy do define. What do you think ?

Dear Pierre,

Adding service filters to RBridge (now deployed supporting PPP) seems to represent an alternative having security advantages since it does not depend on layer 3.  Using routable IP addresses means publishing is not without significant risk.

An update to mdns-xlink offers an alternative Security Consideration section from that of draft-ietf-dnssd-requirements.
http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03

As an experiment, a test was made using a new popular brand of an IPv6 enabled printer.  Discovery by name resolution and not by address probing for the printer allowed Internet access without any logs created.  This is a problem not easily resolved using routable IP addresses.

Regards,
Douglas Otis