In message <787AE7BB302AE849A7480A190F8B93300A0156BD@xxxxxxxxxxxxxxxxxxxxxxxxxx ot.infra.ftgroup>, mohamed.boucadair@xxxxxxxxxx writes: > 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 aot 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. Requires EVERY DNSSEC validator on the planet to learn about DNS64. DS-Lite does NOT require every DNSSEC validator on the planet to be upgraded. > 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. Since you are sending IPv4 as IPv6 there is no difference between NAT64 and DNS-Lite etc. > - This solution does not introduce any additional tunnelling > overhead on any interfaces. You have 1480 payloads with NAT64 and 1460 byte playloads with DS-Lite etc. Incoming 1500 byte IPv4 packets get fragmented either way as they can't fit in a 1500 byte IPv6 packet. > - 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. None required for DS-Lite either. > - 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. Same with DS-Lite. > - Solution to the public IPv4 address exhaustion problem through > the use of stateful NAT64. Same with DS-Lite (stateful NAT again). > - No impact on QoS/bearer procedures between UE and PDN GW/S GW. > === DS-Lite does NOT require every node on the planet to aquire a CLAT only a encapsulating interface to talk to legacy devices. When you ignore some of the problem space NAT64 looks ok. When you look at the entire problem space that is not the case. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx