RFC 4135: Goals of Detecting Network Attachment in IPv6
In plain English — editorial summary, not part of the RFC
When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling. This memo provides information for the Internet community.
Document record
- Document ID
- RFC4135
- Published
- August 2005
- Authors
- JH. Choi; G. Daley
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- int
- Pages
- 9
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6059Simple Procedures for Detecting Network Attachment in IPv6Current
November 2010
- RFC 1376The PPP DECnet Phase IV Control Protocol (DNCP)Obsoleted
November 1992
- RFC 4137State Machines for Extensible Authentication Protocol (EAP) Peer and AuthenticatorCurrent
August 2005
- RFC 4140Hierarchical Mobile IPv6 Mobility Management (HMIPv6)Obsoleted
August 2005
- RFC 4113Management Information Base for the User Datagram Protocol (UDP)Current
June 2005
- RFC 4174The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name ServiceUpdated
September 2005
- RFC 4093Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) GatewaysCurrent
August 2005
- RFC 4087IP Tunnel MIBCurrent
June 2005
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?