jiebi/CodeConvo huggingface dataset:
of DHCPv6 can't be considered "suitable"&#151;not all hosts can actually use it. <ins> Note: there can be layer two networks where neighbor discovery is not supported and therefore we cannot set the 'L' bit, but could set the 'A' bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </ins> A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is received in response which contains a prefix information option
Local IPv6 Unicast Addresses (RFC4193) are randomly allocated prefixes.  A stub router MUST allocate a single ULA Site Prefix for use in providing on-link prefixes to the stub network and the <del> adjacent infrastructure link, as needed. </del> <ins> adjacent infrastructure link as described in state-begin-advertising. </ins> Any ULA Link Prefixes allocated by a stub router SHOULD be maintained across reboots, and SHOULD remain stable over time.  (TBD: mention
the interface.  This prefix has a valid and preferred lifetime of STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix <del> Information Option (PIO).  In the PIO, the A (autonomous configuration) flag RFC4861 MUST be set and the L (on-link) flag SHOULD be set.  The exception cases where the L flag can be cleared is where the specific link-layer technology and/or configuration requires clearing the L flag. </del> <ins> Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous configuration) flag RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. </ins> The Stub Router flag (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the M and O flags MUST be copied from
all times, when a new host arrives on the AIL, it is able to acquire an IPv6 address on that link. <ins> During all of the states mentioned here except for state-unknown, the SNAC router is expected to treat the infrastructure interface as an Advertising Interface as described in RFC4861.  There are two sets of information that need to be sent in an RA; if neither is present, then the SNAC router SHOULD NOT send an RA even if it is treating the infrastructure interface as an advertising interface. These two sets of information are the on-link prefix, if any, that is to be advertised.  Whether or not such a prefix is advertised, and what exactly is advertised regarding that prefix, is determined by the state machine.  The other set of information is a set of routes to prefixes on the SNAC network.  Whenever we know of a reachable (scope is not link-local) prefix on the SNAC network, we include an RIO option in the RA on the infrastructure network indicating that that prefix is reachable through the SNAC router. It is important to note that it is possible for an on-link, routable prefix to be advertised and then withdrawn on the SNAC network, but for it to still be valid, and for there to still be some communication occurring using that prefix.  In order to avoid prematurely interrupting such communication, the SNAC router MUST maintain a list of prefixes known to be valid on the SNAC network, even if those prefixes have been deprecated, and MUST include RIO options for all such prefixes in the RAs that it sends on the adjacent infrastructure link. </ins> 5.1.2.1. When the stub router interface first connects to the AIL, it MUST
stub router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead. <ins> A DHCPv6-PD client can request a particular lease interval for the DHCPv6-delegated prefix.  However, there is no particular reason for a SNAC router to specify this interval. 5.2.3.1. It is possible that a SNAC router might obtain a prefix from a DHCPv6 server using prefix delegation and then something about the infrastructure network attachment might change that affects the validity of that prefix for use on the stub network.  The section of I-D.ietf-dhc-rfc8415bis titled "Refreshing Configuration Information" discusses the various scenarios that can occur.  We assume that the DHCPv6 prefix delegation client being used by the SNAC router conforms to this specification. Situations that can occur include (but are not limited to): The SNAC router MUST NOT use a prefix once the DHCPv6-PD client has determined that it is no longer valid.  If the DHCPv6-PD client provides a new prefix, and the old prefix is still valid, the SNAC router SHOULD explicitly deprecate the old prefix at the same time that it first advertises the new prefix. If the DHCPv6-PD client determines that the prefix it provided to use as the OSNR prefix is no longer valid, and no replacement prefix is provided by the DHCPv6 server, then the SNAC router MUST switch to the ULA link prefix that it has allocated for use on the SNAC network.  In the case that the DHCPv6-PD client is unable to renew its lease on the current OSNR prefix, and time between the T2 interval for the prefix assignment I-D.ietf-dhc-rfc8415bis and the end of the lease has been reached, then the SNAC router MUST deprecate the DHCPv6-PD-provided OSNR prefix and begin advertising the ULA link prefix. A failure to renew the DHCPv6-PD-provided OSNR prefix could be because the SNAC network has been disconnected from one AIL and moved to a different AIL.  In this situation, if the new AIL also has IPv6 service and DHCPv6-PD service, the DHCPv6 client will get a clear indication that the old prefix is no longer valid.  However, it may be that no DHCPv6-PD service is available on the new link, either because it is an IPv4-only link or because it's an IPv6-capable link that doesn't provide DHCPv6 service.  In this situation, if the SNAC network remains connected to the link and no DHCPv6 service appears, the DHCPv6-PD-provided OSNR prefix will eventually time out and be replaced.  The SNAC router SHOULD NOT attempt to replace it prior to this normal timeout process, because there is no benefit to changing the OSNR prefix on the SNAC network in such a situation, and it's possible that the SNAC router will return to the other link before the OSNR prefix expires. </ins> 5.3. Stub routers MUST advertise reachability to stub network OSNR
6. <ins> SNAC networks rely on IPv6 to enable routing between links, which would not be possible with IPv4 due to the lack of a standard mechanism similar to router advertisements in IPv4.  However, it can stll be useful for hosts on the SNAC network to establish communications with IPv4-only hosts on the infrastructure network. Although NAT64 provides IPv6-only hosts with a way to reach IPv4 hosts, there is no easy way for an IPv4 host to use NAT64 to originate communication with an IPv6 host.  Therefore, this document enables IPv6 hosts on the SNAC network to discover and reach with IPv4 hosts on infrastructure, but does not provide a way for IPv4-only hosts on infrastructure to communicate to IPv6 hosts on the SNAC network. This should be acceptable because hosts on the infrastructure network should not be IPv4-only, since the SNAC router is providing IPv6 service on the infrastructure network that is suitable for communicating using IPv6 to hosts on the SNAC network--there should not be any hosts on the infrastructure network that can't communicate with hosts on the stub network unless such hosts do not have an IPv6 stack at all. So the purpose of providing IPv4 connectivity for SNAC hosts is to enable communication with arbitrary IPv4 hosts which may not be on the AIL.  This is accomplished by providing NAT64 address translation in the stub router, and by enabling service discovery using a Discovery Proxy. </ins> Stub Network routers must be capable of providing NAT64 themselves, and must be capable of discovering the availability of NAT64 service on the infrastructure network and providing it when it is available
stub router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead. <del> 5.3. </del> <ins> A DHCPv6-PD client can request a particular lease interval for the DHCPv6-delegated prefix.  However, there is no particular reason for a SNAC router to specify this interval. 5.2.3.1. It is possible that a SNAC router might obtain a prefix from a DHCPv6 server using prefix delegation and then something about the infrastructure network attachment might change that affects the validity of that prefix for use on the stub network.  The section of I-D.ietf-dhc-rfc8415bis titled "Refreshing Configuration Information" discusses the various scenarios that can occur.  We assume that the DHCPv6 prefix delegation client being used by the SNAC router conforms to this specification. Situations that can occur include (but are not limited to): The SNAC router MUST NOT use a prefix once the DHCPv6-PD client has determined that it is no longer valid.  If the DHCPv6-PD client provides a new prefix, and the old prefix is still valid, the SNAC router SHOULD explicitly deprecate the old prefix at the same time that it first advertises the new prefix. If the DHCPv6-PD client determines that the prefix it provided to use as the OSNR prefix is no longer valid, and no replacement prefix is provided by the DHCPv6 server, then the SNAC router MUST switch to the ULA link prefix that it has allocated for use on the SNAC network.  In the case that the DHCPv6-PD client is unable to renew its lease on the current OSNR prefix, and time between the T2 interval for the prefix assignment draft-ietf-dhc-rfc8415bis and the end of the lease has been reached, then the SNAC router MUST deprecate the DHCPv6-PD-provided OSNR prefix and begin advertising the ULA link prefix. A failure to renew the DHCPv6-PD-provided OSNR prefix could be because the SNAC network has been disconnected from one AIL and moved to a different AIL.  In this situation, if the new AIL also has IPv6 service and DHCPv6-PD service, the DHCPv6 client will get a clear indication that the old prefix is no longer valid.  However, it may be that no DHCPv6-PD service is available on the new link, either because it is an IPv4-only link or because it's an IPv6-capable link that doesn't provide DHCPv6 service.  In this situation, if the SNAC network remains connected to the link and no DHCPv6 service appears, the DHCPv6-PD-provided OSNR prefix will eventually time out and be replaced.  The SNAC router SHOULD NOT attempt to replace it prior to this normal timeout process, because there is no benefit to changing the OSNR prefix on the SNAC network in such a situation, and it's possible that the SNAC router will return to the other link before the OSNR prefix expires. 5.2.4. </ins> Stub routers MUST advertise reachability to stub network OSNR prefixes on any AIL to which they are connected.  If the stub router
and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <del> 8. </del> <ins> 5.5. </ins> In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: <del> 9. </del> <ins> 5.6. </ins> This document has no IANA actions. <del> 10. </del> <ins> 5.7. </ins> Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security
link in a Prefix Information option (RFC4861) with the following Prefix Information option header values: <del> A prefix is not considered a suitable on-link prefix if the 'L' bit is set, but the 'A' bit is not set.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "suitable"&#151;not all hosts can actually use it. </del> <ins> A prefix is not considered a suitable on-link prefix if the 'L' flag bit is set, but the 'A' flag bit is not set.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "suitable"&#151;not all hosts can actually use it. </ins> Note: there can be layer two networks where neighbor discovery is not <del> supported and therefore we cannot set the 'L' bit, but could set the 'A' bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </del> <ins> supported and therefore we cannot set the 'L' flag bit, but could set the 'A' flag bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </ins> A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous <del> configuration) flag RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. The Stub Router flag (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the M and O flags MUST be copied from the respective M/O flag values seen in the most recent (unicast or multicast) RA received from a non-stub-router.  For the selection of the most recent RA, the following RAs MUST be excluded: If there is no recent RA from a non-stub-router, both M and O flags MUST be cleared, unless the stub router rebooted recently.  After a reboot, if no recent RA is received from a non-stub router, but a recent RA has been received from a stub router, the values for the M and O flags provided by that stub router MUST be copied.  After MAX_FLAGS_COPY_TIME after reboot, the stub router MUST go back to the regular behavior defined above.  This avoids a situation where a stub router that has rebooted starts to advertise different M/O flag values than other stub routers present on the same link. </del> <ins> configuration) RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST also be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. The 'Stub Router' flag bit (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the 'M' and 'O' flag bits MUST be copied from the respective 'M' and 'O' flag bit values seen in the most recent (unicast or multicast) RA received from a non-stub- router.  For the selection of the most recent RA, the following RAs MUST be excluded: If there is no recent RA from a non-stub-router, both 'M' and 'O' flag bits MUST be cleared, unless the stub router rebooted recently. After a reboot, if no recent RA is received from a non-stub router, but a recent RA has been received from a stub router, the values for the 'M' and 'O' flag bits provided by that stub router MUST be copied.  After MAX_FLAGS_COPY_TIME after reboot, the stub router MUST go back to the regular behavior defined above.  This avoids a situation where a stub router that has rebooted starts to advertise different 'M' and 'O' flag bit values than other stub routers present on the same link. </ins> The sent router advertisement MUST also include a Route Information option (RFC4191) for each routable prefix advertised on the stub
The stub router may receive a router advertisement containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the stub router is advertising as the <del> on-link suitable prefix, and the Stub Router flag is not set in in the Router Advertisement flags field, the stub router moves the </del> <ins> on-link suitable prefix, and the 'Stub Router' flag bit is not set in in the Router Advertisement flags field, the stub router moves the </ins> interface to STATE-DEPRECATING (state-deprecating). <del> If the stub router bit is set in the RA header flags field, then one of the following must be true in order for that prefix to be </del> <ins> If the 'Stub Router' flag bit is set in the RA header flags field, then one of the following must be true in order for that prefix to be </ins> considered suitable: 5.1.2.5.
A stub network that services a Wi-Fi stub network SHOULD provide DNS64 translation: hosts on the stub network cannot be assumed to be able to do DNS64 synthesis in the stub resolver.  In this case the <del> DNS resolver on the stub router MUST honor the CD and DO bits if received in a request, since this indicates that the stub resolver on the requestor intends to do DNSSEC validation.  In this case, the resolver on the stub router MUST NOT perform DNS64 synthesis. </del> <ins> DNS resolver on the stub router MUST honor the 'CD' and 'DO' flag bits if received in a request, since this indicates that the stub resolver on the requestor intends to do DNSSEC validation.  In this case, the resolver on the stub router MUST NOT perform DNS64 synthesis. </ins> On specific stub networks it may be desirable to require the stub network device to perform DNS64 synthesis.  Stub network routers for
prefix) MUST also be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. <del> The 'Stub Router' flag bit (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the 'M' and 'O' flag bits MUST be copied from the respective 'M' and 'O' flag bit values seen in the most recent (unicast or multicast) RA received from a non-SNAC- router.  For the selection of the most recent RA, the following RAs MUST be excluded: </del> <ins> The 'SNAC Router' flag bit (I-D.ietf-6man-snac-router-ra-flag) MUST be set in the RA flags field.  The values of the 'M' and 'O' flag bits MUST be copied from the respective 'M' and 'O' flag bit values seen in the most recent (unicast or multicast) RA received from a non-SNAC-router.  For the selection of the most recent RA, the following RAs MUST be excluded: </ins> If there is no recent RA from a non-SNAC-router, both 'M' and 'O' flag bits MUST be cleared, unless the SNAC router rebooted recently.
The SNAC router may receive a Router Advertisement message containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the SNAC router is advertising <del> as the on-link suitable prefix, and the 'Stub Router' flag bit is not </del> <ins> as the on-link suitable prefix, and the 'SNAC Router' flag bit is not </ins> set in in the Router Advertisement flags field, the SNAC router moves the interface to STATE-DEPRECATING (state-deprecating). <del> If the 'Stub Router' flag bit is set in the RA header flags field, </del> <ins> If the 'SNAC Router' flag bit is set in the RA header flags field, </ins> then one of the following must be true in order for that prefix to be considered suitable:
5.2. How addressability is managed on stub networks depends on the nature <del> of the stub network.  For some stub networks, the stub router can be </del> <ins> of the stub network.  For some stub networks, the SNAC router can be </ins> sure that it is the only router.  For example, a SNAC router that is providing a Wi-Fi network for tethering will advertise its own SSID and use its own joining credentials; in this case, it can assume that
5.2.2. In order to be able to provide addressability either on the stub <del> network or on an adjacent infrastructure network, a stub router MUST </del> <ins> network or on an adjacent infrastructure network, a SNAC router MUST </ins> allocate its own ULA Site Pefix.  ULA prefixes, described in Unique Local IPv6 Unicast Addresses (RFC4193) are randomly allocated prefixes.  A SNAC router MUST allocate a single ULA Site Prefix for
5.3. SNAC routers MUST advertise reachability to stub network OSNR <del> prefixes on any AIL to which they are connected.  If the stub router </del> <ins> prefixes on any AIL to which they are connected.  If the SNAC router </ins> is advertising a suitable prefix on any interface, any such prefixes MUST be advertised on that interface in the same Router Advertisement message that is advertising the suitable prefix, to avoid unnecessary
The SNAC router MAY advertise itself as a default router on the stub network, if it itself has a default route on the AIL.  In some cases it may not be desirable to advertise reachability to the Internet as <del> a whole; in this case the stub router is not required to advertise </del> <ins> a whole; in this case the SNAC router is not required to advertise </ins> itself as a default router. If the SNAC router is not advertising itself as a default router on
that received it. Consequently, SNAC routers SHOULD be configurable to not advertise <del> themselves as default routers on the stub network.  Stub routers </del> <ins> themselves as default routers on the stub network.  SNAC routers </ins> SHOULD be configurable to explicitly advertise AIL prefixes on the stub network even if they are advertising as a default router.  The mechanisms by which such configuration can be accomplished are out of
to be advertised.  Whether or not such a prefix is advertised, and what exactly is advertised regarding that prefix, is determined by the state machine.  The other set of information is a set of routes <del> to prefixes on the SNAC network.  Whenever we know of a reachable (scope is not link-local) prefix on the SNAC network, we include an </del> <ins> to prefixes on the stub network.  Whenever we know of a reachable (scope is not link-local) prefix on the stub network, we include an </ins> RIO option in the RA on the infrastructure network indicating that that prefix is reachable through the SNAC router. It is important to note that it is possible for an on-link, routable <del> prefix to be advertised and then withdrawn on the SNAC network, but </del> <ins> prefix to be advertised and then withdrawn on the stub network, but </ins> for it to still be valid, and for there to still be some communication occurring using that prefix.  In order to avoid prematurely interrupting such communication, the SNAC router MUST <del> maintain a list of prefixes known to be valid on the SNAC network, </del> <ins> maintain a list of prefixes known to be valid on the stub network, </ins> even if those prefixes have been deprecated, and MUST include RIO options for all such prefixes in the RAs that it sends on the adjacent infrastructure link.
If the DHCPv6-PD client determines that the prefix it provided to use as the OSNR prefix is no longer valid, and no replacement prefix is provided by the DHCPv6 server, then the SNAC router MUST switch to <del> the ULA link prefix that it has allocated for use on the SNAC </del> <ins> the ULA link prefix that it has allocated for use on the stub </ins> network.  In the case that the DHCPv6-PD client is unable to renew its lease on the current OSNR prefix, and time between the T2 interval for the prefix assignment I-D.ietf-dhc-rfc8415bis and the