On 17 April 2016 at 00:49, David Miller <da...@davemloft.net> wrote: > From: Michal Kazior <michal.kaz...@tieto.com> > Date: Thu, 14 Apr 2016 14:46:28 +0200 > >> There are some use-cases to allow link-local >> routing for bridging purposes. >> >> One of these is allowing transparent 802.11 >> bridging. Due to 802.11 framing limitations many >> Access Points make it impossible to create bridges >> on Client endpoints because they can't maintain >> Destination/Source/Transmitter/Receiver address >> distinction with only 3 addresses in frame header. >> >> The default behavior, i.e. link-local traffic >> being non-routable, remains. The user has to >> explicitly enable the bypass when defining a given >> route. >> >> Signed-off-by: Michal Kazior <michal.kaz...@tieto.com> > > Sorry, whilst I realize your problem, I'm not going to add what is > explicitly a violation of the way link-local addresses are meant to > work and the very much intentional restrictions the RFCs place upon > them (they MUST not be routed). > > I also didn't see any real discussions in response to your original > proposals, not from even one person I know is knowledgable about ipv6 > and the implications your change would have, and that is extremely > troubling. > > I tried to let your patches sit for several days in order to let that > kind of discussion happen, but it didn't.
I totally understand. Thanks anyway. > So, you'll need to find another way to achieve your goals. Hmm.. I actually do have another idea in mind already. I was wondering about about implementing a link device in a similar fashion to macvlan, bridge, et al, i.e. the device would take an interface (wlan interface in my case) as a slave and perform L2 address mangling (which should be enough to accommodate the addressing deficiency in wireless client modes). The device would obviously need to do some L3/L4 packet inspection and manipulation. Would something like that be acceptable? Thoughts? Michał
