> Proofreading edits to follow shortly... (For large values of "shortly"...)
First, comments on the language of the document, then the purely spelling nits. 1. Introduction I'd like to see a little more development of the problem statement. Perhaps something like the following after the third paragraph: Even with the widespread deployment of IPv6 in the internet infrastructure, all the way to the broadband customers, there will be a continued need for IPv4 addresses, as customer equipment, applications, and web services are slowly transitioned to IPv6 capability. Only when there are significant numbers of IPv6-only devices will the demand start to recede. 4.1. Access model One other important feature of the access model is that it brings native IPv6 to the customer site, so that true dual-stack migration can begin immediately. This section ends in an ellipsis, which indicates an unfinished thought. 4.3. Directly connected device This scenario is identical to wireless devices directly connected over the air interface to their provider. This sentence is awkward to read, and doesn't really add anything. 5.3. Fragmentation and Reassembly Unfortunately, path MTU discovery [RFC1191] is not a reliable method to deal with this problem. [citation needed] Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv6 header. Reassembly is entirely dependent on how fragmentation is done, so the second MUST is a meaningless assertion. Some discussion would be beneficial to explain why encapsulation-before-fragmentation is preferable. 5.5. DNS As DHCPv6 only defines an option to get the IPv6 address of such a DNS recursive server, the B4 element cannot easily discover the IPv4 address of such a recursive DNS server, and as such will have to perform all DNS resolution over IPv6. It occurs to me that the DHCPv6 server could send an IPv4-mapped address, e.g. ::ffff:207.69.188.172. However, this is getting pathological, and probably not worth mentioning in this document. 5.6. Interface initialization Initialization of the interface including a B4 element is out-of- scope in this specification. So...why bother to mention it? 5.7. Well-known IPv4 address IANA has defined a well-known range, 192.0.0.0/29. This is jumping the gun just a little, since it's only requested in this document. If necessary, the B4 could source packets using its LAN address (e.g. 192.168.1.1). However, the 192.0.0.0/29 address would allow the AFTR to identify the packet as originating from the B4. Maybe a little discussion about how/when the B4 needs to talk to the AFTR over IPv4. Section 6.5 has an explicit MAY with regard to using this address. This section should add similar language. Note: a range of addresses has been reserved for this purpose. The intend is to accommodate for nodes implementing several B4 elements... The mechanisms to decide which of those addresses to use on a B4 element is implementation dependant and out of scope for this document. The ellipsis implies an unfinished thought, which really doesn't belong in a WGLC document. The -04 version of this text mentioned multihoming directly. Some discussion about multihoming is needed, perhaps in section 7. 6.3. Fragmentation and Reassembly Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv6 header. See prior discussion. Fragmentation at the Tunnel Entry-Point is a light-weighted operation. In contrast, reassembly at the Tunnel Exit-Point can be expensive. This could be construed as an argument for fragmentation before encapsulation - it shifts the cost of reassembly to the ultimate destination. Other methods to avoid fragmentation, such as rewriting the TCP MSS option or using technologies such as Subnetwork Encapsulation and Adaptation Layer defined in [I-D.templin-seal] are out of scope for this document. "Other" implies that there has been some preceding mention of ways to avoid fragmentation. I'd strike the word, or repeat section 5.3 (increase the link MTU if possible). Also, some mention of MSS clamping would be good, since that's a cheap and easy solution for TCP traffic. Simply ruling it out of scope doesn't really help anyone. 6.4. DNS As noted previously, DS-Lite node implementing a B4 elements will perform DNS resolution over IPv6. As such, very few, if any, DNS traffic will flow through the AFTR element. I talked this to death in my previous email. Besides, this section is entirely irrelevant, since DNS traffic flowing through the AFTR will be just like any other UDP traffic. There are no special considerations at the protocol level. 7.2. VPN The combination of the dual-stack lite technology with either IPv4 VPNs or IPv6 VPNs is out of scope for this document. Meaning we haven't thought about it. But we need to. 7.3. Multicast considerations Multicast is out-of-scope in this document. Ditto. 8.1. NAT pool It is expected that AFTRs will operate distinct, non overlapping NAT pools. However, those NAT pools do not have to be continuous. What on earth does this mean? 8.3. ALG Spell out Application Level Gateways in the heading 12. Author's Addresses There are two separate Author's Address sections - here and at the end of the document (the usual place). 13.1.2. A+P model It should be mentioned that the AFTR that supports this has to fully implement the A+P semantic, including checking the source address and port range of all outbound packets. 15.2. Horizontal scaling In case of a spike of traffic, for example during the Olympic games or an important political event, capacity can be quickly added in any location of the network (tunnels can terminate anywhere) simply by splitting user groups. Extra capacity can be later removed when the traffic returns to normal by resetting the DHCPv6 tunnel end-point settings. Note that, since the only currently-defined tunnel discovery mechanism is DHCPv6, This is subject to normal DHCPv6 lease renewal times, or by pushing DHCPv6 Reconfigure notices to a large number of customers. As such, this approach works best as a planned cutover rather than as an OMG reaction to an unanticipated traffic spike. In general, I think this should be approached with the same planning and caution as a network renumbering. ---------------- spelling/grammar Numbers are abolute line numbers in the .txt document. 195: s/later/latter/ 197, 215: future tense 219: period 251: s/between B4 and the AFTR/between the CPE and the NAT/? 252: s/leverage/leveraged/ 262: s/is // 297: s/is forwarding any regular IPv4 packets/forwards any other IPv4 traffic/ 314: s/home gateway/a home gateway/ 371: s/However,as/However, as/ 428: s/intend/intent/ 430: s/dependant/dependent/ 454: s/service provider//? s/service provider subscribers/customers'/? 467: s/for// 472: s/light-weighted/light-weight/ 481: s/demand/require/ 498: s/few/little/ OR s/traffic/packets/ 517: s/will/is used to/ 572: s/port/ports/ 596: s/digit/digits/ 600: s/service provider/service providers/ 628: s/the/the AFTR/ 738: s/what/that/ 815: s/bellow/below/ 819: s/Application/Applications/ 819: s/ones/applications/ 823: s/king/kind/ 824: s/be in the way of/prevent/ 827: s/argue for an/argues for a/ 833: s/a static number of ports/a number of static ports/ 928: s/device/devices/ _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
