Technical data
16 ServerIron ADX NAT64 Configuration Guide
53-1002288-02
Configuring Packet fragmentation with IPv6-only client to IPv4 resource
2
DRAFT: BROCADE CONFIDENTIAL
After insertion, the HTTP request will be:
GET /abc/index.html HTTP 1/0\r\n
Host: foo.com\r\n
…
Connection: Keep-Alive\r\n
X-Forwarded-For: 2001:db8::6401:101\r\n
\r\n
No automatic detection of HTTP traffic
Client IP address insertion needs to be enabled for the port running HTTP traffic. The ServerIron
ADX will not automatically detect HTTP traffic on any port.
Insertion to the first request
A client IP address will only be inserted for the first HTTP request, in a TCP connection. This means
that for a keep-alive or pipelined request, the client IP address header is inserted for the first
request but not for subsequent requests.
Enabling HTTP client IP address insertion
You can configure HTTP client IP insertion and configure the http header name through the nat64
http-client-ip-insertion port command. This is configured as shown.
ServerIron ADX(config) nat64 http-client-ip-insertion
Syntax: [no] nat64 http-client-ip-insertion {port <port> | acl <acl-name>} <header-string>
This command enables you to configure HTTP client IP insertion.
Enabling this command with the port option directs client IP insertion for the <port> specified by its
decimal value.
Optionally, you can use the acl option to direct client IP insertion as defined by the ACL that is
specified by the <acl-name> variable.
If enabled without specifying a <port> or <acl-name>, client IP insertion will be enabled for HTTP
port 80 and the header name will be “X-Forwarded-For”.
A customized header can be be added by specifying one for the <header> variable. In The following
example, the ServerIron ADX is configured to insert “NAT64-CLIENT-IP” in a request to an IPv4
server as the header instead of the default header of “X-Forwarded-For”.
ServerIron ADX(config) nat64 http-client-ip-insertion port 80 “NAT64-CLIENT-IP”
Configuring Packet fragmentation with IPv6-only client to IPv4
resource
Reverse packets from the IPv4 server to the IPv6 client can be too large and need to be split into
two IPv6 packets. The following describes the criteria for judging that packets are too large: