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

[Fernando Gont <[e-mail]>]

On 11/08/2017 11:58 PM, Lorenzo Colitti wrote:
> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont <[e-mail]
> <mailto:[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.

That's incorrect. We are talking about sending multicasted internetlayer
packets to a unicast link-layer address. There's nothing in RFC4861 that
suggests you should do that. RFC6085 says "you shouldn't drop packets if
they are internet-layer multicast but link-layer unicast". But
certainly, unless a protocol spec says otherwise, the normal mapping
applies.

There's nothing in RFC4862 that may suggest "leasing one prefix per
node". In fact, all nodes share all the prefixes being announced. And
when you don't want multiple nodes to share them, you just segment the
network one way or another. From the point of view of SLAAC, there's no
"one prefix per node". If it happens, it's because you segmented the
network, not because SLAAC is meant for that.



>     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
>     <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.

If you want to give each host it's own prefix, you do prefix delegation.
So far, SLAAC doesn't do prefix delegation. If you want to do prefix
delegation in slaac, write a std track document in 6man, not a BCP in
v6ops.



>     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.

A SLAAC router need not maintain any sort of dynamic mapping. It's
static configuration information of the sort "I'm announcing this prefix
on this interface".. If you think otherwise, please point me the section
in RFC4862 where this conceptual data structure is mentioned. (Note:
Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).



>     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;
> }

Great that Linux double-checks this. But it need not. Linux is just one
implementation. A very popular one. But one implementation.




>     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.

Routers store configuration info, not dynamic mappings.

Simple scenario:

With slaac, the network is 100% resilient if a rotuer crashes and
reboots (because, as the name implies, it is stateless). With this
protocol you are specifying in this document, if the router crashes and
reboots, the network may just break -- same prefix may be reassigned to
different nodes, etc.



> 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.

SLAAC stores *configuration information*. This protocol that you are
specifying requires SLAAC to store the *dynamic mappings* of which
prefix was "leased" to which host. And the fact that you need this for
this mechanism to work is an indication that you are specifying a
protocol. (Call it Stateful SLAAC, or AAC ;-) )

An operational practice is when you fiddle with the knobs that a
protocol gives you. Here you are introducing a state machine into SLAAC.
That's certainly not an operational practice, but rather a fundamental
change to SLAAC that makes it a stateful protocol



>     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.

Actually, what's not in the scope of this document, and not within v6ops
charter, is the protocol you are specifying to handle prefixes with SLAAC.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492