> October 11, 2007 @ 12:37: Iljitsch van Beijnum > > 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),
Yes, the DSLF liaison statements were driven by triple-play providers who need to change out their CPE anyway. Since there are 200M+ DSL lines in the world, this triple play market could eventually become large. > 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. Many DSL providers already use DHCP with Option 82 (added at the DSLAM) for location information. The EAP information transported from the client would be used incrementally for subscriber (or CPE) identity. (As an FYI for triple play, it is important that "trusted" customer specific CPEs can be identified.) > 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. What you describe is certainly possible. But to me it seems more complicated for failure mode debugging than the DHCP Auth proposals. (And remember, DSL providers already use DHCP & Option 82.) Eric _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
