Subject: NAT64 support in CPE?

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Nov 2008 13:53:11 -0600

Fred,

I looked over draft-baker-behave-v4v6-framework-00 again, but I  
couldn't find any place where the CPE would perform any actions to  
enable NAT64 or make NAT64 work better. Did I miss something?

There are some DNS64 corner cases, but in general I don't believe CPEs  
would have to do anything to make a NAT64 type solution work.

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Nov 2008 14:30:51 -0600

On Nov 18, 2008, at 1:53 PM, Iljitsch van Beijnum wrote:

> There are some DNS64 corner cases, but in general I don't believe  
> CPEs would have to do anything to make a NAT64 type solution work.

For those that miss the referent, look at
http://tools.ietf.org/html/draft-baker-behave-v4v6-framework
   "Framework for IPv4/IPv6 Translation", Fred Baker, 26-Oct-08,
   <draft-baker-behave-v4v6-framework-00.txt>

The case that comes quickly to mind is the second case discussed in  
1.5.1. The following is cut/paste from the draft:

                    ----------
                 ///          \\\
                //    IPv6      \\              192.168.1.0/24
              //      ISP         \\    +------+2001:db8:0:1::0/64
             |/                    \|   |      +---------------
             |  Allocates           |   |      |
            |   2001:db8::/60 to     |  |CPE   |192.168.2.0/24
            |   Customer             |  |Router|2001:db8:0:2::0/64
            |                        +--+      +---------------
            |   Doesn't know it,     |  |      |
             |  but sees customer   |   |      |192.168.3.0/24
             |\ IPv4 as            /|   |      |2001:db8:0:3::0/64
              \\2001:db8::a.b.c.d //    |      +---------------
                \\              //      +------+
                 \\\          ///
                    ----------     LIR prefix is 2001:db8::0/96

                    Figure 2: Customer dual stack network

    Figure 2 creates transition options to a customer network connected
    to an IPv6-only ISP, or some equivalent relationship.  The customer
    might internally be using traditional IPv4 with NAT services, and  
the
    ISP might change its connection to an IPv6-only network and  
encourage
    it to transition.  If the ISP assigns a /60 prefix to a SOHO, for
    example, the CPE router in the SOHO could distribute several dual
    stack subnets internally, one for wireless and one for each of
    several fixed LANs (the entertainment system, his office, her  
office,
    etc).  One of the /64 prefixes would be dedicated to representing  
the
    SOHO's IPv4 addresses in the ISP or the IPv4 network beyond it, and
    the other prefixes for the various internal subnets.  Internally,  
the
    subnets might carry prefix pairs 192.168.n.0/24 and 2001:db8:0.n::/ 
64
    for n in 1..15 (1..0xF), and externally might appear as 2001:db8:0:
    n::/64 for the IPv6 subnets and 2001:db8::192.168.n.0/120 for the
    IPv4 devices.  Note that to connect to an IPv4-only network beyond,
    RFC 1918 addresses would have to be statefully mapped using
    traditional IPv4 mechanisms somewhere; if this is done by the ISP,
    collusion on address mapping is required, and the case in
    Section 1.5.4 is probably a better choice.

    In this environment, the key issue is that one wants a prefix that
    enables the entire [RFC1918] address space to be embedded in a  
single
    /64 prefix, with the assumption that any routing structure behind  
the
    translator is managed by IPv4 routing.

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Nov 2008 14:33:17 -0600

> enable NAT64 or make NAT64 work better. Did I miss something?

By the way, as I recall the outcome of the Montreal interim, the  
question isn't "nat64", it is "the outcome of behave", which is a  
merger of IVI and NAT64. Did you understand differently?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Nov 2008 14:44:37 -0600

> merger of IVI and NAT64. Did you understand differently?

I just use "NAT64" as "any type of translation between IPv6 clients  
and IPv4 servers" here because I only have limited room for fast  
changing terminology in my head...

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Nov 2008 15:14:09 -0600

> changing terminology in my head...

:-)