Приложение A. Будущие расширения
A.1. Комбинированные передачи
This document does not specify how to piggyback payload packets on the binding related messages. However, it is envisioned that this can be specified in a separate document when issues such as the interaction between piggybacking and IPsec are fully resolved (see also Appendix A.3). The return routability messages can indicate support for piggybacking with a new mobility option.
A.2. Треугольная маршрутизация
Due to the concerns about opening reflection attacks with the Home Address destination option, this specification requires that this option be verified against the Binding Cache, i.e., there must be a Binding Cache entry for the Home Address and Care-of Address. Future extensions may be specified that allow the use of unverified Home Address destination options in ways that do not introduce security issues.
A.3. Новые методы авторизации
While the return routability procedure provides a good level of security, there exist methods that have even higher levels of security. Secondly, as discussed in Section 15.4, future enhancements of IPv6 security may cause a need to also improve the security of the return routability procedure. Using IPsec as the sole method for authorizing Binding Updates to correspondent nodes is also possible. The protection of the Mobility Header for this purpose is easy, though one must ensure that the IPsec SA was created with appropriate authorization to use the home address referenced in the Binding Update. For instance, a certificate used by IKE to create the security association might contain the home address. A future specification may specify how this is done.
A.4. Динамически генерируемые домашние адреса
A future version of this specification may include functionality that allows the generation of new home addresses without requiring prearranged security associations or certificates even for the new addresses.
A.5. Удаленное конфигурирование домашнего адреса
The method for initializing a mobile node's home address upon powerup or after an extended period of being disconnected from the network is beyond the scope of this specification. Whatever procedure is used should result in the mobile node having the same stateless or stateful (e.g., DHCPv6) home address autoconfiguration information it would have if it were attached to the home network. Due to the possibility that the home network could be renumbered while the mobile node is disconnected, a robust mobile node would not rely solely on storing these addresses locally.
Such a mobile node could be initialized by using the following procedure:
- Generate a care-of address.
- Query DNS for an anycast address associated with the FQDN of the home agent(s).
- Perform home agent address discovery, and select a home agent.
- Configure one home address based on the selected home agent's subnet prefix and the interface identifier of the mobile node.
- Create security associations and security policy database entries for protecting the traffic between the selected home address and home agent.
- Perform a home registration on the selected home agent.
- Perform mobile prefix discovery.
- Make a decision if further home addresses need to be configured.
This procedure is restricted to those situations where the home prefix is 64 bits and the mobile node knows its own interface identifier, which is also 64 bits.
A.6. Расширения протокола Neighbor Discovery
Future specifications may improve the efficiency of Neighbor Discovery tasks, which could be helpful for fast movements. One factor is currently being looked at: the delays caused by the Duplicate Address Detection mechanism. Currently, Duplicate Address Detection needs to be performed for every new care-of address as the mobile node moves, and for the mobile node's link-local address on every new link. In particular, the need and the trade-offs of reperforming Duplicate Address Detection for the link-local address every time the mobile node moves on to new links will need to be examined. Improvements in this area are, however, generally applicable and progress independently from the Mobile IPv6 specification.
Future functional improvements may also be relevant for Mobile IPv6 and other applications. For instance, mechanisms that would allow recovery from a Duplicate Address Detection collision would be useful for link-local, care-of, and home addresses.
Адреса авторов
David B. Johnson
Rice University
Dept. of Computer Science, MS 132
6100 Main Street
Houston TX 77005-1892 USA
EMail: ude.ecir.sc@jbd
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043 USA
EMail: moc.aikon.grpi@peilrahc
Jari Arkko
Ericsson
02420 Jorvas Finland
EMail: moc.nosscire@okkra.iraj