netdev - Re: IPv6 nexthop for IPv4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJO99Tm+ex7aELCrNnubWz1hGjELMp0LCMKSqtyr+Vci1hrmuw@mail.gmail.com>
Date:	Thu, 26 Mar 2015 16:10:21 +0100
From:	Bjørnar Ness <bjornar.ness@...il.com>
To:	Sowmini Varadhan <sowmini05@...il.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: IPv6 nexthop for IPv4

2015-03-26 15:53 GMT+01:00 Sowmini Varadhan <sowmini05@...il.com>:
> On Thu, Mar 26, 2015 at 10:39 AM, Bjørnar Ness <bjornar.ness@...il.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html