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
On Thu, Mar 26, 2015 at 9:16 AM, Bjørnar Ness [off-list ref] 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.
On Thu, Mar 26, 2015 at 9:16 AM, Bjørnar Ness [off-list ref] wrote:
quoted
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
quoted
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
On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness [off-list ref] wrote:
quoted
quoted
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
On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness [off-list ref] wrote:
quoted
quoted
quoted
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
quoted
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?
quoted
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
On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness [off-list ref] wrote:
quoted
quoted
quoted
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.
On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness [off-list ref] wrote:
quoted
quoted
quoted
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?
From: Eric Dumazet <hidden> Date: 2015-03-26 16:37:54
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?
From: Andy Gospodarek <hidden> Date: 2015-03-26 17:17:27
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:
quoted
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?