Re: ipv6_enable
On 04/04/10 22:49, Hiroki Sato wrote: Doug Barton do...@freebsd.org wrote in 4bb95564.1070...@freebsd.org: do On 04/04/10 02:41, Hiroki Sato wrote: do Kevin Oberman ober...@es.net wrote doin 20100404053352.e6f751c...@ptavv.es.net: do do ob The use of FACILITY_enable in rc.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 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 that an rc.d knob do cannot control enabling/disabling the IPv6 functionality actually. do It was true even when we were using the network_ipv6 script. do do But that's equally true of how you're using ipv6_prefer. :) You've do basically just moved the overloading of 2 of the 3 previous functions of do ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. if checkyesno ipv6_prefer; then _ipv6_opts=-ifdisabled else _ipv6_opts=ifdisabled fi In any case, I give up. Reasonable arguments for not continuing to pursue ipv6_enable: 1. Of those who expressed an opinion, it was roughly evenly divided between support and opposition. 2. In the months since your original commit, I'm the only one who has expressed a strong preference for keeping it. Unreasonable arguments: I am completely out of time and energy to continue discussing it. So, I just committed r206408 that has most of my previously posted changes, but altered to fit both the lack of ipv6_enable, and the requirement to explicitly configure the interface. I've chosen to take the complete lack of commentary on any of my previous patches to be implicit approval of the changes. The one area where we did seem to reach consensus is that ipv6_network_interfaces=AUTO is a reasonable intermediate step, so I've included that change as well. The actual changes and the rationale for them are described in the commit message. The documentation in rc.conf.5 is greatly expanded as well, which I think should make things perfectly clear. With these changes you can now configure RA as simply as adding ifconfig_interface_ipv6=RTADV to rc.conf (assuming of course that INET6 is in the kernel). The lo0 interface will continue to be configured by default. If there are no ifconfig_interface_ipv6 options for any of the other interfaces they will not be configured for IPv6 at all. Any commentary on the technical merits of the changes is welcome assuming that the code has been reviewed and understood. Regards, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
[ snipped ] On 04/05/10 08:52, Bjoern A. Zeeb wrote: I have no idea (unless I'll read them) about the guts of various shell function magic we use to configure interfaces, and I heck do not care about where it's called autoblah_foo or zigbangbusheek as none of our users does, so I'll ignore that. I'll probably have to comment on a few rc.conf knobs as that's all a user cares about. Agreed. I've tried to make the point repeatedly that the users should not have to learn about the internals to do simple enabling of the interface. Neither IPv4 nor IPX have an AF_enable= knob in defaults/rc.conf and I cannot see why we would need it for IPv6. You don't configure it on an interface you don't have it configured an interface. The fact that it had been there for IPv6 is historic and could have 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 want to have a link-local address on my non-loopback interfaces working unless I asked for them. That's why we had ipv6_autolinklocal in the past and that's why the current rc/devd/iface framework prevents this from happening unless explicitly asked for. That's why there is nd6 options=IFDISABLED. I agree that this is a feature, and I've maintained it in the changes I just committed. I am trying to think of a reason I had needed ipv6_interfaces in the past and I can find some. I have checked my current configurations and I couldn't find any instance of *interfaces anymore. Being able to use ifconfig_IF**, especially with the IPv6 per interface options, seems to have fixed all for me with the current implementation. It's probably worth pointing out that this is because of the defaults in /etc/defaults/rc.conf. Why do we need ipv6_prefer? Well, actually we do not need it. We could have people use ip6addrctl and a static config file with their preference. Here I disagree. Having a nice knob in rc.conf makes this an easy thing for users to configure, and is consistent with your point of view above that users should not have to learn about the internals to do simple configuration. So what do you people actually want to change? You want auto-magic to happen (again) that suits your local setup or that does what we used to have in the 5.x days? Well put your local needs into ifconfig_IF_ipv6 and be done. For the record, I resent your implication that my motivations are personal. I wasn't even using the stock interface until recently, and I am more than capable of writing all the custom configuration scripts I need. My motivation is simply to keep things simple for our users, and avoid what I consider to be a POLA violation. However, given the lack of consensus around keeping the ipv6_enable option I'll accept the community's decision and move on. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. 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 for your response. Do you think the compromise that I suggested in my response to Kevin, enabling SLAAC for the interface if DHCP is in use for IPv4 is reasonable? I think this is reasonable. However, I think it would also be worth while to revisit this point when DHCPv6 has evolved to do a more complete job (like assign a default gateway). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
On 04/04/10 23:01, sth...@nethelp.no wrote: No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. 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 for your response. Do you think the compromise that I suggested in my response to Kevin, enabling SLAAC for the interface if DHCP is in use for IPv4 is reasonable? I think this is reasonable. However, I think it would also be worth while to revisit this point when DHCPv6 has evolved to do a more complete job (like assign a default gateway). Absolutely. That's why I wanted to add the [NO]RTADV knobs, so that you could combine them with DHCPv6 options. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
Doug Barton do...@freebsd.org wrote in 4bb95564.1070...@freebsd.org: do On 04/04/10 02:41, Hiroki Sato wrote: do Kevin Oberman ober...@es.net wrote doin 20100404053352.e6f751c...@ptavv.es.net: do do ob The use of FACILITY_enable in rc.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 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 that an rc.d knob do cannot control enabling/disabling the IPv6 functionality actually. do It was true even when we were using the network_ipv6 script. do do But that's equally true of how you're using ipv6_prefer. :) You've do basically just moved the overloading of 2 of the 3 previous functions of do ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included disable ACCEPT_RTADV by default, which is one of the topics we are discussing now. After I moved the initialization outside of the $ipv6_enable, then I noticed that the rest which should be inside of the $ipv6_enable is IPv6 GUA address assignments and routing settings only. Here I stepped further; I changed the disabling feature of $ipv6_enable into whether an IPv6 address is assigned or not. That was the whole story. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by disable IPv6. My opinion is ipv6_enable=NO should mean disabling IPv6 functionality completely. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as ipv6_enable as well as do not want to disable IPv6 functionality completely by default. So I am interested in what people want more precisely. -- Hiroki pgp4tjGEbjwmU.pgp Description: PGP signature
Re: ipv6_enable
On Mon, Apr 05, 2010 at 02:42:52PM +0900, Hiroki Sato wrote: Doug Barton do...@freebsd.org wrote in 4bb7e224.6020...@freebsd.org: do As we've discussed previously, you and I have a lot of disagreement on do some of these principles. I'm going to outline my responses in some do detail, however I'm also interested in what others have to say since I'd do ultimately like to see some consensus from the community on how this do should be configured. Yes, I agree that it is good to have discussion with more people. do I'm just about the biggest rc.d purist there is, and even I don't agree do with this. :) I also disagree with your idea that the original design do of rc.d scripts didn't intend for concepts like this. Sorry for the noise. This involves my preference and was a different story. Please ignore this for IPv6 discussion for the moment. do Second, if people need a way to disable IPv6 protocol, they have do already the way; no IPv6 configuration in /etc/rc.conf. If you need do a handy way for on-and-off, separating the IPv6 configuration from do rc.conf to rc.conf.ipv6 and putting a line . /etc/rc.conf.ipv6 into do /etc/rc.conf should be enough, for example. do do Even if I agreed with this idea (and I don't necessarily have strong do DISagreement with it) the knob has existed since the beginning of IPv6 do support in FreeBSD, and shouldn't be removed lightly. Personally I find do it handy to be able to configure things in rc.conf and turn them on and do off with one knob without having to comment or uncomment a bunch of stuff. I didn't removed it *lightly*. My motivation for that is I want to enable IPv6 by default without making trouble for IPv4-only people. I also committed several kernel-level measures for people who want IPv4-only, IPv6-only, and the both to live without the knob at that time. Enabling/disabling IPv6 by using rc.d script was quite complex and the switching will be incomplete with no kernel support. My conclusion for integration of the network_ipv6-netif changes was depend on if adding an GUA or not and it works fine for asynchronous invocation of rc.d/netif as well as needs no reboot for the switch (see another email for the whole story). Some processing which were in network_ipv6 (calculating $rtsol_interface and so on) are intentionally removed thanks to this assumption. If you want to go back to the old days and enable receiving RA by default, we must look into the whole process carefully again. If people want to disable IPv6 GUA assignment in per-AF 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 disabling all of ifconfig_IF_ipv6 handling. 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 will cause people tend to think IPv6 is disabled completely. If we want to disable ifconfig_IF_AF lines in a handy manner, implementing ifconfig_DEFAULT_AF is more consistent and where we should go. All of AF-specific parameters for an interface are in $ifconfig_IF_AF, and having a global knob to define the default for all interfaces are quite reasonable to me. I do not want to go back to AF-specific handling like ipv6_* wherever possible. I think this policy is compatible with David Horn's suggestions. ifconfig_DEFAULT_ipv6=DHCP for DHCPv6 by default, ifconfig_DEFAULT_ipv6=accept_rtadv for SLAAC by default, ifconfig_fxp0_ipv6=-accept_rtadv for no-SLAAC for fxp0, for example (note that I do not stick to these keywords. slaac would also be a good candidate). No concern for conflicting/confusing with IPv4; this is orthogonal among AFs. We can support another new method by just adding a keyword. Note that SLAAC and DHCPv6 are exclusive. Combinations of DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the latter is rather popular). This is one of the reasons I stick to the per-IF/per-AF solution here. b. Disagree with disabling IPv6 by default. I think there is no technical and security reason to go back to the old days. do Also, we should not consider IPv6 as special. do do I wish that were so, but I disagree. I think we need to make it as easy do as possible for users to take advantage of IPv6, but there are a lot of do reasons why it is actually special. Primarily because unlike some of our do other networking protocols it's on the cusp of being something that do everyone will need someday, but isn't quite ready for prime time. IMO, at least for handling in rc.d scripts, it is not necessary to consider IPv6
Re: ipv6_enable
I think it's clear at this point that you and I have some pretty serious disagreements about how this thing should look. I think that's unfortunate, since you have a lot of good ideas, I just think some of them are wrong. :) Seriously though, I hope we can find a way to come to agreement. I'm going to repeat myself one more time here, and in response to your other post, and then step back and let others express their opinions. I'd really like to come to an agreement on how to proceed in the next couple days. On 04/04/10 22:49, Hiroki Sato wrote: Doug Barton do...@freebsd.org wrote in 4bb95564.1070...@freebsd.org: do On 04/04/10 02:41, Hiroki Sato wrote: do Kevin Oberman ober...@es.net wrote doin 20100404053352.e6f751c...@ptavv.es.net: do do ob The use of FACILITY_enable in rc.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 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 that an rc.d knob do cannot control enabling/disabling the IPv6 functionality actually. do It was true even when we were using the network_ipv6 script. do do But that's equally true of how you're using ipv6_prefer. :) You've do basically just moved the overloading of 2 of the 3 previous functions of do ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included disable ACCEPT_RTADV by default, which is one of the topics we are discussing now. I think most of what you've got here is right, and I've tried to preserve it in my changes. My understanding is that lo0 needs to be configured if INET6 is in the kernel, but none of the other interfaces need to be. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. The end result is the same though. If ipv6_enable=no then when ifconfig_up() calls ipv6if() it'll come back negative, and that interface won't be configured for IPv6 at all. Specifically, the inet6 ifdisabled ifconfig arg will be given. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by disable IPv6. My definition is not configuring IPv6 on any interface other than lo0. My opinion is ipv6_enable=NO should mean disabling IPv6 functionality completely. If we had a method of turning off IPv6 at the kernel level even though INET6 is in the kernel then I would agree with you. Since we don't have that, inet6 ifdisabled is the next best option. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as ipv6_enable That's not what I'm proposing, have you actually looked at my patch? as well as do not want to disable IPv6 functionality completely by default. I don't know exactly what you mean by this. I _think_ you mean that IPv6 functionality should remain available, but that the interfaces should not be configured unless there is a specific configuration given via ifconfig_IF_ipv6. Is that right? If so, I agree with you, and my patch accomplishes this. The difference being that in v2 of the patch RA has to be enabled in ifconfig_IF_ipv6, OR it will be enabled if there is IPv4 DHCP configuration for the interface. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
On 04/04/10 22:42, Hiroki Sato wrote: Doug Barton do...@freebsd.org wrote in 4bb7e224.6020...@freebsd.org: If people want to disable IPv6 GUA assignment in per-AF 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. To be honest, I think what you're proposing is way too complicated, and unnecessarily so. I think you've got a very interesting vision for where we should end up down the road, but as I said in a previous message I think your proposed UI is much too complex. 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 handling. That's not what I'm actually proposing. Your idea is that the model should be focused 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 will cause people tend to think IPv6 is disabled completely. Throughout this discussion you've been ignoring something very important. The ipv6_enable knob already existed, and already had well understood semantics, which you removed. IMO this is a serious POLA violation. What I'm suggesting is a return to the same semantics that we had previously, but with your improvements running under the hood. I think being able to disable RA particularly and IPv6 generally on a per-interface basis is a tremendous improvement. If we want to disable ifconfig_IF_AF lines in a handy manner, implementing ifconfig_DEFAULT_AF is more consistent and where we should go. All of AF-specific parameters for an interface are in $ifconfig_IF_AF, and having a global knob to define the default for all interfaces are quite reasonable to me. I do not want to go back to AF-specific handling like ipv6_* wherever possible. I think this policy is compatible with David Horn's suggestions. ifconfig_DEFAULT_ipv6=DHCP for DHCPv6 by default, ifconfig_DEFAULT_ipv6=accept_rtadv for SLAAC by default, ifconfig_fxp0_ipv6=-accept_rtadv for no-SLAAC for fxp0, for example (note that I do not stick to these keywords. slaac would also be a good candidate). No concern for conflicting/confusing with IPv4; this is orthogonal among AFs. We can support another new method by just adding a keyword. Once again, I think what you're proposing is interesting, but way too complex. I certainly think it's too complex as a first step. Note that SLAAC and DHCPv6 are exclusive. That's not accurate, but it's outside the scope of this issue. Combinations of DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the latter is rather popular). This is one of the reasons I stick to the per-IF/per-AF solution here. Once again, we don't disagree on the principle, that's why I'm adding support for [NO]RTADV so that down the road we could have something like ifconfig_IF_ipv6=RTADV DHCPV6-PD, etc. b. Disagree with disabling IPv6 by default. I think there is no technical and security reason to go back to the old days. Need to be clear on what this means. Given that INET6 is in GENERIC (which I think it should be) we have to have a sensible default when it comes to configuring the external interfaces. IMO the only sensible default for that is not to. Configuring them by default when the user doesn't actually have IPv6 connectivity to the outside world would cause a lot of problems. And, well, please let me suggest something for the further discussion here. Whether we have $ipv6_enable or not, whether we enable $ipv6_enable by default or not, and whether receiving RA by default or not, are separated topics from each other. So, I would like everyone's opinions for the following points separately: 1. Do we need a knob to disable IPv6? If so, which in the following is expected for that knob? 1-a) Disable ifconfig_IF_ipv6 processing only. This means people can still do manual configuration for IPv6. My version of the patch does this. 1-b) Disable IPv6 functionlity completely. We don't currently have a way to do this at all if INET6 is in the kernel. 2. If we have a knob described in 1, what should be the default value? Off. 3. Do we go for accept RAs by default? We can break down this in the following way related to 2: 3-a) Enable IPv6 functionality and accept RAs by default. 3-b) Enable IPv6 functionality and not accept RAs by default 3-c) Disable IPv6 functionality by default and accept RAs if one enables IPv6 in rc.conf. I think this is the right answer, but others have expressed disagreement on accepting RAs by default. 3-d) Disable IPv6 functionality by default
Re: ipv6_enable
Doug Barton do...@freebsd.org wrote in 4bb95564.1070...@freebsd.org: do On 04/04/10 02:41, Hiroki Sato wrote: do Kevin Oberman ober...@es.net wrote doin 20100404053352.e6f751c...@ptavv.es.net: do do ob The use of FACILITY_enable in rc.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 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 that an rc.d knob do cannot control enabling/disabling the IPv6 functionality actually. do It was true even when we were using the network_ipv6 script. do do But that's equally true of how you're using ipv6_prefer. :) You've do basically just moved the overloading of 2 of the 3 previous functions of do ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included disable ACCEPT_RTADV by default, which is one of the topics we are discussing now. After I moved the initialization outside of the $ipv6_enable, then I noticed that the rest which should be inside of the $ipv6_enable is IPv6 GUA address assignments and routing settings only. Here I stepped further; I changed the disabling feature of $ipv6_enable into whether an IPv6 address is assigned or not. That was the whole story. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by disable IPv6. My opinion is ipv6_enable=NO should mean disabling IPv6 functionality completely. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as ipv6_enable as well as do not want to disable IPv6 functionality completely by default. So I am interested in what people want more precisely. -- Hiroki pgpB7qA06TOsk.pgp Description: PGP signature
Re: ipv6_enable
On 04/05/2010 00:21, Kevin Oberman wrote: Date: Sun, 04 Apr 2010 20:13:40 -0700 From: Doug Barton do...@freebsd.org On 04/04/10 02:41, Hiroki Sato wrote: Kevin Oberman ober...@es.net wrote in 20100404053352.e6f751c...@ptavv.es.net: 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 years ago and it was in assembly and BLISS, not C. I am just a bit uncomfortable with the use of the DHCP tag in rc.conf to control the use of SLAAC as SLAAC is so different in function and capability from DHCPv4, but it's probably the best we can do. Thanks to both of you for your attention to this. I think IPv6 is critical and anything that makes the transition easier will bear great fruit at time goes on. Not really seeing the correct thread to reply to with this content I decided to reply to Kevin and lead off from here. Seeing a lot of *_enable for interfaces makes sense in the traditional way of configuring daemons or enabling things like rtsold/rtadvd for IPv6. Don't get me wrong but the below I am not talking about phasing those _enables out for the daemons. Personally I believe that using them for such a behavior as configuring a protocol for a interface is incorrect usage given the current use of IPv4 and not needing something like ipv4_enable. Why not skip the need for ipv?_enable all-in-all and leave those out of the mix?. Since they do not really disable them or enable anything other than the ability to use and or check ipv6 related daemons. How about this? (using ath0 as the example interface) and following what we already do for DHCP on ipv4 interfaces. ifconfig_ath0_inet6=dead:beef::1000::1 RTSOL RTADV DHCP While right now without inet6 would obviously be ipv4 configured and when the time comes to switch to IPv6 by default, chop the inet6 into just inet or inet4. This eventually should lead into a smoother transition than ipv4_enable ipv6_enable while relieving some of the checks that to me just seem useless and can be checked for just by the existance of the above interface with inet6 attached to the end. Obviously if the configuration line exists then the user wants ipv6 functionality configured so check that line and mark ipv6 enabled. Maybe its just me but I really think we are trying to check for way to much here to make it a usable solution for the end user. No offense intended. PS: I would really love to sort(1) a rc.conf and have ipv4 and ipv6 functionality sorted together by interface but this is not my main goal by writing this. Same would go for static_routes but that is another story. Regards, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
John Hay j...@meraka.org.za 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 desktop/notebook user on a ipv6 radv network, what does he jh need to do to have his machine ipv6 usable? Given that it is 9-CURRENT and the box has 1 NIC (fxp0), add the following line to rc.conf: ifconfig_fxp0_ipv6=accept_rtadv jh A network server that does not accept radv, what should its ipv6 config jh in rc.conf look like? ifconfig_fxp0_ipv6=inet6 2001:db8:1::1/64 jh What about a server that accept radv (so that it can get router info) jh and have fixed addresses for it services? ifconfig_fxp0_ipv6=inet6 2001:db8:1::1/64 accept_rtadv jh A router kind of box, what should it look like? Given that the box has 2 NICs (fxp0 and fxp1), add the following lines to rc.conf: ipv6_gateway_enable=YES ifconfig_fxp0_ipv6=inet6 2001:db8:1::1/64 ifconfig_fxp1_ipv6=inet6 2001:db8:2::1/64 And, no ifconfig_IF_ipv6 line means no IPv6 configuration for the IF. After my changes committed last September, the existence of ifconfig_IF_ipv6 is used as a flag for whether IPv6 is enable or not on that interface. -- Hiroki pgpNptkehlRmA.pgp Description: PGP signature
Re: ipv6_enable
On Mon, 5 Apr 2010, jhell wrote: Hi, reading the thread in thread view I had wondered why your reply had been ignored until I realized that it was the last to come in. So I'll use it to reply to, especially as I like it. I have no idea (unless I'll read them) about the guts of various shell function magic we use to configure interfaces, and I heck do not care about where it's called autoblah_foo or zigbangbusheek as none of our users does, so I'll ignore that. I'll probably have to comment on a few rc.conf knobs as that's all a user cares about. Not really seeing the correct thread to reply to with this content I decided to reply to Kevin and lead off from here. Seeing a lot of *_enable for interfaces makes sense in the traditional way of configuring daemons or enabling things like rtsold/rtadvd for IPv6. Don't get me wrong but the below I am not talking about phasing those _enables out for the daemons. Personally I believe that using them for such a behavior as configuring a protocol for a interface is incorrect usage given the current use of IPv4 and not needing something like ipv4_enable. Why not skip the need for ipv?_enable all-in-all and leave those out of the mix?. Since they do not really disable them or enable anything other than the ability to use and or check ipv6 related daemons. As said, I like the idea of simplification. And I like the idea of having: ifconfig_IF_ipv6=inet6 ... ifconfig_IF_ipv6_aliasn=inet6 ... as well as ipv6_defaultrouter=.. ipv6_static_routes=.. ipv6_gateway_enable=.. An I like it for IPv4 and actually if you look at defaults/rc.conf you will find that we even liked it for: ifconfig_ed0_ipx=ipx 0x00010010 ipxgateway_enable=NO So here comes one of the things I don't like, POLA back POLA forth. None of the three AFs was implemented in a consistent way. In the old days we used (and still) have (though a lot less) a mix of ip6 and ipv6 and while IPv4 was kind of default there was no ifconfig_IF_ipv4=.. which has historic reasons I believe but it was ifconfig_IF_ipx= and I like it that it's ifconfig_IF_ipv6 now. It should be ipx_gateway_enable instaed of ipxgateway_enable but that's something to cleanup more easily;) Neither IPv4 nor IPX have an AF_enable= knob in defaults/rc.conf and I cannot see why we would need it for IPv6. You don't configure it on an interface you don't have it configured an interface. The fact that it had been there for IPv6 is historic and could have 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. If I boot up without having any RC framework or anything but the shell run, these days I get a network stack with a loopback interface and it looks like this: # ifconfig -a lo0: flags=8008LOOPBACK,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM if it also had an interface it would look like this: iface: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 02:00:00:00:07:0a There is no IPv6 address, there is no IPv4 address, they are down because noone told them to be up. If I up them manually it looks like this: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL iface: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 02:00:00:00:07:0a inet6 fe80::ff:fe00:70a%iface prefixlen 64 scopeid 0x2 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL This actually is bad but that's because neither devd nor the rc framework were run yet and the kernel defaults were never changed (if my memory serves me right for RFC reasons). Silly me doing this in single user;) I wouldn't want to have a link-local address on my non-loopback interfaces working unless I asked for them. That's why we had ipv6_autolinklocal in the past and that's why the current rc/devd/iface framework prevents this from happening unless explicitly asked for. That's why there is nd6 options=IFDISABLED. If if were to implement 3927 (I think it was) 169.254.0.0 stuff like some other OSes do we would want to control that as well and have it off by default. Why do I not want that for our users? Let me repeat the argument from a couple of years ago from other people: If I put my FreeBSD machine anywhere and I have no 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/16 case). Re-enabling them had never worked well in the past if ipv6_enable was NO on boot. You had to change the sysctl (manually) and then down up the interface(s) leading to serivce interruption even for IPv4. There is a PR about it if you want to check
Re: ipv6_enable
Kevin Oberman ober...@es.net wrote in 20100404053352.e6f751c...@ptavv.es.net: ob The use of FACILITY_enable in rc.conf predates /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 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 IPv6 functionality actually. It was true even when we were using the network_ipv6 script. I agree that the idea to use $xxx_enable is clear, but I think it is better not to use it because it cannot make the functionality enable/disable completely in this IPv6 case. To use IPv6, please add an IPv6 GUA to the interface makes everything simple. If we really need a knob for enable/disable, $ipv6_enable is the best. However, if it cannot disable actually, $xxx_enable is just a confusing name. I added $ipv6_prefer and removed $ipv6_enable because of this reason. I have seen a lot of people who are trying to add an IPv6 address to use IPv6 but do not notice they have ipv6_enable=NO. The trouble is that it actually works with some incomplete configurations. I want to get rid of such a possibility. Especially issues of an interface has an IPv6 GUA and no link-local address and sysadmins who want IPv4 only do not notice an IPv6 link-local address can do L3 communication. The current default settings are not the best, but a result of trade-off. ob Have you ported any of those changes to FreeBSD? There is a lot of talk ob currently about a near-term future when internal networks are v6-only, ob and all communication with v4 networks happen over some kind of ob translation layer. I'm not sure whether I like those ideas or not, but I ob think it would be great for FreeBSD to be in a leadership role here. ob ob I hate the idea. I want a end-to-end network that can be trivially ob subordinated to the control of any entity and allows for the innovation ob that an end-to-end network allows. I also fear the stability of massive ob carrier grade NAT systems. There is a huge amount of state required for ob CGN and if something goes wrong, it goes VERY wrong. My goal is for eliminating implicit IPv4 dependency and make the world AF-neutral wherever possible, not eliminating IPv4. Something like changes to rc.d/netoptions in HEAD is a good example. ob do 2. ipv6_network_interfaces should be set to AUTO, the same way that it ob do is for IPv4. ob obI agree with this change, but I am still not sure if we should have ob$ipv6_network_interfaces itself. ob ob I think it's useful because people may want to configure some interfaces ob for v6 and not others. ob ob I agree with Doug, here, though I think its use will be very limited. ob (But maybe I will be wrong.) I agree with the usefulness, but we can implement this functionality with no $ipv6_network_interfaces. For example, $network_interfaces is for all IFs and AFs, ifconfig_DEFAULT_AF=IGNORE is per-AF, and ifconfig_IF_AF=IGNORE is per-AF+IF. I think it is not necessary to have a global knobs for a specific AF because we already have a per-AF knob for each IF as described above. The reason why we have ipv6_* knobs equivalent to ones for IPv4 is that the ipv6_-prefixed knobs were used in KAME to separate the IPv6 knobs from the existing IPv4 ones. As I explained, I want to merge the duplicates in AF-neutral manner. Not want to eliminate the existing functionality itself. obFor IPv4 we do not invoke dhclient by default. ob ob I think this is an apples and oranges comparison. IPv6 has a lot of ob similarities to IPv4, but they have a lot of differences as well. As I ob said above (for better or worse) RA is fundamental to the design and ob implementation of IPv6, and for almost all users it will be necessary in ob order to get IPv6 connectivity up. ob ob I agree with Doug. This is one of the few areas where IPv4 and IPv6 are ob really different. While I don't agree that accepting RTADV should be the ob default, the IPv4 comparison is really not relevant. No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. -- Hiroki pgpJqChyz6dtF.pgp Description: PGP signature
Re: ipv6_enable
No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. 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. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
Thanks for the reply, it's nice to get other viewpoints involved, especially from those who have actual working knowledge of IPv6. I'm going to snip the bits where we agree for ease of reading. On 04/03/10 22:33, Kevin Oberman wrote: Date: Sat, 03 Apr 2010 17:49:40 -0700 From: Doug Barton do...@freebsd.org Sender: owner-freebsd-curr...@freebsd.org As we've discussed previously, you and I have a lot of disagreement on some of these principles. I'm going to outline my responses in some detail, however I'm also interested in what others have to say since I'd ultimately like to see some consensus from the community on how this should be configured. I guess it's time to put in my $.02. I do have some experience with IPv6. I have the first system to run a production IPv6 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 do...@freebsd.org wrote in 4bb70e1e.3090...@freebsd.org: I actually look forward to the day when we have an ipv4_enable, and look forward even more to the day when it defaults to off. :) It's possible that the time will come this decade when IPv4 is really not needed by the typical user, but I don't expect utilization to drop low enough that it would be appropriate to make the default no (certainly not off). POLA and general conservatism will prevent this for a long time. Yes, my sentiment is serious, but the practicalities dictated the smiley at the end. :) do 3. Each IPv6 interface (other than lo0) should be configured with rtsol do by default, but manual configuration should still be possible. I would agree with Doug EXCEPT for experiences I have had. I have been at a conference where a rogue RA totally clobbered the IPv6 network. Yes, not that many of us were running over IPv6, but I was (see the headers on this message) and it was very annoying. (It was also totally inadvertent.) I also know that a large federal research lab discovered that they had hundreds of systems running IPv6 on their network without knowing it. Almost all UNIX systems turn it on by default and some systems were configured for RTADV. It was causing all sorts of problems that were very hard to track down. Neither of these cases involved any intent to cause harm, but they 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 needing a system running RTADV on the wire. I've read the various opinions regarding having RA on by default, and have reconsidered my position. Therefore I'd like to offer a compromise. What I'm after is that modulo the need to toggle ipv6_enable if a user has an interface configured with IPv4 that the same interface should just work with IPv6. Given that RA is the default method of IPv6 deployment, and given that it will almost certainly be necessary, I thought enabling it by default was a good idea. However I'm nothing if not reasonable. :) So I'd like to suggest returning the default in ipv6_autoconfif() to off, but enabling it if the user has a DHCP option in their IPv4 configuration for that same interface. To that end I've modified my patch, you can see the new version at http://people.freebsd.org/~dougb/v6-enable-2.diff. I've also added support for an RTADV keyword in ifconfig_IF_ipv6 and updated rc.conf.5 to match. I think this is a reasonable compromise, as those users who are using DHCP for IPv4 already have the expectation that their interfaces will be automatically configured. Those who are manually specifying their v4 addresses will have a little more work to get IPv6 up and running, but I can just send them to Hiroki or Steinar for help. :) Incidental to the RA default, when working on this new patch I noticed that noafif() is only ever called by ipv6_autoconfif() so I changed it to be in line rather than a separate function. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
On 04/04/10 02:41, Hiroki Sato wrote: Kevin Oberman ober...@es.net wrote in 20100404053352.e6f751c...@ptavv.es.net: ob The use of FACILITY_enable in rc.conf predates /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 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 IPv6 functionality actually. It was true even when we were using the network_ipv6 script. But that's equally true of how you're using ipv6_prefer. :) You've basically just moved the overloading of 2 of the 3 previous functions of ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 functions into different knobs. I also have a lot of sympathy for the idea that there should be a sysctl or something to switch off IPv6 functionality even if INET6 is in the kernel. However, doing so is beyond my ability, and even if I _could_ do that, I'd _still_ want to toggle it with ipv6_enable. :) I agree that the idea to use $xxx_enable is clear, but I think it is better not to use it because it cannot make the functionality enable/disable completely in this IPv6 case. To use IPv6, please add an IPv6 GUA to the interface makes everything simple. I think I can see your perspective on this, however I don't agree with you. It also seems to me that the consensus seems to be forming around the idea that maintaining the ipv6_enable knob is a good thing. I have seen a lot of people who are trying to add an IPv6 address to use IPv6 but do not notice they have ipv6_enable=NO. I actually agree that this is a problem, which is why I've jiggled the order in etc/defaults/rc.conf a bit, and expanded the documentation in rc.conf.5. At the end of the day though, I agree that there is a learning curve, but I think that given the default of having INET6 in GENERIC it's necessary. Also, this issue doesn't change with the way you're using ipv6_prefer, it just moves the problem to that knob instead of _enable. The trouble is that it actually works with some incomplete configurations. I want to get rid of such a possibility. Especially issues of an interface has an IPv6 GUA and no link-local address and sysadmins who want IPv4 only do not notice an IPv6 link-local address can do L3 communication. I agree with your concerns in this area, which is why I moved the testing of ipv6_enable into ipv6if(). This way we don't get either of the problems you described. ob Have you ported any of those changes to FreeBSD? There is a lot of talk ob currently about a near-term future when internal networks are v6-only, ob and all communication with v4 networks happen over some kind of ob translation layer. I'm not sure whether I like those ideas or not, but I ob think it would be great for FreeBSD to be in a leadership role here. ob ob I hate the idea. I want a end-to-end network that can be trivially ob subordinated to the control of any entity and allows for the innovation ob that an end-to-end network allows. I also fear the stability of massive ob carrier grade NAT systems. There is a huge amount of state required for ob CGN and if something goes wrong, it goes VERY wrong. My goal is for eliminating implicit IPv4 dependency and make the world AF-neutral wherever possible, not eliminating IPv4. Something like changes to rc.d/netoptions in HEAD is a good example. As I've said previously, I think this is a good goal, of which I am 100% supportive. I probably shouldn't have included the aside about IPv4 stuff in my previous post, sorry for distracting the conversation. ob do 2. ipv6_network_interfaces should be set to AUTO, the same way that it ob do is for IPv4. ob obI agree with this change, but I am still not sure if we should have ob$ipv6_network_interfaces itself. ob ob I think it's useful because people may want to configure some interfaces ob for v6 and not others. ob ob I agree with Doug, here, though I think its use will be very limited. ob (But maybe I will be wrong.) I agree with the usefulness, but we can implement this functionality with no $ipv6_network_interfaces. For example, $network_interfaces is for all IFs and AFs, ifconfig_DEFAULT_AF=IGNORE is per-AF, and ifconfig_IF_AF=IGNORE is per-AF+IF. I think this might be an interesting next step, I will have to think more about it. At this time however I would really like to get HEAD back to something that reasonably resembles the previous status quo for the user interface in concept, with your improved features running under the hood. I think it is not necessary to have a global knobs for a specific AF because we already have a per-AF knob for each IF as described above
Re: ipv6_enable
On 04/04/10 02:51, sth...@nethelp.no wrote: No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. 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 for your response. Do you think the compromise that I suggested in my response to Kevin, enabling SLAAC for the interface if DHCP is in use for IPv4 is reasonable? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
Date: Sun, 04 Apr 2010 20:13:40 -0700 From: Doug Barton do...@freebsd.org On 04/04/10 02:41, Hiroki Sato wrote: Kevin Oberman ober...@es.net wrote in 20100404053352.e6f751c...@ptavv.es.net: ob The use of FACILITY_enable in rc.conf predates /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 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 IPv6 functionality actually. It was true even when we were using the network_ipv6 script. But that's equally true of how you're using ipv6_prefer. :) You've basically just moved the overloading of 2 of the 3 previous functions of ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 functions into different knobs. I also have a lot of sympathy for the idea that there should be a sysctl or something to switch off IPv6 functionality even if INET6 is in the kernel. However, doing so is beyond my ability, and even if I _could_ do that, I'd _still_ want to toggle it with ipv6_enable. :) I agree that the idea to use $xxx_enable is clear, but I think it is better not to use it because it cannot make the functionality enable/disable completely in this IPv6 case. To use IPv6, please add an IPv6 GUA to the interface makes everything simple. I think I can see your perspective on this, however I don't agree with you. It also seems to me that the consensus seems to be forming around the idea that maintaining the ipv6_enable knob is a good thing. I have seen a lot of people who are trying to add an IPv6 address to use IPv6 but do not notice they have ipv6_enable=NO. I actually agree that this is a problem, which is why I've jiggled the order in etc/defaults/rc.conf a bit, and expanded the documentation in rc.conf.5. At the end of the day though, I agree that there is a learning curve, but I think that given the default of having INET6 in GENERIC it's necessary. Also, this issue doesn't change with the way you're using ipv6_prefer, it just moves the problem to that knob instead of _enable. The trouble is that it actually works with some incomplete configurations. I want to get rid of such a possibility. Especially issues of an interface has an IPv6 GUA and no link-local address and sysadmins who want IPv4 only do not notice an IPv6 link-local address can do L3 communication. I agree with your concerns in this area, which is why I moved the testing of ipv6_enable into ipv6if(). This way we don't get either of the problems you described. ob Have you ported any of those changes to FreeBSD? There is a lot of talk ob currently about a near-term future when internal networks are v6-only, ob and all communication with v4 networks happen over some kind of ob translation layer. I'm not sure whether I like those ideas or not, but I ob think it would be great for FreeBSD to be in a leadership role here. ob ob I hate the idea. I want a end-to-end network that can be trivially ob subordinated to the control of any entity and allows for the innovation ob that an end-to-end network allows. I also fear the stability of massive ob carrier grade NAT systems. There is a huge amount of state required for ob CGN and if something goes wrong, it goes VERY wrong. My goal is for eliminating implicit IPv4 dependency and make the world AF-neutral wherever possible, not eliminating IPv4. Something like changes to rc.d/netoptions in HEAD is a good example. As I've said previously, I think this is a good goal, of which I am 100% supportive. I probably shouldn't have included the aside about IPv4 stuff in my previous post, sorry for distracting the conversation. ob do 2. ipv6_network_interfaces should be set to AUTO, the same way that it ob do is for IPv4. ob obI agree with this change, but I am still not sure if we should have ob$ipv6_network_interfaces itself. ob ob I think it's useful because people may want to configure some interfaces ob for v6 and not others. ob ob I agree with Doug, here, though I think its use will be very limited. ob (But maybe I will be wrong.) I agree with the usefulness, but we can implement this functionality with no $ipv6_network_interfaces. For example, $network_interfaces is for all IFs and AFs, ifconfig_DEFAULT_AF=IGNORE is per-AF, and ifconfig_IF_AF=IGNORE is per-AF+IF. I think this might be an interesting next step, I will have to think more about it. At this time however I would really like to get HEAD back to something that reasonably resembles the previous status quo for the user interface in concept, with your
Re: ipv6_enable
Doug Barton do...@freebsd.org wrote in 4bb7e224.6020...@freebsd.org: do As we've discussed previously, you and I have a lot of disagreement on do some of these principles. I'm going to outline my responses in some do detail, however I'm also interested in what others have to say since I'd do ultimately like to see some consensus from the community on how this do should be configured. Yes, I agree that it is good to have discussion with more people. do I'm just about the biggest rc.d purist there is, and even I don't agree do with this. :) I also disagree with your idea that the original design do of rc.d scripts didn't intend for concepts like this. Sorry for the noise. This involves my preference and was a different story. Please ignore this for IPv6 discussion for the moment. do Second, if people need a way to disable IPv6 protocol, they have do already the way; no IPv6 configuration in /etc/rc.conf. If you need do a handy way for on-and-off, separating the IPv6 configuration from do rc.conf to rc.conf.ipv6 and putting a line . /etc/rc.conf.ipv6 into do /etc/rc.conf should be enough, for example. do do Even if I agreed with this idea (and I don't necessarily have strong do DISagreement with it) the knob has existed since the beginning of IPv6 do support in FreeBSD, and shouldn't be removed lightly. Personally I find do it handy to be able to configure things in rc.conf and turn them on and do off with one knob without having to comment or uncomment a bunch of stuff. I didn't removed it *lightly*. My motivation for that is I want to enable IPv6 by default without making trouble for IPv4-only people. I also committed several kernel-level measures for people who want IPv4-only, IPv6-only, and the both to live without the knob at that time. Enabling/disabling IPv6 by using rc.d script was quite complex and the switching will be incomplete with no kernel support. My conclusion for integration of the network_ipv6-netif changes was depend on if adding an GUA or not and it works fine for asynchronous invocation of rc.d/netif as well as needs no reboot for the switch (see another email for the whole story). Some processing which were in network_ipv6 (calculating $rtsol_interface and so on) are intentionally removed thanks to this assumption. If you want to go back to the old days and enable receiving RA by default, we must look into the whole process carefully again. If people want to disable IPv6 GUA assignment in per-AF 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 disabling all of ifconfig_IF_ipv6 handling. 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 will cause people tend to think IPv6 is disabled completely. If we want to disable ifconfig_IF_AF lines in a handy manner, implementing ifconfig_DEFAULT_AF is more consistent and where we should go. All of AF-specific parameters for an interface are in $ifconfig_IF_AF, and having a global knob to define the default for all interfaces are quite reasonable to me. I do not want to go back to AF-specific handling like ipv6_* wherever possible. I think this policy is compatible with David Horn's suggestions. ifconfig_DEFAULT_ipv6=DHCP for DHCPv6 by default, ifconfig_DEFAULT_ipv6=accept_rtadv for SLAAC by default, ifconfig_fxp0_ipv6=-accept_rtadv for no-SLAAC for fxp0, for example (note that I do not stick to these keywords. slaac would also be a good candidate). No concern for conflicting/confusing with IPv4; this is orthogonal among AFs. We can support another new method by just adding a keyword. Note that SLAAC and DHCPv6 are exclusive. Combinations of DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the latter is rather popular). This is one of the reasons I stick to the per-IF/per-AF solution here. b. Disagree with disabling IPv6 by default. I think there is no technical and security reason to go back to the old days. do Also, we should not consider IPv6 as special. do do I wish that were so, but I disagree. I think we need to make it as easy do as possible for users to take advantage of IPv6, but there are a lot of do reasons why it is actually special. Primarily because unlike some of our do other networking protocols it's on the cusp of being something that do everyone will need someday, but isn't quite ready for prime time. IMO, at least for handling in rc.d scripts, it is not necessary to consider IPv6 as a special AF after I added AF-specific $ifconfig_* knobs, rc.d/netoptions changes, and so on. And, well, please let me suggest something for the further
ipv6_enable
-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 previously overloaded to allow general IPv6 configuration support, rtsol autoconfiguration, and preference of IPv6 vs. IPv4. The ipv6_prefer variable was introduced to handle the first and third functions, and ipv6_enable was deprecated. In previous discussions on various lists (including this one) there seems to have been general consensus on the following ideas: 1. There should be an ipv6_enable knob to easily turn IPv6 configuration on and off when INET6 is in the kernel. I think the value of this kind of knob is obvious, but I'd be happy to elaborate if that is necessary. 2. ipv6_network_interfaces should be set to AUTO, the same way that it is for IPv4. 3. Each IPv6 interface (other than lo0) should be configured with rtsol by default, but manual configuration should still be possible. The first question is, are the defaults listed above reasonable? I'd like to see some sort of consensus on this before we proceed with any changes. Next, I have a patch that implements the defaults suggested above that I want to offer for testing and review: http://people.freebsd.org/~dougb/v6-enable.diff The patch has several features in addition to changing the defaults. The network.subr changes in particular are difficult to visualize via the diff, it's probably easier to apply it in a test tree and review it that way. 1. Clean up and optimize the following functions: ifconfig_up (the ipv6 elements) noafif ipv6if ipv6_autoconfif The general concepts of the cleanups were to move the easy tests earlier in the functions, consolidate duplicate code, and of course to make things work with the above-listed defaults. 2. Convert noafif() to use is_wired_interface() instead of listing wireless interfaces explicitly. 3. In rc.d/netoptions, add code for an ipv6_privacy option to use RFC 4193 style privacy addresses (this is what windows does by default, FYI). 4. In /etc/defaults/rc.conf: Add ipv6_enable back, default to off. If a user has INET6 in the kernel (which it does by default) no external interfaces will be configured unless the user enables it. The lo0 interface is always configured if INET6 is in the kernel. Set ipv6_network_interfaces to AUTO. Switch ipv6_prefer to YES. If ipv6_enable is not set this will have no effect. 5. Document all of this in rc.conf.5. Enjoy, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAku3Dh4ACgkQyIakK9Wy8Pur8ACg9du7VjeEy5nxfeP1/Ij6RDQc nqgAoLfOdoOGY48MzW7OOZMWRsBKMe+g =S8zx -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
Doug Barton do...@freebsd.org 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 necessary. There were reasons related to technical difficulty and inconsistency (and a bit my preference) to drop $ipv6_enable. First, we are overly abusing $xxx_enable knob even when no corresponding rc.d/xxx file. I think $xxx_enable knob should be used only for rc.d/xxx whenever possible. It is intuitive, and what the original design of rc.d scripts intended. Although this would be another topic, it was one of the motivation for me to remove the knob. Second, if people need a way to disable IPv6 protocol, they have already the way; no IPv6 configuration in /etc/rc.conf. If you need a handy way for on-and-off, separating the IPv6 configuration from rc.conf to rc.conf.ipv6 and putting a line . /etc/rc.conf.ipv6 into /etc/rc.conf should be enough, for example. After all, protocols cannot be disabled only by using rc.d scripts. If we really need the way to do that, we have to have kernel-level knobs like sysctl or ifconfig flag. Also, we should not consider IPv6 as special. Why we have to have $ipv6_enable while we don't have $ipv4_enable? I am using INET6-only machines for years and the process removing the IPv4 dependency in the userland was really hard, but I believe no line for the protocol in /etc/rc.conf means no configuration is a policy which can be implemented and can work fine even there. do 2. ipv6_network_interfaces should be set to AUTO, the same way that it do is for IPv4. I agree with this change, but I am still not sure if we should have $ipv6_network_interfaces itself. The current implementation is equivalent to always AUTO while the default value is set NONE (see ipv6if()). The reason I changed it to NONE simply because we need to extend list_net_interfaces() for per-AF listing first. While I added some support for SLAAC, it is still not enough and not used yet. Setting $ipv6_network_interfaces (or $network_interfaces) to non-AUTO value is for narrowing down the interface list which the rc.d scripts handle, but I think this should be okay with non-AF-specific one only for the same reason as not having $ipv6_enable. Anyway, the current one is incomplete. Changing to AUTO is harmless unless we do not use list_net_interfaces() to list interfaces for some kind of automatic configuration. do 3. Each IPv6 interface (other than lo0) should be configured with rtsol do by default, but manual configuration should still be possible. Why accepting RA and sending RS by default? I object this because it is too problematic. The KAME implementation does not care about receiving RAs from multiple networks and we cannot control the accept-or-not. My patch for per-IF ACCEPT_RTADV handling was the first step, but still I can imagine cases which cause surprising results for sysadmins. My opinion is: receiving RA must be enabled only when explicitly specified. If the box is a host with only one physical interface and there is no network configuration it might be good to send RS for SLAAC as the last resort, but it is still risky. For IPv4 we do not invoke dhclient by default. This is not so simple. A network interface can appears by cloning or adding a new NIC into the system, and then devd(8) invokes rc.d/netif via /etc/pccard_ether asynchronously. If the kernel accepts RAs by default, these dynamically-added ones will also become RA-receiving interfaces. Pseudo ifconfig flags like NORTADV don't work for them. Unconditionally accepting RAs is harmful, but we still have limited countermeasures. While I recently added DEFROUTE_RTADV flag in my private branch /user/hrs/ipv6 as another step for that, I believe the disadvantages outweigh the positives at this moment. -- Hiroki pgpzjEuuWtIJz.pgp Description: PGP signature
Re: ipv6_enable
As we've discussed previously, you and I have a lot of disagreement on some of these principles. I'm going to outline my responses in some detail, however I'm also interested in what others have to say since I'd ultimately like to see some consensus from the community on how this should be configured. On 04/03/10 04:51, Hiroki Sato wrote: Doug Barton do...@freebsd.org 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 necessary. There were reasons related to technical difficulty and inconsistency (and a bit my preference) to drop $ipv6_enable. First, we are overly abusing $xxx_enable knob even when no corresponding rc.d/xxx file. I think $xxx_enable knob should be used only for rc.d/xxx whenever possible. It is intuitive, and what the original design of rc.d scripts intended. Although this would be another topic, it was one of the motivation for me to remove the knob. I'm just about the biggest rc.d purist there is, and even I don't agree with this. :) I also disagree with your idea that the original design of rc.d scripts didn't intend for concepts like this. Second, if people need a way to disable IPv6 protocol, they have already the way; no IPv6 configuration in /etc/rc.conf. If you need a handy way for on-and-off, separating the IPv6 configuration from rc.conf to rc.conf.ipv6 and putting a line . /etc/rc.conf.ipv6 into /etc/rc.conf should be enough, for example. Even if I agreed with this idea (and I don't necessarily have strong DISagreement with it) the knob has existed since the beginning of IPv6 support in FreeBSD, and shouldn't be removed lightly. Personally I find it handy to be able to configure things in rc.conf and turn them on and off with one knob without having to comment or uncomment a bunch of stuff. After all, protocols cannot be disabled only by using rc.d scripts. If we really need the way to do that, we have to have kernel-level knobs like sysctl or ifconfig flag. The standard way for users to configure stuff like this is rc.conf. That's a feature. :) Yes, more detailed knobs exist, but should the user have to learn about them? Also, we should not consider IPv6 as special. I wish that were so, but I disagree. I think we need to make it as easy as possible for users to take advantage of IPv6, but there are a lot of reasons why it is actually special. Primarily because unlike some of our other networking protocols it's on the cusp of being something that everyone will need someday, but isn't quite ready for prime time. Why we have to have $ipv6_enable while we don't have $ipv4_enable? I actually look forward to the day when we have an ipv4_enable, and look forward even more to the day when it defaults to off. :) I am using INET6-only machines for years and the process removing the IPv4 dependency in the userland was really hard, Have you ported any of those changes to FreeBSD? There is a lot of talk currently about a near-term future when internal networks are v6-only, and all communication with v4 networks happen over some kind of translation layer. I'm not sure whether I like those ideas or not, but I think it would be great for FreeBSD to be in a leadership role here. do 2. ipv6_network_interfaces should be set to AUTO, the same way that it do is for IPv4. I agree with this change, but I am still not sure if we should have $ipv6_network_interfaces itself. I think it's useful because people may want to configure some interfaces for v6 and not others. do 3. Each IPv6 interface (other than lo0) should be configured with rtsol do by default, but manual configuration should still be possible. Why accepting RA and sending RS by default? Because (like it or not) that's how the protocol works for the vast majority of IPv6 networks. I think users should have the reasonable expectation that if they enable IPv6 it should just work. That said, I added the NORTADV knob precisely because I look forward to the day when we have other viable options like DHCPv6. When the default for IPv6 configuration is no longer RA this should be revisited. I object this because it is too problematic. The KAME implementation does not care about receiving RAs from multiple networks and we cannot control the accept-or-not. My patch for per-IF ACCEPT_RTADV handling was the first step, but still I can imagine cases which cause surprising results for sysadmins. I actually agree with these concerns. I personally don't like RA, I think it has all the security concerns you describe and more. But it IS the way that the world works at the moment. DHCPv6 is in its infancy, which means that the only viable configuration options right now are RA and direct configuration via ifconfig_IF_v6. In the latter case my patch
Re: ipv6_enable
Date: Sat, 03 Apr 2010 17:49:40 -0700 From: Doug Barton do...@freebsd.org Sender: owner-freebsd-curr...@freebsd.org As we've discussed previously, you and I have a lot of disagreement on some of these principles. I'm going to outline my responses in some detail, however I'm also interested in what others have to say since I'd ultimately like to see some consensus from the community on how this should be configured. I guess it's time to put in my $.02. I do have some experience with IPv6. I have the first system to run a production IPv6 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 do...@freebsd.org 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 necessary. There were reasons related to technical difficulty and inconsistency (and a bit my preference) to drop $ipv6_enable. First, we are overly abusing $xxx_enable knob even when no corresponding rc.d/xxx file. I think $xxx_enable knob should be used only for rc.d/xxx whenever possible. It is intuitive, and what the original design of rc.d scripts intended. Although this would be another topic, it was one of the motivation for me to remove the knob. I'm just about the biggest rc.d purist there is, and even I don't agree with this. :) I also disagree with your idea that the original design of rc.d scripts didn't intend for concepts like this. Second, if people need a way to disable IPv6 protocol, they have already the way; no IPv6 configuration in /etc/rc.conf. If you need a handy way for on-and-off, separating the IPv6 configuration from rc.conf to rc.conf.ipv6 and putting a line . /etc/rc.conf.ipv6 into /etc/rc.conf should be enough, for example. Even if I agreed with this idea (and I don't necessarily have strong DISagreement with it) the knob has existed since the beginning of IPv6 support in FreeBSD, and shouldn't be removed lightly. Personally I find it handy to be able to configure things in rc.conf and turn them on and off with one knob without having to comment or uncomment a bunch of stuff. The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I see no reason not to use them to enable or disable functionality whether it involves a script in rc.d or not. The idea is to have a clear, obvious way to enable or disable functionality. I see nothing in Hiroki's proposal that is nearly as clear and to the point as 'ipv6_enable'. After all, protocols cannot be disabled only by using rc.d scripts. If we really need the way to do that, we have to have kernel-level knobs like sysctl or ifconfig flag. The standard way for users to configure stuff like this is rc.conf. That's a feature. :) Yes, more detailed knobs exist, but should the user have to learn about them? Also, we should not consider IPv6 as special. I wish that were so, but I disagree. I think we need to make it as easy as possible for users to take advantage of IPv6, but there are a lot of reasons why it is actually special. Primarily because unlike some of our other networking protocols it's on the cusp of being something that everyone will need someday, but isn't quite ready for prime time. Why we have to have $ipv6_enable while we don't have $ipv4_enable? I actually look forward to the day when we have an ipv4_enable, and look forward even more to the day when it defaults to off. :) It's possible that the time will come this decade when IPv4 is really not needed by the typical user, but I don't expect utilization to drop low enough that it would be appropriate to make the default no (certainly not off). POLA and general conservatism will prevent this for a long time. I am using INET6-only machines for years and the process removing the IPv4 dependency in the userland was really hard, Have you ported any of those changes to FreeBSD? There is a lot of talk currently about a near-term future when internal networks are v6-only, and all communication with v4 networks happen over some kind of translation layer. I'm not sure whether I like those ideas or not, but I think it would be great for FreeBSD to be in a leadership role here. I hate the idea. I want a end-to-end network that can be trivially subordinated to the control of any entity and allows for the innovation that an end-to-end network allows. I also fear the stability of massive carrier grade NAT systems. There is a huge amount of state required for CGN and if something goes wrong, it goes VERY wrong. do 2. ipv6_network_interfaces should be set to AUTO, the same way that it do is for IPv4. I agree with this change, but I am still not sure if we should
