Subject: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host)

From: Mark Smith <[email-masked]>
Date: Thu, 24 Aug 2017 20:17:34 +1000

On 24 August 2017 at 18:13, Ole Troan <[email-masked]> wrote:
>>> On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L <[email-masked]> wrote:
>>> With RFC7934, we already have BCP recommendations on host address availability
>>> With the advent of these recommendations and practices, we see an operational
>>> advantage for hosts to discover the delegated prefixes of neighbors on the link so
>>> that communications can go directly from peer to peer for better performance
>>> and to reduce the load on routers.

<snip>

>> If you want hosts on the same link to communicate directly, we already know how to do that, use classic multiple host per prefix subnets. As I said before this mechanism isn't intended as a universal replacement for classic subnets.
>
> Indeed. The only difference is that host to host now happens at L3 instead of L2.
> That hosts are on the same link is typically emulated at L2, we largely stopped building shared media links in the 80s. ;-)
> This is just making the L3 topology reflect reality.
>

The trouble is that IPv6 by default doesn't really reflect that
reality. Its link layer reachability assumptions are inconsistent.

Per RFC5942, the link-local prefix is assumed to to be on-link, so
link-local destinations are assumed to be directly reachable across
the link, while all other prefixes are to be assumed off-link, so all
other destinations have to be reached via a router.

The link-local direct reachability assumption also exists is in the
RFC6724 source/destination address selection algorithm, as link-local
destinations are preferred over ULA and GUAs if there is a set of
destinations to choose from.

An a "private VLAN", this LL on-link/GUA/ULA off-link assumption could
cause an end-user application problems. For pure IPv6, the LL
connection attempt will have to fail before the ULA and/or GUA
destinations are attempted, likely incurring end-user visible
multi-second delays, and then they're likely to succeed because the
router will trombone the traffic back onto the link to the
destination. (i.e., Nodes A and B on same link, A -> B via LL fails, A
-> RTR -> B via ULA/GUA succeeds).

If the application is using Happy Eyeballs, the failure of the IPv6 LL
would cause the IPv4 alternative to be used even though alternative
ULA or GUA destinations would have probably worked immediately.

Regards,
Mark.

---

From: DY Kim <[email-masked]>
Date: Thu, 24 Aug 2017 19:53:43 +0900

Questions for clarification:

---
DY

> On 24 Aug 2017, at 19:17, Mark Smith <[email-masked]> wrote:
> 
> Per RFC5942, the link-local prefix is assumed to to be on-link,

Do you mean, by ‘link-local prefix', specifically the prefix ‘FE80’ (1111 1110 1000) as specified in Sec. 2.4.6 of RFC4291?

> so link-local destinations are assumed to be directly reachable across
> the link

Do you mean, by ‘link-local destination’, the Link-Local IPv6 Unicast Address as defined in Sec. 2.4.6. of RFC4291?

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Aug 2017 21:41:20 +1000

> other destinations have to be reached via a router.

By default I mean. The RA PIO L flag changes the off-link assumption
for other non-LL on-link prefixes if set for them in the corresponding
RA PIOs. It isn't possible to invert the LL on-link assumption so that
LL destinations that are also on the same link are then reachable via
a router on the link.

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

---

From: DY Kim <[email-masked]>
Date: Thu, 24 Aug 2017 20:50:53 +0900

A typo…?

Did you mean to say:

  "LL destinations that are also on the same link are then directly reachable.”

---
DY

> On 24 Aug 2017, at 20:41, Mark Smith <[email-masked]> wrote:
> 
> It isn't possible to invert the LL on-link assumption so that

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Aug 2017 21:50:47 +0200

Mark,

> -> RTR -> B via ULA/GUA succeeds).

I don't think we should blame IPv6 subnet model for the hack of private VLANs.
And of course if you map L3 subnets to the physical topology and do s/bridging/routing/g then this problem doesn't exist.

> ULA or GUA destinations would have probably worked immediately.

A typical application wouldn't not connect using an link-local address.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Fri, 25 Aug 2017 10:50:29 +1000

> I don't think we should blame IPv6 subnet model for the hack of private VLANs.

I don't think I am.

I think some things have changed over time, and the consequences of
the changes may not have been fully recognised.

 - we have a new type of link now - "constrained broadcast
multi-access" (in addition to p2p, NBMA, and "Broadcast Multi-Access"
e.g. traditional Ethernet/TR/ARCnet etc.). There are multiple examples
- Private VLANs, TR101 VLANs with 1:N forwarding, 802.11 with station
isolation. They're common and they're not going to go away.

- we are now attaching untrusted and potentially malicious hosts to
the same link. We used to only attach trusted hosts to the same link,
with link boundaries (e.g., VLAN boundaries) being the security/trust
domain boundaries. Trust of hosts/nodes was also inherent in the
link-layer forwarding capability of any-to-any. Private VLANs etc. are
a response to now untrusted host attachment to the same link.

I think it should be clear in discussion and now specifications as to
whether the hosts or more generally nodes attached to the same link
are trusted or not by their link peers.

> And of course if you map L3 subnets to the physical topology and do s/bridging/routing/g then this problem doesn't exist.

RFC4007 permits packets with LLs to be routed, as long as it is back
out the same interface that the packet was received on. However, it
isn't possible to instruct hosts to send LLs to a router to be
forwarded back onto the link - they'll always ND for the destination
because of the RFC5942 LL on-link default.

> A typical application wouldn't not connect using an link-local address.

MDNS specifies to use LLs, so any application service that is
announced using MDNS expects to use LLs.

"IPv6 Address Usage Recommendations"
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-03

recommends using IPv6 address scopes to limit the attack surface of
listening application services e.g., bind to ULA rather than GUA if
the service is only to be accessed from within the local network. In
cases where it would be useful and possible, binding a service to only
Link-Local addresses reduces that attack surface further.

I think there are other benefits of using Link-Local addresses in applications:

"How to use IPv6 Link-Local Addresses in Applications"
https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Aug 2017 13:32:15 +1200

On 25/08/2017 12:50, Mark Smith wrote:
...
> are trusted or not by their link peers.

That's a serious and complex issue. We are trying to tackle it for the
specific case of forming an Autonomic Control Plane in ANIMA, and it
needs 3 substantial drafts so far:
draft-ietf-anima-voucher
draft-ietf-anima-bootstrapping-keyinfra
draft-ietf-anima-autonomic-control-plane

At the level of basic IPv6, I don't really see how we can tackle this,
except by stating that all nodes are untrustworthy until proved otherwise.

...
> I think there are other benefits of using Link-Local addresses in applications:

You can't avoid using them during the bootstrap phase of forming a secure
network after a cold start. And they come in mighty handy when running an
IPv6-only app on a LAN with no IPv6 router ;-).

   Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Aug 2017 09:06:59 +0200

> On 25 Aug 2017, at 03:32, Brian E Carpenter <[email-masked]> wrote:
> 

If you follow the model of having IP topology follow the physical topology LANs are gone. You are left with a set of p2p links. 

Ole

---

From: [email-masked]
Date: Fri, 25 Aug 2017 09:42:33 +0200 (CEST)

> If you follow the model of having IP topology follow the physical topology LANs are gone. You are left with a set of p2p links. 

Agreed. However, I think this may be an even bigger change, especially
for enterprises, than starting to use IPv6. As a networking guy I love
p2p links, but I also see how much our IT people love their LANs :-)

Steinar Haug, AS2116

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Aug 2017 15:21:42 +0200

Steinar,

> p2p links, but I also see how much our IT people love their LANs :-)

Yes, I think this one is considered in the area of "what socks has he been smoking now!" ;-)

Got running code though:
https://gerrit.fd.io/r/#/c/7224/

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Aug 2017 11:22:44 +1200

> p2p links, but I also see how much our IT people love their LANs :-)

Agreed. I think LANs will be a great deal harder to get rid of than IPv4.

Apart from anything else, there seems to be no consistent o/s-independent
model for VRFs. I don't see how to progressively hide the LAN model
without that. (We are grappling with this issue in ANIMA.)

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Aug 2017 10:45:33 +1000

Hi Brian,

> except by stating that all nodes are untrustworthy until proved otherwise.

I think whether hosts are allowed to send directly to each other over
a link, or must go via a router, is an expression of their
trustworthiness. I think the off-link default assumption for non-LL
prefixes is expressing a default host distrust.

Having to go via a router for all destinations creates an opportunity
for the router to do more than just layer 3 forward the packets back
onto the same link to their destination as it can perform
security/firewall functions on the traffic. Layer 2 forwarding
constraints such as Private VLANs enforce that.

I don't think we could change the default on-link assumption for LLs,
however I'd like it to be possible to have a router override that
default (via an RA PIO for the LL prefix, with the L bit set to off),
so that LL destinations are also considered "off-link" and must go
through the router too. That would allow applications to use LL
addresses to reach other hosts on the same link via a router, while
also creating an opportunity to have that router perform more detailed
traffic inspection if needed. Per RFC4007, routers are allowed to
forward packets with LL addresses, as long they are forwarded back
onto the link they arrived on.

In combination with layer 2 enforcement, it would also be a more
general purpose way of performing things such as RA guard, rather than
trying to have layer 2 devices inspect layer 3 packets (parse EH
chains, defragment etc.)

Being able to invert the on-link LL status would then allow the
on-link/off-link treatment of all prefixes to be consistent on a link.

One use case I think of is a residential Wifi LAN. I have a number of
devices over which I don't have administrative rights e.g., VOD
devices, smartphones etc. I need them all to be on the same LAN so
that MDNS etc. discovery works. However, I'd like to have them hairpin
all their unicast traffic, including that over LLs, through my router,
so that I can use the router as a traffic security policy enforcement
point.

> IPv6-only app on a LAN with no IPv6 router ;-).

Agree, requiring a router so that hosts attached to a single link can
communicate may be doing no more than adding a single point of
failure.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Aug 2017 11:38:38 +1000

> Agreed. I think LANs will be a great deal harder to get rid of than IPv4.

+1

I think the use of subnets as a method of creating host security
domains is probably where the most resistance would come from.

I was surprised to find that in a recent environment I worked in, host
firewalls on VMs were actively disabled and removed (I think meaning
the configuration utilities removed) because the model of using
subnets as security domains and having network firewalls at subnet
boundaries was so ingrained (the security model wasn't mine to debate,
what I wanted to use the host firewalls for was to have
per-application/service e.g DNS protocol packet counters visible on
the hosts)

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Aug 2017 11:51:05 +1000

> Do you mean, by ‘link-local prefix', specifically the prefix ‘FE80’ (1111 1110 1000) as specified in Sec. 2.4.6 of RFC4291?

Yes.

> Do you mean, by ‘link-local destination’, the Link-Local IPv6 Unicast Address as defined in Sec. 2.4.6. of RFC4291?

Yes.

"on-link" and "off-link" are understandable names, however they become
a bit confusing when referring to the "link-local" prefix and
addresses.

"on-link" really means "might be directly reachable across the local
link", where as "off-link" really means "ask a router", even if the
destination might be on the same local link.

While it isn't possible currently, a Link-Local prefix could be
flagged as "off-link", meaning a host would "ask a router" for any LL
destinations. Per RFC4007, "IPv6 Scoped Address Architecture" routers
are allowed to forward packets with LL destinations, as long as
they're forwarded back out the same interface they arrived on.

This draft suggests how it could done, the thing I didn't get around
to working out was how to include quotes in the title field. I'll add
them here.

'Indicating Link-Local Unicast Destinations are "Off-Link"'
https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Sat, 26 Aug 2017 08:36:30 +0200

> On 26 Aug 2017, at 02:45, Mark Smith <[email-masked]> wrote:
> 

How would the host reach the default router?

Ole

---

From: Ole Troan <[email-masked]>
Date: Sat, 26 Aug 2017 08:42:34 +0200

> On 26 Aug 2017, at 01:22, Brian E Carpenter <[email-masked]> wrote:
> 

I am ANIMA ignorant, so bear with me. Why would hosts need to deal with VRFs?

Ole

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Aug 2017 18:34:32 +1000

> How would the host reach the default router?

RAs provide the router's LL address. Going by RFC4861, I think it may
be necessary to create a /128 entry in Prefix List for the router's LL
address, with the Router's LL address being flagged as on-link. That
would then create a Destination cache entry for the router when the
first packet is sent to it. That would then also create a Neighbor
cache entry and possibly trigger an NS/ND for the router's LL address.

It may not be necessary to create a /128 entry in the Prefix List. I
find the RA processing section of RFC4861 (6.3.4.) a little unclear in
the area of whether a ND cache entry should always immediately be
created for the router's LL address. It seems to be saying an ND cache
entry for the router's LL is only created or updated if there is a
Source Link-Layer Address option. If an ND cache entry is created
(which may trigger an NS/ND) and the Destination cache and Neighbor
cache are the same structure, then a /128 entry wouldn't need to be
added to the Prefix List for the router's LL address.

It would probably be good to create a /128 entry for the router's LL
address in the Prefix List regardless, to make it clear that the
router's LL address is considered on-link even though other
destinations in the LL prefix aren't.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Aug 2017 21:24:48 +1000

On 24 Aug. 2017 21:50, "DY Kim" <[email-masked]> wrote:

A typo…?

Did you mean to say:

  "LL destinations that are also on the same link are then directly
reachable.”

No.

Per RFC5942, LL destinations are on-link.

Per RFC5942, all other destinations e.g. GUA default to off-link.

For these other destinations, they can be switched to on-link using a RA
PIO with the L bit set for the prefix.

It is not currently possible via an RA PIO to switch the LL prefix to
off-link.

(Remember, "off-link" means "ask a router".)

---
DY

---

From: DY Kim <[email-masked]>
Date: Sat, 26 Aug 2017 20:28:39 +0900

Oh… you want to route LL destinations also via the default router, not directly…

---
DY

> On 26 Aug 2017, at 20:24, Mark Smith <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Aug 2017 08:32:59 +1200

> I am ANIMA ignorant, so bear with me. Why would hosts need to deal with VRFs?

The intention is to build the autonomic control plane as a secure overlay network
on top of link-local connectivity, so that it has no dependency on regular
routing and addressing. So every autonomic node needs a VRF mechanism. But this is
not my bit of ANIMA, so I have to refer you to draft-ietf-anima-autonomic-control-plane.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 27 Aug 2017 16:22:25 +1000

On 26 Aug 2017 21:28, "DY Kim" <[email-masked]> wrote:

Oh… you want to route LL destinations also via the default router, not
directly…

Yes. Direct is the default, and cannot currently be overridden.

---
DY

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Aug 2017 08:29:34 +1200

> Yes. Direct is the default, and cannot currently be overridden.

It's more than that. It's a matter of *definition*. If X and Y are on the
same link, X can send layer 2 packets directly to Y. If you put measures
in place to prevent that happening, they are no longer on the same link in
any meaningful way. This is why most layer 2 "switches" emulate 1983-style
Ethernet yellow cable and why the more clever ones perform MLD snooping,
so that the overhead traffic for emulated multicast is limited.

If you take that away, your *only* link-local neighbour is the switch
itself. You can never discover any other LL neighbour and therefore never
send packets to it, because it doesn't exist.

Now you could, in theory, make my head hurt by also performing LL snooping
in the "switch", so that it emulates yellow cable for some addresses in
fe80::/10 but not others, but why you would do that instead of just using
a VLAN beats me.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Aug 2017 08:20:13 +1000

On 28 August 2017 at 06:29, Brian E Carpenter
<[email-masked]> wrote:
> any meaningful way.

It sounds like you haven't heard of "Private VLANs" or Broadband Forum
TR-101 N:1 VLANs.

These LANs are more similar to NBMA or the RFC4861 "shared-media"

shared media   - a link that allows direct communication among a
                    number of nodes, but attached nodes are configured
                    in such a way that they do not have complete prefix
                    information for all on-link destinations.  That is,
                    at the IP level, nodes on the same link may not know
                    that they are neighbors; by default, they
                    communicate through a router.  Examples are large
                    (switched) public data networks such as Switched
                    Multimegabit Data Service (SMDS) and Broadband
                    Integrated Services Digital Network (B-ISDN).  Also
                    known as "large clouds".  See [SH-MEDIA].

(SH-MEDIA IS RFC1620).

with the difference being that it is not possible to use or create a
shortcut path between the attached nodes. That is layer 2 security
being imposed on inter-node communication.

So why "Private VLANs" instead of per-host physical or logical p2p links?

- no need for a router interface (logical or physical) per host

- no per-host router interface configuration

- no per-host subnet assignment and subnet identifier management

- in the case of logical p2p links e.g., VLANs, no virtual link ID management

- less likelihood of running out of virtual link IDs - For VLANs, 4094
host-VLANs in a network is a lot lower threshold than 4094 multi-host
VLANs.

In a broadband scenario, using VLANs limits the subscribers attached
to 4094, which for a BNG is a low number. Double VLAN tagging can be
used to resolve that, however that creates configuration and ID
management overhead for the subscriber termination devices e.g. ADSL
DSLAMs. TR-101 N:1 VLANs create subscriber separation without that
overhead.

- no router configuration needed to aggregate the downstream address space

With p2p links, usually would aggregate those subnets into a single
prefix before announcing them to upstream routers. A trivial task,
however another thing to remember to do and to possibly make an error
doing.

- can have router redundancy, because 2 routers can be made visible to a host

No such thing as a "3 ended" point-to-point physical link. Could be
done with per-host VLANs, however now all the above router
configuration complexity is duplicated across two routers.

There can be limits on how many instances of things such as VRRP that
can be run on a router, which may impose a limit on how many VLANs can
exist and therefore hosts that can be attached.

- conceptually more similar to the way hosts have been attached to
multi-access LANs for many years (Less likely today, however many
people for many years would have looked at you funny if you said we're
going to create a subnet and VLAN per host)

IP subnets have been used for many things over the years. In this
case, the fundamental advantage of placing all hosts in a single
subnet, even though functionality they're closer to being attached to
p2p links, is that it is effectively creating a dynamic pool of p2p
links without having to perform the corresponding p2p related IP
subnet and link-layer configuration and management. It's a
configuration and maintenance optimisation.

Regards,
Mark.

> This is why most layer 2 "switches" emulate 1983-style

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 27 Aug 2017 18:33:15 -0400

Mark, it sounds like you are describing a situation where, for IP 
purposes, none of the leaf hosts are on the same "link" as any other 
leaf hosts.  For some other purposes, they may or may not be on the same 
"link".

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Aug 2017 11:06:40 +1200

On 28/08/2017 10:20, Mark Smith wrote:
>                     that they are neighbors;

I've generally found it beneficial to ignore the BBF, but that is *exactly*
what I'm saying - if they don't know they are neighbours, they are *not*
neighbours in any meaningful sense. They can't detect each other's existence,
so the notion of talking to each other using link-local addresses is
meaningless, and the notion of on-link determination is also meaningless,
because ND won't work anyway. So for all practical purposes they are not
on the same link.

   Brian

> ...by default, they

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Aug 2017 09:10:15 +1000

Hi Joel,

On 28 August 2017 at 08:33, Joel M. Halpern <[email-masked]> wrote:
> Mark, it sounds like you are describing a situation where, for IP purposes,
> none of the leaf hosts are on the same "link" as any other leaf hosts.  For
> some other purposes, they may or may not be on the same "link".
>

It is certainly a matter of perspective.

The perspective I think I'm taking is the IP one - if a group of hosts
are members of the same subnet(-prefix per RFC4291) (explicitly, have
addresses with a common subnet-prefix), and the model IP follows
assigns a subnet-prefix to a link, then that group of hosts with the
common subnet-prefix are attached to the same link according to IP.

Sure, at layer 2 the link may be constructed of physical p2p links,
and the shared nature emulated (with things like Private VLANs
changing the emulation function). That physical multi-link topology
isn't visible to the IP layer because the IP layer believes that hosts
with a common subnet-prefix are all attached to the same one link.

So if the true physical p2p link nature of the link-layer was exposed
to IP, and we follow the IP model, then that means that each of those
p2p links needs to have its own subnet-prefix.

(Just because I looked it up to be sure, here is what RFC4291 says in
the Addressing Model section:

" Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.")

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Aug 2017 10:22:57 +1000

On 28 August 2017 at 09:06, Brian E Carpenter
<[email-masked]> wrote:
> I've generally found it beneficial to ignore the BBF,

BBF didn't invent this. Private VLANs have been around for about 15
years or more. From memory, they were created to save IPv4 address
space, avoiding losing .0 and subnet broadcast addresses for each
subnet/VLAN. That requirement doesn't apply to IPv6, however people
are going to want to add IPv6 to their existing IPv4/Private VLANs
setups, and there are some operational advantages of doing so, per my
earlier list. Mirroring IPv4 and IPv6 routing operation is going to be
a common goal.

Support for them is already on the standards track,

RFC6857, "Duplicate Address Detection Proxy"

"Abstract

   The document describes a proxy-based mechanism allowing the use of
   Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-
   multipoint architecture with a "split-horizon" forwarding scheme,
   primarily deployed for Digital Subscriber Line (DSL) and Fiber access
   architectures.  Based on the DAD signaling, the first-hop router
   stores in a Binding Table all known IPv6 addresses used on a point-
   to-multipoint domain (e.g., VLAN).  When a node performs DAD for an
   address already used by another node, the first-hop router defends
   the address rather than the device using the address."

https://tools.ietf.org/rfc/rfc6957.txt

> but that is *exactly*

To me, devices with the same subnet-prefix are part of the same link
from the IP layer's perspective, per RFC4291,

"Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link."

To me, "on-link" and "off-link" flags are not statements of link
membership, they are instructions for a device on how to determine the
first hop for a packet, and it is possible for different devices
attached to the same link to have different perspectives on the
"on-link" or "off-link" status of a destination.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Aug 2017 14:23:19 +0900

> with a common subnet-prefix are all attached to the same one link.

Building such a network is generally a bad idea because it doesn't work
unless all the addresses can be controlled by the network, and the network
maintains state at all times on all the addresses on the subnet. Example:

   - If two hosts on this "subnet" form the same IPv6 address, they can't
   detect a collision unless the network does DAD proxying.
   - The network must at all times know all mappings between host addresses
   and link-layer addresses, because otherwise it cannot send packets to the
   right host. Sending a multicast NS in this situation allows hosts to steal
   each others' traffic. Therefore, ND cache entries cannot be allowed to
   expire.
   - If a host forms an address and the network doesn't know about it,
   things don't work.

The result of this architecture is that the router must maintain much more
state. In practice this results in the network limiting the number of
addresses that hosts can use, and or requiring the use of an address
registration or assignment protocol in order to use the network.

A vastly superior alternative is to assign each host its own prefix, and
make the link between the host and the router unnumbered.

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Aug 2017 15:48:46 +1000

On 28 August 2017 at 15:23, Lorenzo Colitti <[email-masked]> wrote:
> If two hosts on this "subnet" form the same IPv6 address, they can't detect
> a collision unless the network does DAD proxying.
> The network must at all times know all mappings between host addresses and
> link-layer addresses, because otherwise it cannot send packets to the right
> host. Sending a multicast NS in this situation allows hosts to steal each
> others' traffic. Therefore, ND cache entries cannot be allowed to expire.
> If a host forms an address and the network doesn't know about it, things
> don't work.
>

I don't disagree with any of that.

Would a BCP saying IPv6 SHOULD NOT be implemented over Private VLANs
and similar be the better answer for these reasons? Unfortunately I
don't think that is going to stop people trying to do so.

Actually, I'd forgotten there was a draft about this,

IP over Intentionally Partially Partitioned Links
https://tools.ietf.org/html/draft-ietf-intarea-ippl-00

> make the link between the host and the router unnumbered.

No such thing as an unnumbered link, there's always a link-local
prefix, per RFC4291's required interface addresses, so the above
issues will still exist for the attached host's LL addresses.

There's no escaping these issues and the state to emulate them unless
links are truly point-to-point links between the router and the
host(/cpe) with individual links having their own subnet prefix, or
multi-access links have full any-to-any connectivity.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Aug 2017 14:54:44 +0900

> don't think that is going to stop people trying to do so.

It's definitely a good idea to document these problems, at least.

> multi-access links have full any-to-any connectivity.

Agreed. What I meant was that the hosts should be isolated at layer 2 as
well. The links that I am suggesting be unnumbered (i.e., link-local only)
are the links between the host and the router; where there is one such link
per host.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Aug 2017 08:34:17 +1200

> are the links between the host and the router; where there is one such link

That sounds about right. Whatever the electrical connection might be,
there is a virtual point-to-point link between each host and the router.
The other nodes are not neighbours in any way that IPv6 can recognise.
The only link-local neighbour is the router. ND to ff02::1 won't reach
the other hosts, so the router had better not send a PIO with an L flag.

The nodes will all listen to ff02::1 anyway. But the RAs need to be
tailored so that each host only hears about the prefix(es) that are
relevant to it. Each host is in its own separate world. The router
needs to keep track of them, but it can't treat them as a bunch of
hosts on the same LAN, because they aren't. However it keeps track of
them, it is not a normal neighbour cache for a LAN interface. The hosts
may well issue MLDv2 joins, but that's going to be a no-op for LL
multicast, because the router isn't going to replicate LL multicast
packets anyway.

   Brian