Subject: Fwd: New Version Notification for draft-smith-6man-link-locals-off-link-00.txt

From: Mark Smith <[email-masked]>
Date: Sun, 16 Aug 2015 22:39:15 +1000

Hi,

I've had this idea for a while, finally got around to writing it up.

The idea is override the Link-Local on-link default assumption so that
Link-Local addresses can be used on "Constrained Broadcast
Multi-Access Links" e.g., TR-101 N:1 VLANs or "Private VLANs".

Regards,
Mark.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 16 August 2015 at 22:35
Subject: New Version Notification for
draft-smith-6man-link-locals-off-link-00.txt
To: Mark Smith <[email-masked]>

A new version of I-D, draft-smith-6man-link-locals-off-link-00.txt
has been successfully submitted by Mark Smith and posted to the
IETF repository.

Name:           draft-smith-6man-link-locals-off-link
Revision:       00
Title:          Indicating Link-Local Unicast Destinations are Off-Link
Document date:  2015-08-16
Group:          Individual Submission
Pages:          10
URL:
https://www.ietf.org/internet-drafts/draft-smith-6man-link-locals-off-link-00.txt
Status:
https://datatracker.ietf.org/doc/draft-smith-6man-link-locals-off-link/
Htmlized:
https://tools.ietf.org/html/draft-smith-6man-link-locals-off-link-00

Abstract:
   Certain link-layers limit reachability for one set of nodes, while
   permitting full reachability for a different set of nodes, for
   unicast, multicast and broadcast traffic.  If IPv6 hosts are members
   of the first set of nodes, and IPv6 routers are members of the
   second, Link-Local traffic between IPv6 hosts will fail, due to the
   default on-link assumption for Link-Local destinations.  This memo
   describes the use of a Link-Local Prefix Information Option to
   indicate to these hosts that Link-Local destinations are "off-link",
   and are reachable via their default router(s).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Aug 2015 14:03:09 +0200

Mark,

</nochair>

> Multi-Access Links" e.g., TR-101 N:1 VLANs or "Private VLANs”.

I have to admit some scepticism about this subnet model.
I could sort of understand the justification for it for IPv4, but why do you need it for IPv6?
if you need L3 isolation, why pretend that nodes share the same subnet? in IPv6 you could easily put each node on separate subnets.

also, if you continue with the semi-shared subnet model, do you need link-local communication between nodes? instead of advertising FE80::/10 as off-link, can’t you just block any inter-node LL traffic?

cheers,
Ole

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Aug 2015 15:58:16 +1000

Hi Ole,

On 17 August 2015 at 22:03, Ole Troan <[email-masked]> wrote:
> if you need L3 isolation, why pretend that nodes share the same subnet?

I don't think people are actually wanting L3 isolation. I think what
they want is the first hop device for all traffic, which can inspect
the traffic for security reasons. If the traffic passes the security
checks, and the destination is on the link it received it from, it
sends it back out the same interface.

IPv6 hosts assume non-Link-Local destinations are off-link, unless
informed otherwise by the L bit in the PIOs, meaning that the default
router(s) are in a position to inspect intra-link IPv6 traffic for
non-Link-Local destinations. In other words, ULA and GUA traffic can
and will reach other hosts sharing the same link, not directly over
the link, but indirectly via a router attached to the link. So there
is no layer 3 host isolation occurring if ULA or GUA addresses are
used.

That fails for Link-Local destinations on CBMA links because hosts
assume Link-Locals are on-link.

My proposal is to be able to inform hosts that Link-Local destinations
are "off-link" too, so that Link-Local traffic is also sent via a
first hop device for inspection. If it passes inspection, it is
forwarded back onto the link to its final destination. Routers are
allowed to forward Link-Local traffic back onto the same link
according to RFC4007, just not onto different links, as per RFC4291.

Is my explanation of this in the draft unclear?

> in IPv6 you could easily put each node on separate subnets.
>

I don't think it is always that easy. How do you do that on Wifi
networks? The only way I can think of is to have per-host SSIDs, and I
don't know how easily that could be done (attach to a shared visible
SSID, that then informs the host as to which (hidden) SSID it is to
use, ensuring 1:1 host to SSID? does such a mechanism exist?)

Hosts sharing the same subnet is simpler and would create less control
plane load than per-hosts subnets, which results in per-subnet control
plane state, variables and timers, and individual per-subnet RAs, due
to unique PIOs.

This control plane load becomes a concern on BRASes/BNGs with
per-subscriber subnets when supporting 1000s of PPPoE sessions. The
TR-101 N:1 VLANs model is much better in this regard, because one
single multicast RA is for all devices attached to the VLAN.

> also, if you continue with the semi-shared subnet model, do you need link-local communication between nodes? instead of advertising FE80::/10 as off-link, can’t you just block any inter-node LL tra…

Blocking of inter-node LL traffic is inherent in the CBMA links. But
that is a problem because IPv6 applications are allowed to use LLs,
and address selection will prefer them if there is a choice between
LLs and ULA or GUAs. Inter-node LL is currently broken on CBMA links
because of the LL on-link assumption, and that may cause applications
that try to use them to fail.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Aug 2015 12:15:50 +0200

Hi Mark,

> sends it back out the same interface.

1:N model: put many subscribers on the same L2, then add stateful filtering functions in Ethernet bridges to ensure what’s effectively a unidirectional point to point link to the first-hop router. the bridges are essentially layer violating middleboxes dynamically creating state based on snooping DHCP and ND.

is that a fair description of the 1:N model?

(I’m not a big fan as you can tell. ;-))

> assume Link-Locals are on-link.

proxy ND?

> Is my explanation of this in the draft unclear?

no, I think it is clear.
I think my main question is, given the specifics around 1:N deployments, what would be the use case of having a link-local scope larger than first-hop router - single subscriber? what applications would require link-local addresses for this?

> use, ensuring 1:1 host to SSID? does such a mechanism exist?)

I think there are already deployments of this.
we also had a student that implemented a prototype, essentially treating each station on a WIFI network as having a separate P2P link between station and first-hop router/AP. that’s quite trivial to implement and solves all the problems with multicast vs unicast. you don’t need address resolution, no need for DAD and so on.

> plane state, variables and timers, and individual per-subnet RAs, due

our experience is the opposite. especially in a 1:N model, where you by using this model would trade dynamic state both in Ethernet bridges and in routers for configured state. You can do away with the ND cache as well of course.

> that try to use them to fail.

address selection would only prefer them if you gave it a LL DA. in this case there wouldn’t be a way to give it one, right?

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Aug 2015 19:36:32 +1000

Hi Ole,

> is that a fair description of the 1:N model?

Yes. I didn't think they were doing or didn't think it was necessary
to do any layer violation to achieve this in TR-101 networks, as it
hasn't been necessary in Private VLANs.

I think it is probable that snooping of DHCP and ND/ARP is necessary
for IPv4 because there is no commonly known or implemented way of
expressing that addresses within the IPv4 subnet are "off-link" or
reachable via the default router. (I think there might be a way, if
you tell the IPv4 host that it's subnet mask is a /32, then it should
consider all destinations "off-link" or reachable via it's default
router, but I haven't tested it much (I know you can statically
configure that setup on Linux).)

> (I’m not a big fan as you can tell. ;-))

So I don't like the idea of layer violations either, however I like
the idea of N:1 a lot more than the alternative of 10s of 1000s of
PPPoE sessions, with their own IPv6 subnets and therefore their own
individual RAs and their own individual RA timers etc.

On the IPv6 broadband deployment I worked on a number of years back,
our BRAS/BNG was carrying 30 000 subscribers. Even with the RA
unsolicited interval wound out the current maximum of 30 minutes, that
meant sending 16 different RAs per second. Probably not a significant
control plane load, but compared to being able to send a single
periodic unsolicited multicast RA with the same PIOs to all of those
30K subs, it is.

>> assume Link-Locals are on-link.

So proxy ND would be the way to legacy hosts that don't implement what
I've proposed.

There are of course costs:

- hosts are maintaining individual ND entries for their Link-Local
destinations, all pointing to the same link-layer address, and are
performing NUD on each and every one of those entries, which would
load to the router performing proxy ND's control plane.

- hosts are sending multicast NSes for any Link-Local destinations,
increasing the number of multicasts

- the router performing proxy ND either has to listen to all
multicasts to receive NSes for LLs it is proxying for, although it
could be a bit smart and only listen for multicasts to the solicited
node groups that hosts have joined

> I think my main question is, given the specifics around 1:N deployments, what would be the use case of having a link-local scope larger than first-hop router - single subscriber?
>

So to focus on the ISP scenario, ISPs want two things (a) customers to
send more traffic so they can bill for it and (b) customers
applications having the best chance of working, so that customers
don't call the helpdesk. As long as a customer isn't using link-local
traffic to disrupt other customers (e.g, by spoofing RAs etc.), then
an ISP won't care whether inter-customer traffic is using Link-Local
addresses or GUA addresses, as long as they can bill for it.

If an ISP doesn't want to "switch on" what I've proposed, then that is
their choice. The trouble is that currently there is no way to switch
it on even if an ISP (or anybody else using a CBMA link) wants to.

> what applications would require link-local addresses for this?

I don't know.

But does it matter? At the network layer, aren't we not supposed to
care what the applications do with the packets, we just try our best
to deliver them?

On every other link type (BMA, NBMA, P2P), Link-Locals have such a
high likelihood of success of working that if an application has a
choice to use LLs verses ULAs/GUAs, the address selection RFC says
pick the Link-Locals.

This is a network layer constraint dictating what addresses an
application can use, and it doesn't signal that limitation to the
application, so if an application would gain most value from using
Link-Locals, the application now has to have extra code to cope with
LLs failing on some types of link, and then either completely failing
if they only use LLs, or fall back to using ULAs or GUAs if they're
available.

That's application development time that really should be spent on
further application development, not overcoming network layer
limitations. I think we've paid enough of that price with NAT
traversal in IPv4.

> we also had a student that implemented a prototype, essentially treating each station on a WIFI network as having a separate P2P link between station and first-hop router/AP. that’s quite trivial t…

So perhaps that is really saying that all link types should be true
point-to-point, and there is now no place for true multi-access
link-layers and multicasts or broadcasts over them?

> our experience is the opposite. especially in a 1:N model, where you by using this model would trade dynamic state both in Ethernet bridges and in routers for configured state. You can do away with…

Yes, but on high end BRASes/BNGs, control plane resources co$t a lot
more than they do when you distribute state to the more commodity
ethernet bridges's control planes.

> address selection would only prefer them if you gave it a LL DA. in this case there wouldn’t be a way to give it one, right?

As I mentioned above, "layer 5" applications don't know about layer 3
limitations. How would an application know that it can use LLs because
it is attached to a BMA, NBMA or a P2P link, but can't use LLs because
it is attached to a CBMA link?

Is the goal to try to get applications away from having to care about
addresses and address types, and recovering from certain address types
failures in only some scenarios, rather than going the other
direction?

The alternative position I'd take is that if LLs have no chance of
working on some link types, then applications shouldn't really be
allowed to use them at all (and therefore, either a router or DHCPv6
server must always be present on the link to give hosts addresses that
the applications can use.)

Regards,
Mark.