Subject: [BEHAVE] real addresses versus x, y, z notation in nat64 walkthrough

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 Jan 2010 23:34:57 +0100

Hi,

Dave suggested to change the x,y,z notation used in the nat64 
wlakthrough to real IP addresses. I attach both formats so people can 
comment what you preffer.

Please let me know what you think:

x,y,z notation:

1.2.2.  Stateful NAT64 Behaviour Walkthrough

   In this section we provide a simple example of the NAT64 behaviour.
   We consider an IPv6 node located in an IPv6-only site that initiates
   a TCP connection to an IPv4-only node located in the IPv4 network.

   The notation used is the following: upper case letters are IPv4
   addresses; upper case letters with a prime(') are IPv6 addresses;
   lower case letters are ports; prefixes of length n are indicated by
   "P::/n", an IPv6 address built from an IPv4 address X by adding the
   prefix P::/96 is indicated as "P:X", mappings are indicated as "(X,x)
   <--> (Y',y)".

   The scenario for this case is depicted in the following figure:

             +---------------------+         +---------------+
             |IPv6 network         |         |    IPv4       |
             |           |  +-------------+  |  Network      |
             |           |--| Name server |--|               |
             |           |  | with DNS64  |  |  +----+       |
             |  +----+   |  +-------------+  |  | H2 |       |
             |  | H1 |---|         |         |  +----+       |
             |  +----+   |      +-------+    |  IP addr: X   |
             | IP addr:Y'|------| NAT64 |----|               |
             |           |      +-------+    |               |
             |           |         |         |               |
             +---------------------+         +---------------+

   The figure above shows an IPv6 node H1 with an IPv6 address Y' and an
   IPv4 node H2 with IPv4 address X. H2 has h2.example.com as FQDN.

   A NAT64 connects the IPv6 network to the IPv4 network.  This NAT64
   has a /96 prefix (called Pref64::/96) that it uses to represent IPv4

Bagnulo, et al.           Expires July 20, 2010                 [Page 8]

Internet-Draft               Stateful NAT64                 January 2010

   addresses in the IPv6 address space and a single IPv4 address T
   assigned to its IPv4 interface.  The routing is configured in such a
   way that the IPv6 packets addressed to a destination address in
   Pref64::/96 are routed to the IPv6 interface of the NAT64 device.

   Also shown is a local name server with DNS64 functionality.  The
   local name server needs to know the /96 prefix assigned to the local
   NAT64 (Pref64::/96).  For the purpose of this example, we assume it
   learns this through manual configuration.

   For this example, assume the typical DNS situation where IPv6 hosts
   have only stub resolvers and the local name server does the recursive
   lookups.

   The steps by which H1 establishes communication with H2 are:

   1.  H1 performs a DNS query for h2.example.com and receives the
       synthetic AAAA RR from the local name server that implements the
       DNS64 functionality.  The AAAA record contains an IPv6 address
       formed by the Pref64::/96 associated to the NAT64 and the IPv4
       address of H2 (i.e.  Pref64:X).

   2.  H1 sends a TCP SYN packet to H2.  The packet is sent from a
       source transport address of (Y',y) to a destination transport
       address of (Pref64:X,x), where y and x are ports set by H1.

   3.  The packet is routed to the IPv6 interface of the NAT64 (since
       IPv6 routing is configured that way).

   4.  The NAT64 receives the packet and performs the following actions:

       *  The NAT64 selects an unused port t on its IPv4 address T and
          creates the mapping entry (Y',y) <--> (T,t)

       *  The NAT64 translates the IPv6 header into an IPv4 header using
          the IP/ICMP Translation Algorithm
          [I-D.ietf-behave-v6v4-xlate].

       *  The NAT64 includes (T,t) as source transport address in the
          packet and (X,x) as destination transport address in the
          packet.  Note that X is extracted directly from the
          destination IPv6 address of the received IPv6 packet that is
          being translated.  The destination port x of the translated
          packet is the same as the destination port of the received
          IPv6 packet.

Bagnulo, et al.           Expires July 20, 2010                 [Page 9]

Internet-Draft               Stateful NAT64                 January 2010

   5.  The NAT64 sends the translated packet out its IPv4 interface and
       the packet arrives at H2.

   6.  H2 node responds by sending a TCP SYN+ACK packet with destination
       transport address (T,t) and source transport address (X,x).

   7.  Since the IPv4 address T is assigned to the IPv4 interface of the
       NAT64 device, the packet is routed to the NAT64 device, which
       will look for an existing mapping containing (T,t).  Since the
       mapping (Y',y) <--> (T,t) exists, the NAT64 performs the
       following operations:

       *  The NAT64 translates the IPv4 header into an IPv6 header using
          the IP/ICMP Translation Algorithm
          [I-D.ietf-behave-v6v4-xlate].

       *  The NAT64 includes (Y',y) as destination transport address in
          the packet and (Pref64:X,x) as source transport address in the
          packet.  Note that X is extracted directly from the source
          IPv4 address of the received IPv4 packet that is being
          translated.  The source port x of the translated packet is the
          same as the source port of the received IPv4 packet.

   8.  The translated packet is sent out the IPv6 interface to H1.

   The packet exchange between H1 and H2 continues and packets are
   translated in the different directions as previously described.

   It is important to note that the translation still works if the IPv6
   initiator H1 learns the IPv6 representation of H2's IPv4 address
   (i.e., Pref64:X) through some scheme other than a DNS look-up.  This
   is because the DNS64 processing does NOT result in any state
   installed in the NAT64 and because the mapping of the IPv4 address
   into an IPv6 address is the result of concatenating the prefix
   defined within the site for this purpose (i.e., Pref64::/96) to the
   original IPv4 address.

IP address notation

1.2.2.  Stateful NAT64 Behaviour Walkthrough

   In this section we provide a simple example of the NAT64 behaviour.
   We consider an IPv6 node located in an IPv6-only site that initiates
   a TCP connection to an IPv4-only node located in the IPv4 network.

   The scenario for this case is depicted in the following figure:

             +---------------------+         +---------------+
             |IPv6 network         |         |    IPv4       |
             |           |  +-------------+  |  Network      |
             |           |--| Name server |--|               |
             |           |  | with DNS64  |  |  +----+       |
             |  +----+   |  +-------------+  |  | H2 |       |
             |  | H1 |---|         |         |  +----+       |
             |  +----+   |      +-------+    |  192.0.2.1    |
             |2001:DB8::1|------| NAT64 |----|               |
             |           |      +-------+    |               |
             |           |         |         |               |
             +---------------------+         +---------------+

   The figure above shows an IPv6 node H1 with an IPv6 address 2001:
   DB8::1 and an IPv4 node H2 with IPv4 address 192.0.2.1.  H2 has
   h2.example.com as FQDN.

   A NAT64 connects the IPv6 network to the IPv4 network.  This NAT64
   uses the Well-Know Prefix 64:FF9B::/96 defined
   [I-D.ietf-behave-address-format] to represent IPv4 addresses in the
   IPv6 address space and a single IPv4 address 203.0.113.1 assigned to
   its IPv4 interface.  The routing is configured in such a way that the
   IPv6 packets addressed to a destination address in 64:FF9B::/96 are

Bagnulo, et al.           Expires July 20, 2010                 [Page 8]

Internet-Draft               Stateful NAT64                 January 2010

   routed to the IPv6 interface of the NAT64 device.

   Also shown is a local name server with DNS64 functionality.  The
   local name server uses the Well-Know prefix 64:FF9B::/96 to create
   the IPv6 addresses in the synthetic RRs.

   For this example, assume the typical DNS situation where IPv6 hosts
   have only stub resolvers and the local name server does the recursive
   lookups.

   The steps by which H1 establishes communication with H2 are:

   1.  H1 performs a DNS query for h2.example.com and receives the
       synthetic AAAA RR from the local name server that implements the
       DNS64 functionality.  The AAAA record contains an IPv6 address
       formed by the Well-Known Prefix and the IPv4 address of H2 (i.e.
       64:FF9B::192.0.2.1).

   2.  H1 sends a TCP SYN packet to H2.  The packet is sent from a
       source transport address of (2001:DB8::1,1500) to a destination
       transport address of (64:FF9B::192.0.2.1,80), where the ports are
       set by H1.

   3.  The packet is routed to the IPv6 interface of the NAT64 (since
       IPv6 routing is configured that way).

   4.  The NAT64 receives the packet and performs the following actions:

       *  The NAT64 selects an unused port e.g. 2000 on its IPv4 address
          203.0.113.1 and creates the mapping entry (2001:DB8::1,1500)
          <--> (203.0.113.1,2000)

       *  The NAT64 translates the IPv6 header into an IPv4 header using
          the IP/ICMP Translation Algorithm
          [I-D.ietf-behave-v6v4-xlate].

       *  The NAT64 includes (203.0.113.1,2000) as source transport
          address in the packet and (192.0.2.1.,80) as destination
          transport address in the packet.  Note that 192.0.2.1. is
          extracted directly from the destination IPv6 address of the
          received IPv6 packet that is being translated.  The
          destination port 80 of the translated packet is the same as
          the destination port of the received IPv6 packet.

   5.  The NAT64 sends the translated packet out its IPv4 interface and
       the packet arrives at H2.

Bagnulo, et al.           Expires July 20, 2010                 [Page 9]

Internet-Draft               Stateful NAT64                 January 2010

   6.  H2 node responds by sending a TCP SYN+ACK packet with destination
       transport address (203.0.113.1,2000) and source transport address
       (192.0.2.1.,80).

   7.  Since the IPv4 address 203.0.113.1 is assigned to the IPv4
       interface of the NAT64 device, the packet is routed to the NAT64
       device, which will look for an existing mapping containing
       (203.0.113.1,2000).  Since the mapping (2001:DB8::1,1500) <-->
       (203.0.113.1,2000) exists, the NAT64 performs the following
       operations:

       *  The NAT64 translates the IPv4 header into an IPv6 header using
          the IP/ICMP Translation Algorithm
          [I-D.ietf-behave-v6v4-xlate].

       *  The NAT64 includes (2001:DB8::1,1500) as destination transport
          address in the packet and (64:FF9B::192.0.2.1,80) as source
          transport address in the packet.  Note that 192.0.2.1. is
          extracted directly from the source IPv4 address of the
          received IPv4 packet that is being translated.  The source
          port 80 of the translated packet is the same as the source
          port of the received IPv4 packet.

   8.  The translated packet is sent out the IPv6 interface to H1.

   The packet exchange between H1 and H2 continues and packets are
   translated in the different directions as previously described.

   It is important to note that the translation still works if the IPv6
   initiator H1 learns the IPv6 representation of H2's IPv4 address
   (i.e., 64:FF9B::192.0.2.1) through some scheme other than a DNS
   look-up.  This is because the DNS64 processing does NOT result in any
   state installed in the NAT64 and because the mapping of the IPv4
   address into an IPv6 address is the result of concatenating the Well-
   Known Prefix to the original IPv4 address.

---

From: Dave Thaler <[email-masked]>
Date: Sun, 17 Jan 2010 04:22:28 +0000

Just to start the responses, I prefer the IP notation. :)

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of marcelo bagnulo braun
> Sent: Saturday, January 16, 2010 2:35 PM
> To: Behave WG
> Subject: [BEHAVE] real addresses versus x, y, z notation in nat64
> walkthrough
> 
> Hi,
> 

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