Zhenghui Xie writes: > >Any? Does that include lo0? > > > > > Not just lo0. It should be lo0 plus any not-loopback interface.
Such as vni0? > The current meaning of milestone/network is: > " the service exists to ensure network security and basical network > configuration are online before establishing listening sockets." Right, and that's the part that I think is basically nonsense. Except for things that are entirely specified and controlled by local configuration data, there is no bound on when that state above might be reached. In other words, if you're using BOOTP, DHCP, or RARP to acquire interface addresses, you may have to wait "forever" for this event to occur. "Forever" is almost certainly too long for anyone's patience to hold out. Similar things occur if we have to wait on indeterminate behaviors in the lower layers, such as 802.1X or 802.11 AP interactions. There's just no telling when or if those will ever converge, and that's not necessarily a bug. So, I would assert that either the time is ripe to open sockets when time begins (which is when the ip module itself is loaded and 'lo0' logically becomes available), or that there just is no such time that can be reliably determined for all systems. Otherwise, you're stuck in an unreliable world. You have to launch those configuration services, wait "a while" for them to start, then just throw your hands in the air and continue on as if they had actually started in the event that you get tired of waiting. That makes the milestone (and anything that depends on it) unreliable. Backing up to the original problem: what actually does depend on milestone/network _and_ also needs to have some non-lo0 interface plumbed? Are any of these dependencies not bugs? If any of them are not actually bugs or design flaws in those services, then I'd like to understand how that's the case. > Right now actually we cannot ganrantee security at milestone/network > stage even though we say so. But after 6185380, IPsec will be some > separate service(s) and should not depend on network. Then I think it > can be fixed as such: > > IPsec service(s) don't depend on any network service. > milestone/network depend on IPsec service(s) and network/loopback and That part seems fine. > milestone/network will be enabled by NWAM profile when NWAM reaches > NWAM_IFF_RUNNING state. That part doesn't. > So after NWAM,(just my understanding) milestone/network means that the > machine can safely talk to the outside world. In order to talk with the outside world safely, IPsec and IP Filter both need to be initialized. Those are simple internal processes -- loading files and stuffing bits into the kernel -- that do not depend on any external behavior. Nor do these activities (as far as I understand) depend on plumbing or configuring any IP interfaces other than perhaps loopback. That makes them rather different from configuring interfaces, unless "configuring" doesn't actually mean waiting for the interfaces to become usable. (In which case, I'm even more confused about milestone/network.) -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
