Hiroki, Throughout your post you are *theorizing* about what you *think* will happen. You obviously missed the parts of my post(s) where I said I actually tested it. BEFORE you make any changes to the existing code you need to do some actual testing, publish your methods and results, make a persuasive argument for your proposed changes, and let other people review your work and have a chance to respond. I feel that I have tried very hard to be patient here, and I continue to have deep appreciation for the hard work that you've put into this. However I think your current stance is unreasonable, and what you've said in this post essentially amounts to "If I don't get my way I'm going to pick up my toys and go home." That's not an appropriate method of interaction for a committer, and I don't appreciate being placed in the situation of having to repeatedly ask you to act in a reasonable manner. More comments below. On 04/23/10 08:26, Hiroki Sato wrote: > Doug Barton <dougb_at_FreeBSD.org> wrote > in <4BCB6A14.5040308_at_FreeBSD.org>: > > do> > # ifconfig gif0 create > do> > # ifconfig gif0 up > do> > do> Your statement is literally true, in this case the network.subr stuff > do> "has no control" because it isn't run. That was the same for the old > do> code as it is for the new code. > > No, in this case devd(8) invokes rc.d/netif as it is created. The > old code does "ifconfig inet6 -ifdisabled" before it becomes "up" > when ipv6_prefer=YES, and the new code always does "ifconfig inet6 > ifdisabled" when no ifconfig_gif0_ipv6 line, respectively. As I said in my previous post: 1. Based on my testing the code in ifconfig_up() in network.subr that does what you're referring to is not run when you ifconfig a *gif* interface on the command line. I realize that it IS run for other interfaces. 2. The case of people randomly creating tunnels on the command line is an edge case, almost all network configuration happens in rc.conf, and EVEN IF it is required to add a line or two more than we have to do now in order to make tunnel configuration work, that is not too high a price to pay for a clean, consistent user interface. > do> Note that IPv6 link-local addresses (those that start with fe80::) will > do> be automatically configured whenever possible. You may need to remove > do> IPv6 link-local addresses manually using ifconfig(8) ... > > No, the ifdisabled flag set via devd(8) prevents this. The gif man page section that I quoted seems to indicate that enough people wanted to REMOVE the link-local addresses that it was worth mentioning explicitly how to do it. It's not at all clear to me that what you are proposing (auto-magic configuration of link-local for tunnels) is even what the majority of users want. > do> > IPv4 people hates that gif0 has an IPv6 link-local (and IPv6 > do> > communication itself), > do> > do> People who don't want v6 at all compile it out of the kernel, and the > do> whole problem goes away. The project made a decision a long time ago to > do> ship with v6 in GENERIC, so this is not a new issue. > > No, the auto link-local addr assignment was turned to off by default > some years ago for this reason. This was a secteam's decision after > IPv6 was included in GENERIC. This is an issue for both IPv4 and > IPv6 people. LOL ... If what you're saying is accurate then you're actually trying to subvert the defaults, not "restore" them. If the secteam decided that link-local addresses should not be created by default then even if your description of what the current code does is accurate, it is doing exactly what it should be doing. > do> > and IPv6 people hates that it needs an > do> > additional step to enable it (ifconfig inet6 -ifdisabled in this > do> > case). gif (and other cloned interfaces) can be created by a program > do> > (a ppp script, for example), so we cannot prepare $ifconfig line in > do> > rc.conf in advance. > do> > do> Why not? There is no reason you can't have ifconfig_* lines for > do> interfaces that are not always configured, I do it all the time. > > Because the interface identifier cannot always be known in advance. > > For example, IPv6 tunnel server/client which accept an incoming > connection and establish a gif tunnel between the two create a lot of > gif interfaces on demand, and the created gif interfaces must be > ready for IPv6 without "ifconfig -ifdisabled" if the sysadmin wants > IPv6. The net/dtcp{,client} in the ports collection is one of the > typical applications. This situation is also common in a > linkup/linkdown scripts for PPP(IPV6CP). Having all possible > interface names in rc.conf is not practical even if the number of > interfaces is small. IPv6 people (including me) surely want a knob > for "-ifdisabled on interfaces with no $ifconfig line in rc.conf" if > an interface has the ifdisabled flag. Without it, such kind of > programs do not work. Please provide actual examples of what you're describing that I can set up and test. Also, please explain why (if it is necessary at all) that the appropriate ifconfig line cannot be added to whatever technique is used to create the tunnels (script, configuration file, etc.). As I've said previously, IF there is an actual problem I am willing to work with you to fix it. But as far as I can see you are only theorizing, and the actual testing that I've done seems to indicate that your theories are wrong. > Of course we can fix the programs to always use -ifdisabled, but the > ifdisabled flag should not become popular for users. I reluctantly > designed the ifdisabled flag only for IPv4 people who hate a > link-local addr, in order to make IPv6 enabled by default as much as > possible with minimal impact to them as well as IPv6 people. This is > *the reason* why I improved the ifdisabled flag and used it in the > rc.d scripts. This has no compatibility with other KAME-derived > implementation, and for IPv6 people it is nothing but an annoying > obstacle. > > The ifdisabled flag never disables the IPv6 functionality, The description in the man page is: Set a flag to disable all of IPv6 network communications on the specified interface. If that description is not accurate, it should be updated to describe the actual effect of the flag. > and it can > make various wired situations for IPv6 people because the > functionality is enabled but the communication including the critical > ones is disabled. Please describe how this could occur. > Anyway, if we will go ahead with "to use IPv6 please do ifconfig > inet6 -ifdisabled first" or "please always add the interface name to > rc.conf" as the current implementation does, I will revert my changes > which added support of the ifdisabled flag into ifconfig before > BSDCan. That would not be an appropriate method of dispute resolution. The ifdisabled flag *as described* adds useful functionality to FreeBSD, and should not be removed unless there is a very good reason to do so. So far you have not demonstrated a good reason. > This flag is just needed to solve the issues I explained in > this and previous emails. And the issue of being able to disable IPv6 on an individual interface is a very valid one given that we ship with IPv6 in GENERIC. On this point you and I are in agreement. > do> Are you theorizing here, or do you have actual examples? If you can find > do> actual examples of "here is something that used to work, but now it does > do> not" then we can work on a solution. I am not necessarily opposed to the > do> idea of automatically creating link-local addresses for cloned > do> interfaces, but it's impossible for me to code against something I don't > do> have in front of me. :) > > See tunnel server/client programs like what I described above and/or > try to build an L2TP over UDP concentrator which uses IPV6CP + > DHCPv6-PD. I'm not asking for generic descriptions. I'm asking you to provide actual examples, preferably ones that you have actually tested with the current code that demonstrate the problem you are describing. To repeat myself, I think that you are theorizing, and that your theory is wrong. OTOH if it turns out that you are right I'm more than happy to make any needed changes, but I need something that I can test against to verify that any changes actually do what we want them to do. 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/Received on Fri Apr 23 2010 - 17:45:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC