Subject: [MOBILE-IP] New GRE Draft Extensions

From: Gopal Dommety <[email-masked]>
Date: Thu, 9 Mar 2000 12:31:14 -0800

Hello:

I am  attaching the  GRE addendum/extensions.  As  you go  through the
 draft at places identified by # there are request for comments. I have
split the sequence no into two subfeilds (the other option is to define an
acknowledgement like PPTP WHEN such a need it felt).

Please send  your comments to  [email-masked] mailing list.  you can
subscribe   to   this   mailing   list   by  sending   an   email   to
[email-masked]

Thanks
Gopal

Network Working Group                                      Gopal Dommety
INTERNET DRAFT                                             cisco Systems
March 2000

Expires October 2000

                Key and Sequence Number Extensions to GRE
                    draft-dommety-gre-ext-00.txt

Status of this Memo

   This document is a submission by the Network Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the [email-masked] mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This  document describes extensions  by which  two fields,  Key and
Sequence Number, can be optionally carried in the GRE (Generic Routing
Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
of an arbitrary network  layer protocol over another arbitrary network
layer  protocol.

Dommety                                                           [Page 1]

Internet Draft  Key and Sequence Number Extensions to GRE  February 2000

1. Introduction

   Current specification of Generic Routing Encapsulation [1] specifies
a protocol  for encapsulation of  an arbitrary network  layer protocol
over another arbitrary network layer protocol. This document describes
enhancements  by which  two fields,  Key and  Sequence Number,  can be
optionally carried  in the GRE  Header [1]. The  Key field is  used to
create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
is used to maintain sequence of packets within a GRE Tunnel.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the
   requirements of the specification.

   Silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.

2. Extensions to GRE Header

   The GRE packet header[1] has the following format:

    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)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The proposed GRE header will have the following format:

    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| |K|S| Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Key (optional)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Key Present (bit 2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.  Otherwise, the Key field is
      not present in the GRE header.

      Sequence Number Present (bit 3)

      If the Sequence Number Present bit is set to 1, then it indicates
      that the Sequence Number field is present.  Otherwise, the
      Sequence Number field is not present in the GRE header.

      The  Key and Sequence Present bits are chosen to be  compatible
      with RFC 1701 [2].

2.1. Key Field (4 octets)

     The Key field contains a  four octet number which was inserted by
     the encapsulator. The actual method by which this Key is obtained
     is beyond the scope of this document.  Key field is intended to be
     used for  creating separate sub-tunnels within a  GRE Tunnel and the
     Key field identifies the sub-tunnel.

2.2. Sequence Number (4 octets)

    The Sequence Number  field is divided into two  sub-fields (Tx and
    Rx sequence number). These subfields are inserted by the encapsulator
    when Sequence Number Present Bit is set . Tx Sequence Number  MUST
    be used by the receiver to establish the  order in which  packets
    have been  transmitted from the  encapsulator  to  the  receiver.
    The intended  use  of  the Tx Sequence  Field is  to provide
    unreliable and in-order delivery.   If the Key  present bit (bit 2)
    is set, the sequence number is specific to the sub-tunnel identified
    by the Key field.

    The Tx sequence number  value ranges from 1 to  65535. The first
    datagram is sent with a Tx sequence number of 1. The Tx sequence
    number is thus a free running counter represented modulo 65536,
    with the exception that 1 is used when modulo 65536 results in 0
    (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.

#Q The Rx can be the Tx  sequence number of the last successfully decap
  pack.  And  say  that  how  you  use  this  info  is  implementation
  dependent.  I am currently saying Rx sequence no
  is set to 0. Comments?

    When the decapsulator receives an out-of sequence packet it SHOULD
    be silently discarded. Additionally, reordering of out-of sequence
    packets  MAY  be  performed   by  the  decapsulator  for  improved
    performance and  tolerance to reordering in the  network (since the
    state of the stateful compression or encryption is reset by packet
    loss, it  might help the  performance to tolerate some  amount of
    packet reordering in the network by buffering). Exact buffering
    schemes are outside the scope
    of  this  document. Note that the  Tx sequence number is used to detect
    lost packets and/or restore  the original sequence of packets that
    may have been reordered during transport.

   A packet  is considered an out-of-sequence packet  if the Tx sequence
   number  of  the  received packet  is  lesser than or equal to  the Tx
   sequence  number   of last  successfully  decapsulated
   packet. The  Tx sequence number  of a received message is considered
   less than or equal to the last successfully received Tx sequence number
   if its value lies in the range of the last received Tx sequence number
   and the preceding 32766 values, inclusive.  For example, if the last
   successfully received Tx sequence number was 15, then messages with Tx
   sequence numbers 1 through 15, as well as 32784 through 65535, would be
   considered less than or equal. Such a message would be considered an
   out-of-sequence packet and  ignored from processing.

    If the received packet is an in-sequence packet, it is successfully
    de capsulated. Note that  the TX sequence number is  used to detect
    lost packets and/or restore the original sequence of packets (with
    buffering) that may have been reordered during transport.

#C I have considered trying to  have a different starting point for TX
sequence nos  during rollover and initial starting  point.  This would
let a node  identify if the other end  reset (like agent advertisement
sequence no to identify reboot and normal rollover). This is useful if
we keep  turning on  and off  sequence nos option  in a  tunnel. Since
there  is no  security it  is easy  for others  to reset  the sequence
also. Comments?

3. IANA Considerations

4. Acknowledgments

5. References

   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
   "Generic           Routing           Encapsulation          (GRE),"
   draft-meyer-gre-update-03.txt, January 2000.

   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
   October 1994.

   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.

Dommety                                                 [Page 4]

Internet Draft   Key and Sequence Number extensions to GRE   February 2000

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [email-masked]

Dommety

Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
[email-masked]
Cisco Systems, San Jose, CA, 95051

---

From: Gopal Dommety <[email-masked]>
Date: Thu, 9 Mar 2000 12:58:46 -0800

>subscribe   to   this   mailing   list   by  sending   an   email   to

Sorry, you need to send the email to [email-masked]

-Gopal

Thank You.
Regards,
Gopal

Gopal Dommety
408 525 1404
[email-masked]

---

From: Ajoy Singh <[email-masked]>
Date: Fri, 10 Mar 2000 11:25:06 -0600

Hello Gopal,

Here is couple of questions i have regarding the attached GRE draft.  I have not participated in previous
discussion of GRE, so i am
not aware of any decision made by IESG regarding this respect.

1. What is the Value of Version number field of  proposed GRE header ?  Is it 0 or something else ?  Does it mean
that all existing GRE implementations need to change to support this header format to be standard compliant?  I
was hoping that we can use different version number to support the new extensions and that way we do not require
to change existing deployment of GRE. This way any network element can discard right away the GRE packets which
it does not support ?
2. In GRE header format you have  specified RX Sequence number which seems to me same as ack sequence number of
PPTP GRE. Why we need similar thing represented in two different way in two different standards ?

thanks,
ajoy

>    The GRE packet header[1] has the following format:

The only possible way this sequence number can be used to support some type of sliding window protocol either for

flow control or retransmission. I belive this does

---

From: "Frederick N. Chase" <[email-masked]>
Date: Fri, 10 Mar 2000 13:54:58 -0500

Re:  Key and Sequence Number Extensions to GRE

The proposed use of two previously-reserved header bits
in  draft-dommety-gre-ext-00.txt
differ in a fundamental way.

The proposed use of a reserved bit as a
"Sequence Number Present" bit is a
potentially-beneficial modifier
on encapsulator/decapsulator behavior and therefore
seems to me to be advisable or at least not inadvisable.

The proposed use of a reserved bit as a
"Key Present" bit does not affect (narrowly construed)
encapsulator/decapsulator behavior but rather
concerns the processor of the encapsulated or decapsulated
data.  This proposal seems to me to be inadvisable.

Acceptance of the "Key Present" proposal unnecessarily
encumbers some other
processor of encapsulated or decapsulated data
which might like to have an optional extra 32 bits for some purpose
where the terms "Key and "sub-tunnel" would be
confusing and inappropriate.

   -Fred Chase

---

From: Rene Tio <[email-masked]>
Date: Fri, 10 Mar 2000 11:08:26 -0800

On Fri, Mar 10, 2000 at 11:25:06AM -0600, Ajoy Singh wrote:
> Hello Gopal,
>
> Here is couple of questions i have regarding the attached GRE draft.  I
> have not participated in previous discussion of GRE, so i am not aware of
> any decision made by IESG regarding this respect.

I do not know if the IESG figures into this since GRE is informational.
However I would like to know the reason behind the updates because
draft-meyer + draft-dommety looks pretty close to RFC 1701.  The changes
appear to be the semantics of the key field, which was somewhat semantic
free before since its use as an authenticator was always suspect, and the
split sequence number field.  What's the use of deprecating some fields in
one draft and extending it with the same deprecated fields in another draft?

> 1. What is the Value of Version number field of proposed GRE header ?  Is
> it 0 or something else ?  Does it mean that all existing GRE
> implementations need to change to support this header format to be
> standard compliant?

There is no change between draft-meyer-gre-update-03.txt and RFC 1701.  The
version field remains 0.

> I was hoping that we can use different version number to support the new
> extensions and that way we do not require to change existing deployment of
> GRE. This way any network element can discard right away the GRE packets
> which it does not support ?

Your point is well-taken.  Since the sequence number field is now split, RFC
1701 GRE will not understand draft-dommety GRE.  A new version number may be
required.  This is in contrast to draft-meyer, which is interoperable with
RFC 1701.

> 2. In GRE header format you have specified RX Sequence number which seems
> to me same as ack sequence number of PPTP GRE. Why we need similar thing
> represented in two different way in two different standards ?

Neither of them are "standards".  And not everyone uses GRE for PPTP.

R.

---

From: Rene Tio <[email-masked]>
Date: Fri, 10 Mar 2000 11:08:26 -0800

Resending this to cover the GRE mailing list and to prevent others from
replying to the majordomo.

------------------------------------------------------------------------

R.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Mar 2000 17:04:39 -0500

Folks,

I'm redirecting followups to the gre list. To join:

    [email-masked]
    subscribe gre

Note: there are folks interested in gre outside of mobile-ip. The UDLR
WG has also expressed an interest in this area.

> I do not know if the IESG figures into this since GRE is
> informational. However I would like to know the reason behind the
> updates because draft-meyer + draft-dommety looks pretty close to
> RFC 1701.  The changes appear to be the semantics of the key field,
> which was somewhat semantic free before since its use as an
> authenticator was always suspect, and the split sequence number
> field.  What's the use of deprecating some fields in one draft and
> extending it with the same deprecated fields in another draft?

RFC 1701 is informational. It cannot be referenced by standards track
documents in a normative way.

draft-meyer-gre-update-03.txt has been approved as a Proposed Standard
by the IESG an will be out as an RFC any day now. This document is
backwards compatable with 1701 in the sense that existing
implementations of 1701 are already compliant with the new
standard. However, draft-meyer-gre-update does not include some of the
more exotic extensions that 1701 has. Thus, the new GRE document isn't
for everyone, as it doesn't include the key and sequence
fields. meyer-gre-update is just the basics, no fluff.

The purpose of draft-dommety is to define some new options to GRE that
may in fact look suprisingly like some of the fields in 1701 that
don't appear in draft-meyer-gre-update. One problem with 1701's
definition of those fields is that they are underspecified (you can't
implement them from 1701) and its not even clear whether everyone
would agree on what semantics those fields should have. draft-dommety
is intended to find consensus on what those other fields should be (at
least from the perspectives of mobile IP).

Questions like should GRE extensions use a new version number, etc.,
need to hashed out on the gre list.

Thomas

---

From: Gopal Dommety <[email-masked]>
Date: Sun, 12 Mar 2000 23:36:52 -0800

>1. What is the Value of Version number field of  proposed GRE header ?  Is it 0 or something else ?  Does it mean

The Version is 0.

>to change existing deployment of GRE. This way any network element can discard right away the GRE packets which

This is an addendum to the draft-meyers. Using a different version number will definetly make it easy. If the version number is
to be changed then we have to change it in  draft-meyers.

We should definetly not need to change all existing GRE implementations.

>PPTP GRE. Why we need similar thing represented in two different way in two different standards ?

We can  use the all the four octects for the Transmit sequence as in PPTP and if it is determined that we need an acknowledgement
feild, we can think about the acknowledgement extension. I will make that change.

BTW: PPTP uses the value of 1 for Version number.

Thank You.
Regards,
Gopal

Gopal Dommety
408 525 1404
[email-masked]

---

From: Gopal Dommety <[email-masked]>
Date: Sun, 12 Mar 2000 23:55:23 -0800

>confusing and inappropriate.

Fred,

        I am not sure of the concern. Would appreciate if you could explain.
Is your concern that we have to maintain a  Sequence number per Key when both are present? Or that
earlier (in RFC1701) it was supposed to be  used by the receiver to authenticate
      the source of the packet?

Thanks
Gopal

Thank You.
Regards,
Gopal

Gopal Dommety
408 525 1404
[email-masked]

---

From: David Meyer <[email-masked]>
Date: Mon, 13 Mar 2000 06:43:06 -0800

> to be changed then we have to change it in  draft-meyers.

        We've been through this and decided not to change the
        version number.

> We should definetly not need to change all existing GRE implementations.

        right, should be backwardly compatable.

        Dave

---

From: Gopal Dommety <[email-masked]>
Date: Mon, 13 Mar 2000 09:50:03 -0800

Dave,

>       We've been through this and decided not to change the

I am not suggesting we change the version number. I was clarifying that we cannot change the version no in draft-dommety. If at all it is done
it has to be done in draft-meyers.

Thanks
Gopal

Thank You.
Regards,
Gopal

Gopal Dommety
408 525 1404
[email-masked]

---

From: David Meyer <[email-masked]>
Date: Mon, 13 Mar 2000 09:39:01 -0800

> it has to be done in draft-meyers.

        Sure. But we don't plan to do that.

        Dave

---

From: Rene Tio <[email-masked]>
Date: Mon, 13 Mar 2000 13:44:55 -0800

On Mon, Mar 13, 2000 at 09:50:03AM -0800, Gopal Dommety wrote:
> >> This is an addendum to the draft-meyers. Using a different version
> >> number will definetly make it easy. If the version number is
> I am not suggesting we change the version number. I was clarifying that we
> cannot change the version no in draft-dommety. If at all it is done

I don't see why this has to be so.  draft-meyer is pretty much completely
backward compatible to 1701, whereas draft-dommety isn't.  Thus draft-meyer
doesn't require a version number bump but draft-dommety in its original form
did.

However, if the Sequence Number field were changed to 32 bits, as Gopal
recently suggested, and the only change was to better define the behaviour
of the Sequence Number field, then the need for bumping GRE versions I feel
would be unnecessary.

If, however, you are going to add an Ack sequence number, *and* use the Key
field as some form of tunnel demux, then it's beginning to look a whole lot
like PPTP and I'd probably suggest splitting out the PPTP GRE portions into
a separate draft and making draft-dommety look like it (and bump the version
numbers, eck).

This discussion is sounding very circular at the moment.

Cheers,
Rene

---

From: David Meyer <[email-masked]>
Date: Mon, 13 Mar 2000 14:32:54 -0800

> of the Sequence Number field, then the need for bumping GRE versions I feel

        This is my feeling as well.
> a separate draft and making draft-dommety look like it (and bump the version

        Ditto.

        Dave