On 12/11/2019 10:31 PM, Bruce Dubbs via lfs-dev wrote:
Recently Joel Bion sent us a hint that addresses setting static
ipv6 addresses in LFS.
http://www.linuxfromscratch.org/hints/downloads/files/IPv6-in-LFS.txt
I've been looking at this trying to decide if/how to incorporate this
into LFS.
When I look at ipv6, my first question is why? In the case of the
user that gets an ipv4 address from his ISP, the use of private
addresses 10.x, 172.16-31.x, 192.168.x makes ipv6 unneeded. 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.
Nor I, but I'm pretty sure that there are some servers, admittedly few
enough that I can't even find an example right now, that are only
available via v6 at this point. From a user POV, the only real _need_
vs. want that I can think of is in countries serviced by APNIC - for
consumers, ISPs are employing CGNAT with 4in6.
I do know that ipv4 and ipv6 can be run at the same time, but I can't
think of a valid reason unless there are two connections to the
internet with different routes. In this case the ipv6 route would be
to an ISP that does not have any ipv4 addresses available. I would
think this would be extremely rare and not just for LFS users.
There are some other advantages, but likely nothing that would make a
difference for a home user (except shortage concerns - dealing with NAT
was bad enough at first, quirks that come with double-NAT are worse and
mostly left unresolved). For me, running multiple instances of the same
services behind a firewall without PAT is nice, eliminating a proxy
(which I still have to have for v4 connectivity anyway), but again,
that's not most (or probably even many) users.
The most common reason for ipv6 would be for those that do not have
ipv4 available at all. I have not heard of that from any LFS user,
but I don't hear from everyone.
I have tried to do some ipv6 testing and I can get ping6 to work
between systems and my router. The problem is that I can't seem to
get my router to actually route ipv6 packets to the internet, so my
testing is really insufficient. This seems to be a router/ISP problem
that is beyond the scope of LFS/BLFS.
I've done it before on that platform, but it's been quite some time.
I'll see if I can dig out one of my old consumer firewalls and see if I
can make a newer build work - it'd be a few days, and be older hardware,
but I don't think too old. I've got one of those little flat black
Cicso/Linksys boxes out in the shed (N4600?) that I think will do the job.
If another editor who can do ipv6 testing can validate ipv6
instructions, I'm not opposed to adding those, but it may just be
better to reference the ipv6 hint in Section 7.5. General Network
Configuration.
I'll also note that the hint only addresses the System V book. systemd
is another matter.
Nothing to do here, it just works out of the box. Maybe provide a sample
configuration (as is all that should be done for SysV short of
installing the new service file IMO). If you are actually using it, then
the technical aspects you likely already know, you just need to be aware
of the LFS specific parts (the service file and config file in SysV) - a
link to the hint also doesn't hurt, but lets give it a couple of weeks
to shape up a bit - get rid of the /"${IFACE}$"naming requirement for
the config file, as well as the teardown fix for ifdown that Joel has
already provided for us. I can do it if he's not interested (Joel?), but
I wanted to give him the opportunity to finish it since he brought it to
us 95% complete already - just my concern about the dual-stack service
file which really shouldn't be necessary - which is my fault anyway (at
least partially - I don't recall how much I had to do with it, but I do
recall working on ifup/down at that time for at least interface
ordering) as I really should have caught the "backwards compatibility"
part of the alias naming convention when we moved to iproute2.
Also opening up ipv6 in LFS would probably mean that we would need to
address it in several BLFS packages (ntp, nfs, Network Manager, dhcp,
wireless tools, etc).
Not really. AFAICT, for all of those tools, it's just another listen or
=value entry with the same syntax in a config file (if needed at all -
even the servers that you didn't mention - if you need to supply a :port
entry, it's often done in '[fd00::1]:80' syntax). Bind is the only one
AFAICT and we already have it mostly covered - we really should be
limiting the scope in our named configuration anyway (add the 'listen-on
{127.0.0.1/8; 192.168.1.1/24; };' parameter to our sample named.conf -
just need to add a commented //listen-on-v6 entry using the private range).
--DJ
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
