DHCPv6 Relay Agent Information Option and RADIUS Attributes Sub-option draft-droms-dhc-v6-relayopt-00.txt

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

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.

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
• gt Does not interfere with the current
  authentication model between the DHCPv6 client
  and server

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

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

6
Some Feedbacks from dhc Mailing List (contd)

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

7
Next Steps

• To be accepted as a WG working Item ?