From ea70c965920d419b0bc7e2a5cd5e7bc0aac6cbee Mon Sep 17 00:00:00 2001 From: Brian E Carpenter Date: Wed, 23 Nov 2022 16:07:55 +1300 Subject: [PATCH] Bug fixes --- 1. Introduction and Foreword/Acknowledgments.md | 12 ++++++++++++ 2. IPv6 Basic Technology/Address resolution.md | 4 ++-- 2. IPv6 Basic Technology/Managed configuration.md | 12 +++++++++--- 3 files changed, 23 insertions(+), 5 deletions(-) create mode 100644 1. Introduction and Foreword/Acknowledgments.md diff --git a/1. Introduction and Foreword/Acknowledgments.md b/1. Introduction and Foreword/Acknowledgments.md new file mode 100644 index 0000000..d4545b8 --- /dev/null +++ b/1. Introduction and Foreword/Acknowledgments.md @@ -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) + diff --git a/2. IPv6 Basic Technology/Address resolution.md b/2. IPv6 Basic Technology/Address resolution.md index 1af385c..02addee 100644 --- a/2. IPv6 Basic Technology/Address resolution.md +++ b/2. IPv6 Basic Technology/Address resolution.md @@ -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). diff --git a/2. IPv6 Basic Technology/Managed configuration.md b/2. IPv6 Basic Technology/Managed configuration.md index 1dea3f8..da036b6 100644 --- a/2. IPv6 Basic Technology/Managed configuration.md +++ b/2. IPv6 Basic Technology/Managed configuration.md @@ -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. ### [Previous](Auto-configuration.md) [Next](DNS.md) [Chapter Contents](2.%20IPv6%20Basic%20Technology.md)