2. EL 6 ELS
  3. mipv6-daemon
  4. mip6d.conf(5)

Scroll to navigation

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 configuration 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:

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

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

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.

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.

Indicates where debug logs should be stored.

Default: empty (output is redirected to stderr)

Dynamic reload: not supported. Daemon must be restarted.

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 proposed 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 argument boolean specifies if the node should perform route optimization 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 provided by DoRouteOptimizationCN configuration parameter applies for all peers.

Dynamic reload: not supported.

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

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 properly, a Router Advertisement daemon (e.g. radvd) must broadcast advertisements with the Home Agent bit and Home Agent Information 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 interface in a multi-homed Mobile Node. The most preferred interfaces 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 tunnel 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 reliable 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 consider 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 unmodified.

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 gateway. UMIP finds this default route and install a new default one with the same gateway but an updated metric.

Default: disabled

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

Default: enabled

Dynamic reload: not supported.

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 packets. 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:

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 communication), TunnelHomeTesting (for protecting the HoTI/HoT messages), TunnelMh (for protecting all tunneled MH packets, including HoTI/HoT), or TunnelPayload (for protecting all tunneled 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 directions. 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 common SA.

HOME AGENT SPECIFIC OPTIONS

The following definitions are ignored unless the node is configured as a HA:

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

Default: 262140

Dynamic reload: partially supported. Only affects new bindings.

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

Default: enabled

Dynamic reload: partially supported. Only affects new bindings.

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.

Sets a minimum interval (in seconds) for Mobile Prefix Advertisements.

Default: 600

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

Sets a maximum interval (in seconds) for Mobile Prefix Advertisements.

Default: 86400

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

Indicates if the HA accepts Mobile Router bindings.

Default: disabled

Dynamic reload: supported.

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.

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.

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:

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

Default: 262140

Dynamic reload: partially supported. Only affects new bindings.

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

Default: 420

Dynamic reload: partially supported. Only affects new bindings.

Toggles if the Mobile Node should discard ICMPv6 Parameter Problem 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 Service attacks, even though its home registration signalling is protected by IPsec.

Default: disabled

Dynamic reload: supported.

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.

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

Default: disabled

Dynamic reload: supported.

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.

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.

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

Default: enabled

Dynamic reload: supported.

Indicates if the Mobile Node should initialize route optimization with Correspondent Nodes.

Default: enabled

Dynamic reload: partially supported, disabling is not supported.

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 normally disable this option and use Interface options to explicitly list the used interfaces.

Default: disabled

Dynamic reload: same support as "Interface" directive.

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

Default: enabled

Dynamic reload: supported.

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

Default: disabled

Dynamic reload: supported.

Defines the delay (in seconds) for initial interface configuration 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 multiple 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).

Indicates how many times the MN should send Neighbor Unreachability 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.

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 Retransmit Timer value greater than MnRouterProbeTimeout. For example, if the interface Retransmit Timer is 1 second, but MnRouterProbeTimeout 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.

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

Default: 1.5

Dynamic reload: partially supported. Only affects new bindings.

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.

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.

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 positive acknowledgement before using RO or reverse tunneling.

Default: disabled

Dynamic reload: supported.

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 traffic. 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 Security 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 Security 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 structures. 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:

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 BindingAclPolicy. This option must be included in a home link definition.

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

Default: ::

Defines if the MN is a NEMO MR.

Default: disabled

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

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;

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;

NodeConfig CN;
DoRouteOptimizationCN enabled;

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;
}

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;


        # 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;
}

SEE ALSO

mip6d(1), mipv6(7),

RFC6275: Mobility Support in IPv6

RFC3776: Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents

RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture

RFC3963: Network Mobility (NEMO) Basic Support Protocol

January 31, 2006