>>Not just lo0. It should be lo0 plus any not-loopback interface. >> >> > >Such as vni0? > > > Please forgive me if i am asking something stupid. (but I really don't know) What is vni0. and what is the difference between vni0 and bge0 or hme0?
>>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.) > > > I think now I am confused as well. :-) So basically milestone/network is unnecessary, because all network services can be started as long as there is lo0? In this case, do we need to distinguish the states that the machine is isolated from outside network and the machine is connected to some network? If not, then we probably don't need milestone/network. But if we eliminate this milestone, what should we do with those 3rd party services that are depending on it? (not sure what is the number yet, may need some investigation if we decide to delete this milestone.) This milestone was designed to be a stable dependency for long term so I guess there must be some depending on it. -Jan
