Subject: (NAT) RE: IETF NAT Digest V2 #170

From: Oliveira Paul-LPO117 <[email-masked]>
Date: Thu, 30 Dec 1999 08:44:49 -0500

Bernard

Good work!  This should solve our pptp problems and other similar problems
as they arise. Thanks for your response and thanks for addressing all of my
issues.  My only comment with regards to what you have spelled out here is
that the RSIP Server needs an error code to return to the client if it gets
an ALLOCATE_PROTOCOL primitive but does not know (no code for) the protocol
that the client has asked for.

Paul

> -----Original Message-----
> From: [email-masked]@livingston.com
> [mailto:[email-masked]@livingston.com]
> Sent: Wednesday, December 29, 1999 11:00 PM
> To: [email-masked]
> Subject: IETF NAT Digest V2 #170
> 
> 
> 
> IETF NAT Digest      Wednesday, December 29 1999      Volume 
> 02 : Number 170
> 
> 
> 
> (NAT) Some thoughts on PPTP and RSIP
> 
> ----------------------------------------------------------------------
> 
> Date: Wed, 29 Dec 1999 15:30:11 -0800
> From: "Bernard Aboba" <[email-masked]>
> Subject: (NAT) Some thoughts on PPTP and RSIP
> 
> Back a while ago, there was a question on how PPTP
> might be supported in RSIP. 
> 
> As noted in RFC 2637, PPTP uses a well known port
> of TCP 1723 for the control channel and a 
> (modified) RFC 1701 GRE header for encapsulated data.
> 
> The TCP 1723 control channel should just work with
> RSIP as currently specified. 
> 
> Within the GRE v1 header (protocol 47), two octets of
> the RFC 1701 Key field is used to encode the Call ID,
> which (along with the source IP address) can be used to
> de-multiplex incoming data packets. For those interested
> in the details, some packet formats are included at
> the end of this message. RFC 2637 (PPTP) has further
> details. 
> 
> To support this, the RSIP gateway would need to make
> sure that no two clients speaking to the same destination
> would be using the same call ID. This could be accomplished
> by having the client suggest a call ID which the RSIP
> gateway could check for conflicts, suggesting an
> alternative if necessary. 
> 
> The question arose as to whether support for PPTP
> might be added in such a way that it might apply to
> other protocols as well. 
> 
> I think that this is possible. This case closely
> resembles allocation of UDP and TCP ports in that
> it involves allocation of a two octet field for a
> IP protocol number. 
> 
> This might be accomplished by including an RSIP primitive
> ALLOCATE_PROTOCOL that would supply the 
> DEST_IPADDR and PROTOCOL_ID as well as the
> OFFSET & LENGTH for the field to be allocated,
> and as usual, a SUGGESTION for the value. 
> 
> For the case of PPTP, the PROTOCOL_ID would be
> set to 47, the OFFSET to HEX 18 (see protocol
> diagram below) and the LENGTH to 2. 
> 
> Such a primitive, if supplied, would apply to
> any protocol that can be specified by an
> IP protocol number and has a single field that 
> needs to be multi-plexed. The primitive would
> therefore apply to UDP and TCP as well as
> modified GRE. 
> 
> The question arose as to whether PPTP support
> in RSIP could be leveraged to apply to GRE
> proper, as defined in RFC 1701 (and now being
> updated). 
> 
> As far as I can determine, I think the answer
> is no because GRE proper does not have the 
> equivalent of a "port" field. Thus, only one
> client can be talking to GRE v0 destination
> at a time. 
> 
> MODIFIED GRE HEADER
> rfc2637.txt
> 
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |    Key (HW) Payload Length    |       Key (LW) Call ID        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                  Sequence Number (Optional)                   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |               Acknowledgment Number (Optional)                |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Where:
>    C = checksum present. Set to zero (0).
>    R = routing present. Set to zero (0).
>    K = Key Present. Set to one (1).
>    S = Sequence no. present. Set to 1 for payload, 0 for ACK. 
>    s = strict source route present. Set to zero (0).
>    Recur = recursion control. Set to zero (0).
>    A = Acknowledgement seq. no. present. Set to 1 if packet
>        contains acknowledgement no. 
>    Flags. Must be set to zero (0).
>    Ver = Must contain 1 (enhanced GRE). 
>    Protocol Type = Set to hex 880B. 
>    Key
>       Payload length: size of payload, not including GRE header.
>       Call ID: Peer's Call ID for the session to which this 
> packet belongs.
>       Sequence Number: sequence number of the payload. 
> Present if S = 1.  
>       Acknowledgment Number = Present if A =1. 
>             
> 
> GRE Header Format 
> http://www.ietf.org/internet-drafts/draft-meyer-gre-update-01.txt
> 
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |C|       Reserved0       | Ver |         Protocol Type         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |      Checksum (optional)      |       Reserved1 (Optional)    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Here:
> C = 1 if Checksum is present, 0 otherwise
> Ver = 0
> 
> - -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat' in the body of the message.
> 
> ------------------------------
> 
> End of IETF NAT Digest V2 #170
> ******************************
> 
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat-digest' in the body of the message.
> 
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.