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

From: GangChen <[email-masked]>
Date: Mon, 9 Dec 2013 11:48:44 +0800

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.

BRs

Gang

2013/12/9, [email-masked] <[email-masked]>:
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Dan Wing <[email-masked]>
Date: Tue, 10 Dec 2013 19:05:27 -0800

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

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.

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?

   |     Email      | Pass                                               |

Is that IMAP, POP, SMTP, or all?  Is that with, or without, SMTP-ALG?

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

   |      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 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 for IPsec Passthru which is a defacto standard (but not documented, and has some issues with SPI changing).

   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.

-d

---

From: GangChen <[email-masked]>
Date: Wed, 11 Dec 2013 23:04:13 +0800

Thank you for the useful comments. Please see my reply inline.

2013/12/11, Dan Wing <[email-masked]>:
> 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."

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

> 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""
> Is that IMAP, POP, SMTP, or all?  Is that with, or without, SMTP-ALG?

We test POP and SMTP.  SMTP-ALG is supported

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

Some additional descriptions will be added as below (*)

> 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.
For IPsec ESP,NAT64 can't update the TCP/UDP checksum, which is encrypted.
The remote peer is failed to validate the received packages.

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?

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

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

BRs

Gang

---

From: Dan Wing <[email-masked]>
Date: Wed, 11 Dec 2013 09:04:41 -0800

>    |   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 packet since NAT64 changes the header and IPsec-AH likely detect

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.

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

> Would it be helpful if we also add above statement into the draft?

"packages" -> "packets".

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

>   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 voice call is failed
>   mechanism during the SIP IPv6 transition.

Add citation to RFC6157 at the end of that sentence, above.

> Required functions should be
>   and STUN server should be deployment.[RFC6157] describes both signalling and

I would delete the above two sentences; too much detail.

-d

---

From: GangChen <[email-masked]>
Date: Thu, 12 Dec 2013 11:38:56 +0800

2013/12/12, Dan Wing <[email-masked]>:
>>>   |     Email      | Pass
>>> |
> 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."

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

> 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

---

From: Dan Wing <[email-masked]>
Date: Wed, 11 Dec 2013 20:30:51 -0800

> traveral mechanism during the SIP IPv6 transition.

NAT64 is not mentioned in RFC6157, so the above sentence shouldn't mention NAT64.  RFC6157 is just about the transition to v6, for both dual-stack and single-stack nodes.

OLD:
... to be supported as the NAT64 traversal mechanism during the SIP IPv6 transition.

NEW:
... to be supported for SIP IPv6 transition.

> should fix this function in the NAT64 box.  

Can't be fixed there.

> Anyway, I will document

It isn't helpful to an IETF audience that may well be unfamiliar with GSMA/3GPP/ITU terminology, and that VoLTE is really VoIP over some non-Ethernet layer 2.

-d

>>> traveral

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Dec 2013 15:49:54 +0900

On Thu, Dec 12, 2013 at 2:04 AM, Dan Wing <[email-masked]> wrote:

> needed if the IPv6 network has simple security (RFC6092).
>

Actually it isn't necessarily needed.

If two parties establish a bidirectional stream (which in the case of a
voice or video call they will), then each endpoint's outgoing packets to
the other endpoint will punch a hole in its firewall that allows the other
endpoint's packets to come in, and you don't need ICE for anything.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Dec 2013 11:11:51 -0500

Le 2013-12-16 01:49, Lorenzo Colitti a écrit :
>     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).
>
>
> the other endpoint will punch a hole in its firewall that allows the
> other endpoint's packets to come in, and you don't need ICE for anything.

What you describe is ICE, is it not?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca