On Wed, Aug 01, 2018 at 07:12:42PM -0400, Michael Richardson wrote:
> The ACP addresses (including interface identifiers) are assigned by the ANI
> Registrar, and are embedded in certificates issued by the Registrar.
> Schemes 6.10.2 and 6.10.3 support this mechanism.
Right.
> Section 6.10.4 is about very much MANUAL allocation, which is basically
> a non-zero-touch backdoor which nobody is supposed to use, unless they aren't
> doing ANI stuff.
"Nobody..." ;-)
The ACP connect construct is short term the ACP version of the
20 IPv6 transition mechanisms, so given how we only need one scheme,
and not 20, that's pretty good. Aka: not being able to put IPsec
secure channel code into existing NMS servers.
Long term this ACP-connect also makes sense when my nodes start to become
virtualized, and the links between nodes are linux bridges or Veth
configured by an orchestrator. Quie arguable if you want/need/benefit of running
IPsec over those virtual links. This is discussed in 8.1.2.
> Really, it's about the Registrar doing it's work (section 6.10.7), and the
> only reason to have any statements about addressing schemes is so that we can
> paint off some areas for manual allocation. (I didn't want any of these
> schemes here,
> I don't think it helps, but maybe it causes no harm).
Yes, long discussion with JoelH about this as well towards -16. I
definitely wanted to carve out the manual space explicitly so that
any better implementation can prohibit explicit configuration of
the anon-manual prefixes, so routing for them can not be messed up
through manual config or SDN controller. And i didn't want to leave
the ACP connect addressing to random chance if as explained above we may
have also strategic uses for it, and even short-term its nice for
operators to have recommendations for an address plan to use.
> The explanation in 6.10.7.2 further allows for multiple Registrars to operate
> without coordinating via a centralized database (or blockchain).
Yepp. Just need to add "without centralized ACP addressing coordination".
Still need coordination for security via CAs (Ekr's comment).
> So, by all means, suggest an RFC8064 IID in the UI when configuring a manual
> address, but if the admin is even close to that part of the configuration,
> then they probably meant to do something very specific.
See reply to Brian.
Cheers
Toerless
> --
> ] Never tell me the odds! | ipv6 mesh networks
> [
> ] Michael Richardson, Sandelman Software Works | network architect
> [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> [
>
>
>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
