mip6d.conf(5)

📦 version 2.0.2.umip.0.4, in opensuse-leap 16.0

🎀 NAME 🎀

Okay bestie, welcome to mip6d.conf(5) — the Mobile IPv6 and NEMO Daemon Configuration page — aka the MIPL Mobile IPv6 and NEMO Configuration file. It's literally the config file for the MIPL Mobile IPv6 and NEMO daemon, and we're gonna go through every option together, no skipped lore. 🫶

✨ SYNOPSIS ✨

/etc/mip6d.conf

💖 DESCRIPTION 💖

This is the MIPL Mobile IPv6 and NEMO daemon's configuration file. Main character energy, honestly.

Below is a list of currently supported configuration options. All configuration lines are terminated with a semicolon. Sub-sections are enclosed in { and }. Strings are quoted with double quotes. periodt. 💅

💅 COMMON OPTIONS 💅

The file contains the following common definitions:

include "<pattern>" — Includes content from other files based on the 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 the 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. iykyk.

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. Choose your fighter.

Default: CN

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). tty bestie era.

Default: 0

DoRouteOptimizationCN boolean; — Indicates if a node should participate in route optimization with a Mobile Node.

Default: enabled

NonVolatileBindingCache boolean; — This option is currently ignored. Binding cache is always stored in volatile memory, and is not retained between shutdown and startup. Not me thinking this would persist things 😭

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

Interface — Specifies an interface and options associated with it. If no options are present, Interface can be terminated with semi-colon. This is used for the 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 possible to provide interfaces that are not already available when the daemon is started. Those will be used when available. slay, flexible queen.
- MnIfPreference number; — 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 is the primary selector for interface and default route selection, and the default router preference value provided in RA can then be used to break a tie.

Default: 10

IfType CN | HA | MN; — 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 boolean; — When enabled, this flag explicitly marks the interface as a tunnel interface and modifies 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 set up 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.

Default: disabled

Limitations and details:

Tunnel interfaces are only allowed for MN and CN (not HA).
They are never considered as home link (i.e. you will never be at home on a tunnel).
Unlike for physical interfaces, link detection is not reliable for tunnel interfaces. If the tunnel interface state is directly dependent on 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.
An address must be configured on the interface for it to be selected. If no address is available, UMIP will simply not consider the interface at all (even if it provides a default route).
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 installs a new default one with the same gateway but an updated metric.

UseMnHaIPsec boolean; — Indicates if the MN-HA MIPv6 signalling should be protected with IPsec.

Default: enabled

KeyMngMobCapability boolean; — If dynamic keying with MIPv6-aware IKE is used, this option should be enabled. It turns on the K-bit for binding updates and binding acknowledgements. <butterfly>key management wig.</butterfly>

Default: disabled

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

IPsecPolicySet — 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, the 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. policy queen behavior.

IPsecPolicy type UseESPnumber number;

IPsecPolicy type UseESPnumber number; — Field type can be one of HomeRegBinding, Mh, MobPfxDisc, ICMP, any, TunnelMh, TunnelHomeTesting, or TunnelPayload. The any option protects all transport mode communication between the MN and HA. 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 than 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. no cap, that mapping matters.

👑 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

SendMobPfxAdvs boolean; — Controls whether the home agent sends Mobile Prefix Advertisements to mobile nodes in foreign networks.
SendUnsolMobPfxAdvs boolean; — Controls whether the home agent sends unsolicited Mobile Prefix Advertisements to mobile nodes in foreign networks.
MinMobPfxAdvInterval number; — Sets a minimum interval (in seconds) for Mobile Prefix Advertisements.

Default: 600

MaxMobPfxAdvInterval number; — Sets a maximum interval (in seconds) for Mobile Prefix Advertisements.

Default: 86400

HaAcceptMobRtr enabled | disabled; — Indicates if the HA accepts Mobile Router bindings.

Default: disabled;

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.
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 to a NEMO Mobile Router are listed in the MNP-list. The list can either be an empty string or a comma separated list of network prefixes enclosed in braces, for example: (3ffe:2620:6:3::/64, 3ffe:2620:6:4::/64) ACL glamour.
DefaultBindingAclPolicy allow | deny; — Defines the default policy if no matching BindingAclPolicy entry is found for a MN.

Default: allow

💅 MOBILE NODE SPECIFIC OPTIONS 💅

Okay bestie, heads up: these definitions are ignored unless the node is configured as a MN. So if your node is not in Mobile Node mode, this whole section is basically behind a velvet rope. 🫶

MnMaxHaBindingLife number; — Limits the maximum lifetime (in seconds) for Mobile Node home registrations. Default: 262140
MnMaxCnBindingLife number; — Limits the maximum lifetime (in seconds) for Mobile Node Correspondent Node registrations. Default: 420
MnDiscardHaParamProb boolean; — 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
SendMobPfxSols boolean; — Controls whether mobile node sends Mobile Prefix Solicitations to the home network.
DoRouteOptimizationMN boolean; — Indicates if the Mobile Node should initialize route optimization with Correspondent Nodes. Default: enabled
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 normally disable this option and use Interface options to explicitly list the used interfaces. Default: disabled
MobRtrUseExplicitMode enabled | disabled; — Toggles between explicit or implicit mode home registrations in the MR. Default: enabled
UseCnBuAck boolean; — Indicates if the Acknowledge bit should be set in Binding Updates sent to Correspondent Nodes. Default: disabled
MnRouterProbes number; — 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
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 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
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 positive acknowledgement before using RO or reverse tunneling. Default: disabled
MnHomeLink name { ... } — 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. All the home link specific definitions are detailed below:

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

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 of the same format as in BindingAclPolicy. This option must be included in a home link definition.
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;

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

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:

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:

NodeConfig CN;

DoRouteOptimizationCN enabled;

A Home Agent example:

NodeConfig HA;

Interface "eth0";
Interface "eth1";

UseMnHaIPsec enabled;

IPsecPolicySet {
        HomeAgentAddress 3ffe:2620:6:1::1;

        HomeAddress 3ffe:2620:6:1::1234/64;
        HomeAddress 3ffe:2620:6:1::1235/64;

        IPsecPolicy HomeRegBinding UseESP;
        IPsecPolicy TunnelMh UseESP;
}

A Mobile Node example:

NodeConfig MN;

DoRouteOptimizationCN enabled;

DoRouteOptimizationMN enabled;

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;

        IPsecPolicy HomeRegBinding UseESP;
        IPsecPolicy TunnelMh UseESP;
}

🦋 SEE ALSO 🦋

mip6d(1)
mipv6(7)
RFC3775: Mobility Support in IPv6
RFC3776: Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents

And that's the whole vibe, bestie: this is the mip6d.conf(5) manual page, dated January 31, 2006. 💖✨

📦 where this page comes from

opensuse-leap 16.0: mipv6d 2.0.2.umip.0.4-bp160.1.12 · GPL-2.0
opensuse-leap 16.0: mipv6d 2.0.2.umip.0.4-bp160.1.12 · GPL-2.0
opensuse-leap 16.0: mipv6d 2.0.2.umip.0.4-bp160.1.12 · GPL-2.0
opensuse-leap 16.0: mipv6d 2.0.2.umip.0.4-bp160.1.12 · GPL-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms