Hello Juliusz, > > I wanted to add a little bit info on IPv6 nexthops in IPv4 routes in the > > context of IXPs. There are efforts to allow clients to run their IPv4 > > routing > > over RFC 8950 only, yet it means that for IPv4-only clients, you have to > > translate the IPv6 nexthop to IPv4 to accept the nexthops, and possibly also > > vice versa. > > Perhaps you could explain the setup? Are you saying that the next-hop > router has both a v4 and a v6 address, and that you serve either the v4 or > the v6, depending on the capabilities of the client?
Sorry, didn't realize that my description was so vague. Let's say there is Woof GmbH, and Meow LLC, both running a classical dual-stack setup within Animal IXP, connecting to the route server by two sessions, one IPv6, another IPv4. Now Meow LLC wants to shut down the legacy IPv4 session and send all their routes via the IPv6 session, and utilize RFC 8950 to advertise everything with their IPv6 address. Now the route server cannot send these routes to Woof GmbH – they would refuse them because of bad nexthop. So what the IXPs are trying to do, is nexthop translation. The route server puts all the routes into the same table, and when announcing to the "other flavor", the route server translates the next hop according to a pre-configured table (addressing in the IXPs is usually fixed) to match the peers' expectations. This works as long as all the IPv4-capable peers still keep their IPv4 address assigned and up, to respond to ARP queries, and allows the peers to reconfigure one-by-one without adverse effects. And the thing is that we definitely want the two alternative nexthops to always yield the same link address. Hoping that it's clear now. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
