RFC 5419: Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
In plain English — editorial summary, not part of the RFC
Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments. This memo provides information for the Internet community.
Document record
- Document ID
- RFC5419
- Published
- January 2009
- Authors
- B. Patil; G. Dommety
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- int
- Pages
- 19
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4280Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control ServersCurrent
December 2005
- RFC 4068Fast Handovers for Mobile IPv6Obsoleted
July 2005
- RFC 4067Context Transfer Protocol (CXTP)Current
July 2005
- RFC 4066Candidate Access Router Discovery (CARD)Current
July 2005
- RFC 7121High Availability within a Forwarding and Control Element Separation (ForCES) Network ElementUpdated
February 2014
- RFC 5395Domain Name System (DNS) IANA ConsiderationsObsoleted
November 2008
- RFC 5452Measures for Making DNS More Resilient against Forged AnswersCurrent
January 2009
- RFC 5453Reserved IPv6 Interface IdentifiersCurrent
February 2009
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?