On 08/08/2018 12:02, Toerless Eckert wrote: > 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.
True. My thinking was more that since the current general-purpose recommendation is RFC8064, ACP implementers don't need to do anything different (e.g. continue using old-fashioned Modified EUI-64). But saying nothing is fine. > > 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. Yes, that has been noticed. But requiring a node to re-identify itself after a MAC address change seems like a good thing anyway. Brian > > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
