



We recommend using local variables inside of "unlang" sections
instead of defining attributes in this fine.  See the reference documentation
for more information on 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.


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

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 shuld 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 http://iana.org/. We
strongly suggest doing that *only* if you are a vendor of
RADIUS equipment.

See https://tools.ietf.org/html/rfc6158[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.




## v3 Compatible names.

All of the attributes have been renamed from v3.  This change was
necessary in order to support new funtionality in v4.  The
unfortunate side effect of this change is that all of the names in
SQL, LDAP, and the "files" module are incompatible with v4.

We recognize that is is difficult to change every entry in a
database, especially when there's no clear mapping between the
"old" and "new" names.  This renaming is made more complex because
the "new" names need to be grouped and arranged in ways that the
old ones were not.

The "old" names were all in flat lists, so that User-Name appeared
next to Cisco-AVPAir.  This organization was simple enough to work
for 20 years, but its time has come.  The new names are
hierarchical, so that the organization is nested by definition.

For v4, the Cisco-AVPair attribute is called "AVPair", and 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.

This process continues for many thousands of vendor-specific
attributes.

Happily, it is possible to (mostly) use the old names with v4.
There are limitations, but it will mostly 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 "upgrade everything" process.

The old v3 names are in "alias" 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/alias/VENDOR.txt` where
_VENDOR_ is the name of the vendor, which is taken from the `VENDOR`
definition in the v3 dictionaries.

You will need to add a `$INCLUD`E 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.

Yes, 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 compatiblity 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.


All of the v3 compatibility names are in the RADIUS namespace.



== Default Configuration

```
#DEFINE	My-Local-String		string
#DEFINE	My-Local-IPAddr		ipaddr
#DEFINE	My-Local-Integer	integer
#BEGIN-PROTOCOL RADIUS
#$INCLUDE ${dictdir}/radius/alias/cisco.txt
#END-PROTOCOL RADIUS
```
