Brian:
As explained in reply to Alissa, this was leftover text, so
i could simply remove it, except that i figured that it was wrong
to allow these addresses into the Certs, which lead to the mayor fixes
for Alissas discuss.
The ACP connect LANs are just normal IPv6 subnets, managed via
existing manual methods, SLAAC etc. This is written already for
several revisions of the doc now into 8.1 and specifically 8.1.3.
I did not fancy to bother about recommending any specific SLAAC
enhancements in that section, because i wanted to concentrate
on the important methods only, and thats primarily the route
autoconfiguration (RFC4191) because those NOC nodes will be multi-homed,
one interface on ACP connect subnet, one on Data-Plane, and then
you want to make sure they correctly route the ACP destinations
across the ACP interface only.
I looked through RFC8064 and didn't find it particularily beneficial
for the use-case. It seems to be very much focussed on user-devices
with a browser connected to the Internet and the resulting security
and privacy issues. Not really relevant IMHO for Network Management
servers in a NOC that likely announce their addresses via GRASP
into the ACP anyhow, so those addresses do not need to be stable,
and they certainly can't be private/hidden, and i wouldn't see
how any of the rfc8064/rfc7217 considerations would increase security
for these servers.
Besides, the rfc7217 algorithm recommended by rfc8064 is IMHO
not very good to achieve stable addresses. A common issue
i have with those servers is that ethernet HW fails, and then
you have to reconnect your subnet to another physcial port
(often servers have more than enough spare ports) and i bet that
the Net_Iface parameter will cause the stable address to change.
This whole disussion was important though, because it had me finally
realize that i can not put normally managed addresses, even if
they claim to be stable into certificates, because they never
are stable, and a registrar can't determine them upfront
when you want to leverage existing IPv6 protocols to manage
them.
Cheers
Toerless
On Thu, Aug 02, 2018 at 08:44:53AM +1200, Brian E Carpenter wrote:
> On 02/08/2018 03:52, Alissa Cooper wrote:
> ....
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Section 6.10.4:
> >
> > "The value of the Interface Identifier is left for future definitions."
> >
> > I don't understand how this is usable without some definition. I.e., if I
> > assign every interface ID in my ACP to be 0, it's not going to work. Could
> > you
> > elaborate about what is expected in this field?
> >
>
> Why not:
>
> The value of the Interface Identifier SHOULD follow [RFC8064].
>
> That would work fine and is a SHOULD to allow for alternatives
> if there's a good reason.
>
> Brian
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
