Re: Disabling ip4 and IPV6 on F20RC1



----- Original Message -----
From: "Tore Anderson" <tore fud no>
To: "Pavel Simerda" <psimerda redhat com>, "Bjørn Mork" <bjorn mork no>
Cc: "Dan Winship" <danw redhat com>, networkmanager-list gnome org
Sent: Tuesday, December 17, 2013 5:36:48 PM
Subject: Re: Disabling ip4 and IPV6 on F20RC1

* Pavel Simerda

But unfortunately we need to be a little bit careful about the theory
written down on paper and the actual needs. Linux has the long
history of allowing more than just blind following of what's written
down. And I'm not the only person who repeatedly proved that IPv6
standards are not yet mature and that some of the requirements and
suggestions don't lead to good network experience.

So it appears to be my view against the details written down in one
of the very RFCs and I'm indeed going to speak up my concerns with
the IETF as well (and the list of those is quite big).

The number of ways in which you can use Linux to violate published
standards are probably near-infinite. But just because you can, doesn't
mean you should.

I think we should try to refrain from empty phrases, especially when posting to the mailing list.

While you are of course completely free to spend your time implementing
NetworkManager support for some link-local-free IPv6-ish protocol, and
to pursue IETF standardisation of this new protocol,

Nope, I'm not interested in anything like that. Instead I'm interested in practical networking which can't be 
based on random phrases taken from immature standards taken out of context. Our previous discussions should 
be taken as an evidence that I'm very interested in (and actually daily using) link-local addresses for 
application networking (not just rdisc and DHCP).

I would find it sad
to see development effort being wasted in such a way when there are no
shortage of actually useful IPv6-related things to fix and/or implement
in NM;

It's better to accept the open source way where you don't usually call the work spent on something you're not 
so much interested in a waste. Especially now that NetworkManager is not my day-to-day work any more 
(although you're not expected to know that bit).

After all, the bits about link-local addresses should be more or less taken as a side effect of documenting 
the methods in my own way. I do believe turning kernel link-local addresses on/off separately is useful for 
many purposes (including just asking the kernel to reset them and including static address scenarios). I do 
believe any effort to make IPv6 as close as possible to IPv4 is worth taking. But I'm not at all against 
hearing other opinions. In fact I will be more than happy if you edit the page I linked (as you did in the 
past with other pages) and if we want to provide information we disagree on, we can always find a way to do 
so (e.g. by documenting particular pros and cons so that anyone can choose the ones important for him and 
decide for himself).

IPv6 support on mobile broadband,

I don't have much knowledge in that. Except the very exception of the point to point nature where 
link-local/global addresses distinction loses its sense. I don't think I currently have time and motivation 
to do that. I'll be happy if anyone does, though.

IPv6 support in applicable VPN plugins,

That requires knowledge of the VPN plugins and IPv6 in the respective VPN systems. I don't think I currently 
have time and motivation to do that. I'll be happy if anyone else does, though.

correct handling of RA lifetimes, and so on.

There's no correct handling of RA lifetimes until the standards are fixed, anyway. That is something I feel 
much more motivated for, so if you want to discuss that with me, feel free. A wiki page might be useful for 
that.

It's only a bit sad that the whole handling of lifetimes is there because of a (in my opinion shortsighted) 
decision to develop a stateless autoconfiguration protocol for IPv6. Single-lifetime contract-based protocol 
like DHCP seems to be a much better option in the long term and this is one of the things that delays IPv6 
deployment without any real advantages. But that's nothing more than an opinion of mine.

Cheers,

Pavel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]