On 11-okt-2007, at 16:12, Eric Voit (evoit) wrote:
(1) PANA does not meet IPAuth-14 "Must allow for authentication and
download of subscriber service profile before service IP address is
assigned." IPAuth14 is from the earlier DSLF liaison document to
which
Mark referred.
Hm, but this could be worked around by having a provisional IP
address that can be used to carry PANA, after which the "service" IP
address is assigned. The PANA spec specifically mentions such a
scenario. The advantage of PANA over DHCP is that, as far as I can
tell from a quick read of the spec, PANA is completely IP version
agnostic while DHCP and DHCPv6 are orthogonal protocols, raising all
kinds of issues when 1. adding IPv6 or 2. replacing IPv4 with IPv6.
Also, while it should be doable to get the necessary changes to DHCP
into new home gateways within a reasonable timeframe (but forget most
existing ones), it would be quite hard to upgrade DHCP
implementations in operating systems. A small but significant part of
all users uses OS versions which are no longer supported. Unless I
missed something, PANA could be implemented as a simple third party
application or even be run as a Java applet in a web browser.
Apart from the IPv4/IPv6 issue and deployment difficulties I'm also
worried about putting information in DHCP that is specific to a
single attachment point while DHCP is meant to help a host attach to
the network in numerous locations without location-specific
configuration.
Another good way to meet the DSL Forum's requirement would be to run
PANA over IPv6 link-local addresses. Assuming the presence of an IPv6
stack on both ends, this seems to be the least problematic way to do
all of this: you get to talk to the first layer 3 device upstream
without any layer 2 issues to worry about but address provisioning
hasn't happened yet so no difficulties there either. This wouldn't be
ethernet-specific but it would probably be advantageous to correlate
the MAC address that was used in the PANA exchange with the MAC
address in subsequent DHCP exchanges.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
