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

[Alexandru Petrescu <[e-mail]>]

Med -

Le 16/02/2015 17:00, [e-mail] a écrit :
> 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:

Tunneling should always be an option in mobile networks and elsewhere.
If the first-hop operator does not provide a tunnel endpoint (for
various reasons), other entities in the network do.

These tunnels must co-exist with any other option, like CLAT.

There are many viable tunnels out there.  Is CLAT compatible with them?

> native IPv6 connectivity + NAT64 is currently the favorite option of
> mobile providers.

Well, stated so I can only agree.  But there should always be an option
to tunnel through, this should not be blocked.

> (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.)

YEs, I recall as well.  There may have been several proposals, like
DS-MIPv6 RFC5555 as well.  Probably this is not adopted in the
operational networks either.

> 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.

And there should be an operator offering full IPv6 and full IPv4 at the
same time.

And I doubt that what an operator does all the others should too.

>> 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.

YEs, we are all for AF-independent apps.

But that's hard to do.

Is CLAT itself not AF-independent and not making use of literals?

> 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.

"Tunnelling" - IPv6 packet with an UDP payload carrying an IPv4 packet
in turn; not sure which RFC should I cite?  OpenVPN can do this, I think.

CLAT is efficient - ok, but should not prohibit OpenVPN from doing it.

>> 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

Thanks for the pointer.  I dont complain about translation in general.
But compared to tunnelling it should not be mandatory.

In the same vein, there is also Specific Routing (Routing Header) which
is an intermediary form between Tunnelling and Translation.  One
wouldn't take sides either.

> - 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?

The IPv4 address for self.

> 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  ;-)

Ok.

>> 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.

WEll, noted.

This reads like a Router, not like a Host.  It 'shares' its connectivity.

Besides, we want it to be able to run DHCPv6 Prefix Delegation.  Its 
name would also be a "Requesting Router".

>> 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.

Noted.

I wanted to ask this: assuming IPv4 access dies out and IPv6 is the only
possible access, all an IPv4-inclined can do is run CLAT?

Alex

>
>
>