mip6d.conf man page on RedHat

mip6d.conf man page on RedHat

Man page or keyword search:
man Server 29550 pages
apropos Keyword Search (all sections)
Output format

mip6d.conf(5) Mobile IPv6 and NEMO Daemon Configuration mip6d.conf(5)

NAME
mip6d.conf - UMIP Mobile IPv6 and NEMO Configuration file

SYNOPSIS
/etc/mip6d.conf

DESCRIPTION
UMIP Mobile IPv6 and NEMO daemon's configuration file

Below is a list of currently supported configuration options. All con‐
figuration lines are terminated with a semicolon. Sub-sections are
enclosed in '{' and '}'. Optional parameters are designated with
square brackets (you must omit them if you set the optional parameter).
Strings are quoted with double quotes.

Default value is given when available. Support for dynamic reload of
the option through SIGHUP is also indicated.

COMMON OPTIONS
The file contains the following common definitions:

include "<pattern>"

Includes content from other files based on provided pattern.
Usual shell wildcards are supported ('?', '*', '['). See man (7)
glob for details. The number of included files is virtually
unlimited but only five levels of recursion are authorized to
prevent loops. Note that if given pattern does not match any
file, a simple warning is issued but parsing continues. Unlike
most configuration statements, no ';' is expected after the pat‐
tern.

Example: include "/etc/mip6d.conf.d/*.conf"

NodeConfig CN | HA | MN;

Indicates if the daemon should run in Correspondent Node, Home
Agent or Mobile Node mode.

Default: CN

Dynamic reload: not supported. Daemon must be restarted.

DebugLevel number;

Indicates the debug level of the daemon. If the value is
greater than zero, the daemon will not detach from tty (i.e.
debug messages will be printed on the controlling tty).

Default: 0

Dynamic reload: partially supported. Cannot detach from tty
afterwards.

DebugLogFile "/path/to/log/file";

Indicates where debug logs should be stored.

Default: empty (output is redirected to stderr)

Dynamic reload: not supported. Daemon must be restarted.

DoRouteOptimizationCN boolean;

Indicates if a node should participate in route optimization
with a Mobile Node, i.e. if it should accept a binding proposed
by a peer. The value is used as the default binding policy
value, if no CnBindingPolicySet have been defined for the pro‐
posed binding.

Default: enabled

Dynamic reload: supported but does not affect existing bindings.

CnBindingPolicySet {
peer_hoa [ local_addr ] boolean;
...
}

The decision to accept a binding from a MN and participate in
route optimization with it is governed on a global basis by
DoRouteOptimizationCN parameter, i.e. which is used as the
default binding policy value.

The CnBindingPolicySet section can be used to define specific
binding policies for some given peers. In that context, each
line is dedicated to a MN. The address (HoA) of the MN is given
as first element of the line (i.e. peer_hoa ). The local
address local_addr at which the Binding Update messages are
expected to be received can be optionally specified as second
argument (If we are acting as a MN, this will be one of our
HoA). If it is not provided, the local address to which the BU
from that MN are sent is not taken into account. The last argu‐
ment boolean specifies if the node should perform route opti‐
mization with that peer.

Note that a MN must have at most a single entry defined in that
section i.e. having more than one line starting with the same
address is not allowed.

Default: by default, the set is empty and the default value pro‐
vided by DoRouteOptimizationCN configuration parameter applies
for all peers.

Dynamic reload: not supported.

NonVolatileBindingCache boolean;

This option is currently ignored. Binding cache is always
stored in volatile memory, and is not retained between shutdown
and startup.

OPTIONS COMMON TO HOME AGENT AND MOBILE NODE
These options are used both in the Home Agent and Mobile Node:

Interface name;

Interface name {
MnIfPreference number;
IfType CN | HA | MN;
Tunnel boolean;
}

Specifies an interface and options associated with it. If no
options are present, Interface can be terminated with semi-
colon. This is used for home agent to specify which interfaces
are used for HA operation. For the home agent to function prop‐
erly, a Router Advertisement daemon (e.g. radvd) must broadcast
advertisements with the Home Agent bit and Home Agent Informa‐
tion Option set on these interfaces. This option is also used
by multihomed Mobile Nodes to define which interfaces are used
by it. For MN and CN, it is posible to provide interfaces that
are not already available when the daemon is started. Those will
be used when available.

Dynamic reload: partially supported. Only new inet6 interfaces
will use the new configuration.

MnIfPreference sets the interface preference value for an inter‐
face in a multi-homed Mobile Node. The most preferred inter‐
faces have preference 1, the second most preferred have 2, etc.
Values between 0 and 10 are allowed. A preference of zero means
the interface will not be used.

The interface preference has a direct impact on the metric of
default routes configured by the daemon from RA information.
Note that if two interfaces with associated default routes have
the same preference value, the routes will end up having the
same metric, except if different default router preference (RFC
4191) values are provided in RA. In a sense, MnIfPreference
value value is the primary selector for interface and default
route selection and default router preference value provided in
RA can then be used to break a tie.

Default: 10

IfType overrides the default node behavior for this interface.
If a MN doesn't wish to use this interface for mobility, or a
node doesn't act as HA on this interface, the interface type
should be set to CN.

Default: same as NodeConfig

Tunnel

When enabled, this flag explicitly marks the interface as a tun‐
nel interface and modify the behavior of UMIP regarding the
router discovery, address configuration and route addition steps
for the interface. Those are expected to be done externally
(manually or by another automatic process (for instance when
using a Teredo interface). Note that the handling of routing
via the interface is still partly handled by UMIP but leaves
some latitude to the user or the automatic process that setup
the interface. UMIP looks for default routes in the main table
that use the interface as output device and replaces them by a
default route with a proper preference. If a gateway was present
for the route (there is one for 6to4, but none when miredo is
used), it is kept in the new route. Other routes that are
defined for the device (including other default routes in other
tables) are left untouched.

Limitations and details:

1) Tunnel interfaces are only allowed for MN and CN (not HA).

2) They are never considered as home link (i.e. you will never
be at home on a tunnel).

3) Unlike for physical interfaces, link detection is not reli‐
able for tunnel interfaces. If the tunnel interface state is
directly dependent of some physical interface link status, that
status must be monitored externally (i.e. not by UMIP) and
reflected by having either the interface being set down/up or
address being removed/added for UMIP to detect the change in
interface configuration.

4) An address must be configured on the interface for it to be
selected. If no adress is available, UMIP will simply not con‐
sider the interface at all (even if it provides a default
route).

5) Routes that include specific sources are not considered by
UMIP.

Example:

When using a teredo interface, the default route through the
teredo device is found and its preference changed. Link local
routes are kept unchanged. Address configuration is kept unmodi‐
fied.

When using a 6to4 tunnel interface, a default route through the
6to4 device exists. It uses the 6to4 relay address
(::192.88.99.1 anycast address or another specific one) as gate‐
way. UMIP finds this default route and install a new default one
with the same gateway but an updated metric.

Default: disabled

UseMnHaIPsec boolean;

Indicates if the MN-HA MIPv6 signalling should be protected with
IPsec.

Default: enabled

Dynamic reload: not supported.

KeyMngMobCapability boolean;

If dynamic keying with MIPv6-aware IKE is used, this options
should be enabled. It turns on the K-bit for binding updates
and binding acknowledgements.

Default: disabled

Dynamic reload: supported.

IPsecPolicySet {
HomeAgentAddress address;
HomeAddress address/length;
IPsecPolicy ...
...
}

IPsecPolicySet is a set of policies to apply for matching pack‐
ets. A policy set can contain multiple HomeAddress options, but
only one HomeAgentAddress option. For home agent, home agent
address field contains its own address, and home address fields
may contain any number of mobile nodes for which the same policy
applies.

Dynamic reload: supported. The sets can be changed, added or
removed. Removing rules for established bindings may have
unpredicted effects.

IPsecPolicy has the following format:

IPsecPolicy type UseESP number number;

Field type can be one of HomeRegBinding (for protecting BU/BH),
Mh (for protecting all MH packets: BU, BA, BE), MobPfxDisc (for
protecting MPS/MPA), ICMP (for protecting all ICMP packets,
including MPS/MPA), any (for protecting all transport mode com‐
munication), TunnelHomeTesting (for protecting the HoTI/HoT mes‐
sages), TunnelMh (for protecting all tunneled MH packets,
including HoTI/HoT), or TunnelPayload (for protecting all tun‐
neled packets including tunneled MH packets).

Currently only the ESP IPsec protocol is supported, but in the
future AH and IPComp might also be available. The two remaining
numeric fields are the IPsec reqid values, the first one used
for MN - HA, the second one for HA - MN communication. If just
one value is defined, the same reqid will be used in both direc‐
tions. If no reqid is given, reqid will not be used.

If more that one IPsec transport mode or tunnel mode policy is
defined between the MN and HA in each direction, reqid can be
used to provide an unambiguous one-to-one mapping between IPsec
policies and SAs. Otherwise the policies will just share a com‐
mon SA.

HOME AGENT SPECIFIC OPTIONS
The following definitions are ignored unless the node is configured as
a HA:

HaMaxBindingLife number;

Limits the maximum lifetime (in seconds) for Mobile Node home
registrations.

Default: 262140

Dynamic reload: partially supported. Only affects new bindings.

SendMobPfxAdvs boolean;

Controls whether home agent sends Mobile Prefix Advertisements
to mobile nodes in foreign networks.

Default: enabled

Dynamic reload: partially supported. Only affects new bindings.

SendUnsolMobPfxAdvs boolean;

Controls whether home agent send unsolicited Mobile Prefix
Advertisements to mobile nodes in foreign networks.

Default: enabled

Dynamic reload: partially supported. Only affects new bindings.

MinMobPfxAdvInterval number;

Sets a minimum interval (in seconds) for Mobile Prefix Adver‐
tisements.

Default: 600

Dynamic reload: partially supported. Only affects new scheduled
MPA.

MaxMobPfxAdvInterval number;

Sets a maximum interval (in seconds) for Mobile Prefix Adver‐
tisements.

Default: 86400

Dynamic reload: Partially supported. Only affects new scheduled
MPA.

HaAcceptMobRtr enabled | disabled;

Indicates if the HA accepts Mobile Router bindings.

Default: disabled

Dynamic reload: supported.

HaServedPrefix prefix/length;

Prefix is an IPv6 prefix and length is the prefix length.
Defines the whole aggregated or extended prefix the HA serves.
This option is only used for MR bindings and is only needed if
the MRs derive their Home Addresses from their Mobile Network
Prefixes, instead of one of the home link prefixes.

Dynamic reload: supported.

BindingAclPolicy address [ MNP-list ] allow | deny;

Defines if a MN is allowed to register with the HA or not. The
home address of the MN is given in the address field. The
mobile network prefixes belonging a NEMO Mobile Router are
optionally listed in MNP-list for example: (3ffe:2620:6:3::/64,
3ffe:2620:6:4::/64)

Dynamic reload: partially supported. Does not affect existing
bindings until they expire.

DefaultBindingAclPolicy allow | deny;

Defines the default policy if no matching BindingAclPolicy entry
is found for a MN.

Default: allow

Dynamic reload: partially supported. Only affects new bindings.

MOBILE NODE SPECIFIC OPTIONS
The following definitions are ignored unless the node is configured as
a MN:

MnMaxHaBindingLife number;

Limits the maximum lifetime (in seconds) for Mobile Node home
registrations.

Default: 262140

Dynamic reload: partially supported. Only affects new bindings.

MnMaxCnBindingLife number;

Limits the maximum lifetime (in seconds) for Mobile Node Corre‐
spondent Node registrations.

Default: 420

Dynamic reload: partially supported. Only affects new bindings.

MnDiscardHaParamProb boolean;

Toggles if the Mobile Node should discard ICMPv6 Parameter Prob‐
lem messages from its Home Agent. As the ICMPv6 error messages
won't normally be protected by IPsec, a malicious third party
can quite easily impersonate the HA to the MN. Having the MN
accept these messages therefore leaves it open to Denial of Ser‐
vice attacks, even though its home registration signalling is
protected by IPsec.

Default: disabled

Dynamic reload: supported.

MnResetDhaadAtHome boolean;

If the MN uses DHAAD, then enabling this option will force UMIP
to set the Home Agent Address to the unspecified address every
time the MN returns home. As a consequence, the MN will run
DHAAD every time it moves from home to a foreign network. If
disabled, the HA address obtained from the very first DHAAD
exchange will be remembered even if the MN returns home.

Default: disabled

Dynamic reload: supported.

MnFlushAllAtHome boolean;

Enabling this option allows the MN to flush all uncertain regis‐
trations upon returning home, instead of keeping trying to com‐
plete them from home until the retry counters expire. Also, this
option forces the returning home procedure for valid registra‐
tions in the case the HA does not reply to DAD probe when
returning home.

Default: disabled

Dynamic reload: supported.

MnMaxCnConsecutiveResends number;

By default, if the MN does not receives a BA from a CN, it
resends the BU indefinitely. Setting this option to 1 or more
allows to stop trying after the specified number. 1 resend is
the minimum, as 0 is a reserved value to indicate that resend
should be performed indefinitely.

Default: 0 (resend indefinitely)

Dynamic reload: supported.

MnMaxHaConsecutiveResends number;

By default, if the MN learnt the HA address through DHAAD and
did not receive a BA from a HA after 5 retries, it invalidates
the HA and tries to switch to another HA. This option allows to
tune the number of retry before switching. Note that if DHAAD is
not used, this option has no effect, and the MN retries sending
the BU indefinitely.

Default: 5

Dynamic reload: supported.

SendMobPfxSols boolean;

Controls whether mobile node sends Mobile Prefix Solicitations
to the home network.

Default: enabled

Dynamic reload: supported.

DoRouteOptimizationMN boolean;

Indicates if the Mobile Node should initialize route optimiza‐
tion with Correspondent Nodes.

Default: enabled

Dynamic reload: partially supported, disabling is not supported.

MnUseAllInterfaces enabled | disabled;

Indicates if all interfaces should be used for mobility. The
preference of these interfaces is always 1. Unless you use
dynamically created and named network interfaces you should nor‐
mally disable this option and use Interface options to explic‐
itly list the used interfaces.

Default: disabled

Dynamic reload: same support as "Interface" directive.

MobRtrUseExplicitMode enabled | disabled;

Toggles between explicit or implicit mode home registrations in
the MR.

Default: enabled

Dynamic reload: supported.

UseCnBuAck boolean;

Indicates if the Acknowledge bit should be set in Binding
Updates sent to Correspondent Nodes.

Default: disabled

Dynamic reload: supported.

InterfaceInitialInitDelay decimal;

Defines the delay (in seconds) for initial interface configura‐
tion at startup before any movement decision occurs.

At startup, UMIP gathers information on interfaces available on
the system. Then, for interfaces listed in the configuration,
it either learn CoA (for those marked as Tunnel) or send RS to
receive RA (asynchronously) and then configured CoA.

At startup, if the MN has multiple interfaces, UMIP may first
select a CoA on a given interface and then change its mind and
switch to another CoA. This may result in the emission of multi‐
ple useless BU. Additionally, when Dynamic Keying (IKE) is used
for negotiating protection of traffic, a CoA change occurring
during the initial negotiation only leads to additional delays.

By introducing an initial default delay at startup, that side
effect is avoided. If your MN is configured to use only a single
interface, or do not use IKE and startup delay matters, you may
set the parameter to 0.

Default: 2.0

Dynamic reload: not supported (only valid at daemon startup).

MnRouterProbes number;

Indicates how many times the MN should send Neighbor Unreacha‐
bility Detection (NUD) probes to its old router after receiving
a Router Advertisement (RA) from a new one. If the option is set
to zero or the new router advertises a strictly higher default
preference value than the old one (as defined in RFC 4191), the
MN will move to the new router straight away.

Default: 0

Dynamic reload: supported.

MnRouterProbeTimeout decimal;

Indicates how long (in seconds) the MN should wait for a reply
during a access router Neighbor Unreachability Detection probe.
If set, it overrides any default Neighbor Solicitation Retrans‐
mit Timer value greater than MnRouterProbeTimeout. For example,
if the interface Retransmit Timer is 1 second, but MnRouterPro‐
beTimeout is just 0.2 seconds, the MN will only wait 0.2 seconds
for a Neighbor Advertisement before proceeding with the handoff.

Default: 0.0

Dynamic reload: supported.

InitialBindackTimeoutFirstReg decimal;

Upon the first registration attempt, indicates how long (in sec‐
onds) the MN should wait before re-sending the Binding Update
when no Binding Ack has been received. For subsequent registra‐
tions, you may set the InitialBindackTimeoutReReg option.

Default: 1.5

Dynamic reload: partially supported. Only affects new bindings.

InitialBindackTimeoutReReg decimal;

Indicates how long (in seconds) the MN should wait before re-
sending the Binding Update when no Binding Ack has been
received. For the first registration attempt, you may set the
InitialBindackTimeoutFirstReg option.

Default: 1.0

Dynamic reload: partially supported. Does not affect existing
bindings until they expire.

InitialSolicitTimer decimal;

Indicates how long (in seconds) the MN should wait before re-
sending the initial Mobile Prefix Solitication message when no
answers have been received. Option SendMobPfxSols must be
enabled.

Default: 3.0

Dynamic reload: not supported.

OptimisticHandoff enabled | disabled;

When a Mobile Node sends a Binding Update to the Home Agent, no
Route Optimized or reverse tunneled traffic is sent until a
Binding Acknowledgement is received. When enabled, this option
allows the Mobile Node to assume that the binding was successful
right after the BU has been sent, and does not wait for a posi‐
tive acknowledgement before using RO or reverse tunneling.

Default: disabled

Dynamic reload: supported.

NoHomeReturn enabled | disabled;

When a MN returns Home, it usually deregisters its binding.
Additionally, when IPsec is in use to protect data traffic, a MN
also deinstall the IPsec Security Policies protecting data traf‐
fic. One problem with that expected behavior is that an insecure
trigger (Home Link Detection mechanism, based on prefix
announced in RA messages) is used for the removal of IPsec Secu‐
rity Policies for data traffic.

The NoHomeReturn option can be used to change that behavior.
When enabled, the MN will never consider itself at home. That
way, if IPsec is used to protect data traffic, associated Secu‐
rity Policies will never be removed.

Note that for the option to work when the MN really returns home
(i.e. on the subnet where the Home Agent is defending MN's HoA),
the two following conditions must be met:

1) The HoA of the MN must be different from the CoA the MN will
automatically configure itself on its interface that connects to
its home network,

2) The interface that connects to the home subnet must not be
the MnHomeLink interface (because the MN configures its HoA on
that interface, which will in turn make DAD fail on the HA for
the HoA).

Default: disabled

Dynamic reload: supported (for the next home return).

MnHomeLink name {
HomeAddress address/length [ MNP-list ];
HomeAgentAddress address;
MnRoPolicy ...
...
}

Each MnHomeLink definition has a name. This is the name
(enclosed in double quotes) of the interface used for connecting
to the physical home link. To set up multiple Home Addresses on
the Mobile Node, you need to define multiple MnHomeLink struc‐
tures. The interface names don't have to be unique in these
definitions.

Dynamic reload: not supported. The daemon has to be restarted
for the changes in this directive to take effect.

All the home link specific definitions are detailed below:

HomeAddress address/length [ MNP-list ];

Address is an IPv6 address, and length the prefix length of the
address, usually 64. The MNP-list contains the mobile network
prefixes belonging to that particular NEMO Mobile Router. The
MNP-list is optional and is of the same format as in BindingA‐
clPolicy. This option must be included in a home link defini‐
tion.

HomeAgentAddress address;

Address is the IPv6 address of the Mobile Node's Home Agent.
DHAAD is used if it is the unspecified address ::.

Default: ::

IsMobRtr enabled | disabled;

Defines if the MN is a NEMO MR.

Default: disabled

The route optimization policies are of the form:

MnRoPolicy address boolean;

Any number of these policies may be defined. If no policies are
defined default behavior depends on the DoRouteOptimizationMN
option.

The fields for a route optimization policy entry are as follows:
address defines the Correspondent Node this policy applies to,
if left undefined the uspecified address is used as a wildcard
value boolean sets route optimization either enabled or disabled
for packets matching this entry.

EXAMPLES
A NEMO Home Agent example (without IPsec):

NodeConfig HA;

Interface "eth0";

HaAcceptMobRtr enabled;

HaServedPrefix 3ffe:2620:6::/48;

DefaultBindingAclPolicy deny;
BindingAclPolicy 3ffe:2620:6:1::1234 (3ffe:2620:6:2::/64, 3ffe:2620:6:3::/64) allow;
BindingAclPolicy 3ffe:2620:6:1::1235 allow;

UseMnHaIPsec disabled;

A NEMO Mobile Router example (without IPsec):

NodeConfig MN;

DoRouteOptimizationCN disabled;
DoRouteOptimizationMN disabled;

Interface "eth0";

MnRouterProbes 1;

MobRtrUseExplicitMode enabled;

MnHomeLink "eth0" {
IsMobRtr enabled;
HomeAgentAddress 3ffe:2620:6:1::1;
HomeAddress 3ffe:2620:6:1::1234/64 (3ffe:2620:6:2::/64, 3ffe:2620:6:3::/64);
}

UseMnHaIPsec disabled;

A Correspondent Node example (without IPsec):

NodeConfig CN;

DoRouteOptimizationCN enabled;

A Home Agent example (with IPsec static keying):

NodeConfig HA;

Interface "eth0";

BindingAclPolicy 3ffe:2620:6:1::1234 allow;

UseMnHaIPsec enabled;

IPsecPolicySet {
HomeAgentAddress 3ffe:2620:6:1::1;
HomeAddress 3ffe:2620:6:1::1234/64;

# All MH packets (BU/BA/BERR)
IPsecPolicy Mh UseESP 111 112;
# All tunneled packets (HoTI/HoT, payload)
IPsecPolicy TunnelPayload UseESP 113 114;
# All ICMP packets (MPS/MPA, ICMPv6)
IPsecPolicy ICMP UseESP 115 116;
}

A Mobile Node example (with IPsec static keying):

NodeConfig MN;

DoRouteOptimizationCN enabled;
# DoRouteOptimizationMN cannot be used
# with TunnelPayload IPsecPolicy
DoRouteOptimizationMN disabled;

UseCnBuAck enabled;

MnHomeLink "eth0" {
HomeAgentAddress 3ffe:2620:6:1::1;
HomeAddress 3ffe:2620:6:1::1234/64;

# address opt.
#MnRoPolicy 3ffe:2060:6:1::3 enabled;
#MnRoPolicy disabled;
}

UseMnHaIPsec enabled;

IPsecPolicySet {
HomeAgentAddress 3ffe:2620:6:1::1;
HomeAddress 3ffe:2620:6:1::1234/64;