Add an appendix to address issue 52, the topology taxonomy

[Abhayakara]

Fixes #51 Fixes #56

[EskoDijk]

@Abhayakara The new sections need to go in just after all the "", otherwise the XML doesn't build (order is fixed).

[EskoDijk]

Question on the cases included: isn't there a case possible where

• network is managed and is IPv6
• only DHCPv6 addressing is used (as intended by operator) - assume DHCPv6 hands out ULA addresses
• no RA-Guard is applied
• user brings stub router, plugs it in, and it advertises a ULA prefix in PIO
• other devices on the link start configuring a SLAAC IPv6 address and try to use this to communicate (and routing fails because the DHCP managed ULA was not used as the source, but rather the SLAAC based ULA)

But maybe this is not relevant because the source address selection algorithm would always pick the correct, managed ULA due to a better prefix match with the IPv6 destination address ?

[Abhayakara]

Regarding the DHCPv6-only use case, we are assuming that the network operator wants to control which devices have addresses on the local link. In this case, they MUST use RA Guard. If they do not, then there is no protection against random devices sending RAs. So this would be a misconfiguration, and hence we don't need to do anything about it.

[EskoDijk]

@Abhayakara Right, I also agree we don't have to do anything about solving this "problem" other than pointing to RA guard. But still I think it's worth mentioning: it's the one identified corner case where the SNAC router has unwanted side effects. I wasn't even sure if I was correct in predicting the effects.

Considering that there is I think no other IETF-specified / IETF-compliant device that, when plugged in, would instantly disrupt this network in the way that the stub router does.

If this is the worst case we can find, it should actually show that our stub router is good to go.