Re: Large prefix lists/sets on IOS-XR

[Tom Beecher]

>
> That's a take on it I really hadn't considered.  I'm very aware that
> moving from a decade or two of legacy manual config to full data
> model/automation in a big bang is never going to work, but I'd been looking
> at what individual elements could be pulled out and automated with
> judicious use of "replace".  Never considered making the *entire* legacy
> config a starting point for the template, and then effectively working on
> automating replacing parts of that config file with data-driven versions of
> the same.
>

It really makes life a LOT easier to do it that way. It can create some
quirky downsides where different people create the sections to replace in
different ways, and operational confusion (Is this section under automation
now or not?) , but it's still light years ahead of trying to build a
monolithic template from scratch.

Working section by section also makes it much easier to handle deltas and
exceptions for different sites and locations.

On Mon, Dec 12, 2022 at 5:27 AM t...@pelican.org  wrote:

> On Saturday, 10 December, 2022 06:47, "Saku Ytti"  said:
>
> > What you can do, day1
> >
> > a) copy configs as-is, as templates
> > b) only edit the template
> > c) push templates to network
>
> That's a take on it I really hadn't considered.  I'm very aware that
> moving from a decade or two of legacy manual config to full data
> model/automation in a big bang is never going to work, but I'd been looking
> at what individual elements could be pulled out and automated with
> judicious use of "replace".  Never considered making the *entire* legacy
> config a starting point for the template, and then effectively working on
> automating replacing parts of that config file with data-driven versions of
> the same.
>
> Food for thought, thanks for that.
>
> Cheers,
> Tim.
>
>
>

Re: AS3356 Announcing 2000::/12

[Job Snijders via NANOG]

The Internet delivers when we need it the most! :-)

https://is2000slash12announcedagain.com/

Props to Ben Cartwright-Cox

Re: Windows 11 now implements RFC 7217 (stable privacy addresses)!

[Douglas Fischer]

Good news!
Good perspectives for the future...

But this thread remembered-me about RFC 3021 and Windows... Since December
2000.

https://social.technet.microsoft.com/Forums/en-US/6da37a2d-6884-4c3c-bdd5-1b8356edfced/windows-102019-non-compliant-with-rfc-3021-ipv4-31-subnet-mask?forum=winserverPN

Em ter., 13 de dez. de 2022 03:45, Fernando Gont 
escreveu:

> Folks,
>
> After over 10 (yes, *ten*) years, we have finally addressed
> security/privacy issues in the generation of IPv6 stable addresses in
> most popular operating systems.
>
> The traditional scheme/algorithm to generate stable IPv6 addresses with
> SLAAC required that the underlying MAC address be employed to generate
> the Interface Identifier. That is, the underlying MAC address would be
> embedded in the lower bits of an IPv6 address.
>
> This scheme allowed for host-tracking (since MAC addresses are usually
> globally-unique), address scanning (since addresses will follow specific
> patterns) and a number of other issues.
>
> In 2011, I submitted an IETF Internet-Draft proposing a scheme for
> generating stable addresses with SLAAC, meant to replace the traditional
> scheme. The scheme could be summarised and simplified as: Interface_ID =
> Hash(Prefix, Secret). Thus, interface identifiers would be stable within
> the same subnet, but vary across subnets.
>
> [Replacing the traditional scheme with this new scheme was anything but
> easy -- if you're curious, please check the "IPv6 Addressing" section in
> <
> https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-in-ipv6-security-part-i/>
>
> ]
>
> Over time, popular operating systems and packages adopted the proposed
> algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS,
> etc. Eventually, virtually every popular OS had adopted the scheme
> except Windows.
>
> Based on a recent note by Brian Carpenter, I ended up testing Windows
> 11, and I can confirm that it does implement RFC 7217 / RFC 8064!
>
> Therefore, e.g. if multiple prefixes are employed on a subnet, the
> stable addresses for each of such prefixes will employ a different
> Interface Identifier, thus avoiding the security/privacy issues
> discussed above -- this is really good news!
>
> Unfortunately, Windows still generates temporary addresses with the
> algorithm specified in RFC 4941, thus resulting in all temporary
> addresses for a given interface employing the same Interface Identifier
> (!). This problem has been addressed in RFC 8981... but it's
> implementation is not yet widespread, yet (it has been incoporated in
> e.g. the Linux kernel, though).
>
> I just hope it doesn't take Windows and others yet another 10+ years to
> implement RFC 8981, to finally address the remaining security/privacy
> issues in IPv6 address generation!
>
> [Original article with screenshots:
>
> https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-have-activity-7008316664207290368-Wcto
> ]
>
> Thanks!
>
> Regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>