diff --git a/docs/books/admin_guide/12-network.md b/docs/books/admin_guide/12-network.md index ddfbaaa6b1..25374930eb 100644 --- a/docs/books/admin_guide/12-network.md +++ b/docs/books/admin_guide/12-network.md @@ -177,7 +177,7 @@ As mentioned earlier, subnet masks divide IPv4 addresses into two parts: network * Network prefix - It is equivalent to the network bits in an IPv4 address. According to the subnet mask, occupy "n" bits. * Interface ID - It is equivalent to the host bits in an IPv4 address. According to the subnet mask, occupy "128-n" bits. -For example **2001:0db8:130F:0000:0000:09C0:876A:130B/64**： +For example **2001:0db8:130F:0000:0000:09C0:876A:130B/64**: ``` Network prefix @@ -228,9 +228,9 @@ The actual length of IPv4 header = The value of the IHL field * 4 **Header Checksum**: This field will be recalculated every time the datagram passes through the router, mainly due to the decreasing TTL field causing changes in the header. This field only verifies the header (excluding the data part). If other fields remain unchanged and only the TTL changes, the checksum will be updated to a new value (non-zero) to ensure that the header has not been tampered with or damaged during transmission. -**Source address**: IPv4 address of the datagram sender +**Source Address**: IPv4 address of the datagram sender -**Destination address**: IPv4 address of the datagram receiver +**Destination Address**: IPv4 address of the datagram receiver **Options**: Optional field, with a length range of 0-40 bytes. It is only used when the IHL is greater than 5. The length of this field must be an integer multiple of 4 bytes (if the length is less than 4 bytes, use the **padding** field for padding). @@ -246,7 +246,7 @@ IPv6 datagrams consist of three parts: * Extension Header * Upper Layer Protocol Data Unit -In some books, the Extended Header and Upper Layer Protocol Data Unit are collectively referred to as the **Payload**. +In some books, the Extendsion Header and Upper Layer Protocol Data Unit are collectively referred to as the **Payload**. ![](./images/IPv6-basic-header.png) @@ -258,9 +258,9 @@ The fixed length of the Basic Header is 40 bytes and it is fixed to 8 fields: **Flow Label**: This IPv6 new field is used to control packet flow. A non-zero value in this field means that the packet should be treated specially; i.e., the packet should not be sent through different routes to reach the destination but rather use the same path. An advantage to this is that the receiving end doesn’t have to reorder the package, thus speeding the process. This field helps avoid reordering data packets and is specifically designed for streaming media/live media. -**Payload Length**: Indicate the size of the payload. This field can only represent a Payload with a maximum length of 65535 bytes. In case the length of the payload is greater than 65535 bytes, then the payload length field will be set to 0 and the jumbo payload option is used in the Hop-by-Hop Options Extension Header. +**Payload Length**: Indicate the size of the payload. This field can only represent a Payload with a maximum length of 65535 bytes. In case the length of the payload is greater than 65535 bytes, then the Payload Length field will be set to 0 and the jumbo payload option is used in the Hop-by-Hop Options Extension Header. -**Next Header**: Used to indicate the type of packet header after the basic header. If there is a first extension header, it represents the type of the first extension header. Otherwise, it represents the protocol type used by the upper layer, such as 6 (TCP) and 17 (UDP). +**Next Header**: Used to indicate the type of packet header after the Basic Header. If there is a first Extension Header, it represents the type of the first Extension Header. Otherwise, it represents the protocol type used by the upper layer, such as 6 (TCP) and 17 (UDP). **Hop Limit**: This field is equivalent to Time To Live (TTL) in IPv4 datagrams. @@ -272,50 +272,86 @@ The fixed length of the Basic Header is 40 bytes and it is fixed to 8 fields: In IPv4 datagrams, the IPv4 header contains optional fields such as Options, which include Security, Timestamp, Record Route, etc. These Options can expand the length of the IPv4 header from 20 bytes to 60 bytes. During the forwarding process, handling IPv4 datagrams carrying these Options can consume a significant amount of device resources, so it is rarely used in practice. -IPv6 removes these Options from the IPv6 basic header and places them in the extension header, which is placed between the IPv6 Basic Header and the Upper Layer Protocol Data Unit. +IPv6 removes these Options from the IPv6 Basic Header and places them in the Extension Header, which is placed between the IPv6 Basic Header and the Upper Layer Protocol Data Unit. -An IPv6 packet can contain 0, 1, or multiple extension headers, which are only added by the sender when special processing is required by the device or destination node. +An IPv6 packet can contain 0, 1, or multiple Extension Headers, which are only added by the sender when special processing is required by the device or destination node. -Unlike the IPv4 Options field (which can be extended up to 40 bytes and requires continuous storage), the IPv6 Extension Header adopts a chain structure and has no fixed length limit, making it more scalable in the future. Its 8 byte alignment mechanism is implemented through the Next Header field, which ensures processing efficiency and avoids fragmentation overhead. +Unlike the IPv4 Options field (which can be extended up to 40 bytes and requires continuous storage), the IPv6 Extension Header adopts a chain structure and has no fixed length limit, making it more scalable in the future. Its 8 byte alignment mechanism is implemented through the Next Header field, which ensures processing efficiency and avoids fragment overhead. **Next Header**: This field has the same function as the Next Header field in the Basic Header. -**Extension Header Len**: Indicate the length of the extension header (excluding the length of the Next Header). +**Extension Header Len**: Indicate the length of the Extension Header (excluding the length of the Next Header). -**Extension Head Data**: The content of the Extension Header is a combination of a series of option fields and padding fields. +**Extension Header Data**: The content of the Extension Header is a combination of a series of Option fields and Padding fields. Currently, RFC defines the following types of Extension Headers: -* Hop-by-Hop Options header (Next Header Field Value is 0) - Must be handled by all routers in the path. -* Destination Options header (Next Header Field Value is 60) - Only processed by the destination node. -* Routing header (Next Header Field Value is 43) - This Extension Header is similar to the Loose Source and Record Route options in IPv4. -* Fragment header (Next Header Field Value is 44) - Like IPv4 packets, the length of IPv6 packets to be forwarded cannot exceed the maximum transmission unit (MTU). When the packet length exceeds the MTU, the packet needs to be fragmented. In IPv6, the Fragment header is used by an IPv6 source node to send a packet larger than the MTU. -* Authentication header (Next Header Field Value is 51) - IPSec uses this header to provide data origin authentication, data integrity check, and packet anti-replay functions. It also protects some fields in the IPv6 basic header. -* Encapsulating Security Payload header (Next Header Field Value is 50) - This header provides the same functions as the Authentication header plus IPv6 packet encryption. +* Hop-by-Hop Options Header (Next Header field value is 0) - Must be handled by all routers in the path. +* Destination Options Header (Next Header field value is 60) - Only processed by the destination node. +* Routing Header (Next Header field value is 43) - This Extension Header is similar to the Loose Source and Record Route options in IPv4. +* Fragment Header (Next Header field value is 44) - Like IPv4 packets, the length of IPv6 packets to be forwarded cannot exceed the maximum transmission unit (MTU). When the packet length exceeds the MTU, the packet needs to be fragmented. In IPv6, the Fragment header is used by an IPv6 source node to send a packet larger than the MTU. +* Authentication Header (Next Header field value is 51) - IPSec uses this header to provide data origin authentication, data integrity check, and packet anti-replay functions. It also protects some fields in the IPv6 Basic Header. +* Encapsulating Security Payload Header (Next Header field value is 50) - This header provides the same functions as the Authentication Header plus IPv6 packet encryption. -RFC specifies that when multiple extension headers are used in the same datagram, it is recommended that these headers appear in the following order: +RFC specifies that when multiple Extension Headers are used in the same datagram, it is recommended that these headers appear in the following order: 1. IPv6 Basic Header -2. Hop-by-Hop Options header -3. Destination Options header -4. Routing header -5. Fragment header -6. Authentication header -7. Encapsulating Security Payload header -8. Destination Options header -9. Upper-layer protocol header +2. Hop-by-Hop Options Header +3. Destination Options Header +4. Routing Header +5. Fragment Header +6. Authentication Header +7. Encapsulating Security Payload Header +8. Destination Options Header +9. Upper-layer Protocol Header -Except for the Destination Option Header which may appear once or twice (once before the Routing Extension header and once before the Upper-layer protocol header), all other extension headers can only appear once. +Except for the Destination Option Header which may appear once or twice (once before the Routing Extension Header and once before the Upper-layer Protocol Header), all other Extension Headers can only appear once. -### DNS Domain +### DNS -Client machines can be part of a DNS (**Domain Name System**, e.g., `mydomain.lan`) domain. +**DNS (Domain Name System)**: The TCP/IP protocol family provides the ability to connect to devices through IP addresses, but it is quite difficult for users to remember the IP address of a device. Therefore, a string based host naming mechanism has been specifically designed, where these hostnames correspond to the IP address. There needs to be a conversion and query mechanism between IP addresses and hostnames, and the system that provides this mechanism is the Domain Name System (DNS). The process of "translating" a domain name into an IP address is called **Domain Name Resolution**. -The fully qualified machine name (**FQDN**) becomes `pc-rocky.mydomain.lan`. +Please note the difference between hostname and domain name: -A set of computers can be grouped into a logical, name-resolving, set called a DNS domain. A DNS domain is not, of course, limited to a single physical network. +* Hostname - It is used to uniquely identify devices within a LAN (Local Area Network) or as part of a domain name (for example `docs`) +* Domain name - Used to uniquely identify devices on the WAN (Wide Area Network). For example `docs.rockylinux.org`, where `rockylinux.org` is the Domain name of the Domain -In order for a computer to be part of a DNS domain, it must be given a DNS suffix (here `mydomain.lan`) as well as servers that it can query. +!!! tip + + Domain does not represent a specific host + +**Q: Why is DNS needed?** + +In the early days of the Internet, to remember the correspondence between hostnames and IP addresses, all the correspondence had to be written into a file, and users had to manually maintain the file content. With the vigorous development of the Internet, the main problems that need to be solved are: + +* A single file only takes effect on the computer currently in use +* Manually maintaining file content is becoming increasingly difficult + +To solve the problems that emerged, people developed DNS, whose advantages are: + +* Distributed - DNS servers available for users all over the world +* Hierarchical management - Divide the hierarchy for easier management. As shown in the following figure: + + ![](./images/domain.png) + +For the root domain, it is commonly referred to as having thirteen root domain servers worldwide. A more standardized expression: + +> "The global DNS root server system is logically architected around 13 canonical endpoints (a.root-servers.net through m.root-servers.net), a design rooted in historical protocol constraints. Physically, these endpoints are implemented through over 1,500 anycast-instanced servers distributed worldwide, operated by 13 independent organizations under ICANN/IANA coordination." + +For `docs.rockylinux.org.`: + +* **Root Domain** - It refers to a point (`.`). +* **First-level domain** - It refers to the string `org`. There is a lot of controversy about the division of first-level domains, for example, some document materials classify `.org` or `org.` as first-level domains. +* **Second-level domain** - It refers to the string `rockylinux`. There is a lot of controversy about the division of second-level domains, for example, some document materials `rockylinux.org.` or `.rockylinux.org.` as second-level domains. +* **hostname** - It refers to the string `docs`. + +**FQDN (Fully Qualified Domain Name)**: A complete domain name consisting of a hostname and various levels of domains. According to the RFC standard (RFC 1034, RFC 2181, RFC 8499), the root domain at the end is industry standard (for example `docs.rockylinux.org.`). In the configuration files of some DNS software, a standard FQDN must be entered, but the root domain can be ignored when accessing certain network resources (for example, when a user visits `https://docs.rockylinux.org`, the browser will automatically add a dot to the end). +**Domain name**: A structure that connects domains at all levels and starts with a hostname. +**Zone**: Represents a contiguous portion of the DNS namespace managed by a specific authoritative server, which stores all the FQDN resolution records (such as A, MX, etc.) within that scope. + +!!! tip + + Generally speaking, "FQDN" is more effective in expressing the meaning of an author's document than "domain name", as readers from different industries have different understandings of the term "domain name". For example, for `rockylinux.org`, some readers may interpret it as a domain name, but this is actually incorrect. Strictly speaking, this should be referred to as a domain (rather than a domain name). Therefore, in order to enhance rigor, readers are requested to strictly distinguish the meanings of domains and domain names. ### Reminder of the OSI model diff --git a/docs/books/admin_guide/images/domain.png b/docs/books/admin_guide/images/domain.png new file mode 100644 index 0000000000..6686c93655 Binary files /dev/null and b/docs/books/admin_guide/images/domain.png differ