Re: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt]

[Mark Smith <[e-mail]>]

On 1 February 2018 at 20:02, Mikael Abrahamsson <[e-mail]> wrote:

>
> I can only guess what you wrote down here. So I'm going to guess that you
> wrote "You're saying hosts that have a common LL prefix *aren't* on the
> same link?" and answer that.
>
> Your definition if "link" is too rigid. There can be lots of things done
> on L2 that would mean the answer to your question is "well, kind of".
>

It  doesn't matter what my definition is, what matters is what IPv6's
definition is.

IPv6 expects a link supports multicast, so that RAs, ND and DAD work. If
the link doesn't support multicast, it is to be emulated per IPv6 over NBMA.

IPv6 expects any to any unicast, because the Link Local Prefix is marked as
On-link, and that cannot be changed.

IPv6 expects Link-Locals to work for applications when GUAs/ULAs won't,
because IPv6 src/dest selection prefers LLAs over GUA/ULA when given a
choice.

(A perverse situation is that src/dst address selection prefers LLAs over
GUA/ULAs, yet on these types of links, as LLA L=1 (and cannot be changed),
and GUA/ULA is set to L=0 via RA PIO, application connectivity will fail
even though hosts on the link are reachable via the GUA/ULA addresses.
Preferring LLAs makes sense, smaller scope and more local addresses should
be more reliable than greater and less local addresses.)



>
> If two hosts can't talk to each other directly over L2 (all traffic is
> forwarded via the router),

the router (perhaps) defends their respective LLA and does forwarding
> between these LLA addresses, the L2 (perhaps) enforces LLA/MAC address
> mapping (using SAVI) etc, are they on the same link? The router sees all
> their traffic coming in on the same interface.
>


I think having a device pretend to be another is a hack. The better
solution would be to indicate to hosts that they are to reach LLAs via the
router(s) on the link - "Indicating Link-Local Unicast Destinations are
Off-Link"  -
https://www.ietf.org/archive/id/draft-smith-6man-link-locals-off-link-00.txt

Then you still have the multicast reachability issue, meaning that ND and
DAD don't work.

The answer would appear to be DAD Proxy (RFC6957). Trouble is, that is also
a hack because it is one device pretending to be another. DAD Proxy doesn't
specify how two routers on the link for redundancy are to work either.
(There's some discussion of this multicast issue in the draft towards the
end of the "IPv6 over CBMA Links" section.)

When you're down a complexity, hacks and work arounds rat hole like this, I
think it is worth stepping back and asking "what problem are you trying to
solve"?

So what is all this hackery trying to achieve? To overcome link layer
constraints imposed by the same people who chose put them there in the
first place?!

Why are people trying to put multiple entirely untrusted hosts within the
same IPv6 subnet/on the same link that assumes implicit host trust?

Why are people, in one part of the network, likely using subnets/virtual
links to group together trusted hosts, meaning they're using network layer
subnets to create trusted host security domains to implement security
policy, yet in another part of the network, choose to group together
entirely untrusted hosts in the same subnet/link?!

Regards,
Mark.



>
> The answer is: "Well, kind of, but not really".
>
> It's complicated.
>
> On Thu, 1 Feb 2018, Mark Smith wrote:
>
> On 31 Jan 2018 20:49, "Mikael Abrahamsson" <[e-mail]> wrote:
>>
>> On Wed, 31 Jan 2018, Mark Smith wrote:
>>
>> RFC8273 fails the proper layer 2 isolation/per-host link/LAN requirement
>>
>>> too.
>>>
>>>
>> No, it doesn't. It just doesn't specify how this is to be achieved. I am
>> of
>> the opinion that it doesn't need to, and it shouldn't. Yes, someone
>> implementing this should make sure that L2 assures that customers can't
>> spoof each other, that source validation etc is in place, but I am of the
>> opinion that RFC8273 doesn't need to specify how that should be done.
>>
>>
>> The hosts are all sharing the same Link-Local prefix, rather than each
>> host
>>
>>> having its own instance of the Link-Local prefix. They're all using the
>>> same router interface, rather than each host having its own dedicated
>>> router interface. There is sharing of IP layer resources between multiple
>>> hosts, so the hosts are not on separate links.
>>>
>>>
>> Sure.
>>
>>
>> Per RFC4291, in the Addressing Model section,
>>
>>>
>>> "Currently, IPv6 continues the IPv4 model in that a subnet prefix is
>>>   associated with one link."
>>>
>>> multiple hosts that share just one common IPv6 subnet of possibly a
>>> number on the link are members of the same one link.
>>>
>>>
>> But the GUA prefix isn't the same, just the LLA.
>>
>>
>>
>> You're saying hosts that have a common LL prefix *aren't* on the same
>> link?
>>
>>
>>
>>
>> So when a host attaches to a port, the layer 2 device allocates a new
>>
>>> virtual link, dedicated to the host, and then signals the router, which
>>> then allocates a new Link-Local prefix, new GUA and possibly ULA prefix,
>>> and then creates a new router interface for that individual host?
>>>
>>>
>> No. Those are your requirements, it's you who are saying all of those are
>> needed. Not me.
>>
>>
>> I don't have any experience or detailed knowledge of it , however I'm
>>
>>> reminded of Access Node Control Protocol - RFC6320. Perhaps a generalised
>>> version of that for other types of layer 2 edge devices might be an
>>> option.
>>>
>>>
>> PPPoE doesn't solve the mac address duplication problem, either. Only
>> separate L2 per user solves that.
>>
>> So what I have been proposing for lots of years is to keep the 1:N model
>> for IPv4 (because that's what a lot of people do), but create
>> one-vlan-per-user for IPv6, using ethertype based vlans. This requires no
>> host changes.
>>
>>
> --
> Mikael Abrahamsson    email: [e-mail]
>