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

[Simon Perreault <[e-mail]>]

Le 2013-12-11 12:52, Fred Baker (fred) a écrit :
> 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
>
>    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.
>
> 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