Subject: [netlmm] FW: I-D Action:draft-ietf-netlmm-grekey-option-06.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Feb 2009 10:27:21 -0600

Hello Jari and All,
We have submitted a new revision which addresses all received comments
todate.

Please take a look and let us know if you have any comments. 

Here is a brief list of the changes:

1. Demoted MUST to SHOULD in the case when the LMA receives a PBU with
the GRE Key option included and GRE encapsulation is NOT required. The
LMA SHOULD send a successful PBA with status code <GRE Key OPTION NOT
REQUIRED> without including the GRE key option.

2. Used the TLV-header format as originally suggested by Henrik and
presented and modified by Joel and Vijay.

3. Addressed Vijay's review comments.

4. Made the GRE Key option available and can be used by BU/BA between
the MN and the HA.

5. Some minor editorial changes.

Regards,
Ahmad 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, February 24, 2009 10:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-netlmm-grekey-option-06.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network-based Localized Mobility
Management Working Group of the IETF.

	Title           : GRE Key Option for Proxy Mobile IPv6
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-ietf-netlmm-grekey-option-06.txt
	Pages           : 24
	Date            : 2009-02-24

This specification defines a new Mobility Option for allowing the mobile
access gateway and the local mobility anchor to negotiate GRE (Generic
Routing Encapsulation) encapsulation mode and exchange the downlink and
uplink GRE keys which are used for marking the downlink and uplink
traffic that belong to a specific mobility session.  In addition, the
same mobility option can be used to negotiate the GRE encapsulation mode
without exchanging the GRE keys.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-grekey-option-06.t
xt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Joel Hortelius <[email-masked]>
Date: Thu, 26 Feb 2009 09:30:09 +0000

Hi Ahmad;

A few reflections;

The TLV tunneling format in 7.1 requires an IPV4 header as starter; the
DSMIP spec regarding tunneling  allows for IPV6 UDP encapsulation as
well; that is v6 -> UDP -> payload and not just v4 -> UDP -> payload.
Should the TLV format specifier allow for that as well?

A question regarding the negotiation as well; If I receive an UDP
encapsulated BU with GRE option but no T flag set; what would the
appropriate response be? Is it considered invalid and should be silently
dropped? One could switch to IP tunneling by discarding the GRE option
if policy allows, but if it doesn't?

Regards,
Joel Hortelius

On Tue, 2009-02-24 at 10:27 -0600, Ahmad Muhanna wrote:
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Feb 2009 10:49:17 -0600

Hi Joel,
Please see inline.

> Action:draft-ietf-netlmm-grekey-option-06.txt
> 
> Hi Ahmad;
> 
> A few reflections;
> 
> The TLV tunneling format in 7.1 requires an IPV4 header as 
> starter; the DSMIP spec regarding tunneling  allows for IPV6 
> UDP encapsulation as well; that is v6 -> UDP -> payload and 
> not just v4 -> UDP -> payload.

[Ahmad]
Do you mean we need to specify this for the scenario listed in section
5.4.1. of DSMIP6?

> 
> A question regarding the negotiation as well; If I receive an 
> UDP encapsulated BU with GRE option but no T flag set; what 
> would the appropriate response be? Is it considered invalid 
> and should be silently dropped? One could switch to IP 
> tunneling by discarding the GRE option if policy allows, but 
> if it doesn't?

[Ahmad]
I believe we have two cases here:

1. NAT device have been detected. In this case, the LMA would
communicate back to the MAG that NAT has been detected following DSMIP6.
In this case, we need the TLV-header before being able to use GRE.

2. If NAT has not been detected, then the MAG still can use GRE over
IPv4. No need for UDP nor TLV-header.

So probably we need to address case No. 1. IMO, there are two ways to do
it:

1. Document the scenario and mention if NAT has been detected, that MAG
will NOT be able to use UDP encapsulation with GRE without the
negotiation of TLV-header. This means, the MAG needs to resend the PBU
to negotiate TLV-header (T) flag.

-OR-

2. Introduce another code (less than 128) which state "GRE OVER UDP
REQUIRE TLVHEADER". LMA set this code only if it detects NAT device.

IMO, we do not need that code because it does not solve the issue of two
round trips. Still the MAG needs to resend a PBU to negotiate TLV header
if the MAG needs to use GRE with UDP.

> > This specification defines a new Mobility Option for allowing the 
> > mobile access gateway and the local mobility anchor to 
> negotiate GRE 
> > (Generic Routing Encapsulation) encapsulation mode and exchange the 
> > downlink and uplink GRE keys which are used for marking the 
> downlink 
> > and uplink traffic that belong to a specific mobility session.  In 
> > addition, the same mobility option can be used to negotiate the GRE 
> > encapsulation mode without exchanging the GRE keys.
> >