Subject: RE: (NAT) doubt in checksum calculation algo of NAT.

From: "Egevang, Kjeld" <[email-masked]>
Date: Tue, 21 Dec 1999 01:25:28 -0800

Hi.

It will work fine if you set optr and nptr to point at the previous
byte and increment olen and nlen.

Note that it is not advisable to just redo the checksum calculation
unless you check the checksum first and discard packets with bad checksums.

/Kjeld

> -----Original Message-----
> From: Ramasamy [mailto:[email-masked]]
> Sent: 16. december 1999 06:23
> To: [email-masked]'
> Subject: (NAT) doubt in checksum calculation algo of NAT.
> 
> 
> 
> Hi
> 	I have a doubt in checksum caluclation module of NAT.
> Actually, the  checksum calculation algo. given in 
> draft-ietf-nat-traditional-01.txt will work only if the optr( 
> pointer to the old data ) is at an even offset from the start 
> of the header.
> suppose if optr starts from the odd offset, can we change 
> optr to optr-1, so that it will point to the byte which is 
> immediately before the actual start of the old data and now 
> the optr points to an even offset from the start of the 
> header. after this modification ,can we apply the same algo. 
> will there be any problem?
> 
> or do we have to compute the checksum byte by byte in the 
> usual way, if the  conditions given in the draft are not satisfied?.
> 
> please clarify my doubts.
> 
> bye
> rams.
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat' in the body of the message.
> 

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 29 Dec 1999 15:30:11 -0800

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

-