Internet-Draft Kuniaki Kondo Expiration Date: March 2002 IIJ November 2001 Network Address Translation with Sub-Address(NATS) 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract Networks which are using IPv4 addresses are using the address translation technologies such as NAT[1] at end-networks for various reasons. However, those technologies sometimes prevent two-way transparently communications. This document will define a way to enhance address translation technologies such as NAT. This way will be able to communicate transparently by adding a sub-address to IPv4. This enhancement will be called 'NATS'(Network Address Translation with Sub-Address) in this document. Kuniaki NATS [Page 1] Internet-Draft November 2001 2. Overview This enhancement has the following two advantages: a) The use of NATS is limited to use for end-networks which are usually connected by NAT router. b) The use of NATS will be easier to implement for a router and a host. Implementation of the NATS needs minor changes for application softwares and network equipments including dial-up routers which are connected to end-networks. This enhancement adds 16 bits of sub-address space for each IPv4 address. This sub-address space is added to the IPv4 option header. The option header includes a source sub-address field and a destination sub-address field. When a host or a router which do not support the NATS receive a NATS supported packet, these packets will be ignored without supporting the NATS. In this way, when the NATS is implemented, the NATS supported equipments maintains interoperability with the NATS non-supported equipments. 3. Identification of the NATS supported packets The NATS packets will be identified by checking the IPv4 Option header. When the header includes the NATS option and the equipment supports the NATS, the equipment has to process the NATS option header. However, a backbone router which is connected by a high-bandwidth line don't care about the NATS option. In the following this document will define behavior of a router and a host, when they receive the NATS supported and non-supported packets. Kuniaki NATS [Page 2] Internet-Draft November 2001 4. IP Option Header Format Copied Flag : copied : 1 Option Class : Control : 0 Option Number : Not Defined : N/A Option Length : Fixed : 8 Octets - Option Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 100nnnn | 00001000 | Type | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/C: Not Care: This field is filled out 0x00. 4.1 Type Field The type field specifies the type number of the data field. The type number describes: 0: Sub-address This type is used for normal data communications. The data field is separated 16 bits source sub-address(SSA) field and 16 bits destination sub-address(DSA) field. Data field format describes: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSA | DSA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kuniaki NATS [Page 3] Internet-Draft November 2001 1: Sub-Address Discovery This type is used at searching a sub-address which described in the SA field to a connected network. When a host want to know the sub-address which is connected the local network, the host should send the packet to the connected network using this message. The host should wait to receive a response packet. Expire time for response is optional. However, this time may set 30seconds for default. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2: Sub-Address Response This type is used for response of the "Sub-Address Discovery". When the sub-address included SA field of the "Sub-Address Discovery" packet which is sent by the broadcast is a same as local sub-address, the received host should send this response packet to the source host. This packet defined a local sub-address in the SA field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. The Range of Sub Address The sub-address has 16 bits of address space and it can use from 0 to 65535. However, the following sub-address is reserved. 0x0000: Unknown Sub Address(USA) Kuniaki NATS [Page 4] Internet-Draft November 2001 6. Equipment behavior 6.1 Hosts When a host sends a request packet to make connection, if the following criterias are matched, then the host has to add the NATS option header. 1. An application specifies a destination sub-address using the way of described in section 6 except that the destination sub-address is USA. 2. An application specifies a destination sub-address using the dynamically address expression. A host has to reply using NATS packet when the host receives a NATS packet to make connection. However, if a NATS supported host is not assigned sub-address, then the host never send NATS packets. 6.2 Routers 6.2.1 Function of the NATS routers The NATS router have to keep a sub-address table. It records local IP addresses for sub-address. When SSA value of received a NATS supported packet from connected network is not match with the sub-address table in the router, the router processes the packets as the received packets is correct. 6.2.2 Mechanisms of DNS query hooking by NATS routers A NATS router should be implemented mechanism what the router hooks DNS queris from local network. The purpose of this mechanism is when a NATS non-supported host is connected on local network, a NATS router helps that the NATS non-supported host can connect to a NATS supported host using NATS protocol. This mechanism is described in below. 1. A NATS supported router should hook DNS queries from local network. The host which is connected on local network may be configured that DNS is the NATS router ideally. If the host is not configured, then the NATS router should also hook DNS query. Kuniaki NATS [Page 5] Internet-Draft November 2001 2. When the NATS router receives DNS query to search A RR, its query should be hooked and send a query to actual DNS instead of the local host. At this time, the NATS router requests to search both of A RR and HINFO RR. 3. If the NATS router can get HINFO RR and IP address and sub-address describes in HINFO RR, the NATS router identifies the object of the query as the NATS supported host. 4. If the NATS router identifies the object of the query as the NATS supported host by the answer of DNS query, the NATS router assigns a virtual IP address which should be configured as NATS spool address in NATS router for the object, and store a pair of the real IP address, sub-address and virtual IP address. Next, the NATS router answers A RR and HINFO RR to local host. However, this A RR contains virtual IP address. 5. A NATS non-supported host will try to connect using virtual IP address, when the host communicates with a host which is connected global address network. When the NATS router receives those packets, it translates virtual IP address into global IP address to refer the table which is stored in the NATS router. And next, the NATS router sends the translated packet to global address network. Furthermore, the NATS router has to translate source IP address in a return packet from a destination host into the virtual IP address. 6.2.3 Behavior of the NATS router - When the NATS router receives the NATS supported packet from the WAN interface, it refers to the internal sub-address table and the packet will be sent to appropriate host which is placed in the local network. If destination host which is defined in the DSA field can not be found in the sub-address table, then the router broadcast the "Sub-Address Discovery" to the local network for resolving DSA. After the router sent the "Sub-Address Discovery" packet, it should wait a response packet during 15 seconds, in generally. If the router wait a response packet over 15 seconds, then it should send an ICMP_UNREACH/ICMP_UNREACH_HOST_UNKNOWN message to the source host. - When the NATS router receives the NATS non-supported packet from the WAN interface, the packet will be sent to a default host. When the default host is not configured, the router send ICMP_UNREACH/ICMP_UNREACH_HOST_UNKNOWN message to the source host. Kuniaki NATS [Page 6] Internet-Draft November 2001 - When the NATS router receives the NATS supported packet from the LAN interface, the packet will be sent to the destination host without changing the packet. At this time, the router has to change the IPv4 source address to the WAN interface IP address. - When the NATS router receives the NATS non-supported packet from the LAN interface, the router refers to the sub-address table and SSA change to referred sub-address and DSA change to USA and sent the packet. This SSA value has to reserved in the NATS router. If this reserve address do not configured, then the NATS router should send an ICMP_UNREACH/ICMP_UNREACH_HOST_UNKNOWN message to the source host. 7. Address Expression - Dynamically address expression !example.com will be described in decimal. For future reference: When the host doesn't support the NATS, to resolve the name by DNS, FQDN is used "!example.com". In this case, "!example.com" is registered to DNS 'A' record, the host can resolve the gateway IPv4 address which is used by the destination network. This is not a substantial improvement. However, from the making connection by best effort point of view, it is important. Therefore, the author suggests that the NATS host registers to DNS in this way. - By name expression Address resolution with the sub-address is done by normal DNS resolution. When the host resolve sub-address, it refers to the HINFO resource record. The HINFO resource record format is following: hostname HINFO "/SUBA:!/" "" In this format, from '/SUBA:' to '/' describes the sub-address and IP Address. Excepting this format is ignored. This format should be identified and placed anywhere in the HINFO resource record. Actually, the HINFO resource record has two fields, 'CPU Information' and 'OS Information'. This format should be identified on either field. When there are two or more sub-address statements, the first statement will be identified. Kuniaki NATS [Page 7] Internet-Draft November 2001 The host can resolve the sub-address to refer HINFO resource record of DNS by hostname. 8. Acknowledgements Thanks to Toshiya Asaba, Ikuo Nakagawa, Ryo Shimizu, Kiyoshi Ishida, Tomokazu Takizawa, Masahiko Tsuda, Junichi Watanabe and Susan Harris for their comments. REFERENCES [1] P. Srisuresh and M. Holdrege "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663, August 1999 Authors' Address Kuniaki Kondo IIJ, Inc. 3-13 Kanda, Nishiki-Cho, Chiyoda-ku, Tokyo, Japan Email: kuniaki@iij.ad.jp Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kuniaki NATS [Page 8]