Internet Draft Kuniaki Kondo Expiration Date: March 2002 IIJ November 2001 Capsulated Network Address Translation with Sub-Address(C-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 'C-NATS'(Capsulated Network Address Translation with Sub-Address). However, 'C-NATS' will be call 'NATS' in this document. Kuniaki C-NATS [Page 1] Internet-Draft November 2001 2. Overview 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 software and network equipments 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 document defines a new transport protocol for that this protocol will be used in generic IPv4 network. This transport protocol consists of 8 octets NATS control fields and transport data fields which is used usual IPv4 packets. 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. Kuniaki C-NATS [Page 2] Internet-Draft November 2001 3. NATS encoding Following is the NATS header format. NATS Header Format Protocol Number : N/A 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | NATS Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NATS Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Data | | ..... | Protocol Number for the NATS is not assigned by IANA yet. Type Field: Type Field specifies a kind of data in the NATS Data field in this header. The detail will describe. 4. Sub-Address Space NATS Sub-Address Space uses 16 bits space. However, following addresse is reserved. 0x0000 : Unknown Sub-Address (USA) Kuniaki C-NATS [Page 3] Internet-Draft November 2001 5. Detail format for the NATS every types Type number should be managed in following. 0 - 127 : IANA Reserved 128 - 255 : Vendor Specific This document assigns following types. 0: Sub-Address This type is used for normal data communications. NATS Header consists of Type Number, Transport Number, Source Sub-Address, Destination Sub-Address and Transport Data. NATS header encoding is following. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Transport Num| N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Sub-Address (SSA) | Destination Sub-Address(DSA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Data | | ..... | Transport Num.: Transport Number is a protocol number of transport data field which is encoded by NATS. Protocol Numbers are managed by IANA. Detail is at http://www.iana.org/assignments/protocol-numbers . 1: Sub-Address Discovery This type is used for resolving sub-address from a network. - In case of resolving for IP Address from sub-address. 1. Sub-Address is in SA field. IP Address field is 0.0.0.0. And, this packet send to network by broadcast. 2. When the host receive a packet which is specified its sub-address, the host send a packet to source host. The IP Address field of the packet is local IP address. Kuniaki C-NATS [Page 4] Internet-Draft November 2001 - In case of resolving for Sub-Address from IP address. 1. USA is in the SA field. IP address field is IP address of the destination host. And, this packet send to destination host by unicast. 2. When the host receive a packet, the host return a packet to source host. The SA field of the packet is local Sub-Address. Expire time for this request is optional. However, this time may set 30seconds for default. Following is encoding of this request: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0x00 | SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. Sub-Address Registration This message is used for that a NATS supported host notifies local sub-address to a NATS router, or a NATS router assigns a sub-address for a NATS supported host. The NATS router can know that the host supports NATS protocol using this message. Reg. type 0 is registration, 1 is deletion. When the host notifies that the host supports NATS, the host send Reg. Type 0(Add) using this message. If the host doesn't know the local sub-address, then the host specifies USA in the SA field. At this time, the NATS router assigns a sub-address to the host, and the host returns Reg.type 3(Assignment). The SA field of this message is a assigned sub-address. When the host is done shutdown or it is in similar situation, the host should send a message of Reg.type 1(Delete), and the host should release sub-address. Expire time of this message is 0(Zero). When the SA filed is not USA, expire time have must be set. When the expire time is 0(Zero), it means that expire time is 1800 for default. Expire time field describes 'seconds'. Kuniaki C-NATS [Page 5] Internet-Draft November 2001 Following is encoding of this request: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reg.Type | SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expire Time | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reg.Type : Registration Type 0: Add 1: Delete 2: Assignment 3: Expired A host or a router must manage valid time for sub-address using expire time. When expire time arrived, the host should notify that current sub-address is expired using Reg.Type 3(Expired). The equipments which are received this message can request to continue for using current sub-address using Reg. Type2 (Assignment). If the current sub-address cannot continue for using, then the equipment return Reg.Type 2(Assignment). The SA field of this message is USA. When the equipments reject continuing to use a sub-address, the equipment need to request getting a new sub-address using same way of first set of assignment of a sub-address. 6. 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. Kuniaki C-NATS [Page 6] Internet-Draft November 2001 - 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. The host can resolve the sub-address to refer HINFO resource record of DNS by hostname. 7. Equipment behavior 7.1 Hosts When a host sends a request packet to make connection, if the following criterias are matched, then the host has to send a packet which is encoded for the NATS. 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 encoded packet when the host receives a NATS encoded packet to make connection. However, if a NATS supported host is not assigned sub-address, then the host never send NATS encoded packets. Kuniaki C-NATS [Page 7] Internet-Draft November 2001 7.2 Routers 7.2.1 Function of NATS routes The NATS router have to keep a sub-address table. It records a pair of local IP address and its sub-address. When SSA value of a received NATS encoded packet from connected network does not match with the sub-address table in the router, the router processes the packets as the received packet is correct. 7.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. 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. Kuniaki C-NATS [Page 8] Internet-Draft November 2001 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. 7.2.3 Behavior of the NATS router - When the NATS router receives the NATS encoded 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. At this time, if the destination host does not support the NATS, then the NATS router has to decode to normal IPv4 packet as to delete the NATS header from the received packet. The way of judgement whether the destination host supports the NATS or not, is done using Sub-Address registration mechanism which is described in section 5. If the destination host which is defined in the DSA field can not found, then the router try to resolve using sub-address discovery which is described in section 5. After the router sent the "Sub-Address Discovery" packet, it should wait a response packet during 15 seconds in default. 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 normal IPv4 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 encoded 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. Kuniaki C-NATS [Page 9] Internet-Draft November 2001 - When the NATS router receives the normal IPv4 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. However, If the NATS router is implemented DNS hook mechanism and destination IPv4 address is same as virtual IP address which is assigned by the NATS router, the NATS router has to translate virtual IP address into global IP address related virtual IP address. Furthermore, the NATS router has to translate source IP address in a return packet from a destination host into the virtual IP address. 8. Recommendations of implementation This protocol requires to implement to a gateway router between local network and global network and a host. However, to implement this protocol to those devices are difficult. Therefore, this section explains a way of light implementation. Firstly, Following devices have to implement NATS. 1. Gateway routers that are placed between local network as assigned private addresses every host and global network as assigned global addresses. 2. Hosts that are placed on global network as assigned global addresses. Secondly, following functions which is described in this document don't have to implement. Those functions is recommended to implement. 1. Sub-Address Discovery 2. Sub-Address Registration 9. IANA Considerations The Type Field value 0 - 2 are assigned in this document. Type Field value 3 - 127 for extended-type are to be assigned by IANA, using the "First Come First Served" policy defined in RFC2434. Type values 128 - 255 for extended types are for vendor-specific types, and values in this range are not to be assigned by IANA. Kuniaki C-NATS [Page 10] Internet-Draft November 2001 10. 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 C-NATS [Page 11]