All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Haley <brian.haley@hp.com>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: nicolas.dichtel@6wind.com, Florian Westphal <fw@strlen.de>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] ipv4/ipv6: check hop limit field on input
Date: Mon, 01 Jun 2009 14:55:20 -0400	[thread overview]
Message-ID: <4A242418.1090804@hp.com> (raw)
In-Reply-To: <4A242161.3010609@cosmosbay.com>

Eric Dumazet wrote:
> Nicolas Dichtel a écrit :
>> Le 01.06.2009 18:19, Florian Westphal a écrit :
>>> Nicolas Dichtel <nicolas.dichtel@dev.6wind.com> wrote:
>>>> when network stack receives a packet, it didn't check value of
>>>> ttl/hop limit
>>>> field. RFC indicates that a router must drop the packet if this field
>>>> is 0.
>>> Whats wrong with the checks in ip(6)_forward?
>> It's on forward, not on input. Router must not process it.
>> For example, if you try to ping (with ttl set to 0) the router, you will
>> receive a reply.
>>
> 
> You seem to mix requirements for routers and hosts. ttl processing
> is relevant for a gateway only, not for a host.
> 
> (terminology : gateway / host in rfc 792)
> 
> I would say : who sent this ttl=0 packet at first ?
> 
> ping -t 0 host
> ping: can't set unicast time-to-live: Invalid argument
> 
> So Linux is not able to do that, unless using tricks of course, or patching IP_TTL

'ping6 -t 0 host' does work however.  The problem I see is that if you ping a system,
if it's a host it will respond, if it's a router it won't - the RFCs don't
explicitly state the host should drop the packet.  I don't know if that difference
in behavior is desired.  Do we know how any other OSes behave?

-Brian

  reply	other threads:[~2009-06-01 18:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01 15:13 [PATCH] ipv4/ipv6: check hop limit field on input Nicolas Dichtel
2009-06-01 16:19 ` Florian Westphal
2009-06-01 16:49   ` Nicolas Dichtel
2009-06-01 17:13     ` Florian Westphal
2009-06-02  9:30       ` Nicolas Dichtel
2009-06-01 18:43     ` Eric Dumazet
2009-06-01 18:55       ` Brian Haley [this message]
2009-06-02  1:54         ` John Dykstra
2009-06-02  2:02           ` David Miller
2009-06-02  9:22             ` John Dykstra
2009-06-02  9:32               ` David Miller
2009-06-02  9:35           ` Nicolas Dichtel
2009-06-02  9:30         ` Nicolas Dichtel
2009-06-02  9:30       ` Nicolas Dichtel
2009-06-02  2:04 ` David Miller
2009-06-02  5:31   ` Eric Dumazet
2009-06-02  5:43     ` David Miller
2009-06-02  9:36   ` Nicolas Dichtel
2009-06-02  9:37     ` David Miller

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=4A242418.1090804@hp.com \
    --to=brian.haley@hp.com \
    --cc=dada1@cosmosbay.com \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.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 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.