1 / 7

Ralph Droms and Wing Cheong Lau Nov 9, 2004

DHCPv6 Relay Agent Information Option and RADIUS Attributes Sub-option draft-droms-dhc-v6-relayopt-00.txt. Ralph Droms and Wing Cheong Lau Nov 9, 2004. Objective.

oya
Download Presentation

Ralph Droms and Wing Cheong Lau Nov 9, 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DHCPv6 Relay Agent Information Optionand RADIUS Attributes Sub-optiondraft-droms-dhc-v6-relayopt-00.txt Ralph Droms and Wing Cheong Lau Nov 9, 2004 Page 1

  2. 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 2

  3. Operations of DHCPv6 Relay Agent Info Option and RADIUS Attributes sub-option • 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 3

  4. 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 4

  5. 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 5

  6. 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 6

  7. Next Steps • To be accepted as a WG working Item ? Page 7

More Related