Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt

[GangChen <[e-mail]>]

2013/12/12, Dan Wing <[e-mail]>:
>
> On Dec 11, 2013, at 7:04 AM, GangChen <[e-mail]> wrote:
>
>> Thank you for the useful comments. Please see my reply inline.
>>
>> 2013/12/11, Dan Wing <[e-mail]>:
>>>
>>> On Dec 8, 2013, at 7:48 PM, GangChen <[e-mail]> wrote:
>>>
>>>> Wg,
>>>>
>>>> We have submitted the new version of NAT64 Operational Experience.
>>>> The updates are summarized as follows:
>>>>
>>>> 1) Clarify the case when NAT64 serves as the IPv6 gateway ( Sec. 3.1.2)
>>>> 2) Polish the statement of NAT44 & NAT64 co-existing (Sec. 3.1.4)
>>>> 3) Clarify that the sub-domain configuration is only for the
>>>> experimental phase (Sec 3.2)
>>>> 4) Share the data for the scale of sync data in hot standby (Sec 4.1)
>>>> 5) Assessing the Impact of NAT64 to applications (Sec. 6.1)
>>>>
>>>> Your further reviews/comments are welcome.
>>>
>>> draft-ietf-v6ops-nat64-experience-05 reads, in part:
>>>
>>>  "6.1.  Service Reachability
>>>
>>>   NAT64 is providing a translation capability between IPv6 and IPv4
>>>   end-nodes.  In order to provide the reachability between two IP
>>>   address families, NAT64-CGN has to implement appropriate application
>>>   aware functions, i.e. Application Layer Gateway (ALG), where address
>>>   translation is not itself sufficient and security mechanisms do not
>>>   render it infeasible.  Most NAT64-CGNs mainly provide FTP-
>>>   ALG[RFC6384].  NAT64-FEs may have functional richness on Load
>>>   Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have
>>>   been supported."
>>>
>>> Can some text be added describing what an HTTP-ALG, HTTPS-ALG, RTSP-ALG,
>>> and
>>> SMTP-ALG might do?  For HTTP, HTTPS, and maybe RTSP, I guess it adds a
>>> Via
>>> or X-Forwarded-For so the IPv4 host can get visibility to the original
>>> IPv6
>>> address?  (I'm not sure.)  For SMTP-ALG, I can't guess what it might do
>>> --
>>> add a Received: header, or modify the EHLO/HELO exchange?
>>
>> Depending on the tests, ALGs detect and change following filed:
>>
>> For HTTP, HTTPs, the IP address inserted in the Via filed
>> For RTSP, the "dest_addr" and "src_addr" in SETUP message
>> For SMTP,  some mail message for trace purpose insert the IP address
>> in the "Received: " field or "Mail From: "
>>
>> To describe what those ALGs might do, the follows texts will be added
>> for the clarification:
>>
>> "NAT64-FEs may have functional richness on Load Balancer, for example
>> HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have been supported. Those
>> application protocols exchange IP address and port parameters within
>> control session, for example the "via" filed in a HTTP header,
>> "transport" field in a RTSP SETUP message and "Received: " header in
>> SMTP message.  ALG functions will detect those fields and make IP
>> address translations."
>>
>>>
>>> Later in the table, it reads:
>>>
>>>  Instance Message|Mostly fail, softwares don't support IPv6
>>>
>>> I think it should be "instant messenger".  It seems important to point
>>> out,
>>> in the document, that the lack of IPv6 support is not the fault or cause
>>> of
>>> NAT64 technology.  Rather, the lack of IPv6 support prevents those
>>> applications from working on an IPv6-only host or working over IPv6 on a
>>> dual-stack host -- that is, they are stuck being IPv4-only applications.
>>> The only thing that will help them is 464xlat, which should be pointed
>>> out
>>> in the document.
>>
>> Agree. We will clarify the meaning.
>>
>>>
>>> Then for games it says:
>>>
>>>   |     Games      |Mostly pass for web-based games and mostly fail for
>>> |
>>>   |                |standalone games due to software supports
>>>
>>> Is "due to software supports" the same as "softwares don't support IPv6",
>>> or
>>> is the different phrasing describing an important difference?
>>
>> Same meaning with "softwares don't support IPv6""
>>>
>>>   |     Email      | Pass
>>> |
>>>
>>> Is that IMAP, POP, SMTP, or all?  Is that with, or without, SMTP-ALG?
>>
>> We test POP and SMTP.  SMTP-ALG is supported
>>
>>>
>>>
>>>   |     VoIP       | Fail, due to the lack of SIP-ALG support on NAT64
>>> |
>>>
>>> There certainly are non-SIP VoIP applications -- XMPP for example, and
>>> proprietary systems like Skype.  If only SIP was tested, say "SIP".
>>> Furthermore, if the SIP endpoint supports ICE, SIP-ALG is unnecessary,
>>> and
>>> any successful Internet deployment of a SIP client does need to support
>>> ICE.
>>> This particular case needs to be tightened up in the document.
>>
>> We mainly test SIP-VoIP applications as below stated. I will notice
>> this information in the table.
>> The test is made based on 4G mobile environment. The ICE function is
>> not available at the mobile device side yet at this time.
>> Your comments are useful, because I didn't realize it should be
>> recommended to make use of ICE other than implementing ALG on the
>> NAT64 box.
>> I will update this row as
>>
>>    |   SIP-VoIP       | Fail, due to the lack of SIP NAT64 traversal |
>
> ICE is not only useful for NAT traversal, but also firewall traversal for
> both IPv4 and IPv6.  That is, ICE (or NAT-PMP, or UPnP IGD, or PCP) is
> needed if the IPv6 network has simple security (RFC6092).  My point, which I
> hope can be reflected in your I-D, is that the need for firewall traversal
> is not solely because of NAT64, but rather would also be a requirement for a
> 100% end-to-end IPv6 network, if that network has a firewall (and to protect
> hosts and to protect network bandwidth, a lot of networks have installed
> firewalls, they aren't going away!).

The text in the row is only specific to the reason for this failure.
The use of ICE for firewall traversal may be worth to mentioned in the
discussion part, like

"The voice call is failed due to the lack of NAT64 traveral when an
IPv6 SIP user agent communicates with an IPv4 SIP user agent. The
Interactive Connectivity Establishment(ICE)
described in [RFC5245]is recommended to be supported as the NAT64
traveral mechanism during the SIP IPv6 transition.
[RFC6157] describes both signalling and media layer process, which
should be followed. In addition, it may be worth to notice that ICE is
not only useful for NAT traversal, but also firewall traversal for
both IPv4 and IPv6. Even IPv6 is deployed in an end-to-end manner, ICE
still is of great value to avoid the impact of firewall to the SIP
procedure."


>
>> Some additional descriptions will be added as below (*)
>>
>>
>>>
>>>   |      VPN       | Fail, due to incapability of IPsec verification
>>> |
>>>
>>> So, this was IPsec VPN, and not "SSL" VPN.  That should be clarified in
>>> the
>>> document.  What is "incapability of IPsec verification"?  I know the
>>> issue
>>> you are no doubt referring to, but that could be solved in IPsec
>>> implementations should they be inclined - but nobody has documented the
>>
>> "incapability of IPsec verification" means the remote peer would
>> invalidate
>> the packet since NAT64 changes the header and IPsec-AH likely detect
>> the change.
>
> Yes, it has long been true that IPsec AH does not survive any sort of
> network address translation, and IPsec AH also does not survive translation
> from IPv6 to IPv4.
>
> Nobody much uses IPsec AH because of its incompatibility with NAT.
>
>> For IPsec ESP,NAT64 can't update the TCP/UDP checksum, which is
>> encrypted.
>> The remote peer is failed to validate the received packages.
>
> That isn't at all a problem for IPsec ESP.  It works fine through NAT64.
> The problem that exists is really in the specified NAT-T behavior for
> detecting a NAT, which is done by IKE.
>
>
>>
>> We will update the row as
>>
>> |      VPN       | Fail for IPsec-based VPN, the translated IPsec
>> packages are invalidated |
>>
>> Would it be helpful if we also add above statement into the draft?
>
> "packages" -> "packets".
>
>
>>
>>
>>> problem yet.  Did you try IPsec-over-UDP or IPsec-over-TCP, and did
>>> those
>>> also fail?  If IPsec native (protocol 50), I guess the CGN-NAT64 had
>>> support
>>
>> TCP/UDP is failed due to above reason.
>>
>>> for IPsec Passthru which is a defacto standard (but not documented, and
>>> has
>>> some issues with SPI changing).
>>
>> The tested NAT64 can't support this function. So I can't say more on this
>> point.
>> Your suggestion would be appreciated.
>
> Ah, so your test was IPsec-over-UDP (which failed) and IPsec-over-TCP (which
> failed).  That's odd; they should both work fine through a NAT64, assuming
> the IPv4 IPsec terminator was IPv6-aware (that is, fixed its NAT-T handling
> in its IKE code).

It seems NAT-T in IKE is missed on the tested NAT64 box. I guess we
should fix this function in the NAT64 box.  Anyway, I will document
the issues we found so let audiences
know NAT64 should be capable of NAT-T IKE.


>
>>
>>>
>>>   In regard to the widespread applications
>>>   of VoLTE in the near future, SIP-ALG is of great value to be
>>>   implemented on NAT64-CGN.
>>>
>>> I whole-heartedly disagree with that sentence.  We should be encouraging
>>> RFC6157 ("IPv6 Transition in the Session Initiation Protocol (SIP)") not
>>> the
>>> proliferation of application layer gateways.  Application layer gateways
>>> are
>>> buggy (as is all software) and cause interoperation problems, interfere
>>> with
>>> deployment of new services, and a myriad of other problems.  Their time
>>> has
>>> come and gone, let's bid ALG farewell and have applications be
>>> responsible
>>> for their proper function on the network, rather than the network trying
>>> to
>>> 'help' the applications.
>>
>> (*)Really great comments.  I incorporate your comments and try to make
>> following changes:
>>
>> ===OLD===
>>
>>   For VoIP services, we mainly tested Voice over
>>   LTE services[IR.92], which is the major solution for voice in the
>>   fourth generation communication ages.  NAT64 is testified with some
>>   issues of SIP-ALG supports.  In regard to the widespread applications
>>   of VoLTE in the near future, SIP-ALG is of great value to be
>>   implemented on NAT64-CGN.
>>
>> ===New===
>>
>>   For SIP-VoIP services, we mainly tested Voice over
>>   LTE services[IR.92], which is the major solution for voice in the
>>   fourth generation mobile communication age.
>
> A nit.  I know 3GPP loves calling it Voice over LTE, but isn't it really RTP
> over UDP over IP over LTE?  Considering the IETF audience for this eventual
> RFC, perhaps "Voice over IP over LTE [IR.92]" would be a reasonable
> compromise description.

The stack for Voice over LTE is RTP over UDP over IP over LTE.
Keeping the name in line with GSMA term may be easy to convey this information.


BRs

Gang
>
>> The voice call is failed
>>   due to the lack of NAT64 traveral when an IPv6 SIP user agent
>> communicates
>>   with an IPv4 SIP user agent. The Interactive Connectivity Establishment
>> (ICE)
>>   described in [RFC5245]is recommended to be supported as the NAT64
>> traveral
>>   mechanism during the SIP IPv6 transition.
>
> Add citation to RFC6157 at the end of that sentence, above.
>
>> Required functions should be
>>   implemented at SIP client side(e.g. mobile device), and STUN relay
>> server
>>   and STUN server should be deployment.[RFC6157] describes both signalling
>> and
>>   media layer process, which should be followed.
>
> I would delete the above two sentences; too much detail.
>
> -d
>
>
>> BRs
>>
>> Gang
>>
>>> -d
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> BRs
>>>>
>>>> Gang
>>>>
>>>> 2013/12/9, [e-mail] <[e-mail]>:
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>> This draft is a work item of the IPv6 Operations Working Group of the
>>>>> IETF.
>>>>>
>>>>> 	Title           : NAT64 Operational Experience
>>>>> 	Author(s)       : Gang Chen
>>>>>                         Zhen Cao
>>>>>                         Chongfeng Xie
>>>>>                         David Binet
>>>>> 	Filename        : draft-ietf-v6ops-nat64-experience-05.txt
>>>>> 	Pages           : 21
>>>>> 	Date            : 2013-12-08
>>>>>
>>>>> Abstract:
>>>>>  This document summarizes NAT64 function deployment scenarios and
>>>>>  operational experience.  Both NAT64 Carrier Grade NAT (NAT64-CGN) and
>>>>>  NAT64 server Front End (NAT64-FE) are considered in this document.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-05
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>
>