Ralph Droms and Wing Cheong Lau Nov 9, 2004
description
Transcript of Ralph Droms and Wing Cheong Lau Nov 9, 2004
Page 1Nov 9, 2004
DHCPv6 Relay Agent Information Optionand RADIUS Attributes Sub-optiondraft-droms-dhc-v6-relayopt-00.txt
Ralph Droms and Wing Cheong LauNov 9, 2004
Page 2Nov 9, 2004
Objective
• To provide an option for DHCPv6 Relay Agents to insert Information when forwarding client-originated message to a DHCPv6 server so that:– DHCPv6 servers recognizing the Relay Agent Information
option MAY use the information as a HINT to implement IP address or other parameter assignment policies.
• In particular, we are interested in the scenario where – the DHCPv6 Relay Agent is also a NAS and– the Relayed Information contains RADIUS Attributes obtained
by the NAS from the AAA server during the L2 access authentication process.
Page 3Nov 9, 2004
Operations of DHCPv6 Relay Agent Info Option and RADIUS Attributes sub-option
Network Device
NAS / DHCPv6 Relay
Agent
Home AAA Server(HAAA)
Request for L2 Access
DHCPv6 request
DHCPv6 reply
RADIUS Access-Request
RADIUS Access-Accept carrying RADIUS Attributes
L2 Access Accept
NAS stores RADIUS Attributes for the Network Device locally
DHCPv6Server
NAS strips away RRAO
DHCPv6 Relay Agent inserts RADIUS Attributes as the proposed options (RRAO)
while forwarding the request
Relayed DHCPv6 request with RRAO included
Make DHCPv6 assignment using RRAO as Hints
DHCPv6 reply ; also echos RRAO
• The relayed information is inserted (echoed) as an option in the Relay-Forward (Relay-Reply) Message, in the same manner as the insertion of the existing DHCPv6 Interface Option in RFC3315
• DHCPv6 client is unaware of the Option
=> Does not interfere with the current authentication model between the DHCPv6 client and server
Page 4Nov 9, 2004
Related Work
• Similar Relay Agent Information Option, RADIUS Attributes Sub-option and other sub-options already exist for DHCPv4 in Cable Modem/ DSL, as well as 802.1X applications:– RFC 3046 and – draft-dhc-agentopt-radius-08.txt (approved by IESG to
become a proposed standard in Sept 04). » It also identifies the list of “safe” RADIUS Attributes to be
relayed (to avoid interactions of RADIUS/DHCP state machines):• User-Name (RFC 2865)• Service-Type (RFC 2865)• Vendor-Specific (RFC 2865)• Session-Timeout (RFC 2865)• Framed-Pool (RFC 2869)• Framed-IPv6-Pool (RFC 3162)
– draft-ietf-dhc-vendor-suboption-00.txt
Page 5Nov 9, 2004
Some Feedbacks from dhc Mailing List
• Instead of a 2-level hierarchy of DHCP Relay Information Relay Option/ RADIUS Attributes sub-option, why not just using a single option to relay RADIUS-Attributes– Our original intent was to introduce general “relay” capability for
DHCPv6 relay agents, e.g. for other future sub-options such as the Vendor-Specific Information Option BUT it was pointed out in the Mailing list that » The Vendor-Specific Information Option in RFC3315 was also
intended to be used by the Relay Agent although the current text in RFC 3315 does not describe such usage
– Unlike DHCPv4, there is enough code-points for DHCPv6 option field
– Single-level option would allow 16-bit RRAO length => remove practical restriction on length of RADIUS Attributes to be relayed
To change to a single-level Relayed RADIUS Attributes Option (RRAO) in the next revision.
Page 6Nov 9, 2004
Some Feedbacks from dhc Mailing List (cont’d)
• Concern of cross-domain RADIUS operations where Home AAA server and DHCP relay-agent/server belong to different administrative domains
Current applicability statement already clearly states that the proposed mechanism would not provide robust operations across arbitrary RADIUS domains.
However, the proposed approach can be used to support roaming applications across Service Providers who – (1) Have Pre-established Roaming agreements and – (2) Are willing to accept the Risks, Limitations and Required
Coordinations/ Precautions of supporting cross-domain RADIUS service, e.g. as discussed in RFC 2607.
Page 7Nov 9, 2004
Next Steps
• To be accepted as a WG working Item ?