Re: MC 7304 ipv4v6

[Bjørn Mork <bjorn mork no>]

Reinhard Speyerer <rspmn arcor de> writes:
> On Mon, Nov 30, 2015 at 10:53:35AM +0100, Bjørn Mork wrote:
>
> > hmm, "fixing" this seems simple enough: Just add the necessary code to
> > net/ipv6/addrconf.c for handling ARPHRD_NONE devices.  But I have two
> > questions:
> >
> > 1) will random addresses be a problem?  We might have to recreate the
> >  address every time the interface comes up, as we have nowhere to store
> >  it AFAICS.  So the link-local address will change whenever you toggle
> >  the device down/up.
>
> This might invalidate some fundamental assumptions in the firmware about
> the host environment. My suggestion would therefore be to avoid changing
> the link-local address when changing the network interface up/down status.

Yes.  That's definitely so unexpected that it's better not to implement
it at all..

> > 2) what about other ARPHRD_NONE devices? This is currently 'tun', 'hso'
> >  and 'n_gsm'.  Will a default IPv6 link local address be a problem for
> >  any of these?
> >
> > The only device type I know how to test is 'tun'.  And to me it looks
> > like an obvious winner there.  Why shouldn't tun devices do SLAAC and
> > support other IPv6 link local services by default?  But I don't normally
> > use such devices, so I know very little about real use cases...
>
> Since tun may have non-IP use cases and n_gsm is a line discipline AFAIK
> we should probably not overload ARPHRD_NONE like this.

I'm not sure that would be a problem, any more than using ethernet for
non-IP is one.

> > If we can't add such generic ARPHRD_NONE code, then the alternatives I
> > can see are
> >  - defined an new ARPHRD_ type with about the same semantics, and add
> >    ipv6/addrconf code for it
> >  - do some driver hack - I believe it is possible to manually create an
> >    IPv6 device and assign an address from the driver.
> >
> > I don't like either.  So I guess I will propose the ARPHRD_NONE code.
>
> Perhaps it might be possible to use raw IP mode with IPv6 without a
> link-local address by using WDS status indications?

It's definitely possible to use raw IP with IPv6 without a link local
address.  But I don't think it should be :)

> The reason I used
> the original ifconfig inet6 up implementation was that this was
> required to trigger SLAAC according to ETSI/3GPP TS 27.060 for early
> MC77xx firmware versions as WDSGetCurrentSettings did not return an
> IPv6 prefix when WDSStartNetwork was finished.
>
> However at least current MC73xx firmware versions (and perhaps also
> other "modern" QMI firmwares) now proactively perform an internal SLAAC
> after a WDSStartNetwork and WDSGetCurrentSettings returns the same IPv6
> prefix as an ifconfig inet6 up with SLAAC in Ethernet mode would.  If
> mReconfigureRequired from the WDSPacketServiceStatusReport TLV 0x01
> would correctly indicate when the IPv6 prefix assigned from the
> network has changed it might be possible to mirror the effect of SLAAC
> for raw IP from user space.

Yes, I know that the prefix could change - in theory.  I have my doubts
whether that would actually work in the real world.  The status is about
the same as for IPv6 renumbering elsewhere: All the necessary tools are
there so you can make it work, but every user and device have made some
bogus assuption that needs fixing first.

I don't think we are any more guaranteed that renumbering will work with
SLAAC than without.  The chances are about the same.

And I believe the good NM people will want to do SLAAC in userspace
anyway.  So the missing link local address might be a non-issue for NM?

In any case, I got very helpful feedback from YOSHIFUJI Hideaki so I
am considering implementing a random (but permanent) ifid allocation
scheme after all.


Bjørn