From: Oskar Andreasson <oan@frozentux.net>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: RFC1812 and CLUSTERIP
Date: Thu, 26 Oct 2006 13:41:12 +0200 [thread overview]
Message-ID: <1161862872.6634.26.camel@LAPTOP4.MSHOME> (raw)
In-Reply-To: <453FE484.9090705@trash.net>
[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]
Hi Patrick,
It seems to me that the CLUSTERIP target relies on multicast mac to
receive packets to several hosts at the same time. Without it, only a
single machine would actually get the data? According to RFC 1812, as
you could see in the snippet, this seems to be a prohibited behavior,
more or less.
According to the RFC 1812 snippet below, it is prohibited for a router
to handle or believe in ARP replies from another (in this case) host
that basically says, send data for this host ip address to this
multicast mac address.
If a router is perfectly RFC 1812 compliant, it should to my
understanding simply not send the packets to the host in this case. It
does however not state what to do with the packets from what i've seen.
I guess this isn't a big deal yet (maybe never, who knows), but I'd
wander and make a guess that it would be a bugger to try and find out
what the hell is going on if you actually did find yourself in the
situation?
How about either document that the (possible) problem exists,
alternatively to write some kind of check for iptables to only allow
multicast ip addresses together with the CLUSTERIP target? Since the
second suggestion probably will break some users implementations, i'd at
least suggest documenting it and/or give off a warning if people do it?
On Thu, 2006-10-26 at 00:26 +0200, Patrick McHardy wrote:
> Oskar Andreasson wrote:
> > Hi all again,
> >
> > I've snowed in on the CLUSTERIP target to some extent, and I am still
> > figuring it out to some extent.
> >
> > One question that came to mind is its use of multicast MAC addresses. Is
> > it really allowed to make use of them in the way that it is right now?
> >
> > From RFC 1812 section 3.3.2:
> >
> > ------
> > A router MUST not believe any ARP reply that claims that the Link
> > Layer address of another host or router is a broadcast or multicast
> > address.
> > ------
> >
> > As I understand it, this is exactly what the CLUSTERIP target does?
> > Behaves as if a single host has a multicast address?
>
> I'm not too familiar with the CLUSTERIP target, what behaviour
> exactly are you refering to?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
next prev parent reply other threads:[~2006-10-26 11:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-25 12:05 RFC1812 and CLUSTERIP Oskar Andreasson
2006-10-25 22:26 ` Patrick McHardy
2006-10-26 11:41 ` Oskar Andreasson [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-11-30 15:36 Ben Grimm
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=1161862872.6634.26.camel@LAPTOP4.MSHOME \
--to=oan@frozentux.net \
--cc=kaber@trash.net \
--cc=netfilter-devel@lists.netfilter.org \
/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.