> > 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. > > If I read you right, this is equivalent to having a redundant routing > table, with two routes to each prefix (one pure IPv4, one v4-via-v6), and > using filtering rules so that every client receives just one route to each > prefix. Is that right?
Yes in that you have essentially two equivalent versions of every route, one pure legacy, another v4-via-v6. But the clients announce only one of these, and the route server automagically creates the other one. > > And the thing is that we definitely want the two alternative nexthops to > > always yield the same link address. > > I'm sure you're right (you usually are, at least as far as routing is > concerned), but I'm struggling to see where this requirement comes from. > If the redundant table is loop-free, then the filtered sub-tables will > still be loop-free, right? So your claim would seem to imply that the > only way to build a loop-free redundant routing table is to ensure that > redundant routes map to the same MAC address, which I don't believe is > true. My motivation is that if I switch from pure legacy to RFC 8950 (or back, for whatever reason), I would expect the traffic shapes to look the same as before. If the traffic suddenly goes another way, I'm definitely investigating what went wrong. There is already confusion among the operators about the semantics of v4-over-v6 and I had to repeatedly explain that the IP nexthop is just an alias for a MAC address and the traffic looks exactly the same on the link (only ARP is substituted by ND). Also configuring a MAC mismatch for legacy / v4-over-v6 is basically a ingress traffic lottery depending on how many of other peers decide to switch to RFC 8950. I don't say it's the only way to require consistency, but I can't see any good reason for the mapping to not keep the MAC address. (My suggestion says SHOULD, not MUST.) One may indeed have a cursed legacy-only device which doesn't like IPv6 on any interface, and therefore they have to use another link for the legacy-via-v6 traffic … but that's still a reason cursed enough for the SHOULD there. -- 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
