Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@irif.fr>
To: "Dan Lüdtke" <mail@danrl.com>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Dave Täht" <dave@taht.net>,
	"WireGuard mailing list" <wireguard@lists.zx2c4.com>
Subject: Re: [RFC] Multicast and IPv6 Link Local Addresses
Date: Sat, 08 Apr 2017 19:15:04 +0200	[thread overview]
Message-ID: <87d1cm2547.wl-jch@irif.fr> (raw)
In-Reply-To: <E60CF446-DDB2-4C66-B221-FBDCA346E461@danrl.com>

> - Scalability: I agree with what George said. Broadcast does not scale
>   nicely, and IPv6 multicast is intended to help scaling things by
>   reaching exactly the node that need to get a copy of a particular
>   packet.

Not necessarily.  IPv6 link-local multicast replaces IPv4 link-local
broadcast.  Implementing link-local multicast as broadcast, while
suboptimal, is good enough to get IPv6 to work.

> - Multicast is not the everyday use case,

That's IPv4 thinking.  In IPv6, multicast is a basic, compulsory part of
the protocol.  A number of very basic IPv6 protocols fail to work if
link-local multicast is not functional.

See the IPv6 over NMBA (MARS, not LANE) specification for the kind of
horrors that are required to work around link layers that don't support
multicast.

> - IPv6 link-local addressing: For me it is a perfect example for "the
>   right amount of magic". It would make (at least my) life so much
>   easier. Filling the neighbor cache would require WireGuard to provide
>   (simulated or real) solicited node multicast addresses routing, right?

Yes, IPv6 neighbour discovery is one of those protocols that rely on
link-local multicast.

-- Juliusz

  reply	other threads:[~2017-04-08 17:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 14:02 Jason A. Donenfeld
2017-04-07 14:31 ` Jason A. Donenfeld
     [not found]   ` <03B23E99-75C4-4598-AC0A-3C65F346675F@gmail.com>
2017-04-07 20:42     ` Jason A. Donenfeld
2017-04-08 12:43       ` Toke Høiland-Jørgensen
2017-04-08 15:44       ` George Walker
2017-04-08  9:39 ` Dan Lüdtke
2017-04-08 17:15   ` Juliusz Chroboczek [this message]
2017-04-08 19:05     ` Juliusz Chroboczek
2017-04-17 14:11 ` Baptiste Jonglez
2017-04-17 16:55   ` Toke Høiland-Jørgensen

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=87d1cm2547.wl-jch@irif.fr \
    --to=jch@irif.fr \
    --cc=dave@taht.net \
    --cc=mail@danrl.com \
    --cc=toke@toke.dk \
    --cc=wireguard@lists.zx2c4.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).