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

Re: stretch and DNS name resolution service for other devices on a LAN



Le 22/02/2018 à 22:57, David Wright a écrit :
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.

They are meant to be used with low level IPv6 services (automatic configuration, neighbour discovery...)

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 did not pay any money for IPv6 link local addresses.

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.)

Hackish.

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,

No, A MAC address is configured in the ethernet adapter NVRAM. Besides, The two interfaces we are discussing about are not connected to any router.

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.

Get a ULA prefix. Online generators are available on the web.
Pick up two host addresses in the prefix.
Statically assign an address to the two interface in /etc/network/interfaces or any other network manager.

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.

You can't be more wrong. With the static configuration of a pair of IPv4 addresses in a distinct prefix at both ends of the ethernet link the traffic between these addresses would flow through the ethernet link.

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).

Same with IPv4.

Anyway, we have a saying here which roughly translates to : "you cannot force an unthirsty donkey to drink".


Reply to: