Recognize an IPv4 tail
04Some IPv6 address forms embed an IPv4 address in the final 32 bits. Mixed notation writes only those bits as four decimal octets.
2001:db8::c000:201 alone does not establish an IPv4-embedding scheme. Keep ordinary hexadecimal output; external prefix knowledge could instead permit mixed notation.
Source for this drawing: RFC 5952 · Read RFC section 5 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Identify the address type before selecting mixed output.
- For recognizable IPv4-embedded forms using a well-known prefix, mixed notation is RECOMMENDED. The IPv4-mapped format has 80 zero bits, 16 one bits, then the IPv4 address (RFC 4291 §2.5.5.2).
- Only the last 32 bits use dotted decimal. Apply the §4 hexadecimal rules to the leading part: ::ffff:192.0.2.1 is the shown mapped example.
- If external information establishes that a particular prefix embeds IPv4, mixed notation MAY be used. Do not infer that any arbitrary IPv6 suffix is an IPv4 address.
This is a formatting example, not a NAT, DNS, or connection algorithm. The prefix identifies the mapped form; the four decimal octets encode the same 32 bits as c000:201. Scoped zone identifiers and later embedding schemes are outside this walkthrough.
Read the RFC section ↗