Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[e-mail]] 
Envoyé : lundi 16 février 2015 15:52
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Le 16/02/2015 14:47, [e-mail] a écrit :
> Hi Alex,
>
> Based on the discussion in this thread, I don't think there is a
> justification to change the wording for this recommendation... but I
>  understood you have some issues with CLAT being a hurdle to have
> AF-applications. What about the following change?

Hello Med,

Thank you for the suggestion of better text.

> OLD:
>
> C_REC#9:  In order to ensure IPv4 service continuity in an IPv6-only
> deployment context, the cellular host should implement the Customer
> Side Translator (CLAT, [RFC6877]) function which is compliant with
> [RFC6052][RFC6145][RFC6146].
>
> CLAT function in the cellular host allows for IPv4-only application
> and IPv4-referals to work on an IPv6-only connectivity.  CLAT
> function requires a NAT64 capability [RFC6146] in the core network.
>
> The IPv4 Service Continuity Prefix used by CLAT is defined in
> [RFC7335].
>
> NEW:
>
> C_REC#9:  In order to ensure IPv4 service continuity in an IPv6-only
> deployment context, the cellular host should implement the Customer
> Side Translator (CLAT, [RFC6877]) function which is compliant with
> [RFC6052][RFC6145][RFC6146].

I disagree with that SHOULD.  It should be a MAY.  It should be
accompanied by all other mechanisms achieving the same, like tunnelling.

[Med] I thought we clarified this point ;-) Tunneling is not an option for current IPv6 deployment in mobile networks: native IPv6 connectivity + NAT64 is currently the favorite option of mobile providers. (Note, I recall there was a proposal to adapt DS-Lite to the mobile context (Gi-DS-Lite, RFC6674) but that proposal is not adopted in operational networks.) We set this recommendation to "should" because we have to find a balanced position between: 
* the operators that want to provide the same service level as in IPv4 when adopting an IPv6-only mode. For those operators, CLAT is a "MUST" 
* Those who do not care about these broken application can ignore CLAT.  


> CLAT function in the cellular host allows for IPv4-only application
> and IPv4-referals to work on an IPv6-only connectivity.  The more
> applications are address family independent, the less CLAT function
> is solicited.

YEs, I agree with the more AF-independence, the less CLAT-requirement.

[Med] Great!

In addition, now reading it, I am afraid it may be circular.  I think
CLAT itself is not AF-independent and makes use of IPv4 and IPv6
literals. As such, it can't pretend to be a panacea solution to
IPv4-referral use.

[Med] Not sure to get your point here. CLAT fixes an issue with applications that make use of IPv4 referrals. We all are for AF-independent applications.

I think this could be re-written:

>> Functions like CLAT and tunnelling in the Computer MAY allow for
>> IPv4-only applications using IPv4-referals (literals), and
>> applications not relying on DNS resolution, to still work when the
>> computer has only an IPv6 connection.  Note that setting up the
>> CLAT function itself does not rely on DNS and makes use of IPv4
>> and IPv6 literals.  The more the applications are AF-independent,
>> and more reliance on DNS, the less the functions like CLAT (or
>> tunnelling) are solicited.

[Med] Which "tunneling"? The text you are proposing is at most vague. Please don't forget this is a profile document that ambitions to include explicit features not generic assumption. CLAT has proven its efficiency + it is RFCed. 

> CLAT function requires a NAT64 capability [RFC6146] in the network.
>
> The IPv4 Service Continuity Prefix used by CLAT is defined in
> [RFC7335].
>
> The activation of the CLAT function does not interfere with native
> IPv6 communications.

One should also consider:
- activation with CLAT interferes with native IPv4 communications.

[Med] CLAT assumes NAT64 is deployed in the network. Translation leads to a loss of semantic but other issues can be solved, please refer to https://tools.ietf.org/html/rfc6889 

- CLAT software itself involves manual configuration by way of literals
   IPv4 and IPv6.

[Med] This profile document advocates for means to discover the PREFIX64 + indicate which IPv4 prefix is to be used by the CLAT function. What manual configuration are you referring to?

For these reasons, I do not understand why making CLAT a SHOULD on the
end-user device.

One could write that CLAT may be used by some users in need of _some_
kind of IPv4 Internet connectivity, and that IPv4 connectivity is
limited in nature (interferes with some IPv4 applications, etc.)

> BTW, do you think a modification is needed for L_REC#4:
>
> L_REC#4:  In order to ensure IPv4 service continuity in an IPv6-only
> deployment context, the cellular device should support the Customer
> Side Translator (CLAT) [RFC6877].

On one hand, this makes think that if the end user device implements
CLAT then IPv4 access is fine.  It is not: one still has to use literals
to configure CLAT itself.

On another hand, there are several other ways in which better IPv4
access can be obtained when connecting to a v6-only access, and which do
not use CLAT nor address translation: for example tunnelling, Mobile IP,
VPN.

For these reasons, L_REC#4 could be a "MAY" only.

Also, the notion of "service continuity" could be understood as "session
continuity" - using Mobile IP.  Maybe one should clarify what is meant
by this continuity.

> Various IP devices are likely to be connected to cellular device,
> acting as a CPE.

I agree.

The cellular device is rather a 'cellular interface'.

'CPE' - Customer PRemisses Equipment - makes sense in fixed home/office
context, but when deployed out in the field, where there is no customer,
one would call it just a Router.  Or anything else but a CPE.

[Med] There is always a "customer" that can delegate the right to use the service to a user. I suspect you are the user for the case you are referring to. Someone has to pay the bill  ;-)

> Some of these devices can be dual-stack, others are IPv6-only or
> IPv4-only. IPv6-only connectivity for cellular device does not allow
>  IPv4-only sessions to be established for hosts connected on the LAN
>  segment of cellular devices.

Right.  Except that 'cellular devices' are actually cellular interfaces.
  I may have several cellular interfaces on a same unique Router, for
bandwidth augmentation.

> In order to allow IPv4 sessions establishment initiated from devices
>  located on LAN segment side and target IPv4 nodes, a solution
> consists in integrating the CLAT function in the cellular device. As

HEre instead of cellular device I would rather think "the Router on
which that cellular interface connects"

[Med] Please note this definition the I-D:

   o  "3GPP cellular device" (or cellular device for short) refers to a
      cellular host which supports the capability to share its WAN (Wide
      Area Network) connectivity.

> elaborated in Section 2, the CLAT function allows also IPv4
> applications to continue running over an IPv6-only host.
                                   ^through          ^Router

[Med] The initial wording is correct. This is just a reminder to the other usage of CLAT as indicated in Section 2.