ve
> been a good or bad idea at that time during the early days of
> development. I am actully too lazy to see why it had really been added.
See my answer to Hiroki. Since there was no clear consensus to keep
ipv6_enable I agree to allow it to stay deprecated.
> I wouldn't wan
clear,
> do> > ob> obvious way to enable or disable functionality. I see nothing in
> Hiroki's
> do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'.
> do> >
> do> > Another reason I lean to not using xxx_enable is th
o clue about IPv6
I don't want my neighbor to ping6 or ssh or even compromise my machine
just because I didn't know we have this kind of thing and autom-agic
happened."
That's why link-local addresses had been disabled in the past (similar
arguemnts would apply for the 169.254/1
John Hay wrote
in <20100405083056.ga8...@zibbi.meraka.csir.co.za>:
jh> These questions actually start more questions for me. :-) Maybe we should
jh> also think from the user perspective and list a few use cases and what a
jh> user need to put in rc.conf to make that work?
jh>
jh> Your normal de
Gentlemen,
>
> I think this is converging on a good, functional solution. Making
> ipv6_enable="NO" really turn off IPv6 looks like the ideal answer, but I
> think it's up to Hiroki to determine if it is feasible. I did my last
> kernel programming on VMS about 25 ye
tc/rc.d scripts and I
do> > ob> see no reason not to use them to enable or disable functionality
whether
do> > ob> it involves a script in rc.d or not. The idea is to have a clear,
do> > ob> obvious way to enable or disable functionality. I see nothing in
Hiroki
cused on ifconfig_IF_ipv6. I'd like to make that completely
unnecessary for the common case (RA).
> However, I disagree with using the
> name "ipv6_enable" just for the purpose. ipv6_enable=NO never
> means disabling IPv6 functionality in the kernel, and it
.conf predates /etc/rc.d scripts
> and I
> do> > ob> see no reason not to use them to enable or disable functionality
> whether
> do> > ob> it involves a script in rc.d or not. The idea is to have a clear,
> do> > ob> obvious way to enable or disabl
F manner, it
> should be done by per-AF global knobs for $ifconfig_* because the GUA
> assignment involves $ifconfig_* knobs only for the user as explained
> in another email.
>
> Let me summarize what I agree and disagree again:
>
> a. I agree that it is useful to have a knob for disa
tc/rc.d scripts and I
do> > ob> see no reason not to use them to enable or disable functionality
whether
do> > ob> it involves a script in rc.d or not. The idea is to have a clear,
do> > ob> obvious way to enable or disable functionality. I see nothing in
Hiroki
gt;>>
>>> Agree 100%. Having IPv6 SLAAC as the default is a bad idea.
>>>
>>> On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for
>>> the top level IPv6 functionality - even if it doesn't do a 100% job.
>>
>> Thanks fo
the default is a bad idea.
> >
> > On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for
> > the top level IPv6 functionality - even if it doesn't do a 100% job.
>
> Thanks for your response. Do you think the compromise that I suggested
> in my resp
uld be done by per-AF global knobs for $ifconfig_* because the GUA
assignment involves $ifconfig_* knobs only for the user as explained
in another email.
Let me summarize what I agree and disagree again:
a. I agree that it is useful to have a knob for disabling all of
ifconfig_IF_ipv6 hand
etc/rc.d scripts and I
> > ob> see no reason not to use them to enable or disable functionality whether
> > ob> it involves a script in rc.d or not. The idea is to have a clear,
> > ob> obvious way to enable or disable functionality. I see nothing in
>
Having IPv6 SLAAC as the default is a bad idea.
>
> On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for
> the top level IPv6 functionality - even if it doesn't do a 100% job.
Thanks for your response. Do you think the compromise that I suggested
in my response to K
ty whether
> ob> it involves a script in rc.d or not. The idea is to have a clear,
> ob> obvious way to enable or disable functionality. I see nothing in Hiroki's
> ob> proposal that is nearly as clear and to the point as 'ipv6_enable'.
>
> Another reason I
y
> demonstrate that it would not be hard for a miscreant to take advantage
> of this.
>
> ATM there is no alternative to running RTADV, and I am hopeful that IETF
> finishes and that vendors quickly implement RA-Guard, as well as mods
> to DHCPv6 to allow it to operate without needi
nd, I *do* like a single rc.conf knob (ipv6_enable) for
the top level IPv6 functionality - even if it doesn't do a 100% job.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/ma
ea is to have a clear,
ob> obvious way to enable or disable functionality. I see nothing in Hiroki's
ob> proposal that is nearly as clear and to the point as 'ipv6_enable'.
Another reason I lean to not using xxx_enable is that an rc.d knob
cannot control enabling/disabling the
address in that
ARIN region sitting under my desk in Berkeley.
I agree with one of Doug's points and one of Hiroki's.
>
> On 04/03/10 04:51, Hiroki Sato wrote:
> > Doug Barton wrote
> > in <4bb70e1e.3090...@freebsd.org>:
> >
> > do> 1. There sh
n how this
should be configured.
On 04/03/10 04:51, Hiroki Sato wrote:
> Doug Barton wrote
> in <4bb70e1e.3090...@freebsd.org>:
>
> do> 1. There should be an ipv6_enable knob to easily turn IPv6 configuration
> do> on and off when INET6 is in the kernel. I think the value of
Doug Barton wrote
in <4bb70e1e.3090...@freebsd.org>:
do> 1. There should be an ipv6_enable knob to easily turn IPv6 configuration
do> on and off when INET6 is in the kernel. I think the value of this kind
do> of knob is obvious, but I'd be happy to elaborate if that is nec
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
hrs@ has been doing some great work on bringing IPv6 support up to par
with IPv4, and deserves a lot of credit for that work. Included in those
changes were changes to the traditional semantics of how ipv6_enable
works. That variable was
23 matches
Mail list logo
