Yes, updating equipment on the client side is Hard. That's chiefly why
the dominant mechanism today relies on option 82 where you can do
subscriber line authentication in DHCP, without touching the Client. The
Client-side authentication in DHCP is only for the cases where option 82
isn't workable, and in these cases it is a foregone conclusion that some
update must be done on the client-side software. Note that the dominant
*short-term* interest seems to be from ISPs where the client in question
is a box that they provide to the customer for which they have a lot of
control over the code within, while the transit switches and BNG come
from (a variety of) vendors.
- Mark
Iljitsch van Beijnum wrote:
On 12-okt-2007, at 14:23, Eric Voit (evoit) wrote:
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.
Yes, I can see how a DHCP solution is attractive from this perspective.
(As an FYI for triple play, it is important that "trusted" customer
specific CPEs can be identified.)
Are we then talking about a protocol that is only exchanged between an
ISP-supplied CPE and the DSLAM? In that case they can use any protocol
that they want because there is no interaction with the end-user or
any equipment that's not under the control of the ISP. However, from
the list of requirements it seems that the DSL Forum is looking for
something that goes from the end-user PC to the DSLAM or from a third
party gateway installed and operated by the end-user to the DSLAM so
the protocol needs to make sense both on commercially available home
gateways and on regular multi-purpose operating systems.
Another good way to meet the DSL Forum's requirement would be
to run PANA over IPv6 link-local addresses.
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.)
So how would a DHCP solution work when the user connects:
- a Windows XP or MacOS X machine but Microsoft/Apple won't be
including the new DHCP option for another 12 months
- a Windows 98 machine that is no longer getting updates from Microsoft
- a no brand home gateway which can't be upgraded by the user
- a machine that runs DHCP for IPv4 and DHCPv6 for IPv6
- a machine that runs DHCP for IPv6 and runs IPv6 but not DHCPv6
- a machine that doesn't run IPv4 but IPv6 + DHCPv6
- a machine that doesn't run IPv4 but IPv6 without DHCPv6
_______________________________________________
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
