Hi Job & GROW WG, I am not sure why we need to push for IPv6-only IXP fabrics ?
What's wrong in using IPv4 & IPv6 addressing on the IXP fabrics as it is a common practice today ? 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. See the draft in question is extremely questionable as there is no guarantee that all IXP members would like such translation to occur. 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. Kind regards, Robert On Wed, Jul 22, 2026 at 5:31 PM Job Snijders <[email protected]> wrote: > Dear all, > > In today's GROW @ IETF 126 session Maria gave a presentation on NEXT_HOP > translation in IX Route Servers. (Thanks Maria!) > > slides: > https://datatracker.ietf.org/meeting/126/materials/slides-126-grow-route-server-next-hop-translation-00 > draft: > http://datatracker.ietf.org/doc/draft-marenamat-grow-route-server-nh-translation/ > > I suspect the 'route-server-nh-translation' work is best handled in IDR, > given IDR's charter and history (i.e., RFC 7947). > > Cross-posting adoption call / feedback requests to grow@ is fine, given > GROW's charter and history (RFC 7948). > > Kind regards, > > Job > co-chair GROW > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
