IPv4 アドレスは 32 bit なので，全体が本の幅，ブログなどのテキストの幅にうまくおさめることができます． それは，PowerPoint のようなツールをつかって書くばあいでも，“ASCII で” 書くときも同様です． RFC には通常，つぎのような ASCII 形式で記述されます．
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
しかし，IPv6 になるとこんなにうまくはいきません． RFC に書くには 32 bit ずつ行をかえて書くしかないとおもえます． 1 行のながさをもっとながくしてよいときでも，128 bit ぶんすべてを 1 行に書くには，なにかくふうが必要です． それは “ASCII で” 書くときでも PowerPoint などで書くときでも同様です． 一部をちぢめて書くとか，省略するとかしないと，おさまりません． もっとらくに書く方法はないものでしょうか?
IPv6 の RFC には “ASCII で” 書かれたつぎのような図が記述されています．
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
このばあいはアドレスそのものの構造を書く必要がないので，32 bit で改行しても問題はすくないわけです． しかし，たとえばプレフィクス，サブネット ID，インタフェース ID によって構成されるユニキャスト・アドレスの構造を書こうとすると，これらを横にならべて書きたくなります． アドレスの種類によっては 4 bit ずつくぎられていることもあって (たとえばマルチキャスト・アドレス)，全体を比例的に 1 行におさめて書くと 4 bit のわくのなかにはなにも書けなくなります．
キーワード: IPv6, インターネット・プロトコル
