Subject: [homenet] Homenet multicast support

From: Pierre Pfister <[email-masked]>
Date: Mon, 28 Apr 2014 15:10:12 +0200

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 ?

Thank you for your comments,

Pierre

---

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

> 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…

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

---

From: Dave Taht <[email-masked]>
Date: Mon, 28 Apr 2014 12:14:49 -0700

On Mon, 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.
>
>
> - 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)

Sure. However the only thing that still sort of uses multicast from the
wan side is some forms of television.

Regrettably the state of pim is very very very undertested and
the relevant code for it needs love - pimd (what I ship in cero) is
rather flaky, and pim support from things like quagga only existed,
if ever, out of tree. I don't listen on the wan address.

Things like openwrt compile pim out by default. (It's compiled
in in cerowrt, but I'm not aware of any users)

>
> 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.

Multicast is a major headache from a firewalling perspective and in multiple
other regards.

The cerowrt bcp38 implementation filters out

list match '240.0.0.0/4'     # RFC 5745

and relies on source specific routing to filter out other stuff on ipv6.

> - 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...)

Depends on your form of multicast. If they cannot join a group on the
next hop up, they won't go anywhere.

> 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.
>
> 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 ?
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Apr 2014 09:52:03 +0200 (CEST)

> Do you think these are reasonable requirements ?

Absolutely, fully support.

> Are these definitions reasonable to you ?

I would like to not rule out the home as a multicast sender to the 
outside. I agree not sending out the packets is good default behavior, but 
there could be potential use-cases going forward where one would actually 
like the home to be able to source multicast.

> 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’’.

You don't write this outright, so just let me ask: You don't propose that 
the home speaks PIM with the ISP, right? In my view, the world the home 
would do IGMPv3/MLDv2 join towards the ISP. It would then use PIM-SSM 
within the home for the multicast routing. If we have to insert a static 
/128 route towards each S, that might be the price to pay.

> 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:

Personally I think that SM should go away, and we should only use PIM-SSM. 
I'd rather see the S being sent out as service discovery messages and 
discovered that way, rather than using PIM-SM to discover sources. I now 
read up on BIDIR (didn't know about it before), and.. hm, well, so your 
proposal is to only use shared trees within the home and nothing else? 
Well, it's and idea that should be considered.

> 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 ?

Wouldn't it make sense that the HNCP elected routing would have a PIM 
priority setting that would elect it to be PIM DR on the LAN as well?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 29 Apr 2014 10:10:57 +0200

Le 29 avr. 2014 à 09:52, Mikael Abrahamsson <[email-masked]> a écrit :

> I would like to not rule out the home as a multicast sender to the outside. I agree not sending out the packets is good default behavior, but there could be potential use-cases going forward where one would actually like the home to be able to source multicast.

Why not I guess. Border routers could be configured manually or with HNCP to allow some groups to be shared with the outside.

> 
>> 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).
>> 
> You don't write this outright, so just let me ask: You don't propose that the home speaks PIM with the ISP, right? In my view, the world the home would do IGMPv3/MLDv2 join towards the ISP. It would then use PIM-SSM within the home for the multicast routing. If we have to insert a static /128 route towards each S, that might be the price to pay.

Of course ! The problem would be quite easier if home and ISP could speak PIM, but the goal here is to make border routers proxy PIM subscriptions toward the ISP using IGMPv3/MLDv2 indeed. 

> 
>> 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:
> 
> Personally I think that SM should go away, and we should only use PIM-SSM. I'd rather see the S being sent out as service discovery messages and discovered that way, rather than using PIM-SM to discover sources. I now read up on BIDIR (didn't know about it before), and.. hm, well, so your proposal is to only use shared trees within the home and nothing else? Well, it's and idea that should be considered.

Using service discovery makes sense in order to discover service sources. But in a dense sources situation, wildcard subscription (*,G) could still be useful. I think the hard part is SSM (Because it requires more knowledge about source/group location). Once SSM is supported (*,G) subscriptions would work as well. So I don’t think discarding (*,G) would make the solution easier.

What I like with BIDIR is that you don’t use tunneling even if you have no idea where is the source located (which could happen quite often if the source is from an ISP). But if you do, then you can optimize the path. I have no experience using BIDIR thought (and am looking for an IPv6  implementation for Linux, if anybody has one).

> 
>> 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 ?
> 
> Wouldn't it make sense that the HNCP elected routing would have a PIM priority setting that would elect it to be PIM DR on the LAN as well?

It makes sense. IMHO the most complicated part in PIM bootstrapping is the message formatting and transmission. But I don’t see any capabilities or performances differences between PIM BS and HNCP. So using HNCP for election is possible.