Subject: [v6ops] a (misguided) site-local attempted "definition"

From: Erik Kline <[email-masked]>
Date: Wed, 8 Dec 2010 16:38:55 -0800

[subject changed to avoid thread pollution]

On 6 December 2010 10:41, Fred Baker <[email-masked]> wrote:
>
> On Dec 6, 2010, at 10:22 AM, Mark Baugher wrote:
>
>> site-local multicast
>
> Someday when someone has some time, I would like an explanation of "site-local" that doesn't involve a network administration configuring some form of filter in the exact set of interfaces (not routers, interfaces) that constitute the edge of a site.
>
> In case you are wondering why the distinction between routers and interfaces there, consider this case:
>
>                        |Link to upstream
>                        |network or provider
>                   +----+-----+
>                   |          |
>        -----------+  Router  +------------
>       Link to     |          |      Link to
>       somewhere   +----+-----+      somewhere
>       else within      |            else outside
>       sit         -----+------      site
>                      Local LAN
>
> A site-local multicast may be routed between the local LAN and "somewhere else within the site", but not "outside" or "upstream". Is a "site" "my company"? If so, Cisco's concept of a "site" might be somewhat breathtaking. Is it a campus? A building? A cube? What the !@#$%^ is a site?
>
> As near as I can tell, the definition is in the hands of the local administration, and requires some form of "edge" - a filter in a routing protocol, an air gap in the routing protocol (between a CPE and its upstream perhaps), or something. And that filter/gap/whatever has to be in every place that should be considered an edge and nowhere else.
>
> Considering the frequency of reports of 0.0.0.0/0, RFC 1918 prefixes, and other martians being advertised in routing, I tend to think that any such definition is full of holes.

Caveats:

    (1) I was not present for, nor have I read any archived messages
pertaining to, the original site-local deprecation discussion.

    (2) I foolishly think I have properly donned my flame-retardant underwear.

This silly idea, which I expressed to Mark Townsley over sake in Tokyo
a few months ago, has not been fully baked nor even researched yet.
But I offer it up for consideration or public humiliation nonetheless.

I happen to think that, by DEFAULT (and with a smidge of extra help*),
one could define "site" as extending across all links from any point
of origin where on-link computation is either not permitted or not
necessary.  The network of links a datagram traverses before
encountering such a boundary forms the logical "interior" of a site.

*Extra help that makes this default position slightly more
operationally practical:

    (1) If ISPs disabled on-link computation in their RAs to home
gateways then this would indicate a natural "site" boundary.  Home
gateways that further delegate, say via DHCPv6-PD, to nodes on the LAN
side would NOT disable on-link computation in the RA and hence
interior networks could be easily added to the "site" through simple
chaining.

    (2) Similarly, a route/host with a VPN tunnel up would not, by
DEFAULT, extend the notion of "site" through that tunnel interface if
on-link computation were disabled or not necessary (which it can be so
considered if it's a point-to-point link).

    (3) This doesn't work by default in networks with inter-domain
routing...unless they use /127s for router links (see Maz/Lorenzo/et
alia's I-D).

A network with intra-domain routing wishing to extend the definition
of "site" could theoretically do so via configuration, since
intra-domain (and inter-domain) routing typically doesn't happen
without human configuration.

One thing that I think does become possible in this scheme is
site-local multicast.  Once you have that you can do site-wide service
discovery fairly simply.  Organizations running larger networks would
need to decide just how far flung these packets would be permitted to
fly, but it should be workable for most (all?) simple/small networks.

Flame/shame on,
-Erik

---

From: Erik Kline <[email-masked]>
Date: Thu, 9 Dec 2010 05:27:54 -0800

> considered if it's a point-to-point link).

I think it might be better to simply say "by DEFAULT all tunnel links
are site boundaries".

---

From: Mark Townsley <[email-masked]>
Date: Thu, 09 Dec 2010 14:55:55 +0100

If an RG happens to use PPP or 6rd, it's pretty obvious where the likely
ISP/home boundary is. The ambiguity arises in IPoE cases where an RG is
plugged into the ethernet port of a cable or dsl modem that is doing the
DOCSIS/DSL piece, but otherwise bridging data to the RG. Here, the RG
can't tell whether it is doing ND/DHCP with the ISP or ND/DHCP with
other CPE. What your proposal does is provide a bit (literally) of
information to try and ascertain this.

What I like about this is that it gives some promise that we could have
a better hint (there could be other hints as well) for where the
boundary between home and ISP is. I hear a lot that "RGs know where the
physical WAN port is because it is labeled". That doesn't work when the
WAN port is plugged into a bridge to the ISP vs. being plugged into the
back of another router as the protocols are otherwise identical. I also
hear a lot about how bridging in the home should be the default whenever
possible for IPv6 rather than routing, but again we need to know when to
be a bridge and when to be a router in that case. There may be more than
one way to try and determine this edge, but if the L bit can help, so be
it (even better as this becomes a potentially in-charter v6ops BCP
recommendation rather than a bits-on-the-wire protocol extension).

- Mark

---

From: Erik Kline <[email-masked]>
Date: Thu, 9 Dec 2010 13:47:59 -0800

> interior networks could be easily added to the "site" through simple

There is the obvious concern that an exterior agent could cause such a
default site's boundary to change just by flipping this bit.  Either
through misconfiguration or intent, flipping to L=1 would cause such a
"default site" to extend its notion of "interior" out to exterior
agents.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 09 Dec 2010 23:13:43 +0100

> "default site" to extend its notion of "interior" out to exterior
The security model in the vast majority of broadband deployments is that
a malicious user cannot send traffic at L2 directly to anyone's
residential gateway. If this barrier is broken (by physically inserting
in the line, breaking encryption, or otherwise), flipping L=1 would be
but one of many vectors of potential attack.

- Mark

---

From: Nathan Ward <[email-masked]>
Date: Fri, 10 Dec 2010 11:33:57 +1300

On 9/12/2010, at 1:38 PM, Erik Kline wrote:

> Complicated things

I have not seen the historical discussions either, but have heard that they were difficult.
What I wonder is, why do we need to define site, when talking about multicast?

Surely an ISP will filter any multicast packets they receive from outside their network (customers) that are for site-local groups?
That's a good start.

ISP access router vendors might want to enable this filtering by default on dynamic interfaces, or DHCPv6-PD interfaces or something as I would imagine that it is better to not forward site local multicast, and then administrators wanting to enable it for some corner case can do so.

The ISP router could have a PIM option on the interface to say that it's a site boundary, so joins for a site local group received on that interface are ignored, and joins are not sent.
Then again, multicast DNS should probably be in a densely flooded group I imagine, so perhaps we pretend that site-local groups are automatically pruned on interfaces that have this option turned on.
Maybe the PIM option to filter site-local should be enabled by default on all interfaces on non-CPE routers, or perhaps it should be 'ipv6 pim enable-site-local' or something.

A DHCPv6 option could exist that the ISP router sends to the CPE to indicate that it is a site boundary - but this shouldn't really be needed, it'd just be an optimisation.

Summary is, I don't think we want to have some magic rules to define a site (for multicast purposes) and have dumb CPE make this determination themselves. It sounds like asking for trouble (because we can't possibly consider all cases), and help desk headaches.

--
Nathan Ward

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Dec 2010 14:38:22 -0800

> What I wonder is, why do we need to define site, when talking about multicast?

because there is a site-local form of a multicast address.

---

From: Nathan Ward <[email-masked]>
Date: Fri, 10 Dec 2010 11:58:31 +1300

> because there is a site-local form of a multicast address. 

That question was essentially rhetorical, the rest of my post goes on answer that we don't, and explains alternatives to making assumptions in this forum and defining policy to derive where site boundaries exist for the purposes of IPv6 multicast (do any other purposes still exist?).

This is somewhat analogous to ULA - I would expect that ISPs filter FEC/8 on their customer and peering links (regardless of whether we recommend enabling ULA in CPE or not, it's going to leak over customer circuits to ISPs, and certainly over peering circuits, just like RFC1918 would without filtering) - except for some corner cases, which they can select and configure. The same optional filtering should be done for site local multicast.

--
Nathan Ward

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Dec 2010 09:56:49 +0100

Nathan,

> This is somewhat analogous to ULA - I would expect that ISPs filter FEC/8 on their customer and peering links (regardless of whether we recommend enabling ULA in CPE or not, it's going to leak over…

this is touching upon a slightly larger problem. in a zero configuration routed home network, where you plug routers together in an arbitrary fashion...

routers have to behave differently on internal and external (to the site) interfaces. on the CE to PE link the interface has to be in a hybrid host/router mode (rfc4861).
it most likely will have a different default security policy (e.g. firewall) on external interfaces. it will most likely (we haven't defined this) run something like zOSPF on internal interface but not on external ones. it must be a ULA and multicast (organizational scope) boundary, since you don't want to trust your ISP with your 'internal' packets.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Dec 2010 10:55:19 +0100

Le 9 déc. 2010 à 01:38, Erik Kline a écrit :

> ...

I don't know if it helps, but RFC 4193, where ULAs are defined and which isn't deprecated, abundantly refers to "sites".
The assumed understanding of what it means is IMHO satisfactory.
 
Regards,
RD

PS: I noted an unfortunate tendency to use "datagrams" in place of "packets".
In IPv6, where packets are always end-to end, intermediate nodes aren't concerned with datagrams.

---

From: Alan Kavanagh <[email-masked]>
Date: Fri, 10 Dec 2010 12:33:42 -0500

Agree with Mark, there are mechanisms in place where by  subscriber lines do not talk directly on L-2, all traffic from the RG is sent upstream to the g/w.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: December-09-10 5:14 PM
To: Erik Kline
Cc: IPv6 Operations
Subject: Re: [v6ops] a (misguided) site-local attempted "definition"

On 12/9/10 10:47 PM, Erik Kline wrote:
> > gateways that further delegate, say via DHCPv6-PD, to nodes on the 
> > LAN side would NOT disable on-link computation in the RA and hence 
The security model in the vast majority of broadband deployments is that a malicious user cannot send traffic at L2 directly to anyone's residential gateway. If this barrier is broken (by physically inserting in the line, breaking encryption, or otherwise), flipping L=1 would be but one of many vectors of potential attack.

- Mark

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops