Document: draft-ietf-v6ops-v6-in-mobile-networks-03 Reviewer: Kathleen Moriarty Review Date: 11-02-21 IETF LC End Date: 11-02-21 IESG Telechat date: (if known) Summary: I have a number of nits that could improve the readability of the document that should be considered. There is a high number of transitional phrases used in the document. Reducing these and making sentences more concise would increase the readability of the document. There are also many places where commas are used that are unnecessary. I went through the document and made a few suggestions listed below, but can take another pass through once these are corrected to assist further. Major issues: Minor issues: Nits/editorial comments: Introduction, first sentence: Change from: The dramatic growth of the Mobile Internet is accelerating the exhaustion of available IPv4 addressing pool. To: The dramatic growth of the Mobile Internet is accelerating the exhaustion of available IPv4 addresses. OR: The dramatic growth of the Mobile Internet is accelerating the exhaustion of the available IPv4 addressing pool. Introduction, second sentence (some commas are unnecessary): Change from: It is widely accepted that IPv6 is necessary for the continued operation, and growth of the Internet in general, and that of the Mobile Internet in particular. To: It is widely accepted that IPv6 is necessary for the continued operation and growth of the Internet in general, and that of the Mobile Internet in particular. Introduction, forth sentence (remove comma): Change from: This document describes such challenges, and outlines the applicability of the existing IPv6 deployment solutions. To: This document describes such challenges and outlines the applicability of the existing IPv6 deployment solutions. Section 2, first paragraph: Change from: An APN is a logical concept which can be used to specify what kinds of services, such as Internet access, high-definition video streaming, content-rich gaming, and so on, a MN is entitled to. And, each APN can specify what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN. To: An APN is a logical concept which can be used to specify what kinds of services, such as Internet access, high-definition video streaming, content-rich gaming, etc., a MN is entitled. Each APN can specify what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN. Section 2, Second paragraph. The first sentence is a run-on, I recommend breaking it up. What is the comparison being made to use the word "whereas" at the start of this paragraph? I am not quite able to follow this, so maybe a change would clear it up. Section 2, second paragraph: Consider adding some text to the transition sentence before the bulleted list. What is the connection from this paragraph to the items in the bulleted list? It would help to include that information in this transition sentence. Change the sentence, "The different nodes in the figure are defined below:" to include the link from this paragraph to the bulleted list. For each of the bullets in this section, the acronyms should first be spelled out and then followed by the acronym. For example: Change from: o BS: The radio Base Station which provides wireless connectivity to the MN. o ANG: The Access Network Gateway. This is a node that forwards IP packets to and from the MN. To: o Base Station (BS): the radio BS which provides wireless connectivity to the MN o Access Network Gateway (ANG): The ANG is a node that forwards IP packets to and from the MN. Section 3.1, second to last sentence, remove the comma. Section 3.1 paragraph 2: Change from: In the following, we primarily focus on translation based mechanisms such as NAT44 (i.e., translation from public IPv4 to private IPv4 and vice versa) and NAT64 (i.e., translation from public IPv6 to public IPv4 and vice versa); we do this because the 3GPP architecture already defines a tunneling infrastructure with the GPRS Tunneling Protocol (GTP), and the architecture allows for dual-stack and IPv6-only deployments. To: In the following, we primarily focus on translation based mechanisms such as NAT44 (i.e., translation from public IPv4 to private IPv4 and vice versa) and NAT64 (i.e., translation from public IPv6 to public IPv4 and vice versa). This approach is taken because the 3GPP architecture already defines a tunneling infrastructure with the GPRS Tunneling Protocol (GTP) and the architecture allows for dual-stack and IPv6-only deployments. Section 3.1, third paragraph: Change from: A PDN connection may support both IPv4 and IPv6 traffic (as in a dual-stack PDN in 4G LTE networks) or it may support either one only (as in the existing 3G UMTS networks). To: A PDN connection may support both IPv4 and IPv6 traffic (as in a dual-stack PDN in 4G LTE networks) or it may support only one of the two traffic types (as in the existing 3G UMTS networks). Section 3.1, forth paragraph: Change from: An approach to address this problem is to make the always-on PDN to be IPv6, and To: An approach to address this problem is to make the always-on PDN to be IPv6 and Change from: In any case, there need to be appropriate triggers to initiate DHCP To: In any case, there needs to be appropriate triggers to initiate DHCP Section 3.1, fifth paragraph: Change from: And, the existing so-called pre-Release-8 deployments do not support the dual-stack PDP connection. Hence two separate To: The existing so-called pre-Release-8 deployments do not support the dual-stack PDP connection. Hence, two separate Section 3.1, last paragraph: Change from: Operators can introduce IPv6 in their networks, perhaps to access operator's own applications and services to begin with. To: Operators can introduce IPv6 in their networks, perhaps to access operator's own applications and services. Section 3.2, paragraph 3: BR is already defined and should be used consistently. Change from: Some network deployments use the "centralized model" where the pool is managed by a common node, such as the PDN's Border Router, and the pool shared by multiple gateways all attached to the same BR. To: Some network deployments use the "centralized model" where the pool is managed by a common node, such as the PDN's BR, and the pool shared by multiple gateways all attached to the same BR. Section 3.2, paragraph 3: Change from: This model has served well in the pre-3G deployments where the number of subscribers accessing the mobile Internet at any given time, perhaps, has not exceeded the available address pool. To: This model has served well in the pre-3G deployments where the number of subscribers accessing the mobile Internet at any given time has not exceeded the available address pool. Section 3.2, Paragraph 5: I am wondering why is each MNG limited to the use of the Net10 block and not all of the non-routable networks set aside for this purpose? Section 3.2, last paragraph: Consider breaking this sentence into two: Whereas the centralized models with a common NAT have the advantages of continuing their legacy deployments, re-use of private IPv4 addressing, and centralized NAT, they need additional functions to enable traffic differentiation, and NAT state correlation with subscriber state management at the MNG. Recommend removing the first comma in this sentence: The distributed models also achieve private IPv4 address re-use, and avoid overlapping private IPv4 traffic in the operator's core, but without the need for additional mechanisms. Section 3.3, last paragraph: Consider changing the first sentence from: Roaming is important in mobile networks and roaming introduces diversity in network deployments. To: Roaming is important in mobile networks and introduces diversity in network deployments. Section 3.4, first paragraph: Change from: And, an All-IP mobile network service provider is required to provide voice service as well, whereas a fixed network provider is not required to. To: An All-IP mobile network service provider is required to provide voice service, whereas this is not required for a fixed network provider. Change from: Such architectural differences, as well as policy and business model differences, make convergence challenging. To: Architectural, policy, and business model differences make convergence challenging. Section 3.4, second paragraph: Second sentence, was this intended to say: For instance, IPv4 address management is a common concern for both the access networks and . OR: For instance, IPv4 address management is a common concern for both of the access networks. Third sentence, consider rewording: This implies the same mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion and introducing IPv6 in operational networks, apply for the converged networks as well. I am having trouble reading and understanding the intent of the first three sentences of this section and am unsure how to fix this and keep the meaning as intended. Note: There are a large number of examples in this section. Would it be possible to provide them in a list format or is the set of examples not intended to cover all possible use cases? Having the examples grouped as they are related to each other may increase readability. The transitional phrases, such as however, are used quite frequently. As a reader, the examples used with these statements make it difficult to decipher the set of examples and the exceptions that need to be tracked for each example. Section 3.4, forth paragraph: Change from: Using IPv6 for the Femto (or any other access technology), on the other hand, could alleviate some of these concerns if the IPv6 communication could bypass the NAT. To: Using IPv6 for the Femto (or any other access technology) could alleviate some of these concerns if the IPv6 communication could bypass the NAT. Section 4, first paragraph: Consider changing from: In this document, we discussed the considerations in deploying IPv6 in mobile networks. Specifically, we discussed: To: This document discusses the considerations of deploying IPv6 in mobile networks. The following bullets summarize the point discussed. Bullet one: Change from: o IPv4 address exhaustion and its implications to mobile networks: we saw that, as the mobile networks begin to deploy IPv6, conserving the available IPv4 pool and delaying its exhaustion implies the need for network translation in mobile networks. At the same time, providers can make use of the 3GPP architecture constructs such as the APN and PDN connectivity to introduce IPv6 without affecting the (predominantly IPv4) Internet access. The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily. To: o IPv4 address exhaustion and its implications to mobile networks: As mobile networks begin to deploy IPv6, conserving the available IPv4 pool is necessary to delay its exhaustion and implies the need for network translation in mobile networks. At the same time, providers can make use of the 3GPP architecture constructs such as the APN and PDN connectivity to introduce IPv6 without affecting (predominantly IPv4) Internet access. The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily. Consider changing the second bullet to: o The placement of NAT functionality in mobile networks: Both the centralized and distributed models of private IPv4 address pool management and their relative merits were discussed. By enabling each MNG to manage its own NET10 pool, the distributed model achieves re-use of available private IPv4 pool and avoids the problems associated with the non-unique private IPv4 addresses for the MNs without additional protocol mechanisms. The distributed model augments the "subscriber management" functions at an MNG, such as readily enabling NAT session correlation with the rest of the subscriber session state. On the other hand, the existing deployments which have used the centralized IP address management can continue their legacy architecture by placing the NAT at a common node. The centralized model can achieve private IPv4 address re-use, but needs additional protocol extensions to differentiate overlapping addresses at the common NAT, as well as to integrate with policy and billing infrastructure. Consider changing the third bullet to: o IPv6-only mobile network deployments: This deployment model is feasible in the LTE architecture for an operator's own services and applications. Existing MNs still expect an IPv4 address assignment<, which could be problematic>. Roaming, which is unique to mobile networks, requires that a provider support IPv4 connectivity when their (outbound) users roam into a mobile network that is not IPv6-enabled. Similarly, a provider needs to support IPv4 connectivity for (inbound) users whose MNs are not IPv6-capable. In this use case, IPv6 - IPv4 interworking is necessary for IPv6-only MNs to access the IPv4 Internet. Consider changing the forth bullet to: o Fixed-Mobile Convergence: The examples provided illustrate the differences in the requirements of fixed and mobile networks. While some harmonization of functions may be possible across the access networks, the service provider's core network is best-suited for converged network architecture. Perhaps even greater gains are feasible in the service and application layers. I am not following the last two sentences of this bullet and why it might be the case that the core is best suited for convergence, but then 'greater gains' might be seen in the service and application layers. It reads as though both are the best over the other. Some rewording or expanded thoughts may help here.