1mip6d.conf(5) Mobile IPv6 and NEMO Daemon Configuration mip6d.conf(5)
2
3
4
6 mip6d.conf - UMIP Mobile IPv6 and NEMO Configuration file
7
9 /etc/mip6d.conf
10
11
13 UMIP Mobile IPv6 and NEMO daemon's configuration file
14
15 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
21 Default value is given when available. Support for dynamic reload of
22 the option through SIGHUP is also indicated.
23
24
26 The file contains the following common definitions:
27
28 include "<pattern>"
29
30 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
39 Example: include "/etc/mip6d.conf.d/*.conf"
40
41
42
43 NodeConfig CN | HA | MN;
44
45 Indicates if the daemon should run in Correspondent Node, Home
46 Agent or Mobile Node mode.
47
48 Default: CN
49
50 Dynamic reload: not supported. Daemon must be restarted.
51
52
53 DebugLevel number;
54
55 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
59 Default: 0
60
61 Dynamic reload: partially supported. Cannot detach from tty
62 afterwards.
63
64
65 DebugLogFile "/path/to/log/file";
66
67 Indicates where debug logs should be stored.
68
69 Default: empty (output is redirected to stderr)
70
71 Dynamic reload: not supported. Daemon must be restarted.
72
73
74 DoRouteOptimizationCN boolean;
75
76 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
82 Default: enabled
83
84 Dynamic reload: supported but does not affect existing bindings.
85
86
87 CnBindingPolicySet {
88 peer_hoa [ local_addr ] boolean;
89 ...
90 }
91
92 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
97 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
109 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
113 Default: by default, the set is empty and the default value pro‐
114 vided by DoRouteOptimizationCN configuration parameter applies
115 for all peers.
116
117 Dynamic reload: not supported.
118
119
120 NonVolatileBindingCache boolean;
121
122 This option is currently ignored. Binding cache is always
123 stored in volatile memory, and is not retained between shutdown
124 and startup.
125
126
128 These options are used both in the Home Agent and Mobile Node:
129
130 Interface name;
131
132 Interface name {
133 MnIfPreference number;
134 IfType CN | HA | MN;
135 Tunnel boolean;
136 }
137
138 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
150 Dynamic reload: partially supported. Only new inet6 interfaces
151 will use the new configuration.
152
153 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
159 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
169 Default: 10
170
171 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
176 Default: same as NodeConfig
177
178 Tunnel
179
180 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
196 Limitations and details:
197
198 1) Tunnel interfaces are only allowed for MN and CN (not HA).
199
200 2) They are never considered as home link (i.e. you will never
201 be at home on a tunnel).
202
203 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
211 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
216 5) Routes that include specific sources are not considered by
217 UMIP.
218
219 Example:
220
221 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
226 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
232 Default: disabled
233
234
235 UseMnHaIPsec boolean;
236
237 Indicates if the MN-HA MIPv6 signalling should be protected with
238 IPsec.
239
240 Default: enabled
241
242 Dynamic reload: not supported.
243
244
245 KeyMngMobCapability boolean;
246
247 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
251 Default: disabled
252
253 Dynamic reload: supported.
254
255
256 IPsecPolicySet {
257 HomeAgentAddress address;
258 HomeAddress address/length;
259 IPsecPolicy ...
260 ...
261 }
262
263 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
270 Dynamic reload: supported. The sets can be changed, added or
271 removed. Removing rules for established bindings may have
272 unpredicted effects.
273
274 IPsecPolicy has the following format:
275
276
277 IPsecPolicy type UseESP number number;
278
279 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
288 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
295 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
301
303 The following definitions are ignored unless the node is configured as
304 a HA:
305
306
307 HaMaxBindingLife number;
308
309 Limits the maximum lifetime (in seconds) for Mobile Node home
310 registrations.
311
312 Default: 262140
313
314 Dynamic reload: partially supported. Only affects new bindings.
315
316
317 SendMobPfxAdvs boolean;
318
319 Controls whether home agent sends Mobile Prefix Advertisements
320 to mobile nodes in foreign networks.
321
322 Default: enabled
323
324 Dynamic reload: partially supported. Only affects new bindings.
325
326
327 SendUnsolMobPfxAdvs boolean;
328
329 Controls whether home agent send unsolicited Mobile Prefix
330 Advertisements to mobile nodes in foreign networks.
331
332 Default: enabled
333
334 Dynamic reload: partially supported. Only affects new bindings.
335
336
337 MinMobPfxAdvInterval number;
338
339 Sets a minimum interval (in seconds) for Mobile Prefix Adver‐
340 tisements.
341
342 Default: 600
343
344 Dynamic reload: partially supported. Only affects new scheduled
345 MPA.
346
347
348 MaxMobPfxAdvInterval number;
349
350 Sets a maximum interval (in seconds) for Mobile Prefix Adver‐
351 tisements.
352
353 Default: 86400
354
355 Dynamic reload: Partially supported. Only affects new scheduled
356 MPA.
357
358
359 HaAcceptMobRtr enabled | disabled;
360
361 Indicates if the HA accepts Mobile Router bindings.
362
363 Default: disabled
364
365 Dynamic reload: supported.
366
367
368 HaServedPrefix prefix/length;
369
370 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
376 Dynamic reload: supported.
377
378
379 BindingAclPolicy address [ MNP-list ] allow | deny;
380
381 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
387 Dynamic reload: partially supported. Does not affect existing
388 bindings until they expire.
389
390
391 DefaultBindingAclPolicy allow | deny;
392
393 Defines the default policy if no matching BindingAclPolicy entry
394 is found for a MN.
395
396 Default: allow
397
398 Dynamic reload: partially supported. Only affects new bindings.
399
400
402 The following definitions are ignored unless the node is configured as
403 a MN:
404
405
406 MnMaxHaBindingLife number;
407
408 Limits the maximum lifetime (in seconds) for Mobile Node home
409 registrations.
410
411 Default: 262140
412
413 Dynamic reload: partially supported. Only affects new bindings.
414
415
416 MnMaxCnBindingLife number;
417
418 Limits the maximum lifetime (in seconds) for Mobile Node Corre‐
419 spondent Node registrations.
420
421 Default: 420
422
423 Dynamic reload: partially supported. Only affects new bindings.
424
425
426 MnDiscardHaParamProb boolean;
427
428 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
436 Default: disabled
437
438 Dynamic reload: supported.
439
440
441 MnResetDhaadAtHome boolean;
442
443 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
450 Default: disabled
451
452 Dynamic reload: supported.
453
454
455 MnFlushAllAtHome boolean;
456
457 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
464 Default: disabled
465
466 Dynamic reload: supported.
467
468
469 MnMaxCnConsecutiveResends number;
470
471 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
477 Default: 0 (resend indefinitely)
478
479 Dynamic reload: supported.
480
481
482 MnMaxHaConsecutiveResends number;
483
484 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
491 Default: 5
492
493 Dynamic reload: supported.
494
495
496 SendMobPfxSols boolean;
497
498 Controls whether mobile node sends Mobile Prefix Solicitations
499 to the home network.
500
501 Default: enabled
502
503 Dynamic reload: supported.
504
505
506 DoRouteOptimizationMN boolean;
507
508 Indicates if the Mobile Node should initialize route optimiza‐
509 tion with Correspondent Nodes.
510
511 Default: enabled
512
513 Dynamic reload: partially supported, disabling is not supported.
514
515
516 MnUseAllInterfaces enabled | disabled;
517
518 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
524 Default: disabled
525
526 Dynamic reload: same support as "Interface" directive.
527
528
529 MobRtrUseExplicitMode enabled | disabled;
530
531 Toggles between explicit or implicit mode home registrations in
532 the MR.
533
534 Default: enabled
535
536 Dynamic reload: supported.
537
538
539 UseCnBuAck boolean;
540
541 Indicates if the Acknowledge bit should be set in Binding
542 Updates sent to Correspondent Nodes.
543
544 Default: disabled
545
546 Dynamic reload: supported.
547
548
549 InterfaceInitialInitDelay decimal;
550
551 Defines the delay (in seconds) for initial interface configura‐
552 tion at startup before any movement decision occurs.
553
554 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
559 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
566 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
571 Default: 2.0
572
573 Dynamic reload: not supported (only valid at daemon startup).
574
575
576 MnRouterProbes number;
577
578 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
585 Default: 0
586
587 Dynamic reload: supported.
588
589
590 MnRouterProbeTimeout decimal;
591
592 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
600 Default: 0.0
601
602 Dynamic reload: supported.
603
604
605 InitialBindackTimeoutFirstReg decimal;
606
607 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
612 Default: 1.5
613
614 Dynamic reload: partially supported. Only affects new bindings.
615
616
617 InitialBindackTimeoutReReg decimal;
618
619 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
624 Default: 1.0
625
626 Dynamic reload: partially supported. Does not affect existing
627 bindings until they expire.
628
629
630 InitialSolicitTimer decimal;
631
632 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
637 Default: 3.0
638
639 Dynamic reload: not supported.
640
641
642 OptimisticHandoff enabled | disabled;
643
644 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
651 Default: disabled
652
653 Dynamic reload: supported.
654
655
656 NoHomeReturn enabled | disabled;
657
658 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
666 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
671 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
675 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
679 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
684 Default: disabled
685
686 Dynamic reload: supported (for the next home return).
687
688
689 MnHomeLink name {
690 HomeAddress address/length [ MNP-list ];
691 HomeAgentAddress address;
692 MnRoPolicy ...
693 ...
694 }
695
696 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
703 Dynamic reload: not supported. The daemon has to be restarted
704 for the changes in this directive to take effect.
705
706 All the home link specific definitions are detailed below:
707
708
709 HomeAddress address/length [ MNP-list ];
710
711 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
718
719 HomeAgentAddress address;
720
721 Address is the IPv6 address of the Mobile Node's Home Agent.
722 DHAAD is used if it is the unspecified address ::.
723
724 Default: ::
725
726
727 IsMobRtr enabled | disabled;
728
729 Defines if the MN is a NEMO MR.
730
731 Default: disabled
732
733
734 The route optimization policies are of the form:
735
736
737 MnRoPolicy address boolean;
738
739 Any number of these policies may be defined. If no policies are
740 defined default behavior depends on the DoRouteOptimizationMN
741 option.
742
743 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
749
751 A NEMO Home Agent example (without IPsec):
752
753 NodeConfig HA;
754
755 Interface "eth0";
756
757 HaAcceptMobRtr enabled;
758
759 HaServedPrefix 3ffe:2620:6::/48;
760
761 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
765 UseMnHaIPsec disabled;
766
767
768 A NEMO Mobile Router example (without IPsec):
769
770 NodeConfig MN;
771
772 DoRouteOptimizationCN disabled;
773 DoRouteOptimizationMN disabled;
774
775 Interface "eth0";
776
777 MnRouterProbes 1;
778
779 MobRtrUseExplicitMode enabled;
780
781 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
787 UseMnHaIPsec disabled;
788
789
790 A Correspondent Node example (without IPsec):
791
792 NodeConfig CN;
793
794 DoRouteOptimizationCN enabled;
795
796
797 A Home Agent example (with IPsec static keying):
798
799 NodeConfig HA;
800
801 Interface "eth0";
802
803 BindingAclPolicy 3ffe:2620:6:1::1234 allow;
804
805 UseMnHaIPsec enabled;
806
807 IPsecPolicySet {
808 HomeAgentAddress 3ffe:2620:6:1::1;
809 HomeAddress 3ffe:2620:6:1::1234/64;
810
811 # 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
819
820 A Mobile Node example (with IPsec static keying):
821
822 NodeConfig MN;
823
824 DoRouteOptimizationCN enabled;
825 # DoRouteOptimizationMN cannot be used
826 # with TunnelPayload IPsecPolicy
827 DoRouteOptimizationMN disabled;
828
829 UseCnBuAck enabled;
830
831 MnHomeLink "eth0" {
832 HomeAgentAddress 3ffe:2620:6:1::1;
833 HomeAddress 3ffe:2620:6:1::1234/64;
834
835 # address opt.
836 #MnRoPolicy 3ffe:2060:6:1::3 enabled;
837 #MnRoPolicy disabled;
838 }
839
840 UseMnHaIPsec enabled;
841
842 IPsecPolicySet {
843 HomeAgentAddress 3ffe:2620:6:1::1;
844 HomeAddress 3ffe:2620:6:1::1234/64;
845
846 # 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
854
856 mip6d(1), mipv6(7),
857
858 RFC6275: Mobility Support in IPv6
859
860 RFC3776: Using IPsec to Protect Mobile IPv6 Signaling Between Mobile
861 Nodes and Home Agents
862
863 RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Archi‐
864 tecture
865
866 RFC3963: Network Mobility (NEMO) Basic Support Protocol
867
868
869
870 January 31, 2006 mip6d.conf(5)