#  -*- text -*-
#
#
#  $Id: d5e88c3c57c767f642207faa055082a481cd4e90 $

#######################################################################
#
#  # Local dictionary definitions
#
#  This is the local dictionary file which can be
#  edited by local administrators.  It will be loaded
#  *after* the main dictionary files are loaded.
#
#
#  NOTE: We recommend using local variables inside of "unlang"
#        sections instead of defining attributes in this file. See
#        the xref:reference:index.adoc[reference documentation]
#        for more information on
#        xref:unlang/local.adoc[local variables].
#
#
#  This file exists for two purposes:
#
#  1) defining local attributes in order to simplify the process
#     of migrating from version 3 to version 4.  We recommend
#     removing these attributes, and using local variables instead.
#
#  2) Including alias dictionaries in order to simplify the
#     process of migrating from version 3 to version 4.  We
#     recommend using the new names where possible.
#
#  ## Dictionary loading order
#
#  FreeRADIUS will automatically load the main dictionary files from:
#
#  	${prefix}/share/freeradius/dictionary
#
#  It is no longer necessary for this file to `$INCLUDE` the main
#  dictionaries from this file.  However, if the `$INCLUDE` line is
#  here, nothing bad will happen.

#
#  ## Dictionaries per Virtual Server
#
#  v4 also supports a `dictionary { ... }` subsection in a virtual
#  server.  If the attributes are used only in one virtual server,
#  they should be defined there.
#

#
#  ## Editing the dictionary
#
#  Any new/changed attributes *must* be placed in this file.
#  The pre-defined dictionaries *should not* be edited.
#  See `man dictionary` for documentation on how dictionary
#  entries should be formatted.
#
#  All local attributes and `$INCLUDE` directives should
#  go into this files.
#
#  The attribute definitions here should use `DEFINE`, not `ATTRIBUTE`.
#  The `DEFINE` keyword is exactly like `ATTRIBUTE`, except it does not
#  require an attribute number.
#
#  As a result, there is no need to manually manage numbers.
#
#  Any attribute `DEFINE`d here will not go into a packet.
#
#  If you do want attributes to go into a RADIUS packet, you
#  will need to use VSAs. This means requesting allocation
#  of a Private Enterprise Code from https://www.iana.org/. We
#  strongly suggest doing that *only* if you are a vendor of
#  RADIUS equipment.
#
#  See RFC 6158 for more details:
#    http://ietf.org/rfc/rfc6158.txt

#
#  ## Example attributes
#
#  The attributes below are examples. You should edit them as
#  required, or add your own.
#

#DEFINE	My-Local-String		string
#DEFINE	My-Local-IPAddr		ipaddr
#DEFINE	My-Local-Integer	integer

#
#  ## v3 Compatibility and Migration
#
#  By default, the server does NOT load the v3 names.  While this
#  behavior is done to simplify the server configuration, it can also
#  make migration more difficult.
#
#  If your system is using Vendor-Specific attributes from a
#  particular vendor, you can list those dictionaries below.  The
#  server will then load the version 3 names, which makes migration
#  much simpler.
#
#  For v4, all of the attributes have been renamed from v3.  This
#  change was necessary in order to support new functionality.  The
#  unfortunate side effect of this change is that all of the attribute
#  names used by v3 in the SQL, LDAP, and "files" module are
#  incompatible with v4.
#
#  The problem with v3 was that names were all in flat lists, so that
#  User-Name appeared in the same list as Cisco-AVPAir.  This
#  organization was simple enough to work for 25 years, but its time
#  has come.  The new names are hierarchical, which means they are
#  organized into a tree-like structure.
#
#  For v4, the Cisco-AVPair attribute is now called "AVPair".  It
#  lives inside of the "Cisco" namespace, which in turn lives inside
#  of the "Vendor-Specific" namespace.  So the new name for
#  `Cisco-AVPair` is `Vendor-Specific.Cisco.AVPair`.
#
#  These changes have been made for many hundreds of dictionary files,
#  and many thousands of Vendor-Specific attributes.
#
#  In the interest of compatibility, is possible to use the old names
#  with v4.  There are some limitations, but it will generally work.
#  The main reason for enabling the old names is to try out v4 with a
#  database that is also used by v3.  This lets you test that v4
#  works, without going through a complex process to upgrade
#  everything.
#
#  The old v3 names are in "v3" dictionaries, in the `${dictdir}`
#  directory.  To find out where this directory is on your local
#  system, run "radiusd -h" or "radclient -h".  Then look for the "-D"
#  command-line option, and it will tell you where the dictionary
#  files are located.
#
#  The v3 names are in `${dictdir}/radius/v3/VENDOR.txt` where
#  _VENDOR_ is the name taken from the v3 `dictionary.VENDOR`.
#
#  You will need to edit the text below to add a `$INCLUDE` line for
#  each vendor-specific dictionary which is used by your local system.
#  The default v4 dictionaries do not enable all of v3 compatibility
#  names.
#
#  We recognize that this process is a bit of work.  However, we
#  wish to encourage everyone using v4 to upgrade to using the new v4
#  features.  Our experience shows that if we automatically enable
#  "compatibility functions", then those compatibility functions will
#  be used for a decade.  So we need to find a balance between
#  upgrades and ongoing support.  Easy upgrades will mean complex
#  ongoing support.  Complex upgrades make ongoing support easier, but
#  also make it less likely that people will upgrade.
#
#  Note that if you over-write the "v3/dictionary.VENDOR" files with a
#  copy of the v3 dictionary, then it won't work.  Migrations across
#  major version numbers means that the configuration files are *not*
#  100% compatible. This includes the dictionaries!
#
#  The v3 compatibility names are in the RADIUS namespace.
#  There are no aliases for DHCPv4.
#
#BEGIN-PROTOCOL RADIUS
#$INCLUDE ${dictdir}/radius/v3/dictionary.cisco
#$INCLUDE ${dictdir}/radius/v3/dictionary.aruba
#END-PROTOCOL RADIUS

#
#  This dictionary includes v3-compatible names like "Cleartext-Password",
#  or "NT-Password".
#
#$INCLUDE ${dictdir}/freeradius/v3/dictionary.freeradius.internal
