jiebi/CodeConvo huggingface dataset:
Code change:
The working group didn't actually agree on the use of the term "CPE Router", and there were substantive objections to it. I've used the term Home Gateway here, and included a definition that I think includes both ISP-provided routers with integrated uplink support (cable modem or DSL modem) and also includes routers where the WAN link is an ethernet connector. Not clear that this is correct, but hopefully it's evolving in the right direction.

Related discussion:
text: 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
Code change:
The working group didn't actually agree on the use of the term "CPE Router", and there were substantive objections to it. I've used the term Home Gateway here, and included a definition that I think includes both ISP-provided routers with integrated uplink support (cable modem or DSL modem) and also includes routers where the WAN link is an ethernet connector. Not clear that this is correct, but hopefully it's evolving in the right direction.

Related discussion:
text: 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
Code change:
…flag in the Prefix Information Option flags, but in fact Jonathan's document describing the flags field sets it in the Router Advertisement Flags Extension option. We discussed this in 6man and I think the general consensus was to just use one of the remaining reserved bits rather than requiring the additional extension option prematurely, so I'm updating the text to say that, and have asked Jonathan to update the stub router flags document accordingly.

Related discussion:
text: 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
Code change:
see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Related discussion:
text: 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
Code change:
see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Related discussion:
text: 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.
Code change:
see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Related discussion:
text: 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.
Code change:
Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Related discussion:
text: 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.
Code change:
Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Related discussion:
text: 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
Code change:
Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Related discussion:
text: 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
Code change:
I added a section about services provided by the Stub Network. This will need some more work, but it seems useful to have, and it now says that DHCPv6 is generally NOT RECOMMENDED but is permitted, and MUST be off by default.
(Based on recent discussion in v6ops) We don't specify yet the type of hosts on the IPv6 stub network in detail. For example, an IoT device host only needs an address which it can configure with SLAAC based on the /64 on-mesh/on-link prefix. However, there could also be more complex hosts in principle that need their own prefixes (e.g. /64) delegated to it for internal usage and they may like to use their DHCPv6-PD client for that. For example for running multiple virtual machines / dockers inside the host where these VMs are on their own virtual network segment. I expect these cases to be out of scope and there's no requirement on the stub router to do either DHCPv6-PD server or relay role. Do we need to make this explicit in a goal / non-goal / out-of-scope section ?
With my AD hat one, I sincerely hope to keep the stub network with simple devices, else the SNAC WG will try to make a simple problem too complex ;-) Without any hat, I do not mind having an applicability statement with non-goals in it.

Related discussion:
text: then the ULA prefix that is numerically lowest should be kept, and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <ins> 6.5. In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: </ins>
Code change:
Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.

Related discussion:
text: Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-lemon-stub-networks-07 </del> <ins> draft-ietf-snac-simple-00 </ins> Abstract
Code change:
Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.

Related discussion:
text: 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
Code change:
Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.

Related discussion:
text: the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <del> 6.5. </del> <ins> 8. </ins> In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed