This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IXP pool lower boundary of assignments
- Previous message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Tue Nov 8 15:18:32 CET 2022
* Nick Hilliard > this is kinda the problem with RFC 5549, no? I.e. it deals only with > signaling rather than transport. So even if it's deployed, the IXP > will still need to provide ipv4 addresses for transport purposes. Apart from the BGP session itself (which supports multi-AF), the addresses are just needed for resolution of the next-hop layer-2 address. There's no real reason that address needs to be IPv4 and resolved via ARP, it can be resolved just as well with IPv6 ND, as I understand it. For example, on Linux, you can program the FIB in this way: $ ip route add 192.0.2.0/24 via inet6 fe80::1 dev eth0 The 'eth0' interface does not need any IPv4 addresses assigned. Obviously the major router vendors need to build in corresponding capability in their BGP software for IPv6-only IX-es to be a realistic proposition. I have no idea if they have. Tore
- Previous message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]