I agree with what Uwe is saying 100%.
IPv6 use is increasing - right now Google is seeing 24.9% of its
incoming daily traffic is IPv6, of course a lot of that has to do with
mobile devices.
But nobody can really ignore it any more. Ubuntu, Fedora/RedHat, Mint,
etc. - they all support the thing 'out of the box.'
In my own experience in adding IPv6 to a public-facing server with a
global static IPv4, used for my weather-station hobby, that I pretty
much had to change hosts, resolv.conf, and one firewall rule for my
firewall.
It's time to get IPv6 awareness into LFS. If not in the 'core' LFS, then
the 'core LFS' should point to a hint, because enough people are going
to want to use this.
As to the multi-stack vs. single-stack service files for the network
configuration, I will admit that I still really lean towards a single
configuration file with a multi-stack service, as long as that
multi-stack service file can handle the IPv4 only (and IPv6-only) use
cases as well. Why do I lean towards this? A few reasons:
1) Explaining to people that to add a static-IPv6 to LFS is just adding
IP6ADDRESS, IP6PREFIX to the ifconfig.eth0 file is much simpler than
saying "create this second file and put them in, and use this service
file, etc.
2) If you are going to a multi-file approach for network configuration,
I would vote it should be done fully or not at all. A good example of
this is: Where does MTU go? It's a Layer 2 thing - doesn't belong in a
v4 config, or a v6 config, as it usually applies to both, but yet
support for MTU handling is in /sbin/ifup. So how is this case handled?
And since things like MTU and other Layer2 stuff want to be settled on
an interface BEFORE you kick off the layer 3 initialization, you will
want to make sure that information is read in and processed before the
layer 3 things. However, if all configuration is in one file, then any
script handling it can do things in the proper order. In other words,
either keep things very simple (and limited in flexibility) like today -
or bite the bullet and go to a network configuration/setup system that
handles all that stuff.
-Joel
On 2019-12-12 00:27, Uwe Düffert via lfs-dev wrote:
Hi all,
On Wed, 11 Dec 2019, Bruce Dubbs via lfs-dev wrote:
Only in the case that the ISP does not have any ipv4 addresses
available is it really needed. I don't know how common that is.
I can't really tell either, but it will get more common and it
happened to me a few times in the past weeks. My ISP provides me an
IPv4 and an IPv6 address, and for years I usually only ever used the
IPv4 one. But recently it happened a few times that there was no
internet connectivity on the IPv4 one while IPv6 was working
flawlessly - with unchanged hard and software (i.e. its the same
device routing both). I'd guess they distributed more IPv4 addresses
than they had at prime time. This would fit rather good to recent
news:
https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/the-ripe-ncc-has-run-out-of-ipv4-addresses
It was quite enlightening to see what worked with IPv6 and what
didn't, if your were *suddenly* forced to use it. I was kind of
surprised that most issues were rather easy to fix - usually, software
is "already" prepared to it nowadays. Just nobody cared to configure
it so far. Prominent example: The domain of my ISPs support website
only resolves to an IPv4 address... So I appreciate your effort to
push IPv6. And yes, dual stack, not IPv6 only. You can't really tell
what "the other side" is doing. One domain might only resolve to IPv4
at all, while the other resolves to both but only IPv6 is working
properly...
Uwe
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
