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

Bug fixes

Browse Source
This commit is contained in:
Brian E Carpenter
2022-11-23 16:07:55 +13:00
parent 835bc716e5
commit ea70c96592
3 changed files with 23 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
1. Introduction and Foreword/Acknowledgments.md
+12
View File
@@ -0,0 +1,12 @@
## Acknowledgments
Contributors via GitHub may be identified at [Contributors](https://github.com/becarpenter/book6/graphs/contributors).
Other contributors (mainly via email) include:
- Tim Chown
- Jyrki Soini
(with apologies to those forgotten)
2. IPv6 Basic Technology/Address resolution.md
+2 -2
View File
@@ -2,9 +2,9 @@
When an IPv6 node "A" becomes aware of the IPv6 address of another node "B", and requires to send a packet to B, it must first determine whether B is directly connected to one of the same links as A. If not, it will need to send the packet to a router (see [Routing](Routing.md)). This is known as "on-link determination". The simplest case is when the address of B is a link local address as described in [Addresses](Addresses.md). In that case, it is necessarily on-link. In cases where B has a routeable address, A can determine whether it is on-link by consulting information received from Router Advertisement (RA) messages. This process is well described in [RFC4861](https://www.rfc-editor.org/info/rfc4861), so is not repeated here.
When A has determined that B's address is on-link, and in the process determined which interface that link is connected to, it starts address resolution, also known as neighbor discovery (ND). It multicasts a Neighbor Solicitation message via that interface to the link local all-nodes multicast address, which is ```ff02::1```. Neighbor Solicitation is a specific form of ICMPv6 message; ICMPv6 is defined in [RFC8200](https://www.rfc-editor.org/info/rfc8200). Since this is a link local multicast, such messages never escape the local link.
When A has determined that B's address is on-link, and in the process determined which interface that link is connected to, it starts address resolution, also known as neighbor discovery (ND). It multicasts a Neighbor Solicitation message via that interface to the relevant link local multicast address, which is known as the solicited-node multicast address (defined in {{RFC4291}} but explained in {{RFC4861}}). Neighbor Solicitation is a specific form of ICMPv6 message; ICMPv6 is defined in [RFC8200](https://www.rfc-editor.org/info/rfc8200). Since this is a link local multicast, such messages never escape the local link.
All IPv6 nodes **MUST** monitor multicasts sent to ```ff02::1```. When B receives the Neighbor Solicitation from A, it replies with a Neighbor Advertisement ICMPv6 message, sent unicast to A's link local address. A will then decode that message to obtain B's Layer 2 address (typically an IEEE MAC address), and will record the information in its Neighbor Cache for future use. At that point, A has all the information it needs to send packets to B.
All IPv6 nodes **MUST** monitor multicasts sent to the solicited-node multicast address. When B receives the Neighbor Solicitation from A, it replies with a Neighbor Advertisement ICMPv6 message, sent unicast to A's link local address. A will then decode that message to obtain B's Layer 2 address (typically an IEEE MAC address), and will record the information in its Neighbor Cache for future use. At that point, A has all the information it needs to send packets to B.
These are the essentials of address resolution; readers who want more detail should consult [RFC4861](https://www.rfc-editor.org/info/rfc4861).
2. IPv6 Basic Technology/Managed configuration.md
+9 -3
View File
@@ -29,15 +29,21 @@ DHCPv6 options include:
- Authentication Option
- Server Unicast Option
- Status Code Option
- DNS Recursive Name Server Option
- Domain Search List Option
- Identity Association for Prefix Delegation Option
- IA Prefix Option
Readers who want more details should consult [RFC8415](https://www.rfc-editor.org/info/rfc8415) directly.
Be warned, this is a very complex RFC of about 150 pages. Also, the full lists of defined messages and options may be found at [IANA](https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml), with citations of the relevant RFCs.
A missing DHCPv6 option is DNS server information; this is only available
via RAs, as mentioned in the previous section. No consensus has
been reached in the IETF to also supply this information via DHCPv6.
A missing DHCPv6 option is information about default routers; this is only available
via RAs, as described in the previous sections. No consensus has
been reached in the IETF to also supply this information via DHCPv6. In fact,
DHCPv6 is designed to supplement router advertisement information and is not intended
to work on a subnet that has no router. Therefore DHCPv6 assigned addresses effectively
have prefix length /128, and clients need to combine that information with RA information
to communicate with other on-link hosts.
<!-- Link lines generated automatically; do not delete -->
### [<ins>Previous</ins>](Auto-configuration.md) [<ins>Next</ins>](DNS.md) [<ins>Chapter Contents</ins>](2.%20IPv6%20Basic%20Technology.md)