Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone?
On 5/4/21 21:07, Adam Thompson wrote: LOLOLOL. “%VXLAN-4-IPV6_UNDERLAY_UNSUPPORTED: VXLAN encapsulation using IPv6 VTEP addresses is not supported on this platform” Guess it’s going to be a non-issue for me, at this time, since VxLAN was the main reason for this entire setup… Thanks for all the responses! https://tools.ietf.org/html/rfc7439 Doesn't speak to VXLAN (and is MPLS), but the problem is the same. IPv6-only networks that want to tunnel services will continue to struggle, as parity from a vendor standpoint is sorely lacking. Mark.
Comcast mail contact
Anyone from Comcast on this list? would appreciate if you can reach out off the list. Have a few concerns regarding Comcast servers intermittently throwing 550.5.1.0 -- invalid domain errors.
Re: Comcast mail contact
https://list.mailop.org/listinfo/mailop - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Nathanael Cariaga" To: "NANOG" Sent: Wednesday, May 5, 2021 1:17:46 PM Subject: Comcast mail contact Anyone from Comcast on this list? would appreciate if you can reach out off the list. Have a few concerns regarding Comcast servers intermittently throwing 550.5.1.0 -- invalid domain errors.
RE: Comcast mail contact
Nathanael, You can reach out to me privately if you'd like. Typically those are related to DNS being unable to resolve an MX/A/ for your 5321 Mail From domain, but I can take a better look to be sure. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: NANOG On > Behalf Of Nathanael Cariaga > Sent: Wednesday, May 5, 2021 2:18 PM > To: NANOG > Subject: Comcast mail contact > > Anyone from Comcast on this list? would appreciate if you can reach out off > the > list. Have a few concerns regarding Comcast servers intermittently throwing > 550.5.1.0 -- invalid domain errors.
Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone?
On 5/4/21 11:34 AM, Saku Ytti wrote: On Tue, 4 May 2021 at 18:28, Adam Thompson wrote: When I look at my IPv6 routing table, the next-hops are all... well... gibberish, at least to me. My experience is that LLAs are not durable, so memorizing them is not IMHO a useful task. Figuring out an (IS-IS) IPv6 route currently involves a couple of extra steps to locate the LLA's interface route, find the MAC address of that LLA on that link, and then identify the router from its MAC address. Am I missing something obvious? I don't think you are, I read like an opinion piece so it's inherently not right or wrong. I don't have the same experience and I consider forcing LLA a blessing in limiting attack vectors and I personally don't see downsides as all addresses are gibbering to me, as my working memory contains very few digits. I wish ND had mandated LLA too, so many customer tickets due to poorly configured filters due to misunderstanding how ND works. Sadly, all 128-bit IPv6 addresses are gibberish. The original IPv6 design specified the upper 32 bits as the ASN, the lower 32 to match the subnetting of IPv4. I'd even specified an alternative representation to Karn's notation (called Simpson's notation), so that the IPv4 and IPv6 matched! Karn's notation: x.x.x.x/24 compared to :::/56 Simpson's notation: x.x.x.x//8 matching ::://8 All that went out the window with the IESG decision to override our 64-bit design and specify 128-bit addresses with no topological prefix. The IESG didn't have any operators on it. OTOH, I was the pioneer of the RFC *Operational* Considerations section (and an early operator). Link Local Addresses are/were intended to be durable. They are/were statically based upon a physical constant, such as the interface MAC. IPv6 globally routed addresses are/were intended to change every day. One of my drafts indicated that IANA would test changing a leading ASN at least once per month, ensuring that software properly handled it. Neighbor Discovery was intended to use the stable Link Local Address. Neighbor and Router Discovery were intended to be authenticated. You shouldn't allow some random device to be attached to your network. You shouldn't authenticate some unknown interface address. And you shouldn't communicate via some router that cannot demonstrate verification of your per interface secret. Also you shouldn't assign a globally routable address to any unauthenticated device. All that went out the window with the IESG decision Remember the vocal resistance (screaming) in the DHCP WG meeting? Configuring a secret key for each interface is just too hard. (Eventually, various countries required every device to have a secret, printed on the label along with the model and serial number.) Configuring a public key for every ASN is just too hard. Configuring a public key for every Domain Name is just too hard.
Re: Perhaps it's time to think about enhancements to the NANOG list...?
. On 21/03/2021 17:29, Willy Manga wrote: > Hi, > > On 21/03/2021 16:00, nanog-requ...@nanog.org wrote: >> Message: 13 >> Date: Sat, 20 Mar 2021 12:46:57 -0600 >> From: David Siegel >> [...] >> The board has been thinking about enhancements to the NANOG list for a >> couple of years now, with the goal of creating a modern interface that the >> younger generation of engineers will be more comfortable using. > > May I suggest that if you *really* want such enhancement, perhaps > upgrade the mailing-list to mailman3. > It's still mailman but with those 'modern' features. one example with APNIC . Here is what the frontend looks like. The available lists: https://mailman.apnic.net/hyperkitty/ Discussions within one list https://mailman.apnic.net/hyperkitty/list/sig-routingsecur...@apnic.net/ Content of one thread https://mailman.apnic.net/hyperkitty/list/sig-routingsecur...@apnic.net/thread/ZH6KCIF5IE2AIPW66VRKEXLZTR46HYV2/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
