Subject: RE: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunne l?

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 4 Sep 2001 14:29:51 -0500

Looks good to me. 
regards,
ajoy 

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 2:20 PM
To: [email-masked]
Subject: RE: [mobile-ip] Low Latency Issue: Where to Run the Reverse
Tunne l?

Ok, well, it seems like this issue hasn't stirred alot of comment. In
the interest of pushing the draft forward, I'd like to make the following
proposal. I think this will address Ajoy's comment about tunneling
compressed packets or PPP to the old FA, and also the comment in the
original issue summary about how to accommodate route optimization.

The proposal involves modifying the flag bits to indicate whether
the reverse tunnel should be terminated at the old FA or at the HA,
and whether route optimization is in effect.

Currently, we have 4 flag bits concerned with tunneling: M for minimal 
encapsulation supported, G for GRE encapsulation supported, T for reverse tunnel 
supported. These flag bits occur in both the Handoff Request and Handoff Reply.

I'd like to propose that we modify the tunneling flags as follows:

M - MN requested minimal encapsulation, use it in any tunnel with FA or HA
G - MN requested GRE encapsulation, use it in any tunnel with FA or HA
    (must be accompanied  by the GRE Key Extension if GRE security in 
     effect)
H -  MN requested reverse tunnel to HA, perform reverse tunnel regardless
     of egress filtering status on new subnet (the MN may be using 
     a private home address, for example). 
O - old FA is performing optimizations on MNs traffic (compression, 
    PPP, etc.), tunnel through the old FA regardless of egress filtering
     status on new subnet.
R - Route optimization is in effect and the MN is using CoA as the source
    address. MN's old CoA included in the message instead of the MN's 
    home address. The O bit MUST also be set.
    
The reverse tunnel termination point would be decided by the following
algorithm:

  If the H flag is set, the new FA MUST reverse tunnel to the HA regardless of
  the egress filtering status on the new subnet. This is because the
  MN requested reverse tunneling.
  
  If the O flag is set, the old FA is performing optimizations, such
  as compression, and therefore the new FA MUST reverse tunnel to
  the old FA regardless of the egress filtering status because the
  old FA must perform processing before the packets can be sent. This
  flag MUST also be set if the R flag is on, indicating that the 
  MN is performing route optimization.
  
  If neither the H nor the O flag are set, then the new FA can reverse tunnel
  to the HA, reverse tunnel to the old FA, or it can simply route packets
  directly onto its subnet if egress filtering is not on.
  
Note that if the new FA does NOT want to perform reverse tunneling but
the MN did not request reverse tunneling, the H flag MUST NOT be set.
The new FA indicates its unwillingness to reverse tunnel by 
a tunnel lifetime of zero in the Handoff Request or Handoff Reply, this 
indication applies to forward tunneling also.

If the R flag is set, the old FA sends the MN's old Care of Address
in place of the MN's Home Address, since the source address on
outgoing packets will be the MN's old Care of Address. The MN's 
HA address is also sent.

Comments?

			jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 6 Sep 2001 14:52:35 -0500

Thanks Alex.

Madjid

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 7:13 AM
To: [email-masked]
Subject: Re: [mobile-ip] Low Latency Issue: Where to Run the Reverse
Tunne l?

Nakhjiri Madjid-MNAKHJI1 <[email-masked]> writes:
> Hi,
> 
> looks like this draft is not accessible:
> 
> ftp://ftp.isi.edu/internet-drafts/draft-calhoun-mobileip-gre-ext-00.txt
> 
>  01 is on the ftp site but it has expired last week.
> Do you have a copy?
> 
> thanks,
> Madjid

We keep older versions of I-D's.

Alex

INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Microsystems, Inc.
Title: draft-calhoun-mobileip-gre-ext-00.txt                  Tom Hiller
Date: September 2000                                     Peter J. McCann
                                                     Lucent Technologies
                                                             Yingchun Xu
                                                        3Com Corporation

                             GRE Extensions

Status of this Memo

   This document is an individual contribution for consideration by the
   Mobile IP Working Group of the Internet Engineering Task Force.
   Comments should be submitted to the mobile-
   [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 its 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.

   Copyright   (C) The Internet Society 2000.  All Rights Reserved.

Abstract

   The GRE specification contains a Key field, which MAY contain a value

Calhoun et al.           expires February 2001                  [Page 1]

INTERNET DRAFT                                            September 2000

   that is used to identify a particular GRE "flow". This specification
   defines a new Mobile IP extensions that is used to exchange the value
   to be used in the GRE Key field.

   This specification also introduces a new extension, called the GRE
   Type extension, which is used during registration to signal the GRE
   type that will be used for the Mobile Node's session. This extension
   is deemed important in order to allow the Mobility Agents to setup
   the necessary protocol interfaces prior to receiving the mobile's
   traffic.

Table of Contents

      1.0  Introduction
            1.1  Requirements language
            1.2  Fast handoffs
      2.0  GRE Key extension
      3.0  GRE Type extension
      4.0  Error Values
      5.0  GRE Encapsulation
      6.0  IANA Considerations
      7.0  Security Considerations
      8.0  References
      9.0  Acknowledgements
      10.0  Authors' Addresses
      11.0  Full Copyright Statement

Calhoun et al.           expires February 2001                  [Page 2]

INTERNET DRAFT                                            September 2000

1.0  Introduction

   The GRE specification contains a Key field, which MAY contain a value
   that is used to identify a particular GRE "flow". This specification
   defines a new Mobile IP extensions that is used to exchange the value
   to be used in the GRE Key field.

   This specification also introduces a new extension, called the GRE
   Type extension, which is used during registration to signal the GRE
   type that will be used for the Mobile Node's session. This extension
   is deemed important in order to allow the Mobility Agents to setup
   the necessary protocol interfaces prior to receiving the mobile's
   traffic.

1.1  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [2].

2.0  GRE Key extension

   The GRE Key extension MAY be included in Registration Requests [1],
   and Regional Registration Requests [3] whose 'G' bit is enabled. The
   GRE Key extension is used to inform the recipient of the Mobile IP
   request of the value to be used in GRE's Key field.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Key Identifier                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD (non-skippable) [1]

      Length

         6

      Reserved

         This field MUST be set to zero (0).

Calhoun et al.           expires February 2001                  [Page 3]

INTERNET DRAFT                                            September 2000

      Key Identifier

         This is a four octet value assigned in the Registration or
         Regional Registration Request, and inserted in every GRE frame
         (see Section 5).

3.0  GRE Type extension

   The GRE Type extension MAY be included in Registration Requests [1],
   and Regional Registration Requests [3] whose 'G' bit is enabled. The
   GRE Type extension is used to signal to the peer the type of traffic
   that will be sent from the Mobile Node encapsulated in GRE. Note that
   only one GRE Type extension MAY be present in a request.

   If the GRE Type is not supported by the receiver of the Registration
   or Regional Registration Request, it MUST return the appropriate
   Reply with the Code field set to PROTO_NOT_SUPPORTED (see Section 4).

   If the GRE Type extension was present in the Request, all traffic for
   the Mobile Node MUST be of the type specified in this extension.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |           GRE Type            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD (skippable) [1]

      Length

         6

      GRE Type

         The GRE protocol type, as defined in [4].

4.0  Error Values

   The following table contains the name of Code [1] to be returned in a
   Registration and Regional Registration Replies, the value for the
   Code, and the section in which the error is first mentioned in this
   specification.

Calhoun et al.           expires February 2001                  [Page 4]

INTERNET DRAFT                                            September 2000

      Error Name               Value   Section of Document
      ----------------------   -----   -------------------
      PROTO_NOT_SUPPORTED       TBD    3.0

5.0  GRE Encapsulation

   When the Registration or Regional Registration Request has the 'G'
   bit enabled, contains the GRE Key extension, all GRE [4] encapsulated
   packets for the Mobile Node MUST include the value found in the
   extension within the GRE Key field [5]. The receiver of the GRE frame
   will use the Key field to identify the particular Mobility Binding.

6.0  IANA Considerations

   The GRE Key extension defined in Section 2 and the GRE Type extension
   are Mobile IP registration extension as defined in RFC 2002 [1] and
   extended in RFC 2356 [6]. IANA should assign a value of 131 for this
   purpose.

   The Code values defined in Section 4 are error codes as defined in
   RFC 2002 [1] and extended in RFC 2344 [7] and RFC 2356 [6].

7.0  Security Considerations

   This specification does not introduce any new security
   considerations, beyond those described in [1].

8.0  References

   [1]  C. Perkins, Editor. "IP Mobility Support". RFC 2002. October
        1996.

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

   [3]  E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional
        Registration", draft-ietf-mobileip-reg-tunnel-02.txt (work in
        progress), March 2000.

   [4]  Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P.,
        "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000.

   [5]  Gopal Dommety. "Key and Sequence Number Extensions to GRE".

Calhoun et al.           expires February 2001                  [Page 5]

INTERNET DRAFT                                            September 2000

        draft-dommety-gre-ext-04.txt, June 2000. (work in progress)

   [6]  Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
        Mobile IP", RFC 2356, June 1998.

   [7]  G. Montenegro.  Reverse Tunneling for Mobile IP.  Request for
        Comments (Proposed Standard) 2344, Internet Engineering Task
        Force, May 1998.

9.0  Acknowledgements

   The authors would like to thank the authors of draft-ietf-mobileip-
   3Gwireless-ext-04.txt, given that some text from that Internet Draft
   was copied into this specification.

10.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  +1 650 786 7733
         Fax:  +1 650 786 6445
      E-mail:  [email-masked]

      Gopal Dommety
      Cisco Systems
      170 West Tasman Drive
      San Jose, CA 95134

       Phone: +1 408 525 1404
      E-mail: [email-masked]

Calhoun et al.           expires February 2001                  [Page 6]

INTERNET DRAFT                                            September 2000

      Tom Hiller
      Lucent Technologies
      Rm 2F-218
      263 Shuman Blvd
      Naperville, IL  60566-7050
      USA

       Phone: +1 630 979 7673
         Fax: +1 630 979 7673
      E-Mail: [email-masked]

      Peter J. McCann
      Lucent Technologies
      Rm 2Z-305
      263 Shuman Blvd
      Naperville, IL  60566-7050
      USA

       Phone: +1 630 713 9359
         Fax: +1 630 713 4982
      E-Mail: [email-masked]

      Yingchun Xu
      3Com Corporation
      1800 West Central Road
      Mount Prospect,
      USA 60056

       Phone: +1 847 342 6814
      E-mail: [email-masked]

11.0  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this docu-
   ment itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as

Calhoun et al.           expires February 2001                  [Page 7]

INTERNET DRAFT                                            September 2000

   required to translate it into languages other than  English. The lim-
   ited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
   CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
   TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE."

Calhoun et al.           expires February 2001                  [Page 8]

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 6 Sep 2001 21:53:45 +0200

[ I haven't expressed my opinion on this to the rest of the 
authors so I'll just say it on the list]

James, 

	I'm just as confused as Pete, your use of "CoA" in the case
	where an FA is used seems really strange to me. 
	Are you saying the MN has a colocated CoA ? 
	If so what is the FA (or low latency draft's) role here ?

	Hesham

> > > My concern was that packets originating at the MN will be
> > > sent with the source address set to the care of address and
> > > not the home address, as would be the case if no route optimization
> > > were in effect. 
> >
> >Ok, I'm lost.  I managed to find an old (-07) version of the route
> >optimization draft, and I quickly searched through the new Reverse
> >Tunneling RFC.  I couldn't find where this requirement is stated.  My
> >current understanding of Route Optimization is that it only affects
> >the forward direction traffic.
> >
> 
> Right, but the MN will still put its CoA in as the source address
> on outgoing packets, I think.
> 
> >RFC 3024 states:
> >
> >   Route optimization [4] introduces forward tunnels initiated at a
> >   correspondent host.  Since a mobile node may not know if the
> >   correspondent host can decapsulate packets, reverse tunnels in that
> >   context are not discussed here.
> >
> >Does the new -11 version of R-O contain some text about reverse
> >tunnels?  It's too bad I can't look at it.  I think you are saying
> >that, even if the MN is using an FA-located COA, it would "borrow"
> >this address for the purpose of sending packets to CNs with which it
> >had arranged for route optimization, while implementing reverse
> >tunneling.  Essentially these "reverse tunnels" would go back to CNs,
> >but as we can't expect the FA to do source routing per-CN, the MN must
> >take care of it.  However, I'm just making up protocol now - could
> >someone tell me whether -11 R-O deals with this?  Better yet, could
> >someone put a copy up somewhere that I can read?
> >
> 
> I wasn't proposing that the reverse tunnel go back to  the CN, only
> that the new FA be able to use the MN CoA to index to the reverse tunnel
> to the old FA, since the packet coming from the MN will have the
> CoA and not the home address as the source address. But, as mentioned,
> this is unnecessary if the old FA uses the L2 address to
> identify which packet should go through the tunnel to the old FA.
> 
> But you do bring up an interesting point about how to deal with the
> case where the reverse tunnel needs to run to the CN. As far as
> low latency is concerned, I think we can basically punt since
> the route optimization draft doesn't propose to solve the
> fundamental problem.
> 
> > > I think saying there is no security is a bit strong, there
> > > could be security, it could be prearranged via context transfer
> > > or even some configuration step. I think it would be more precise
> > > to say that the new FA is not expected to set up a security 
> > > association in real time during the handover, but that it SHOULD,
> > > at its discretion, choose to support a reverse tunnel as well.
> >
> >Pre-arranged I could buy (although it would require some other MN from
> >that HA to have visited previously), but I hope we don't end up
> >transferring security associations.  SAs, especially IPSec SAs, are
> >indexed by IP address and I think it would be a bad idea to allow an
> >HA to start using an SA for a different communication endpoint just
> >because it started getting packets on it.
> >
> 
> OK.
> 
> >OK.  Does anyone have a copy of route optimization -11 that we could
> >use to resolve some of the questions above?
> >
> 
> I'll see if I can find one, but I think that I've got enough to go
> on now to rework the POST-REG/BETH  section of the low latency draft.
> Thanx.
> 
> 		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 13:04:33 -0700 (PDT)

Hesham,

As Peter pointed out, this is not an issue since the MN uses its 
home address as the source address regardless of whether route
optimization is in effect, unless the CoA is colocated.

		jak
		
>From: "Hesham Soliman  (ERA)" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: RE: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunne l?
>Date: Thu, 6 Sep 2001 21:53:45 +0200 
>