netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: shanwei@cn.fujitsu.com
Cc: albertpretorius@yahoo.co.uk, netdev@vger.kernel.org,
	yoshfuji@linux-ipv6.org, pekkas@netcore.fi, jmorris@namei.org
Subject: Re: IPV6 loopback bound socket succeeds connecting to remote host
Date: Thu, 16 Dec 2010 12:18:05 -0800 (PST)	[thread overview]
Message-ID: <20101216.121805.59690737.davem@davemloft.net> (raw)
In-Reply-To: <4CF75BC3.1020606@cn.fujitsu.com>

From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Thu, 02 Dec 2010 16:41:39 +0800

> Albert Pretorius wrote, at 12/02/2010 03:45 PM:
>> Hi
>> 
>> --- On Wed, 1/12/10, Shan Wei <shanwei@cn.fujitsu.com> wrote:
>>> I think it make nonsense to translate data between loopback
>>> device and other e.g. eth0 device in same machine.
>> 
>> I agree, RFC4291 makes it clear for IPV6 that no interface should accept traffic from loopback, I should not have tried to make it behave like IPV4.
>> I can not find an equivalent statement for IPV4 though, all I could find is this from RFC3330:
>> 
>>    127.0.0.0/8 - This block is assigned for use as the Internet host
>>    loopback address.  A datagram sent by a higher level protocol to an
>>    address anywhere within this block should loop back inside the host.
>>    This is ordinarily implemented using only 127.0.0.1/32 for loopback,
>>    but no addresses within this block should ever appear on any network
>>    anywhere [RFC1700, page 5].
>> 
>> Do you perhaps know?
> 
> There are no same statement for IPv4 loopback address. I have checked RFC1122, RFC1700 and RFC5753 .		

Shan, you really need to handle this in the ipv6 routing code.

Your approach will only modify socket based route handling, it will
not handle the ipv6 forwarding case which as per the quoted RFC
sections must be handled too.

  reply	other threads:[~2010-12-16 20:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-29 10:55 IPV6 loopback bound socket succeeds connecting to remote host Albert Pretorius
2010-12-01  8:18 ` Shan Wei
2010-12-02  7:45   ` Albert Pretorius
2010-12-02  8:41     ` Shan Wei
2010-12-16 20:18       ` David Miller [this message]
2010-12-20  6:31         ` Shan Wei
2010-12-20  6:43           ` David Miller
2010-12-22  7:06             ` Shan Wei
2010-12-29 16:53               ` Albert Pretorius

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=20101216.121805.59690737.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=albertpretorius@yahoo.co.uk \
    --cc=jmorris@namei.org \
    --cc=netdev@vger.kernel.org \
    --cc=pekkas@netcore.fi \
    --cc=shanwei@cn.fujitsu.com \
    --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).