From sacadmin Tue Apr 8 22:14:27 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m395ERHE025948; Tue, 8 Apr 2008 22:14:27 -0700 (PDT) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m395ERdn025944; Tue, 8 Apr 2008 22:14:27 -0700 (PDT) Date: Tue, 8 Apr 2008 22:14:27 -0700 (PDT) From: Darren Reed Message-Id: <200804090514.m395ERdn025944@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: IPv6 NAT for IPFilter [PSARC/2008/250 FastTrack timeout 04/15/2008] Status: RO Content-Length: 551 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: IPv6 NAT for IPFilter 1.2. Name of Document Author/Supplier: Author: Yifan Xu 1.3 Date of This Document: 08 April, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Reed@sun.com Tue Apr 8 22:18:29 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m395ISmS025963 for ; Tue, 8 Apr 2008 22:18:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m395IMRL024138 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Apr 2008 06:18:27 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ100117LEOR000@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 Apr 2008 22:18:24 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ1001AGLELP200@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 Apr 2008 22:18:22 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m395IpgU024679 for ; Wed, 09 Apr 2008 05:18:51 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZ100001L9K9H00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 13:18:14 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ10042OLECPG2C@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 13:18:13 +0800 (SGT) Date: Tue, 08 Apr 2008 22:18:18 -0700 From: Darren Reed Subject: PSARC/2008/250 IPv6 NAT for IPFilter Sender: Darren.Reed@sun.com To: PSARC-EXT Cc: Yifan Xu Message-id: <47FC519A.6030402@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1JPpbQvR0iqmIrA3HtrS5g)" X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 4273 This is a multi-part message in MIME format. --Boundary_(ID_1JPpbQvR0iqmIrA3HtrS5g) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT I'm submitting the attached spec as the proposal for the IPv6 NAT project on behalf of Yifan Xu. Darren --Boundary_(ID_1JPpbQvR0iqmIrA3HtrS5g) Content-type: text/plain; name=ipv6nat.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=ipv6nat.txt IPv6 NAT for IP Filter Overview ======== This change request aims to provide IPv6 NAT capabilities for IP Filter. The requested release binding is micro/patch. Customer impact =============== A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT sessions in kernel needs to rebuild their program due to the changes of structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. A customer which uses other IP Filter IPv4 NAT features does not need to change anything. Out of scope ============ Several kernel proxies are built in the IP Filter IPv4 NAT code, such as ftp, h.323, ipsec, irc, pptp, raudio, rcmd, and rpcb. There will be no provision for IPv6 kernel proxy support in this project. Interface changes ================= There are three interface changes made by this project. They are ipnat command usage, ipmon output, and SIOCGNATL/SIOCSTPUT ioctl input. ipnat ----- The only change to user orientated interfaces is to extend the ipnat command. Users will be able to specify IPv6 addresses and netmasks in NAT rules. A simple IPv6 NAT rule could be written as: map ce0 fec0:1::/64 -> fec0:2::2 Any usage format following the grammar in ipnat.conf(4) are accepted. Below are some examples for portmap, map-block and rdr rules: map ppp0 fec0:1::/64 -> 2000:1:2::/72 portmap tcp/udp 1025:65000 map-block ppp0 fe80:0:0:209::/64 -> 209:1:2::/72 ports auto rdr ce0 209::ffff:fe13:e43e port 80 -> fec0:1::e,fec0:1::f port 80 tcp round-robin One cannot specify both IPv4 and IPv6 addresses in the same rule. If any IPv6 address is specified, the "mapproxy" and "rdrproxy" options will not be allowed to use in the same rule. See ipnat.conf(4). ipmon ----- To log IPv6 NAT packets, ipmon will be updated to include IPv6 addresses as part of its output, which is a volatile interface. ioctls ------ For ioctl SIOCGNATL, the structure "natlookup_t" has been changed to be able to contain IPv6 addresses. A new member "nl_v" is added to specify whether it is looking for an IPv4 or an IPv6 NAT session. For compatibilities, IPv4 NAT session lookup doesn't need to assign "nl_v". See ipnat(7i). For ioctl SIOCSTPUT, A new member "nat_v" is added to the structure "nat_t" to specify whether it is inserting an IPv4 or an IPv6 NAT session. For compatibilities, inserting an IPv4 NAT session doesn't need to assign "nat_v". See ipnat(7i). Package Impact ============== SUNWipfr SUNWipfu SUNWipfh Reference ========= [1] PSARC 2003/046 Solaris IP Filter [2] PSARC 2005/201 IPv6 for IP Filter [3] PSARC 2005/233 IPFilter API for NAT entry duplicate detection [4] RFE: 6600474 Need ipv6 support on NAT Appendix A - structure changes ============================== Below are the changes to ipnat(7i) @@ -67,9 * Structure used with SIOCGNATL. */ typedef struct natlookup { - struct in-addr nl_inip; - struct in_addr nl_outip; - struct in_addr nl_realip; + i6addr_t nl_inipaddr; + i6addr_t nl_outipaddr; + i6addr_t nl_realipaddr; + int nl_v; int nl_flags; u_short nl_inport; u_short nl_outport; @@ -76,6 +77,13 @@ u_short nl_realport; } natlookup_t +#define nl_inip nl_inipaddr.in4 +#define nl_outip nl_outipaddr.in4 +#define nl_realip nl_realipaddr.in4 +#define nl_inip6 nl_inipaddr.in6 +#define nl_outip6 nl_outipaddr.in6 +#define nl_realip6 nl_realipaddr.in6 + /* * Accepted values for nl_flags */ @@ -169,6 +177,7 @@ int nat_hv[2]; char nat_ifnames[2][LIFNAMSIZ]; int nat_rev; + int nat_v; } nat_t; #define nat_inip nat_inip6.in4 --Boundary_(ID_1JPpbQvR0iqmIrA3HtrS5g)-- From Darren.Moffat@Sun.COM Wed Apr 9 02:39:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m399dJw2004372 for ; Wed, 9 Apr 2008 02:39:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m399dDM4001523 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Apr 2008 10:39:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ100501XHHNR00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 02:39:17 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ1005E2XHGRRA0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 02:39:17 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m399dGgA007023 for ; Wed, 09 Apr 2008 09:39:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZ100I01UM1NB00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 10:39:16 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZ100A5LXHDS530@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 10:39:13 +0100 (BST) Date: Wed, 09 Apr 2008 10:39:13 +0100 From: Darren J Moffat Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <47FC519A.6030402@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Darren Reed Cc: PSARC-EXT , Yifan Xu Message-id: <47FC8EC1.6040803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FC519A.6030402@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 390 Darren Reed wrote: > I'm submitting the attached spec as the proposal for the IPv6 NAT project > on behalf of Yifan Xu. I thought the whole point of IPv6 was to avoid the need for NAT, sigh. On this case specifically, why is it acceptable to provide IPv6 NAT support without the proxies ? Are they not useful or is it just a project scoping issue for resourcing ? -- Darren J Moffat From Evan.Xu@Sun.COM Wed Apr 9 03:26:20 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m39AQKCL006541 for ; Wed, 9 Apr 2008 03:26:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m39AQAM4004341 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 03:26:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ10032ZZNV5U00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 03:26:19 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ1001YNZNSIE10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 03:26:17 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39AQTH8023695 for ; Wed, 09 Apr 2008 10:26:29 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZ100C01ZK21B00@mail-apac.sun.com> (original mail from Evan.Xu@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 18:25:43 +0800 (SGT) Received: from [129.158.219.242] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ100B1CZMPRGV6@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 18:25:39 +0800 (SGT) Date: Wed, 09 Apr 2008 18:25:38 +0800 From: yifan evan xu - Sun Microsystems - Beijing China Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <47FC8EC1.6040803@Sun.COM> Sender: Evan.Xu@Sun.COM To: Darren J Moffat Cc: Darren Reed , PSARC-EXT Message-id: <47FC99A2.5060802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FC519A.6030402@Sun.COM> <47FC8EC1.6040803@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 1076 Darren J Moffat wrote: > Darren Reed wrote: >> I'm submitting the attached spec as the proposal for the IPv6 NAT >> project >> on behalf of Yifan Xu. > > I thought the whole point of IPv6 was to avoid the need for NAT, sigh. > > On this case specifically, why is it acceptable to provide IPv6 NAT > support without the proxies ? Are they not useful or is it just a > project scoping issue for resourcing ? > The requirement comes from the exploitation of implementing transparent proxying in IPv6 network, which has been exploited in IPv4 environment. Transparent proxying is achieved through two NATing steps: 1) Redirect client connections to local host, by applying ipfilter RDR rules. 2) Forward the client request to the server using client's IP as the source address, by inserting ipfilter MAP sessions through SIOCSTPUT ioctl. This project aims to provide the capabilities to support this kind of use case for IPv6 network. Simply NATing IPv6 addresses for intranet host does seem useless. That's why kernel proxies are not involved in the scope. Yifan From gww@eng.sun.com Tue Apr 15 14:03:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3FL3njY010244 for ; Tue, 15 Apr 2008 14:03:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3FL3ilP005215 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 16 Apr 2008 05:03:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZD00805X6AR100@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 15 Apr 2008 14:03:46 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZD006Q1X6AEH40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 15 Apr 2008 14:03:46 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3FL3i6R050431; Tue, 15 Apr 2008 14:03:44 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m3FL3JVN011493; Tue, 15 Apr 2008 14:03:19 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3FL3Je4011492; Tue, 15 Apr 2008 14:03:19 -0700 (PDT) Date: Tue, 15 Apr 2008 14:03:19 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter To: Darren.Reed@sun.com, psarc-ext@sun.com Cc: Evan.Xu@sun.com Message-id: <200804152103.m3FL3Je4011492@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 582 > IPv6 NAT for IP Filter > > Overview > ======== > This change request aims to provide IPv6 NAT capabilities for IP Filter. > The requested release binding is micro/patch. > Customer impact > =============== > A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT > sessions in kernel needs to rebuild their program due to the changes of > structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. What is the taxonomy of these ioctls. If it is above Volatile, how is the incompatible change mitagated for the requested release binding? Gary.. From Evan.Xu@Sun.com Tue Apr 15 20:46:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3G3kGmt022548 for ; Tue, 15 Apr 2008 20:46:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3G3k9dB027504 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 16 Apr 2008 11:46:15 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZE00309FT3UK00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 15 Apr 2008 20:46:15 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZE00NZGFT02V40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 15 Apr 2008 20:46:13 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3G3kiuU008040 for ; Wed, 16 Apr 2008 03:46:44 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZE00101FS1ZH00@mail-apac.sun.com> (original mail from Evan.Xu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 11:46:05 +0800 (SGT) Received: from [129.158.219.242] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZE004URFSSPGV0@mail-apac.sun.com>; Wed, 16 Apr 2008 11:46:05 +0800 (SGT) Date: Wed, 16 Apr 2008 11:45:30 +0800 From: yifan evan xu - Sun Microsystems - Beijing China Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <200804152103.m3FL3Je4011492@marduk.eng.sun.com> Sender: Evan.Xu@Sun.com To: Gary Winiger Cc: Darren.Reed@Sun.com, psarc-ext@Sun.com Message-id: <4805765A.8040701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804152103.m3FL3Je4011492@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 955 Gary Winiger wrote: >> IPv6 NAT for IP Filter >> >> Overview >> ======== >> This change request aims to provide IPv6 NAT capabilities for IP Filter. >> The requested release binding is micro/patch. >> > > >> Customer impact >> =============== >> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT >> sessions in kernel needs to rebuild their program due to the changes of >> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. >> > > What is the taxonomy of these ioctls. If it is above Volatile, > how is the incompatible change mitagated for the requested > release binding? > > It's "External Stable". Does it mean for functionality extension we need to provide new ioctl? Are the header files changable? Or we need to provide new header files? Can we add new structures into the old header files as long as we guarantee that no recompiling action is required for original customers? Yifan From Darren.Reed@sun.com Wed Apr 16 00:45:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3G7j4IR028171 for ; Wed, 16 Apr 2008 00:45:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3G7j3DH017222 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 16 Apr 2008 15:45:03 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZE0020DQV2ZJ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 00:45:02 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZE00LCIQV154B0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 00:45:02 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3G7jDkR014788 for ; Wed, 16 Apr 2008 07:45:13 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZE00H01QOVOH00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 15:44:54 +0800 (SGT) Received: from [129.158.219.238] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZE007MCQUSUHFG@mail-apac.sun.com>; Wed, 16 Apr 2008 15:44:53 +0800 (SGT) Date: Wed, 16 Apr 2008 00:44:53 -0700 From: Darren Reed Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <200804152103.m3FL3Je4011492@marduk.eng.sun.com> Sender: Darren.Reed@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, Evan.Xu@sun.com Message-id: <4805AE75.6090301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804152103.m3FL3Je4011492@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) Status: RO Content-Length: 1259 Gary Winiger wrote: >> IPv6 NAT for IP Filter >> >> Overview >> ======== >> This change request aims to provide IPv6 NAT capabilities for IP Filter. >> The requested release binding is micro/patch. > >> Customer impact >> =============== >> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT >> sessions in kernel needs to rebuild their program due to the changes of >> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. > > What is the taxonomy of these ioctls. If it is above Volatile, > how is the incompatible change mitagated for the requested > release binding? I was wondering if someone would notice this... There are a few things going on here... 1) management isn't interested in investing in a non-ioctl API unless there is significant interest outside of engineering (there is some interest), meaning that internal changes that get reflected in changes to the ioctls either cost engineers a whole bunch of extra work or cause customers a bunch of pain/work; 2) the changes to support ipv6 NAT, in the external code base are being made as part of the next major release (4.x -> 5.x) but we're not doing that here... Feel free to accost said mangler when he returns O:-) Darren From gww@eng.sun.com Wed Apr 16 10:42:07 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3GHg6QC017646 for ; Wed, 16 Apr 2008 10:42:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3GHfpQp017547 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 16 Apr 2008 18:42:05 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZF00J07II2TK00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 10:42:02 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZF004UIII27RC0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 10:42:02 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3GHg0OO065171; Wed, 16 Apr 2008 10:42:00 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m3GHfaex013449; Wed, 16 Apr 2008 10:41:36 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3GHfax8013448; Wed, 16 Apr 2008 10:41:36 -0700 (PDT) Date: Wed, 16 Apr 2008 10:41:36 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter To: gww@eng.sun.com, Evan.Xu@sun.com Cc: Darren.Reed@sun.com, psarc-ext@sun.com Message-id: <200804161741.m3GHfax8013448@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2312 Evan writes: > Gary Winiger wrote: > >> IPv6 NAT for IP Filter > >> > >> Overview > >> ======== > >> This change request aims to provide IPv6 NAT capabilities for IP Filter. > >> The requested release binding is micro/patch. > >> > > > > > >> Customer impact > >> =============== > >> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT > >> sessions in kernel needs to rebuild their program due to the changes of > >> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. > >> > > > > What is the taxonomy of these ioctls. If it is above Volatile, > > how is the incompatible change mitagated for the requested > > release binding? > > > > > > It's "External Stable". Does it mean for functionality extension we need to > provide new ioctl? Are the header files changable? Or we need to provide new > header files? Can we add new structures into the old header files as long as > we guarantee that no recompiling action is required for original customers? I'm not sure what "External Stable" is, so I'll take it as the former Stable which is the current Committed. And I'll ask again: "How is the incompatible change mitagated for the requested Patch release binding?" Darren write: > There are a few things going on here... > 1) management isn't interested in investing in a non-ioctl API > unless there is significant interest outside of engineering > (there is some interest), meaning that internal changes that > get reflected in changes to the ioctls either cost engineers > a whole bunch of extra work or cause customers a bunch of > pain/work; > > 2) the changes to support ipv6 NAT, in the external code base > are being made as part of the next major release (4.x -> 5.x) > but we're not doing that here... > > Feel free to accost said mangler when he returns O:-) I'm not sure what the reasons are, or if they really matter unless the architecture is wrong and then I'd leave that up to the Case Owner and the Case Submitter to work out before submitting the Fast Track. I'm asking the naive question presuming the Case Owner has approved of the general architecture and that's less up for discussion. If ioctls are the wrong architecture, the Case Owner should just derail or withdraw the case. Gary.. From Darren.Reed@sun.com Thu Apr 17 00:30:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3H7U47s015413 for ; Thu, 17 Apr 2008 00:30:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3H7TrbW028904 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 17 Apr 2008 15:30:03 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZG00709KU2U100@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 17 Apr 2008 00:30:02 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZG00D87KU0JBF0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 17 Apr 2008 00:30:01 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3H7UWDd029656 for ; Thu, 17 Apr 2008 07:30:32 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZG00301KRIZ700@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 17 Apr 2008 15:29:51 +0800 (SGT) Received: from [129.158.219.238] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZG004SZKTQPGE3@mail-apac.sun.com>; Thu, 17 Apr 2008 15:29:51 +0800 (SGT) Date: Thu, 17 Apr 2008 00:29:51 -0700 From: Darren Reed Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <200804161741.m3GHfax8013448@marduk.eng.sun.com> Sender: Darren.Reed@sun.com To: Gary Winiger Cc: Evan.Xu@sun.com, psarc-ext@sun.com Message-id: <4806FC6F.1060008@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804161741.m3GHfax8013448@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) Status: RO Content-Length: 2568 Gary Winiger wrote: > Evan writes: > >> Gary Winiger wrote: >> >>>> IPv6 NAT for IP Filter >>>> >>>> Overview >>>> ======== >>>> This change request aims to provide IPv6 NAT capabilities for IP Filter. >>>> The requested release binding is micro/patch. >>>> >>>> >>> >>> >>>> Customer impact >>>> =============== >>>> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT >>>> sessions in kernel needs to rebuild their program due to the changes of >>>> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. >>>> >>>> >>> What is the taxonomy of these ioctls. If it is above Volatile, >>> how is the incompatible change mitagated for the requested >>> release binding? >>> >>> >>> >> It's "External Stable". Does it mean for functionality extension we need to >> provide new ioctl? Are the header files changable? Or we need to provide new >> header files? Can we add new structures into the old header files as long as >> we guarantee that no recompiling action is required for original customers? >> > > I'm not sure what "External Stable" is, so I'll take it as the > former Stable which is the current Committed. And I'll ask again: > "How is the incompatible change mitagated for the requested Patch > release binding?" > > Darren write: > >> There are a few things going on here... >> 1) management isn't interested in investing in a non-ioctl API >> unless there is significant interest outside of engineering >> (there is some interest), meaning that internal changes that >> get reflected in changes to the ioctls either cost engineers >> a whole bunch of extra work or cause customers a bunch of >> pain/work; >> >> 2) the changes to support ipv6 NAT, in the external code base >> are being made as part of the next major release (4.x -> 5.x) >> but we're not doing that here... >> >> Feel free to accost said mangler when he returns O:-) >> > > I'm not sure what the reasons are, or if they really matter > unless the architecture is wrong and then I'd leave that up > to the Case Owner and the Case Submitter to work out before > submitting the Fast Track. > > I'm asking the naive question presuming the Case Owner has approved > of the general architecture and that's less up for discussion. > If ioctls are the wrong architecture, the Case Owner should just > derail or withdraw the case. As an intern, am I able to derail it? As far as I'm aware I'm not able to but I would support a member doing so. Darren From Evan.Xu@sun.com Fri Apr 18 02:10:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3I9AK3S026336 for ; Fri, 18 Apr 2008 02:10:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3I9ADls026144 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 18 Apr 2008 10:10:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZI0070TK579J00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 18 Apr 2008 02:10:19 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZI00LLGK557K80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 18 Apr 2008 02:10:18 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3I9AWiK028683 for ; Fri, 18 Apr 2008 09:10:32 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZI00001JXKVM00@mail-apac.sun.com> (original mail from Evan.Xu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 18 Apr 2008 17:10:08 +0800 (SGT) Received: from [129.158.219.242] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZI00MAFK4V9MS1@mail-apac.sun.com>; Fri, 18 Apr 2008 17:10:08 +0800 (SGT) Date: Fri, 18 Apr 2008 17:09:32 +0800 From: yifan evan xu - Sun Microsystems - Beijing China Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <200804161741.m3GHfax8013448@marduk.eng.sun.com> Sender: Evan.Xu@sun.com To: Gary Winiger Cc: Darren.Reed@sun.com, psarc-ext@sun.com Message-id: <4808654C.3030608@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_kprjKwrTuvMs3C+Qn/I8dw)" X-PMX-Version: 5.4.1.325704 References: <200804161741.m3GHfax8013448@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 6779 This is a multi-part message in MIME format. --Boundary_(ID_kprjKwrTuvMs3C+Qn/I8dw) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT I am sending the updated spec with respect to Gary's issue. Yifan Gary Winiger wrote: > Evan writes: > >> Gary Winiger wrote: >> >>>> IPv6 NAT for IP Filter >>>> >>>> Overview >>>> ======== >>>> This change request aims to provide IPv6 NAT capabilities for IP Filter. >>>> The requested release binding is micro/patch. >>>> >>>> >>> >>> >>>> Customer impact >>>> =============== >>>> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT >>>> sessions in kernel needs to rebuild their program due to the changes of >>>> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. >>>> >>>> >>> What is the taxonomy of these ioctls. If it is above Volatile, >>> how is the incompatible change mitagated for the requested >>> release binding? >>> >>> >>> >> It's "External Stable". Does it mean for functionality extension we need to >> provide new ioctl? Are the header files changable? Or we need to provide new >> header files? Can we add new structures into the old header files as long as >> we guarantee that no recompiling action is required for original customers? >> > > I'm not sure what "External Stable" is, so I'll take it as the > former Stable which is the current Committed. And I'll ask again: > "How is the incompatible change mitagated for the requested Patch > release binding?" > > Darren write: > >> There are a few things going on here... >> 1) management isn't interested in investing in a non-ioctl API >> unless there is significant interest outside of engineering >> (there is some interest), meaning that internal changes that >> get reflected in changes to the ioctls either cost engineers >> a whole bunch of extra work or cause customers a bunch of >> pain/work; >> >> 2) the changes to support ipv6 NAT, in the external code base >> are being made as part of the next major release (4.x -> 5.x) >> but we're not doing that here... >> >> Feel free to accost said mangler when he returns O:-) >> > > I'm not sure what the reasons are, or if they really matter > unless the architecture is wrong and then I'd leave that up > to the Case Owner and the Case Submitter to work out before > submitting the Fast Track. > > I'm asking the naive question presuming the Case Owner has approved > of the general architecture and that's less up for discussion. > If ioctls are the wrong architecture, the Case Owner should just > derail or withdraw the case. > > Gary.. > --Boundary_(ID_kprjKwrTuvMs3C+Qn/I8dw) Content-type: text/plain; name=ipv6nat.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=ipv6nat.txt IPv6 NAT for IP Filter Overview ======== This change request aims to provide IPv6 NAT capabilities for IP Filter. The requested release binding is micro/patch. Customer impact =============== ABI compatibility with the old structure definitions is preserved by this case. Applications that do not use memset/bzero to zero the entire structure passed into the kernel (as shown in the example code for ipnat(7i)) may fail after recompiled if they do not set nl_v/nat_v to the correct version before doing the ioctl call. See below for more details on structure changes for ioctls. Out of scope ============ Several kernel proxies are built in the IP Filter IPv4 NAT code, such as ftp, h.323, ipsec, irc, pptp, raudio, rcmd, and rpcb. There will be no provision for IPv6 kernel proxy support in this project. Interface changes ================= There are three interface changes made by this project. They are ipnat command usage, ipmon output, and SIOCGNATL/SIOCSTPUT ioctl input. ipnat ----- The only change to user orientated interfaces is to extend the ipnat command. Users will be able to specify IPv6 addresses and netmasks in NAT rules. A simple IPv6 NAT rule could be written as: map ce0 fec0:1::/64 -> fec0:2::2 Any usage format following the grammar in ipnat.conf(4) are accepted. Below are some examples for portmap, map-block and rdr rules: map ppp0 fec0:1::/64 -> 2000:1:2::/72 portmap tcp/udp 1025:65000 map-block ppp0 fe80:0:0:209::/64 -> 209:1:2::/72 ports auto rdr ce0 209::ffff:fe13:e43e port 80 -> fec0:1::e,fec0:1::f port 80 tcp round-robin One cannot specify both IPv4 and IPv6 addresses in the same rule. If any IPv6 address is specified, the "mapproxy" and "rdrproxy" options will not be allowed to use in the same rule. See ipnat.conf(4). ipmon ----- To log IPv6 NAT packets, ipmon will be updated to include IPv6 addresses as part of its output, which is a volatile interface. ioctls ------ For ioctl SIOCGNATL, the structure "natlookup_t" has been changed to be able to contain IPv6 addresses. A new member "nl_v" is added to specify whether it is looking for an IPv4 or an IPv6 NAT session. For compatibilities, IPv4 NAT session lookup doesn't need to assign "nl_v". See ipnat(7i). For ioctl SIOCSTPUT, A new member "nat_v" is added to the structure "nat_t" to specify whether it is inserting an IPv4 or an IPv6 NAT session. For compatibilities, inserting an IPv4 NAT session doesn't need to assign "nat_v". See ipnat(7i). Package Impact ============== SUNWipfr SUNWipfu SUNWipfh Reference ========= [1] PSARC 2003/046 Solaris IP Filter [2] PSARC 2005/201 IPv6 for IP Filter [3] PSARC 2005/233 IPFilter API for NAT entry duplicate detection [4] RFE: 6600474 Need ipv6 support on NAT Appendix A - structure changes ============================== Below are the changes to ipnat(7i) @@ -67,9 * Structure used with SIOCGNATL. */ typedef struct natlookup { - struct in-addr nl_inip; - struct in_addr nl_outip; - struct in_addr nl_realip; + i6addr_t nl_inipaddr; + i6addr_t nl_outipaddr; + i6addr_t nl_realipaddr; + int nl_v; int nl_flags; u_short nl_inport; u_short nl_outport; @@ -76,6 +77,13 @@ u_short nl_realport; } natlookup_t +#define nl_inip nl_inipaddr.in4 +#define nl_outip nl_outipaddr.in4 +#define nl_realip nl_realipaddr.in4 +#define nl_inip6 nl_inipaddr.in6 +#define nl_outip6 nl_outipaddr.in6 +#define nl_realip6 nl_realipaddr.in6 + /* * Accepted values for nl_flags */ @@ -169,6 +177,7 @@ int nat_hv[2]; char nat_ifnames[2][LIFNAMSIZ]; int nat_rev; + int nat_v; } nat_t; #define nat_inip nat_inip6.in4 --Boundary_(ID_kprjKwrTuvMs3C+Qn/I8dw)-- From gww@eng.sun.com Tue Apr 22 12:38:02 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MJc14q000383 for ; Tue, 22 Apr 2008 12:38:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3MJbvjK006933 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 23 Apr 2008 03:38:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ00709RVBZV00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 12:37:59 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ00EUJRVA5SE0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 12:37:58 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MJbusZ057761; Tue, 22 Apr 2008 12:37:56 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m3MJbg7q021335; Tue, 22 Apr 2008 12:37:42 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3MJbgdl021334; Tue, 22 Apr 2008 12:37:42 -0700 (PDT) Date: Tue, 22 Apr 2008 12:37:42 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter To: Darren.Reed@sun.com, gww@eng.sun.com Cc: Evan.Xu@sun.com, PSARC-ext@sun.com Message-id: <200804221937.m3MJbgdl021334@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1116 > >> Feel free to accost said mangler when he returns O:-) > >> > > > > I'm not sure what the reasons are, or if they really matter > > unless the architecture is wrong and then I'd leave that up > > to the Case Owner and the Case Submitter to work out before > > submitting the Fast Track. > > > > I'm asking the naive question presuming the Case Owner has approved > > of the general architecture and that's less up for discussion. > > If ioctls are the wrong architecture, the Case Owner should just > > derail or withdraw the case. > > As an intern, am I able to derail it? > As far as I'm aware I'm not able to but I would support a member doing so. Technically no. However, if you raise the issue and intern the case, I'd expect a Member to call the actual derail. So, my further point is a Fast Track Case Owner is generally expected not to have unstated architectural issues with the case being sponsored. If there are unstated architectural issues, please state them. If they are such that a full case is desirable, say so and suggest the case be derailed for full review. Gary.. From John.Plocher@sun.com Tue Apr 22 13:12:16 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MKCGGW002193 for ; Tue, 22 Apr 2008 13:12:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MKCChZ004675 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Apr 2008 21:12:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ00B0NTGCO600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 13:12:12 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ00AI9TGCIH40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 13:12:12 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MKCCU8014735 for ; Tue, 22 Apr 2008 13:12:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZQ00J01T5RVZ00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 13:12:12 -0700 (PDT) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZQ00F8VTGB08D0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 13:12:11 -0700 (PDT) Date: Tue, 22 Apr 2008 13:12:11 -0700 From: John Plocher Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <200804221937.m3MJbgdl021334@marduk.eng.sun.com> Sender: John.Plocher@sun.com Cc: PSARC-ext@sun.com, Evan.Xu@sun.com Message-id: <480E469B.5090600@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804221937.m3MJbgdl021334@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 911 >>>> Feel free to accost said mangler when he returns O:-) >>>> >>> I'm not sure what the reasons are, or if they really matter >>> unless the architecture is wrong and then I'd leave that up >>> to the Case Owner and the Case Submitter to work out before >>> submitting the Fast Track. This is an important point. There is an explicit expectation that the fasttrack Sponsor has reviewed the fasttrack and convinced themselves that it is indeed fasttrack material (obvious and non controversial) AND that the proposal being submitted is a true and complete description of the project itself. The reason the ARC can get by with a somewhat superficial email review for fasttracks is /because/ they rely on the Sponsor to do a good job with the above. If the Sponsor doesn't do their job well, everyone suffers. This includes saying no when asked to sponsor something that is incomplete. -John From gww@eng.sun.com Tue Apr 22 14:52:32 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MLqVWT006332 for ; Tue, 22 Apr 2008 14:52:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3MLq5dI025687 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 23 Apr 2008 05:52:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ00M05Y3GV600@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 14:52:28 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ00EOTY3GUC30@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 14:52:28 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MLqQiZ002154; Tue, 22 Apr 2008 14:52:26 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m3MLqCN0021584; Tue, 22 Apr 2008 14:52:12 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3MLqCHA021583; Tue, 22 Apr 2008 14:52:12 -0700 (PDT) Date: Tue, 22 Apr 2008 14:52:12 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter To: Evan.Xu@sun.com, gww@eng.sun.com Cc: Darren.Reed@sun.com, psarc-ext@sun.com Message-id: <200804222152.m3MLqCHA021583@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2224 > I am sending the updated spec with respect to Gary's issue. I'm still confused on how changing the size of structures is mitigated in a patch release. What am I misunderstanding? Further I don't see any expression of the interface stability in the updated spec. Did I miss that also? Gary.. > > I'm not sure what "External Stable" is, so I'll take it as the > > former Stable which is the current Committed. And I'll ask again: > > "How is the incompatible change mitagated for the requested Patch > > release binding?" > ioctls > ------ > For ioctl SIOCGNATL, the structure "natlookup_t" has been changed to be able to > contain IPv6 addresses. A new member "nl_v" is added to specify whether it is > looking for an IPv4 or an IPv6 NAT session. For compatibilities, IPv4 NAT session > lookup doesn't need to assign "nl_v". See ipnat(7i). > > For ioctl SIOCSTPUT, A new member "nat_v" is added to the structure "nat_t" to > specify whether it is inserting an IPv4 or an IPv6 NAT session. For compatibilities, > inserting an IPv4 NAT session doesn't need to assign "nat_v". See ipnat(7i). > @@ -67,9 > * Structure used with SIOCGNATL. > */ > typedef struct natlookup { > - struct in-addr nl_inip; > - struct in_addr nl_outip; > - struct in_addr nl_realip; > + i6addr_t nl_inipaddr; > + i6addr_t nl_outipaddr; > + i6addr_t nl_realipaddr; > + int nl_v; > int nl_flags; > u_short nl_inport; > u_short nl_outport; > @@ -76,6 +77,13 @@ > u_short nl_realport; > } natlookup_t > > +#define nl_inip nl_inipaddr.in4 > +#define nl_outip nl_outipaddr.in4 > +#define nl_realip nl_realipaddr.in4 > +#define nl_inip6 nl_inipaddr.in6 > +#define nl_outip6 nl_outipaddr.in6 > +#define nl_realip6 nl_realipaddr.in6 > + > /* > * Accepted values for nl_flags > */ > @@ -169,6 +177,7 @@ > int nat_hv[2]; > char nat_ifnames[2][LIFNAMSIZ]; > int nat_rev; > + int nat_v; > } nat_t; > > #define nat_inip nat_inip6.in4 From Evan.Xu@sun.com Tue Apr 22 22:16:46 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3N5Gkkq018367 for ; Tue, 22 Apr 2008 22:16:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3N5GjnG043487 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 22 Apr 2008 23:16:46 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZR00A1LINWOL00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 23:16:44 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZR001YRINVAV50@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 23:16:44 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3N5GvJH000713 for ; Wed, 23 Apr 2008 05:16:57 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZR00K01IBRJC00@mail-apac.sun.com> (original mail from Evan.Xu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 Apr 2008 13:15:55 +0800 (SGT) Received: from [129.158.219.204] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZR00BCZIMDRE4T@mail-apac.sun.com>; Wed, 23 Apr 2008 13:15:55 +0800 (SGT) Date: Wed, 23 Apr 2008 13:15:45 +0800 From: yifan evan xu - Sun Microsystems - Beijing China Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <200804222152.m3MLqCHA021583@marduk.eng.sun.com> Sender: Evan.Xu@sun.com To: Gary Winiger Cc: Darren.Reed@sun.com, psarc-ext@sun.com Message-id: <480EC601.6000303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804222152.m3MLqCHA021583@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 3142 Gary Winiger wrote: >> I am sending the updated spec with respect to Gary's issue. >> > > I'm still confused on how changing the size of structures > is mitigated in a patch release. What am I misunderstanding? > The IPFILTER_VERSION (see ipnat(7i)) is used to keep track of user application's version thus the old binaries can still work after this change. The kernel code would handle the ioctl input/output based on the version number to make it a compatible change. Those are all implementation changes and there's no change required for user applications using the interfaces, either using the old binaries or recompiling with the new header files. > Further I don't see any expression of the interface stability > in the updated spec. Did I miss that also? > There is no new interface exported in this case. The one-pager comment states that stability levels are required for new exported interface. Correct me if I was wrong. The stabilities (External Stable) of ipnat(7i) and the header files are defined in: [3] PSARC 2005/233 IPFilter API for NAT entry duplicate detection Yifan > Gary.. > >>> I'm not sure what "External Stable" is, so I'll take it as the >>> former Stable which is the current Committed. And I'll ask again: >>> "How is the incompatible change mitagated for the requested Patch >>> release binding?" >>> > > >> ioctls >> ------ >> For ioctl SIOCGNATL, the structure "natlookup_t" has been changed to be able to >> contain IPv6 addresses. A new member "nl_v" is added to specify whether it is >> looking for an IPv4 or an IPv6 NAT session. For compatibilities, IPv4 NAT session >> lookup doesn't need to assign "nl_v". See ipnat(7i). >> >> For ioctl SIOCSTPUT, A new member "nat_v" is added to the structure "nat_t" to >> specify whether it is inserting an IPv4 or an IPv6 NAT session. For compatibilities, >> inserting an IPv4 NAT session doesn't need to assign "nat_v". See ipnat(7i). >> > > >> @@ -67,9 >> * Structure used with SIOCGNATL. >> */ >> typedef struct natlookup { >> - struct in-addr nl_inip; >> - struct in_addr nl_outip; >> - struct in_addr nl_realip; >> + i6addr_t nl_inipaddr; >> + i6addr_t nl_outipaddr; >> + i6addr_t nl_realipaddr; >> + int nl_v; >> int nl_flags; >> u_short nl_inport; >> u_short nl_outport; >> @@ -76,6 +77,13 @@ >> u_short nl_realport; >> } natlookup_t >> >> +#define nl_inip nl_inipaddr.in4 >> +#define nl_outip nl_outipaddr.in4 >> +#define nl_realip nl_realipaddr.in4 >> +#define nl_inip6 nl_inipaddr.in6 >> +#define nl_outip6 nl_outipaddr.in6 >> +#define nl_realip6 nl_realipaddr.in6 >> + >> /* >> * Accepted values for nl_flags >> */ >> @@ -169,6 +177,7 @@ >> int nat_hv[2]; >> char nat_ifnames[2][LIFNAMSIZ]; >> int nat_rev; >> + int nat_v; >> } nat_t; >> >> #define nat_inip nat_inip6.in4 >> From gww@eng.sun.com Tue Apr 22 22:57:31 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3N5vVWO018929 for ; Tue, 22 Apr 2008 22:57:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3N5vSne019377 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 23 Apr 2008 06:57:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZR00303KJRP400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 22:57:27 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZR00EONKJQ27A0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Apr 2008 22:57:26 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3N5vPDW045796; Tue, 22 Apr 2008 22:57:25 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m3N5vBPu022175; Tue, 22 Apr 2008 22:57:11 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3N5vBIs022174; Tue, 22 Apr 2008 22:57:11 -0700 (PDT) Date: Tue, 22 Apr 2008 22:57:11 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter To: Evan.Xu@sun.com, gww@eng.sun.com Cc: Darren.Reed@sun.com, psarc-ext@sun.com Message-id: <200804230557.m3N5vBIs022174@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1677 > > I'm still confused on how changing the size of structures > > is mitigated in a patch release. What am I misunderstanding? > > > > The IPFILTER_VERSION (see ipnat(7i)) is used to keep track of user So part of this case, so far unstated is that IPFILTER_VERSION is be incremented. That seems pretty important to mention up front. > application's version thus the old binaries can still work after this > change. The kernel code would handle the ioctl input/output based on the > version number to make it a compatible change. Those are all > implementation changes and there's no change required for user > applications using the interfaces, either using the old binaries or > recompiling with the new header files. > There is no new interface exported in this case. The one-pager comment > states that stability levels are required for new exported interface. > Correct me if I was wrong. The stabilities (External Stable) of > ipnat(7i) and the header files are defined in: There is no such stablilty. Update the man page to a correct stability. see attributes(5): Old New Comments _________________________________________________________________ Standard Committed An entry in the attributes table for the Standard attribute type should appear. Stable Committed Name change. Evolving Uncommitted Actual commitments match. Unstable Uncommitted Name change. External Volatile Name change with expansion of allowed usage. Obsolete (Obsolete) Was a classification, now a modifier. Are these interfaces Committed? Gary.. From Evan.Xu@sun.com Wed Apr 23 01:00:43 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3N80h2q023221 for ; Wed, 23 Apr 2008 01:00:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3N80fIW014359 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 23 Apr 2008 01:00:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZR00M0BQ958B00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 Apr 2008 02:00:41 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZR00JPCQ92J110@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 Apr 2008 02:00:40 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3N80rQF014669 for ; Wed, 23 Apr 2008 08:00:53 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZR00501PWTYZ00@mail-apac.sun.com> (original mail from Evan.Xu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 Apr 2008 15:59:50 +0800 (SGT) Received: from [129.158.219.204] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZR00BH0Q7DRFDE@mail-apac.sun.com>; Wed, 23 Apr 2008 15:59:38 +0800 (SGT) Date: Wed, 23 Apr 2008 15:59:34 +0800 From: yifan evan xu - Sun Microsystems - Beijing China Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <200804230557.m3N5vBIs022174@marduk.eng.sun.com> Sender: Evan.Xu@sun.com To: Gary Winiger Cc: Darren.Reed@sun.com, psarc-ext@sun.com Message-id: <480EEC66.8020702@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_9oH0W+t3nt6JUCZOOPFc1g)" X-PMX-Version: 5.4.1.325704 References: <200804230557.m3N5vBIs022174@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 8972 This is a multi-part message in MIME format. --Boundary_(ID_9oH0W+t3nt6JUCZOOPFc1g) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT Gary Winiger wrote: >>> I'm still confused on how changing the size of structures >>> is mitigated in a patch release. What am I misunderstanding? >>> >>> >> The IPFILTER_VERSION (see ipnat(7i)) is used to keep track of user >> > > So part of this case, so far unstated is that IPFILTER_VERSION > is be incremented. That seems pretty important to mention > up front. > >> There is no new interface exported in this case. The one-pager comment >> states that stability levels are required for new exported interface. >> Correct me if I was wrong. The stabilities (External Stable) of >> ipnat(7i) and the header files are defined in: >> >> Are these interfaces Committed? >> >> >> According to your advice, I exported IPFILTER_VERSION as a Committed interface, as well as "netinet/ipl.h" as an Uncommitted interface. See the interface table in the updated spec. Stability level is changed to Committed for ipnat(7i), and I also appended the changes to ipnat.conf(4) in the appendix. Yifan --Boundary_(ID_9oH0W+t3nt6JUCZOOPFc1g) Content-type: text/plain; name=ipv6nat.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=ipv6nat.txt IPv6 NAT for IP Filter Overview ======== This change request aims to provide IPv6 NAT capabilities for IP Filter. The requested release binding is micro/patch. Customer impact =============== ABI compatibility with the old structure definitions is preserved by this case. Applications that do not use memset/bzero to zero the entire structure passed into the kernel (as shown in the example code for ipnat(7i)) may fail after recompiled if they do not set nl_v/nat_v to the correct version before doing the ioctl call. See below for more details on structure changes for ioctls. Out of scope ============ Several kernel proxies are built in the IP Filter IPv4 NAT code, such as ftp, h.323, ipsec, irc, pptp, raudio, rcmd, and rpcb. There will be no provision for IPv6 kernel proxy support in this project. Interface changes ================= There are three interface changes made by this project. They are ipnat command usage, ipmon output, and SIOCGNATL/SIOCSTPUT ioctl input. ipnat ----- The only change to user orientated interfaces is to extend the ipnat command. Users will be able to specify IPv6 addresses and netmasks in NAT rules. A simple IPv6 NAT rule could be written as: map ce0 fec0:1::/64 -> fec0:2::2 Any usage format following the grammar in ipnat.conf(4) are accepted. Below are some examples for portmap, map-block and rdr rules: map ppp0 fec0:1::/64 -> 2000:1:2::/72 portmap tcp/udp 1025:65000 map-block ppp0 fe80:0:0:209::/64 -> 209:1:2::/72 ports auto rdr ce0 209::ffff:fe13:e43e port 80 -> fec0:1::e,fec0:1::f port 80 tcp round-robin One cannot specify both IPv4 and IPv6 addresses in the same rule. If any IPv6 address is specified, the "mapproxy" and "rdrproxy" options will not be allowed to use in the same rule. See ipnat.conf(4). ipmon ----- To log IPv6 NAT packets, ipmon will be updated to include IPv6 addresses as part of its output, which is a volatile interface. ioctls ------ For ioctl SIOCGNATL, the structure "natlookup_t" has been changed to be able to contain IPv6 addresses. A new member "nl_v" is added to specify whether it is looking for an IPv4 or an IPv6 NAT session. For compatibilities, IPv4 NAT session lookup doesn't need to assign "nl_v". See ipnat(7i). For ioctl SIOCSTPUT, A new member "nat_v" is added to the structure "nat_t" to specify whether it is inserting an IPv4 or an IPv6 NAT session. For compatibilities, inserting an IPv4 NAT session doesn't need to assign "nat_v". See ipnat(7i). Interface Classification Comments --------- -------------- -------- IPFILTER_VERSION Committed see ipnat(7i) ioctl SIOCGNATL Committed see ipnat(7i) ioctl SIOCSTPUT Committed see ipnat(7i) ioctl SIOCSTLCK Committed see ipnat(7i) struct natlookup Uncommitted see ipnat(7i) struct nat Uncommitted see ipnat(7i) /usr/include/netinet/ipl.h Uncommitted IPFilter header /usr/include/netinet/ip_fil.h Uncommitted IPFilter header /usr/include/netinet/ip_nat.h Uncommitted IPFilter header Package Impact ============== SUNWipfr SUNWipfu SUNWipfh Reference ========= [1] PSARC 2003/046 Solaris IP Filter [2] PSARC 2005/201 IPv6 for IP Filter [3] PSARC 2005/233 IPFilter API for NAT entry duplicate detection [4] RFE: 6600474 Need ipv6 support on NAT Appendix A - changes to ipnat(7i) ================================= @@ -44,8 +44,9 @@ int ipfo_offset; /* bytes from ipfo_ptr where to start */ u_char ipfo_xxxpad[32]; /* reserved for future use */ } ipfobj_t; + #define IPFILTER_VERSION 4010901 /* IPFilter version */ #define IPFOBJ_NATSAVE 8 /* struct nat_save */ #define IPFOBJ_NATLOOKUP 9 /* struct natlookup */ @@ -102,21 +103,29 @@ returned to the caller. - /* + /* * Structure used with SIOCGNATL. */ typedef struct natlookup { - struct in-addr nl_inip; - struct in_addr nl_outip; - struct in_addr nl_realip; + i6addr_t nl_inipaddr; + i6addr_t nl_outipaddr; + i6addr_t nl_realipaddr; + int nl_v; int nl_flags; u_short nl_inport; u_short nl_outport; u_short nl_realport; } natlookup_t + #define nl_inip nl_inipaddr.in4 + #define nl_outip nl_outipaddr.in4 + #define nl_realip nl_realipaddr.in4 + #define nl_inip6 nl_inipaddr.in6 + #define nl_outip6 nl_outipaddr.in6 + #define nl_realip6 nl_realipaddr.in6 + /* * Accepted values for nl_flags */ #define IPN_TCP 0x00001 @@ -241,8 +250,9 @@ int nat_ref; int nat_hv[2]; char nat_ifnames[2][LIFNAMSIZ]; int nat_rev; + int nat_v; } nat_t; #define nat_inip nat_inip6.in4 #define nat_outip nat_outip6.in4 @@ -473,9 +483,9 @@ ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| - | Interface Stability | External Stable | + | Interface Stability | Committed | |_____________________________|_____________________________| Appendix B - changes to ipnat.conf(4) ===================================== @@ -149,15 +149,18 @@ same expressions available with ipf. A simple NAT rule could be written as: map de0 10.1.0.0/16 -> 201.2.3.4/32 + map de0 fec0:1::/64 -> fec0:2::2/128 or as map de0 from 10.1.0.0/16 to any -> 201.2.3.4/32 + map de0 from fec0:1::/64 to any -> fec0:2::2/128 As is true of all NAT rules, you can compare against only IP - address and port numbers. + address and port numbers. In addition, one cannot specify b- + oth IPv4 and IPv6 addresses in the same rule. Translation To the right of the -> is the address and port specification that will be written into the packet, provided it has @@ -232,9 +235,10 @@ Kernel Proxies The IP Filter software comes with a few, simple, proxies built into the code that is loaded into the kernel to allow secondary channels to be opened without forcing the packets - through a user program. + through a user program. Kernel proxies are not supported for + IPv6 NAT-ing. Transparent Proxies True transparent proxying should be performed using the redirect (rdr) rules directing ports to localhost --Boundary_(ID_9oH0W+t3nt6JUCZOOPFc1g)-- From Darren.Reed@sun.com Wed Apr 23 22:41:07 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3O5f7Bc007012 for ; Wed, 23 Apr 2008 22:41:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3O5f4IU016320 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 23 Apr 2008 23:41:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZT00601EFWDB00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 Apr 2008 22:40:44 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZT00GRBEFVNX70@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 Apr 2008 22:40:44 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3O5evuv007074 for ; Thu, 24 Apr 2008 05:40:57 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZT00F01EDQFB00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 24 Apr 2008 13:40:32 +0800 (SGT) Received: from [10.13.21.205] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZT00MQYEFJ9UVI@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 24 Apr 2008 13:40:32 +0800 (SGT) Date: Thu, 24 Apr 2008 13:40:19 +0800 From: Darren Reed Subject: Re: PSARC/2008/250 IPv6 NAT for IPFilter In-reply-to: <480EEC66.8020702@sun.com> Sender: Darren.Reed@sun.com To: yifan evan xu - Sun Microsystems - Beijing China Cc: psarc-ext@sun.com Message-id: <48101D43.6030500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804230557.m3N5vBIs022174@marduk.eng.sun.com> <480EEC66.8020702@sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 51 This case was approved on the 23rd of April 2008.