netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [RFC] GTSM for IPv6
Date: Sun, 28 Mar 2010 08:57:27 -0700	[thread overview]
Message-ID: <20100328085727.48e089c0@nehalam> (raw)
In-Reply-To: <4BA71BDC.1080609@linux-ipv6.org>

On Mon, 22 Mar 2010 16:27:24 +0900
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:

> (2010/03/20 1:56), Stephen Hemminger wrote:
> > Also RFC doesn't explicitly address GTSM on IPV6.
> > Maybe the RFC editors think the problem will magically no longer exist
> > in IPv6 world because everyone will be using IPsec.
> 
> > ---
> >   include/linux/in6.h      |    3 +++
> >   include/linux/ipv6.h     |    3 ++-
> >   net/ipv6/ipv6_sockglue.c |   12 ++++++++++++
> >   net/ipv6/tcp_ipv6.c      |   17 ++++++++++++++---
> >   4 files changed, 31 insertions(+), 4 deletions(-)
> 
> Why don't we have code for other protocols such as
> UDP etc?  We already have similar protection in NDP,
> It seem to make sense.
> 
> And, as many other socket options (such as IPV6_UNICAST_HOPS
> etc.) do, please accept value of -1 to set the system's
> default (0 so far).
> 
>              x < -1:        return an error of EINVAL
>              x == -1:       use kernel default
>              0 <= x <= 255: use x
>              x >= 256:      return an error of EINVAL
> 
> We may also want to have sysctl for it.

The choice was made with IPv4 to follow the precedent of FreeBSD.
And it makes sense to me to have IPv6 follow what IPv4 did.

It doesn't make sense as a sysctl value since the value is associated
with a socket. It requires both sides to cooperate and the path
has to be known. The sender sets the hop count to 255 and the receiver
knows the sender is at most N hops away. The receiver then sets the
MIN_HOPCOUNT value to 255 - N.

Implementing GTSM for UDP, SCTP, DCCP is left as an exercise for
the reader. It can't be done in the IP layer since the IP layer
does not a socket and shouldn't be looking it up.

      reply	other threads:[~2010-03-28 22:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19 16:56 [RFC] GTSM for IPv6 Stephen Hemminger
2010-03-19 18:02 ` Pekka Savola
2010-03-22  3:16   ` David Miller
2010-03-22  7:14   ` YOSHIFUJI Hideaki
2010-03-22  7:27 ` YOSHIFUJI Hideaki
2010-03-28 15:57   ` Stephen Hemminger [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=20100328085727.48e089c0@nehalam \
    --to=shemminger@vyatta.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.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).