All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg <lego12239@yandex.ru>
To: Thorsten Glaser <t.glaser@tarent.de>
Cc: netdev@vger.kernel.org
Subject: Re: ipv6 ::1 and lo dev
Date: Thu, 19 Aug 2021 12:16:52 +0300	[thread overview]
Message-ID: <20210819091652.GA22188@legohost> (raw)
In-Reply-To: <fb3e3ad3-7bc3-9420-d3f6-e9bae91f4cd@tarent.de>

On Wed, Aug 18, 2021 at 07:47:37PM +0200, Thorsten Glaser wrote:
> On Wed, 18 Aug 2021, Oleg wrote:
> 
> > I try to replace ::1/128 ipv6 address on lo dev with ::1/112 to
> > access more than 1 address(like with ipv4 127.0.0.1/8). But i get
> 
> AIUI this is not possible in IPv6, only :: and ::1 are reserved,
> the rest of ::/96 is IPv4-compatible IPv6 addresses.

This is a big mistake of standards and, i think, we shouldn't conform to
standards in this area. Because standards conflicts with real life practice
(and needs) here.

I think, we can safely use ::/104 as analog of 127.0.0.1/8, because, AFAIK,
0.0.0.0/8 isn't used now in practice and thus there are no problems with
ipv4-mapped ipv6 addresses.

In any case, we should allow users to get an expected behaviour for lo dev
address - as with 127.0.0.1/8. I.e. when i remove ::1/128 and set ::1/104
i expect that ping ::2, ::3 and etc will work(may be only if some parameter for
"ip a add" is specified).

Unfortunately i can't suggest any patch, because my kernel programming level
is about 0 :-). May be anybody can do it?

> I never understood why you’d want more than one address for loopback
> anyway (in my experience, the more addresses a host has, the more
> confused it’ll get about which ones to use for what).

Besides already mentioned cases i say you about my 2 cases:

1. We have a service which serve many tunnels to different machines
  (think of it as many ssh -R X:127.0.0.N:Y to our service servers). Each
  machine is mapped to address:port(thus it constant between sessions).
  And we use many addresses from 127.0.0.1/8 :-).
2. We have many qemu VMs on several hardware hosts. We assign an address
  to every VM from 127.0.0.1/8 for comfort use of telnet/vnc. E.g. we
  have in /etc/hosts something like this(where third column is for
  host machine index and fourth column is for VM index):

  ...
  127.0.1.2       www1.vm
  127.0.1.3       www2.vm
  127.0.1.4       www3.vm
  127.0.1.5       dns1.vm
  127.0.1.5       dns2.vm
  127.0.1.6       mail1.vm
  ...

  and run qemu with:

  -serial telnet:dns1.vm:23,server,nowait -vnc dns1.vm:0

  This /etc/hosts syncronized between hardware hosts and if one if it fail
  we can migrate all VMs from it to another one and their addresses aren't
  intermixed.

-- 
Олег Неманов (Oleg Nemanov)

      parent reply	other threads:[~2021-08-19  9:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 16:59 ipv6 ::1 and lo dev Oleg
2021-08-18 17:47 ` Thorsten Glaser
2021-08-18 20:17   ` Willy Tarreau
2021-08-18 21:15     ` Stephen Hemminger
2021-08-19  9:16   ` Oleg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210819091652.GA22188@legohost \
    --to=lego12239@yandex.ru \
    --cc=netdev@vger.kernel.org \
    --cc=t.glaser@tarent.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.