Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 504
    • Issues 504
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 53
    • Merge requests 53
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #72
Closed
Open
Created Aug 27, 2018 by Ghost User@ghost

Radius option definitions

The RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to the server.

Kea should be able to understand such options. See RFC4014 (v4) and RFC7037 (v6) for details. Kea should be able to represent radius attributes as sub-options, so general mechanisms, like client classification could be used.

This ticket calls for option definitions only. No special handling logic should be implemented.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking