draft-kuniaki-nats-00.txt Kuniaki Kondo IIJ June 2000 Network Address Translation with Sub-Address(NATS) -- Phase 2 -- 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 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. At the NATS Phase 1, it is impossible to make a reverse connection between two hosts which is placed at difference network, because the source sub-address field of NATS phase 1 packets always fill out the Unknown. The NATS Phase 2 which will be defined in this documents will specifies the contents of source sub-address field when the NATS supported host send packets. And, this document will specify some enhancements for identifying local sub-address. 2. Overview of the NATS This enhancement has the following three advantages: a) There is NO-IMPACT for high hierarchy network routing (such as backbones). b) The use of NATS is limited to use for end-networks which are usually connected by NAT router. c) 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 devices including dial-up routers which are connected to end-networks. Therefore, this enhancement does not adversely affect backbone networks such as a high-bandwidth network. 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. 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 +--------+--------+--------+--------+ |100nnnnn|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: +--------+--------+--------+--------+ | SSA | DSA | +--------+--------+--------+--------+ 　　1: Sub-Address Discovery This type is used at searching a sub-address which described in the SA field to a connected network. When some hosts want to know the sub-address which is connected the local network, the hosts should send the this type packet to the connected network. +--------+--------+--------+--------+ | 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. +--------+--------+--------+--------+ | 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) 6. Equipment behavior 6.1 Hosts The host which support the NATS have to send NATS supported packets. In this case, the host fills out the local sub-address in SSA field. When the NATS non-supported host receives the NATS supported packets, the host ignores the NATS option header as an unknown IP option. 6.2 Routers - 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. 　- 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. - 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 !hogehoge.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 "!hogehoge.com". In this case, "!hogehoge.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. 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. The host can resolve the sub-address to refer HINFO resource record of DNS by hostname. 8. Acknowledgements TBD. 9. References RFC791: Internet Protocol DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION RFC3022: Traditional IP Network Address Translator (Traditional NAT) 10. Author Information Kuniaki Kondo IIJ, Inc. 3-13 Kanda, Nishiki-Cho, Chiyoda-ku, Tokyo, Japan Email: kuniaki@iij.ad.jp 11. Full Copyright Statement -- Kuniaki Kondo kuniaki@iij.ad.jp