* IPv6 nexthop for IPv4 @ 2015-03-26 13:16 Bjørnar Ness 2015-03-26 14:29 ` Sowmini Varadhan 0 siblings, 1 reply; 9+ messages in thread From: Bjørnar Ness @ 2015-03-26 13:16 UTC (permalink / raw) To: netdev Hello, hope this is the right place to ask. Does anyone know if there is work beeing done in natively supporting IPv6 nexthops for IPv4? I know that "some" Linux switch software company is working on this, but I am afraid the functionality will be more of a "hack". The benefit of this is stateless configuration (rfc5549), using IPv6 link-local neighbor address as IPv4 nexthop, beeing able to do for example: ip route add 10.0.0.0/16 via fe80::225:90ff:fed3:bfb4/64 dev sfp0 This is somehow possible now by exploiting static arp entries and "unused" IPv4 addresses for nexthop, but is far from ideal. Hope someone will be able to provide some insight on what is planned in this area, and weather this direct functionality will ever make it into the kernel. -- Bjørnar Ness ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 13:16 IPv6 nexthop for IPv4 Bjørnar Ness @ 2015-03-26 14:29 ` Sowmini Varadhan 2015-03-26 14:39 ` Bjørnar Ness 0 siblings, 1 reply; 9+ messages in thread From: Sowmini Varadhan @ 2015-03-26 14:29 UTC (permalink / raw) To: Bjørnar Ness; +Cc: netdev On Thu, Mar 26, 2015 at 9:16 AM, Bjørnar Ness <bjornar.ness@gmail.com> wrote: > Hello, hope this is the right place to ask. > > Does anyone know if there is work beeing done in natively supporting > IPv6 nexthops for IPv4? What problem are you trying to solve? Do you want to tunnel your ipv4 packet through IPv6? there are a number of tunneling mechanisms in linux for this. > > I know that "some" Linux switch software company is working on this, but > I am afraid the functionality will be more of a "hack". > > The benefit of this is stateless configuration (rfc5549), using IPv6 link-local > neighbor address as IPv4 nexthop, beeing able to do for example: > > ip route add 10.0.0.0/16 via fe80::225:90ff:fed3:bfb4/64 dev sfp0 Trying to understand what the desired behavior is, for the route above: if I send a packet from 10.0.0.1 to 10.0.0.2, you want the dst-mac to be the mac address of e80::225:90ff:fed3:bfb4??? how do you know that fe80::225:90ff:fed3:bfb4 supports ipv4 forwarding on the receiving interface (and if it does, why didn't it advertise itself as an IPv4 router on that interface)? > > This is somehow possible now by exploiting static arp entries and > "unused" IPv4 addresses for nexthop, but is far from ideal. > > Hope someone will be able to provide some insight on what is planned > in this area, and weather this direct functionality will ever make it > into the kernel. > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 14:29 ` Sowmini Varadhan @ 2015-03-26 14:39 ` Bjørnar Ness 2015-03-26 14:53 ` Sowmini Varadhan 0 siblings, 1 reply; 9+ messages in thread From: Bjørnar Ness @ 2015-03-26 14:39 UTC (permalink / raw) To: Sowmini Varadhan, netdev 2015-03-26 15:29 GMT+01:00 Sowmini Varadhan <sowmini05@gmail.com>: > On Thu, Mar 26, 2015 at 9:16 AM, Bjørnar Ness <bjornar.ness@gmail.com> wrote: >> Hello, hope this is the right place to ask. >> >> Does anyone know if there is work beeing done in natively supporting >> IPv6 nexthops for IPv4? > > What problem are you trying to solve? Do you want to tunnel your > ipv4 packet through IPv6? there are a number of tunneling mechanisms > in linux for this. No, no tunneling, just route the packet directly as-is to the ipv6 nexthop >> I know that "some" Linux switch software company is working on this, but >> I am afraid the functionality will be more of a "hack". >> >> The benefit of this is stateless configuration (rfc5549), using IPv6 link-local >> neighbor address as IPv4 nexthop, beeing able to do for example: >> >> ip route add 10.0.0.0/16 via fe80::225:90ff:fed3:bfb4/64 dev sfp0 > > Trying to understand what the desired behavior is, for the route > above: if I send a packet from 10.0.0.1 to 10.0.0.2, you want the dst-mac > to be the mac address of e80::225:90ff:fed3:bfb4??? Absolutely, correct. > how do you know that fe80::225:90ff:fed3:bfb4 supports ipv4 > forwarding on the receiving interface (and if it does, why didn't it > advertise itself as an IPv4 router on that interface)? Basically because you either added the route manually, or it was provided by fe80::225:90ff:fed3:bfb4 itself via some routing protocol (MP-BGP) This will be the same as any other route. How do you know it forwards traffic.. In large routed setups, address management in general and lack of IPv4 addresses can become a big hassle. Beeing able to get a ipv6 neighbor for a ipv4 route would make this process a lot simpler. -- Bj(/)rnar ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 14:39 ` Bjørnar Ness @ 2015-03-26 14:53 ` Sowmini Varadhan 2015-03-26 15:10 ` Bjørnar Ness 0 siblings, 1 reply; 9+ messages in thread From: Sowmini Varadhan @ 2015-03-26 14:53 UTC (permalink / raw) To: Bjørnar Ness; +Cc: netdev On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness <bjornar.ness@gmail.com> wrote: >>> ip route add 10.0.0.0/16 via fe80::225:90ff:fed3:bfb4/64 dev sfp0 >> >> Trying to understand what the desired behavior is, for the route >> above: if I send a packet from 10.0.0.1 to 10.0.0.2, you want the dst-mac >> to be the mac address of e80::225:90ff:fed3:bfb4??? > > Absolutely, correct. What if the current node does not want to support ipv6? This sounds pretty "creative", if this can work, you might as well make the nexthop to be the L2 address of the gw. > Basically because you either added the route manually, or it was provided > by fe80::225:90ff:fed3:bfb4 itself via some routing protocol (MP-BGP) > > This will be the same as any other route. How do you know it forwards traffic.. because you would be running a routing protocol that manages reachability of the gw and the route. RIP, OSPF, BGP etc all have a lot of mechanisms to monitor liveness of the route and of the nexthop, which has to be of the same address family as the route itself. > > In large routed setups, address management in general and lack of IPv4 addresses > can become a big hassle. Beeing able to get a ipv6 neighbor for a ipv4 > route would > make this process a lot simpler. Yes, that's the motivation behind all the tunneling/transition mechanisms in the various ipv6 working groups. --Sowmini ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 14:53 ` Sowmini Varadhan @ 2015-03-26 15:10 ` Bjørnar Ness 2015-03-26 15:43 ` John W. Linville 0 siblings, 1 reply; 9+ messages in thread From: Bjørnar Ness @ 2015-03-26 15:10 UTC (permalink / raw) To: Sowmini Varadhan; +Cc: netdev 2015-03-26 15:53 GMT+01:00 Sowmini Varadhan <sowmini05@gmail.com>: > On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness <bjornar.ness@gmail.com> wrote: > >>>> ip route add 10.0.0.0/16 via fe80::225:90ff:fed3:bfb4/64 dev sfp0 >>> >>> Trying to understand what the desired behavior is, for the route >>> above: if I send a packet from 10.0.0.1 to 10.0.0.2, you want the dst-mac >>> to be the mac address of e80::225:90ff:fed3:bfb4??? >> >> Absolutely, correct. > > What if the current node does not want to support ipv6? This sounds > pretty "creative", if this can work, you might as well make the nexthop to > be the L2 address of the gw. If it does not support IPv6 I guess the route command will fail! This is a bad argument against this. Dont see the point of limiting nexthop to L2 >> Basically because you either added the route manually, or it was provided >> by fe80::225:90ff:fed3:bfb4 itself via some routing protocol (MP-BGP) >> >> This will be the same as any other route. How do you know it forwards traffic.. > > because you would be running a routing protocol that manages reachability > of the gw and the route. RIP, OSPF, BGP etc all have a lot of mechanisms > to monitor liveness of the route and of the nexthop, which has to be of > the same address family as the route itself. Did you look at RFC5549 and MP-BGP? >> In large routed setups, address management in general and lack of IPv4 addresses >> can become a big hassle. Beeing able to get a ipv6 neighbor for a ipv4 >> route would >> make this process a lot simpler. > > Yes, that's the motivation behind all the tunneling/transition mechanisms > in the various ipv6 working groups. Point is we dont need another software encapsulation for this to work. It can work more or less "out-of-the-box" if ipv4 nexthops can be ipv6 Say you have 10 racks with 40 servers in each, two links to each server to each TOR, and you want to run a full L3 BGP routed network here. The configuration/addressing overhead we need today is enormous. With neighbor discovery and IPv6 nexthops, this configuration can be done totally dynamic using link-local addresses. I know people are working on this, but as I wrote in the first mail, I just hope it gets done "right", not hacky like this (POC): https://ams-ix.net/downloads/RFC5549/ -- Bj(/)rnar ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 15:10 ` Bjørnar Ness @ 2015-03-26 15:43 ` John W. Linville 2015-03-26 16:27 ` Andy Gospodarek 0 siblings, 1 reply; 9+ messages in thread From: John W. Linville @ 2015-03-26 15:43 UTC (permalink / raw) To: Bjørnar Ness; +Cc: Sowmini Varadhan, netdev, Andy Gospodarek On Thu, Mar 26, 2015 at 04:10:21PM +0100, Bjørnar Ness wrote: > 2015-03-26 15:53 GMT+01:00 Sowmini Varadhan <sowmini05@gmail.com>: > > On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness <bjornar.ness@gmail.com> wrote: > > > >>>> ip route add 10.0.0.0/16 via fe80::225:90ff:fed3:bfb4/64 dev sfp0 > >>> > >>> Trying to understand what the desired behavior is, for the route > >>> above: if I send a packet from 10.0.0.1 to 10.0.0.2, you want the dst-mac > >>> to be the mac address of e80::225:90ff:fed3:bfb4??? > >> > >> Absolutely, correct. > > > > What if the current node does not want to support ipv6? This sounds > > pretty "creative", if this can work, you might as well make the nexthop to > > be the L2 address of the gw. > > If it does not support IPv6 I guess the route command will fail! This > is a bad argument > against this. Dont see the point of limiting nexthop to L2 This topic was discussed at the recent Netconf event in Ottawa. This is a viable means of interconnecting two IPv4 "island" subnets across an IPv6 "ocean" backplane. Andy Gospodarek gave a short discussion on the topic, and IIRC it was warmly received. I'll Cc him on this message -- I think he had a (fairly simple) patch more or less ready. Hth! John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 15:43 ` John W. Linville @ 2015-03-26 16:27 ` Andy Gospodarek 2015-03-26 16:37 ` Eric Dumazet 0 siblings, 1 reply; 9+ messages in thread From: Andy Gospodarek @ 2015-03-26 16:27 UTC (permalink / raw) To: John W. Linville, Bjørnar Ness; +Cc: Sowmini Varadhan, netdev On Thu, Mar 26, 2015 at 11:43:36AM -0400, John W. Linville wrote: > On Thu, Mar 26, 2015 at 04:10:21PM +0100, Bjørnar Ness wrote: > > 2015-03-26 15:53 GMT+01:00 Sowmini Varadhan <sowmini05@gmail.com>: > > > On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness <bjornar.ness@gmail.com> wrote: > > > > > >>>> ip route add 10.0.0.0/16 via fe80::225:90ff:fed3:bfb4/64 dev sfp0 > > >>> > > >>> Trying to understand what the desired behavior is, for the route > > >>> above: if I send a packet from 10.0.0.1 to 10.0.0.2, you want the dst-mac > > >>> to be the mac address of e80::225:90ff:fed3:bfb4??? > > >> > > >> Absolutely, correct. > > > > > > What if the current node does not want to support ipv6? This sounds > > > pretty "creative", if this can work, you might as well make the nexthop to > > > be the L2 address of the gw. > > > > If it does not support IPv6 I guess the route command will fail! This > > is a bad argument > > against this. Dont see the point of limiting nexthop to L2 > > This topic was discussed at the recent Netconf event in Ottawa. > This is a viable means of interconnecting two IPv4 "island" subnets > across an IPv6 "ocean" backplane. > > Andy Gospodarek gave a short discussion on the topic, and IIRC it > was warmly received. I'll Cc him on this message -- I think he had a > (fairly simple) patch more or less ready. Yes, I do have one! I was working on some other issues and need to rebase it based on Eric's recent work. It was fairly simple and the netlink changes are also not too difficult so the patch to iproute2 was small. I have an older patch you can see here: https://github.com/gospo/net-next/commit/7f602a54424f453872b6a45ae5ed4d3a601db91d Shall I rebase and post to the list for all to see? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 16:27 ` Andy Gospodarek @ 2015-03-26 16:37 ` Eric Dumazet 2015-03-26 17:17 ` Andy Gospodarek 0 siblings, 1 reply; 9+ messages in thread From: Eric Dumazet @ 2015-03-26 16:37 UTC (permalink / raw) To: Andy Gospodarek Cc: John W. Linville, Bjørnar Ness, Sowmini Varadhan, netdev On Thu, 2015-03-26 at 12:27 -0400, Andy Gospodarek wrote: > Yes, I do have one! I was working on some other issues and need to > rebase it based on Eric's recent work. It was fairly simple and the > netlink changes are also not too difficult so the patch to iproute2 was > small. > > I have an older patch you can see here: > > https://github.com/gospo/net-next/commit/7f602a54424f453872b6a45ae5ed4d3a601db91d > > Shall I rebase and post to the list for all to see? Absolutely ! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPv6 nexthop for IPv4 2015-03-26 16:37 ` Eric Dumazet @ 2015-03-26 17:17 ` Andy Gospodarek 0 siblings, 0 replies; 9+ messages in thread From: Andy Gospodarek @ 2015-03-26 17:17 UTC (permalink / raw) To: Eric Dumazet Cc: John W. Linville, Bjørnar Ness, Sowmini Varadhan, netdev On Thu, Mar 26, 2015 at 09:37:51AM -0700, Eric Dumazet wrote: > On Thu, 2015-03-26 at 12:27 -0400, Andy Gospodarek wrote: > > > Yes, I do have one! I was working on some other issues and need to > > rebase it based on Eric's recent work. It was fairly simple and the > > netlink changes are also not too difficult so the patch to iproute2 was > > small. > > > > I have an older patch you can see here: > > > > https://github.com/gospo/net-next/commit/7f602a54424f453872b6a45ae5ed4d3a601db91d > > > > Shall I rebase and post to the list for all to see? > > Absolutely ! > Enthusiasm appreciated! Rebasing and testing now. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-03-26 17:17 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-26 13:16 IPv6 nexthop for IPv4 Bjørnar Ness 2015-03-26 14:29 ` Sowmini Varadhan 2015-03-26 14:39 ` Bjørnar Ness 2015-03-26 14:53 ` Sowmini Varadhan 2015-03-26 15:10 ` Bjørnar Ness 2015-03-26 15:43 ` John W. Linville 2015-03-26 16:27 ` Andy Gospodarek 2015-03-26 16:37 ` Eric Dumazet 2015-03-26 17:17 ` Andy Gospodarek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.