Internet Draft Kuniaki Kondo Expiration Date: December 2003 IIJ June 2002 Capsulated Network Address Translation with Sub-Address(C-NATS) 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 Many home user networks or enterprise networks are using the address translation technology (NAT[1]) at the boundary of their end-networks for various reasons. One disadvantage of the use of the address translation technology is that it might disable two-way transparent communication. This document specifies the enhancement of the address translation technology, which it adds "sub-address" to current IP address space to enable NAT inside/outside hosts to setup transparent communication in both direction through enhanced NAT routers. This enhancement is called 'C-NATS' (Capsulated Network Address Translation with Sub-Address) and the word 'NATS' used in this document implies 'C-NATS'. Kuniaki C-NATS [Page 1] Internet-Draft February 2002 2. Overview The Sub-Address enhancement has the following advantages: a) There is no requirement for high hierarchy network routing architecture such as back-bone routers. b) The use of NATS is limited within end-networks, which are ideally using current NAT technology to connect Internet. c) NATS is easily to implement for a router and a host. Implementation of the NATS requires minor changes for application software and network equipments including dial-up routers connected to end-networks. However, this enhancement does not require any changes for backbone networks and its forwarding performance. This enhancement adds 32 bits of sub-address space for each IPv4 address. This document defines a new user transport protocol for that and so this protocol can be used in generic IPv4 network. When a host or a router, which does not support this protocol, receive NATS packets, these packets could be ignored. In this way, NATS framework maintains interoperability with the NATS non-supported equipments. 3. Sub-Address NATS Sub-Address space uses 32 bits space. Sub-Address expression uses dotted decimal which is used for IPv4 address expression in generic. It is defined in RFC1035[2]. The following address is reserved for the future use. 0.0.0.0 : Unknown Sub-Address (USA) 4. NATS Packet Encoding NATS uses 32 bit address space same as IPv4 address space. Therefore, When NATS uses for IPv4 network, IPv4 addresses which are assigned for local network equipments can use for Sub-Address. This advantage makes that NATS packets look like same as UDP tunnel when the packets through the Internet. Packet encoding is very simple. It looks like that "IP in IP Tunneling"[3] enhances using UDP. Kuniaki C-NATS [Page 2] Internet-Draft February 2002 +---------------------------+ | Outer IP Header | +---------------------------+ | UDP Header | +---------------------------+ +---------------------------+ | IP Header | | Inner IP Header | +---------------------------+ ====> +---------------------------+ | | | | | IP Payload | | IP Payload | | | | | +---------------------------+ +---------------------------+ UDP port number is NN. It is used for both of source/destination. In this documents, Source/Destination IP Address of inner IP header in above figure defines "Sub-Address". 5. NATS Management Protocol NATS defines the management protocol. It uses between a NATS router and a host which is connected to local network. NATS management protocol uses user data protocol(UDP), and UDP port number is MM. When the NATS router or the host receive the packet, these equipments SHOULD handle following functions. Following is the generic packet encoding for NATS management protocol. 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 | | ..... | Type number field describes a data type of NATS Data field. Type number is managed by following. 0 - 127 : IANA Reserved 128 - 255 : Vendor Specific This document assigns the following types. 0: Reserve 1: Get I/F Address Kuniaki C-NATS [Page 3] Internet-Draft February 2002 This message uses for getting an IP address which is assigned to an interface of a NATS router. The NATS router MUST NOT distinguish that a sender host supports NATS protocol when the NATS router receives this message. This message mostly uses for getting an IP address which is assigned to WAN interface of the NATS router. 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 | +-+-+-+-+-+-+-+-+ | I/F Num. | +-+-+-+-+-+-+-+-+ | Error Num. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Number of this message is 1. Both of request and reply message use same format. In request message, error number and IP address field SHOULD be set by '0'(zero). I/F number field contains arbitrary interface number. Generally, this interface number is same as SNMP interface number. Reply message MUST be contained all fields appropriately. Error number field contains error number in reply message. When the NATS router can not reply appropriate message, the NATS router contains following error numbers in this field. 0: No Error 1: I/F Not Available A interface which is specified by interface number field is not available. 2: I/F Not Enabled A interface which is specified by interface number field is not enabled because the interface is shutdowned. 3: I/F Not Active A interface which is specified by interface number field is not active because the interface does not connect by dial-up or does not assigned IP address. 4: System Error Other errors If error 1 to 4 causes, IP address field contains '0'(zero). Kuniaki C-NATS [Page 4] Internet-Draft February 2002 2: NATS Support Confirmation This message uses for confirming that a host which is connected local network supports NATS protocol or not before the NATS router forwards NATS data packets to the host. Following is packet encoding of this message. 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 | Confirm. Code |Confirmation ID| Return Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type number of this message is 2. Confirmation Code: 0: Confirmation Request 1: Confirmation Answer Return Code: 0: NATS Not Supported 1: NATS Supported Both of request and reply message use same format. Request message MUST send from a NATS router to a destination host. The NATS router assign a unique confirmation ID, and it contains the confirmation ID field in the request message. The confirmation ID has 8 bits space, and the NATS router can use any number in this space. The return code field of a request message uses for answering that a host which receives a request message supports NATS protocol or not. When the NATS router send the request message, the return code field MUST be set by '0'(zero). The NATS router MAY keep a status that is known by reply of this message from viewpoint of performance. Expiration time of this status MAY set 30 minutes. The NATS router might not receive a reply for a request message sometimes. Therefore, the NATS router MUST set expiration time for waiting the reply message. Expiration time MAY set 15 seconds. If the NATS router receives the reply message after the time is expired, then the reply message MUST be ignored. Kuniaki C-NATS [Page 5] Internet-Draft February 2002 6. Address Expression - Direct Sub-Address expression !example.com MUST be expressed according to be defined in Section 3. 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 resolves 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. This format allows to describe FQDN in field. When FQDN is described in the field, NATS equipments SHOULD resolve FQDN again. 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. 7. Mechanisms of DNS query hooking by NATS routers A NATS router SHOULD be implemented the mechanism what the router hooks DNS queries 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. Kuniaki C-NATS [Page 6] Internet-Draft February 2002 This mechanism is described in below. 1. A NATS supported router MUST 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 from local network, its query MUST be hooked and send a query to actual DNS instead of the host. At this time, the NATS router requests to search both of A RR and HINFO RR. If the NATS router receives a DNS query that it requests to search using direct sub-address expression as "!", then the NATS router does not search HINFO RR. However, the NATS router search only A RR, and the NATS router identifies that a destination host supports NATS protocol, and this process skips to 4 in below. 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 the 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 the virtual IP address. 5. A NATS non-supported host will try to connect using the 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 the virtual IP address into global IP address and sub-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. Kuniaki C-NATS [Page 7] Internet-Draft February 2002 Following pictures describe flows which was explained in this section. - Case 1: Normal Case - NATS non-support host address : 192.168.0.1 - NATS Router WAN I/F Address : 10.10.10.1 - Spool Address for NATS : 172.0.0.0/16 - Destination IPv4 Address : 10.0.0.1 - Destination Sub-Address : 192.168.0.100 NATS non-support host NATS Router DNS Host A (Local Network) | | | | |DNS Query:Host A |DNS Query: | | |---------------------->| 'A'/'HINFO' RR | | | |---------------------->| | | | | | | | DNS Answer | | | | HINFO = | | | | '/SUBA:192.168.0.100!10.0.0.1/' | |<----------------------| | | DNS Answer(Assigned) | | | | A = 172.0.0.1 | | | | HINFO = | | | | '/SUBA:192.168.0.100!10.0.0.1/' | | |<----------------------| | | | | | |Dest = 172.0.0.1 | | |Src = 192.168.0.1 | | |---------------------->|Dest = 192.168.0.100!10.0.0.1| | |Src = 192.168.0.1!10.10.10.1 | | |---------------------------->| | | | | |Dest = 192.168.0.1!10.10.10.1| | |Src = 192.168.0.100!10.0.0.1 | | |<----------------------------| |Dest = 192.168.0.1 | | |Src = 172.0.0.1 | | |<----------------------| | | | | Kuniaki C-NATS [Page 8] Internet-Draft February 2002 - Case 2: Pre-Specified Case - NATS non-support host address : 192.168.0.1 - NATS Router WAN I/F Address : 10.10.10.1 - Spool Address for NATS : 172.0.0.0/16 - Destination IPv4 Address : 10.0.0.1(example.com) - Destination Sub-Address : 192.168.0.100 NATS non-support host NATS Router DNS Host A (Local Network) | | | | |DNS Query:Host A | | | |(192.168.0.100!example.com) | | |---------------------->|DNS Query: 'A' RR | | | |---------------------->| | | | | | | | DNS Answer | | | | A = 10.0.0.1 | | | |<----------------------| | | DNS Answer(Assigned) | | | | A = 172.0.0.1 | | | |<----------------------| | | | | | | |Dest = 172.0.0.1 | | |Src = 192.168.0.1 | | |---------------------->|Dest = 192.168.0.100!10.0.0.1| | |Src = 192.168.0.1!10.10.10.1 | | |---------------------------->| | | | | |Dest = 192.168.0.1!10.10.10.1| | |Src = 192.168.0.100!10.0.0.1 | | |<----------------------------| |Dest = 192.168.0.1 | | |Src = 172.0.0.1 | | |<----------------------| | | | | Kuniaki C-NATS [Page 9] Internet-Draft February 2002 8. Address Translation A NATS router provides end-to-end communication doing apropriate address translation for packets which receive from WAN and LAN interface. This section describes methods of those address translation. 8.1 Access from NATS supported hosts 8.1.1 Criteria that a NATS router uses the NATS protocol When a host send first packet to make connection, a NATS router MUST use the NATS protocol according as following criteria. 1. When a host tries to resolve IP address and Sub-Address, a NATS router hooks DNS query using a method which is describes in section 7 and its sub-address is not USA. 2. Sub-Address is specifed directly. If a host receives NATS encoded packet to make connection, then the host SHOULD reply using NATS encoded packet. However, If the NATS support host is not assigned sub-address, then the host MUST NOT send NATS encoded packet. 8.1.2 Send a NATS packet from NATS support host When a NATS support host send a NATS encoding packets, the host MUST be done capsulating every packet same as a NATS router. However, values of inner header and outer header mostly use same value except protocol number and IP address. Following describes some points when a NATS router sends a NATS encoded packets. - Inner Header Source IP Address : I/F Address of local host Destination IP Address : Destination Sub-Address Other Header Value : Same as normal operation - Outer Header Source IP Address : I/F Address of local host Destination IP Address : Destination IP Address Protocol Number : UDP Other Header Value : Same as Inner Header value Kuniaki C-NATS [Page 10] Internet-Draft February 2002 - UDP Header According as definition in section 4. 8.2 Send a NATS non-support packet from local host When a NATS router receives a packet which is not encoded NATS, the NATS router MUST be done follwoing. - When the NATS rotuer receives a packet which is used spool address for destination address using method describes in section 7, the NATS router MUST encodes NATS packets and forwards them. Following describes value of header for NATS encoded packets. - Inner Header Destination IP Address : Destination IP address which is binded spool address by the NATS router Other Header Value : Same as original - Outer Header Source IP Address : IP address of WAN interface Destination IP Address : Destination IP address which is binded spool address by the NATS router Protocol Number : UDP TTL : Decremented value of TTL in original packet. Other Header Value : Same as inner header - UDP Header According as definition in section 4. - Other cases in above, packets SHOULD be fowarded using generic NAPT. 8.3 Send a NATS encoded packet from local network When a NATS router receives NATS encoded packets from local network, the NATS router MUST be done generic NAT translation for outer header. At this time, UDP port number both of source and destination MUST NOT be translated. Kuniaki C-NATS [Page 11] Internet-Draft February 2002 8.4 Receive a NATS encoded packte from WAN A NATS router receives NATS encoded packets from WAN interface, the NATS router SHOULD change translation behavior according as the destination host support NATS or not. The NATS router can distinguish the host supports NATS or not to check destination IP address in inner header(Sub-Address) and using a method of NATS support confirmation in section 5. Following describes the method of translation. - Case of destination host does not support NATS. If the destination host does not support NATS, then the NATS router MUST decode received packets to normal IP packets, and forwards them. Following descrives values of decoded IP packets header. Source IP Address : Source IP address in outer header Destination IP Address : Destination IP address in inner header TTL : Decremented value of TTL in outer header Other Header Value : Same as inner header - Case of destination host supports NATS. If the destination host supports NATS, then the NATS router fowards the received packets without decoding. However, following fields of header MUST be changed. - Outer Header Destination IP Address : Destination IP address in inner header (Sub-Address) Other Header Value : No change - Inner Header No change. 9. Recommendations of implementation This protocol requires to implement to a gateway router which is placed at border 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. First, Following equipments MUST implement NATS. Kuniaki C-NATS [Page 12] Internet-Draft February 2002 1. Gateway routers that are placed at border between local network as assigned private addresses every hosts and global network as assigned global addresses. 2. Hosts that are placed on global network as assigned global addresses. That is, implementing NATS protocol for a host which is connected local network is optional. Futhermore, 'Get I/F address' and 'NATS support confirmation' protocol can instead that the NATS router keep sub-address table. Then, implementing those protocols are optional. 10. UDP Port Number Considerations This document requires to assign following two UDP port numbers. 1. NATS require a UDP port for communicating NATS encoded data packets. This UDP port is called NATS Data Port, and it describes 'NN' in this document. 2. NATS requrire a UDP port for managing a NATS router and a host. This UDP port is called NATS control port, and it describes 'MM' in this document. Currently, those port numbers were not assigned by IANA. 11. 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. 12. Acknowledgements Thanks to Toshiya Asaba, Ikuo Nakagawa, Ryo Shimizu, Kiyoshi Ishida, Tomokazu Takizawa, Masahiko Tsuda, Junichi Watanabe and Susan Harris for their comments. Kuniaki C-NATS [Page 13] Internet-Draft February 2002 Appendix 1: Implementations Current NATS implementations are below. - Linux NATS for RedHad Linux will be released for trial. - Products - IIJ/SEIL - Edge SOHO Router (SCHEDULED) Appendix 2: Mainling Linst - Mailing list nats@nats-project.org - Web Page http://www.nats-project.org/ REFERENCES [1] P. Srisuresh and M. Holdrege "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663, August 1999 [2] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" RFC1035, November 1987 [2] W. Simpson, "IP in IP Tunneling", RFC1853, October 1995 Authors' Address Kuniaki Kondo IIJ, Inc. 3-13 Kanda, Nishiki-Cho, Chiyoda-ku, Tokyo, Japan Email: kuniaki@nats-project.org Kuniaki C-NATS [Page 14] Internet-Draft February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 15] -- Kuniaki Kondo kuniaki@iij.ad.jp NATS Page: http://www.nats-project.org/