I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. This is an updated version of the review which went out yesterday without the summary and some belated thoughts on the connection to DS-Lite. Apologies for the finger trouble. Document: draft-ietf-softwire-public-4over6-09 Reviewer: Elwyn Davies Review Date: 23 May 2013 IETF LC End Date: 24 May 2013 IESG Telechat date: 30 May 2013 Summary: Nearly ready for the IESG but there are a lot of nits and two interelated significant issues that need to be resolved: 1. Ensuring that it is clear that this is a historical description of a mechanism that has been superseded; this should probably be reflected in the status of the document being Historical rather than Informational. 2. The discussion of the use of DS-Lite as a fallback mechanism and/or the mechanims being 'backwards compatible' with DS-Lite. Given that this mechanism is not recommended for future deployments, the discussion of DS-Lite is either documentation of what was actually done in existing deployments or irrelevant complication/speculation that is not needed in what is effectively a historical document. It needs to be either made clear that DS-Lite is actually used in this way or the whole matter can be removed. Major(ish) issues: Purpose of the document: We only find out that this document is a description of existing practice in CERNET2 in para 2 of section 1 (OK that is quite close to the front). It is not recommended for future deployments that should use the Unified CPE mechanism instead. At the very least this should be repeated in the Abstract and be right up front in the Introduction. Arguably this document should be classified as Historical rather than Informational. Relation to DS-Lite: In s3 DS-Lite is mentioned as an alternative to Public 4over6 in situations where IPv4 addresses are in short supply. This is either irrelevant (as this mechanism is now deprecated) or a statement of how it has actually been used. It should be made clear which is the case. In s5 DS-Lite is suggested as a fallback mechanism in case of certain failures. Again, is this dcoumentation of what has actually happened or speculation on how it could be used? Finally, ss7 and 8 claim that the DS-Lite RFC 6333 fragmentation and DNS considerations apply. This may well be the case, but it seems possibly anachronistic: does Public 4over6 pre- or post-date DS-Lite? More interesting would be documentation of what was actually done in CERNET2 to meet these considerations. Minor issues: It would be desirable to emphasize that (I assume) 'public' is used as a synonym for 'globally routable' or 'globally unique'. Looking closely at RFC 1918, the term 'public address' is not used as an antonym for 'private address' (as opposed to 'private host' and 'public host'). RFC 1918 states that public hosts are expected to use 'globally unique' (and hence 'globally routable') addresses. Abstract, last sentence: s/the allocation of full IPv4 address over IPv6 network/the allocation and distribution of globally routable IPv4 addresses over the provider's IPv6 network/ Subsequent to writing this I see from s1, para 3/4 that 'full IPv4 address' is being used as a 'term of art' meaning that the user is free to use the address with any port number (as opposed to a 'port-restricted address'). The reader of the abstract would not understand this implication I think. Suggest making the substitution: NEW: the allocation and distribution over the provider's IPv6 network of globally routable IPv4 addresses that can be used with any port number Since the term 'full (IPv4) address' is used several times in the document it needs to be defined. Perhaps I could suggest using 'unrestricted' instead of 'full' ('full' seems to imply the whole 32 bits rather than just a prefix which I don't think is the intention of the term). s7/s8: RFC 6333 talks about B4 and AFTR elements: How does this map into the elements in this draft? In particular referring to s5.5 of RFC 6333, do both CE and BR need DNS proxies? I am not sure that just referencing RFC 6333 is sufficient here, but with the mapping explained it may be adequate. s10: This section should probably refer to the security considerations of RFC 6333 in the case of fallback to DS-lite. s10: Some variant of the RFC 6333 logging issue is probably needed since the IPv4 addresses mare allocated to CEs and I suspect that there needs to be a tie between the DHCP logging and the bindings. s10: Is there any way for a bad actor to 'steal' a CE IPv4 address? Does this document need a (brief) section on routing for the IPv4 addresses? (Not sure if this is really needed). Nits/editorial comments: General: s/hub and spokes/hub and spoke/ (is traditional I think) Abstract: s/When the service provider networks/When service providers' networks/ s/uses IPv4-over-IPv6 tunnel as basic method to traverse/uses an IPv4-over-IPv6 tunnel as the basic method for traversing/ Abstract, last sentence: Expand ICP acronym. s1: Be consistent in use of 'user-side' or 'user side' (2 instance of each currently). [I think the RFC Editor will probably prefer 'user-side'.] s1: There ought to be a reference to RFC 2473 regarding IPV4-in-IPv6 tunnelling. s1, para 1: s/still a functionality required/still required/ s/IPv4-only/the IPv4-only/ s/this type of IPv4 services./this type of IPv4 service./ s1, para 2: Probably s/Binding approach/binding approach/ - it is only capitalized at the start of sentences in the bmk draft. s1, para 3: Expand ISP acronym. s1, para 3, last sentence: OLD: as well as save the IPv4 address resource from being assigned all over the network NEW: as well as avoiding the need to deploy scarce IPv4 address resources throughout the network. s1, para 4, sentence 1: s/are developed/have been developed/ s1. para 4, sentence 3: s/Further more/Furthermore/ s1, para 4, sentence 4: OLD: operating system could support the mechanism smoothly, while transparency on upper-layer applications is guaranteed. NEW: in general, operating systems are able to support the mechanism natively, while transparency is guaranteed for upper-layer applications. s1, para 4, sentence 5: s/which/that/ s1, para 5: s/operation/operational/, s/other: end user IPv4/other; the end user's IPv4/ (note semi-colon instead of colon), s/in on-demand style/in an on-demand style/, s/in the way of/being/ s1, para 6: s/IPv4-over-IPv6 tunnel/IPv4-over-IPv6 tunnelling/ s1, last para: s/are maintained/is maintained/ s2, Public 4over6: OLD: Public 4over6 supports bidirectional communication between IPv4 Internet and IPv4 hosts or customer networks in IPv6 access network, by leveraging IPv4-in-IPv6 tunnel and public IPv4 address allocation over IPv6. NEW: Public 4over6 supports bidirectional communication between the global IPv4 Internet and IPv4 hosts or customer networks via an IPv6 access network, by leveraging IPv4-in-IPv6 tunnelling [RFC2473] and public IPv4 address allocation over IPv6. s2, border relay: OLD: 4over6 Border Relay (BR): A router functioning as the border relay in Public 4over6 environment. 4over6 BR is the IPv4-in-IPv6 tunnel concentrator located in IPv6 ISP network. It is a dual-stack router which connects to both the IPv6 ISP network and IPv4 Internet. The 4over6 BR also works as a DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning public IPv4 address to 4over6 CEs. NEW: 4over6 Border Relay (BR): A router functioning as the border relay in the Public 4over6 environment. A 4over6 BR is the IPv4-in-IPv6 tunnel concentrator located in the IPv6 ISP network. It is a dual-stack router which connects to both the IPv6 ISP network and the IPv4 Internet. The 4over6 BR also works as a DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning and distributing a public IPv4 address to 4over6 CEs. s3, para 1: Are the customer networks necessarily LANs? 'private' might be a better term? Expand acronym LAN (whether or not as it appears in 'home LAN'). Comment also applies to Figure 1. s3, para 1: s/connected to IPv4 Internet/connected to the IPv4 Internet/ s3, para 1: s/border relays/Border Relays/ (or use acronym BR that you defined). Figure 1: Would be a little clearer if the height of the BR box was expanded to 7 lines so the connections to the CEs were not at the corners of the box. s3, para 2: Explicitly associate DS-Lite acronym with Dual-Stack Lite. s3, para 2: s/which switches/that switches/ s3, para 2: Might be good to emphasise that you are talking about globally routable IPv4 address resource. s3, para 2: s/so much/so many/ s3, para 2: Expand acronym CGN. s3, para 2: OLD: A typical case of the high-end users that could use Public 4over6 is IPv4 application server. Full, public IPv4 address brings significant convenience in this case, which is important to IPv6 transition for ICPs. The DNS registration can be direct using dedicated address; the access of the application service can be straightforward, with no translation involved; there will be no need to provide NAT traversal mechanisms for incoming traffic, and no special handling is required for well-known ports. NEW: A typical use case for high-end users that could use Public 4over6 is an IPv4 application server. Using a full (unrestricted), public IPv4 address brings significant advantages in this case, which is important for transitioning ICPs to IPv: - The DNS registration can be direct using a dedicated address; - Access for clients of the application service can be straightforward, with no translation involved; - There will be no need to provide NAT traversal mechanisms for incoming traffic, and no special handling is required for well-known ports. s4.1, bullet 1: s/the information of/knowledge of/, s/by DHCPv6/using DHCPv6/ (possibly) s4.2, para 2: s/enables DHCPv4 message/allows DHCPv4 messages/, s/between BR and CE/between the BR and the relevant CE/, s/to support that/needed to support this operation/ s4.2, last para: OLD: While regular users would probably take DHCPv4 over IPv6, the manual configuration is usually seen in two cases: application server, which requires a stable IPv4 address, and enterprise network, which usually requires an IPv4 prefix rather than one single address (Note that DHCPv4 does not support prefix allocation). NEW: While regular users would probably opt for DHCPv4 over IPv6, the static configuration is particularly applicable in two cases: for application servers, which require a stable IPv4 address, and for enterprise networks, which usually require an IPv4 prefix rather than one single address (Note that DHCPv4 does not support prefix allocation). s5, para 1: s/or DHCPv6 option/or via a DHCPv6 option/ s5, para 2: OLD: The CE regards the BR as DHCPv4-over-IPv6 server/relay for public IPv4 address allocation, whose IPv6 address is learned by the CE as described above. NEW: The CE regards the BR as its DHCPv4-over-IPv6 server/relay, which is used to obtain its public IPv4 address allocation; its IPv6 address is learned by the CE as described above. s5, para 3: s/DHCPv4 over IPv6/DHCPv4-over-IPv6/ (I think). s5, para 4: OLD: The decapsulation on 4over6 CE is simple. When receiving an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and either hands it to upper layer or forward it to customer network according to the IPv4 destination address. NEW: The decapsulation on the 4over6 CE is simple. When receiving an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and either hands it to a local upper layer or forwards it to the customer network according to the IPv4 destination address. s5, para 5: Expand NAPT acronym. s5, para 6: s/necessarily/necessary/ s5, para 7: s/4over6 CE supports/The 4over6 CE supports/, s/employ Well-Known/employ the Well-Known/, Expand B4 acronym, s/for instance, the DHCPv4 over IPv6/for instance, if the DHCPv4-over-IPv6/ s6, para 1: s/4over6 BR/The 4over6 BR/, s/to provide correct/to provide the correct/, s/validate/validating/ s6, bullet 1: s/collocated/co-located/ or 'colocated', s/delete/deletes/ s6, bullet 2: Expand TRA acronym s12: This section would normally be called 'Contributors'. s13: I think I-D.ietf-dhc-dhcpv4-over-ipv6 is a normative reference. s13.1: Requires a reference to RFC 2473. RFCs 4925, 4966, 5549, and 5565 are not referenced currently.