jiebi/CodeConvo huggingface dataset:
of firmware revisions to verify that the firmware update seen by a single device, is <del> indeed the same as seen by all the devices. </del> <ins> indeed the same as seen by all the devices </ins> reliably discern an update that has been signed by the appropriate and intended signing identity make an informed judgement on all available information about <del> firmware at the install time.  For example, the firmware is still in a good state or otherwise? </del> <ins> firmware at the install time.  (For example, the firmware is still in a good state or otherwise?) </ins> 3.9. Software Integration is a complex activity.  This typically involves <del> getting various software components from multiple suppliers and </del> <ins> getting various software components from multiple suppliers, </ins> producing an integrated package deployed as part of device assembly. For example, car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software. <del> Consumer of an integrated software wants: </del> <ins> Consumers of an integrated software wants: </ins> all components presents in a software product listed, and the ability to identify and retrieve them from a secure and tamper-
security scans of running software provide valid annotations on build integrity to ensure conformance <ins> 3.10. Software producers often have multiple and concurrent supported versions of a product.  The versions may represent major feature or compatibility differentiating releases (1.0, 2.0), or implementations for different Operating System Platforms and Architectures (Linux, Mac, Windows, AMD, ARM, x86, x64). For each release, the software producer must be capable of providing statements, unique to that version.  Producers may provide free patching to a specific version the consumer has purchased, while requiring upgrades to newer major releases.  Consumers need to know which updates are compatible with their environment.  Third parties that provide statements of quality need to know how to differentiate supported version bands, avoiding the recommendation to upgrade to an incompatible version. As versions age, and vulnerabilities are discovered, consumers need to know the newer version of a particular product.  Software producers implement versioning updates, however there are no standards for consumers and third parties to apply across software producers. Consumers and Producers want: a standard means to associate vulnerability information, statements of quality, statements of support and end of life (EOL) with a specific version of a product a standard means to identify a patched version, specific to their Operating System and Platform a standard means to differentiate major and minor version upgrades a standard means to provide concurrent versioned updates </ins>
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected. <del> It may be noted that just as you can plug several home routers together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </del> <ins> It may be noted that just as you can plug several CPEs together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </ins> The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support
described in RFC4861. Support for adjacent infrastructure links on networks where Neighbor <del> Discovery is not supported are out of scope for this document.  Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </del> <ins> Discovery is not supported and is out of scope for this document. Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </ins> 5.1.
A prefix is not considered a usable on-link prefix if it is advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the <del> Prefix option.  This indicates that node addressibility is being </del> <ins> Prefix option.  This indicates that node addressability is being </ins> 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 "usable"&#151;not all hosts can actually use it.
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently <del> providing a prefix on the stub network, it need take no action.  If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network. It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </del> <ins> providing a prefix on the stub network, it needs to take no action. If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </ins> When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected. <del> It may be noted that just as you can plug several CPEs together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </del> <ins> It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </ins> The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently <del> providing a prefix on the stub network, it needs to take no action. If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </del> <ins> providing a prefix on the stub network, it does not need to take action.  If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </ins> When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement containing this prefix.  The 'A' (autonomous configuration), 'L' (on-link) RFC4861 and the Stub Router bit (I- <del> D.hui-stub-router-ra-flag) MUST be set in the prefix header. </del> <ins> D.hui-stub-router-ra-flag) MUST be set in the Router Advertisement header flags field RFC5175. </ins> This router advertisement MUST also include a Route Information Option (RFC4191) for each routable prefix advertised on the stub
autonomous configuration. A prefix is not considered a usable on-link prefix if it is <del> advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the Prefix option.  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 "usable"&#151;not all hosts can actually use it. </del> <ins> advertised on the link as on-link, but the 'a' bit is not set in the Prefix Information option header (RFC4861) that contains the Prefix option.  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 "usable"&#151;not all hosts can actually use it. </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
header flags field RFC5175. This router advertisement MUST also include a Route Information <del> Option (RFC4191) for each routable prefix advertised on the stub </del> <ins> option (RFC4191) for each routable prefix advertised on the stub </ins> network.  If the stub router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space.
It is also possible that stub routers for more than one stub network may be connected to the same adjacent infrastructure link.  In this <del> case, the stub routers will be advertising Router Information Options </del> <ins> case, the stub routers will be advertising Router Information options </ins> in their router advertisements for their OSNR prefixes.  Stub routers MUST track the presence of such routes, and MUST advertise reachability to them on interfaces connected to stub networks.
5.2.3. If DHCPv6 PD is available on the link, it is preferable to acquire a <del> prefix using DHCPv6 PD rather than generating a ULA prefix, because the DHCPv6-PD-provided prefix is routable at least on the local infrastructure.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </del> <ins> prefix using DHCPv6 PD rather than generating a ULA prefix.  Using a prefix provided by the infrastructure DHCPv6 prefix delegation service means (assuming the infrastructure is configured correctly) that routing is possible between the stub network links and all links on the infrastructure network, and possibly to the general internet. By contrast, if the prefix generated by the stub router is used, reachability is only possible between the stub network and the adjacent infrastructure link, because the OSNR prefix in this case is not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure- provided NAT64 will not work.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </ins> 5.3.
NAT64 prefix(es) MUST be advertised by those stub routers that are able to discover it. <ins> In order for infrastructure-provided NAT64 to work, the stub network must have an OSNR prefix that is known to the infrastructure. Typically this means that the stub router must have acquired this prefix using DHCPv6 Prefix Delegation.  Unless otherwise configured to do so, the stub router MUST NOT advertise infrastructure-provided NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation. </ins> 6.2. Most infrastructure networks at present do not provide NAT64 service. <del> It is therefore necessary for stub routers to be able to provide </del> <ins> Many infrastructure networks do not provide DHCPv6 Prefix Delegation. In these cases it is necessary for stub routers to be able to provide </ins> NAT64 service if IPv4 hosts are to be reachable from the stub <del> network. </del> <ins> network.  Therefore, stub routers MUST be capable of providing NAT64 service to the stub network.  When infrastructure-provided NAT64 service is not present or is not usable, and when no other NAT64 service is already advertised on the stub network, stub routers MUST, by default, enable their own NAT64 service and advertise it on the stub network. </ins> To provide NAT64 service, a stub router must allocate a NAT64 prefix. For convenience, the stub network allocates a single prefix out of
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 7. </del> <ins> 6.3. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. 6.4. </ins> If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is
6. <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 and usable. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. There are four possible combinations of circumstances in which to consider how to provide NAT64 service: In the first case, infrastructure-provided NAT64 is preferred, and the stub router MUST advertise this service to the stub network. In the second case, there is no way to provide connectivity to the infrastructure: we don't have IPv6 routing, because we don't have a routable prefix, we don't have NAT64 for the same reason, and we don't have IPv4, so the stub router can't do NAT64 on its own.  In this case, the stub router MUST NOT advertise NAT64 service. In the third case, despite the infrastructure providing NAT64, we can't use it, so the stub router MUST provide its own NAT64 service. In the fourth case, the stub router MUST provide its own NAT64 service. An additional complication is that there may be more than one stub router connecting the stub network to infrastructure.  In this case, it may be desirable to limit the number of stub routers providing NAT64 service, or it may be acceptable for all stub routers to provide it.  In the latter case, this should not be a problem: since each stub router is using its own ULA prefix to provide NAT64, any 5-tuple that goes through a stub router's NAT64 translator will necessarily have as its destination an IPv6 address in a particular NAT64 prefix, and that address will select the correct stub router through which to send the packet for translation. A further complication is that in some cases, some stub routers connected to the stub network may not be able to advertise an infrastructure-provided NAT64 prefix, while others may.  In this case, when the infrastructure-provided NAT64 service appears on the stub network, stub routers that are not able to advertise an infrastructure NAT64 service MUST NOT do so. To differentiate between infrastructure-provided NAT64 service and stub router-provided NAT64 service, stub routers that advertise infrastructure-provided NAT64 service MUST use a preference of medium for this service.  Stub routers advertising their own service MUST use a preference of low. In some cases a stub router may be administratively configured with a NAT64 prefix.  In this situation, the stub router MUST advertise the prefix with a preference of high. Stub routers must monitor the advertisement of other NAT64 prefixes on the stub network.  If a stub router is advertising a NAT64 prefix, and a NAT64 prefix is advertised on the stub network with a higher preference, the stub router SHOULD deprecate the prefix it is advertising. </ins> 6.1. Stub networks are defined to be IPv6-only because it would be
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 6.3. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. 6.4. </del> <ins> 7. </ins> If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is
different ULA prefix each time it connects to a different infrastructure network. <del> If IPv6 prefix delegation is available, which implies that IPv6 service is also available on the infrastructure link, then the stub router MAY use IPv6 prefix delegation to acquire a prefix to advertise on the stub network, rather than allocating one out of its ULA prefix. </del> 5.2.3. <del> If DHCPv6 PD is available on the link, it is preferable to acquire a prefix using DHCPv6 PD rather than generating a ULA prefix.  Using a prefix provided by the infrastructure DHCPv6 prefix delegation service means (assuming the infrastructure is configured correctly) that routing is possible between the stub network links and all links on the infrastructure network, and possibly to the general internet. </del> <ins> If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using DCHPv6 prefix delegation.  Using a prefix provided by the infrastructure DHCPv6 prefix delegation service means (assuming the infrastructure is configured correctly) that routing is possible between the stub network links and all links on the infrastructure network, and possibly to the general internet. </ins> By contrast, if the prefix generated by the stub router is used, reachability is only possible between the stub network and the
not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure- <del> provided NAT64 will not work.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </del> <ins> provided NAT64 will not work.  Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6 PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix. A stub router SHOULD request stub network prefixes with length 64. If the stub router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros. If the stub router obtains a prefix with length greater than 64, the stub router MUST treat the prefix as unusable and allocate a prefix out of its ULA prefix instead. </ins> 5.3.
to the destination, and will drop the packet. To address this problem, stub routers SHOULD remember the last time a <del> prefix was advertised across restarts.  On restart, the router can immediately begin deprecating the prefix, and can stop after the prefix valid lifetime goes to zero, based on the recorded time that the last advertisement was sent. </del> <ins> prefix was advertised across restarts.  On restart, the router configures the prefix on its interface but does not advertise it in Router Advertisements.  Devices that are still using that prefix will be seen as on-link to the router, and so packets will be delivered using ND on-link rather than forwarded to the default router. </ins> When a stub router has only flash memory with limited write lifetime, it may be inappropriate to do a write to flash every time an RA
record the set of prefixes that have been advertised on infrastructure and the maximum valid lifetime that was advertised. On restart, the router should assume that hosts on the infrastructure <del> link have received advertisements for any such prefixes, and should immediately deprecate them, and continue to do so until the maximum valid lifetime has elapsed after restart. [WG: we could actually just not advertise the prefix, rather than deprecating it.  In this case, the host should wind up preferring some other prefix for new connections anyway, because it will have a later preferred lifetime expiry.  As long as we remember the route and resume forwarding for it, existing connections can continue until the prefix becomes invalid. Further experience with this shows that this solution doesn't work well at all.  Ideally the stub routers would all use some identifier specific to the stub network to construct the prefix advertised on the AIL.  At present Thread uses the Thread "extended PAN ID", which is a 64-bit quantity.  Perhaps something like the SSID could be used for a WiFi stub network.  I don't think there's a way to specify this generally.  But it seems as if the solution proposed here probably isn't worth doing.] </del> <ins> link have received advertisements for any such prefixes. When possible, it is best if all stub routers serving a particular stub network use the same 64-bit prefix on the AIL.  For example, Thread stub routers use bits from the Thread Extended PAN ID to generate the ULA prefix's Global ID and Subnet ID.  The Global ID generation conforms to RFC4193 because the Extended PAN ID is generated randomly using the same mechanism that is specified in RFC 4193 for the ULA prefix bits. </ins> 5.2.2.
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.