On 6 nov 2007, at 16:28, Yoshihiro Ohba wrote:
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?
I am not sure what exact PANA deployment scenario is being discussed
here, but 30 seconds delay mentioned in the old PANA thread is between
the time when DHCP is started and the time when an IPv4 link-local
address is configured after DHCP timeouts.
Apparently my message from earlier today (yesterday by the time this
reaches the net) didn't make it, so once again:
A lot of this complexity can be avoided by using IPv6 link-local
addresses, because those are created independently from "real" address
assignment. This is of course only helpful if IPv6 is spoken on both
ends, so that would leave the Windows 98 case out in the cold.
I believe it would be orders of magnitude easier to add PANA
capability to a commercial OS because PANA doesn't need special access
to the network and doesn't clash with existing capabilities. You could
probably even run it from a browser as a java applet.
DHCP delays could be avoided by the DSLAM caching DHCP requests from
unauthenticated hosts and only responding to those when the
authentication has completed. However, if a short delay is unavoidable
I don't think that's a show stopper, usually people connect after
rebooting or some such, a process that takes a lot more time than
having to wait for a DHCP retransmit or two.
And last but not least: I'm still waiting to hear how the DSL Forum or
others intend to address IPv6. Apart from simply needing this
capability in the near future, the prospect of having to rehash all of
this in short order to add IPv6 isn't very atractive.
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)."
This is the default method for obtaining PAA's IP address. This does
not mean this is the only way. PANA allows other methods for
configuring PAA's IP address if defined. Also, a particular
deployment where PAA always resides in access router may simply use
default gateway address as PAA's address and I believe all DHCP
clients understands Router option.
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!)
I am not sure what coordination of the client state machine exactly
means, but to avoid the ugly behavior, a PAA implementation can delay
returning PANA authentication result until relay agent completes
filtering installation.
Yoshihiro Ohba
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
_______________________________________________
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
