From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Miller <davem@davemloft.net>,
oliver@hartkopp.net, yoshfuji@linux-ipv6.org,
netdev@vger.kernel.org, koster@debian.org.tw,
socketcan@hartkopp.net, urs@isnogud.escape.de, florz@florz.de
Subject: Re: [IPV6] addrconf: Fix IPv6 on tuntap tunnels
Date: Mon, 18 Jun 2007 13:56:26 -0400 [thread overview]
Message-ID: <4676C74A.4010607@hp.com> (raw)
In-Reply-To: <20070616075555.GA23905@gondor.apana.org.au>
Herbert Xu wrote:
> On Fri, Jun 15, 2007 at 03:14:57PM -0700, David Miller wrote:
>>> No, the questions should really be:
>>>
>>> 1. Is IPV6 supported over this media type.
>>> yes: got to 2
>>> no: stop
>>>
>>> 2. Is the device MTU >= IPV6_MIN_MTU
>>> yes: continue
>>> no: stop
>>>
>>> Autoconfiguration is a layer on top of IPv6. Whether it's enabled
>>> or not should not dictate whether IPv6 addressed may be configured or not.
>> Sounds good to me, patches? :-)
>
> I don't think we need any more patches since right now MTU >= IPV6_MIN_MTU
> is the only condition we require before we allow IPv6 addresses to be added
> to an interface.
>
> The original patch simply confused this basic IPv6 address support with
> IPv6 autoconfiguration.
Looking over the history, Herbert has mostly right.
The only concern I have is that it's currently permitted to configure
IPv6 addresses on interface that would not have link-local addressing
(ex: IEEE 1394 link).
Now, is some circumstances that's ok (tuntap is a perfect example).
In others, particularly where there is an "IPv6 over foo" spec, not so much.
-vlad
next prev parent reply other threads:[~2007-06-18 17:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-14 8:16 [IPV6] addrconf: Fix IPv6 on tuntap tunnels Herbert Xu
2007-06-14 20:03 ` David Miller
2007-06-15 9:20 ` Oliver Hartkopp
2007-06-15 20:42 ` Vlad Yasevich
2007-06-15 22:14 ` David Miller
2007-06-16 7:55 ` Herbert Xu
2007-06-18 17:56 ` Vlad Yasevich [this message]
2007-06-16 12:33 ` Oliver Hartkopp
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=4676C74A.4010607@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=davem@davemloft.net \
--cc=florz@florz.de \
--cc=herbert@gondor.apana.org.au \
--cc=koster@debian.org.tw \
--cc=netdev@vger.kernel.org \
--cc=oliver@hartkopp.net \
--cc=socketcan@hartkopp.net \
--cc=urs@isnogud.escape.de \
--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 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.