From owner-nat@livingston.com Thu Mar 2 18:51:13 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01795 for ; Thu, 2 Mar 2000 18:51:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id PAA15365; Thu, 2 Mar 2000 15:36:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA23665 for nat-outgoing; Thu, 2 Mar 2000 15:36:35 -0800 (PST) From: Melinda.Shore@nokia.com Message-ID: To: ietf@ietf.org, end2end-interest@isi.edu, nat@livingston.com Cc: tiphon@list.etsi.fr Subject: (NAT) foglamps BOF and mailing list Date: Thu, 2 Mar 2000 17:30:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Melinda.Shore@nokia.com It has been recognized for some time that breaking the end-to-end model through the introduction of elements like network address translators causes serious problems in IP networks, and the IETF has had ongoing discussions of those problems with an eye towards solving them. What is probably not fully appreciated, however, is the extent to which NAT and firewall-related problems are interfering with the deployment of major applications, such as the migration from circuit-based to packet-based telecommunications networks. Some of us are beginning to suspect that it may be time to bite the bullet and make certain network elements visible to applications by creating explicit external interfaces. To that end, we've requested a BOF session ("foglamps") for the upcoming meeting in Adelaide, and have created a foglamps mailing list on egroups.com (sorry). To subscribe, send email to foglamps-subscribe@egroups.com or use the web-based interface at http://www.egroups.com. Background reading would include: draft-lear-foglamps-01.txt draft-shore-h323-firewalls-00.txt draft-rosenberg-sip-firewalls-00.txt RFC 2775 draft-iab-ntwlyrws-over-02.txt I'll send along an agenda as soon as it's finalized. Melinda -- Melinda Shore Nokia IP Telephony 127 West State Street "Software longa, Ithaca, NY 14850 hardware brevis" +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) melinda.shore@nokia.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Sun Mar 5 18:44:27 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12291 for ; Sun, 5 Mar 2000 18:44:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id PAA22781; Sun, 5 Mar 2000 15:40:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA13957 for nat-outgoing; Sun, 5 Mar 2000 15:43:44 -0800 (PST) Date: Sun, 5 Mar 2000 17:34:12 -0600 From: Billy Biggs To: sip@lists.research.bell-labs.com Cc: nat@livingston.com Subject: (NAT) SIP NAT Draft and Linux Masquerading Module Message-ID: <20000305173412.A5870@mw.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Billy Biggs Hi, I have just submitted a draft describing an Application Level Gateway (ALG) for simple SIP sessions to allow them to pass transparently through a NAT device. A copy of the submitted draft is available here: http://www.sip-happens.com/masquerade/draft-biggs-sip-nat-00.txt We are also releasing the source code for a Linux IP Masquerading module for SIP. This allows a Linux NAT setup to transparently proxy SIP sessions, and is a sample implementation of the ALG described in the above draft. The source for this module and more information about what it supports is available at: http://www.sip-happens.com/masquerade/ We hope that by providing the draft and sample implementation that they can help promote the addition of simple SIP session support to other NAT and Firewall products. Thanks, -- Billy_Biggs@mw.3com.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Mar 6 04:43:17 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01347 for ; Mon, 6 Mar 2000 04:43:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id BAA29330; Mon, 6 Mar 2000 01:40:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id BAA26663 for nat-outgoing; Mon, 6 Mar 2000 01:45:06 -0800 (PST) Message-ID: <00e101bf874f$1e26f920$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: (NAT) SIP 2000 International Conference Date: Mon, 6 Mar 2000 10:33:45 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01BF8757.73594D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Peter Lewis" This is a multi-part message in MIME format. ------=_NextPart_000_00DE_01BF8757.73594D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unknown and even rejected by many vendors and operators only a few = months ago, SIP is on the brink of making a definitive name for itself.=20 Visit the SIP 2000 International Conference programme: http://www.upperside.fr/basip.htm ------=_NextPart_000_00DE_01BF8757.73594D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unknown and even rejected by many vendors and operators only a few = months=20 ago, SIP is on the brink of making a definitive name for itself.
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.= htm
 
------=_NextPart_000_00DE_01BF8757.73594D00-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Mar 9 15:26:17 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12480 for ; Thu, 9 Mar 2000 15:26:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA17464; Thu, 9 Mar 2000 12:21:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA08146 for nat-outgoing; Thu, 9 Mar 2000 12:22:03 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: "Iyer, Prakash" cc: nat@livingston.com Message-ID: <8625689D.006F0108.00@mwgate02.mw.3com.com> Date: Thu, 9 Mar 2000 14:12:55 -0600 Subject: Re: (NAT) RSIP: comments on latest draft versions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" Iyer and all, I apologize for not responding in detail to these comments. I will very soon. I'd also like to let everyone know that if there are any more comments on either the framework or protocol drafts, please send them over asap (like today). I'm shooting for a minor rev of each before tomorrow's cutoff. -Mike "Iyer, Prakash" on 02/29/2000 04:03:50 PM Please respond to "Iyer, Prakash" Sent by: "Iyer, Prakash" To: nat@livingston.com cc: (Mike Borella/MW/US/3Com) Subject: (NAT) RSIP: comments on latest draft versions > rsip-framework-03 draft: > * In the introduction section, text says > While NAT does not require a host to be aware of its presence, it requires > the presence of a proxy module, the application layer gateway (ALG), > within the NAT router for each application that embeds addressing > information, IP address or port content, within the packet payload (e.g., > FTP). RSIP (Realm Specific IP) provides an alternative to remedy these > limitations. > > What's needed is an example to show how proxies are completely eliminated > with RSIP. Applications that use the local IP address in application PDUs > may have to use the private realm IP address for communication in the > private realm and the public IP address for communication with a node in > the public realm. An example on how this can be done should be included in > the framework draft. Consider active mode FTP and H.323 apps (e.g. > NetMeeting) as examples on the client side. On the gateway side, an H.323 > proxy in a NAT environment is an example: if an H.323 application tries to > register with a Gatekeeper, the proxy translates the source IP address to > the external (WAN) IP address before forwarding the registration packet to > an external Gatekeeper. If the proxy is eliminated, how will this continue > to work? > > * Comment on the following text, > When using RSAP-IP, an RSIP server maintains a pool of IP addresses as > well as pools of port numbers per address. RSIP clients lease an IP > address and one or more ports to use with it. Once an address / port > tuple has been allocated to a particular client, only that client may use > the tuple until it is returned to the pool(s. > In the trivial case of a pool of 1 IP address, does this imply that only 1 > client can be supported in the private realm. That is clearly not the > case. The server can allocate the same IP address to multiple clients in > the private realm and allocate a different, non-overlapping range of ports > (or other de-MUXing parameters) to each client. > > * The draft recommends an MTU size of 512 bytes for UDP datagrams to avoid > fragmentation. How will this accommodate video applications that can > generate datagrams larger than 512 bytes. > > rsip-protocol-05 draft: > * OK and DEALLOCATE messages have been dropped but not mentioned in > revision history. And is this an issue if UDP ise used as transport for > the control channel. > > * Need a section discussing how RSIP works in an environment with N hosts > in private realm and M IP addresses, where N >= M and M > 1. > > * Can an RSIP client using RSAP-IP use its own (a different set of) ports > after it requests and is allocated ports by the RSIP server. It seems like > this should be possible for communication on the local LAN but to keep the > protocol simple, this may be explicitly disallowed. For communication with > external (public) hosts, the RSIP client MUST use ports from an RSIP > server allocated range. Section 7.1 should be clear on this issue. > > * An RSIP gateway should not allocate more than one 1 IP address to an > RSIP client simultaneously. > > * Text is inconsistent in specifying handling of "Don't Care" values. > For example, section 8.1 states > a "don't care" value for an address is signified by a setting the length > field to 1 and omitting the value field. > > But in section 9.8.3, > An RSIP client may indicate that it has no preference for local address or > ports, the RSIP client may place a "don't care" value of zeros in the > respective address or ports parameters > > * QUERY_REQUEST specifies a network tuple which has a network and a > netmask field. What's the format of the network field - an example will > help. > > * Handling of port requests should be documented clearly. For example, if > a client requests 4 ports from an RSIP server, the server MAY respond with > the same or a smaller number of ports. Some or all of the ports requested > the client may be included in a response from the RSIP server. > > Also need an example of a case where a client may specify a don't care > value for a port. > > rsip-ipsec-02 draft: > * The following text is confusing: > If the RSIP client wishes to use IPsec to protect a TCP or UDP > application, it MUST use the port range parameter (see Appendix A). > Otherwise, it MUST set the port parameters to the "don't need" value. > This is accomplished by setting the length field to 0, and by > omitting both the number field and the port field. > > Looks like the first instance of MUST should be a SHOULD (the Appendix > describes the consequence if a client does not require ports). > > The second part states that fields can be omitted to specify don't need > values but the semantics are not consistent with any text in the protocol > draft. > > * ASSIGN_REQUEST_RSIPSEC is missing the Overall Length parameter. > > * The draft does not recommend the use of port mapping in IPsec transport > mode. For example, is it OK to port map for transport mode IPsec but to > not modify ports for tunnel mode IPsec. > -Prakash Iyer Intel Arch Labs - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Mar 10 08:25:15 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09539 for ; Fri, 10 Mar 2000 08:25:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id FAA00486; Fri, 10 Mar 2000 05:20:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id FAA13696 for nat-outgoing; Fri, 10 Mar 2000 05:21:38 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: nat@livingston.com cc: prakash.iyer@intel.com Message-ID: <8625689E.00487C33.00@mwgate02.mw.3com.com> Date: Fri, 10 Mar 2000 07:12:10 -0600 Subject: Re: (NAT) RSIP: comments on latest draft versions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" Oops, this should have gone to the list... ---------------------- Forwarded by Mike Borella/MW/US/3Com on 03/10/2000 07:08 AM --------------------------- Mike Borella/MW/US/3Com 03/09/2000 04:36 PM Sent by: Mike Borella - AT&SE, Carrier R&D To: "Iyer, Prakash" cc: Subject: Re: (NAT) RSIP: comments on latest draft versions (Document link: Database 'Mike Borella', View '($Sent)') Prakash, Thanks for your comments. I've addressed them below. "Iyer, Prakash" on 02/29/2000 04:03:50 PM Please respond to "Iyer, Prakash" Sent by: "Iyer, Prakash" To: nat@livingston.com cc: (Mike Borella/MW/US/3Com) Subject: (NAT) RSIP: comments on latest draft versions > rsip-framework-03 draft: > * In the introduction section, text says > While NAT does not require a host to be aware of its presence, it requires > the presence of a proxy module, the application layer gateway (ALG), > within the NAT router for each application that embeds addressing > information, IP address or port content, within the packet payload (e.g., > FTP). RSIP (Realm Specific IP) provides an alternative to remedy these > limitations. > > What's needed is an example to show how proxies are completely eliminated > with RSIP. Applications that use the local IP address in application PDUs > may have to use the private realm IP address for communication in the > private realm and the public IP address for communication with a node in > the public realm. An example on how this can be done should be included in > the framework draft. Consider active mode FTP and H.323 apps (e.g. > NetMeeting) as examples on the client side. On the gateway side, an H.323 > proxy in a NAT environment is an example: if an H.323 application tries to > register with a Gatekeeper, the proxy translates the source IP address to > the external (WAN) IP address before forwarding the registration packet to > an external Gatekeeper. If the proxy is eliminated, how will this continue > to work? This is a much bigger problem than RSIP. In order for a SIP or 323 proxy/GK to operate with either NAT or RSIP, the proxy/GK may have to be able to dump state down to the NAT/RSIP gateway. Both boxes will probably have to live on the "edge" in the sense that they both have public and private IPs. Not at all clean. For your particular scenario, I don't understand what the problem is. The client uses a public IP. The GK doesn't necessarily know the difference. > * Comment on the following text, > When using RSAP-IP, an RSIP server maintains a pool of IP addresses as > well as pools of port numbers per address. RSIP clients lease an IP > address and one or more ports to use with it. Once an address / port > tuple has been allocated to a particular client, only that client may use > the tuple until it is returned to the pool(s. > In the trivial case of a pool of 1 IP address, does this imply that only 1 > client can be supported in the private realm. That is clearly not the > case. The server can allocate the same IP address to multiple clients in > the private realm and allocate a different, non-overlapping range of ports > (or other de-MUXing parameters) to each client. We're not talking about addresses, we're talking about address/port pairs. Read the paragraph again with that in mind and it should be clear that we never imply that a single IP can't be shared. > * The draft recommends an MTU size of 512 bytes for UDP datagrams to avoid > fragmentation. How will this accommodate video applications that can > generate datagrams larger than 512 bytes. Good point. I'll have to think about this one further. > rsip-protocol-05 draft: > * OK and DEALLOCATE messages have been dropped but not mentioned in > revision history. And is this an issue if UDP ise used as transport for > the control channel. How so? DEALLOCATE is definitely not necessary. I don't think OK is either. > * Need a section discussing how RSIP works in an environment with N hosts > in private realm and M IP addresses, where N >= M and M > 1. The whole draft is about this situation. What in particular needs to be explained? > * Can an RSIP client using RSAP-IP use its own (a different set of) ports > after it requests and is allocated ports by the RSIP server. It seems like > this should be possible for communication on the local LAN but to keep the > protocol simple, this may be explicitly disallowed. For communication with > external (public) hosts, the RSIP client MUST use ports from an RSIP > server allocated range. Section 7.1 should be clear on this issue. If you mean that an RSIP client that is allocated port X to use with public address A also wants to use port X with local address B, then yes, that's perfectly fine. "RSIP ports" are different from tcp or udp ports. > * An RSIP gateway should not allocate more than one 1 IP address to an > RSIP client simultaneously. Why? I belive that this is a useful feature for policy routing support, and I can't imagine what any drawbacks might be. > * Text is inconsistent in specifying handling of "Don't Care" values. > For example, section 8.1 states > a "don't care" value for an address is signified by a setting the length > field to 1 and omitting the value field. > > But in section 9.8.3, > An RSIP client may indicate that it has no preference for local address or > ports, the RSIP client may place a "don't care" value of zeros in the > respective address or ports parameters Yes, this is cruft left over from the change in how don't care is represented. Thanks for pointing it out. Will fix. > * QUERY_REQUEST specifies a network tuple which has a network and a > netmask field. What's the format of the network field - an example will > help. An IP address parameter. I think this is clear in sec. 9.14.2, but let me know if it isn't and feel free to suggest an improvement. > * Handling of port requests should be documented clearly. For example, if > a client requests 4 ports from an RSIP server, the server MAY respond with > the same or a smaller number of ports. Some or all of the ports requested > the client may be included in a response from the RSIP server. My intention has been that if a client request cannot be granted as is, then an error should be returned, telling the client what was wrong, and then the client will determine what to do next. For example, if a client asks for 3 ports but the server only grants 2, this is ok if the client only needs 1 or 2. But if the client actually needs all 3 ports, then it will not be able to do whatever it was trying to do. Of course it may then request another port in a separate binding, but this can be problematic if the server revokes one binding and not the other. One point of bindings is to logically group the resources that a client needs for certain tasks. In any case, I'll add some words to address this and we can debate in Adelaide. > Also need an example of a case where a client may specify a don't care > value for a port. This is the usual case - a client application using an ephemeral port. > rsip-ipsec-02 draft: > * The following text is confusing: > If the RSIP client wishes to use IPsec to protect a TCP or UDP > application, it MUST use the port range parameter (see Appendix A). > Otherwise, it MUST set the port parameters to the "don't need" value. > This is accomplished by setting the length field to 0, and by > omitting both the number field and the port field. > > Looks like the first instance of MUST should be a SHOULD (the Appendix > describes the consequence if a client does not require ports). The paragraph above specifically says "to protect a TCP or UDP application". In that case, ports MUST be allocated. > The second part states that fields can be omitted to specify don't need > values but the semantics are not consistent with any text in the protocol > draft. That's because there is no analogous case in the protocol draft. > * ASSIGN_REQUEST_RSIPSEC is missing the Overall Length parameter. Thanks. We'll fix this. > * The draft does not recommend the use of port mapping in IPsec transport > mode. For example, is it OK to port map for transport mode IPsec but to > not modify ports for tunnel mode IPsec. Port mapping is not necessary at all with IPSEC. That's what we're using the SPIs for. -Mike - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Mar 17 22:28:03 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24076 for ; Fri, 17 Mar 2000 22:28:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id TAA03685; Fri, 17 Mar 2000 19:24:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id TAA18360 for nat-outgoing; Fri, 17 Mar 2000 19:21:24 -0800 (PST) Message-ID: <20000318032020.21136.qmail@web1406.mail.yahoo.com> Date: Fri, 17 Mar 2000 19:20:20 -0800 (PST) From: Pyda Srisuresh Subject: (NAT) Fwd: Re: NAT Agenda To: nat@livingston.com Cc: agenda@ietf.org, holdrege@lucent.com, srisuresh@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Folks, Sorry for the late posting. NAT WG is currently scheduled to meet on tuesday afternoon for 1 hour (17:00-18:00). Below is the agenda. Please read the drafts prior to attending the meeting. We have not had much discussion on the base NAT drafts listed below. I encourage you to actively raise any issues you may have with the drafts on the mailing list. Thanks. 1. Base-Nat drafts * draft-iab-nat-implications-05.txt from Tony 10 mins. * draft-ietf-nat-protocol-complications-02.txt 5 mins. from Matt 2. RSIP drafts - 30 mins. * draft-ietf-nat-rsip-slp-00.txt * draft-ietf-nat-rsip-ipsec-02.txt * draft-ietf-nat-rsip-protocol-05.txt * draft-ietf-nat-rsip-framework-03.txt 3. Miscellaneous - 15 mins. cheers, suresh & Matt __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Sat Mar 18 21:22:29 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25914 for ; Sat, 18 Mar 2000 21:22:29 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id SAA11925; Sat, 18 Mar 2000 18:18:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA12459 for nat-outgoing; Sat, 18 Mar 2000 18:18:09 -0800 (PST) Message-ID: <20000319021706.25457.qmail@web1406.mail.yahoo.com> Date: Sat, 18 Mar 2000 18:17:06 -0800 (PST) From: Pyda Srisuresh Subject: Fwd: (NAT) Fwd: Re: NAT Agenda To: nat@livingston.com Cc: agenda@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Oops... I listed older rev RSIP drafts in the agenda I sent yesterday. Here is the revised agenda with the right rev nos. Thanks. NAT WG Meeting time: tuesday afternoon 17:00-18:00 Agenda: 1. Base-Nat drafts * draft-iab-nat-implications-05.txt from Tony 10 mins. * draft-ietf-nat-protocol-complications-02.txt 5 mins. from Matt 2. RSIP drafts - 30 mins. * draft-ietf-nat-rsip-slp-00.txt * draft-ietf-nat-rsip-ipsec-03.txt * draft-ietf-nat-rsip-protocol-06.txt * draft-ietf-nat-rsip-framework-04.txt 3. Miscellaneous - 15 mins. cheers, suresh ===== __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Sun Mar 19 12:41:40 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22648 for ; Sun, 19 Mar 2000 12:41:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id JAA16388; Sun, 19 Mar 2000 09:37:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA27032 for nat-outgoing; Sun, 19 Mar 2000 09:35:17 -0800 (PST) Message-ID: <4148FEAAD879D311AC5700A0C969E8901CC1AE@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: "'Pyda Srisuresh'" , nat@livingston.com Cc: holdrege@lucent.com Subject: RE: (NAT) Fwd: Re: NAT Agenda Date: Sun, 19 Mar 2000 09:33:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Iyer, Prakash" Mike Borella was supposed to have submitted protocol-06 and updated the ipsec draft to -03 based on some comments. Should we be reviewing those docs. -Prakash -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] Sent: Friday, March 17, 2000 7:20 PM To: nat@livingston.com Cc: agenda@ietf.org; holdrege@lucent.com; srisuresh@yahoo.com Subject: (NAT) Fwd: Re: NAT Agenda Folks, Sorry for the late posting. NAT WG is currently scheduled to meet on tuesday afternoon for 1 hour (17:00-18:00). Below is the agenda. Please read the drafts prior to attending the meeting. We have not had much discussion on the base NAT drafts listed below. I encourage you to actively raise any issues you may have with the drafts on the mailing list. Thanks. 1. Base-Nat drafts * draft-iab-nat-implications-05.txt from Tony 10 mins. * draft-ietf-nat-protocol-complications-02.txt 5 mins. from Matt 2. RSIP drafts - 30 mins. * draft-ietf-nat-rsip-slp-00.txt * draft-ietf-nat-rsip-ipsec-02.txt * draft-ietf-nat-rsip-protocol-05.txt * draft-ietf-nat-rsip-framework-03.txt 3. Miscellaneous - 15 mins. cheers, suresh & Matt __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Mar 27 05:40:06 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24864 for ; Mon, 27 Mar 2000 05:40:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id CAA19379; Mon, 27 Mar 2000 02:35:11 -0800 (PST) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id CAA07332 for nat-outgoing; Mon, 27 Mar 2000 02:32:47 -0800 (PST) Message-ID: <00a501bf97d7$6877aea0$2cf2cdc1@coritel.it> From: "Raffaele Pellicciotta" To: Subject: (NAT) NAT & Tunnel Date: Mon, 27 Mar 2000 12:29:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Raffaele Pellicciotta" Content-Transfer-Encoding: 7bit Hi, I desire to know how can I use NAT and tunnel together (PPTP). In my Test bed I have a linux machine with RedHat 6.1 and kernel 2.2.12. In my private LAN some machines ( privarte addresses) go towards Internet ( public IP addresses) through a single border machine which works like a Nat router or with a Tunnel server!!! It works well but only on a single way: It has to work or like a Nat router or like a tunnel server but if these mechanisms works together we have no a good working. Can I realize an coexistence NAT-TUNNEL SERVER on the same border machine? Thanks a lot, Raffaele Pellicciotta - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Mar 28 19:14:12 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00192 for ; Tue, 28 Mar 2000 19:14:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id QAA00663; Tue, 28 Mar 2000 16:09:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id QAA09834 for nat-outgoing; Tue, 28 Mar 2000 16:06:49 -0800 (PST) Message-ID: <20000329000540.25471.qmail@web1405.mail.yahoo.com> Date: Tue, 28 Mar 2000 16:05:40 -0800 (PST) From: Pyda Srisuresh Subject: (NAT) To: gab@sun.com, mike_borella@3com.com Cc: nat@livingston.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Gabriel and Mike, Couple of comments. 1. Appendix B: I believe, you will need another set of 3 error message for IKE as well here. 2. Appendix G: I believe, fundamentally, the premise that incoming IKE connections can be supported (in the case of RSAP-IP)with the aid of ephemeral IKE ports is not correct. Secondly, your suggestion that an RSAP-IP client may register with RSAP_IP gateway to redirect incoming IKE sessions from one or more external IKE nodes to it (i.e., RSAP-IP client) sounds interesting. But, does such a provision exist on platforms like UNIX (that supports multiple users) to allow a user specific IKE application to register for incoming IKE? cheers, suresh __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.