Design Considerations for MIPv6 Firewall Traversal

Introduction

Terminology

I don't think we need too many new terms but we might be able to copy-and-paste something from RFC 4621 (see http://www.rfc-editor.org/rfc/rfc4621.txt). Maybe we want to reuse these terms:

• Available address
• Locally operational address
• Operational address pair
• Path
• Current path
• Preferred address
• Peer address set
• Bidirectional address pair
• Unidirectional address pair

I believe that this terminology would be very useful for the case where multiple addresses exist and more than once choice is available.

Scope

Explain what is in- and out-of-scope of the work. Previously, we have said that the following functionality is outside the scope of the work:

• Protocol between FW and MN that is triggered by incoming data packets.
• Transferring packet filter rules between HA and MAP (HMIP) secured using IKE.
• HA behind a VPN gateway

Design Considerations

IPsec Usage between MN and HA

Mobile Nodes and Multiple Interfaces in IPv6 (monami6)

MIPv6 Authentication Protocol (RFC 4285)

IPsec between Mobile and Correspondent IPv6 Nodes

Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)

Deployment Considerations

Gabor mentioned different deployment scenarios to consider based on the capabilities of the involved nodes and their ability to support potential extensions.

All nodes support the signaling solution

Firewall does not support it.

One of the end points (CN, HA, MN) does not support it.

Strawman Proposals

Not quite sure about this section. We could put high-level solution ideas in the quality of strawman proposals in there.

Security Considerations

Place for non-obvious security issues.

IANA Considerations

Empty since we don't define a solution in this doc.

-- HannesTschofenig - 21 Jan 2007