Browse Source

include pdfs instead of png

Signed-off-by: Nico Schottelius <nico@nico-notebook.schottelius.org>
master
Nico Schottelius 3 years ago
parent
commit
38c3b9f850
  1. 1
      doc/.gitignore
  2. 21
      doc/Abstract.tex
  3. 2
      doc/Background.tex
  4. 416
      doc/Design.tex
  5. 9
      doc/Makefile
  6. BIN
      doc/Thesis.pdf
  7. 1
      doc/Thesis.tex
  8. BIN
      doc/graphviz/arp-ndp.png
  9. BIN
      doc/graphviz/dns64.png
  10. BIN
      doc/graphviz/dualstack.png
  11. BIN
      doc/graphviz/icmp6ndp.png
  12. BIN
      doc/graphviz/netpfgadesign.png
  13. BIN
      doc/graphviz/networkdesignnat64.png
  14. BIN
      doc/graphviz/softwarenat64design.png
  15. BIN
      doc/graphviz/statefulnat64.png
  16. BIN
      doc/graphviz/switchdesign.png
  17. BIN
      doc/graphviz/v4only.png
  18. BIN
      doc/graphviz/v6-v4-innetwork.png
  19. BIN
      doc/graphviz/v6-v4-mixed.png
  20. BIN
      doc/graphviz/v6-v4-standard.png
  21. BIN
      doc/graphviz/v6-v6-separated.png
  22. BIN
      doc/graphviz/v6only.png
  23. 4
      doc/preamble.tex

1
doc/.gitignore vendored

@ -10,3 +10,4 @@ plan.tex
Thesis.bbl
Thesis.blg
Thesis.blg
abc.dot

21
doc/Abstract.tex

@ -7,21 +7,22 @@
\begin{center}\textbf{Abstract}\end{center}
Due to the lack of IPv4 addresses, IPv6 deployments have recently
gained in importance in the Internet.
Several transition mechanisms exist that allow translating IPv6
packets into IPv4 packets, thus enabling the coexistence
and interoperability of both protocols.
Several transition mechanisms exist that include
translating IPv6 packets into IPv4 packets,
thus enabling the coexistence and interoperability of both protocols.
This thesis describes an implementation of the transition mechanism
NAT64 implemented in P4. Using the P4 programming language
This thesis describes an implementation of the translation mechanism
NAT64, implemented in P4. Using the P4 programming language
a software emulated switch was created that translates IPv4 to IPv6 and vice versa.
Due to the target independence of P4 the same code can be compiled
for and deployed to on the FPGA hardware platform ``NetFPGA''.
for and deployed to the FPGA hardware platform ``NetFPGA''.
Within the NetFPGA the NAT64 implementation achieves a stable throughput of
9.29 Gigabit/s and allows in-network translations without a
router. Due to the nature of P4, the implementation runs at line speed
and thus with different hardware the same code can run potentially at
much higher speeds, for instance on 100 Gbit/s switches.
9.28 Gigabit/s. Our solution allows in-network translations without a
router or client configurations. Due to the nature of P4, the
implementation runs at line speed and thus with different hardware
the same code can run potentially at much higher speeds,
for instance on 100 Gbit/s switches.
%% P4. P4 is protocol and target independent and allo
%% P4 is a protocol independent programming language that allows programming network

2
doc/Background.tex

@ -21,7 +21,7 @@ parser will read and parse in the ingress pipeline one protocol
\caption{P4 protocol independence~\cite{vanbever:_progr_networ_data_planes}}
\label{fig:p4fromnsg}
\end{figure}
The \textit{target independence} is the second very powerful feature
The \textit{target independence} is the second strong feature
of P4: it allows code to be compiled to different targets. While in
theory the P4 code should be completely target independent, in reality,
there are some modifications needed on a per-target basis and each

416
doc/Design.tex

@ -2,141 +2,16 @@
%** Design.tex: How was the problem attacked, what was the design
% the architecture
In this chapter we describe the architecture of our solution and our
design choices.
design choices. We first introduce the general design of NAT64 in the
P4 architecture. Afterwards we describe the design differences
for the BMV2 and NetFPGA P4 architectures. Afterwards we discuss the
design of stateless and stateful NAT64 in relation to P4 an well as
two existing software NAT64 solutions.
Lastly we discuss how we verify NAT64 functionality present
the network configurations that we use.
% ----------------------------------------------------------------------
\section{\label{design:configuration}IPv6 and IPv4 configuration}
The following sections refer to host and network configurations. In
this section we describe the IPv6 and IPv4 configurations as a basis
for the discussion.
All IPv6 addresses are from the documentation block
\textit{2001:DB8::/32}~\cite{rfc3849}. In particular the following sub
networks and IPv6 addresses are used:
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
\hline
\textbf{Address} & \textbf{Description} \\
\hline
2001:db8:42::/64 & IPv6 host network \\
\hline
2001:db8:23::/96 & IPv6 mapping to the IPv4 Internet \\
\hline
2001:db8:42::42 & IPv6 host address \\
\hline
2001:db8:42::77 & IPv6 router address \\
\hline
2001:db8:42::a00:2a & In-network IPv6 address mapped to 10.0.0.42 (p4)\\
\hline
2001:db8:23::a00:2a & IPv6 address mapped to 10.0.0.42 (tayga) \\
\hline
2001:db8:23::2a & IPv6 address mapped to 10.0.0.42 (jool)\\
\hline
\end{tabular}
\end{minipage}
\caption{IPv6 address and network overview}
\label{tab:ipv6address}
\end{center}
\end{table}
We use private IPv4 addresses as specified by RFC1918~\cite{rfc1918}
from the 10.0.0.0/8 range as follows:
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
\hline
\textbf{Address} & \textbf{Description} \\
\hline
10.0.0.0/24 & IPv4 host network \\
\hline
10.0.1.0/24 & IPv4 network mapping to IPv6\\
\hline
10.0.0.77 & IPv4 router address\\
\hline
10.0.0.66 & In-network IPv4 address mapped to 2001:db8:42::42 (p4)\\
\hline
10.0.1.42 & IPv4 address mapped to 2001:db8:42::42 (tayga)\\
\hline
10.0.1.66 & IPv4 address mapped to 2001:db8:42::42 (jool)\\
\hline
\end{tabular}
\end{minipage}
\caption{IPv4 address and network overview}
\label{tab:ipv4address}
\end{center}
\end{table}
% ok
% ----------------------------------------------------------------------
\section{\label{design:tests}NAT64 Verification}
We use socat~\cite{rieger:_multip} to verify basic operation of the
NAT64 gateway and iperf~\cite{dugan:_tcp_udp_sctp} to test stability
of the implementation and measure bandwidth.
In particular we use
the commands listed in table \ref{tab:nat64verification}. The socat
commands allow interactive testing on TCP and UDP connections, while
the iperf commands fully utilise the available bandwidth with test
data.
The socat and iperf commands are used to verify all three NAT64
implementations (p4, tayga, jool).
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c |}
\hline
\textbf{Command} & \textbf{Example} & \textbf{Description} \\
\hline
\texttt{socat - TCP6:HOST:PORT} & socat -
TCP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/TCP\\
& & to IPv4 host\\
%\hline
\texttt{socat - UDP6:HOST:PORT} & socat -
UDP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/UDP \\ & & to IPv4 host\\
%\hline
\texttt{socat - TCP:HOST:PORT} & socat -
TCP:10.0.1.42:2345 & Connect via IPv4/TCP \\ & & to IPv6 host \\
%\hline
\texttt{socat - UDP:HOST:PORT} & socat -
UDP:10.0.1.42:2345 & Connect via IPv4/UDP \\ & & to IPv6 host \\
\hline
\texttt{socat - UDP6-LISTEN:PORT} & socat -
UDP6-LISTEN:2345 & Listen on IPv6/UDP \\
%\hline
\texttt{socat - TCP6-LISTEN:PORT} & socat -
TCP6-LISTEN:2345 & Listen on IPv6/TCP \\
%\hline
\texttt{socat - UDP-LISTEN:PORT} & socat -
UDP-LISTEN:2345 & Listen on IPv4/UDP \\
%\hline
\texttt{socat - TCP-LISTEN:PORT} & socat -
TCP-LISTEN:2345 & Listen on IPv4/TCP \\
\hline
\texttt{iperf3 -PROTO -p PORT} & iperf3 -4 -p 2345 & IPv4 iperf server\\
\texttt{-B IP -s} & -B 10.0.0.42 -s &\\
& iperf3 -6 -p 2345 & IPv6 iperf server\\
& -B 2001:db8:42::42 -s & \\
\hline
\texttt{iperf3 -PROTO -p PORT } & iperf3 -6 -p 2345& Connect to iperf server\\
\texttt{-O IGNORETIME -t RUNTIME} & -O 10 -t 190 &
Run for 190 seconds, \\
& & skip first 10 seconds\\
\texttt{-P PARALLEL -c IP} & -P20 -c 2001:db8:23::2a &
with 20 sessions\\
& & connecting to\\
& & 2001:db8:23::2a\\
\texttt{iperf3 -PROTO -p PORT} & & Same as above,\\
\texttt{-O IGNORETIME -t RUNTIME} & & but connect via UDP\\
\texttt{-P PARALLEL -c IP} & & \\
\texttt{-u -b0} & & \\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 verification commands}
\label{tab:nat64verification}
\end{center}
\end{table}
% ----------------------------------------------------------------------
\section{\label{design:nat64}NAT64 with P4}
\section{\label{design:nat64}P4/NAT64}
\begin{figure}[h]
\includegraphics[scale=0.4]{switchdesign}
\centering
@ -189,75 +64,15 @@ segment.
\caption{In-network NAT64 translation}
\label{fig:v6v4mixed}
\end{figure}
% ----------------------------------------------------------------------
\section{\label{design:statelessnat64}Stateless NAT64}
As seen in section \ref{background:transition:stateless}, stateless
NAT64 can be implemented using various factors. Our design for the
stateless depends on the capabilities of the environment and is
summarised in table \ref{tab:statelessnat64factors}.
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
\hline
\textbf{Implementation} & \textbf{NAT64 match}\\
\hline
P4/BMV2 & LPM (both directions)\\
& and individual entries (both directions)\\
\hline
P4/NetPFGA & Individual entries\\
\hline
Tayga & LPM (IPv6 to IPv4) and individual entries (IPv4 to IPv6)\\
\hline
Jool & LPM (both directions)\\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 match factors}
\label{tab:statelessnat64factors}
\end{center}
\end{table}
When using LPM for translating from IPv6 to IPv4, a /96 IPv6 network
is configured for covering the whole IPv4 Internet and the individual
IPv4 address is appended to the prefix (compare section
\ref{design:configuration}). We also use LPM to match on an IPv4 sub
network that translates to an IPv6 sub network. Individual
entries are configured differently depending on the implementation:
Limitations in the P4/NetFPGA environment require to use table
entries. Jool supports individual entries as a special case of LPM,
with a network mask matching only one IP address. Tayga
support LPM for translation from IPv6 to IPv4, but requires individual
entries for translating from IPv4 to IPv6. Our P4/BMV2 offers the
highest degree of flexibility, as it provides support for individual
entries based on table entries and LPM table entries.
% ----------------------------------------------------------------------
\section{\label{design:statefulnat64}Stateful NAT64}
Similar to stateless NAT64, the design of stateful NAT64 depends on
the features of the individual implementation. As pointed out in section
\ref{background:transition:statefulnat64}, stateful NAT64 is very
similar to stateless NAT64, with the main difference being an
additional stateful table that helps to create 1:n mappings.
We use different approaches within the implementations
to solve this problem:
\begin{itemize}
\item For P4/BMV2 and P4/NetPFGA a python controller handles packets
that don't have a table entry, sets the table entry in the P4 switch
and inserts the original packet afterwards back into the switch.
\item With tayga we rely on the Linux kernel NAT44 capabilities
\item Jool implements its own stateful mechanism based on a port
ranges
\end{itemize}
All methods though operate in a very similar fashion: A ``controller''
inspects the IPv6 packet and depending on the source address,
destination address, protocol (TCP, UDP,
ICMP, ICMP6, etc.) and the protocol ID (source / destination TCP/UDP
port, ICMP identifier) it selects an outgoing IPv4 address, and source
port or ICMP identifier.
In case of Jool and Tayga this decision is based on a session table
inside the Linux kernel, in case of P4 this decision is based on a
session table inside the python controller. While the Jool and Tayga
both support cleaning up old session entries,
our P4 based solution does not support this feature at the moment.
\section{\label{design:nat64:indepth}P4/NAT64}
P4 switches in general look very similar to regular switches, however
support executing logic while the packet passes through the switch.
When a packet enters the switch,
\digraph[scale=0.5]{abc}{rankdir=LR; a->b->c;}
% ----------------------------------------------------------------------
\section{\label{design:bmv2}P4/BMV2}
\begin{figure}[h]
@ -391,4 +206,203 @@ It is notable that
not the full headers are used, but only a ``pseudo header'' (compare figures
\ref{fig:ipv6pseudoheader} and \ref{fig:ipv4pseudoheader}).
% ok
% ----------------------------------------------------------------------
\section{\label{design:statelessnat64}Stateless NAT64}
As seen in section \ref{background:transition:stateless}, stateless
NAT64 can be implemented using various factors. Our design for the
stateless depends on the capabilities of the environment and is
summarised in table \ref{tab:statelessnat64factors}.
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
\hline
\textbf{Implementation} & \textbf{NAT64 match}\\
\hline
P4/BMV2 & LPM (both directions)\\
& and individual entries (both directions)\\
\hline
P4/NetPFGA & Individual entries\\
\hline
Tayga & LPM (IPv6 to IPv4) and individual entries (IPv4 to IPv6)\\
\hline
Jool & LPM (both directions)\\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 match factors}
\label{tab:statelessnat64factors}
\end{center}
\end{table}
When using LPM for translating from IPv6 to IPv4, a /96 IPv6 network
is configured for covering the whole IPv4 Internet and the individual
IPv4 address is appended to the prefix (compare section
\ref{design:configuration}). We also use LPM to match on an IPv4 sub
network that translates to an IPv6 sub network. Individual
entries are configured differently depending on the implementation:
Limitations in the P4/NetFPGA environment require to use table
entries. Jool supports individual entries as a special case of LPM,
with a network mask matching only one IP address. Tayga
support LPM for translation from IPv6 to IPv4, but requires individual
entries for translating from IPv4 to IPv6. Our P4/BMV2 offers the
highest degree of flexibility, as it provides support for individual
entries based on table entries and LPM table entries.
% ----------------------------------------------------------------------
\section{\label{design:statefulnat64}Stateful NAT64}
Similar to stateless NAT64, the design of stateful NAT64 depends on
the features of the individual implementation. As pointed out in section
\ref{background:transition:statefulnat64}, stateful NAT64 is very
similar to stateless NAT64, with the main difference being an
additional stateful table that helps to create 1:n mappings.
We use different approaches within the implementations
to solve this problem:
\begin{itemize}
\item For P4/BMV2 and P4/NetPFGA a python controller handles packets
that don't have a table entry, sets the table entry in the P4 switch
and inserts the original packet afterwards back into the switch.
\item With tayga we rely on the Linux kernel NAT44 capabilities
\item Jool implements its own stateful mechanism based on a port
ranges
\end{itemize}
All methods though operate in a very similar fashion: A ``controller''
inspects the IPv6 packet and depending on the source address,
destination address, protocol (TCP, UDP,
ICMP, ICMP6, etc.) and the protocol ID (source / destination TCP/UDP
port, ICMP identifier) it selects an outgoing IPv4 address, and source
port or ICMP identifier.
In case of Jool and Tayga this decision is based on a session table
inside the Linux kernel, in case of P4 this decision is based on a
session table inside the python controller. While the Jool and Tayga
both support cleaning up old session entries,
our P4 based solution does not support this feature at the moment.
% ----------------------------------------------------------------------
\section{\label{design:tests}NAT64 Verification}
We use socat~\cite{rieger:_multip} to verify basic operation of the
NAT64 gateway and iperf~\cite{dugan:_tcp_udp_sctp} to test stability
of the implementation and measure bandwidth.
In particular we use
the commands listed in table \ref{tab:nat64verification}. The socat
commands allow interactive testing on TCP and UDP connections, while
the iperf commands fully utilise the available bandwidth with test
data.
The socat and iperf commands are used to verify all three NAT64
implementations (p4, tayga, jool).
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c |}
\hline
\textbf{Command} & \textbf{Example} & \textbf{Description} \\
\hline
\texttt{socat - TCP6:HOST:PORT} & socat -
TCP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/TCP\\
& & to IPv4 host\\
%\hline
\texttt{socat - UDP6:HOST:PORT} & socat -
UDP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/UDP \\ & & to IPv4 host\\
%\hline
\texttt{socat - TCP:HOST:PORT} & socat -
TCP:10.0.1.42:2345 & Connect via IPv4/TCP \\ & & to IPv6 host \\
%\hline
\texttt{socat - UDP:HOST:PORT} & socat -
UDP:10.0.1.42:2345 & Connect via IPv4/UDP \\ & & to IPv6 host \\
\hline
\texttt{socat - UDP6-LISTEN:PORT} & socat -
UDP6-LISTEN:2345 & Listen on IPv6/UDP \\
%\hline
\texttt{socat - TCP6-LISTEN:PORT} & socat -
TCP6-LISTEN:2345 & Listen on IPv6/TCP \\
%\hline
\texttt{socat - UDP-LISTEN:PORT} & socat -
UDP-LISTEN:2345 & Listen on IPv4/UDP \\
%\hline
\texttt{socat - TCP-LISTEN:PORT} & socat -
TCP-LISTEN:2345 & Listen on IPv4/TCP \\
\hline
\texttt{iperf3 -PROTO -p PORT} & iperf3 -4 -p 2345 & IPv4 iperf server\\
\texttt{-B IP -s} & -B 10.0.0.42 -s &\\
& iperf3 -6 -p 2345 & IPv6 iperf server\\
& -B 2001:db8:42::42 -s & \\
\hline
\texttt{iperf3 -PROTO -p PORT } & iperf3 -6 -p 2345& Connect to iperf server\\
\texttt{-O IGNORETIME -t RUNTIME} & -O 10 -t 190 &
Run for 190 seconds, \\
& & skip first 10 seconds\\
\texttt{-P PARALLEL -c IP} & -P20 -c 2001:db8:23::2a &
with 20 sessions\\
& & connecting to\\
& & 2001:db8:23::2a\\
\texttt{iperf3 -PROTO -p PORT} & & Same as above,\\
\texttt{-O IGNORETIME -t RUNTIME} & & but connect via UDP\\
\texttt{-P PARALLEL -c IP} & & \\
\texttt{-u -b0} & & \\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 verification commands}
\label{tab:nat64verification}
\end{center}
\end{table}
% ----------------------------------------------------------------------
\section{\label{design:configuration}IPv6 and IPv4 configuration}
The following sections refer to host and network configurations. In
this section we describe the IPv6 and IPv4 configurations as a basis
for the discussion.
All IPv6 addresses are from the documentation block
\textit{2001:DB8::/32}~\cite{rfc3849}. In particular the following sub
networks and IPv6 addresses are used:
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
\hline
\textbf{Address} & \textbf{Description} \\
\hline
2001:db8:42::/64 & IPv6 host network \\
\hline
2001:db8:23::/96 & IPv6 mapping to the IPv4 Internet \\
\hline
2001:db8:42::42 & IPv6 host address \\
\hline
2001:db8:42::77 & IPv6 router address \\
\hline
2001:db8:42::a00:2a & In-network IPv6 address mapped to 10.0.0.42 (p4)\\
\hline
2001:db8:23::a00:2a & IPv6 address mapped to 10.0.0.42 (tayga) \\
\hline
2001:db8:23::2a & IPv6 address mapped to 10.0.0.42 (jool)\\
\hline
\end{tabular}
\end{minipage}
\caption{IPv6 address and network overview}
\label{tab:ipv6address}
\end{center}
\end{table}
We use private IPv4 addresses as specified by RFC1918~\cite{rfc1918}
from the 10.0.0.0/8 range as follows:
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
\hline
\textbf{Address} & \textbf{Description} \\
\hline
10.0.0.0/24 & IPv4 host network \\
\hline
10.0.1.0/24 & IPv4 network mapping to IPv6\\
\hline
10.0.0.77 & IPv4 router address\\
\hline
10.0.0.66 & In-network IPv4 address mapped to 2001:db8:42::42 (p4)\\
\hline
10.0.1.42 & IPv4 address mapped to 2001:db8:42::42 (tayga)\\
\hline
10.0.1.66 & IPv4 address mapped to 2001:db8:42::42 (jool)\\
\hline
\end{tabular}
\end{minipage}
\caption{IPv4 address and network overview}
\label{tab:ipv4address}
\end{center}
\end{table}
% ok

9
doc/Makefile

@ -3,16 +3,21 @@ FILE = Thesis
all: all-graphviz
pdflatex $(FILE)
dot -Tpdf -o abc.pdf abc.dot
bibtex $(FILE)
makeindex Thesis.nlo -s nomencl.ist -o Thesis.nls
pdflatex $(FILE)
pdflatex $(FILE)
clean:
rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~ *.ilg *.nlo *.nls *.out *.glo
rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~ *.ilg *.nlo *.nls *.out *.glo graphviz/*.png graphiz/*.pdf
all-graphviz:
for dot in graphviz/*.dot; do make $${dot%%.dot}.png; done
#for dot in graphviz/*.dot; do make $${dot%%.dot}.png; done
for dot in graphviz/*.dot; do make $${dot%%.dot}.pdf; done
graphviz/%.png: graphviz/%.dot
dot -Tpng < $< > $@
graphviz/%.pdf: graphviz/%.dot
dot -Tpdf < $< > $@

BIN
doc/Thesis.pdf

Binary file not shown.

1
doc/Thesis.tex

@ -36,6 +36,7 @@
\listoffigures
\listoftables
\includepdf[pages=-]{declaration-of-orginality.pdf}
\include{Introduction}
\include{Background}
\include{Design}

BIN
doc/graphviz/arp-ndp.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 37 KiB

BIN
doc/graphviz/dns64.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 69 KiB

BIN
doc/graphviz/dualstack.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 24 KiB

BIN
doc/graphviz/icmp6ndp.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.4 KiB

BIN
doc/graphviz/netpfgadesign.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
doc/graphviz/networkdesignnat64.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

BIN
doc/graphviz/softwarenat64design.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.2 KiB

BIN
doc/graphviz/statefulnat64.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

BIN
doc/graphviz/switchdesign.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.8 KiB

BIN
doc/graphviz/v4only.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/graphviz/v6-v4-innetwork.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

BIN
doc/graphviz/v6-v4-mixed.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

BIN
doc/graphviz/v6-v4-standard.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
doc/graphviz/v6-v6-separated.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 37 KiB

BIN
doc/graphviz/v6only.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

4
doc/preamble.tex

@ -137,4 +137,6 @@
\makeatother
\fi
%\usepackage[pdf]{graphviz}
\usepackage[pdf]{graphviz}
\usepackage{pdfpages}

Loading…
Cancel
Save