Good morning, if we are talking about BGP, IPv4 routing over IPv6 works beautifully. We just add another IPv4 channel and get BGP MP. OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6 one for IPv4, things look correct. But how does OSFPv3 conceptually work if the interface of the ospf area do not have IPv4 addresses themselves? In the BGP case we can use "extended next hop on;" to use the IPv6 nexthop for IPv4, but I did not find a similar setting for OSPF to accept IPv6 nexthops for IGP IPv4 addresses. Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Hi Nico,
On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users <bird-users@network.cz> wrote: OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6 one for IPv4, things look correct. But how does OSFPv3 conceptually work if the interface of the ospf area do not have IPv4 addresses themselves?
In the BGP case we can use "extended next hop on;" to use the IPv6 nexthop for IPv4, but I did not find a similar setting for OSPF to accept IPv6 nexthops for IGP IPv4 addresses.
Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area?
I was facing the same issue before, and unfortunately, RFC 5838 explicitly forbids IPv4 over IPv6 for OSPF. As an alternative suggestion, I have since evaluated babel which mostly suits my purposes (except for some features not yet implemented in bird, like strict bind) - but maybe it works for you? Cheers Sebastian
On 30. Jan 2024, at 14:09, Juliusz Chroboczek <jch@irif.fr> wrote:
As an alternative suggestion, I have since evaluated babel which mostly suits my purposes (except for some features not yet implemented in bird, like strict bind)
Could you please explain what's the feature you're missing?
Hi Julisz, thanks, I was referring to an email I sent earlier this month[0]. I would like to bind babel to some interfaces only. Perhaps we should move over to that thread? I do not want to hijack this question here. Thanks a lot! Sebastian [0]: https://bird.network.cz/pipermail/bird-users/2024-January/017327.html
On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote:
Hi Nico,
On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users <bird-users@network.cz> wrote: OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6 one for IPv4, things look correct. But how does OSFPv3 conceptually work if the interface of the ospf area do not have IPv4 addresses themselves?
In the BGP case we can use "extended next hop on;" to use the IPv6 nexthop for IPv4, but I did not find a similar setting for OSPF to accept IPv6 nexthops for IGP IPv4 addresses.
Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area?
I was facing the same issue before, and unfortunately, RFC 5838 explicitly forbids IPv4 over IPv6 for OSPF.
Well, we could add 'extended next hop' option to override it, even if it would be non-standard. It is rather small deviation. I also thought about 'integrated-OSPFv3', where both IPv4 and IPv6 ranges are propagated in one instance, but that seems like much larger deviation. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek <santiago@crfreenet.org> writes:
I was facing the same issue before, and unfortunately, RFC 5838 explicitly forbids IPv4 over IPv6 for OSPF.
Well, we could add 'extended next hop' option to override it, even if it would be non-standard. It is rather small deviation.
That would be amazing. It might also give a good testbed to write a follow up RFC on it later, in case there are others who also want to run their core IPv4 free.
I also thought about 'integrated-OSPFv3', where both IPv4 and IPv6 ranges are propagated in one instance, but that seems like much larger deviation.
After reading RFC5838, I absolutely agree with you. -- Sustainable and modern Infrastructures by ungleich.ch
Hoi Ondrej, Nico, Sebastian, I am revisiting this thread based on the question from Benoit this week ( https://www.mail-archive.com/bird-users@network.cz/msg07961.html). On Tue, Jan 30, 2024 at 3:25 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote:
Hi Nico,
On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users < bird-users@network.cz> wrote: OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6 one for IPv4, things look correct. But how does OSFPv3 conceptually work if the interface of the ospf area do not have IPv4 addresses themselves?
In the BGP case we can use "extended next hop on;" to use the IPv6 nexthop for IPv4, but I did not find a similar setting for OSPF to accept IPv6 nexthops for IGP IPv4 addresses.
Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area?
I was facing the same issue before, and unfortunately, RFC 5838 explicitly forbids IPv4 over IPv6 for OSPF.
Sebastian - my interpretation of 5838 is slightly different, and I don't think it expressly forbids xAF nexthops:
2.5: Although IPv6 link local addresses could be used as next hops for IPv4 address families, it is desirable to have IPv4 next-hop addresses.
Well, we could add 'extended next hop' option to override it, even if it
would be non-standard. It is rather small deviation.
I also thought about 'integrated-OSPFv3', where both IPv4 and IPv6 ranges are propagated in one instance, but that seems like much larger deviation.
Seeing as OSPFv3 will establish an IPv6 adjacency, and exchange routes, I think that using IPv6 nexthops could be very useful. I think adding 'extended next hop on|off|always' would be a pretty wonderful addition. It would allow operators to cut down on IPv4 ptp transit networks, and catch up with Babel (also referenced in this thread as an alternative), without violating RFC5838. groet, Pim -- Pim van Pelt <pim@ipng.nl> PBVP1-RIPE - http://www.ipng.nl/
Hi Pim,
On 31. Mar 2024, at 11:04, Pim van Pelt <pim@ipng.nl> wrote:
Hoi Ondrej, Nico, Sebastian,
I am revisiting this thread based on the question from Benoit this week (https://www.mail-archive.com/bird-users@network.cz/msg07961.html).
On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote:
On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users <bird-users@network.cz> wrote: Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area?
I was facing the same issue before, and unfortunately, RFC 5838 explicitly forbids IPv4 over IPv6 for OSPF. Sebastian - my interpretation of 5838 is slightly different, and I don't think it expressly forbids xAF nexthops: 2.5: Although IPv6 link local addresses could be used as next hops for IPv4 address families, it is desirable to have IPv4 next-hop addresses.
My understanding came from this:
In order to achieve this, the link's IPv4 address will be advertised in the "link local address" field of the IPv4 instance's Link-LSA. This address is placed in the first 32 bits of the "link local address" field and is used for IPv4 next-hop calculations. The remaining bits MUST be set to zero.
which to me reads like the statement about desirability just explains why the technical design doesn't allow IPv6 next hops. I would be happy to be wrong here. Thanks Sebastian
On Mon, Apr 01, 2024 at 04:14:51PM +0200, Sebastian Hahn wrote:
Sebastian - my interpretation of 5838 is slightly different, and I don't think it expressly forbids xAF nexthops:
2.5: Although IPv6 link local addresses could be used as next hops for IPv4 address families, it is desirable to have IPv4 next-hop addresses.
My understanding came from this:
In order to achieve this, the link's IPv4 address will be advertised in the "link local address" field of the IPv4 instance's Link-LSA. This address is placed in the first 32 bits of the "link local address" field and is used for IPv4 next-hop calculations. The remaining bits MUST be set to zero.
which to me reads like the statement about desirability just explains why the technical design doesn't allow IPv6 next hops. I would be happy to be wrong here.
Hi Unfortunately, RFC 5838 chose the worst way to represent IPv4 in Link-LSA, so there is no reliable way to know whether received Link-LSA should be interpreted as IPv4 or IPv6. Although one could have option that forces it to interpret as IPv6, i would prefer to have 'extended next hop' option that allows to accept both IPv4 and IPv6 next hops in Link-LSA. We could use heuristic, like if first u32 is fe800000, it is IPv6, if remaining u32s are 0, it is IPv4, And hope that nobody uses both fe80::0 and 254.128.0.0. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Hoi Ondrej, On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote: > Although one could have option that forces it to interpret as IPv6, i > would prefer to have 'extended next hop' option that allows to accept > both IPv4 and IPv6 next hops in Link-LSA. Did you mean that: 1) under normal circumstances, an ipv4 channel with an ipv6 ospfv3 adjacency, will respect RFC5838 and overload the link-lsa with the ipv4 address; 2) when `extended next hop` is active on the interface, an ipv4 channel with ipv6 ospfv3 adjacency, will use the ipv6 nexthop in the link-lsa? If so, (2) will make Bird break interoperability with any other RFC5838 neighbor. Is an alternative perhaps, to make Bird choose the message neighbor as nexthop, and ignore the link-lsa value when `extended next hop` is set? Or is that gross? Example: if neighbor fe80:foo::1234/64 sent the LSA with nexthop as c0000201.00* (192.0.2.1), AND `extended next hop` is set AND the interface doesn't have an IPv4 address, only then do we ignore the link-lsa but use fe80:foo::1234%iface instead. Incidentally, if we decide to merge the babel patch I offered, we can further create analogous behavior by allowing `extended next hop always` which would use the message neighbor address even if an IPv4 address is present. ps - even with IPv4 on the interface and RFC5838 as it was intended, I still don't see Bird emit the learned routes to the kernel (see my message to Benoit on 30.03.2024, 15:50); so I think even setting extended next hop aside, I cannot confirm that OSPFv3 with ipv4 channel works in that configuration. groet, Pim -- Pim van Pelt<pim@ipng.ch> PBVP1-RIPEhttps://ipng.ch/
On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote: > Hoi Ondrej, Hi > On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote: > > Although one could have option that forces it to interpret as IPv6, i > > would prefer to have 'extended next hop' option that allows to accept > > both IPv4 and IPv6 next hops in Link-LSA. > Did you mean that: > 1) under normal circumstances, an ipv4 channel with an ipv6 ospfv3 > adjacency, will respect RFC5838 and overload the link-lsa with the ipv4 > address; > 2) when `extended next hop` is active on the interface, an ipv4 channel with > ipv6 ospfv3 adjacency, will use the ipv6 nexthop in the link-lsa? Yes, if there is no IPv4 address or when forced (like your 'extended next hop always'). > If so, (2) will make Bird break interoperability with any other RFC5838 > neighbor. Yes, such option will break interoperability, but if you have no IPv4 address on the interface, what address put to Link-LSA anyway? > Is an alternative perhaps, to make Bird choose the message neighbor as > nexthop, and ignore the link-lsa value when `extended next hop` is set? Or > is that gross? > > Example: if neighbor fe80:foo::1234/64 sent the LSA with nexthop as > c0000201.00* (192.0.2.1), AND `extended next hop` is set AND the interface > doesn't have an IPv4 address, only then do we ignore the link-lsa but use > fe80:foo::1234%iface instead. There is an alternative way to get route nexthops, from (Hello packet) source addresses stored in neighbor structures, indexed by neighbor's router ID. That is probably what you mean by 'message neighbor'. We use this for PtP/PtMP links in OSPFv2 and OSPFv3-IPv6. But it is problematic on multi-access links, where you have adjacency just with DR/BDR. It cannot be used for NBMA links (as you may have no communication with other neighbors). On broadcast links, you have at least Hello exchange with neighbors, but there are still some problematic cases when multiple interfaces are used to connect to one network. > Incidentally, if we decide to merge the babel patch I offered, we can > further create analogous behavior by allowing `extended next hop always` > which would use the message neighbor address even if an IPv4 address is > present. > > ps - even with IPv4 on the interface and RFC5838 as it was intended, I still > don't see Bird emit the learned routes to the kernel (see my message to > Benoit on 30.03.2024, 15:50); so I think even setting extended next hop > aside, I cannot confirm that OSPFv3 with ipv4 channel works in that > configuration. Will check that both. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote:
Hoi Ondrej,
On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
Although one could have option that forces it to interpret as IPv6, i would prefer to have 'extended next hop' option that allows to accept both IPv4 and IPv6 next hops in Link-LSA.
ps - even with IPv4 on the interface and RFC5838 as it was intended, I still don't see Bird emit the learned routes to the kernel (see my message to Benoit on 30.03.2024, 15:50); so I think even setting extended next hop aside, I cannot confirm that OSPFv3 with ipv4 channel works in that configuration.
Hi I have almost implemented 'extended next hop' for OSPFv3. But then i pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have doubts about usefulness of 'extended next hop', as any IPv4 router needs at one IPv4 address anyways (at least to be able to send ICMP messages) and there is no need to put IPv4 addresses on links. Are there any good arguments for it? [*] https://bird.network.cz/pipermail/bird-users/2024-April/017555.html -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Hoi, On 4/5/24 15:23, Ondrej Zajicek wrote:
I have almost implemented 'extended next hop' for OSPFv3. But then i pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have doubts about usefulness of 'extended next hop', as any IPv4 router needs at one IPv4 address anyways (at least to be able to send ICMP messages) and there is no need to put IPv4 addresses on links. Are there any good arguments for it? In VPP, an interface that does not have an ip4 address, will not allow for ip4 traffic to enter it. In other words, there must be an ip4 address on the interface before forwarding is turned on. I know how to change that behavior in VPP, but it's not a problem in practice, because we can set 'unnumbered' interface and borrow an IPv4 address from another interface, usually a loopback interface with a /32 ip4 and /128 ip6.
I think it'd be super cool to use OSPFv3 without IPv4 transit networks and just reusing the loopback addresses, like so: root@vpp0-2:~# ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 loop0 UNKNOWN 192.168.10.2/32 2001:678:d78:200::2/128 fe80::dcad:ff:fe00:0/64 e0 UP 192.168.10.2/32 2001:678:d78:200::2/128 fe80::5054:ff:fef0:1120/64 e1 UP 192.168.10.2/32 2001:678:d78:200::2/128 fe80::5054:ff:fef0:1121/64 * *However, up-thread (message of 2024-04-30, 16:04) I had that configuration, saw the LSAs but did not see Linux (nor VPP) pick up the routes. My suspicion is that your commit will be inert in this scenario, because e0 already has an IPv4 address, so loopback_addr_used will remain 0. The good news is, I have two patches to VPP that may still allow for this to work, one of them inhibits the 'unnumbered' interface from propagating its address to e0, and the other allows an interface to respond to ARP requests that are onlink but p2p and in another subnet. in other words, the configuration would look like this: root@vpp0-2:~# ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 loop0 UNKNOWN 192.168.10.2/32 2001:678:d78:200::2/128 fe80::dcad:ff:fe00:0/64 e0 UP fe80::5054:ff:fef0:1120/64 e1 UP fe80::5054:ff:fef0:1121/64 .. and here I think your use-loopback commit will be active., * *Let me build Bird with your use-loopback commit <https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8>*and* VPP with my unnumbered-inhibit commit <https://github.com/pimvanpelt/lcpng/commit/a960d64a87849d312b32d9432ffb722672c14878> *and* VPP accepting onlink ARP request (pending gerrit <https://gerrit.fd.io/r/c/vpp/+/40482>). I will then check to see if VPP is happy to set the correct nexthop (both in Bird2, but also in the VPP FIB). I'll report back after the weekend but thank you very much for working on this (and/or the extended next hop feature). groet, Pim -- Pim van Pelt PBVP1-RIPE -https://ipng.ch/
On Fri, Apr 05, 2024 at 04:27:27PM +0200, Pim van Pelt wrote:
Hoi,
On 4/5/24 15:23, Ondrej Zajicek wrote:
I have almost implemented 'extended next hop' for OSPFv3. But then i pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have doubts about usefulness of 'extended next hop', as any IPv4 router needs at one IPv4 address anyways (at least to be able to send ICMP messages) and there is no need to put IPv4 addresses on links. Are there any good arguments for it? In VPP, an interface that does not have an ip4 address, will not allow for ip4 traffic to enter it. In other words, there must be an ip4 address on the interface before forwarding is turned on. I know how to change that behavior in VPP, but it's not a problem in practice, because we can set 'unnumbered' interface and borrow an IPv4 address from another interface, usually a loopback interface with a /32 ip4 and /128 ip6.
I think it'd be super cool to use OSPFv3 without IPv4 transit networks and just reusing the loopback addresses, like so:
root@vpp0-2:~# ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 loop0 UNKNOWN 192.168.10.2/32 2001:678:d78:200::2/128 fe80::dcad:ff:fe00:0/64 e0 UP 192.168.10.2/32 2001:678:d78:200::2/128 fe80::5054:ff:fef0:1120/64 e1 UP 192.168.10.2/32 2001:678:d78:200::2/128 fe80::5054:ff:fef0:1121/64 * *However, up-thread (message of 2024-04-30, 16:04) I had that configuration, saw the LSAs but did not see Linux (nor VPP) pick up the routes.
Even if LSAs are here the question is whether OSPF generated such routes (i.e. whether birdc show route would show them). In order for kernel to pick them up, OSPF has to generate them and with 'onlink' flag on next hop.
My suspicion is that your commit will be inert in this scenario, because e0 already has an IPv4 address, so loopback_addr_used will remain 0.
I think it might help, because even if loopback_addr_used will remain 0, there is also this change in the patch: https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23... That for OSPFv3-IPv4 removes next-hop-in-address-range check (and automatically adds onlink flag), which caused rejection of such next hops. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Hoi Ondrej, Bird users, TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either completely unnumbered interfaces, where it 'borrows' a valid IPv4 address from a loopback device. It does so without breaking RFC5838! On 05.04.2024 16:27, Pim van Pelt via Bird-users wrote:
**Let me build Bird with your use-loopback commit <https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8>*and* VPP with my unnumbered-inhibit commit <https://github.com/pimvanpelt/lcpng/commit/a960d64a87849d312b32d9432ffb722672c14878> *and* VPP accepting onlink ARP request (pending gerrit <https://gerrit.fd.io/r/c/vpp/+/40482>). I will then check to see if VPP is happy to set the correct nexthop (both in Bird2, but also in the VPP FIB). I'll report back after the weekend but thank you very much for working on this (and/or the extended next hop feature).
- It now also works when interfaces have duplicate IP addresses. - For the VPP aficionados, both scenario's work with 'set interface unnumbered' and with or without 'lcp lcp-sync-unnumbered' (once my commits to VPP are merged). I tested both scenarios above: - Scenario 1: where e0/e1 have the same IPv4/IPv6 address as loop0 - Scenario 2: where e0/e1 are left unconfigured, and OSPFv3 finds a nexthop from loop0 I wrote up my findings on https://ipng.ch/s/articles/2024/03/06/vpp-ospf.html groet, Pim -- Pim van Pelt<pim@ipng.ch> PBVP1-RIPEhttps://ipng.ch/
On Sat, Apr 06, 2024 at 04:54:48PM +0200, Pim van Pelt via Bird-users wrote:
Hoi Ondrej, Bird users,
TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either completely unnumbered interfaces, where it 'borrows' a valid IPv4 address from a loopback device. It does so without breaking RFC5838!
I wrote up my findings on https://ipng.ch/s/articles/2024/03/06/vpp-ospf.html
Hi Thanks for your wonderful blogposts. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Hello Pim . I get 404 when trying to access the url below . Tia , JimL On Sun, 7 Apr 2024, Ondrej Zajicek via Bird-users wrote:
On Sat, Apr 06, 2024 at 04:54:48PM +0200, Pim van Pelt via Bird-users wrote:
Hoi Ondrej, Bird users,
TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either completely unnumbered interfaces, where it 'borrows' a valid IPv4 address from a loopback device. It does so without breaking RFC5838!
I wrote up my findings on https://ipng.ch/s/articles/2024/03/06/vpp-ospf.html Hi Thanks for your wonderful blogposts.
-- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+
Looks like the date of the post shifted from 03-06 to 04-07, https://ipng.ch/s/articles/2024/04/07/vpp-ospf.html (Can be seen from the index page, https://ipng.ch/s/articles/) On Mon, 8 Apr 2024 at 00:41, babydr DBA James W. Laferriere via Bird-users <bird-users@network.cz> wrote:
Hello Pim . I get 404 when trying to access the url below . Tia , JimL
On Sun, 7 Apr 2024, Ondrej Zajicek via Bird-users wrote:
On Sat, Apr 06, 2024 at 04:54:48PM +0200, Pim van Pelt via Bird-users wrote:
Hoi Ondrej, Bird users,
TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either completely unnumbered interfaces, where it 'borrows' a valid IPv4 address from a loopback device. It does so without breaking RFC5838!
I wrote up my findings on https://ipng.ch/s/articles/2024/03/06/vpp-ospf.html Hi Thanks for your wonderful blogposts.
-- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+
Good morning Sebastian, Sebastian Hahn <bird_users@sebastianhahn.net> writes:
Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area?
I was facing the same issue before, and unfortunately, RFC 5838 explicitly forbids IPv4 over IPv6 for OSPF.
everytime I post to this list I am learning so much - very interesting, first time I actually read RFC 5838.
As an alternative suggestion, I have since evaluated babel which mostly suits my purposes (except for some features not yet implemented in bird, like strict bind) - but maybe it works for you?
Very interesting. As far as I recollect, we did give babel a try way before we introduced OSPF. I am not sure anymore what made us switch over to OSPF, but vaguely recalling we had to quickly introduce an IGP due to an architecture change, wanted to go with babel, we faced some issues with the setup and continued with OSPF and settled on it. But from a simplicity point of view, babel is indeed very attractive and it made it back on my "to recheck in the future"-list. In a way it's great to see you have had the same issue, seeing we are on a similar path for network designs. Cheers, Nico -- Sustainable and modern Infrastructures by ungleich.ch
On 30.01.24 10:32, Nico Schottelius via Bird-users wrote:
Good morning,
if we are talking about BGP, IPv4 routing over IPv6 works beautifully. We just add another IPv4 channel and get BGP MP.
OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6 one for IPv4, things look correct. But how does OSFPv3 conceptually work if the interface of the ospf area do not have IPv4 addresses themselves?
In the BGP case we can use "extended next hop on;" to use the IPv6 nexthop for IPv4, but I did not find a similar setting for OSPF to accept IPv6 nexthops for IGP IPv4 addresses.
Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area?
Best regards,
Nico
Hi Nico, If every router has "at least" a /32 IPv4 address on loopback[1], you could do "OSPF unnumbered". It's not IPv4 over IPv6 but you do not need a bunch of IPv4 peer addresses on each and every interface. [1] IIRC I had some issues with that setup a few years ago, _BUT_ you can /just/ assign the /32 IPv4 loopback address on each OSPF interface, too. Otherwise: If you already have and can use BGP MP, why would you want IPv4 in OSPF, too? (Curious questions...) Best, Bernd
Good morning Bernd, Bernd Naumann <bernd@kr217.de> writes:>
Hi Nico,
If every router has "at least" a /32 IPv4 address on loopback[1], you could do "OSPF unnumbered". It's not IPv4 over IPv6 but you do not need a bunch of IPv4 peer addresses on each and every interface.
[1] IIRC I had some issues with that setup a few years ago, _BUT_ you can /just/ assign the /32 IPv4 loopback address on each OSPF interface, too.
Interesting hack, I love to the creativity. We actually do something similar, albeit a different motivation already: For active-semiactive routers we use /sbin/ip addr add 2a0a:e5c0::a:b::c/64 dev $IFACE nodad preferred_lft 0 With multiple routers having the same address, clients can/will switch over after the neighbor cache expires, but as long as you can keep the routing stateless, it doesn't need any external coordination software such as keepalived.
Otherwise: If you already have and can use BGP MP, why would you want IPv4 in OSPF, too? (Curious questions...)
We use BGP MP a lot, but not everyone we talk to does, resulting in: [ peer A ] | | IPv4 IPv6 BGP BGP | [ router1 ]--- iBGP MP -------- [ routerX ] | BGP MP | [ peer X ] Thus the nexthop for the routes received from peer A are using an IPv4 nexthop to which routerX needs access to, thus the requirement for using OSPF supporting IPv4. Interestingly we have a lot of connections as the one depicted with peer X, where even from outside all routes we receive are always having an IPv6 nexthop, making the whole setup significantly easier. BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch
participants (9)
-
babydr DBA James W. Laferriere -
Bernd Naumann -
Juliusz Chroboczek -
netravnen+birdlist＠gmail.com -
Nico Schottelius -
Ondrej Zajicek -
Pim van Pelt -
Pim van Pelt -
Sebastian Hahn