Re: NAT64 support in CPE?

[Fred Baker <fred@cisco.com>]

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

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

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.