1. EN3020 - Digital System Design
Group Project
NAT64 SERVER
D.P.G.S.R Fernando 080104U
I.U. Liyanage 080269D
J.R.Kodagoda 080238H
R.S.A De Silva 080073v
2. OVERVIEW
Our core objective is to build an interface which connects a set of ipv4 clients to a set of ipv6
servers and vice versa. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal
with the long-anticipated problem of IPv4 running out of addresses. Until IPv6 completely
supplants IPv4, a number of transition mechanisms are needed to enable IPv6-only hosts to
reach IPv4 services and to allow isolated IPv6 hosts and networks to reach each-other over
IPv4-only infrastructure. NAT64 is a mechanism used for such needs and is valuable in present.
PROCEDURE
Work flow of our project is as follows.
Implementing the Tri-mode Ethernet mac-wrapper
Implement the IPv4 to IPv6 conversion algorithm
Implemented the IPv6 to IPv4 conversion algorithm
Combine two algorithms to get the NAT64 module
3. Tri-Mode Ethernet MAC-Wrapper
First of all, we had to implement the Ethernet MAC layer in a FPGA evaluation board. But soft-
Ethernet MAC cores are not freely available. Therefore we had to use either Vertex 5 or Vertex
6 in which Ethernet MAC cores are available. Therefore we had to choose Vertex 5 from the
three choices, Virtex-5, Virtex-2 and Altera.
But in order to make the core functional, we had to use tri-mode Ethernet MAC-wrapper which
is free in the Xilinx Core generator.
Tri-Mode Ethernet MAC wrapper consists of 2 components.
Block Level Wrapper
Local Link Wrapper
o rx_client_fifo
o tx_client_fifo
rx_client_fifo
The rx_client_fifo is built around 2 Dual Port block RAMs, providing a total memory capacity of
4096 bytes of frame data. The receive FIFO writes in data received through the Ethernet MAC. If
4. the frame is marked as good, that frame is presented on the LocalLink interface for reading by
the user. If the frame is marked as bad, that frame is dropped by the receive FIFO. If the receive
FIFO memory overflows, the frame currently being received is dropped, regardless of whether it
is a good or bad frame, and the signal rx_overflow is asserted.
tx_client_fifo
The tx_client_fifo is built around 2 Dual Port block RAMs, providing a total memory capacity of
4096 bytes of frame data. When a full frame has been written into the transmit FIFO, the FIFO
presents data to the MAC transmitter. On receiving the acknowledge signal from the Ethernet
MAC, the rest of the frame is transmitted providing there is no retransmit request output by
the Ethernet MAC. If a retransmission request is received, the frame is queued for
retransmission.
IPv4 to IPv6 Conversion Algorithm
Following diagram illustrates the timing diagram of an incoming IPv4 Ethernet packet and a
converted transmitting IPv6 packet.
Ethernet header is of 14 bytes and a IPv4 header is of 20 bytes in general but may greater than
that if optional fields exist. This is because IPv4 header is termed as ‘x’ bytes in the above
diagram. IPv6 header consists of a fixed amount 40 bytes. Our Verilog code reads a byte of data
in each clock cycle. We read the required fields of the IPv4 header and the Ethernet header
5. within 34 clocks and start sending the IPv6 packet after 36 clocks giving extra clock for data to
be ready to form the IPv6 packet.
IPv6 to IPv4 Conversion Algorithm
Following diagram illustrates the timing diagram of an incoming IPv6 Ethernet packet and a
converted transmitting IPv4 packet.
Verilog code reads the required fields of Ethernet and IPv4 header within 34 clocks and start
sending the IPv4 packet after 36 clocks. Here converted IPv4 header has only 20 bytes because
in our algorithm, we do not create optional fields for IPv4 header.
Header Mapping
IPv4 & IPv6 headers have similarities and dissimilarities though they are used as the layer three
protocols for IP communication. Therefore one to one mapping is impossible. Following table
shows similar fields used in IPv4 & IPv6 headers though have termed using different names.
Ether Type is a layer two field which is used to indicate the layer 3 protocol.
IPv4IPV4 IPv6
Ether Type: 0x0800 Ether Type:0x86dd
Version = 4 Version = 6
DSCP, ECN Traffic class
Header Length, Total Length Payload Length
6. Protocol Next Header
Time to Live Hop Limit
Ipv4 address Ipv6 address
Static NAT Table
A NAT64 server can be implemented on two ways: static & dynamic. We chose static mapping
mechanism and the following table illustrates how mapping is done between IPv4 & IPv6
addresses.
IPv4 IPv6
200.2.2.2 2000:2000:2000:2000:2000:2000:2000:2000
200.3.3.3 3000:3000:3000:3000:3000:3000:3000:3000
200.4.4.4 4000:4000:4000:4000:4000:4000:4000:4000
200.5.5.5 5000:5000:5000:5000:5000:5000:5000:5000
Default Source 200.6.6.6 6000:6000:6000:6000:6000:6000:6000:6000
Address
Broadcast Address 200.255.255.255 ff02::1
Multicast(to all hosts) 224.0.0.2 ff02::1
Multicast(to all 224.0.0.2 ff02::2
routers)
Unspecified 0.0.0.0 ::
Loopback Address 127.0.0.1 ::1
7. Hardware Debug Tools
ChipScope Pro Analyzer
We use ‘ChipScope Pro Inserter flow’ to capture signals of our project while the FPGA is
being in operation.
8. Wireshark
We used this packet sniffer software application to capture the sent and received packets in
our PC which acts as the IPv4 & IPv6 to test and identify problems in implementation.
Challenges
NAT64 server needs two ports to connect the IPv6 and IPv4 sides to the interface. But
Virtex-5 FPGA board consists only one Ethernet port. As a solution we implemented the
system only using the available port and same machine to be acted as IPv4 & IPv6 sides.
Virtex-5 device designs of Tri-mode Ethernet MAC require a Verilog LRM-IEEE 1364-2005
encryption - compliant simulator such as,
o ModelSIM v6.6d
o Cadence Incisive Enterprise Simulator(IES) 10.2
o Synopsys VCS and VCS MX 2010.06
None of these simulators have free versions. So, we did not perform functional or timing
simulations for our project. Instead, we had to use hardware debug tools. Hardware debugging
9. is time consuming because we had to synthesize, implement and generate the program file
each time we debug the design.
