netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: brian.haley@hp.com
Cc: dlstevens@us.ibm.com, enh@google.com, netdev@vger.kernel.org,
	netdev-owner@vger.kernel.org
Subject: Re: linux kernel's IPV6_MULTICAST_HOPS default is 64; should be 1?
Date: Thu, 06 May 2010 00:10:32 -0700 (PDT)	[thread overview]
Message-ID: <20100506.001032.245396059.davem@davemloft.net> (raw)
In-Reply-To: <4BE2205A.3050900@hp.com>

From: Brian Haley <brian.haley@hp.com>
Date: Wed, 05 May 2010 21:50:18 -0400

> David Miller wrote:
>> From: Brian Haley <brian.haley@hp.com>
>> Date: Wed, 05 May 2010 11:36:31 -0400
>> 
>>> I now see that in Elliot's email, but I think it's incorrect.  The RFC
>>> says that setting it to -1 should get you the kernel default, which is
>>> now 1.  Without this change, setting it to -1 will get you 64, the
>>> old behavior.  If the user wants to, they can always just set it to
>>> 64 themselves, that's better than assuming when you set it to -1
>>> you're going to get 64.
>> 
>> It's not 64, it's whatever the per-route metric is.
> 
> Not unless that metric's been set via RTAX_HOPLIMIT (and I believe
> this is the unicast hop limit value anyways), and that metric
> defaults to -1.

Right, if it is, and anyone who does set it and expects the default
multicast hop limit to follow along have no portable way to code their
application in a way that works before and after fixing the RFC
issues.

I gave them a way, by making explicit setting of "-1" do what it's
always done.

> At this point in time I'll gladly implement a per-interface sysctl
> to end this discussion.

The game is over, the result decided, and this is just post-game
discussion as far as I'm concerned. :-)


      reply	other threads:[~2010-05-06  7:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-04  1:33 linux kernel's IPV6_MULTICAST_HOPS default is 64; should be 1? enh
2010-05-04  2:16 ` Brian Haley
2010-05-04  3:58   ` enh
2010-05-04  6:05   ` David Miller
2010-05-04  6:19     ` enh
2010-05-04  6:22       ` David Miller
2010-05-04  6:27         ` enh
2010-05-04  6:42           ` David Miller
2010-05-04  7:48           ` David Stevens
2010-05-04  7:57             ` David Miller
2010-05-04 14:40               ` Brian Haley
2010-05-04 16:12                 ` David Stevens
2010-05-04 16:43                   ` Brian Haley
2010-05-04 17:05                     ` David Stevens
2010-05-04 21:39                   ` David Miller
2010-05-04 21:38                 ` David Miller
2010-05-04 21:46                 ` David Miller
2010-05-04 22:26                   ` enh
2010-05-04 23:07                     ` David Miller
2010-05-05 15:36                   ` Brian Haley
2010-05-05 22:00                     ` David Miller
2010-05-06  1:50                       ` Brian Haley
2010-05-06  7:10                         ` David Miller [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=20100506.001032.245396059.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=brian.haley@hp.com \
    --cc=dlstevens@us.ibm.com \
    --cc=enh@google.com \
    --cc=netdev-owner@vger.kernel.org \
    --cc=netdev@vger.kernel.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 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).