> From: Ralph Droms, November 05, 2007 9:36 PM > > No, PANA would not require changes to the DHCP client > behavior if the first hop relay agent is configured to > discard DHCP messages until PANA authentication is complete.
I am assuming you are talking about discarding DHCP messages for the second DHCP assigned IP address when the lease for the first address expires. In old PANA threads such as: http://www1.ietf.org/mail-archive/web/pana/current/msg00376.html They worried quite a bit about uncoordinated state machines resulting in slow client logon. Up to 30 second delays were mentioned. Since random duration global IP address assignment delays of up to 30 seconds is not acceptable, I am expect that PANA has fixed this. Could one of the PANA people explain how? BTW: even with the DHCP message for the 1st IP address, there are PANA drafts which require DHCP client modifications. For example: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-dhc-paa-opt ion-05.txt "defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more of PANA Authentication Agents (PAA)." > Presumably whatever mechanism is used to allow IP traffic > after PANA authentication could also trigger the relay agent > to allow DHCP forwarding. This would again result in DHCP Timeouts unless coordination of the client state machine is occurring. (And even if there is coordination with the client, there is ugly system behavior if the 2nd client DHCP message is initiated before the relay agent has completed updating its filters!) Eric > Of course, I'm speculating wildly here about implementation > details without the benefit of any system architecture docs... > > - Ralph > > On Nov 5, 2007, at Nov 5, 2007,8:33 PM, Richard Pruss wrote: > > > > > > > Bernard Aboba wrote, around 6/11/07 11:11 AM: > >>> But let's have a fair evaluation. If we decide that PANA > fits the > >>> requirements perfectly, the above objections apply > equally well to > >>> it. > >> > >> Actually, I'm not clear that the objections apply equally well to > >> PANA. > >> > >> On the Windows platform at least, there is an API that permits > >> integration of new EAP lower layers. That means that PANA support > >> can be added by a third party with no required changes to the > >> operating system. > >> > >> Since DHCP/EAP requires change to the DHCP state machine, the work > >> required would be considerably greater. > >> > >> > >> > > Does PANA not also require changes to the DHCP state > machine to stop > > it running until PANA has authenticated on the link local address? > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
