Lines Matching refs:that
28 ** This document discusses aspects of the DHCPv4 client design that have
43 This document assumes that the reader is familiar with the following
64 that it is able to process DHCPv6. It would also have been possible
84 assumptions built into that design.
89 with the DHCP server that granted the address, the address itself,
93 that are under DHCP control. IP interfaces not under DHCP control
94 (for example, those that are statically addressed) are not included
110 copies in the driver layer that end up sapping performance.)
116 list and drops that reference. hold_ifs() and release_ifs() are
117 used by data structures that refer to ifslist entries, such as timer
118 entries, to make sure that the ifslist entry isn't freed until the
121 The design is single-threaded, so code that walks the global list
123 references that may be used at a different time (i.e., pointers
146 that if cancellation is needed, there's a single point where the
157 work. This means that, on Solaris, the client doesn't need DLPI to
159 means that, unlike IPv4 DHCP, DHCPv6 does not need to obtain a lease
171 and the implementation binds that to a single IP logical interface
202 databases that need to be kept in sync. (The equivalent mechanism
210 that each can cause RENEWING or REBINDING state independently.
232 Fortunately, DHCPv6 does end up with one fixed name that can be used
235 that has this link local address (normally the same as the IP
285 list linkage for each LIF, we can observe that a LIF is on exactly
289 list of LIFs that belong to the lease.
298 a state machine, then all that we can do is canonize the LIF
301 of that LIF (it was created because of a DHCPv6 IA), and disposal
327 single lease structure that points back to the same LIF (count of
349 Note that there's intentionally no ordering based on name in the
350 list of LIFs. Instead, the contiguous LIF structures in that list
356 Note also that with IPv4 DHCP, the lease points to the LIF that's
357 also the main LIF for the state machine, because that's the IP
358 interface that dhcpagent controls. With DHCPv6, the lease (one per
359 IA structure) points to a separate set of LIFs that are created just
402 The result is unsatisfying, though, as it results in code that
415 that option nesting can be handled fairly simply by nested loops,
418 wrapper on dhcpv6_find_option() that starts with a PKT_LIST pointer
424 always follow a structure that has type-dependent length. This
425 means that code that handles options must all be written to deal
447 that existing option isn't a top-level option, though, this means
448 that the caller must update the lengths of all of the enclosing
458 would be the most that is needed. This is roughly equivalent to
459 if_sock_ip_fd in the existing design, but that existing socket is
460 bound only after DHCP reaches BOUND state -- that is, when it
468 The first thing that we can do is eliminate the need for the
470 to configure interfaces -- a task that would work as well with any
472 that may arrive via broadcast. Both of these can be eliminated by
475 that the list of running state machines must be scanned on reception
482 problems in the system that may prevent binding from working in some
498 DHCP instances on that PIF are bound. In fact, the current
505 be centralized in a set_smach_state() function that changes the
510 sockets. Now that we keep track of this in a simpler manner, we no
524 mechanism that allows the client to send unicast messages to the
536 Note that it's important to avoid the temptation to resend the last
556 interfaces that are plumbed but not marked IFF_UP. This is left for
567 that's undergoing renewal. It's a simple progression (on timeout)
573 there may be multiple IAs (leases) that are effectively in renewing
575 addresses that have expired.
578 and that server either responds to our requests or doesn't, we can
586 that are within REN_TIMEOUT (10 seconds) of reaching T1 as well.
594 more IAs that need to join in because they've passed point T1 as
601 those other IAs that are past T1 but not yet at T2, we could
602 ignore them (sending only those that have passed point T2),
604 include them in the Rebind message. This isn't an issue that
617 Note that the RFC treats the IAs as separate entities when
620 confusing, especially so given that there's no reason to expect that
635 Note that it would be possible to start the SELECTING state earlier
638 the network that have seen us attempting to Rebind for quite some
639 time, and they have not responded. The likelihood that there's a
640 server that will ignore Rebind but then suddenly spring into action
641 on a Solicit message seems low enough that the optimization won't be
668 means that any persistent state must be kept in the root file
669 system, and that if we write before shutdown, we have to cope
693 that it just never succeeds or that we're rebooted before root
694 becomes writable, then the impact will be that the daemon will wake
702 provided that there's no known saved IAID using that value. Second,
713 one of the goals of the above stability plan is to support that
719 would be to add a new privileged command in ifconfig that forces
736 interfaces that ifconfig uses, so that it can launch dhcpagent and
737 trigger DHCPv6 when necessary. Note that it never needs to shut
738 down DHCPv6, as router advertisements can't do that.
751 interface into a utility that manipulates the service and passes the
768 that when it detects a new IFF_DHCPRUNNING IP logical interface, it
777 when checking for changes that would require it to "abandon" the
780 Given the way that DHCPv6 and in.ndpd control both the horizontal
802 open that interface and read the MAC address and type.
805 out the MAC type so that it can be used in the BOOTP/DHCPv4
809 implementation. However, that project is on-going at this time and
929 dhcp_smach_t.dsm_lif_down number of LIFs that have failed
958 While I'm there, I'll update snoop_arp.c so that when it prints an
977 RFC, that compares leading bits of the address without regard to
991 longest configured prefix length that also matches the candidate
997 (Note that Rule 7 will take care of temporary address preferences,
998 so that this rule doesn't actually need to look at them.)
1002 The result of this is that if there's a local address in the same
1003 configured prefix, then we'll prefer that over other addresses. If
1009 a fix for that will be included with this project.
1043 zero-length read any time the client goes away, and that will be
1090 Clearview is also contributing a new libdlpi that will work for
1092 from this daemon. When that Clearview project integrates, the
1100 This project will not fix that problem, but the DUID/IAID could be
1114 (One potential risk with this plan is that there may be server
1115 implementations that either do not implement the RFC correctly or
1134 this is not being done now is that Network Automagic [NWAM] will
1149 for IPv4. (For the latter, if we fail to do that, it will likely
1155 that new daemon (in.ndpd or dhcp6agent) the same basic IPC features
1160 state handling, this means that the new process would have to look a
1164 eliminates the confusion that the router discovery process for
1171 that, then we end up with two implementations that do many similar
1189 - Change privileges so that dhcpagent can be launched successfully
1204 - Update implementation so that it doesn't rely on gettimeofday()