A fire district shortens 2001:0db8:0000:0000:0000:0000:0000:0001 for city documentation. Which compressed form is correct?
Select an answer to reveal the explanation.
Short Explanation
Drop leading zeros in each hextet, then collapse the longest run of zero hextets into one double-colon — once only. That turns the long museum-piece address into tidy 2001:db8::1 for the runbook.
Full Explanation
A fire district shortens 2001:0db8:0000:0000:0000:0000:0000:0001 for city documentation. Correct IPv6 compression drops leading zeros in each hextet and replaces the longest contiguous run of all-zero hextets with a single “::” used at most once. Applying that yields 2001:db8::1: the leading zero in 0db8 becomes db8, and the long zero run collapses to :: before the final 1.
2001:db8:1 is incomplete—it does not represent eight hextets and omits required compression structure for the zero run. 2001::0db8::1 is illegal because “::” may appear only once; two compressions make the address ambiguous. 2001:0db8::0000:1 still retains unnecessary leading zeros and an expanded zero hextet that should be absorbed into a single clean compression (preferred textual form is 2001:db8::1).
Exam caveat: remember both rules—leading-zero suppression per hextet and a single double-colon for the longest zero sequence. Documentation addresses in 2001:db8::/32 are common in exam stems; treat compression rules the same as for production GUAs.
Operational check in the runbook: rewrite the address to 2001:db8::1, paste into device config or docs, and confirm the IOS/NX-OS or host parser accepts it as equal to the fully expanded form. Avoid double “::” in any municipal addressing spreadsheet.