All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.