#  -*- text -*-
#
#
#  $Id: b41e25afc856b6540c82b6baa33a75197865188f $

#######################################################################
#
#  = 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

#
#  Any local dictionaries can be added in the `dictionary.d`
#  subdirectory.
#
#  The server will load all files in that directory, but will skip
#  editor backup files, and others which are known to not be real
#  files.
#
$INCLUDE- dictionary.d/
