From mailman-owner@ietf.org Wed May 1 06:45:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17656 for ; Wed, 1 May 2002 06:45:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10641 for ; Wed, 1 May 2002 06:45:35 -0400 (EDT) Date: Wed, 1 May 2002 06:45:35 -0400 (EDT) Message-Id: <200205011045.GAA10641@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: nat-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nat-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for nat-archive@lists.ietf.org: List Password // URL ---- -------- nat@ietf.org qLLL https://www1.ietf.org/mailman/options/nat/nat-archive@lists.ietf.org From nat-admin@ietf.org Mon May 6 05:42:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10913 for ; Mon, 6 May 2002 05:42:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08002; Mon, 6 May 2002 05:36:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07983 for ; Mon, 6 May 2002 05:36:27 -0400 (EDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10773 for ; Mon, 6 May 2002 05:36:19 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 06 May 2002 15:25:30 +0530 Received: from arumugamv (arumugamv.future.futsoft.com [10.20.6.91]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g469Zbk03066 for ; Mon, 6 May 2002 15:05:37 +0530 Reply-To: From: "Arumugam V" To: Date: Mon, 6 May 2002 15:07:44 +0530 Message-Id: <001601c1f4e1$ad23ad60$5b06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NAT] NAT Tables... Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Hi, I am Arumugam, new to this NAT area. I'm looking into the lattest draft version of the NAT MIB. Can anyone help me to understand the BIND and SESSION tables of the NAT. 1. when the BIND Table entries would be created and how it's different from Session table. Your help would be appreciated. Thanks and Regards, Arumugam *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From daemon@optimus.ietf.org Mon May 6 06:29:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10922 for ; Mon, 6 May 2002 05:42:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA08174 for nat-archive@odin.ietf.org; Mon, 6 May 2002 05:42:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08002; Mon, 6 May 2002 05:36:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07983 for ; Mon, 6 May 2002 05:36:27 -0400 (EDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10773 for ; Mon, 6 May 2002 05:36:19 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 06 May 2002 15:25:30 +0530 Received: from arumugamv (arumugamv.future.futsoft.com [10.20.6.91]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g469Zbk03066 for ; Mon, 6 May 2002 15:05:37 +0530 Reply-To: From: "Arumugam V" To: Date: Mon, 6 May 2002 15:07:44 +0530 Message-Id: <001601c1f4e1$ad23ad60$5b06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NAT] NAT Tables... Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Hi, I am Arumugam, new to this NAT area. I'm looking into the lattest draft version of the NAT MIB. Can anyone help me to understand the BIND and SESSION tables of the NAT. 1. when the BIND Table entries would be created and how it's different from Session table. Your help would be appreciated. Thanks and Regards, Arumugam *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From owner-nat@portmasters.com Mon May 6 11:40:09 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24032 for ; Mon, 6 May 2002 11:40:09 -0400 (EDT) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g46E0dl07315 for nat-outgoing; Mon, 6 May 2002 09:00:39 -0500 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-nat@portmasters.com using -f From: BTang11111@aol.com Message-ID: <78.263b7231.2a07fa29@aol.com> Date: Mon, 6 May 2002 11:24:25 EDT Subject: (NAT) New ISDN/Analog Modem Always-ON technology RAS implementations on PortMaster4 To: portmaster-modems@portmasters.com CC: nat@portmasters.com, portmaster-announce@portmasters.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0.i for Windows 95 sub 161 Sender: owner-nat@portmasters.com Precedence: bulk Reply-To: BTang11111@aol.com Content-Transfer-Encoding: 7bit NEW SIMULATED ALWAYS-ON DIAL-UP TECHNOLOGY ANNOUNCEMENTS I attached below the Patent Descriptions of "Abbreviated Modem Negotiation Routines / METHODS FOR FAST DIAL-ON-DEMAND INTERNET ACCESS WITH MODEMS , VIA PUBLIC SWITCHED TELEPHONE NETWORKS, BYPASSING PRESENT LENGTHY MODEM NEGOTIATIONS ENABLING APPARENT USER'S FULL SESSION-CONTINUITIES" In particular relevance to PM4 the patent could be readily implemented via RAS dial-up scripting, or console initialisations, from the Patent Descriptions in page 8 : NOTES 1. Modem units referred to may be virtual/software modems, eg Lucent [RTM] Technology PM4 's Modem DSP with PRI lines : the connecting of incoming DSO from PRI to specific Modem DSP could also be effected by assigning incoming DSO to the the same TDM bus time slot of the Modem DSP AND page 4 The method at its most basic essence requires that the reconnecting incoming calls be routed to the same Port #/Modem unit/Data channel (eg to the same DS0 of the ISP's PRI). As a very basic workable example (only one of several!) of PBX Module implementation for ISPs with Lucent [RTM] Technology PortMaster4 and PRI lines (note that there is no modem banks deployed here), all that is required is for the ISP's Telecommunication Service Provider to customise the Exchange Switching Software to suppress the disconnection event and reserve the same DSO of the PRI for Dial-in subscriber to reconnect (identified by Caller-ID) within the said 15 minutes after disconnection. Where subscriber does not reconnect within the said 15 minutes, the Exchange Switching terminates and releases the DSO in the usual manner. The DSO link is treated by ISP as 'live' (thus enabling Dial-in subscriber to reconnect the PSTN line and be immediately Online again to continue the same Session from where was left off retaining the same Session IP address) for 15 minutes after Dial-in subscriber's disconnection, although no datacommunication is possible until Dial-in subscriber reconnects the PSTN line (routed by Exchange Switching Software to the same DSO) within the said 15 minutes. WERE ANYONE INDIVIDUAL INTERESTED IN IMPLEMENTING SIMPLE PROTOTYPE DEMO / ORGANISATIONS INTERESTED IN COMMERCIAL COLLABORATIONS , PLEASE Email Private iwxchange@hotmail.com A 1st COMMERCIALLY READY SOFTWARE CD TITLE " ALWAYS ON TIME" (FOR ISDN/ MOBILE/ DIGITAL USB / WIRELESS MODEMS) IS CURRENTLY BEING RELEASED TO GENRAL PUBLIC VIA PC RETAIL STORES. see http://www.stagway.com IT IS HOPED THIS ALWAYS-ON DIAL-UP TECHNOLOGY READY IMPLEMENTATIONS ON PM4 WILL BRING PORTMASTERS GREAT NEW LEASE OF PROSPERITY! (& FOR DIAL-UPS ANALOG MODEMs/ ISDNs..) Kind Regards, Bob IWXChange, Inc http://www.freesurfs.co.uk PATENT DESCRIPTIONS METHODS FOR FAST DIAL-ON-DEMAND INTERNET ACCESS WITH MODEMS , VIA PUBLIC SWITCHED TELEPHONE NETWORKS, BYPASSING PRESENT LENGTHY MODEM NEGOTIATIONS ENABLING APPARENT USER'S FULL SESSION-CONTINUITIES Fast Dial-on-Demand establishes the physical line connections only upon request from user's application programs (such as web browser) and disconnects when not in use for data transmissions, eliminating requirement for the PSTN connection to be maintained throughout the user session thus achieving substantial cost savings. The methods presented here bypass present lengthy modem renogotiations (typically 20-30 seconds) to effect fast establishment/ re-establishment of ISO Application -Oriented Layer communication link between user Application Programs/Browsers and Internet Sevice Provider, and enables complete session continuity without user being aware of noticable difference due to frequent connections/disconnections of PSTN line. 2 METHOD 1 ========= Internet Service Provider implements a PBX module which monitors incoming calls extracting DTMF Caller-ID (ie caller's phone number) and checks against existing maintained table of modem unit # (or Port #, Data channel)/ Caller-ID to switch the incoming call to the corresponding modem unit (or Port #/Data channel) )if found on the table. If not already on the table, it will be treated as a first time dial-up connection, whereupon the usual modem negotiations, authentications and Dynamic IP address assignment will take place and therafter a new modem unit #(or Port #, data channel)/ Caller-ID entry for this session connection will be created on the Table. The ISP could set the Idle Period before terminating session to say 15 minutes; if there has been no transmission line activities during this period the user's Dial-on-Demand session will be terminated, the modem unit and Dynamically assigned IP address returned to resource pool, and the corresponding modem unit # (or Port #,data channel) / caller-ID entry removed from Table. This prevents tying up of modem(or Port, datachannel), IP address resources by inactive Dial-on-demand sessions. The ISP modem setting for elapsed time period before terminating line connection upon NO CARRIER DETECT (ie caused by user Dial-on-demand software package hanging up telephone line when there are no data transmissions) could be set to the same 15 minutes above, to allow for subsequent instantaneous modem reconnections to new incoming calls by the same user session if within the 15 minutes period after user Dial-on-Demand software package last hanging up on the PSTN line connection. The user Dial-on-demand software package could be set by user to hang up on the PSTN line connection to ISP after a period of say 45 seconds transmissions inactivity to save on phone 3 costs. Most browsers have webpage access connection time-out of around 30 seconds, ie browsers will abort attempt to download webpage if access to the URL site clicked on was not established by then. Within the next 15 minutes after hanging up whenever the Dial-on-demand software package detects via user's Operating System (eg Telecommunication Application Programming Interface environment of Microsoft [RTM] Windows Operating systems) user program's request for Internet access, the software package redials the ISP number; whereupon the ISP module checks the incoming Caller-ID against Table of modem unit # (or Port#, Data channel) / Caller-ID to route the incoming call to be connected to the corresponding modem unit (or Port #, data channel) it was previously connected to. The Dial-on-Demand Software Package insulates the user's Application Programs/Browsers from the PSTN line connection/disconnection events : the Application Programs/Browsers could assume the PSTN line is connected all the time. The user Dial-on-Demand software package could further saves on phone connection costs by immediately hanging up PSTN line when webpages/files download from Internet site is completed, or when browser is not expecting any further incoming response to outgoing transmissions sent. The status/ events are detected by software package from the informations contained in Operating System (eg Telephony Applications Programming Interface environment of Windows). The user Dial-on-demand software package could also monitors incoming call's DTMF Caller-ID from ISP during the next 15 minutes above after software package hanging up the PSTN line connection (which signifies that there's incoming data transmission while the PSTN line is hung up after inactivity period of 45 seconds above, were ISP server software incorporated Dialling to user to notify of incoming transmissions for the Session); upon such detection to redial to ISP, whereupon the ISP PBX module effects fast re-establishment of communication link. 4 The method enables apparent user's full session-continuity , ie HTTP/FTP/TELNET/ONLINE GAMING/AUDIOVISUAL STREAMING continuities. The method at its most basic essence requires that the reconnecting incoming calls be routed to the same Port #/Modem unit/Data channel (eg to the same DS0 of the ISP's PRI). As a very basic workable example (only one of several!) of PBX Module implementation for ISPs with Lucent [RTM] Technology PortMaster4 and PRI lines (note that there is no modem banks deployed here), all that is required is for the ISP's Telecommunication Service Provider to customise the Exchange Switching Software to suppress the disconnection event and reserve the same DSO of the PRI for Dial-in subscriber to reconnect (identified by Caller-ID) within the said 15 minutes after disconnection. Where subscriber does not reconnect within the said 15 minutes, the Exchange Switching terminates and releases the DSO in the usual manner. The DSO link is treated by ISP as 'live' (thus enabling Dial-in subscriber to reconnect the PSTN line and be immediately Online again to continue the same Session from where was left off retaining the same Session IP address) for 15 minutes after Dial-in subscriber's disconnection, although no datacommunication is possible until Dial-in subscriber reconnects the PSTN line (routed by Exchange Switching Software to the same DSO) within the said 15 minutes. 5 METHOD 2 ========= By having a pre-arranged common modem settings, eg specific common connection rate (eg 56KBS), hardware flow control, parity, compression; and installing modified modem drivers to connect at above pre-arranged common settings at both ISP & user modems, lengthy modem negotiation is bypassed for every Dial-ins achieving fast establishment (eg 1 second-4 seconds) of ISO Application-Oriented Layer communication link. The ISP access authentication server system only needs to maintain/check a table of current Session dynamic IP address assigned / Caller-ID to ensure that the reconnecting user gets assigned the same IP address at every subsequent reconnections if reconnecting within a period of say 1 hour since last PSTN line disconnection ( else the corresponding IP address / Caller-ID entry is removed from Table and the IP is returned to the resource pool ). If the Caller-ID is not on the Table on user dial-in, the server will dynamically assign a new IP address for the session, and create a correponding current Session dynamic IP address assigned/Caller-ID entry on the Table. On its own, or together with user Dial-on-demand software package described in Method 1, this Method enables apparent user's full session-continuity, ie HTTP/FTP/TELNET/ONLINE GAMING/AUDIOVISUAL STREAMING continuities. 6 METHOD 3 ========= The ISP maintains a 'State Information' of all users by their Caller-ID. The 'State Information' contains permanent details of user's modem connection settings (eg user specific connection speed/protocol, flow control method, parity, compression method) and details of user's current Dynamically assigned IP address for the Session. The user modem driver is modified to connect at above user specific settings, & an appropriate ISP modem driver is selected corresponding to the incoming Caller-ID & assigned to the ISP modem unit, before the incoming line is picked up by the modem unit, hence doing away with lengthy modem negotiations. Upon detection of DTMF Caller-ID for the Dial-in to a modem, the ISP server will select an appropriate modem driver & set the modem unit to the user specific modem setting details contained in the Caller-ID's 'State Information' before the modem unit picks up the incoming line thus bypassing lengthy modem negotiations, authenticates user and assigns user with the same IP address entry in the 'State Information' if present. If IP address is absent the ISP access authentication server will dynamically assign a new IP address to user for the Session, and record it in user's current Dynamically assigned Session IP address field of user's 'State Information'. After a pre-set Idle Period of say 1 hour the entry in Session IP address from the field in 'State Information' is removed & the IP address is returned to resource pool ( to prevent excessive tying up of IP resource by inactive sessions ) , and any subsequent Dial-in will then be assigned a new new Session IP address. 7 On its own, or together with user Dial-on-Demand software package described in Method 1, this method enables fast establishments (eg 1second-4 seconds) of ISO Application-Oriented Layer communication link, together with apparent user's full session-continuity, ie HTTP/FTP/TELNET/ONLINE GAMING/AUDIOVISUAL STREAMING continuities. 8 NOTES 1. Modem units referred to may be virtual/software modems, eg Lucent [RTM] Technology PM4 's Modem DSP with PRI lines : the connecting of incoming DSO from PRI to specific Modem DSP could also be effected by assigning incoming DSO to the the same TDM bus time slot of the Modem DSP. 2. The Dial-on-Demand software package is here described for predominantly Internet usage, but is also applicable for use in connection between any two user application programs on two computers connected by analog modems via PSTN line. 3. Method 1 described above may also be appled for users with digital Terminal Adapters instead of analog Modems. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe nat' in the body of the message. List archive: From nat-admin@ietf.org Mon May 6 14:53:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02815 for ; Mon, 6 May 2002 14:53:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11910; Mon, 6 May 2002 14:42:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05874 for ; Mon, 6 May 2002 13:03:19 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27367 for ; Mon, 6 May 2002 13:03:12 -0400 (EDT) Received: from cbin2-mira-01.cisco.com (IDENT:mirapoint@cbin2-mira-01.cisco.com [64.104.144.38]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g46H2dpY011864; Mon, 6 May 2002 10:02:40 -0700 (PDT) Received: from cisco.com ([64.104.147.119]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AEA04698 (AUTH raraghun); Mon, 6 May 2002 22:29:43 +0530 (IST) Message-ID: <3CD6B730.CC274748@cisco.com> Date: Mon, 06 May 2002 22:32:40 +0530 From: Rajiv Raghunarayan Reply-To: rrajiv@cisco.com Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: arumugamv@future.futsoft.com CC: nat@ietf.org Subject: Re: [NAT] NAT Tables... References: <001601c1f4e1$ad23ad60$5b06140a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Hi Arumugam, Here's my take on your question: One could separate NAT into two main classes - NAT and NAPT. The former works only on an address translation level while the latter addresses ports as well. The Address Bind table maintains information about the address-only binds. Note that in this case there could be more than one session branched off this BIND (and the loss of a session does not necessarily indicate loss of a BIND) i.e. one entry in the address bind table could map to zero or more entries in the session table. The Address Port Bind table, on the other hand, maintains info regarding napt. Typically one bind in this case would translate to one session, but there could be cases (twice nat) where two binds would combine to form one session entry. Further, if you consider a static binds i.e. no timeouts, a bind would always exist, but there is no guarantee that there is a session necessarily associated with the bind at all times. Hope this answers your query. -Rajiv. Arumugam V wrote: > > Hi, > > I am Arumugam, new to this NAT area. I'm looking into the lattest draft > version of the NAT MIB. > > Can anyone help me to understand the BIND and SESSION tables of the NAT. > > 1. when the BIND Table entries would be created and how it's different from > Session table. > > Your help would be appreciated. > > Thanks and Regards, > Arumugam > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > _______________________________________________ > nat mailing list > nat@ietf.org > https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From daemon@ns.ietf.org Mon May 6 14:53:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02824 for ; Mon, 6 May 2002 14:53:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12487 for nat-archive@odin.ietf.org; Mon, 6 May 2002 14:53:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11910; Mon, 6 May 2002 14:42:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05874 for ; Mon, 6 May 2002 13:03:19 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27367 for ; Mon, 6 May 2002 13:03:12 -0400 (EDT) Received: from cbin2-mira-01.cisco.com (IDENT:mirapoint@cbin2-mira-01.cisco.com [64.104.144.38]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g46H2dpY011864; Mon, 6 May 2002 10:02:40 -0700 (PDT) Received: from cisco.com ([64.104.147.119]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AEA04698 (AUTH raraghun); Mon, 6 May 2002 22:29:43 +0530 (IST) Message-ID: <3CD6B730.CC274748@cisco.com> Date: Mon, 06 May 2002 22:32:40 +0530 From: Rajiv Raghunarayan Reply-To: rrajiv@cisco.com Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: arumugamv@future.futsoft.com CC: nat@ietf.org Subject: Re: [NAT] NAT Tables... References: <001601c1f4e1$ad23ad60$5b06140a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Hi Arumugam, Here's my take on your question: One could separate NAT into two main classes - NAT and NAPT. The former works only on an address translation level while the latter addresses ports as well. The Address Bind table maintains information about the address-only binds. Note that in this case there could be more than one session branched off this BIND (and the loss of a session does not necessarily indicate loss of a BIND) i.e. one entry in the address bind table could map to zero or more entries in the session table. The Address Port Bind table, on the other hand, maintains info regarding napt. Typically one bind in this case would translate to one session, but there could be cases (twice nat) where two binds would combine to form one session entry. Further, if you consider a static binds i.e. no timeouts, a bind would always exist, but there is no guarantee that there is a session necessarily associated with the bind at all times. Hope this answers your query. -Rajiv. Arumugam V wrote: > > Hi, > > I am Arumugam, new to this NAT area. I'm looking into the lattest draft > version of the NAT MIB. > > Can anyone help me to understand the BIND and SESSION tables of the NAT. > > 1. when the BIND Table entries would be created and how it's different from > Session table. > > Your help would be appreciated. > > Thanks and Regards, > Arumugam > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > _______________________________________________ > nat mailing list > nat@ietf.org > https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Mon May 6 15:25:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03606 for ; Mon, 6 May 2002 15:25:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13668; Mon, 6 May 2002 15:15:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13642 for ; Mon, 6 May 2002 15:15:11 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03414 for ; Mon, 6 May 2002 15:15:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GVP00F01ESGUX@firewall.wcom.com> for nat@ietf.org; Mon, 6 May 2002 19:14:40 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GVP00EDFESFTO@firewall.wcom.com>; Mon, 06 May 2002 19:14:40 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GVP00J01ESBPQ@dgismtp01.wcomnet.com>; Mon, 06 May 2002 19:14:39 +0000 (GMT) Received: from rccc6131 ([166.35.224.50]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GVP00J4QERY0U@dgismtp01.wcomnet.com>; Mon, 06 May 2002 19:14:23 +0000 (GMT) Date: Mon, 06 May 2002 14:14:18 -0500 From: "Christopher A. Martin" Subject: RE: [NAT] NAT Tables... In-reply-to: <3CD6B730.CC274748@cisco.com> To: rrajiv@cisco.com, arumugamv@future.futsoft.com Cc: nat@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <003601c1f532$38f78500$32e023a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Comments inline.... -----Original Message----- From: nat-admin@ietf.org [mailto:nat-admin@ietf.org]On Behalf Of Rajiv Raghunarayan Sent: Monday, May 06, 2002 12:03 PM To: arumugamv@future.futsoft.com Cc: nat@ietf.org Subject: Re: [NAT] NAT Tables... Hi Arumugam, Here's my take on your question: One could separate NAT into two main classes - NAT and NAPT. The former works only on an address translation level while the latter addresses ports as well. ---------My comment------ Rajiv, could you calrify, I thought that NAT can work on both the network and/or transport layer (may use a port other than the originating hosts source port), whereas NAPT performs mapping totally at the transport layer, with exception of the single address(es) used for specific NAPT pools. I agree with your comment above except for my stated assumption, which I think should be addressed. Or is the standard for NAT to use the same transport layer address as the originating host (have not seen this, yet, in draft or RFC format) ----end comment----------- The Address Bind table maintains information about the address-only binds. Note that in this case there could be more than one session branched off this BIND (and the loss of a session does not necessarily indicate loss of a BIND) i.e. one entry in the address bind table could map to zero or more entries in the session table. The Address Port Bind table, on the other hand, maintains info regarding napt. Typically one bind in this case would translate to one session, but there could be cases (twice nat) where two binds would combine to form one session entry. Further, if you consider a static binds i.e. no timeouts, a bind would always exist, but there is no guarantee that there is a session necessarily associated with the bind at all times. Hope this answers your query. -Rajiv. Arumugam V wrote: > > Hi, > > I am Arumugam, new to this NAT area. I'm looking into the lattest draft > version of the NAT MIB. > > Can anyone help me to understand the BIND and SESSION tables of the NAT. > > 1. when the BIND Table entries would be created and how it's different from > Session table. > > Your help would be appreciated. > > Thanks and Regards, > Arumugam > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > _______________________________________________ > nat mailing list > nat@ietf.org > https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From daemon@ns.ietf.org Mon May 6 15:25:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03618 for ; Mon, 6 May 2002 15:25:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14119 for nat-archive@odin.ietf.org; Mon, 6 May 2002 15:25:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13668; Mon, 6 May 2002 15:15:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13642 for ; Mon, 6 May 2002 15:15:11 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03414 for ; Mon, 6 May 2002 15:15:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GVP00F01ESGUX@firewall.wcom.com> for nat@ietf.org; Mon, 6 May 2002 19:14:40 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GVP00EDFESFTO@firewall.wcom.com>; Mon, 06 May 2002 19:14:40 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GVP00J01ESBPQ@dgismtp01.wcomnet.com>; Mon, 06 May 2002 19:14:39 +0000 (GMT) Received: from rccc6131 ([166.35.224.50]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GVP00J4QERY0U@dgismtp01.wcomnet.com>; Mon, 06 May 2002 19:14:23 +0000 (GMT) Date: Mon, 06 May 2002 14:14:18 -0500 From: "Christopher A. Martin" Subject: RE: [NAT] NAT Tables... In-reply-to: <3CD6B730.CC274748@cisco.com> To: rrajiv@cisco.com, arumugamv@future.futsoft.com Cc: nat@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <003601c1f532$38f78500$32e023a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Comments inline.... -----Original Message----- From: nat-admin@ietf.org [mailto:nat-admin@ietf.org]On Behalf Of Rajiv Raghunarayan Sent: Monday, May 06, 2002 12:03 PM To: arumugamv@future.futsoft.com Cc: nat@ietf.org Subject: Re: [NAT] NAT Tables... Hi Arumugam, Here's my take on your question: One could separate NAT into two main classes - NAT and NAPT. The former works only on an address translation level while the latter addresses ports as well. ---------My comment------ Rajiv, could you calrify, I thought that NAT can work on both the network and/or transport layer (may use a port other than the originating hosts source port), whereas NAPT performs mapping totally at the transport layer, with exception of the single address(es) used for specific NAPT pools. I agree with your comment above except for my stated assumption, which I think should be addressed. Or is the standard for NAT to use the same transport layer address as the originating host (have not seen this, yet, in draft or RFC format) ----end comment----------- The Address Bind table maintains information about the address-only binds. Note that in this case there could be more than one session branched off this BIND (and the loss of a session does not necessarily indicate loss of a BIND) i.e. one entry in the address bind table could map to zero or more entries in the session table. The Address Port Bind table, on the other hand, maintains info regarding napt. Typically one bind in this case would translate to one session, but there could be cases (twice nat) where two binds would combine to form one session entry. Further, if you consider a static binds i.e. no timeouts, a bind would always exist, but there is no guarantee that there is a session necessarily associated with the bind at all times. Hope this answers your query. -Rajiv. Arumugam V wrote: > > Hi, > > I am Arumugam, new to this NAT area. I'm looking into the lattest draft > version of the NAT MIB. > > Can anyone help me to understand the BIND and SESSION tables of the NAT. > > 1. when the BIND Table entries would be created and how it's different from > Session table. > > Your help would be appreciated. > > Thanks and Regards, > Arumugam > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > _______________________________________________ > nat mailing list > nat@ietf.org > https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From owner-nat@portmasters.com Mon May 6 15:55:33 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04565 for ; Mon, 6 May 2002 15:55:33 -0400 (EDT) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g46IJdW13681 for nat-outgoing; Mon, 6 May 2002 13:19:39 -0500 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-nat@portmasters.com using -f From: BTang11111@aol.com Message-ID: <108.11583612.2a0836e1@aol.com> Date: Mon, 6 May 2002 15:43:29 EDT Subject: (NAT) New ISDN/Analog Modem Always-ON technology RAS implementations on PM4 To: nat@portmasters.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0.i for Windows 95 sub 161 Sender: owner-nat@portmasters.com Precedence: bulk Reply-To: BTang11111@aol.com Content-Transfer-Encoding: 7bit A major ISP in UK using PM4 with PRI has confirmed technical feasibility to switch an incoming DSO to a particular Modem unit , by assigning incoming DSO TDM Bus Slot corresponding to the Modem Unit (note this is already being regularly done at Console Initialisations , just need to dynamically accesss this TDM assignment functions after extracting the Caller-ID ). This is just one of several methods. The part about Exchange Switching Software reserving the same DSO is also one of several possible implementation. In fact, ISP could just as easily implement at their premise a "PBX front end" (just like a live human operator inserting incoming reconnecting calls to the correct TDM bus time slots/ Modem unit ..etc). Actually the main Identification here being Caller-ID, not necessarily needing reconnecting incoming calls landing on the same DS0 implemented on Exchange Switching Software. Yes, V.92 Modem-on-Hold requires Call Waiting & the direct physical end-to-end PSTN circuit is maintained all the time (just held in wait duiring telephone calls) , BUT not always strictly necessarily here. AND our patent predates v.92... Interesting initial comments... Kind Regards, > Bob > IWXChange, Inc > http://www.freesurfs.co.uk - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe nat' in the body of the message. List archive: From nat-admin@ietf.org Tue May 7 10:53:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10782 for ; Tue, 7 May 2002 10:53:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00876; Tue, 7 May 2002 10:47:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12150 for ; Tue, 7 May 2002 06:07:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01308 for ; Tue, 7 May 2002 06:06:56 -0400 (EDT) Received: from cbin2-mira-01.cisco.com (IDENT:mirapoint@cbin2-mira-01.cisco.com [64.104.144.38]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g47A6GpY028070; Tue, 7 May 2002 03:06:17 -0700 (PDT) Received: from cisco.com ([64.104.147.119]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AEF01359 (AUTH raraghun); Tue, 7 May 2002 15:33:20 +0530 (IST) Message-ID: <3CD7A719.85B74870@cisco.com> Date: Tue, 07 May 2002 15:36:17 +0530 From: Rajiv Raghunarayan Reply-To: rrajiv@cisco.com Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: christopher.a.martin@wcom.com CC: rrajiv@cisco.com, arumugamv@future.futsoft.com, nat@ietf.org Subject: Re: [NAT] NAT Tables... References: <003601c1f532$38f78500$32e023a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Christopher, Comments inline.. "Christopher A. Martin" wrote: > > Comments inline.... > > -----Original Message----- > From: nat-admin@ietf.org [mailto:nat-admin@ietf.org]On Behalf Of Rajiv > Raghunarayan > Sent: Monday, May 06, 2002 12:03 PM > To: arumugamv@future.futsoft.com > Cc: nat@ietf.org > Subject: Re: [NAT] NAT Tables... > > Hi Arumugam, > > Here's my take on your question: > > One could separate NAT into two main classes - NAT and NAPT. The > former works only on an address translation level while the latter > addresses ports as well. > > ---------My comment------ > Rajiv, could you calrify, I thought that NAT can work on both the network > and/or transport layer (may use a port other than the originating hosts > source port), whereas NAPT performs mapping totally at the transport layer, > with exception of the single address(es) used for specific NAPT pools. I > agree with your comment above except for my stated assumption, which I think > should be addressed. > > Or is the standard for NAT to use the same transport layer address as the > originating host (have not seen this, yet, in draft or RFC format) I guess I should've been more clear. What I meant to say was that there are two main types of NAT - one which pertains to address translation (basic NAT in its various forms) and the other including transport level translation as well. Yes, by definition NAT covers both covers both address as well as transport level translations (section 4.0, RFC 2663). Thanks for the correction. -Rajiv. > ----end comment----------- > > The Address Bind table maintains information about the address-only > binds. Note that in this case there could be more than one session > branched off this BIND (and the loss of a session does not > necessarily indicate loss of a BIND) i.e. one entry in the address > bind table could map to zero or more entries in the session table. > > The Address Port Bind table, on the other hand, maintains info > regarding napt. Typically one bind in this case would translate > to one session, but there could be cases (twice nat) where two > binds would combine to form one session entry. > > Further, if you consider a static binds i.e. no timeouts, a bind > would always exist, but there is no guarantee that there is a > session necessarily associated with the bind at all times. > > Hope this answers your query. > > -Rajiv. > > Arumugam V wrote: > > > > Hi, > > > > I am Arumugam, new to this NAT area. I'm looking into the lattest draft > > version of the NAT MIB. > > > > Can anyone help me to understand the BIND and SESSION tables of the NAT. > > > > 1. when the BIND Table entries would be created and how it's different > from > > Session table. > > > > Your help would be appreciated. > > > > Thanks and Regards, > > Arumugam > > > > > *************************************************************************** > > This message is proprietary to Future Software Limited (FSL) > > and is intended solely for the use of the individual to whom it > > is addressed. It may contain privileged or confidential information > > and should not be circulated or used for any purpose other than for > > what it is intended. > > > > If you have received this message in error, please notify the > > originator immediately. If you are not the intended recipient, > > you are notified that you are strictly prohibited from using, > > copying, altering, or disclosing the contents of this message. > > FSL accepts no responsibility for loss or damage arising from > > the use of the information transmitted by this email including > > damage from virus. > > > *************************************************************************** > > > > _______________________________________________ > > nat mailing list > > nat@ietf.org > > https://www1.ietf.org/mailman/listinfo/nat > > _______________________________________________ > nat mailing list > nat@ietf.org > https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From daemon@optimus.ietf.org Tue May 7 10:53:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10792 for ; Tue, 7 May 2002 10:53:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01400 for nat-archive@odin.ietf.org; Tue, 7 May 2002 10:53:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00876; Tue, 7 May 2002 10:47:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12150 for ; Tue, 7 May 2002 06:07:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01308 for ; Tue, 7 May 2002 06:06:56 -0400 (EDT) Received: from cbin2-mira-01.cisco.com (IDENT:mirapoint@cbin2-mira-01.cisco.com [64.104.144.38]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g47A6GpY028070; Tue, 7 May 2002 03:06:17 -0700 (PDT) Received: from cisco.com ([64.104.147.119]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AEF01359 (AUTH raraghun); Tue, 7 May 2002 15:33:20 +0530 (IST) Message-ID: <3CD7A719.85B74870@cisco.com> Date: Tue, 07 May 2002 15:36:17 +0530 From: Rajiv Raghunarayan Reply-To: rrajiv@cisco.com Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: christopher.a.martin@wcom.com CC: rrajiv@cisco.com, arumugamv@future.futsoft.com, nat@ietf.org Subject: Re: [NAT] NAT Tables... References: <003601c1f532$38f78500$32e023a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Content-Transfer-Encoding: 7bit Christopher, Comments inline.. "Christopher A. Martin" wrote: > > Comments inline.... > > -----Original Message----- > From: nat-admin@ietf.org [mailto:nat-admin@ietf.org]On Behalf Of Rajiv > Raghunarayan > Sent: Monday, May 06, 2002 12:03 PM > To: arumugamv@future.futsoft.com > Cc: nat@ietf.org > Subject: Re: [NAT] NAT Tables... > > Hi Arumugam, > > Here's my take on your question: > > One could separate NAT into two main classes - NAT and NAPT. The > former works only on an address translation level while the latter > addresses ports as well. > > ---------My comment------ > Rajiv, could you calrify, I thought that NAT can work on both the network > and/or transport layer (may use a port other than the originating hosts > source port), whereas NAPT performs mapping totally at the transport layer, > with exception of the single address(es) used for specific NAPT pools. I > agree with your comment above except for my stated assumption, which I think > should be addressed. > > Or is the standard for NAT to use the same transport layer address as the > originating host (have not seen this, yet, in draft or RFC format) I guess I should've been more clear. What I meant to say was that there are two main types of NAT - one which pertains to address translation (basic NAT in its various forms) and the other including transport level translation as well. Yes, by definition NAT covers both covers both address as well as transport level translations (section 4.0, RFC 2663). Thanks for the correction. -Rajiv. > ----end comment----------- > > The Address Bind table maintains information about the address-only > binds. Note that in this case there could be more than one session > branched off this BIND (and the loss of a session does not > necessarily indicate loss of a BIND) i.e. one entry in the address > bind table could map to zero or more entries in the session table. > > The Address Port Bind table, on the other hand, maintains info > regarding napt. Typically one bind in this case would translate > to one session, but there could be cases (twice nat) where two > binds would combine to form one session entry. > > Further, if you consider a static binds i.e. no timeouts, a bind > would always exist, but there is no guarantee that there is a > session necessarily associated with the bind at all times. > > Hope this answers your query. > > -Rajiv. > > Arumugam V wrote: > > > > Hi, > > > > I am Arumugam, new to this NAT area. I'm looking into the lattest draft > > version of the NAT MIB. > > > > Can anyone help me to understand the BIND and SESSION tables of the NAT. > > > > 1. when the BIND Table entries would be created and how it's different > from > > Session table. > > > > Your help would be appreciated. > > > > Thanks and Regards, > > Arumugam > > > > > *************************************************************************** > > This message is proprietary to Future Software Limited (FSL) > > and is intended solely for the use of the individual to whom it > > is addressed. It may contain privileged or confidential information > > and should not be circulated or used for any purpose other than for > > what it is intended. > > > > If you have received this message in error, please notify the > > originator immediately. If you are not the intended recipient, > > you are notified that you are strictly prohibited from using, > > copying, altering, or disclosing the contents of this message. > > FSL accepts no responsibility for loss or damage arising from > > the use of the information transmitted by this email including > > damage from virus. > > > *************************************************************************** > > > > _______________________________________________ > > nat mailing list > > nat@ietf.org > > https://www1.ietf.org/mailman/listinfo/nat > > _______________________________________________ > nat mailing list > nat@ietf.org > https://www1.ietf.org/mailman/listinfo/nat _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Tue May 14 19:38:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12248 for ; Tue, 14 May 2002 19:38:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01485; Tue, 14 May 2002 19:15:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01464 for ; Tue, 14 May 2002 19:15:13 -0400 (EDT) Received: from berkshire.research.att.com (H-135-207-53-60.research.att.com [135.207.53.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11365 for ; Tue, 14 May 2002 19:14:58 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 512A17B4B for ; Tue, 14 May 2002 14:41:09 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: nat@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 May 2002 14:41:08 -0400 Message-Id: <20020514184109.512A17B4B@berkshire.research.att.com> Subject: [NAT] detecting NATs Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Folks on this list may be interested in a draft paper of mine. (And I'd appreciate feedback.) http://www.research.att.com/~smb/papers/fnat.ps (or .pdf) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From daemon@ns.ietf.org Tue May 14 19:38:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12259 for ; Tue, 14 May 2002 19:38:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03046 for nat-archive@odin.ietf.org; Tue, 14 May 2002 19:38:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01485; Tue, 14 May 2002 19:15:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01464 for ; Tue, 14 May 2002 19:15:13 -0400 (EDT) Received: from berkshire.research.att.com (H-135-207-53-60.research.att.com [135.207.53.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11365 for ; Tue, 14 May 2002 19:14:58 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 512A17B4B for ; Tue, 14 May 2002 14:41:09 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: nat@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 May 2002 14:41:08 -0400 Message-Id: <20020514184109.512A17B4B@berkshire.research.att.com> Subject: [NAT] detecting NATs Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Network Address Translation X-BeenThere: nat@ietf.org Folks on this list may be interested in a draft paper of mine. (And I'd appreciate feedback.) http://www.research.att.com/~smb/papers/fnat.ps (or .pdf) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat