1mip6d.conf(5) Mobile IPv6 and NEMO Daemon Configuration mip6d.conf(5)
2
6 mip6d.conf - UMIP Mobile IPv6 and NEMO Configuration file
7
9 /etc/mip6d.conf
10
13 UMIP Mobile IPv6 and NEMO daemon's configuration file
14 Below is a list of currently supported configuration options. All con‐
16 figuration lines are terminated with a semicolon. Sub-sections are
17 enclosed in '{' and '}'. Optional parameters are designated with
18 square brackets (you must omit them if you set the optional parameter).
19 Strings are quoted with double quotes.
20 Default value is given when available. Support for dynamic reload of
22 the option through SIGHUP is also indicated.
23
26 The file contains the following common definitions:
27 include "<pattern>"
29 Includes content from other files based on provided pattern.
31 Usual shell wildcards are supported ('?', '*', '['). See man (7)
32 glob for details. The number of included files is virtually
33 unlimited but only five levels of recursion are authorized to
34 prevent loops. Note that if given pattern does not match any
35 file, a simple warning is issued but parsing continues. Unlike
36 most configuration statements, no ';' is expected after the pat‐
37 tern.
38 Example: include "/etc/mip6d.conf.d/*.conf"
40 NodeConfig CN | HA | MN;
44 Indicates if the daemon should run in Correspondent Node, Home
46 Agent or Mobile Node mode.
47 Default: CN
49 Dynamic reload: not supported. Daemon must be restarted.
51 DebugLevel number;
54 Indicates the debug level of the daemon. If the value is
56 greater than zero, the daemon will not detach from tty (i.e.
57 debug messages will be printed on the controlling tty).
58 Default: 0
60 Dynamic reload: partially supported. Cannot detach from tty
62 afterwards.
63 DebugLogFile "/path/to/log/file";
66 Indicates where debug logs should be stored.
68 Default: empty (output is redirected to stderr)
70 Dynamic reload: not supported. Daemon must be restarted.
72 DoRouteOptimizationCN boolean;
75 Indicates if a node should participate in route optimization
77 with a Mobile Node, i.e. if it should accept a binding proposed
78 by a peer. The value is used as the default binding policy
79 value, if no CnBindingPolicySet have been defined for the pro‐
80 posed binding.
81 Default: enabled
83 Dynamic reload: supported but does not affect existing bindings.
85 CnBindingPolicySet {
88 peer_hoa [ local_addr ] boolean;
89 ...
90 }
91 The decision to accept a binding from a MN and participate in
93 route optimization with it is governed on a global basis by
94 DoRouteOptimizationCN parameter, i.e. which is used as the
95 default binding policy value.
96 The CnBindingPolicySet section can be used to define specific
98 binding policies for some given peers. In that context, each
99 line is dedicated to a MN. The address (HoA) of the MN is given
100 as first element of the line (i.e. peer_hoa ). The local
101 address local_addr at which the Binding Update messages are
102 expected to be received can be optionally specified as second
103 argument (If we are acting as a MN, this will be one of our
104 HoA). If it is not provided, the local address to which the BU
105 from that MN are sent is not taken into account. The last argu‐
106 ment boolean specifies if the node should perform route opti‐
107 mization with that peer.
108 Note that a MN must have at most a single entry defined in that
110 section i.e. having more than one line starting with the same
111 address is not allowed.
112 Default: by default, the set is empty and the default value pro‐
114 vided by DoRouteOptimizationCN configuration parameter applies
115 for all peers.
116 Dynamic reload: not supported.
118 NonVolatileBindingCache boolean;
121 This option is currently ignored. Binding cache is always
123 stored in volatile memory, and is not retained between shutdown
124 and startup.
125
128 These options are used both in the Home Agent and Mobile Node:
129 Interface name;
131 Interface name {
133 MnIfPreference number;
134 IfType CN | HA | MN;
135 Tunnel boolean;
136 }
137 Specifies an interface and options associated with it. If no
139 options are present, Interface can be terminated with semi-
140 colon. This is used for home agent to specify which interfaces
141 are used for HA operation. For the home agent to function prop‐
142 erly, a Router Advertisement daemon (e.g. radvd) must broadcast
143 advertisements with the Home Agent bit and Home Agent Informa‐
144 tion Option set on these interfaces. This option is also used
145 by multihomed Mobile Nodes to define which interfaces are used
146 by it. For MN and CN, it is posible to provide interfaces that
147 are not already available when the daemon is started. Those will
148 be used when available.
149 Dynamic reload: partially supported. Only new inet6 interfaces
151 will use the new configuration.
152 MnIfPreference sets the interface preference value for an inter‐
154 face in a multi-homed Mobile Node. The most preferred inter‐
155 faces have preference 1, the second most preferred have 2, etc.
156 Values between 0 and 10 are allowed. A preference of zero means
157 the interface will not be used.
158 The interface preference has a direct impact on the metric of
160 default routes configured by the daemon from RA information.
161 Note that if two interfaces with associated default routes have
162 the same preference value, the routes will end up having the
163 same metric, except if different default router preference (RFC
164 4191) values are provided in RA. In a sense, MnIfPreference
165 value value is the primary selector for interface and default
166 route selection and default router preference value provided in
167 RA can then be used to break a tie.
168 Default: 10
170 IfType overrides the default node behavior for this interface.
172 If a MN doesn't wish to use this interface for mobility, or a
173 node doesn't act as HA on this interface, the interface type
174 should be set to CN.
175 Default: same as NodeConfig
177 Tunnel
179 When enabled, this flag explicitly marks the interface as a tun‐
181 nel interface and modify the behavior of UMIP regarding the
182 router discovery, address configuration and route addition steps
183 for the interface. Those are expected to be done externally
184 (manually or by another automatic process (for instance when
185 using a Teredo interface). Note that the handling of routing
186 via the interface is still partly handled by UMIP but leaves
187 some latitude to the user or the automatic process that setup
188 the interface. UMIP looks for default routes in the main table
189 that use the interface as output device and replaces them by a
190 default route with a proper preference. If a gateway was present
191 for the route (there is one for 6to4, but none when miredo is
192 used), it is kept in the new route. Other routes that are
193 defined for the device (including other default routes in other
194 tables) are left untouched.
195 Limitations and details:
197 1) Tunnel interfaces are only allowed for MN and CN (not HA).
199 2) They are never considered as home link (i.e. you will never
201 be at home on a tunnel).
202 3) Unlike for physical interfaces, link detection is not reli‐
204 able for tunnel interfaces. If the tunnel interface state is
205 directly dependent of some physical interface link status, that
206 status must be monitored externally (i.e. not by UMIP) and
207 reflected by having either the interface being set down/up or
208 address being removed/added for UMIP to detect the change in
209 interface configuration.
210 4) An address must be configured on the interface for it to be
212 selected. If no adress is available, UMIP will simply not con‐
213 sider the interface at all (even if it provides a default
214 route).
215 5) Routes that include specific sources are not considered by
217 UMIP.
218 Example:
220 When using a teredo interface, the default route through the
222 teredo device is found and its preference changed. Link local
223 routes are kept unchanged. Address configuration is kept unmodi‐
224 fied.
225 When using a 6to4 tunnel interface, a default route through the
227 6to4 device exists. It uses the 6to4 relay address
228 (::192.88.99.1 anycast address or another specific one) as gate‐
229 way. UMIP finds this default route and install a new default one
230 with the same gateway but an updated metric.
231 Default: disabled
233 UseMnHaIPsec boolean;
236 Indicates if the MN-HA MIPv6 signalling should be protected with
238 IPsec.
239 Default: enabled
241 Dynamic reload: not supported.
243 KeyMngMobCapability boolean;
246 If dynamic keying with MIPv6-aware IKE is used, this options
248 should be enabled. It turns on the K-bit for binding updates
249 and binding acknowledgements.
250 Default: disabled
252 Dynamic reload: supported.
254 IPsecPolicySet {
257 HomeAgentAddress address;
258 HomeAddress address/length;
259 IPsecPolicy ...
260 ...
261 }
262 IPsecPolicySet is a set of policies to apply for matching pack‐
264 ets. A policy set can contain multiple HomeAddress options, but
265 only one HomeAgentAddress option. For home agent, home agent
266 address field contains its own address, and home address fields
267 may contain any number of mobile nodes for which the same policy
268 applies.
269 Dynamic reload: supported. The sets can be changed, added or
271 removed. Removing rules for established bindings may have
272 unpredicted effects.
273 IPsecPolicy has the following format:
275 IPsecPolicy type UseESP number number;
278 Field type can be one of HomeRegBinding (for protecting BU/BH),
280 Mh (for protecting all MH packets: BU, BA, BE), MobPfxDisc (for
281 protecting MPS/MPA), ICMP (for protecting all ICMP packets,
282 including MPS/MPA), any (for protecting all transport mode com‐
283 munication), TunnelHomeTesting (for protecting the HoTI/HoT mes‐
284 sages), TunnelMh (for protecting all tunneled MH packets,
285 including HoTI/HoT), or TunnelPayload (for protecting all tun‐
286 neled packets including tunneled MH packets).
287 Currently only the ESP IPsec protocol is supported, but in the
289 future AH and IPComp might also be available. The two remaining
290 numeric fields are the IPsec reqid values, the first one used
291 for MN - HA, the second one for HA - MN communication. If just
292 one value is defined, the same reqid will be used in both direc‐
293 tions. If no reqid is given, reqid will not be used.
294 If more that one IPsec transport mode or tunnel mode policy is
296 defined between the MN and HA in each direction, reqid can be
297 used to provide an unambiguous one-to-one mapping between IPsec
298 policies and SAs. Otherwise the policies will just share a com‐
299 mon SA.
300
303 The following definitions are ignored unless the node is configured as
304 a HA:
305 HaMaxBindingLife number;
308 Limits the maximum lifetime (in seconds) for Mobile Node home
310 registrations.
311 Default: 262140
313 Dynamic reload: partially supported. Only affects new bindings.
315 SendMobPfxAdvs boolean;
318 Controls whether home agent sends Mobile Prefix Advertisements
320 to mobile nodes in foreign networks.
321 Default: enabled
323 Dynamic reload: partially supported. Only affects new bindings.
325 SendUnsolMobPfxAdvs boolean;
328 Controls whether home agent send unsolicited Mobile Prefix
330 Advertisements to mobile nodes in foreign networks.
331 Default: enabled
333 Dynamic reload: partially supported. Only affects new bindings.
335 MinMobPfxAdvInterval number;
338 Sets a minimum interval (in seconds) for Mobile Prefix Adver‐
340 tisements.
341 Default: 600
343 Dynamic reload: partially supported. Only affects new scheduled
345 MPA.
346 MaxMobPfxAdvInterval number;
349 Sets a maximum interval (in seconds) for Mobile Prefix Adver‐
351 tisements.
352 Default: 86400
354 Dynamic reload: Partially supported. Only affects new scheduled
356 MPA.
357 HaAcceptMobRtr enabled | disabled;
360 Indicates if the HA accepts Mobile Router bindings.
362 Default: disabled
364 Dynamic reload: supported.
366 HaServedPrefix prefix/length;
369 Prefix is an IPv6 prefix and length is the prefix length.
371 Defines the whole aggregated or extended prefix the HA serves.
372 This option is only used for MR bindings and is only needed if
373 the MRs derive their Home Addresses from their Mobile Network
374 Prefixes, instead of one of the home link prefixes.
375 Dynamic reload: supported.
377 BindingAclPolicy address [ MNP-list ] allow | deny;
380 Defines if a MN is allowed to register with the HA or not. The
382 home address of the MN is given in the address field. The
383 mobile network prefixes belonging a NEMO Mobile Router are
384 optionally listed in MNP-list for example: (3ffe:2620:6:3::/64,
385 3ffe:2620:6:4::/64)
386 Dynamic reload: partially supported. Does not affect existing
388 bindings until they expire.
389 DefaultBindingAclPolicy allow | deny;
392 Defines the default policy if no matching BindingAclPolicy entry
394 is found for a MN.
395 Default: allow
397 Dynamic reload: partially supported. Only affects new bindings.
399
402 The following definitions are ignored unless the node is configured as
403 a MN:
404 MnMaxHaBindingLife number;
407 Limits the maximum lifetime (in seconds) for Mobile Node home
409 registrations.
410 Default: 262140
412 Dynamic reload: partially supported. Only affects new bindings.
414 MnMaxCnBindingLife number;
417 Limits the maximum lifetime (in seconds) for Mobile Node Corre‐
419 spondent Node registrations.
420 Default: 420
422 Dynamic reload: partially supported. Only affects new bindings.
424 MnDiscardHaParamProb boolean;
427 Toggles if the Mobile Node should discard ICMPv6 Parameter Prob‐
429 lem messages from its Home Agent. As the ICMPv6 error messages
430 won't normally be protected by IPsec, a malicious third party
431 can quite easily impersonate the HA to the MN. Having the MN
432 accept these messages therefore leaves it open to Denial of Ser‐
433 vice attacks, even though its home registration signalling is
434 protected by IPsec.
435 Default: disabled
437 Dynamic reload: supported.
439 MnResetDhaadAtHome boolean;
442 If the MN uses DHAAD, then enabling this option will force UMIP
444 to set the Home Agent Address to the unspecified address every
445 time the MN returns home. As a consequence, the MN will run
446 DHAAD every time it moves from home to a foreign network. If
447 disabled, the HA address obtained from the very first DHAAD
448 exchange will be remembered even if the MN returns home.
449 Default: disabled
451 Dynamic reload: supported.
453 MnFlushAllAtHome boolean;
456 Enabling this option allows the MN to flush all uncertain regis‐
458 trations upon returning home, instead of keeping trying to com‐
459 plete them from home until the retry counters expire. Also, this
460 option forces the returning home procedure for valid registra‐
461 tions in the case the HA does not reply to DAD probe when
462 returning home.
463 Default: disabled
465 Dynamic reload: supported.
467 MnMaxCnConsecutiveResends number;
470 By default, if the MN does not receives a BA from a CN, it
472 resends the BU indefinitely. Setting this option to 1 or more
473 allows to stop trying after the specified number. 1 resend is
474 the minimum, as 0 is a reserved value to indicate that resend
475 should be performed indefinitely.
476 Default: 0 (resend indefinitely)
478 Dynamic reload: supported.
480 MnMaxHaConsecutiveResends number;
483 By default, if the MN learnt the HA address through DHAAD and
485 did not receive a BA from a HA after 5 retries, it invalidates
486 the HA and tries to switch to another HA. This option allows to
487 tune the number of retry before switching. Note that if DHAAD is
488 not used, this option has no effect, and the MN retries sending
489 the BU indefinitely.
490 Default: 5
492 Dynamic reload: supported.
494 SendMobPfxSols boolean;
497 Controls whether mobile node sends Mobile Prefix Solicitations
499 to the home network.
500 Default: enabled
502 Dynamic reload: supported.
504 DoRouteOptimizationMN boolean;
507 Indicates if the Mobile Node should initialize route optimiza‐
509 tion with Correspondent Nodes.
510 Default: enabled
512 Dynamic reload: partially supported, disabling is not supported.
514 MnUseAllInterfaces enabled | disabled;
517 Indicates if all interfaces should be used for mobility. The
519 preference of these interfaces is always 1. Unless you use
520 dynamically created and named network interfaces you should nor‐
521 mally disable this option and use Interface options to explic‐
522 itly list the used interfaces.
523 Default: disabled
525 Dynamic reload: same support as "Interface" directive.
527 MobRtrUseExplicitMode enabled | disabled;
530 Toggles between explicit or implicit mode home registrations in
532 the MR.
533 Default: enabled
535 Dynamic reload: supported.
537 UseCnBuAck boolean;
540 Indicates if the Acknowledge bit should be set in Binding
542 Updates sent to Correspondent Nodes.
543 Default: disabled
545 Dynamic reload: supported.
547 InterfaceInitialInitDelay decimal;
550 Defines the delay (in seconds) for initial interface configura‐
552 tion at startup before any movement decision occurs.
553 At startup, UMIP gathers information on interfaces available on
555 the system. Then, for interfaces listed in the configuration,
556 it either learn CoA (for those marked as Tunnel) or send RS to
557 receive RA (asynchronously) and then configured CoA.
558 At startup, if the MN has multiple interfaces, UMIP may first
560 select a CoA on a given interface and then change its mind and
561 switch to another CoA. This may result in the emission of multi‐
562 ple useless BU. Additionally, when Dynamic Keying (IKE) is used
563 for negotiating protection of traffic, a CoA change occurring
564 during the initial negotiation only leads to additional delays.
565 By introducing an initial default delay at startup, that side
567 effect is avoided. If your MN is configured to use only a single
568 interface, or do not use IKE and startup delay matters, you may
569 set the parameter to 0.
570 Default: 2.0
572 Dynamic reload: not supported (only valid at daemon startup).
574 MnRouterProbes number;
577 Indicates how many times the MN should send Neighbor Unreacha‐
579 bility Detection (NUD) probes to its old router after receiving
580 a Router Advertisement (RA) from a new one. If the option is set
581 to zero or the new router advertises a strictly higher default
582 preference value than the old one (as defined in RFC 4191), the
583 MN will move to the new router straight away.
584 Default: 0
586 Dynamic reload: supported.
588 MnRouterProbeTimeout decimal;
591 Indicates how long (in seconds) the MN should wait for a reply
593 during a access router Neighbor Unreachability Detection probe.
594 If set, it overrides any default Neighbor Solicitation Retrans‐
595 mit Timer value greater than MnRouterProbeTimeout. For example,
596 if the interface Retransmit Timer is 1 second, but MnRouterPro‐
597 beTimeout is just 0.2 seconds, the MN will only wait 0.2 seconds
598 for a Neighbor Advertisement before proceeding with the handoff.
599 Default: 0.0
601 Dynamic reload: supported.
603 InitialBindackTimeoutFirstReg decimal;
606 Upon the first registration attempt, indicates how long (in sec‐
608 onds) the MN should wait before re-sending the Binding Update
609 when no Binding Ack has been received. For subsequent registra‐
610 tions, you may set the InitialBindackTimeoutReReg option.
611 Default: 1.5
613 Dynamic reload: partially supported. Only affects new bindings.
615 InitialBindackTimeoutReReg decimal;
618 Indicates how long (in seconds) the MN should wait before re-
620 sending the Binding Update when no Binding Ack has been
621 received. For the first registration attempt, you may set the
622 InitialBindackTimeoutFirstReg option.
623 Default: 1.0
625 Dynamic reload: partially supported. Does not affect existing
627 bindings until they expire.
628 InitialSolicitTimer decimal;
631 Indicates how long (in seconds) the MN should wait before re-
633 sending the initial Mobile Prefix Solitication message when no
634 answers have been received. Option SendMobPfxSols must be
635 enabled.
636 Default: 3.0
638 Dynamic reload: not supported.
640 OptimisticHandoff enabled | disabled;
643 When a Mobile Node sends a Binding Update to the Home Agent, no
645 Route Optimized or reverse tunneled traffic is sent until a
646 Binding Acknowledgement is received. When enabled, this option
647 allows the Mobile Node to assume that the binding was successful
648 right after the BU has been sent, and does not wait for a posi‐
649 tive acknowledgement before using RO or reverse tunneling.
650 Default: disabled
652 Dynamic reload: supported.
654 NoHomeReturn enabled | disabled;
657 When a MN returns Home, it usually deregisters its binding.
659 Additionally, when IPsec is in use to protect data traffic, a MN
660 also deinstall the IPsec Security Policies protecting data traf‐
661 fic. One problem with that expected behavior is that an insecure
662 trigger (Home Link Detection mechanism, based on prefix
663 announced in RA messages) is used for the removal of IPsec Secu‐
664 rity Policies for data traffic.
665 The NoHomeReturn option can be used to change that behavior.
667 When enabled, the MN will never consider itself at home. That
668 way, if IPsec is used to protect data traffic, associated Secu‐
669 rity Policies will never be removed.
670 Note that for the option to work when the MN really returns home
672 (i.e. on the subnet where the Home Agent is defending MN's HoA),
673 the two following conditions must be met:
674 1) The HoA of the MN must be different from the CoA the MN will
676 automatically configure itself on its interface that connects to
677 its home network,
678 2) The interface that connects to the home subnet must not be
680 the MnHomeLink interface (because the MN configures its HoA on
681 that interface, which will in turn make DAD fail on the HA for
682 the HoA).
683 Default: disabled
685 Dynamic reload: supported (for the next home return).
687 MnHomeLink name {
690 HomeAddress address/length [ MNP-list ];
691 HomeAgentAddress address;
692 MnRoPolicy ...
693 ...
694 }
695 Each MnHomeLink definition has a name. This is the name
697 (enclosed in double quotes) of the interface used for connecting
698 to the physical home link. To set up multiple Home Addresses on
699 the Mobile Node, you need to define multiple MnHomeLink struc‐
700 tures. The interface names don't have to be unique in these
701 definitions.
702 Dynamic reload: not supported. The daemon has to be restarted
704 for the changes in this directive to take effect.
705 All the home link specific definitions are detailed below:
707 HomeAddress address/length [ MNP-list ];
710 Address is an IPv6 address, and length the prefix length of the
712 address, usually 64. The MNP-list contains the mobile network
713 prefixes belonging to that particular NEMO Mobile Router. The
714 MNP-list is optional and is of the same format as in BindingA‐
715 clPolicy. This option must be included in a home link defini‐
716 tion.
717 HomeAgentAddress address;
720 Address is the IPv6 address of the Mobile Node's Home Agent.
722 DHAAD is used if it is the unspecified address ::.
723 Default: ::
725 IsMobRtr enabled | disabled;
728 Defines if the MN is a NEMO MR.
730 Default: disabled
732 The route optimization policies are of the form:
735 MnRoPolicy address boolean;
738 Any number of these policies may be defined. If no policies are
740 defined default behavior depends on the DoRouteOptimizationMN
741 option.
742 The fields for a route optimization policy entry are as follows:
744 address defines the Correspondent Node this policy applies to,
745 if left undefined the uspecified address is used as a wildcard
746 value boolean sets route optimization either enabled or disabled
747 for packets matching this entry.
748
751 A NEMO Home Agent example (without IPsec):
752 NodeConfig HA;
754 Interface "eth0";
756 HaAcceptMobRtr enabled;
758 HaServedPrefix 3ffe:2620:6::/48;
760 DefaultBindingAclPolicy deny;
762 BindingAclPolicy 3ffe:2620:6:1::1234 (3ffe:2620:6:2::/64, 3ffe:2620:6:3::/64) allow;
763 BindingAclPolicy 3ffe:2620:6:1::1235 allow;
764 UseMnHaIPsec disabled;
766 A NEMO Mobile Router example (without IPsec):
769 NodeConfig MN;
771 DoRouteOptimizationCN disabled;
773 DoRouteOptimizationMN disabled;
774 Interface "eth0";
776 MnRouterProbes 1;
778 MobRtrUseExplicitMode enabled;
780 MnHomeLink "eth0" {
782 IsMobRtr enabled;
783 HomeAgentAddress 3ffe:2620:6:1::1;
784 HomeAddress 3ffe:2620:6:1::1234/64 (3ffe:2620:6:2::/64, 3ffe:2620:6:3::/64);
785 }
786 UseMnHaIPsec disabled;
788 A Correspondent Node example (without IPsec):
791 NodeConfig CN;
793 DoRouteOptimizationCN enabled;
795 A Home Agent example (with IPsec static keying):
798 NodeConfig HA;
800 Interface "eth0";
802 BindingAclPolicy 3ffe:2620:6:1::1234 allow;
804 UseMnHaIPsec enabled;
806 IPsecPolicySet {
808 HomeAgentAddress 3ffe:2620:6:1::1;
809 HomeAddress 3ffe:2620:6:1::1234/64;
810 # All MH packets (BU/BA/BERR)
812 IPsecPolicy Mh UseESP 111 112;
813 # All tunneled packets (HoTI/HoT, payload)
814 IPsecPolicy TunnelPayload UseESP 113 114;
815 # All ICMP packets (MPS/MPA, ICMPv6)
816 IPsecPolicy ICMP UseESP 115 116;
817 }
818 A Mobile Node example (with IPsec static keying):
821 NodeConfig MN;
823 DoRouteOptimizationCN enabled;
825 # DoRouteOptimizationMN cannot be used
826 # with TunnelPayload IPsecPolicy
827 DoRouteOptimizationMN disabled;
828 UseCnBuAck enabled;
830 MnHomeLink "eth0" {
832 HomeAgentAddress 3ffe:2620:6:1::1;
833 HomeAddress 3ffe:2620:6:1::1234/64;
834 # address opt.
836 #MnRoPolicy 3ffe:2060:6:1::3 enabled;
837 #MnRoPolicy disabled;
838 }
839 UseMnHaIPsec enabled;
841 IPsecPolicySet {
843 HomeAgentAddress 3ffe:2620:6:1::1;
844 HomeAddress 3ffe:2620:6:1::1234/64;
845 # All MH packets (BU/BA/BERR)
847 IPsecPolicy Mh UseESP 111 112;
848 # All tunneled packets (HoTI/HoT, payload)
849 IPsecPolicy TunnelPayload UseESP 113 114;
850 # All ICMP packets (MPS/MPA, ICMPv6)
851 IPsecPolicy ICMP UseESP 115 116;
852 }
853
856 mip6d(1), mipv6(7),
857 RFC6275: Mobility Support in IPv6
859 RFC3776: Using IPsec to Protect Mobile IPv6 Signaling Between Mobile
861 Nodes and Home Agents
862 RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Archi‐
864 tecture
865 RFC3963: Network Mobility (NEMO) Basic Support Protocol
867 January 31, 2006 mip6d.conf(5)