Re: stretch and DNS name resolution service for other devices on a LAN
- To: debian-user@lists.debian.org
- Subject: Re: stretch and DNS name resolution service for other devices on a LAN
- From: David Wright <deblis@lionunicorn.co.uk>
- Date: Thu, 22 Feb 2018 15:57:08 -0600
- Message-id: <[🔎] 20180222215708.GC12408@alum>
- Reply-to: debian-user@lists.debian.org
- In-reply-to: <d4a60eec-5af0-749b-daa0-a2959bb2f383@plouf.fr.eu.org>
- References: <20180119151835.GA8374@alum> <slrnp6c7cj.4e4.andy@xcp-mailnews.gently.org.uk> <20180122185135.GA12212@alum> <slrnp6dvfn.8cb.andy@xcp-mailnews.gently.org.uk> <slrnp6e696.42o.curty@einstein.electron.org> <20180123134131.0fd7852e@jresid.jretrading.com> <20180123144327.GA6815@alum> <slrnp6enb9.3mb.andy@xcp-mailnews.gently.org.uk> <20180123170858.GB6815@alum> <d4a60eec-5af0-749b-daa0-a2959bb2f383@plouf.fr.eu.org>
On Tue 23 Jan 2018 at 20:56:31 (+0100), Pascal Hambourg wrote:
> Le 23/01/2018 à 18:08, David Wright a écrit :
> >
> >[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
> > | / |
> > | CAT5 cable IPv6 / |
> > | / | wireless/wired
> >[My Desktop] --- wireless connection IPv4 __/ | connections
> > | IPv4
> > |
> > [TVs]
> >
> >>Both devices will allocate themselves an address in the 'link local' range,
> >>and these addresses can then be used for communicating between the devices.
>
> They can, but they should not be used with application-layer
> protocols. Really. IPv6 link local addresses are not meant for this.
Well, I won't argue with this as I don't know what they were
originally meant for. However, I don't see why I have them if I'm
not allowed to use them when I find a good reason to. I didn't pay
good money just to stare at the numbers in ip address show.
You see, Greg only considered IPv6 in terms of the number of addresses
in the IPv4 private ranges, whereas I have this other valuable use.
> On disadvantage is that these addresses are not globally unique (the
> link local prefix exists on all interfaces) and must be appended
> with an interface name.
Not an issue here. The only change I have made since you commented
on this in August 2016 is that I now sed the output of
ip -o link show
to pick up the name of the ethernet interface. (The file that defines
my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
"eth0" doesn't cut it any more.)
> The second disadvantage is that if the
> interface is replaced for whatever reason, the interface name may
> change and the MAC address will change. The link local addresses is
> based on the MAC addresses, so it will change too.
Well, as the MAC addresses are all configured in my router, having
to edit a MAC in one bash file and push it out to my hosts is hardly
a burden after logging in to the router and typing or pasting things
there. (I hate systems that barely allow you time to sneeze before
they require logging in again.)
> IMO, simple
> static configuration with a ULA prefix, or with a global prefix if
> you own one, would be much reliable.
So what would be involved in setting that up? I have no idea where
to start. I can't believe it's as simple as 1,2,3 below.
> So Andy is right : you could use IPv4 for this. But rather with
> static configuration than unpredictable APIPA assignments.
Of course I could, but then I've got to interfere with the routing
table to prevent the file transfers going through the default
wireless interface. The whole point of plugging in a CAT5 cable is
to avoid hogging wireless bandwidth.
If I use IPv6, this is all I have to do to transfer large files at
CAT5 speeds:
1) plug a CAT5 cable into ethernet ports at each machine,
2) on the source, type: <TargetHost>6 <filenames>
3) when finished, remove the cable.
The wireless interface is unaware of any change, so I can still use
the WAN, or even connect to the other host through its normal wireless
route and, say, initiate transfers in the opposite direction (which
has the advantage that such a connection stays up after the cable has
been removed).
Cheers,
David.
Reply to: