Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

[Lorenzo Colitti <[e-mail]>]

On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont <[e-mail]> wrote:

> While reviewing this document a few days ago, I found that Section 4
> (page 5) contains what is a protocol spec, rather than an operational
> BCP. It contains rules regarding how to set the link-layer address (to a
> unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
> now remember which prefix has been "leased" to which node -- something
> that seems to be way outside of the v6ops charter, and that should have
> been done in 6man, instead.
>

I don't see how this is a protocol change. Sending RAs unicast is already
allowed by RFC 4861, so this is just an operational practice.

Looking at diffs, it seems this additional text was incorporated very
> recently, in version -09 of the I-D, published in mid September
> (<https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-
> unique-ipv6-prefix-per-host-09.txt>).
> It seems to be that this change is way beyond what the authors
> originally proposed
>

The additional text did not actually change this practice at all. It simply
clarified what has always been a fundamental premise of this operational
practice: if you want to give each host its own prefix, you need to ensure
that the RA with that prefix is only received by that host.

1) The protocol spec specified in this document requires the SLAAC
> router to keep state of the "leased" prefixes -- what seems a major
> change to SLAAC, which now would be kind of as stateful as DHCPv6.
>

This is a bizarre claim. The first-hop router must always have fully
up-to-date state on all the prefixes it is sending RAs for, otherwise it
cannot fulfill its fundamental purpose of forwarding traffic to those
prefixes. The word "stateless" in SLAAC applies to addresses configured to
the host, not how routers route traffic.

2) There are scenarios in which multiple nodes might receive the same
> packet -- say a NIC let's the packet through because it is in
> promiscuous mode -- wich could possibly lead to two nodes configuring
> the same prefix.
>

Why do you say promiscuous mode is a problem? Even in promiscuous mode,
network stacks already understand which packets are being send to the host
network stack and which are not. For example, in the linux networking
stack, well before the packet ever gets to the ICMPv6 protocol handlers
that would process incoming RAs, ipv6_rcv does:

if (skb->pkt_type == PACKET_OTHERHOST) {
kfree_skb(skb);
return NET_RX_DROP;
}

3) What happens if the SLAAC router crashes and reboots, loosing state
> of the "leased" prefixes?
>

You seem to be assuming that the router does not store the prefixes in
stable storage. It's certainly the case that if you want this scheme to
work across router crashes, then you need to ensure that the prefixes are
stored somewhere. That sort of seems self-evident, but we could add it to
the text.

4) How are prefixes selected? And, what's the minimum size of the pool
> of prefixes for the selection algorithm not to break due two "prefix
> collisions"? Does the selection algorithm have any specific properties?
>

I see no reason why this should be in scope for this document.