Hi Robert, On Wed, Jul 22, 2026 at 06:25:51PM +0200, Robert Raszuk wrote:
> I am not sure why we need to push for IPv6-only IXP fabrics ? Because IXPs and their clients are asking for that. There has even been an Euro-IX working group investigating how to implement RFC 8950 in IXPs. > What's wrong in using IPv4 & IPv6 addressing on the IXP fabrics as it is a > common practice today ? If the client has fully deployed IPv6-only links with IPv4 solely on end hosts, they prefer getting rid of IPv4 addressing also on eBGP links. Mixed next hops (some IPv4, other IPv6) are messy. Also, IPv4 addresses are scarce. > If IPv4 registered blocks are not available RFC1918 comes handy and I have > never seen an IXP fabric whose number of nodes would exceed 2^24. That has been long rejected, see https://www.ripe.net/community/policies/proposals/2011-05/ It is not possible to use unannounced or RFC1918 address space for IXP peering lans, as this breaks URPF and ICMP communication, and breaks the opportunity for debugging of connections over the Exchange for connected and non-connected networks due to the IX path missing from traceroutes, and peering routers not getting the ability to set reverse DNS. Which brings me back to the request for a Class E allocation which we removed from -02 because we thought it was not really needed, but reading this, it would be probably well justified. > See the draft in question is extremely questionable as there is no > guarantee that all IXP members would like such translation to occur. That's up to the IXPs; the purpose of the draft is to merely _allow_ that, not to _force_ anybody to do that. Also, various IXPs (it's publicly known about DE-CIX) already do ARP/ND proxying on the access switches. Translating the next hop is basically the same but on the BGP level. > The main motivation seems to be coming from section 3.1.3, but this is only > one way to add a client to a fabric. > > Other ways would be to ask client to talk to the IXP fabric via a dedicated > VRF instance. That way addresses used in the fabric have no bearing on > clients's internal addressing scheme as they stay on the client's router > only in the VRF context connecting the IXP fabric. Then advertising them > into client's domain they no longer have that private next hop in any of > the BGP attributes - needless to say vast majority of deployments already > does nhs on the edge. There is no guarantee that all IXP members would like such reconfiguration to be forced on them. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
