Subject: [BEHAVE] comments on draft-xu-behave-hybrid-type-prefix-00

From: "Dan Wing" <[email-masked]>
Date: Mon, 8 Mar 2010 09:41:05 -0800

Hi.  I just read draft-xu-behave-hybrid-type-prefix-00 and had some comments,

* I am unclear on the motivation.  The content provider has deployed a NAT64
because the content provider was unable, or unwilling, to put native IPv6 on
the front-end server.  The content provider wants to create more work in the
IPv6 routing infrastructure (through the new 64::/16 prefix) and RIRs so that
the NAT64 is used by IPv6-only devices and not used by dual-stack devices.

* To be effective, I believe that this I-D requires the dual-stack clients to
modify their RFC3484 IPv6 address preferences to prefer IPv4 over 64::/16.
These dual-stack clients are on remote networks which aren't under the control
of the content provider (the content provider that has deployed the NAT64 and
is using the 64::/16 prefix).  But the I-D does not mention that requirement,
so perhaps I am misunderstanding.  Can this be clarified in email and in the
draft?

-d

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 8 Mar 2010 10:13:15 -0800

> so perhaps I am misunderstanding.  Can this be clarified in email and in the

Dan, what you are saying in the above point makes sense to me and we
can clarify the scenario in the in the I-D.

The genesis of the ideas arose from this thread, where we talk about
weak and strong WKP as well as a network hosting many NAT64 systems
while having the beneficial properties of WKP -- where the host knows
it is communicating via a NAT64 translator.

http://www.ietf.org/mail-archive/web/behave/current/msg07818.html

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 8 Mar 2010 10:31:11 -0800

> -----Original Message-----
> From: Cameron Byrne [mailto:[email-masked]] 
> Sent: Monday, March 08, 2010 10:13 AM
> To: Dan Wing
> Cc: behave; [email-masked]
> Subject: Re: [BEHAVE] comments on 
> draft-xu-behave-hybrid-type-prefix-00
> 

If I'm operating a bunch of dual-stack hosts, though, I may not
have an incentive to avoid the content provider's NAT64.  

For example, the diagram in the I-D shows:

                       +-----------------+
                       |                 |
      +------------+   | IPv6 Internet   |  +-----+  +------------+
      | Dual-stack +---+                 +--+NAT64+--+ IPv4-only  |
      |            |   +-----------------+  +-----+  |            |
      |   +----+   |                                 |   +----+   |
      |   | H1 |   |   +-----------------+           |   | H2 |   |
      |   +----+   +---+                 +-----------+   +----+   |
      +------------+   | IPv4 Internet   |           +------------+
                       |                 |
                       +-----------------+

but let's imagine, instead, the network with the dual-stack
hosts is behind a NAPT44, as shown in this diagram:

                      +-------------+
                      |             |
+----------+          |IPv6 Internet| +-----+ +---------+
|Dual-stack+----------+             +-+NAT64+-+IPv4-only|
|          |          +-------------+ +-----+ |         |
|  +----+  |                                  |  +----+ |
|  | H1 |  | +------+ +-------------+         |  | H2 | |
|  +----+  +-+NAPT44+-+             +---------+  +----+ |
+----------+ +------+ |IPv4 Internet|         +---------+
                      |             |
                      +-------------+

Such a client network lacks an incentive to avoid the content 
provider's NAT64.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Mar 2010 13:18:42 +1300

A couple of things occurred to me while reading this draft:

1. For the part of the problem caused by dual stack hosts
receiving synthetic AAAAs, the best solution would surely
to prevent this ever happening. There are two ways to do
that as far as I can see

(a) Arrange to configure them so that they only use DNS over IPv4.
(Yes, I can see all the objections to that, but a DNS64 is never
going to return a synthetic result over IPv4, is it?)

(b) A bit more painful: have the DNS64 check whether a requesting
host has IPv4 connectivity before returning a synthetic AAAA.

2. For the part of the problem of load-sharing among NAT64s,
maybe we shouldn't load share? Maybe we should in any case put the
NAT64 at an existing single point of failure for a suitably
large group of clients within the access network instead.

Just doing a hand-waving calculation, if we simplify by assuming
100 active ports/client, that means that about 650 v6-only clients
can share one public IPv4 address through a single NAT64. (That'll
be the same calculation for a NAT44 or an A+P box, for that
matter). That could be a fairly cheap box to locate inside the access
network.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Mar 2010 13:58:23 +1300

Somebody kindly pointed out that I misunderstood the
proposed application scenario for this.

If so, I'm sorry. But I'm  not sure our priority should
be to help scenarios in which service providers are unwilling
to upgrade their services.

Regards
   Brian Carpenter

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2010 12:05:34 +1100

> going to return a synthetic result over IPv4, is it?)

The DNS64 server may be being reached over NAT64.  There is no
requirement for the DNS64 server to be inside the IPv6 only network.
Just put mapped addresses into stub resolver configuration and it
will work.

> host has IPv4 connectivity before returning a synthetic AAAA.

How?

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 09 Mar 2010 09:29:55 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Dan
> Wing
> 发送时间: 2010年3月9日 2:31
> 收件人: 'Cameron Byrne'
> 抄送: [email-masked]; 'behave'
> 主题: Re: [BEHAVE] comments on draft-xu-behave-hybrid-type-prefix-00
> 
> 
> 

Hi Dan,

The following is quoted from draft-wing-behave-dns64-config-02:

      Note:  If both a NAT44 and NAT64 are deployed on the same network,
      roughly the same inefficiency occurs (that is, NAT state is
      created).  However, it is generally considered better to perform
      NAT44 than NAT64, because NAT64 translates between IP address
      families which can have side effects (e.g., FTP).

Does the quoted text make sense in the above scenario?

Best wishes,
Xiaohu

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 8 Mar 2010 17:43:08 -0800

> From: Xu Xiaohu [mailto:[email-masked]] 
> Sent: Monday, March 08, 2010 5:30 PM
> To: 'Dan Wing'; 'Cameron Byrne'
> Cc: [email-masked]; 'behave'
> Subject: re: [BEHAVE] comments on 

That quoted text refers to a different situation, when "both 
a NAT44 and NAT64 are deployed on the same network".  

If the case of draft-xu-behave-hybrid-type-prefix, they are
deployed on different networks:  the NAT44 is deployed in 
the network near the client, while the NAT64 is deployed in 
the network near the server.

I'm not seeing an incentive for the operator of network
on the left (with the dual-stack clients) to want to 
reconfigure their host's RFC3484 policy table to 
prioritize the 64::/16 prefix below native IPv4.

If you're saying the incentive is "some applications
will break", then that same problem exists for IPv6-only
clients, too.  And the content provider has the incentive
to fix their applications so they don't break.  If
the content provider does not fix their applications,
the content viewers will go elsewhere (and not view 
their advertising), or will abandon their IPv6 ISP 
and use IPv4.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Mar 2010 15:11:04 +1300

On 2010-03-09 14:05, Mark Andrews wrote:
> The DNS64 server may be being reached over NAT64.

That seems like a really weird scenario. Do we need to worry
about really weird scenarios?

  There is no
>> host has IPv4 connectivity before returning a synthetic AAAA.

ping

I am interested in the case where the DNS64, the NAT64, and the
host that benefits from them are all in the same network.

   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 8 Mar 2010 18:25:08 -0800

> large group of clients within the access network instead.

There is no existing single point of failure to speak of in my network
(unless you are talking cell tower radio).

Load sharing is critically important for the larger operators that 1)
want to absorb dramatic and sudden iphone like growth and 2) don't
want to be locked into having to buy the biggest box instead of buying
many small boxes at a lower cost per X. Scaling linearly is a critical
component of the NAT64 / DNS64 system.  I can in no way rely on the
some region of users (New York City) to be bound by "a box".
Finally, what i am seeking from load sharing goes beyond scaling, it
is also macro-network fault tolerance.  The ability to "swing" traffic
from one geographic array of NAT to another region.  This is not
possible with the current WKP, i cannot direct traffic to a specific
location.  NSP does support this, but i lose the benefits of WKP (host
knows its PREF64).

It is not reasonable to expect that a medium to large size service
provider that does NAT44 today can accept the current /96 WKP.  The
language in draft-ietf-behave-address-format-01 recommends using the
WKP, but it is only possible to be used in an enterprise or very small
network provider since WKP hampers the system from scaling.  Hence,
the HBT defines an larger prefix that is known to the host yet
facilitates macro network reliability and scalability via multiple
NAT64 systems.

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 09 Mar 2010 10:37:45 +0800

> -----邮件原件-----
> 发件人: Brian E Carpenter [mailto:[email-masked]]
> 发送时间: 2010年3月9日 10:11
> 收件人: Mark Andrews
> 抄送: Dan Wing; 'Cameron Byrne'; 'behave';
> [email-masked]

An alternative is to add a Flag (which suggests the client is a dual-stack
host) into the DNS query by the DNS client.

Xiaohu

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 8 Mar 2010 18:40:27 -0800

> Sent: Monday, March 08, 2010 6:25 PM
> To: Brian E Carpenter
> Cc: Dan Wing; 
> [email-masked]; behave

I now understand that the I-D's solution to its Problem Statement 1.1
("Communications Involving Dual-Stack Hosts") is for 64::/16 to be routed on
the Internet whereas the I-D's solution for its Problem Statement 1.2 ("Load
Balancing with WKP") is for 64:://16 to be kept inside an operator's network,
much like WKP is kept inside an operator's network.

The solution to scenario 1.2 ("Load Balancing with WKP"), where the 64::/16 is
kept inside the IPv6 network, is not adequately described in the current I-D.
For example, the current I-D explains the prefix in Section 3 and says 64::/16
can replace the NSP (the NSP is advertised on the Internet; it is the IPv6
provider's normal IPv6 prefix).

-d

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 09 Mar 2010 11:01:12 +0800

> -----邮件原件-----
> 发件人: Dan Wing [mailto:[email-masked]]
> 发送时间: 2010年3月9日 10:40
> 收件人: 'Cameron Byrne'
> 抄送: [email-masked]; 'behave'; 'Brian E
> Carpenter'
> 主题: RE: [BEHAVE] comments on draft-xu-behave-hybrid-type-prefix-00
> 
> 
> 

The WKP block defined in this draft is 64:FF9B::/80 which is a sub-set of the Hybrid Type Prefix block (i.e., 64::/16).

   The relationship among the Hybrid Type Prefix block, the WKP block
   and the strong WKP is shown in Figure 5:

                +-----------------------------------------+
                |   HTP Block 64::/16                     |
                | +----------------------------------+    |
                | | WKP Block 64:FF9B::/80           |    |
                | |  +-------------------------+     |    |
                | |  | Strong WKP 64:FF9B::/96 |     |    |
                | |  +-------------------------+     |    |
                | +----------------------------------+    |
                +-----------------------------------------+

> kept inside the IPv6 network, is not adequately described in the current I-D.

It is 64:FF9B::/80 which should be kept inside the IPv6 network in scenario 1.2 ("Load Balancing with WKP").

> provider's normal IPv6 prefix).

Yes, the prefixes of the 64::/16 block excluding 64:FF9B::/80 block could be assigned in a hierarchical way (e.g., IANA->RIRs->ISPs->Customers) to the customer IPv4 networks as an alternative to the NSP, and the routes to those HTP prefixes could be advertised into the IPv6 Internet. By the way, those HTP prefixes could be aggregated in provider networks.

Xiaohu

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2010 14:17:16 +1100

> about really weird scenarios?

Actually its quite realistic.  The DNS64 server can live anywhere.
The same with the NAT64.   This really no different to how ISP's
do their DNS service today.
 
> >> host has IPv4 connectivity before returning a synthetic AAAA.

Again how?  If you have a query arriving ove IPv4 it has IPv4 connectivity
for some definition of "connectivity".  If the query arrives over IPv6
there is no mapping general from IPv6 to IPv4 so where to you ping to?

> host that benefits from them are all in the same network.

I keep looking at the issues surrounding NAT64/DNS64 and I keep
looking at DS-lite and not seeing those issues for the IPv6 only
network with DS-lite.  DS-lite works with DNSSEC, DS-lite prefers
IPv6 when the remote end supports IPv6.  DS-lite doesn't have all
the issues introduce by translating IPv6 packets into IPv4 packets.

For the IPv4 only network supplying to supply a IPv6 presence to
the rest of the internet NAT64/DNS64 is still a reasonable way to
go though deploying application proxies for the services you want
to offer may be better and less error prone.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Mar 2010 09:53:49 +1300

Mark,

> do their DNS service today.

I've been assuming that there would be pretty strong operational
practices that would limit the placing of DNS64/NAT64 to
un-weird scenarios.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 10:33:04 +1100

> practices that would limit the placing of DNS64/NAT64 to

There is nothing wierd about a recursive server being outside the
network it serves.  This sort of configuration is common.  The rest
just flows from that and that the DNS64 may or may not have IPv6
connectivity.  IPv6 connectivity is not a requirement for it to
fulfil its role.  IPv4 connectivity however is until BCP 91 is
updated.

Mark