< draft-ietf-6man-grand-00.txt   draft-ietf-6man-grand-01.txt >
IPv6 Maintenance J. Linkova IPv6 Maintenance J. Linkova
Internet-Draft Google Internet-Draft Google
Updates: 4861 (if approved) March 9, 2020 Updates: 4861 (if approved) July 25, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: September 10, 2020 Expires: January 26, 2021
Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First- Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
Hop Routers Hop Routers
draft-ietf-6man-grand-00 draft-ietf-6man-grand-01
Abstract Abstract
Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
link-layer addresses of neighboring nodes as well as to discover and link-layer addresses of neighboring nodes as well as to discover and
maintain reachability information. This document updates [RFC4861] maintain reachability information. This document updates RFC4861 to
to allow routers to proactively create a Neighbor Cache entry when a allow routers to proactively create a Neighbor Cache entry when a new
new IPv6 address is assigned to a host. It also updates [RFC4862] IPv6 address is assigned to a node. It also updates RFC4861 and
and recommends hosts to send unsolicited Neighbor Advertisements upon recommends nodes to send unsolicited Neighbor Advertisements upon
assigning a new IPv6 address. The proposed change will minimize the assigning a new IPv6 address. The proposed change will minimize the
delay and packet loss when a host initiate connections to off-link delay and packet loss when a node initiate connections to off-link
destination from a new IPv6 address. destination from a new IPv6 address.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on January 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proposed Changes to Neighbor Discovery . . . . . . . . . . . 4 2. Proposed Changes to Neighbor Discovery . . . . . . . . . . . 4
2.1. Hosts Sending Gratuitous Neighbor Advertisements . . . . 4 2.1. Nodes Sending Gratuitous Neighbor Advertisements . . . . 4
2.2. Routers Creating Cache Entries Upon Receiving Unsolicited 2.2. Routers Creating Cache Entries Upon Receiving Unsolicited
Neighbor Advertisements . . . . . . . . . . . . . . . . . 5 Neighbor Advertisements . . . . . . . . . . . . . . . . . 5
3. Avoiding Disruption . . . . . . . . . . . . . . . . . . . . . 6 3. Avoiding Disruption . . . . . . . . . . . . . . . . . . . . . 5
3.1. Neighbor Cache Entry Exists in Any State Other That 3.1. Neighbor Cache Entry Exists in Any State Other That
INCOMPLETE . . . . . . . . . . . . . . . . . . . . . . . 6 INCOMPLETE . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Neighbor Cache Entry Does Not Exist . . . . . . . . . . . 6 3.2. Neighbor Cache Entry is in INCOMPLETE state . . . . . . . 6
3.3. Neighbor Cache Entry is in INCOMPLETE state . . . . . . . 7 3.3. Neighbor Cache Entry Does Not Exist . . . . . . . . . . . 6
4. Modifications to RFC-Mandated Behavior . . . . . . . . . . . 7 3.3.1. The Rightful Owner Is Not Sending Packets From The
Address . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. The Rightful Owner Has Started Sending Packets From
The Address . . . . . . . . . . . . . . . . . . . . . 7
4. Modifications to RFC-Mandated Behavior . . . . . . . . . . . 9
4.1. Modification to RFC4861 Neighbor Discovery for IP version 4.1. Modification to RFC4861 Neighbor Discovery for IP version
6 (IPv6) . . . . . . . . . . . . . . . . . . . . . . . . 7 6 (IPv6) . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Modification to the section 7.2.5 . . . . . . . . . . 7 4.1.1. Modification to the section 7.2.5 . . . . . . . . . . 9
4.1.2. Modification to the section 7.2.6 . . . . . . . . . . 8 4.1.2. Modification to the section 7.2.6 . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Neighbor Discovery state machine defined in [RFC4861] implies The Neighbor Discovery state machine defined in [RFC4861] assumes
that communications between IPv6 nodes are in most cases bi- that communications between IPv6 nodes are in most cases bi-
directional and if a host A is trying to communicate to its neighbor, directional and if a node A is trying to communicate to its neighbor,
host B, the return traffic flows could be expected. So when the host neighbor B, the return traffic flows could be expected. So when the
A starts the address resolution process, the target host would also node A starts the address resolution process, the target node would
create an entry for the host A address in its neighbor cache. That also create an entry for A address in its neighbor cache. That entry
entry will be used for sending the return traffic to the host A. will be used for sending the return traffic to A.
However when a host sends traffic to off-link destinations a However when a host sends traffic to off-link destinations a
different scenario is observed. After receiving a Router different scenario is observed. After receiving a Router
Advertisement the host populates its neighbor cache with the default Advertisement the host populates its neighbor cache with the default
router IPv6 and link-layer addresses and is able to send traffic to router IPv6 and link-layer addresses and is able to send traffic to
off-link destinations. At the same time the router does not have any off-link destinations. At the same time the router does not have any
cache entries for the host global addresses yet and only starts cache entries for the host global addresses yet and only starts
address resolution upon receiving the first packet of the return address resolution upon receiving the first packet of the return
traffic flow. While waiting for the resolution to complete routers traffic flow. While waiting for the resolution to complete routers
only keep a very small number of packets in the queue (as recommended only keep a very small number of packets in the queue, as recommended
in [RFC4861] Section 7.2.2. All subsequent packets arriving before in Section 7.2.2 [RFC4861]. All subsequent packets arriving before
the resolution process finishes are likely to be dropped. It might the resolution process finishes are likely to be dropped. It might
cause user-visible packet loss and performance degradation cause user-visible packet loss and performance degradation.
The detailed problem statement and the various solution approaches The detailed problem statement and the various solution approaches
could be found in [I-D.ietf-v6ops-nd-cache-init]. This document could be found in [I-D.ietf-v6ops-nd-cache-init]. This document
summarizes the proposed neighbor discovery updates to address the summarizes the proposed neighbor discovery updates to address the
issue. issue.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
Node: a device that implements IP, [RFC4861].
Host: any node that is not a router, [RFC4861].
ND: Neighbor Discovery, [RFC4861]. ND: Neighbor Discovery, [RFC4861].
SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862]. SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862].
NS: Neighbor Solicitation, [RFC4861]. NS: Neighbor Solicitation, [RFC4861].
NA: Neighbor Advertisement, [RFC4861]. NA: Neighbor Advertisement, [RFC4861].
RS: Router Solicitation, [RFC4861]. RS: Router Solicitation, [RFC4861].
RA: Router Advertisement, [RFC4861]. RA: Router Advertisement, [RFC4861].
LLA: Link-Layer Address.
SLLA: Source link-layer Address, an option in the ND packets SLLA: Source link-layer Address, an option in the ND packets
containing the link-layer address of the sender of the packet containing the link-layer address of the sender of the packet
[RFC4861]. [RFC4861].
TLLA: Target link-layer Address, an option in the ND packets TLLA: Target link-layer Address, an option in the ND packets
containing the link-layer address of the target [RFC4861]. containing the link-layer address of the target [RFC4861].
GUA: Global Unicast Address [RFC4291]. GUA: Global Unicast Address [RFC4291].
DAD: Duplicate Address Detection, [RFC4862]. DAD: Duplicate Address Detection, [RFC4862].
Optimistic DAD: a modification of DAD, [RFC4429]. Optimistic DAD: a modification of DAD, [RFC4429].
2. Proposed Changes to Neighbor Discovery 2. Proposed Changes to Neighbor Discovery
The following changes are proposed to minimize the delay in creating The following changes are proposed to minimize the delay in creating
new entries in a router neighbor cache new entries in a router neighbor cache
o A host SHOULD send unsolicited NAs upon assigning a new IPv6 o A node sends unsolicited NAs upon assigning a new IPv6 address to
address to its interface. its interface.
o A router SHOULD create a new cache entry upon receiving an o A router creates a new cache entry upon receiving an unsolicited
unsolicited NA from a host. NA from a host.
The following sections discuss these changes in more detail. The following sections discuss these changes in more detail.
2.1. Hosts Sending Gratuitous Neighbor Advertisements 2.1. Nodes Sending Gratuitous Neighbor Advertisements
The section 7.2.6 of [RFC4861] discusses using unsolicited Neighbor The section 7.2.6 of [RFC4861] discusses using unsolicited Neighbor
Advertisement to inform node neighbors of the new link-layer address Advertisement to inform node neighbors of the new link-layer address
quickly. The same mechanism could be used to notify the host quickly. The same mechanism could be used to notify the node
neighbors about the new network-layer address as well: the host can neighbors about the new network-layer address as well: the node can
send gratuitous unsolicited Neighbor Advertisements upon assigning a send gratuitous unsolicited Neighbor Advertisements upon assigning a
new global IPv6 address to its interface. new IPv6 address to its interface.
To minimize the potential disruption in case of duplicate addresses To minimize the potential disruption in case of duplicate addresses
the host SHOULD NOT set the Override flag for a preferred address and the node should not set the Override flag for a preferred address and
MUST NOT set the Override flag if the address is in Optimistic must not set the Override flag if the address is in Optimistic
[RFC4429] state. [RFC4429] state.
As the main purpose of sending unsolicited NAs upon configuring a new As the main purpose of sending unsolicited NAs upon configuring a new
address is to proactively create a Neighbor Cache entry on the first- address is to proactively create a Neighbor Cache entry on the first-
hop routers, the gratuitous NAs SHOULD be sent to all-routers hop routers, the gratuitous NAs are sent to all-routers multicast
multicast address (ff02::2). Limiting the recipients to routers only address (ff02::2). Limiting the recipients to routers only would
would help reduce the multicast noise level. If the link-layer help reduce the multicast noise level. If the link-layer devices are
devices are performing MLD snooping [RFC4541] then those unsolicited performing MLD snooping [RFC4541] then those unsolicited NAs will be
NAs will be only sent to onlink routers instead of being flooded to only sent to onlink routers instead of being flooded to all nodes.
all nodes.
It should be noted that the proposed mechanism does not cause any It should be noted that the proposed mechanism does not cause any
significant increase in the multicast traffic. The additional significant increase in the multicast traffic. The additional
multicast unsolicited NA would proactively create a STALE cache entry multicast unsolicited NA would proactively create a STALE cache entry
on routers as discussed below. When the router receives the return on routers as discussed below. When the router receives the return
traffic flows it does not need to send multicast NSes to the traffic flows it does not need to send multicast NSes to the
solicited node multicast address but would be sending unicast NSes solicited node multicast address but would be sending unicast NSes
instead. Therefore total amount of multicast traffic should not instead. Therefore total amount of multicast traffic should not
increase. increase.
Another option to reduce multicast noises would be sending the
gratuitous NAs as unicast to all router addresses. However such
approach has a serious disadvantage as it requires the host to have
the complete list of routers on link and their link-layaer addresses.
If not all routers are kept in the Default Router list ([RFC4861]
requires a node to keep at least two entries), the unsolicited NA
would reach only subset of routers, not nessesary the routers
receiving the return traffic flows. If the network provides a first-
hop router redundancy traffic flows can be asymmetrical: the host can
send traffic to one router while the return packets enters the
network via another one. So the router the host is using as its
default gateway (and would send a unicast gratuitous NA to) might not
be the router which needs the cache entry to be created. In
addition, a race condition may occur, if RAs from some routers are
delayed and arrive after the unsolicited NA has been sent.
As number of routers on a link is expected to be quite small, hosts
could send the the multicast gratuitous NAs as Ethernet unicasts,
mapping the IPv6 all-routers multicast address ff02::2 to routers
Ethernet unicast addresses as per [RFC6085]. This approach would
also mitigate the risk of informing an on-link attacker about IPv6
addresses assigned to the host. However it has the same
disadvantages as sending unicast NAs: the routers the NA is sent to
might not be ones routing the return traffic.
2.2. Routers Creating Cache Entries Upon Receiving Unsolicited Neighbor 2.2. Routers Creating Cache Entries Upon Receiving Unsolicited Neighbor
Advertisements Advertisements
The section 7.2.5 of [RFC4861] states: "When a valid Neighbor The section 7.2.5 of [RFC4861] states: "When a valid Neighbor
Advertisement is received (either solicited or unsolicited), the Advertisement is received (either solicited or unsolicited), the
Neighbor Cache is searched for the target's entry. If no entry Neighbor Cache is searched for the target's entry. If no entry
exists, the advertisement SHOULD be silently discarded. There is no exists, the advertisement SHOULD be silently discarded. There is no
need to create an entry if none exists, since the recipient has need to create an entry if none exists, since the recipient has
apparently not initiated any communication with the target". apparently not initiated any communication with the target".
The reasoning behind dropping unsolicited Neighbor Advertisements The reasoning behind dropping unsolicited Neighbor Advertisements
("the recipient has apparently not initiated any communication with ("the recipient has apparently not initiated any communication with
the target") is valid for onlink host-to-host communication but, as the target") is valid for onlink host-to-host communication but, as
discussed in [I-D.ietf-v6ops-nd-cache-init] it does not really apply discussed in [I-D.ietf-v6ops-nd-cache-init] it does not really apply
for the scenario when the host is announcing its address to routers. for the scenario when the host is announcing its address to routers.
Therefore it would be beneficial to allow routers creating new Therefore it would be beneficial to allow routers creating new
entries upon receiving an unsolicited Neighbor Advertisement. entries upon receiving an unsolicited Neighbor Advertisement.
This document suggests that routers SHOULD create a new Neighbor This document updates [RFC4861] so that routers create a new Neighbor
Cache entry when receive an unsolicited Neighbor Advertisement. Cache entry upon receiving an unsolicited Neighbor Advertisement.
The proposed changes do not modify routers behaviour specified in
[RFC4861] for the scenario when the corresponding Neighbor Cache
entry already exists.
3. Avoiding Disruption 3. Avoiding Disruption
If hosts following the recommendations in this document are using the If hosts following the recommendations in this document are using the
DAD mechanism defined in [RFC4862], they would send unsolicited NA as DAD mechanism defined in [RFC4862], they would send unsolicited NA as
soon as the address changes the state from tentative to preferred soon as the address changes the state from tentative to preferred
(after its uniqueness has been verified). However hosts willing to (after its uniqueness has been verified). However hosts willing to
minimize network stack configuration delays might be using optimistic minimize network stack configuration delays might be using optimistic
addresses, which means there is a possibility of the address not addresses, which means there is a possibility of the address not
being unique on the link. The section 2.2 of [RFC4429] discusses being unique on the link. The section 2.2 of [RFC4429] discusses
measures to ensure that ND packets from the optimistic address do not measures to ensure that ND packets from the optimistic address do not
override any existing neighbor cache entries as it would cause override any existing neighbor cache entries as it would cause
traffic interruption of the rightful address owner in case of address traffic interruption of the rightful address owner in case of address
conflict. As hosts willing to speed up their network stack conflict. As hosts willing to speed up their network stack
configuration are most likely to be affected by the problem outlined configuration are most likely to be affected by the problem outlined
in this document it seems reasonable for such hosts to advertise in this document it seems reasonable for such hosts to advertise
their optimistic GUAs by sending unsolicited NAs. The main question their optimistic addresses by sending unsolicited NAs. The main
to consider is the potential risk of overriding the cache entry for question to consider is the potential risk of overriding the cache
the rightful address owner if the optimistic address happens to be entry for the rightful address owner if the optimistic address
duplicated. happens to be duplicated.
The following sections are discussing the address collision scenario
when a host sends an unsolicited NA for an address in the Optimistic
state, while another host has the same address assigned already.
3.1. Neighbor Cache Entry Exists in Any State Other That INCOMPLETE 3.1. Neighbor Cache Entry Exists in Any State Other That INCOMPLETE
If the router Neighbor Cache entry for the target address already If the router Neighbor Cache entry for the target address already
exists in any state other than INCOMPLETE, then as per section 7.2.5 exists in any state other than INCOMPLETE, then as per section 7.2.5
of [RFC4861] an unsolicited NA with the Override flag cleared would of [RFC4861] an unsolicited NA with the Override flag cleared would
change the entry state from REACHABLE to STALE but would not update change the entry state from REACHABLE to STALE but would not update
the entry in any other way. Therefore even if the host sends an the entry in any other way. Therefore even if the host sends an
unsolicited NA from the its Optimistic address the router cache entry unsolicited NA from the its Optimistic address the router cache entry
would not be updated with the new Link-Layer address and no impact to would not be updated with the new Link-Layer address and no impact to
the traffic for the rightful address owner is expected. the traffic for the rightful address owner is expected.
3.2. Neighbor Cache Entry Does Not Exist 3.2. Neighbor Cache Entry is in INCOMPLETE state
If there is no entry then it would be created/updated with the
supplied LLA and its state set to STALE. In that case as soon as the
entry is used for sending traffic to the host, the entry state will
be changed to DELAY, then PROBE and the unicast NS will be send. If
the DAD process has already failed, the host with the duplicated
address would not respond to the unicast NSes. The router will then
send multicast NSes which would reach the rightful owner of the
address and its LLA will be added to the routerND cache. So in the
scenario when the rightful owner does not use the address for
communication then it might be a short (a few seconds) period of time
when the data packets sent from the outside could reach the host with
the optimistic address. However it seems likely that hosts using
Optimistic DAD would start sending/receiving traffic right away, so
the first return packet would trigger the NUD process and rewrite the
cache.
3.3. Neighbor Cache Entry is in INCOMPLETE state
Another corner case is the INCOMPLETE cache entry for the address. Another corner case is the INCOMPLETE cache entry for the address.
If the host sends an unsolicited NA from the Optimistic address it If the host sends an unsolicited NA from the Optimistic address it
would update the entry with the host LLA and set the entry to the would update the entry with the host link-layer address and set the
STALE state. As the INCOMPLETE entry means that the router has entry to the STALE state. As the INCOMPLETE entry means that the
started the ND process for the address and the multicast NS has been router has started the ND process for the address and the multicast
sent, the rightful owner is expected to reply with solicited NA with NS has been sent, the rightful owner is expected to reply with
the Override flag set. Upon receiving a solicited NA with the solicited NA with the Override flag set. Upon receiving a solicited
Override flag the cache entry will be updated with the TLLA supplied NA with the Override flag the cache entry will be updated with the
and (as the NA has the Solicited flag set), the entry state will be TLLA supplied and (as the NA has the Solicited flag set), the entry
set to REACHABLE. It would recover the cache entry and set the LLA state will be set to REACHABLE. It would recover the cache entry and
to the one of the rightful owner. The only potential impact would be set the link-layer address to the one of the rightful owner. The
for packets arriving to the router after the unsolicited NA from the only potential impact would be for packets arriving to the router
host but before the rightful owner responded with the solicited NA. after the unsolicited NA from the host but before the rightful owner
Those packets would be sent to the host with the optimistic address responded with the solicited NA. Those packets would be sent to the
instead of its rightful owner. However those packets would have been host with the optimistic address instead of its rightful owner.
dropped anyway as until the solicited NA is received the router can However those packets would have been dropped anyway as until the
not send the traffic. solicited NA is received the router can not send the traffic.
3.3. Neighbor Cache Entry Does Not Exist
There are two distinct scenarios which can lead to the situation when
the router does not have a NC entry for the IPv6 address:
1. The rightful owner of the address has not been using it for
communication.
2. The rightful owner just started sending packets from that address
but the router has not received any return traffic yet.
The impact on the rightful owner's traffic flows would be different
in those cases.
3.3.1. The Rightful Owner Is Not Sending Packets From The Address
In this scenario the following events are expected to happen:
1. The host configures the address and sets its state to Optimistic.
2. The host sends an unsolicited NA with the Override flag set to
zero and starts sending traffic from the Optimistic address.
3. The router creates a STALE entry for the address and the host
link-layer address.
4. The host starts DAD and detects the address duplication.
5. The router receives the return traffic for the duplicated
address. As the NC entry is STALE it sends traffic using that
entry, changes it to DELAY and wait up to DELAY_FIRST_PROBE_TIME
([RFC4861]) seconds.
6. The router changes the NC entry state to PROBE and sends up to
MAX_UNICAST_SOLICIT ([RFC4861]) unicast NSes separated by
RetransTimer milliseconds ([RFC4861]) to the host link-layer
address.
7. As the host has detected the address conflict already it does not
respond to the unicast NSes.
8. The router sends a multicast NS to the solicited node multicast
address, the rightful owner responds and the router NC entry is
updated with the rightful owner link-local address.
The rightful owner is not experiencing any disruption as it does not
send/receive any traffic. If after step 7 the router keeps receiving
any return traffic for communication initiated at step 2, those
packets would be forwarded to the rightful owner. However the same
behaviour would be observed if changes proposed in this document are
implemented: if the host starts sending packets from its Optimistic
address but then changed the address state to Duplicated, almost all
return traffic would be forwarded to the rightful owner of the said
address. Therefore it's safe to conclude that the proposed changes
do not cause any disruption for the rightful owner.
3.3.2. The Rightful Owner Has Started Sending Packets From The Address
In this scenario the following events are happening:
1. The rightful owner starts sending traffic from the address (e.g.
the address has just been configured or has not been recently
used).
2. The host configures the address and sets its state to Optimistic.
3. The host sends an unsolicited NA with the Override flag set to
zero and starts sending traffic from the Optimistic address.
4. The router creates a STALE entry for the address and the host
link-layer address.
5. The host starts DAD and detects the address duplication.
6. The router receives the return traffic flows for both the
rightful owner of the duplicated address and the new host. As
the NC entry is STALE it sends traffic using that entry, changes
it to DELAY and wait up to DELAY_FIRST_PROBE_TIME ([RFC4861])
seconds.
7. The router changes the NC entry state to PROBE and sends up to
MAX_UNICAST_SOLICIT ([RFC4861]) unicast NSes separated by
RetransTimer milliseconds ([RFC4861]) to the host link-layer
address.
8. As the host has detected the address conflict already it does not
respond to the unicast NSes.
9. The router sends a multicast NS to the solicited node multicast
address, the rightful owner responds and the router NC entry is
updated with the rightful owner link-local address.
As a result the traffic for the address rightful owner would be sent
to the host with the duplicated address instead. The duration of the
disruption can be estimated as DELAY_FIRST_PROBE_TIME*1000 +
(MAX_UNICAST_SOLICIT - 1)*RetransTimer milliseconds. As per the
constants defined in Section 10 of [RFC4861] this interval is equal
to 5*1000 + (3 - 1)*1000 = 7000ms or 7 seconds.
However it should be noted that the probability of such scenario is
rather low as it would require the following things to happen almost
simultaneously (within tens of milliseconds):
o One host starts using a new IPv6 address and sending traffic.
o Another host configures the same IPv6 address in Optimistic mode
before the router receives the return traffic for the first host.
4. Modifications to RFC-Mandated Behavior 4. Modifications to RFC-Mandated Behavior
All normative text in this memo is contained in this section. All normative text in this memo is contained in this section.
4.1. Modification to RFC4861 Neighbor Discovery for IP version 6 (IPv6) 4.1. Modification to RFC4861 Neighbor Discovery for IP version 6 (IPv6)
4.1.1. Modification to the section 7.2.5 4.1.1. Modification to the section 7.2.5
This document proposes the following changes to the section 7.2.5 of This document proposes the following changes to the section 7.2.5 of
skipping to change at page 8, line 21 skipping to change at page 9, line 50
------------------------------------------------------------------ ------------------------------------------------------------------
4.1.2. Modification to the section 7.2.6 4.1.2. Modification to the section 7.2.6
This document proposes the following changes to the section 7.2.6 of This document proposes the following changes to the section 7.2.6 of
[RFC4861]: [RFC4861]:
OLD TEXT: OLD TEXT:
In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT Also, a node belonging to an anycast address MAY multicast
unsolicited Neighbor Advertisement messages to the all-nodes unsolicited Neighbor Advertisements for the anycast address when the
multicast address. These advertisements MUST be separated by at node's link-layer address changes.
least RetransTimer seconds.
NEW TEXT: NEW TEXT:
In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT Also, a node belonging to an anycast address MAY multicast
unsolicited Neighbor Advertisement messages to the all-nodes unsolicited Neighbor Advertisements for the anycast address when the
multicast address. These advertisements MUST be separated by at node's link-layer address changes.
least RetransTimer seconds.
A host may also wish to notify its first-hop routers when it A node may also wish to notify its first-hop routers when it
configures a new global IPv6 address so the routers can proactively configures a new global IPv6 address so the routers can proactively
populate their neighbor caches with the corresponding entries. In populate their neighbor caches with the corresponding entries. In
such cases a host SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT such cases a node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT
Neighbor Advertisement messages. If the address is preferred then Neighbor Advertisement messages. If the address is preferred then
the Override flag SHOULD NOT be set. If the address is in the the Override flag SHOULD NOT be set. If the address is in the
Optimistic state then the Override flag MUST NOT be set. The Optimistic state then the Override flag MUST NOT be set. The
destination address SHOULD be set to the all-routers multicast destination address SHOULD be set to the all-routers multicast
address. These advertisements MUST be separated by at least address. These advertisements MUST be separated by at least
RetransTimer seconds. The first advertisement SHOULD be sent as soon RetransTimer seconds. The first advertisement SHOULD be sent as soon
as one of the following events happens: as one of the following events happens:
o if Optimistic DAD [RFC4429] is used: a new Optimistic GUA is o if Optimistic DAD [RFC4429] is used: a new Optimistic address is
assigned to the host interface. assigned to the node interface.
o if Optimistic DAD is not used: a GUA changes the state from o if Optimistic DAD is not used: an address changes the state from
tentative to preferred. tentative to preferred.
------------------------------------------------------------------ ------------------------------------------------------------------
5. IANA Considerations 5. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
6. Security Considerations 6. Security Considerations
skipping to change at page 9, line 37 skipping to change at page 11, line 16
an on-link attacker about IPv6 addresses assigned to the host. an on-link attacker about IPv6 addresses assigned to the host.
However hiding information about the specific IPv6 address should not However hiding information about the specific IPv6 address should not
be considered a security measure as such information is usually be considered a security measure as such information is usually
disclosed via DAD to all nodes anyway. Network administrators can disclosed via DAD to all nodes anyway. Network administrators can
also mitigate this issue by enabling MLD snooping on the link-layer also mitigate this issue by enabling MLD snooping on the link-layer
devices to prevent IPv6 link-local multicast packets being flooded to devices to prevent IPv6 link-local multicast packets being flooded to
all onlink nodes. If peer-to-peer onlink communications are not all onlink nodes. If peer-to-peer onlink communications are not
desirable for the given network segment they should be prevented by desirable for the given network segment they should be prevented by
proper layer2 security mechanisms. Therefore the risk of allowing proper layer2 security mechanisms. Therefore the risk of allowing
hosts to send unsolicited Neighbor Advertisements to all-routers hosts to send unsolicited Neighbor Advertisements to all-routers
multicast address is low. Should the issue needs to be mitigated on multicast address is low.
the host level, the host can send unsolicited NAs to its routers
Ethernet unicast addresses as described in Section 2.1.
It should be noted that the proposed mechanism allows hosts to It should be noted that the proposed mechanism allows hosts to
proactively inform their routers about global IPv6 addresses existing proactively inform their routers about global IPv6 addresses existing
on-link. Routers could use that information to distinguish between on-link. Routers could use that information to distinguish between
used and unused addresses to mitigate ND cache exhaustion DoS attacks used and unused addresses to mitigate ND cache exhaustion DoS attacks
described in Section 4.3.2 [RFC3756] and [RFC6583]. described in Section 4.3.2 [RFC3756] and [RFC6583].
7. Acknowledgements 7. Acknowledgements
Thanks to the following people (in alphabetical order) for their Thanks to the following people (in alphabetical order) for their
skipping to change at page 10, line 43 skipping to change at page 12, line 19
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-v6ops-nd-cache-init] [I-D.ietf-v6ops-nd-cache-init]
Linkova, J., "Neighbor Cache Entries on First-Hop Routers: Linkova, J., "Neighbor Cache Entries on First-Hop Routers:
Operational Considerations", draft-ietf-v6ops-nd-cache- Operational Considerations", draft-ietf-v6ops-nd-cache-
init-01 (work in progress), December 2019. init-03 (work in progress), July 2020.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004, RFC 3756, DOI 10.17487/RFC3756, May 2004,
<https://www.rfc-editor.org/info/rfc3756>. <https://www.rfc-editor.org/info/rfc3756>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>. <https://www.rfc-editor.org/info/rfc4541>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, DOI 10.17487/RFC6085, January 2011,
<https://www.rfc-editor.org/info/rfc6085>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012, DOI 10.17487/RFC6583, March 2012,
<https://www.rfc-editor.org/info/rfc6583>. <https://www.rfc-editor.org/info/rfc6583>.
Author's Address Author's Address
Jen Linkova Jen Linkova
Google Google
1 Darling Island Rd 1 Darling Island Rd
 End of changes. 37 change blocks. 
143 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/