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

[Fernando Gont <[e-mail]>]

On 11/13/2017 11:07 AM, Ole Troan wrote:
> Fernando,
> 
>>> Or do as I do in my implementation.
>>> Model each host as being on it's own point to point interface.
>>> Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.
>>
>> The I assume that, in that case, you don't need to do anything fancy
>> with how you send the multicasted RAs, and the SLAAC router
>> implementation need not keep a table of bindings?
> 
> That's correct.

Then that's okay from the pov of slaac specification. The I-D in
question could focus on what it wants to achieve and, if anything, point
that this can be achieved with DHCPv6-PD, but there are also products
that achieve the same thing via "virtualization + slaac" (or something
along these lines). And the protocol-specific details from Section 4
(how you send the RAs, etc.) can and should be removed.

Question: is the motivation of this "mechanism" to stick to SLAAC,
because Android does not support DHCPv6?



> The interfaces look like:
> interface P2P-Ethernet0 remote-mac aa:bb:cc:dd:ee:ff
>  ipv6 address 2001:db8::1/64
> 
> Think of it as an interface with a fixed L2 address for the remote end.
> L3 to L2 address mapping is then fixed, both for unicast and multicast.
> Should that have it's own internet draft, very possibly?

If this is somethings that is deemed as useful (I guess it is, if you
implemented it), then: definitely. The document could also discuss
details such as how you time out prefixes, etc. e.g., if a node
vanishes, for how long do you keep the lease/virtual-interface? If you
run out of prefixes, do you just ignore new RSes? Do you base the
generation of the prefix on the MAC address?  How does this work, given
n prefix bits to play with, in the presence of nodes that vanish, nodes
that randomize MAC addresses, etc. Is this expected to work across
crash&reboot events? What's expected to happen in the presence of such
events?

I'm sure you made decisions on all of these things when you implemented
this...and that's stuff is certainly useful. Not only to understand how
this works, but also for folks that might want to implement this on
their own.



> In the vein of all problems in computer science can be solved with another layer of redirection.
> How these interfaces are created and how they are maintained across reboots etc, can be considered out of scope for the SLAAC feature.

If the implementation approach is as you've described, this is outside
of the SLAAC specification, indeed (nobody can prevent you from spawning
instances of SLAAC that behave according to the existing standards).
>From a operational point of view, one would wonder why pursue this path
as opposed to e.g. do DHCPv6 -- even if that means: we want to support
Android, and Android does not support DHCPv6. And also if this is a best
current practice, or just one possible deployment strategy ("you should
do this" vs "we have done this").

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