Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt

From: [email-masked]
Date: Sun, 08 Dec 2013 19:37:34 -0800

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/

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Dec 2013 17:52:52 +0000

Folks: we have been around this block several times, and I'd like to bring it to closure. This updates addresses comments raised in a WGLC in September. My objective is to determine whether there are any remaining issues, and if not, send it to the IESG. I would like to *not* find issues in the IETF WGLC coming from this community - I really want to deal with these here. So...

let's take until 20 December to discuss this - WGLC.

On Dec 8, 2013, at 7:37 PM, [email-masked] wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Dec 2013 16:10:45 +0900

I notice that this draft cites draft-ietf-v6ops-ula-usage-recommendations ,
which is still under discussion. I assume that means that even if this
document passes IETF last call and IESG review, it cannot be published as
an RFC until draft-ietf-v6ops-ula-usage-recommendations is ready to be
published.

The citation of draft-ietf-v6ops-ula-usage-recommendations doesn't seem to
be used for any particular purpose, it just seems to be mentioned in
passing. Authors - if you want this document to be published quickly, you
might want to remove the citation

On Thu, Dec 12, 2013 at 2:52 AM, Fred Baker (fred) <[email-masked]> wrote:

> Folks: we have been around this block several times, and I'd like to bring
> it to closure. This updates addresses comments raised in a WGLC in
> September. My objective is to determine whether there are any remaining
> issues, and if not, send it to the IESG. I would like to *not* find issues
> in the IETF WGLC coming from this community - I really want to deal with
> these here. So...
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 16 Dec 2013 07:49:24 +0000

On Dec 15, 2013, at 11:10 PM, Lorenzo Colitti <[email-masked]> wrote:

> I notice that this draft cites draft-ietf-v6ops-ula-usage-recommendations , which is still under discussion. I assume that means that even if this document passes IETF last call and IESG review, it cannot be published as an RFC until draft-ietf-v6ops-ula-usage-recommendations is ready to be published.
> 
> The citation of draft-ietf-v6ops-ula-usage-recommendations doesn't seem to be used for any particular purpose, it just seems to be mentioned in passing. Authors - if you want this document to be published quickly, you might want to remove the citation

True for normative references; this is informative, which the argument doesn't hold for.

The statement in the draft is

   Unique Local Addresses (ULAs) are defined in [RFC4193] to be
   renumbered within a network site for local communications.  Operators
   may use ULAs as NAT64 prefixes to provide site-local IPv6
   connectivity.  Those ULA prefixes are stripped when the packets going
   to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site.
   The use of ULAs could help in identifying the translation
   traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided
   further guidance for the ULAs usages.

what, specifically, is your objection?

> > ftp://ftp.ietf.org/internet-drafts/

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein

---

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

> what, specifically, is your objection?

I was referring to the text "[I-D.ietf-v6ops-ula-usage-recommendations] has
provided
   further guidance for the ULAs usages.". That document is not an RFC yet,
and I thought that it was inappropriate to cite it from other RFCs. If
you're saying that's not an issue, then that's fine.

That said, I think the document shouldn't say "has provided further
guidance" because we don't yet know what guidance will be. If anything it
should say "provides further guidance".

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 16 Dec 2013 17:12:36 +0000

On Dec 15, 2013, at 11:58 PM, Lorenzo Colitti <[email-masked]> wrote:

> I was referring to the text "[I-D.ietf-v6ops-ula-usage-recommendations] has provided
>    further guidance for the ULAs usages.". That document is not an RFC yet, and I thought that it was inappropriate to cite it from other RFCs. If you're saying that's not an issue, then that's fine.
> 
> That said, I think the document shouldn't say "has provided further guidance" because we don't yet know what guidance will be. If anything it should say "provides further guidance".

If your point is to make is say that it "may be of interest to the reader" or such, so be it. My point was that the rule you cited was inaccurately applied.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Dec 2013 15:35:08 -0500

> let's take until 20 December to discuss this - WGLC.

I read the draft carefully. Maybe it is because I have been involved in 
NAT64 since the start, but I found a lot of text to be evident or 
repeated from other RFCs. Anyway, I don't think this repetition is 
harmful, and could be useful for people new to NAT64. And there are a 
few new and useful nuggets. So go ahead and publish this.

Minor comments inline.

Simon

>
>
>
>
> Internet Engineering Task Force                                  G. Chen
> Internet-Draft                                                    Z. Cao
> Intended status: Informational                              China Mobile
> Expires: June 21, 2014                                            C. Xie
>                                                            China Telecom
>                                                                 D. Binet
>                                                    France Telecom-Orange
>                                                        December 18, 2013
>
>
>                       NAT64 Operational Experience
>                   draft-ietf-v6ops-nat64-experience-06
>
> Abstract
>
> Status of This Memo
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on June 21, 2014.
>
> Copyright Notice
>
>    Copyright (c) 2013 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 1]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
> Table of Contents
>
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
>    3.  NAT64 Networking Experience . . . . . . . . . . . . . . . . .   4
>      3.1.  NAT64-CGN Consideration . . . . . . . . . . . . . . . . .   4
>        3.1.1.  NAT64-CGN Usages  . . . . . . . . . . . . . . . . . .   4
>        3.1.2.  DNS64 Deployment  . . . . . . . . . . . . . . . . . .   4
>        3.1.3.  NAT64 Placement . . . . . . . . . . . . . . . . . . .   5
>        3.1.4.  Co-existence of NAT64 and NAT44 . . . . . . . . . . .   5
>      3.2.  NAT64-FE Consideration  . . . . . . . . . . . . . . . . .   6
>    4.  High Availability . . . . . . . . . . . . . . . . . . . . . .   7
>      4.1.  Redundancy Design . . . . . . . . . . . . . . . . . . . .   7
>      4.2.  Load Balancing  . . . . . . . . . . . . . . . . . . . . .   9
>    5.  Source Address Transparency . . . . . . . . . . . . . . . . .   9
>      5.1.  Traceability  . . . . . . . . . . . . . . . . . . . . . .   9
>      5.2.  Geo-location  . . . . . . . . . . . . . . . . . . . . . .  10
>    6.  Quality of Experience . . . . . . . . . . . . . . . . . . . .  11
>      6.1.  Service Reachability  . . . . . . . . . . . . . . . . . .  11
>      6.2.  Resource Reservation  . . . . . . . . . . . . . . . . . .  12
>    7.  MTU Considerations  . . . . . . . . . . . . . . . . . . . . .  13
>    8.  ULA Usages  . . . . . . . . . . . . . . . . . . . . . . . . .  14
>    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
>    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
>    11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
>    12. Additional Author List  . . . . . . . . . . . . . . . . . . .  15
>    13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
>      13.1.  Normative References . . . . . . . . . . . . . . . . . .  16
>      13.2.  Informative References . . . . . . . . . . . . . . . . .  18
>    Appendix A.  Testing Results of Application Behavior  . . . . . .  20
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21
>
> 1.  Introduction
>
>    IPv6 is the only sustainable solution for numbering nodes on Internet
>    due to the IPv4 depletion.  Network operators have to deploy
>    IPv6-only networks in order to meet the needs of the expanding
>    internet without available IPv4 addresses.
>
>    Single stack IPv6 network deployment can simplify network's

s/'s//

>    provisioning.  Some justifications have been described in 464xlat
>    [RFC6877].  As an example, IPv6-only connectivity confers some
>    benefits to mobile operators.  In such mobile context, it enables the
>    use of a single IPv6 Packet Data Protocol(PDP) context or Evolved
>    Packet System (EPS) bearer if Long Term Evolution (LTE) network is
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 2]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
>    considered, which eliminates significant network costs caused by
>    doubling the number of PDP contexts in some cases and the need of
>    IPv4 addresses to be assigned to customers.  In broadband networks
>    overall, it can allow for the scaling of edge-network growth
>    decoupled from IPv4 numbering limitations.
>
>    In a transition scenario, some existing networks are likely to be
>    IPv4-only configured for quite a long time.  IPv6 networks and hosts
>    will need to coexist with IPv4 numbered resources.  Widespread dual-
>    stack deployments have not materialized at the anticipated rate over
>    the last 10 years, one possible conclusion being that legacy networks
>    will not make the jump quickly.  The Internet will include nodes that
>    are dual-stack, nodes that remain IPv4-only, and nodes that can be
>    deployed as IPv6-only nodes.  A translation mechanism based on a
>    NAT64[RFC6146] [RFC6145]function is likely to be a key element of the
>    Internet for IPv6-IPv4 interoperability.
>
>    [RFC6036] reports at least 30% of operators plan to run some kind of
>    translator (presumably NAT64/DNS64).  Advice on NAT64 deployment and
>    operations are therefore of some importance.  [RFC6586] documents the
>    implications for IPv6 only networks.  This document intends to be
>    specific to NAT64 network planning.
>
> 2.  Terminology
>
>    In regards to IPv4/IPv6 translation, [RFC6144] has described a
>    framework of enabling networks to make interworking possible between
>    IPv4 and IPv6 networks.  This document has further categorized
>    different NAT64 function locations and use cases.  The principle
>    distinction of location is if the NAT64 is located in a Carrier Grade
>    NAT or server Front End. The terms of NAT-CGN/FE are understood to be
>    a topological distinction indicating different features employed in a
>    NAT64 deployment.
>
>    NAT64 Carrier Grade NAT (NAT64-CGN):  A NAT64-CGN is placed in an ISP
>       network.  IPv6 subscribers leverage the NAT64-CGN to access
>       existing IPv4 internet services.  The ISP as an administrative
>       entity takes full control on the IPv6 side, but has limited or no
>       control on the IPv4 side.  NAT64-CGN may have to consider the IPv4
>       Internet environment and services to make appropriate
>       configurations.
>
>    NAT64 server Front End (NAT64-FE):  A NAT64-FE is generally a device
>       with NAT64 functionality in a content provider or data center
>       network.  It could be for example a traffic load balancer or a
>       firewall.  The operator of the NAT64-FE has full control over the
>       IPv4 network within the data center, but only limited influence or
>       control over the external IPv6 network.
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 3]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
> 3.  NAT64 Networking Experience
>
> 3.1.  NAT64-CGN Consideration
>
> 3.1.1.  NAT64-CGN Usages
>
>    Fixed network operators and mobile operators may locate NAT64 in
>    access networks or in mobile core networks.  It can be built into
>    various devices, including routers, gateways or firewalls in order to
>    connect IPv6 users to the IPv4 Internet.  With regard to the numbers
>    of users and the shortage of public IPv4 addresses, stateful
>    NAT64[RFC6146] is more adapted to perform some maximal sharing of
>    public IPv4 addresses.  The usage of stateless NAT64 can be seen with
>    better transparency features
>    [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be
>    coordinated with A+P[RFC6346] processes as specified in
>    [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope

[I-D.ietf-softwire-4rd] now looks very unlike stateless NAT64. I suggest 
removing the reference and keeping only MAP-T, which uses regular 
RFC6145 translation.

>    with IPv4 shortage.
>
> 3.1.2.  DNS64 Deployment
>
>    DNS64[RFC6147] is recommended for use in combination with stateful
>    NAT64, and will likely be an essential part of an IPv6 single-stack
>    network that couples to the IPv4 Internet. 464xlat[RFC6877] is
>    proposed to enable access of IPv4 only applications or applications
>    that call IPv4 literal addresses.  Using DNS64 will help 464xlat to
>    automatically discover NAT64 prefix through [RFC7050].  Berkeley
>    Internet Name Daemon (BIND) software supports the function.  It's
>    important to note that DNS64 generates the synthetic AAAA reply when
>    services only register A records.  Operators should not expect to
>    access IPv4 parts of a dual-stack server using NAT64/DNS64.  The
>    traffic is forwarded on IPv6 paths if dual-stack servers are
>    targeted.  IPv6 traffic may be routed not going through NAT64.  Only
>    the traffic going to IPv4-only service would traverse NAT64.  In some
>    sense, it encourages IPv6 transmission and restrains NAT uses
>    compared to NAT44(if used), on which all traffic flows have to be
>    traversed and translated.  In some cases, NAT64-CGN may serve double
>    roles, i.e. a translator and IPv6 forwarder.  In mobile networks,
>    NAT64 is likely deployed as the default gateway serving for all the
>    IPv6 traffic.  The traffic heading to a dual-stack server is only
>    forwarded on the NAT64.  Therefore, both IPv6 and IPv4 are suggested
>    to be configured on the Internet faced interfaces of NAT64.  We
>    tested on Top100 websites (referring to [Alexa] statistics). 43% of
>    websites are connected and forwarded on the NAT64 since those
>    websites have both AAAA and A records.  With expansion of IPv6
>    supports, the translation process on NAT64 will likely be faded.
>
>
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 4]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
> 3.1.3.  NAT64 Placement
>
>    All connections to IPv4 services from IPv6-only clients must traverse
>    the NAT64-CGN.  It can be advantageous from the vantage-point of
>    troubleshooting and traffic engineering to carry the IPv6 traffic
>    natively for as long as possible within an access network and
>    translate packets only at or near the network egress.  NAT64 can be
>    considered as a feature of the Autonomous System (AS) border in fixed
>    networks.  And, it is likely to be deployed in an IP node beyond the
>    Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway
>    (PDN-GW) in mobile networks or directly in the gateway itself in some
>    situations.  This allows consistent attribution and traceability
>    within the service provider network.  It has been observed that the
>    process of correlating log information is problematic from multiple-
>    vendor's equipment due to inconsistent formats of log records.
>    Placing NAT64 in a centralized location may reduce diversity of log
>    format and simplify the network provisioning.  Moreover, since NAT64
>    is only targeted at serving traffic flows from IPv6 to IPv4-only
>    services, the user traffic volume should not be as high as in a NAT44
>    scenario, and therefore, the gateway's capacity in such location may
>    not be as much of a concern or a hurdle to deployment.  On the other
>    hand, the placement in a centralized way would require more strict
>    high availability (HA) design.  It would also make geo-location based
>    on IPv4 addresses rather inaccurate as it is currently the case for
>    NAT44 CGN already deployed in ISP networks.  More considerations or
>    workarounds on HA and traceability could be found at Section 4 and
>    Section 5.
>
> 3.1.4.  Co-existence of NAT64 and NAT44
>
>    NAT64 could likely co-exist with NAT44 in a dual-stack network mostly
>    because IPv4 private addresses are allocated to customers.  The
>    coexistence has already appeared in mobile networks, in which dual
>    stack mobile phones normally initiate some dual-stack PDN/PDP
>    Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated
>    addresses are very often private ones.  [RFC6724] always prioritizes
>    IPv6 connections regardless of whether the end-to-end path is native
>    IPv6 or IPv6 translated to IPv4 via NAT64/DNS64.  Conversely, Happy
>    Eyeballs[RFC6555] will direct some IP flows across IPv4 paths.  The
>    selection of IPv4/IPv6 paths may depend on particular implementation
>    choices or settings on a host-by-host basis, and may differ from an
>    operator's deterministic scheme.  Our tests verified that hosts may
>    find themselves switching between IPv4 and IPv6 paths as they access
>    identical service, but at different times
>    [I-D.kaliwoda-sunset4-dual-ipv6-coexist].  Since the topology on each
>    path is different, it may cause unstable user experiences and some
>    degradation of Quality of Experience (QoE) when fallback to the other
>    protocol is not powerful enough.  It's also difficult for operators
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 5]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
>    to find a solution to make a stable network with optimal resource
>    utilization.  In general, it's desirable to figure out the solution
>    that will introduce IPv6/IPv4 translation service to IPv6-only hosts
>    connecting to IPv4 servers while making sure dual-stack hosts to have
>    at least one address family accessible via native service if it's
>    possible.  With the end-to-end native IPv6 environment is available,
>    hosts should be upgraded aggressively to migrate to IPv6-only.  There
>    is an ongoing effort to detect host connectivity and propose new
>    DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate
>    configuration information to the hosts.
>
> 3.2.  NAT64-FE Consideration
>
>    Some Internet Content Providers (ICPs) may locate NAT64 in front of
>    an Internet Data Center (IDC), for example co-located with load
>    balancing function.  Load balancers are employed to connect different
>    IP family domains, meanwhile distribute workloads across multiple
>    domains or internal servers actually.  In some cases, IPv4 addresses
>    exhaustion may not be a problem in some IDC's networks.  IPv6 support
>    for some applications may require some investments and workloads so
>    IPv6 support may not be a priority.  The use of NAT64 may be served
>    to support widespread IPv6 adoption on the Internet while maintaining
>    IPv4-only applications access.
>
>    Different strategy has been described in [RFC6883]referred to as
>    "inside out" and "outside in".  An IDC operator may implement the
>    following practices in the NAT64-FE networking.
>
>    o  Some ICPs who already have satisfactory operational experiences
>       would adopt single stack IPv6 operations to build up their data
>       center network, servers and applications since it allows new
>       services delivery without having to integrate consideration of
>       IPv4 NAT and address limitations of IPv4 networks.  Stateless
>       NAT64[RFC6145]is used to provide services for IPv4-only
>       subscribers.  [I-D.anderson-siit-dc]has provided further
>       descriptions and guidelines.
>
>    o  ICPs who attempt to offer customers IPv6 support in their
>       application farms at an early stage may likely run some proxies,
>       which are configured to handle incoming IPv6 flows and proxy them
>       to IPv4 back-end systems.  Many load balancers have already
>       integrated some proxy functionality.  IPv4 addresses configured in
>       the proxy can be multiplexed like a stateful NAT64 performs.  A
>       similar challenge exists once increasingly numerous users in IPv6
>       Internet access an IPv4 network.  High loads on load-balancers may
>       be apt to cause additional latency, IPv4 pool exhaustion, etc.
>       Therefore, this approach is only reasonable at an early stage.
>       ICPs may learn from the experiences and move on to dual-stack or
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 6]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
>       IPv6 single stack in a further stage, since the native IPv6 is
>       always more desirable than transition solutions.
>
>    [RFC6144] recommends that AAAA records of load-balancers or
>    application servers can be directly registered in the authoritative
>    DNS servers requiring to populate these servers with corresponding
>    AAAA records.  In this case, there is no need to deploy DNS64
>    servers.  Those AAAA records can be some native IPv6 addresses or
>    some IPv4-converted IPv6 addresses[RFC6052].  The type of IPv6
>    address does not give the possibility to nodes to get any information
>    about NAT64 presence on communication path and the possibility to
>    prefer IPv4 path or the IPv6 path in dual-stack networks.  For the
>    testing purpose, operators could use an independent sub domain e.g.
>    ipv6exp.xxx.xxx to identify experimental ipv6 services to users.  How
>    to design the FQDN for the IPv6 service is out-of-scope of this
>    document.
>
> 4.  High Availability
>
> 4.1.  Redundancy Design
>
>    High Availability (HA) is a major requirement for every service and
>    network services.  The deployment of redundancy mechanism is an
>    essential approach to avoid single-point failure and significantly
>    increase the network reliability.  It's not only useful to stateful
>    NAT64 cases, but also to stateless NAT64 gateways.
>
>    Three redundancy modes are mainly used hereafter: cold standby, warm
>    standby and hot standby.
>
>    o  Cold standby can't replicate the NAT64 states from the primary
>       equipment to the backup.  Administrators switch on the backup
>       NAT64 only if the primary NAT64 fails.  As the results, all the
>       existing established sessions will be disconnected.  The internal
>       hosts are required to re-establish sessions to the external hosts.
>       Since the backup NAT64 is manually configured to switch over to
>       active NAT64, it may have unpredictable impacts to the ongoing
>       services.  Normally, the handover would take several minutes so as
>       to wait for the whole process of NAT64 bootstrap loader.
>
>    o  Warm standby is a flavor of the cold standby mode.  Backup NAT64
>       would keep running once the primary NAT64 is working.  This makes
>       warm standby less time consuming during the traffic failover.
>       Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a
>       solution to enable automatic handover in the warm standby.  It was
>       tested that the handover takes as maximum as 1 minute if the
>       backup NAT64 needs to take over routing and re-construct the
>       Binding Information Bases (BIBs) for 30 million sessions.  In
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 7]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
>       deployment phase, operators could balance loads on distinct NAT64s
>       devices.  Those NAT64s make a warm backup of each other.
>
>    o  Hot standby must synchronize the BIBs between the primary NAT64
>       and backup.  When the primary NAT64 fails, backup NAT64 would take
>       over and maintain the state of all existing sessions.  The
>       internal hosts don't have to re-connect the external hosts.  The
>       handover time has been extremely reduced.  Thanks to Bidirectional
>       Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay
>       of only 35ms for 30 million sessions handover was observed during
>       testing.  In some sense, it could guarantee the session continuity
>       for every service.  In order to timely transmit session states,
>       operators may have to deploy extra transport links between primary
>       NAT64 and distant backup.  The scale of synchronization data
>       instance is depending on the particular deployment.  For example,
>       If a NAT64-CGN is served for 200,000 users, the average amount of
>       800, 000 sessions per second is roughly estimated for new created
>       and expired sessions.  A 10Gbps transport link should be used for
>       the sync data transmission.

This last recommendation needs to be qualified. There are deployments 
where less than 10 Gbps is plenty.

>
>    In general, cold-standby and warm-standby is simpler and less
>    resource intensive, but it requires clients to re-establish sessions
>    when a fail-over occurs.  Hot standby doubles resource's consumption

"doubles" --> This can vary considerably from one implementation to 
another. This assertion needs to be qualified.

In addition, there is at least one implementation that allows both the 
main and the standby to forward traffic simultaneously, approximately 
doubling the effective capacity when both machines are up. In that case, 
state synchronization is bidirectional.

>    to synchronize the states, but it achieve seamless handover.  The
>    consideration of redundancy mode for stateless NAT64 is simple,
>    because it doesn't have to consider time consuming for states
>    maintenance.  The warm standby is sufficient for stateless NAT64.  In

"Warm standby" does not apply to stateless NAT64 since there is no state 
synchronization. I would suggest to rephrase as: "State synchronization 
is unnecessary for stateless NAT64."

>    regards to stateful NAT64, it may be useful to investigate
>    performance tolerance of applications and the traffic characteristics
>    in a particular network.  Some testing results are shown in the
>    Appendix A.
>
>    Our statistics in a mobile network shown that almost 91.21% of amount
>    of traffic is accounted by browsing services.  Those services don't
>    require session continuity.  The handover time of warm standby is
>    qualified to the delay tolerance.  Hot-standby does not offer much
>    benefit for those sessions on this point.  In a fixed network, HTTP
>    streaming, p2p and online games would be the major
>    traffic[Cisco-VNI].  Consideration should be given to the importance
>    of maintaining bindings for those sessions across failover.
>    Operators may also consider the Average Revenue Per User (ARPU)
>    factors to deploy suitable redundancy mode.  Warm standby may still
>    be adopted to cover most services while hot standby could be used to
>    upgrade Quality of Experience (QoE) using DNS64 with different
>    synthetic responses for limited traffic.  Further considerations are
>    discussed at Section 6.
>
>
>
>
>
> Chen, et al.              Expires June 21, 2014                 [Page 8]
> 
> Internet-Draft              NAT64 Experience               December 2013
>
>
> 4.2.  Load Balancing
>
>    Load balancing is used to accompany redundancy design so that better
>    scalability and resiliency could be achieved.  Stateless NAT64s allow
>    asymmetric routing while anycast-based solutions are recommended in
>    [I-D.ietf-softwire-map-deployment].  The deployment of load balancing
>    may make more sense to stateful NAT64s for the sake of single-point
>    failure avoidance.  Since the NAT64-CGN and NAT64-FE have distinct
>    facilities, the following lists the considerations for each case.
>
>    o  NAT64-CGN equipment doesn't implement load balancer functions on a
>       board card.  Therefore, the gateways have to resort to DNS64 or
>       internal host's behavior.  Once DNS64 is deployed, the load
>       balancing can be performed by synthesizing AAAA response with
>       different IPv6 prefixes.  For the applications not requiring DNS
>       resolver, internal hosts could learn multiple IPv6 prefixes
>       through the approaches defined in[RFC7050] and then select one
>       based on a given prefix selection policy.

There is at least one implementation that allows both the main and the 
standby to forward traffic simultaneously, with bidirectional state 
synchronization. (I don't know if one can build a farm of >2 such 
machines.) This is one form of load balancing that should be mentioned here.

>    o  A dedicated Load Balancer could be deployed at front of a NAT64-FE
>       farm.  Load Balancer uses proxy mode to redirect the flows to the
>       appropriate NAT64 instance.  Stateful NAT64s require a
>       deterministic pattern to arrange the traffic in order to ensure
>       outbound/inbound flows traverse the identical NAT64.  Therefore,
>       static scheduling algorithms, for example source-address based
>       policy, is preferred.  A dynamic algorithm, for example Round-
>       Robin, may have impacts on applications seeking session
>       continuity, which described in the Table 1.

I doubt that this is a valid load balancing method. For a fixed amount 
of traffic, it is less work to apply NAT64 than to apply load balancing.

That's all!

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

---

From: GangChen <[email-masked]>
Date: Fri, 20 Dec 2013 14:01:18 +0800

> few new and useful nuggets. So go ahead and publish this.

Thank you for the comments and review. Please see my reply inline.

> where less than 10 Gbps is plenty.

10Gbps is evaluated considering the amount of session at the peak and
link capacity redundancy during the deployment.
The transmitted amount of sync session at the peak is testified as
around 1.3Gbps. If the redundancy ratio of 0.5 is considered, the
transport link should have around 2.6Gpbs capacity.
However, a physical transport link only has very specific capacity,
for example 10Gbps, 2.5Gbps, 155M
Therefore, 10Gbps may have to be selected as the physical transport
link capacity.

We could qualify the statement by adding specific conditions

OLD
=============
 A 10Gbps transport link should be used for the sync data transmission.

NEW
============
A physical 10Gbps transport link may have to be deployed for the sync
data transmission considering the amount of sync sessions at the peak
and link capacity redundancy.

> another. This assertion needs to be qualified.

"doubles" is evaluated because the mapping state should be stored at
both the primary and backup equipment.
As you point out, that is depending on the implementation. we could
change the sentence as

==NEW
Hot standby increases resource's consumption

> state synchronization is bidirectional.

That will be mentioned at load balance section as below.

> is unnecessary for stateless NAT64."

There is a mistake. I will correct the statement as you suggested.

> machines.) This is one form of load balancing that should be mentioned

The changes are

   o  NAT64-CGN could balance loads on the primary and the backup equipment.
      Those NAT64s may make bidirectional state synchronization for each other.
      The load balance can also resort to DNS64 or
      internal host's behavior.  Once DNS64 is deployed, the load
      balancing can be performed by synthesizing AAAA response with
      different IPv6 prefixes.  For the applications not requiring DNS
      resolver, internal hosts could learn multiple IPv6 prefixes
      through the approaches defined in[RFC7050] and then select one
      based on a given prefix selection policy.		

> of traffic, it is less work to apply NAT64 than to apply load balancing.

That is a common practice in a data center because a load balancer is
normally deployed.
Load balancer could distribute the traffic to different NAT64
according to the configured scheduling algorithms. So we just document
it as is.

BRs

Gang

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 Dec 2013 08:35:38 -0500

> Thank you for the comments and review. Please see my reply inline.

Thanks. I'm OK with the proposed changes.

Simon