Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback

[james woodyatt <jhw@apple.com>]

On Aug 6, 2010, at 17:49, Mark Smith wrote:
> 
> To avoid using a global scope for that, it probably wouldn't be hard to re-originate the content at the IPv6 layer within the ISP's network, changing it's scope at the same time.

I fail to understand why this should be viewed as necessary.  If service providers feel the need to re-originate content at a local interface address, they can certainly do so without changing the multicast addressing scope.  They could easily just retransmit with a distinguished global scope address in the RFC 3305 range corresponding to a route filter at their transit borders.

Nothing requires service providers to advertise every global scope multicast route from their network interior and subscribers all the way out to the public default free zone.  In fact, I'd be shocked and surprised if they did.

That said, I'm sorta guessing that more interest in reserving some value of SCOP > 8 for subscriber aggregation purposes will happen when more interest in multicast routing arises among service providers, but I'm not sure MZAP [RFC 2776] is well-specified for operation across AS boundaries.

(Meanwhile, there is RFC 2908, which makes my head hurt.)

> "LAN.MLD.ROUTED. The device MUST default to not sending MLD messages for scope of 0 through 8."

This says gateways do not join multicast groups on their LAN interfaces unless SCOP > 8, but it says nothing about forwarding behavior.  Otherwise, this isn't that different from what our draft says.

Our draft says that multicast-capable residential gateways should default to acting as an organization-local zone boundary, i.e. they are multicast routers that only *forward* multicast with SCOP > 8.  They can still join multicast narrower-scope groups on the LAN, but they do not forward them into the service provider network.  Likewise, they can join narrower-scope groups on their WAN interface, but they do not forward them into the subscriber LAN.

That's because it's the forwarding behavior we care about.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering