Antonio Prado

Excellent thread: the fe80 and DHCPv6-PD exchanges cover the control-plane side thoroughly. Two operational points from the access/data-centre side that haven't come up yet. Both are about the shared-L2 segment the article leads with (Hetzner/OVH-style VLANs, enterprise access), not the routed-to-the-host fabric, where they don't apply because there is no east-west on the wire to begin with. East-west hairpinning. Once every host is a /32 with no on-link IPv4 subnet, two hosts on the same segment no longer have an on-link path to each other. A→B IPv4 now goes host → 192.0.0.11 → router → back out the same interface → B. On a shared broadcast domain that turns a one-L2-hop intra-segment flow into a router hairpin: roughly double the segment traffic for east-west IPv4, plus load on the first-hop router. For the IPv4-heavy east-west workloads that still live on legacy segments (clustering, storage, backup), that is a real cost the /32 model introduces quietly. Worth a line in deployment considerations, even if only to say "keep east-west-heavy IPv4 segments dual-stack for now." L2 integrity and first-hop redundancy. DHCP snooping, Dynamic ARP Inspection and IP Source Guard build bindings from DHCP state and validate against subnet-and-binding assumptions. A gateway deliberately off-subnet plus /32 leases sits outside the envelope these features were written for, so operators running them will need to validate behaviour and likely add explicit permits for the sentinel, mildly ironic for a mechanism whose headline is "no host changes," since on a DAI-enabled access network the no-change fallback path may need a switch-side change. Related: with redundant first-hops, the draft should say which MAC answers for 192.0.0.11 across a failover: a shared/virtual MAC, or you trade ARP churn for neighbour-cache churn. thanks

Good and much-needed analysis. At last, it moves the discussion from “nice, more bits” to the more practical question: who is supposed to run this in real networks? We all know the Internet is messy: routing policy, traffic engineering, anycast, DDoS workarounds, filters, CPEs, logs, tools, outages, people, and all the odd ways things fail in production. Drawing a bigger address space is easy, but making it useful and operable is the hard part. I also liked the point about routing security: there are concrete mechanisms for concrete problems. The buzzword “cybersecurity” does not really help here, IMHO. All in all, maybe an interesting idea, but still a long way from something operators could actually deploy.

Thanks for this article: the historical walk through the RFC wording is really interesting and I enjoyed reading it. I'd like to share a slightly different perspective on some of the points raised. On the risk of accidental transit: in my experience, this is something you solve with route-maps and filters on eBGP, not by removing iBGP sessions. Removing sessions to prevent misconfigurations feels a bit like removing roads to prevent accidents. On failure scenarios: I keep thinking about what happens during convergence. If BR1 loses its upstream and has no iBGP session with BR2, it just has to sit there and wait for the IRs to converge. With that session in place, BR1 would immediately know that BR2 has an alternative path. That seems worth having. On KISS: I'd actually argue it the other way around. A full mesh of 5 or 6 routers is uniform and predictable. A partial mesh means you need to keep track of who sees what, which in my experience makes troubleshooting harder, not easier. "Everyone talks to everyone" is a pretty simple rule to follow. I also think that tools like next-hop-self, BGP communities, and well-designed route policies are what make full mesh safe and manageable in practice, even where it's not strictly necessary. And in the real world, the boundaries between upstream, peering, and customer roles can be less clear-cut than the model assumes, so having full route visibility across all routers can really help with traffic engineering. Anyway, just my two cents; thanks again for putting this out there, it's a topic that doesn't get discussed enough.

“I want to thank you for your article and for the mention of IX.br, and confirm that the article’s description about its wide geographical coverage helping to absorb massive traffic increases is accurate. I would also like to emphasize that the adequate scaling and dimensioning of the largest IXPs: São Paulo, the largest in the world, Fortaleza, and Rio de Janeiro, has been fundamental in supporting the growing traffic demand. However, I want to clarify that stating the coordination is public or state-led is not correct. CGI.br works in the public interest, as does NIC.br, but the coordination of IX.br is multistakeholder through CGI.br, with balanced participation from the public sector, private sector, civil society, and academia. I also want to clarify that no government funds are involved in IX.br. NIC.br is a private non-profit entity that manages IX.br and other initiatives, funded with private resources mainly from the registration of .br domains, while following the guidelines established by the multistakeholder council CGI.br, which guides public policies for the Internet in Brazil. I remain available for any further clarifications.”

Muito obrigado, Antonio, tanto pela leitura quanto pela importante correção. I’ve now updated my internal notes to reflect this. I’m grateful for your detailed comment, and I will make sure any future references distinguish clearly between multistakeholder coordination and state operation.

“Antonio, I together with Keith Mitchell created LINX in the very early days of the Internet. A key factor you miss is actually the reason we created the LINX. It stops large ISPs from extorting "Taxes" from smaller ISPs. The key here is if a large ISP seeks to restrict traffic, the IXPs provide a route around the blockage. We can see how Deutsche Telecom have tried repeatedly to muscle traffic to their advantage and have been repeatedly thwarted. might form a cartel to maximise their profits. The agreements that are the basis of the whole commercial Internet are underwritten by the IXPs. I have an incomplete paper on IXPs available which explain much that may have been forgotten”

Thank you, Peter, for your comment and for reminding us of the foundational motivations behind the creation of LINX. Your point is absolutely crucial: IXPs are not only about performance and resilience, but also about market fairness and interconnection freedom. It would be very valuable to include historical reflections like yours: if you’re open to sharing the incomplete paper you mentioned, I’d be keen to read it and possibly reference it in future revisions or spin-offs of the article. Thank you again for your contribution and for helping make the Internet what it is today.