mirror/becarpenter-book6
1
0
Fork 0
mirror of https://github.com/becarpenter/book6.git synced 2024-05-07 02:54:53 +00:00
Code Releases Activity

Non RFC3849 addresses irritate me, some addition for RFC5952

Browse Source 
My editor also delete some trailing withe spaces.
This commit is contained in:
Jens Link
2023-07-15 10:04:43 +02:00
parent e57b41cfcd
commit 9fe1b9c247
1 changed files with 17 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
2. IPv6 Basic Technology/Addresses.md
View File

@ -8,38 +8,45 @@ The IPv6 addressing architecture is defined by [RFC4291](http://www.rfc-editor.o
We'll first introduce the notation for writing down IPv6 addresses, and then use that notation to explain the main features.
The only feasible way to write down 128 bit addresses is in hexadecimal. There's no doubt this is less convenient than the decimal notation used for IPv4, but that's unavoidable. Despite what you may see in older RFCs, [the recommendation today](https://www.rfc-editor.org/info/rfc5952) is to use lower-case letters for hexadecimal. Thus a basic example of the notation is:
The only feasible way to write down 128 bit addresses is in hexadecimal. There's
no doubt this is less convenient than the decimal notation used for IPv4, but
that's unavoidable. Despite what you may see in older RFCs, [the recommendation
by RFC5952 today](https://www.rfc-editor.org/info/rfc5952) is to use lower-case letters for hexadecimal. Thus a basic example of the notation is:
~~~
6789:abcd:ef01:2345:6789:abcd:ef01:2345
2001:0db8:ef01:2345:6789:abcd:ef01:2345
~~~
In that example, there are 8 groups of 4 hexadecimal digits, to specify all 128 bits in 16 bit chunks. In conventional hexadecimal notation, that would be `0x6789abcdef0123456789abcdef012345`. The colons (':') are there to help the reader.
In that example, there are 8 groups of 4 hexadecimal digits, to specify all 128
bits in 16 bit chunks. In conventional hexadecimal notation, that would be
`0x20010db8ef0123456789abcdef012345`. The colons (':') are there to help the reader.
In each chunk of 16 bits, leading zeros are dropped, so we write:
~~~
6789:abcd:ef01:45:6789:abcd:ef01:2345
2001:db8:ef01:45:6789:abcd:ef01:2345
~~~
**not**:
~~~
6789:abcd:ef01:0045:6789:abcd:ef01:2345
2001:0db8:ef01:0045:6789:abcd:ef01:2345
~~~
There is often a run of zero bytes in an IPv6 address. One such run can be replaced by a double colon ('::') so that we write:
~~~
6789:abcd::6789:abcd:ef01:2345
2001:db8::6789:abcd:ef01:2345
~~~
**not**:
~~~
6789:abcd:0:0:6789:abcd:ef01:2345
2001:db8:0:0:6789:abcd:ef01:2345
~~~
The idea is that IPv6 addresses should be cut-and-pasted in almost all cases. If you ever do have to enter one manually, a great deal of care is needed.
The idea is that IPv6 addresses should be cut-and-pasted in almost all cases. If
you ever do have to enter one manually, a great deal of care is needed. Note
that not all implementations will follow RFC9592.
The choice of ':' as the separator is annoying in one particular case - when including an IPv6 address in a Web URL, where a colon has another meaning. That's why IPv6 addresses in URLs are in square brackets like this: