Hi Mark, Answering this particular point. Please see inline. Cheers, Med > -----Message d'origine----- > De : ietf [mailto:ietf-bounces@xxxxxxxx] De la part de Mark Andrews > Envoyé : mardi 1 août 2017 09:22 > À : jordi.palet@xxxxxxxxxxxxxx > Cc : ietf@xxxxxxxx > Objet : Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF > Meetings > > > In message <65D79ACB-372A-4978-9030-FFAB4967A2BD@xxxxxxxxxxxxxx>, JORDI > PALET M > ARTINEZ writes: > > Hi Med, > > > > In line … > > > > Saludos, > > Jordi > > > > > > > It is a matter of > > preference of one or another transition mechanisms. All them have good > > and bad things. I see much simpler the combination of NAT64+CLAT than > > DS-Lite or MAP, in addition to the ONLY support in cellular networks is > > precisely NAT64/464XLAT, which means is the MOST extended transition > > mechanism by millions (billions?) of users. It makes a lot of sense to > me > > to go in all the infrastructures to the one that has more deployment > > already. > > Not really. Cellular networks went with anything available, rather > than the best. We are continuing the pay the price for that. [Med] Actually, no. There was an IPv6 Study Item within 3GPP. Both DS-Lite, A+P, and NAT64 were presented and documented in a 3GPP report. For example, this is what was documented for A+P: Known issues: - The UE needs to be modified to support A+P scheme - The gateway needs to forward not only based on IP address but based on address plus port. The network needs to implement PRR in similar places as CGN in the DS-Lite approach - The backend RADIUS system needs to be changed as subscribers can no longer be identified by IP address only, but by IP address and port - In the IPv6 tunnelling approach QoS differentiation between bearers cannot be provided easily - The solution works only with applications using transport protocols, which have concept of port numbers (such as UDP and TCP). There will be challenges with protocols which use plain IP. - The solution sets restrictions to applications within in the UE, as the allocation of fixed port numbers becomes more complicated. - For ICMP messages, the UE must use an ICMP query identifier within the allocated port range, otherwise the response will not be received by this UE. Known benefits: - The UE has access to public IPv4 address, which simplifies the behaviour for P2P applications such as VoIP. - Allows IPv4 lifetime extension if used with GTP/GRE. - Legal requirements for tracing which traffic flow was originated from which UE is simpler than in CGN solutions, as the operator does not need to store each flow but only A+P allocation information. - In GTP/GRE/DSMIP6 based solutions QoS can be provided. - A+P allows for an incremental migration to IPv6-only network - A+P can be fully stateless when used together with IPv6 - No per-state sessions are maintained in the PLMN realm - Unlike NAT44/NAT64, no dynamic state synchronization is required to ensure service robustness - No ALG is required to be implemented in the service/PLMN realm - No extra-cost on the UE to support NAT traversal techniques is required - Unlike double NAT solutions, peer-to-peer services can be delivered with one exception as documented in [23] - No Keep-alive messages are required to maintain NAT entries. This characteristic mitigates battery consumption issues induced by "Always-on" services. Especially, the use of short intervals between keep-alive messages has a big impact on the battery consumption (See [24] for more details about complications to tweak UDP timers in NAT devices and also keep-alive intervals used by UE). Moreover, the network load is more optimized since the load induced by keep-alive messages in the context of CGN solutions is avoided. - Latencies and related problems of NATs are avoided. And for NAT64: == Known issues of the solution: - The session binding between MS/UE IPv6 address and public IPv4 address/port is not known to the PCC architecture. Therefore, depending on deployment and if the application is NAT aware and has access to the binding (as e.g. in the case of IMS), there may or may not be issues with applying PCC to the session. - General NAT concerns, not specific to 3GPP networks, apply. For example, applications that embed IP addresses in the payload and are not NAT aware require additional functionality to work across NATs. - In case of roaming with Local Breakout (PGW/GGSN in VPLMN), if there is a need to reach IPv4-only services, the VPLMN operator would be required to deploy NAT64/DNS64 in order to provide the same user experience using IPv6-only connections for IPv4-only services as in non-roaming scenarios. - It is unclear how IPv4 literals are supported. Known benefits of the solution - This solution requires no changes to the MS/UE. - The existing bearer and session management procedures can be used without any change. - This solution does not introduce any additional tunnelling overhead on any interfaces. - This solution has no impact to the 3GPP network architecture, no new interface or network element is needed. This solution can be deployed without any additional normative specification within 3GPP. Limitations described under "known issues" above apply. - No changes to the IPv6 address-assignment procedures required. - No bearing on the type of transport network: Transport network can be IPv4 or IPv6. - NAT64 can be either co-located or separate from GGSN/PDN-GW. - Solution to the public IPv4 address exhaustion problem through the use of stateful NAT64. - No impact on QoS/bearer procedures between UE and PDN GW/S GW. ===