RFC 5565: Softwire Mesh Framework
In plain English — editorial summary, not part of the RFC
The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]
Document record
- Document ID
- RFC5565
- Published
- June 2009
- Authors
- J. Wu; Y. Cui; C. Metz; E. Rosen
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- int
- Pages
- 31
- Also known as
- —
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 5566BGP IPsec Tunnel Encapsulation AttributeObsoleted
June 2009
- RFC 5568Mobile IPv6 Fast HandoversUpdated
July 2009
- RFC 5571Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)Current
June 2009
- RFC 5555Mobile IPv6 Support for Dual Stack Hosts and RoutersUpdated
June 2009
- RFC 5549Advertising IPv4 Network Layer Reachability Information with an IPv6 Next HopObsoleted
May 2009
- RFC 5543BGP Traffic Engineering AttributeUpdated
May 2009
- RFC 5535Hash-Based Addresses (HBA)Current
June 2009
- RFC 5534Failure Detection and Locator Pair Exploration Protocol for IPv6 MultihomingCurrent
June 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?